On Tuesday, 13 August 2013 at 10:09:11 UTC, Iain Buclaw wrote:
> On 13 August 2013 10:55, Joakim <joakim@airpost.net> wrote:
>> would only apply to the gmake binary.  The GPL is a very badly written
>> license, but I think it has been generally established that you can
>> distribute tools like gmake or g++ with your own code and that doesn't make
>> your own code have to be GPL, as long as gmake/g++ are only used to
>> process/compile your code and your own code doesn't integrate the source for
>> gmake/g++, ie gdc, which is almost never the case.
>>
>
> Pardon?  (I don't understand what point you are trying to put across
> about gdc, so I think it might be wrong ;-)
You seem to have a lot of problems reading what's written. ;) The point was that if you are distributing dmd and phobos source with GPL binary tools like gmake or g++, which are then only compiled by those binaries, there is no problem with the GPL.  You only need to provide the source for gmake and g++.  If you were distributing gdc, which actually integrates with the same compiler backend source as g++, then you have to include the source for the gdc frontend and whatever other glue files it uses.  Since most source code doesn't integrate with the gcc compiler backend, the GPL licensing of gmake/g++ is not a problem for most projects, including dmd.

On Tuesday, 13 August 2013 at 16:11:44 UTC, H. S. Teoh wrote:
> On Tue, Aug 13, 2013 at 11:55:12AM +0200, Joakim wrote:
> [...]
>> Personally, I like the D-based build system idea.  Distribute
>> dmd/phobos with a D-based build tool like dub, which has been
>> compiled ahead of time for each supported platform and will compile
>> D for you, if you want.  Of course, this means that you'll still
>> need to maintain makefiles on the D build machines that will build
>> dub for the D maintainers to distribute, but it isolates all the
>> complexity of makefiles from end users, so they don't have to touch
>> any of that stuff.  Whether that ease of use is worth the extra
>> effort, I don't know.
>
> There's no need to maintain any makefiles once the D build tool is
> usable. As long as you have a working binary of dmd that can compile the
> tool, that's good enough.
I thought you'd still need the makefiles around for the rare occasion when you bootstrap to a new platform, as the D-based build tool won't compile there initially.  Perhaps I'm wrong, I don't know much about all the vagaries involved with bootstrapping.

On Tuesday, 13 August 2013 at 18:10:06 UTC, Walter Bright wrote:
> On 8/13/2013 2:55 AM, Joakim wrote:
>> On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote:
>>> On 8/12/2013 11:48 PM, Jacob Carlborg wrote:
>>>> On 2013-08-13 02:42, Andrei Alexandrescu wrote:
>>>>
>>>>> Is is possible from a licensing standpoint to just distribute a copy of
>>>>> gmake built by gnuwin?
>>>>
>>>> I don't see why we couldn't do that. It's a completely separate tool and
>>>> shouldn't "infect" anything else. We might need to accompany it with a license
>>>> file and a link to the source code to be on the safe side.
>>>>
>>>
>>> Again, read my reply to Brad in this thread.
>>
>> Presumably you are referring to this quote, which does not show up as a reply?
>
> Nobody seems to have read it or be able to find it, it has no replies, so I quote it here:
I think we've all seen that post.  The problem is that Andrei, and Jacob later, were only asking about licensing issues with gmake, but your pasted response to Brad didn't mention licensing.  You're probably right that distributing gmake is problematic on technical and "ease of use" grounds.  I was just making a narrow point that the GPL likely isn't an issue, which is what Andrei and Jacob asked about.

On Tuesday, 13 August 2013 at 17:45:52 UTC, Nick Sabalausky wrote:
> That still involves the overhead of maintaining duplicate makefiles and
> a tendency for gradual divergence.

You complained about incompatible interface of the makefiles for intergation with your tool. The unified gnu makefile solves that problem. As it's said, dm makefile has its positive side.

On 13 August 2013 20:34, Joakim <joakim@airpost.net> wrote:
> On Tuesday, 13 August 2013 at 10:09:11 UTC, Iain Buclaw wrote:
>>
>> On 13 August 2013 10:55, Joakim <joakim@airpost.net> wrote:
>>>
>>> would only apply to the gmake binary.  The GPL is a very badly written
>>> license, but I think it has been generally established that you can
>>> distribute tools like gmake or g++ with your own code and that doesn't
>>> make
>>> your own code have to be GPL, as long as gmake/g++ are only used to
>>> process/compile your code and your own code doesn't integrate the source
>>> for
>>> gmake/g++, ie gdc, which is almost never the case.
>>>
>>
>> Pardon?  (I don't understand what point you are trying to put across about gdc, so I think it might be wrong ;-)
>
> You seem to have a lot of problems reading what's written. ;) The point was that if you are distributing dmd and phobos source with GPL binary tools like gmake or g++, which are then only compiled by those binaries, there is no problem with the GPL.  You only need to provide the source for gmake and g++.  If you were distributing gdc, which actually integrates with the same compiler backend source as g++, then you have to include the source for the gdc frontend and whatever other glue files it uses.  Since most source code doesn't integrate with the gcc compiler backend, the GPL licensing of gmake/g++ is not a problem for most projects, including dmd.
>
>

Right, the way you put it, looked like you were hinting that gdc was an example of code that doesn't integrate the source for g++...

Anyway, IMO on the matter.  Don't distribute binary blobs with source code.  If they wish to build a tool/library from source, leave instructions in a README to tell them where to get all prerequisites (eg: link to a tarball) if their distributiion does not provide packages for said prerequisites already.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 08/13/2013 12:48 AM, H. S. Teoh wrote:
> But you're missing the bigger picture. What I envision is that this D build tool will go beyond merely building DMD/druntime/Phobos. If it's successful, it can become the *standard* D build tool for all D programs. Having a standard D build tool will go a long way in making D programs portable and easy to install, besides freeing us from a dependency on make.

Can I suggest then that you write such a tool _first and foremost_ as a build system for arbitrary D programs (or preferably, arbitrary programs without reference to the language...)?  Then, if it gets uptake, proves a success, etc., we can consider whether it makes sense for the core D stuff.

The thing is that at the end of the day, make may have its problems but it is a well understood tool that is readily accessible to many developers and across platforms.  It also means that the build system is not dependent on one or two D hackers, who might fall under a bus, get a new job, whatever.

I really don't see the benefits of accepting the maintenance burden for a custom build system, with all the potential bottlenecks that introduces, compared to focusing on the things that really matter -- frontend, runtime, and standard library.