On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:
> On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
>> How about using reggae?
>>
>> https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
>
> I haven't studied either.

If you do study that reggae file, remember that it's a deliberate transliteration of the makefile and therefore is a lot more verbose than it *could* be if done from a clean slate or as a proper translation. IIRC it was done to show that reggae could do literally everything the makefile does, in the same way.

On 06/15/2016 08:05 AM, John Colvin wrote:
> On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:
>> On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
>>> How about using reggae?
>>>
>>> https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
>>
>> I haven't studied either.
>
> If you do study that reggae file, remember that it's a deliberate
> transliteration of the makefile and therefore is a lot more verbose than
> it *could* be if done from a clean slate or as a proper translation.
> IIRC it was done to show that reggae could do literally everything the
> makefile does, in the same way.

Does it do -j? -- Andrei

On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu wrote:
> On 06/15/2016 08:05 AM, John Colvin wrote:
>> On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:
>>> On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
>>>> How about using reggae?
>>>>
>>>> https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
>>>
>>> I haven't studied either.
>>
>> If you do study that reggae file, remember that it's a deliberate
>> transliteration of the makefile and therefore is a lot more verbose than
>> it *could* be if done from a clean slate or as a proper translation.
>> IIRC it was done to show that reggae could do literally everything the
>> makefile does, in the same way.
>
> Does it do -j? -- Andrei

It can work with multiple backends (make/tup/ninja), which all support -j. There is also a binary backend (creates an executable), not sure if that supports -j natively.

On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu wrote:
> On 06/15/2016 08:05 AM, John Colvin wrote:
>> On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:
>>> On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
>>>> How about using reggae?
>>>>
>>>> https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
>>>
>>> I haven't studied either.
>>
>> If you do study that reggae file, remember that it's a deliberate
>> transliteration of the makefile and therefore is a lot more verbose than
>> it *could* be if done from a clean slate or as a proper translation.
>> IIRC it was done to show that reggae could do literally everything the
>> makefile does, in the same way.
>
> Does it do -j? -- Andrei

Short answer: yes.

Long answer: it has multiple backends. I assume the one that'd be used for dmd/druntime/phobos would be the binary (compiled D code) one since that one doesn't have dependencies on anything else. It does what ninja does, which is to use the number of cores on the system. There are also the ninja, make and tup backends and those do what they do.

I've been meaning to update my reggae branch for a while but haven't been able to gather enough motivation. The part that just builds the library is easy (I haven't tried compiling the code below):

alias cObjs = objectFiles!(Sources!("etc/c/zlib"),
                           Flags("-m64 -fPIC -O3"));
alias dObjs = objectFiles!(Sources!(["std", "etc"]),
                           Flags("-conf= -m64 -w -dip25 -O -release"),
                           ImportPaths("../druntime/import"));
auto static_phobos = link("$project/generated/linux/release/64/libphobos",
                          cObjs ~ dObjs,
                          "-lib");

The problem is all the other targets, and I can't break any of them, and they're all annoying in their own special way. The auto-tester only covers a fraction and I have no idea if all of them are still being used by anyone. Does anyone do MinGW builds with posix.mak for instance? I'm half convinced it's broken.

Atila

On Wednesday, 15 June 2016 at 12:00:52 UTC, Andrei Alexandrescu wrote:
> I'd say the gating factor is -j. If an build system doesn't implement the equivalent of make -j, that's a showstopper.

Don't worry, there is a --threads option and it defaults to the number of logical cores.

I just did some tests and the reason it is slower than Make is because of the automatic dependency detection on every single command. I disabled the automatic dependency detection and compared it with Make again. Button was then roughly the same speed as Make -- sometimes it was faster, sometimes slower. Although, I think getting accurate dependencies at the cost of slightly slower builds is very much a worthwhile trade-off.

On Wednesday, 15 June 2016 at 12:02:56 UTC, Andrei Alexandrescu wrote:
> In all likelihood. One issue with build systems is there's no clear heir to make. There are so many, including a couple (!) by our community, each with its pros and cons. Which one should we choose?

You should choose mine, obviously. ;)

In all seriousness, Make will probably live as long as C. There are a *ton* of Makefiles out there that no one wants translate to a new build system. Part of the reason for that is probably because they are so friggin' incomprehensible and its not exactly glamorous work. This is why I'm working on that tool to allow Button to build existing Makefiles [1]. It may not work 100% of the time, but it should help a lot with migrating away from Make.

[1] https://github.com/jasonwhite/button-make

On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
>> Yeah, I have often thought that writing a self-contained D program to build D would work well. The full power of the language would be available, there'd be nothing new to learn, and all you'd need is an existing D compiler (which we already require to build).
>
> What about Attila's work with reggae?

Reggae still needs a prebuilt reggae to run the build script.

On Sunday, 12 June 2016 at 23:27:07 UTC, Jason White wrote:
> However, I question the utility of even doing this in the first place. You miss out on the convenience of using the existing command line interface.

Why the build script can't have a command line interface?

On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote:
> On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
>>> Yeah, I have often thought that writing a self-contained D program to build D would work well. The full power of the language would be available, there'd be nothing new to learn, and all you'd need is an existing D compiler (which we already require to build).
>>
>> What about Attila's work with reggae?
>
> Reggae still needs a prebuilt reggae to run the build script.

But seeing as you need a d compiler to build and anyway...

On Thursday, 16 June 2016 at 12:53:35 UTC, John Colvin wrote:
> On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote:
>> On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
>>>> Yeah, I have often thought that writing a self-contained D program to build D would work well. The full power of the language would be available, there'd be nothing new to learn, and all you'd need is an existing D compiler (which we already require to build).
>>>
>>> What about Attila's work with reggae?
>>
>> Reggae still needs a prebuilt reggae to run the build script.
>
> But seeing as you need a d compiler to build and anyway...

Ugh, autocorrect. s/and/dmd