[dmd-beta] 64 bit beta for Linux

[Jonathan M Davis]

On Sunday, February 06, 2011 19:41:13 Andrei Alexandrescu wrote:
> On 2/6/11 9:27 PM, Jonathan M Davis wrote:
> > On Sunday 06 February 2011 18:05:27 Andrei Alexandrescu wrote:
> >> Again, all we need to do is use a different macro than the default one.
> >> In hindsight, using D_Ddoc is a mistake as the user does not want to
> >> generate docs for Phobos but she does want to import stuff from it.
> > 
> > So, essentially we decide to treat druntime and Phobos differently with
> > regards to documentation by using a different macro on the assumption
> > that no one wants to build their ddoc documentation normally?
> 
> That would be the case for any library. Say A writes a library Deimos
> and B uses it and wants to generate documentation for their own project.
> Would they expect to generate docs for Deimos along the way?
> 
> > I'm not sure how this really solves the problem. Anyone who is building
> > their own code with version(D_Ddoc) blocks will find the problem
> > relatively quickly but they at least will then know how to fix it (don't
> > build your code with -D and generate your documentation separately). For
> > projects that _don't_ have that problem but use druntime and Phobos,
> > wouldn't they either just use prebuilt libraries for them or use
> > druntime and Phobos' makefiles when building them, at which point
> > whether they use -D on their project or not has nothing to do with
> > druntime or Phobos.
> 
> Currently Phobos imports are distributed in full. So we need to figure
> out a way to not mess up their -D with ours. In fact we don't need to
> figure out anything - let's just defined and use our own version
> PhobosDoc or whatnot.

If we're going to do this, we should look at doing it soon. At minimum, both 
std.datetime and std.file are affected by this issue. I believe that core.time is 
as well, so we should probably do something similar with druntime.

- Jonathan M Davis