June 15, 2016
On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote:
> Switching the compiler version seems to be a valid use case. You might have other means to detect this, though.

If you want to depend on the compiler version, then you can add a dependency on the compiler executable. It might be a good idea to have Button do this automatically for every command. That is, finding the path to the command's executable and making it a dependency.

> A possible use case is creating object files first and packing them into a library as a second step. Then single object files are of not much interest anymore. Imagine, you want to distribute a build to several development machines such that their local build environments are convinced that the build is up to date. If object files can be treated as secondary or intermediate targets you can save lots of unnecessary network traffic and storage.

You're right, that is a valid use case. In my day job, we have builds that produce 60+ GB of object files. It would be wasteful to distribute all that to development machines.

However, I can think of another scenario where it would just as well be incorrect behavior: Linking an executable and then running tests on it. The executable could then be seen by the build system as the "secondary" or "intermediate" output. If it gets deleted, I think we'd want it rebuilt.

I'm not sure how Make or Shake implement this without doing it incorrectly in certain scenarios. There would need to be a way to differentiate between necessary and unnecessary outputs. I'll have to think about this more.
June 14, 2016
On Wed, Jun 15, 2016 at 05:04:28AM +0000, Jason White via Digitalmars-d-announce wrote:
> On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote:
[...]
> > A possible use case is creating object files first and packing them into a library as a second step. Then single object files are of not much interest anymore. Imagine, you want to distribute a build to several development machines such that their local build environments are convinced that the build is up to date. If object files can be treated as secondary or intermediate targets you can save lots of unnecessary network traffic and storage.
> 
> You're right, that is a valid use case. In my day job, we have builds that produce 60+ GB of object files. It would be wasteful to distribute all that to development machines.
> 
> However, I can think of another scenario where it would just as well be incorrect behavior: Linking an executable and then running tests on it. The executable could then be seen by the build system as the "secondary" or "intermediate" output. If it gets deleted, I think we'd want it rebuilt.
> 
> I'm not sure how Make or Shake implement this without doing it incorrectly in certain scenarios. There would need to be a way to differentiate between necessary and unnecessary outputs. I'll have to think about this more.

I don't think Make handles this at all.  You'd just write rules in the Makefile to delete the intermediate files if you really care to. Most of the time people just ignore it, and add a 'clean' rule with some wildcards to cleanup the intermediate files.

(This is actually one of the sources of major annoyance with Makefiles: because of the unknown state of intermediate files, builds are rarely reproducible, and `make clean; make` is a ritual that has come to be accepted as a fact of life.  Arguably, though, a *proper* build system ought to be such that incremental builds are always correct and reproducible, and does not depend on environmental factors.)


T

-- 
Not all rumours are as misleading as this one.
June 15, 2016
On Tuesday, 14 June 2016 at 14:57:52 UTC, Andrei Alexandrescu wrote:
> On 6/12/16 8:27 PM, Walter Bright wrote:
>> On 5/30/2016 12:16 PM, Jason White wrote:
>>> Here is an example build description for DMD:
>>>
>>>     https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
>>>
>>> I'd say that's a lot easier to read than this crusty thing:
>>>
>>>     https://github.com/dlang/dmd/blob/master/src/posix.mak
>>
>> Yes, the syntax looks nice.
>
> Cool. Difference in size is also large. Do they do the same things? -- Andrei

Not quite. It doesn't download a previous version of dmd for bootstrapping and it doesn't handle configuration (e.g., x86 vs x64). About all it does is the bare minimum work necessary to create the dmd executable. I basically ran `make all -n` and converted the output because it's easier to read than the Makefile itself.

Building from scratch takes about 7 seconds on my machine (using 8 cores and building in /tmp). Make takes about 5 seconds. Guess I need to do some optimizing. :-)
June 15, 2016
On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
> On 6/12/2016 4:27 PM, Jason White wrote:
>> I don't understand this dependency-phobia.
>
> It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the people who just want to try it out.

I suppose you're right. It is just frustrating that people are unwilling to adopt clearly superior tools simply because it would introduce a new dependency. I'm sure D itself has the same exact problem.
June 15, 2016
On Wednesday, 15 June 2016 at 05:04:28 UTC, Jason White wrote:
> If you want to depend on the compiler version, then you can add a dependency on the compiler executable. It might be a good idea to have Button do this automatically for every command. That is, finding the path to the command's executable and making it a dependency.

I think you are fine if adding a dependency works. If it's done automatically someone will ask for a way to disable this feature.


> However, I can think of another scenario where it would just as well be incorrect behavior: Linking an executable and then running tests on it. The executable could then be seen by the build system as the "secondary" or "intermediate" output. If it gets deleted, I think we'd want it rebuilt.
>
> I'm not sure how Make or Shake implement this without doing it incorrectly in certain scenarios. There would need to be a way to differentiate between necessary and unnecessary outputs. I'll have to think about this more.

Shake has 'order only' dependencies that cover the 'intermediate' case. GNU make supports special targets '.INTERMEDIATE' and '.SECONDARY' [1].

[1] http://www.gnu.org/software/make/manual/make.html#Chained-Rules
June 15, 2016
On Monday, 13 June 2016 at 00:27:47 UTC, Walter Bright wrote:
> On 5/30/2016 12:16 PM, Jason White wrote:
>> Here is an example build description for DMD:
>>
>>     https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
>>
>> I'd say that's a lot easier to read than this crusty thing:
>>
>>     https://github.com/dlang/dmd/blob/master/src/posix.mak
>
> Yes, the syntax looks nice.

How about using reggae?

https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
June 15, 2016
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.
June 15, 2016
On Wednesday, 15 June 2016 at 05:42:21 UTC, Jason White wrote:
> On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
>> On 6/12/2016 4:27 PM, Jason White wrote:
>>> I don't understand this dependency-phobia.
>>
>> It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the people who just want to try it out.
>
> I suppose you're right. It is just frustrating that people are unwilling to adopt clearly superior tools simply because it would introduce a new dependency. I'm sure D itself has the same exact problem.

I am confident can build a lua to D transcompiler that works at CTFE.
June 15, 2016
On 6/15/16 1:29 AM, Jason White wrote:
> On Tuesday, 14 June 2016 at 14:57:52 UTC, Andrei Alexandrescu wrote:
>> On 6/12/16 8:27 PM, Walter Bright wrote:
>>> On 5/30/2016 12:16 PM, Jason White wrote:
>>>> Here is an example build description for DMD:
>>>>
>>>> https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
>>>>
>>>> I'd say that's a lot easier to read than this crusty thing:
>>>>
>>>>     https://github.com/dlang/dmd/blob/master/src/posix.mak
>>>
>>> Yes, the syntax looks nice.
>>
>> Cool. Difference in size is also large. Do they do the same things? --
>> Andrei
>
> Not quite. It doesn't download a previous version of dmd for
> bootstrapping and it doesn't handle configuration (e.g., x86 vs x64).
> About all it does is the bare minimum work necessary to create the dmd
> executable. I basically ran `make all -n` and converted the output
> because it's easier to read than the Makefile itself.

OK. I guess at least some of that stuff should be arguably scripted.

> Building from scratch takes about 7 seconds on my machine (using 8 cores
> and building in /tmp). Make takes about 5 seconds. Guess I need to do
> some optimizing. :-)

I'd say the gating factor is -j. If an build system doesn't implement the equivalent of make -j, that's a showstopper.


Andrei

June 15, 2016
On 6/15/16 1:42 AM, Jason White wrote:
> On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
>> On 6/12/2016 4:27 PM, Jason White wrote:
>>> I don't understand this dependency-phobia.
>>
>> It's the "first 5 minutes" thing. Every hiccup there costs us maybe
>> half the people who just want to try it out.
>
> I suppose you're right. It is just frustrating that people are unwilling
> to adopt clearly superior tools simply because it would introduce a new
> dependency. I'm sure D itself has the same exact problem.

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? -- Andrei