EPL and GPL are not compatible. Have a look at: http://dev.eclipse.org/blogs/mike/2010/04/06/epl-gpl-commentary/
Everything that is link with GPL needs to GPL as well. But has the link says there are ways around it. On the otherhand, I just remembered that the DMD frontend is licensed under the Artistic License.

/Jacob Carlborg?

On 09 Feb, 2011,at 10:02 PM, Andrew Wiley <debio264 at gmail.com> wrote:

> On Wed, Feb 9, 2011 at 1:16 PM, Jacob Carlborg <doob at me.com> wrote:
> > Yes, it's open source. It's based the DMD frontend, I think it's basically a
> > Java port of the  frontend. But in the long run it's hard to maintain,
> > constantly need to keep up with DMD and port the changes.
> > Actually I don't know how that is working out with the licenses. DMD fronten
> > is GPL and Eclipse is EPL and they're not compatible
> >
>
> Eclipse plugins can and have been published under almost every
> license. The fact that it's not EPL just means it won't be officially
> adopted by the Eclipse foundation, even if it ever reaches the level
> of maturity required.
> If you want to see the crazy licensing at work, take a look at
> Subversive, the official Eclipse Subversion plugin. The plugin itself
> is hosted at Eclipse, but the Subversion connectors that make it
> actually work have to be hosted off site and installed separately
> because the licenses don't match.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110210/742888d3/attachment.html>

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

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 <jmdavisProg at gmx.com> 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
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Thursday 10 February 2011 12:48:07 Andrei Alexandrescu wrote:
> Doesn't version(StdDdoc) take care of this as discussed?

I don't know. I've never heard of version(StdDdoc) that I recall. I thought that the issue was that we had to pick a version to use instead of version(D_Ddoc) (which could be StdDdoc) and then adjust the makefiles appropriately. So, unless the makefiles have already been adjusted, I don't see how version(StdDdoc) could work. Or maybe I'm missing or misunderstanding something here.

- Jonathan M Davis

On 2/10/11 3:20 PM, Jonathan M Davis wrote:
> On Thursday 10 February 2011 12:48:07 Andrei Alexandrescu wrote:
>> Doesn't version(StdDdoc) take care of this as discussed?
>
> I don't know. I've never heard of version(StdDdoc) that I recall. I thought that
> the issue was that we had to pick a version to use instead of version(D_Ddoc)
> (which could be StdDdoc) and then adjust the makefiles appropriately. So, unless
> the makefiles have already been adjusted, I don't see how version(StdDdoc) could
> work. Or maybe I'm missing or misunderstanding something here.

That is it. The makefile has not been adjusted but that's minor work. We'd essentially be getting back to our previous approach to generating documentation.

Andrei

On Thursday, February 10, 2011 13:55:26 Andrei Alexandrescu wrote:
> On 2/10/11 3:20 PM, Jonathan M Davis wrote:
> > On Thursday 10 February 2011 12:48:07 Andrei Alexandrescu wrote:
> >> Doesn't version(StdDdoc) take care of this as discussed?
> > 
> > I don't know. I've never heard of version(StdDdoc) that I recall. I
> > thought that the issue was that we had to pick a version to use instead
> > of version(D_Ddoc) (which could be StdDdoc) and then adjust the
> > makefiles appropriately. So, unless the makefiles have already been
> > adjusted, I don't see how version(StdDdoc) could work. Or maybe I'm
> > missing or misunderstanding something here.
> 
> That is it. The makefile has not been adjusted but that's minor work. We'd essentially be getting back to our previous approach to generating documentation.

Well, then I suggest that we adjust the makefiles relatively soon (before the next release certainly) for both druntime and phobos. And you're probably the man for the job in this case. You're the one dealing with the documentation on the website, and presumably you have a fair idea of what to do.

I'm perfectly willing to go and fix std.datetime and elsewhere to use version(StdDoc), but I don't want to be the one to edit the makefiles (though a search and replace on version(D_Ddoc) would be easy enough, so fixing the source files isn't hard).

- Jonathan M Davis

On Wed, 2011-02-09 at 08:24 -0700, Andrei Alexandrescu wrote:
> Is it open source? If so, is there interest out there in continuing it?
> 
> Sent by shouting through my showerhead.
> 
> On Feb 9, 2011, at 8:14 AM, Jesse Phillips <jesse.k.phillips at gmail.com> wrote:
> 
> > On Wed, Feb 9, 2011 at 5:00 AM, Jason House <jason.james.house at gmail.com
> > > wrote:
> >
> >> Does Descent work reasonably for D2 yet? Also, I thought that project died...
> >
> > I think it works but not to well wit some of D2 features.
> >
> > Yes it is no longer under development, doesn't mean you can't use it.
> > _______________________________________________
> > dmd-beta mailing list
> > dmd-beta at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/dmd-beta
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

DDT (dsource has a link to the page) is developed, and excellent.

I'll take care of that.

Sent by shouting through my showerhead.

On Feb 10, 2011, at 11:40 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Thursday, February 10, 2011 13:55:26 Andrei Alexandrescu wrote:
>> On 2/10/11 3:20 PM, Jonathan M Davis wrote:
>>> On Thursday 10 February 2011 12:48:07 Andrei Alexandrescu wrote:
>>>> Doesn't version(StdDdoc) take care of this as discussed?
>>>
>>> I don't know. I've never heard of version(StdDdoc) that I recall. I
>>> thought that the issue was that we had to pick a version to use
>>> instead
>>> of version(D_Ddoc) (which could be StdDdoc) and then adjust the
>>> makefiles appropriately. So, unless the makefiles have already been
>>> adjusted, I don't see how version(StdDdoc) could work. Or maybe I'm
>>> missing or misunderstanding something here.
>>
>> That is it. The makefile has not been adjusted but that's minor work.
>> We'd essentially be getting back to our previous approach to
>> generating
>> documentation.
>
> Well, then I suggest that we adjust the makefiles relatively soon
> (before the
> next release certainly) for both druntime and phobos. And you're
> probably the
> man for the job in this case. You're the one dealing with the
> documentation on
> the website, and presumably you have a fair idea of what to do.
>
> I'm perfectly willing to go and fix std.datetime and elsewhere to use
> version(StdDoc), but I don't want to be the one to edit the
> makefiles (though a
> search and replace on version(D_Ddoc) would be easy enough, so
> fixing the source
> files isn't hard).
>
> - Jonathan M Davis
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Hi,

Walter Bright wrote:
> did all but 4092 and 5051.
>> http://d.puremagic.com/issues/show_bug.cgi?id=4014 CodeView debug type info not linked in from library

trying to create a branch with as little changes to the master branch as possible, I noticed that this patch causes problems when creating DLLs (it still wants _Dmain to be defined). This is happening because the patch puts full modules into a library instead of single functions when also adding debug symbols, so any reference into rt.dmain2 drags in the standard console application startup. My patches to create a shared version of the runtime library split this module, so the issue did not show up before.

I'd say the patch to 4014 should be reverted until this is sorted out. A minor improvement could be that prohibiting multiobj generation should be limited to debug builds in addition to adding debug symbols (which could also happen for release builds).

I've found a few more issues while trying to create that branch which I will post to bugzilla, but my lack of knowledge of git gets in the way and leaves me entangled in branches...

Rainer

Rainer Schuetze wrote:
>
> I've found a few more issues while trying to create that branch which I will post to bugzilla, but my lack of knowledge of git gets in the way and leaves me entangled in branches...
>
I've reported them in bugzilla, the most important for me is http://d.puremagic.com/issues/show_bug.cgi?id=5582 (Improvements to the DLL startup code).

This version of dmd is the first one that does not need patching dmd to compile visuald, though it misses some goodies. The library still needs to get my hands a little dirty.

A few things noted on the beta:

- the regression on join(stringarray, std.string.newline) not working is
still in there
- the generated druntime import files have mixed line-endings:
everything seems CR LF, but not after "static this();", it's LF only there.

Thanks,
Rainer