On 2013-08-10 20:35, Nick Sabalausky wrote:
> Although it took longer than I expected to get around to it, I'm
> working on a release-generator tool for DMD. I'm finding that a very
> significant amount of the effort involved (much more than I expected)
> is discovering and dealing with all the fun little differences between
> the posix and win32 makefiles (and now we have some win64 makefiles as
> well).
>
> Efforts can be made to decrease these differences, but simply
> having them separate makefiles in the first place (let alone using
> completely different "make"s: GNU make vs DM make) is a natural
> invitation for divergence.
>
> No disrespect intended to Digital Mars Make, but since GNU make appears
> to be more feature-rich, have wider overall adoption, and is freely
> available on Windows as a pre-built binary
> <http://gnuwin32.sourceforge.net/packages/make.htm>: Would it be
> acceptable to use gmake as *the* make for DMD? Ie, either convert the
> windows makefiles to gmake, or expand the posix makefiles to support
> windows?
>
> I'd be willing to give it a shot myself, and I could trivially
> write a small batch utility to download Win gmake and put it on the
> current PATH, so that nobody has to go downloading/installing it
> manually. I would do this *after* finishing the release-generator tool,
> but afterwords it would allow the tool's implantation to be greatly
> simplified.
>
> Is this something that would be acceptable, or does building DMD for
> Windows need to stay as DM make?

This might not be entirely related to the DMD makefiles but with the druntime and Phobos makefiles I really hate that if I need to add a new module I need to repeat the name several times. So whatever happens to the makefiles, I would prefer that the files that should be compiled shouldn't have to be mentioned at all (or at most once). I just compile everything in a directory with the correct extensions.

-- 
/Jacob Carlborg

On 2013-08-12 00:38, H. S. Teoh wrote:

> Maybe my previous post didn't get the idea across clearly, so let me try
> again. My underlying thrust was: instead of maintaining 3 different
> makefiles (or more) by hand, have a single source for all of them, and
> write a small D program to generate posix.mak, win32.mak, win64.mak,
> whatever, from that source.

If it's written in D it will have the same bootstrap problem. But perhaps that's ok since we're moving DMD to D anyway.

-- 
/Jacob Carlborg

On 2013-08-12 20:06, Russel Winder wrote:

> This is where Waf has a benefit. SCons can put the build system with the
> project leaving only a Python dependency, but Waf is built for this mode
> of working.

Why don't they embed Python inside SCons, at least as an option.

-- 
/Jacob Carlborg

On Sunday, August 11, 2013 13:36:54 Walter Bright wrote:
> On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control. Some issues:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=10710
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=8756

Of course, if having libcurl in Phobos is causing enough problems, that raises the question as to whether we should reverse our decision to include it in Phobos. That would of course create it's own set of problems, because it would break existing code, but it would be trivial enough to change such code to import a separate library rather than std.net.curl if we decided that including it in Phobos was causing enough problems that it wasn't worth it and moved std.net.curl to somewhere else outside of Phobos.

- Jonathan M Davis

On 2013-08-12 21:03, Sean Kelly wrote:

> I suppose std.zip is in the same boat.

Not entirely, since we include the source code for libz.

-- 
/Jacob Carlborg

On Monday, 12 August 2013 at 16:29:36 UTC, H. S. Teoh wrote:
> On Mon, Aug 12, 2013 at 11:16:19AM +0100, Russel Winder wrote:
>> On Sun, 2013-08-11 at 15:41 -0700, H. S. Teoh wrote:
>> > On Sun, Aug 11, 2013 at 09:26:11AM +0100, Russel Winder wrote:
>> > > On Sat, 2013-08-10 at 14:27 -0400, Nick Sabalausky wrote:
>> > > […]
>> > > > is discovering and dealing with all the fun little differences
>> > > > between the posix and win32 makefiles (and now we have some
>> > > > win64 makefiles as well).
>> > > […]
>> > > 
>> > > Isn't this sort of problem solved by using SCons, Waf or (if you
>> > > really have to) CMake?
>> > [...]
>> > 
>> > +1. But people around here seems to have a beef against anything
>> > that isn't make. *shrug*
>> 
>> Make was a revolution and a revelation in 1977, it changed my life.
>> However, it is sad to see projects such as Rust, Julia and D clinging
>> to a 35 year old build concept when it has been proved time and time
>> again that external DSL frameworks for build do not work for
>> cross-platform working. Only internal DSL build frameworks have
>> succeeded in that arena, cf. Gradle, SBT, SCons, Waf,…
>
> +1. If I were the one making the decisions, I'd go for SCons. Or tup
> (http://gittup.org/tup/), but tup seems to be currently posix-specific,
> so SCons still wins if you want cross-platform building.
>
>
>> The only part of this thread that has any up side at all is to ditch
>> all build frameworks and write the build in D over the bootstrap D
>> that will be essential for the D build since D is written in D. It's a
>> pity Rust hasn't twigged to this.
>
> I think the D build tool should extend / be built on top of rdmd to be
> able to handle non-D sources. Once we have that, we basically already
> have a working build system.
>
>
>> I note that the Go tooling is written is C and Go, they ditched make
>> when they realized their vision for packaging – which works very well
>> indeed, particularly pulling in source packages from GitHub, BitBucket
>> and Launchpad, compiling and installing the compiled package into the
>> appropriate place for use.
>
> I ditched make about a decade ago, and I would never go back if I had
> the choice. Sadly, most of the rest of the world still seems stuck in
> that quagmirem, unable to move on.
>
>
>> On the other hand, I bet a cross-platform SCons build of D could be in
>> place and production within days as opposed to the
>> <substitute-your-favourite-long-time> that a D rewrite in D will take.
>> It doesn't matter than the SCons build may be thrown away down the
>> line, it solves a problem now for not that much effort.
>
> What do you say? Let's throw together an SConstruct for DMD, druntime,
> and phobos, and submit a pull for it?
>
> The only downside is that I can predict people will start complaining
> about the Python dependency. (Which is why I proposed writing a build
> system in D -- it will be superior to make (anything would be!), and
> people will have no excuse about what language it's written in.)
>
>
>> Still if the core D community are clinging to "build == make", then
>> they will have to suffer the irritant of having to have a separate
>> build system for each and every platform. That's they way Make is.
> [...]
>
> I used to evangelize SCons to everybody I meet... but after people
> adamantly refused to abandon their precious outdated crappy makefiles, I
> gave up. If they wish to continue suffering, it's not really my business
> to stop them.
>
>
> T

Thanks for the link! I found this excellent paper there: http://gittup.org/tup/build_system_rules_and_algorithms.pdf . :)

On Monday, 12 August 2013 at 16:29:36 UTC, H. S. Teoh wrote:
> On Mon, Aug 12, 2013 at 11:16:19AM +0100, Russel Winder wrote:
>> On Sun, 2013-08-11 at 15:41 -0700, H. S. Teoh wrote:
>> > On Sun, Aug 11, 2013 at 09:26:11AM +0100, Russel Winder wrote:
>> > > On Sat, 2013-08-10 at 14:27 -0400, Nick Sabalausky wrote:
>> > > […]
>> > > > is discovering and dealing with all the fun little differences
>> > > > between the posix and win32 makefiles (and now we have some
>> > > > win64 makefiles as well).
>> > > […]
>> > > 
>> > > Isn't this sort of problem solved by using SCons, Waf or (if you
>> > > really have to) CMake?
>> > [...]
>> > 
>> > +1. But people around here seems to have a beef against anything
>> > that isn't make. *shrug*
>> 
>> Make was a revolution and a revelation in 1977, it changed my life.
>> However, it is sad to see projects such as Rust, Julia and D clinging
>> to a 35 year old build concept when it has been proved time and time
>> again that external DSL frameworks for build do not work for
>> cross-platform working. Only internal DSL build frameworks have
>> succeeded in that arena, cf. Gradle, SBT, SCons, Waf,…
>
> +1. If I were the one making the decisions, I'd go for SCons. Or tup
> (http://gittup.org/tup/), but tup seems to be currently posix-specific,
> so SCons still wins if you want cross-platform building.
>
>
>> The only part of this thread that has any up side at all is to ditch
>> all build frameworks and write the build in D over the bootstrap D
>> that will be essential for the D build since D is written in D. It's a
>> pity Rust hasn't twigged to this.
>
> I think the D build tool should extend / be built on top of rdmd to be
> able to handle non-D sources. Once we have that, we basically already
> have a working build system.
>
>
>> I note that the Go tooling is written is C and Go, they ditched make
>> when they realized their vision for packaging – which works very well
>> indeed, particularly pulling in source packages from GitHub, BitBucket
>> and Launchpad, compiling and installing the compiled package into the
>> appropriate place for use.
>
> I ditched make about a decade ago, and I would never go back if I had
> the choice. Sadly, most of the rest of the world still seems stuck in
> that quagmirem, unable to move on.
>
>
>> On the other hand, I bet a cross-platform SCons build of D could be in
>> place and production within days as opposed to the
>> <substitute-your-favourite-long-time> that a D rewrite in D will take.
>> It doesn't matter than the SCons build may be thrown away down the
>> line, it solves a problem now for not that much effort.
>
> What do you say? Let's throw together an SConstruct for DMD, druntime,
> and phobos, and submit a pull for it?
>
> The only downside is that I can predict people will start complaining
> about the Python dependency. (Which is why I proposed writing a build
> system in D -- it will be superior to make (anything would be!), and
> people will have no excuse about what language it's written in.)
>
>
>> Still if the core D community are clinging to "build == make", then
>> they will have to suffer the irritant of having to have a separate
>> build system for each and every platform. That's they way Make is.
> [...]
>
> I used to evangelize SCons to everybody I meet... but after people
> adamantly refused to abandon their precious outdated crappy makefiles, I
> gave up. If they wish to continue suffering, it's not really my business
> to stop them.
>

I am one of them. In my real life I use Maven most of the time, but for absolutely everything else, including (small/toy) Java projects, I use GNU Make. I know it is does not really matter to many people, but honestly, Make exists on EVERY platform I have ever tried. We have OpenVMS servers here for an example. Guess what, make works like a charm there, and everybody knows (more/less) how to use it. :)

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.

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?

"Oh, I forgot to mention, licensing.

We want Phobos to be free of any restrictive licensing. GPL is restrictive, and
so is LGPL.

We very deliberately picked Boost. Having Phobos be a mix of GPL and Boost would
utterly defeat picking Boost."

If you're only talking about distributing a GPL-licensed gmake binary with dmd/phobos, I don't think it has any impact on Phobos licensing, ie the GPL 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.

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.

On 13 August 2013 10:55, Joakim <joakim@airpost.net> 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?
>
>
> "Oh, I forgot to mention, licensing.
>
> We want Phobos to be free of any restrictive licensing. GPL is restrictive,
> and
> so is LGPL.
>
> We very deliberately picked Boost. Having Phobos be a mix of GPL and Boost
> would
> utterly defeat picking Boost."
>
> If you're only talking about distributing a GPL-licensed gmake binary with dmd/phobos, I don't think it has any impact on Phobos licensing, ie the GPL 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 ;-)

-- 
Iain Buclaw

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