Doesn't version(StdDdoc) take care of this as discussed?
Sent by shouting through my showerhead.
On Feb 10, 2011, at 12:25 PM, Jonathan M Davis <[email protected]>
wrote:
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
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
