On 2016-06-01 06:34, Jason White wrote:

> Building it only requires dmd+phobos+dub.
>
> Why is having dependencies so damaging for build systems? Does it really
> matter with a package manager like Dub? If there is another thread that
> answers these questions, please point me to it.
>
> The two dependencies Button itself has could easily be moved into the
> same project. I kept them separate because they can be useful for
> others. These are the command-line parser and IO stream libraries.
>
> As for the dependency on Lua, it is statically linked into a separate
> executable (called "button-lua") and building it is dead-simple (just
> run make). Using the Lua build description generator is actually
> optional, it's just that writing build descriptions in JSON would be
> horribly tedious.

So, Lua is a build dependency? Seems that Sqlite is a build dependency as well.

-- 
/Jacob Carlborg

On Wednesday, 1 June 2016 at 06:41:17 UTC, Jacob Carlborg wrote:
> So, Lua is a build dependency? Seems that Sqlite is a build dependency as well.

Actually, SQLite more of a run-time dependency because etc.c.sqlite3 comes with DMD.

$ ldd button
    linux-vdso.so.1 (0x00007ffcc474c000)
--> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007f2d13641000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2d13421000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f2d13119000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007f2d12f11000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f2d12d09000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f2d12af1000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f2d12749000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2d13951000)

On 2016-06-01 08:48, Jason White wrote:

> Actually, SQLite more of a run-time dependency because etc.c.sqlite3
> comes with DMD.
>
> $ ldd button
>      linux-vdso.so.1 (0x00007ffcc474c000)
> --> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007f2d13641000)
>      libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2d13421000)
>      libm.so.6 => /usr/lib/libm.so.6 (0x00007f2d13119000)
>      librt.so.1 => /usr/lib/librt.so.1 (0x00007f2d12f11000)
>      libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f2d12d09000)
>      libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f2d12af1000)
>      libc.so.6 => /usr/lib/libc.so.6 (0x00007f2d12749000)
>      /lib64/ld-linux-x86-64.so.2 (0x00007f2d13951000)

So it's both a build and runtime dependency ;)

-- 
/Jacob Carlborg

On Wednesday, 1 June 2016 at 04:34:23 UTC, Jason White wrote:
> Why is having dependencies so damaging for build systems? Does it really matter with a package manager like Dub? If there is another thread that answers these questions, please point me to it.

Rephrasing one famous advice, "every added tooling dependency in an open-source project reduces amount of potential contributors by half" :) Basically, one can expect that anyone working with D will have dmd/phobos and, hopefully, dub. No matter how cool Button is, if it actually needs to be installed in contributor system to build a project, it is very unlikely to be widely used.

That issue can be reduced by making Button itself trivially built from plain dmd/phobos/dub install and configuring the project to bootstrap it if not already present - but that only works if you don't also need to install bunch of additional tools like sqlite or make.

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
```

On Mon, May 30, 2016 at 07:16:50PM +0000, Jason White via Digitalmars-d-announce wrote:
> I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time:
> 
>     Docs:   http://jasonwhite.github.io/button/
>     Source: https://github.com/jasonwhite/button
> 
> Features:
> 
> - Correct incremental builds.
> - Automatic dependency detection (for any build task, even shell scripts).
> - Build graph visualization using GraphViz.
> - Language-independent. It can build anything.
> - Can automatically build when an input file is modified (using inotify).
> - Recursive: It can build the build description as part of the build.
> - Lua is the primary build description language.

Finally got around to looking at this (albeit just briefly). It looks very nice!  Perhaps I'll try using it for my next project.

I'm particularly pleased with the bipartite graph idea. It's a very nice way of sanely capturing the idea of build commands that generate multiple outputs.  Also big plusses in my book are implicit dependencies and use of inotify to eliminate the infamous "thinking pause" that older build systems all suffer from (this idea was also advanced by tup, but IMO Button looks a tad more polished than tup in terms of overall design).  Of course, being written in D is a bonus in my book. :-D Though realistically speaking it probably doesn't really matter to me as an end user, other than just giving me warm fuzzies.

Unfortunately I don't have the time right now to actually do anything non-trivial with it... but I'll try to give feedback when I do get around to it (and I definitely plan to)!


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.

On Saturday, 11 June 2016 at 02:48:59 UTC, H. S. Teoh wrote:
> Finally got around to looking at this (albeit just briefly). It looks very nice!  Perhaps I'll try using it for my next project.

If you do end up using it, I'd be happy to iron out any irritations in Button that you encounter.

Button really needs a large project using it to help drive refinements.

> I'm particularly pleased with the bipartite graph idea. It's a very nice way of sanely capturing the idea of build commands that generate multiple outputs.  Also big plusses in my book are implicit dependencies and use of inotify to eliminate the infamous "thinking pause" that older build systems all suffer from (this idea was also advanced by tup, but IMO Button looks a tad more polished than tup in terms of overall design).  Of course, being written in D is a bonus in my book. :-D Though realistically speaking it probably doesn't really matter to me as an end user, other than just giving me warm fuzzies.

Tup has had a big influence on the design of Button (e.g., a bipartite graph, deleting unused outputs, implicit dependencies, using Lua, etc.). Overall, I'd say Button does the same or better in every respect except maybe speed.

About it being written in D: If Rust had been mature enough when I first started working on it, I might have used it instead. All I knew is that I didn't want to go through the pain of writing it in C/C++. :-)

> Unfortunately I don't have the time right now to actually do anything non-trivial with it... but I'll try to give feedback when I do get around to it (and I definitely plan to)!

Thanks! I look forward to it!

On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
> I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time:
>
>     Docs:   http://jasonwhite.github.io/button/
>     Source: https://github.com/jasonwhite/button
>
> Features:
>
> - Correct incremental builds.
> - Automatic dependency detection (for any build task, even shell scripts).
> - Build graph visualization using GraphViz.
> - Language-independent. It can build anything.
> - Can automatically build when an input file is modified (using inotify).
> - Recursive: It can build the build description as part of the build.
> - Lua is the primary build description language.

Nice work! I'm wondering how Button would compare in the Build System Shootout (https://github.com/ndmitchell/build-shootout).

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).

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).

What about Attila's work with reggae?

On Sunday, 12 June 2016 at 11:06:23 UTC, Fool wrote:
> Nice work! I'm wondering how Button would compare in the Build System Shootout (https://github.com/ndmitchell/build-shootout).

It does pretty well. I even looked over this as I was designing it.

Here's the test cases it succeeds at:

- "basic: Basic dependency"
- "parallel: Parallelism"
- "include: C #include files"
- "wildcard: Build a file specified by an extension wildcard" (Via generating the build description.)
- "spaces: Build a file containing spaces"
- "monad1: Monadic patterns"
- "monad2: More monadic patterns"
- "monad3: More monadic patterns"
- "unchanged: Handle files which do not change"
- "multiple: Rules with multiple outputs"
- "digest: Don't rebuild when a file is modified to the same value"
- "nofileout: Don't produce an output file"

And the ones it fails at:

- "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.)
- "system2: Dependency on system environment variable" (Button doesn't know about environment variables.)
- "pool: Limit the parallelism in a specific stage" (I'm not sure how useful this is, but it could be added.)
- "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.)

As for the "Build System Power" section:

- Yes: Pre dependencies
- Yes: Post dependencies
- Yes: Mid dependencies
- Yes: Auto post dependencies
- Not yet: Auto cached commands

I'd say it's more robust than any other single build system there, but I'm biased. :-)

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