On Sunday, 12 June 2016 at 20:03:06 UTC, Walter Bright wrote:
> On 6/3/2016 1:26 AM, Dicebot wrote:
>> From that perspective, the best build system you could possibly have would look
>> like this:
>>
>> ```
>> #!/usr/bin/rdmd
>>
>> import std.build;
>>
>> // define your build script as D code
>> ```
>
> 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).

The core functionality of Button could be split off into a library fairly easily and there would be no dependency on Lua. Using it might look something like this:

import button;

immutable Rule[] rules = [
    {
        inputs: [Resource("foo.c"), Resource("baz.h")],
        task: Task([Command(["gcc", "-c", "foo.c", "-o", "foo.o"])]),
        outputs: [Resource("foo.o")]
    },
    {
        inputs: [Resource("bar.c"), Resource("baz.h")],
        task: Task([Command(["gcc", "-c", "bar.c", "-o", "bar.o"])]),
        outputs: [Resource("bar.o")]
    },
    {
        inputs: [Resource("foo.o"), Resource("bar.o")],
        task: Task([Command(["gcc", "foo.o", "bar.o", "-o", "foobar"])]),
        outputs: [Resource("foobar")]
    }
];

void main()
{
    build(rules);
}

Of course, more abstractions would be added to make creating the list of rules less verbose.

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. And for what? Just so everything can be in D? Writing the same thing in Lua would be much prettier. I don't understand this dependency-phobia.

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.

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.

Even the makefiles have hiccups. I've had builds fail with the dmd system because I had the wrong version of make installed. And it doesn't fail with "you have the wrong make program installed" messages, it fails with some weird error message pointing into the middle of the makefile.

The makefiles, especially posix.mak, have grown into horrific snarls of who-knows-what-is-happening. I hate makefiles that call other makefiles. Sometimes I feel like chucking them all and replacing them with a batch file that is nothing more than an explicit list of commands:

    dmd -c file1.d
    dmd -c file2.d

etc. :-)

On 2016-06-13 22:12, Walter Bright wrote:

> It's the "first 5 minutes" thing. Every hiccup there costs us maybe half
> the people who just want to try it out.
>
> Even the makefiles have hiccups. I've had builds fail with the dmd
> system because I had the wrong version of make installed. And it doesn't
> fail with "you have the wrong make program installed" messages, it fails
> with some weird error message pointing into the middle of the makefile.
>
> The makefiles, especially posix.mak, have grown into horrific snarls of
> who-knows-what-is-happening. I hate makefiles that call other makefiles.
> Sometimes I feel like chucking them all and replacing them with a batch
> file that is nothing more than an explicit list of commands:
>
>     dmd -c file1.d
>     dmd -c file2.d
>
> etc. :-)

I couldn't agree more. With the D compiler being so fast it's reasonable to just recompile everything at once instead of trying to track what's changed.

-- 
/Jacob Carlborg

On Tuesday, 14 June 2016 at 07:45:10 UTC, Jacob Carlborg wrote:
> I couldn't agree more. With the D compiler being so fast it's reasonable to just recompile everything at once instead of trying to track what's changed.

i'm agree with that. i'm so used to do just "rdmd main.d" in my projects (ranged from "hello, world" to complex game engines).

On Sunday, 12 June 2016 at 22:59:15 UTC, Jason White wrote:
> - "system1: Dependency on system information" (Because tasks with no dependencies are only run once. This could be changed easily enough, but I don't see the point.)

Switching the compiler version seems to be a valid use case. You might have other means to detect this, though.


> - "secondary: Secondary target" (I think this is incorrect behavior and not a feature.)
> - "intermediate: Intermediate target" (Same reason as "secondary". If this is really needed, it should be encapsulated inside a single task.)

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.

> I should probably make a pull request to add it to the shootout.

It might help advertising. :-)

14.06.2016 13:04, ketmar пишет:
> On Tuesday, 14 June 2016 at 07:45:10 UTC, Jacob Carlborg wrote:
>> I couldn't agree more. With the D compiler being so fast it's
>> reasonable to just recompile everything at once instead of trying to
>> track what's changed.
>
> i'm agree with that. i'm so used to do just "rdmd main.d" in my projects
> (ranged from "hello, world" to complex game engines).
I don't agree if you don't mind. I have two almost identical implementation of the same thing in D and C++. And if I rebuild them totally - yes, dmd is faster than gcc:
	dmd        5 secs
	ldmd2      6 secs
	make      40 secs
	make -j10 11 secs

But if I changed several lines only then dmd time doesn't change and gcc takes much less time. In fact digits are small for D, but I feel the difference really. Not big, not bad, but it exists.

On 2016-06-14 14:04, drug wrote:

> I don't agree if you don't mind. I have two almost identical
> implementation of the same thing in D and C++. And if I rebuild them
> totally - yes, dmd is faster than gcc:
>     dmd        5 secs
>     ldmd2      6 secs
>     make      40 secs
>     make -j10 11 secs
>
> But if I changed several lines only then dmd time doesn't change and gcc
> takes much less time. In fact digits are small for D, but I feel the
> difference really. Not big, not bad, but it exists.

For me, IIRC, it takes longer time to recompile a single C++ file from the DMD source code than it takes to build Phobos from scratch. What's slowing down the compilation of Phobos is the C code.

-- 
/Jacob Carlborg

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

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.
>
> ...
>
> The makefiles, especially posix.mak, have grown into horrific snarls of who-knows-what-is-happening.

I had a minor rant about this at DConf.  The makefiles are the major reason I haven't contributed to the core D projects.

They'd be a hell of a lot simpler if everything that isn't building an executable (and isn't idempotent) got ripped out.  No downloading compilers, no cloning/updating repos, etc, etc.  Having a pushbutton process for installing/bootstrapping is cool, but that stuff is better off in scripts.