On 9/24/14, 3:18 PM, Atila Neves wrote:
> On Wednesday, 24 September 2014 at 21:12:15 UTC, Andrei Alexandrescu wrote:
>> On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
>>> That's unfortunate indeed. I wish I could inspire them as to how cool a
>>> properly-done build system can be.
>> [snip]
>>
>> That's all nice. However: (1) the truth is there's no clear modern
>> build tool that has "won" over make; oh there's plenty of them, but
>> each has its own quirks that makes it tenuous to use; (2) any build
>> system for a project of nontrivial size needs a person/team minding it
>> - never saw such a thing as it's just all automated and it works; (3)
>> especially if the build system is not that familiar, the role of the
>> build czar is all the more important.
>>
>> So the reality is quite a bit more complicated than the shiny city on
>> a hill you describe.
>>
>>
>> Andrei
>
> It depends on who you ask, I guess. I don't know what the definition of
> "has won" here is.

Simple: ask 10 random engineers "we need a build system". There's no dominant answer. Well except maybe for make :o). Case in point: we have two at Facebook, both created in house.

But even that's beside the point. The plea here implies D devs are enamored with make and won't change their ways. Not at all! If there were a better thing with a strong champion, yay to that. But we can't be volunteered to use the build system that somebody else likes.


Andrei

On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d wrote: [...]
> If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome.
[...]
> P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs.

I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts.

For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications.

However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. For this, I find that SCon's architecture of fully-customizable plugins may work best: ship the system with prebaked rules for common tasks like compiling C/C++/D/Java/etc programs, packaging into tarballs / zips, etc., and expose a consistent API for users to make their own rules where applicable.

If the scripting language is D, that opens up a whole new realm of possibilities like using introspection to auto-derive build dependencies, which would be so cool it'd freeze the sun.

Now throw in things like built-in parallelization ala SCons (I'm not sure if tup does that too, I suspect it does), 100%-reproducible builds, auto-packaging, etc., and we might have a contender for Andrei's "winner" build system.


> P.S.S autotools is the worse GNU project I know of

+100! It's a system of hacks built upon patches to broken systems built upon other hacks, a veritable metropolis of cards that will entirely collapse at the slightest missing toothpick in your shell environment / directory structure / stray object files or makefiles leftover from previous builds, thanks to 'make'. It's pretty marvelous for what it does -- autoconfigure complex system-dependent parameters for every existing flavor of Unix that you've never heard of -- when it works, that is. When it doesn't, you're in for days -- no, weeks -- no, months, of hair-pulling frustration trying to figure out where in the metropolis of cards the missing toothpick went. The error messages help -- in the same way stray hair or disturbed sand helps in a crime investigation -- if you know how to interpret them. Which ordinary people don't.


T

-- 
Philosophy: how to make a career out of daydreaming.

On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d wrote:
> [...]
>> If I were to write a build system today that had to spell out all of
>> its commands, I'd go with tup or Ninja. That CMake has support for
>> Ninja is the icing on the cake for me. I wrote a Ninja build system
>> generator the other day, that thing is awesome.
> [...]
>> P.S. I've thought of writing a build system in D, for which the
>> configuration language would be D. I still might. Right now, dub is
>> serving my needs.
>
> I've been thinking of that too! I have in mind a hybrid between tup and
> SCons, integrating the best ideas of both and discarding the bad parts.
>
> For example, SCons is notoriously bad at scalability: the need to scan
> huge directory structures of large projects when all you want is to
> rebuild a tiny subdirectory, is disappointing. This part should be
> replaced by Tup-style OS file change notifications.
>
> However, Tup requires arcane shell commands to get anything done --
> that's good if you're a Bash guru, but most people are not. For this, I
> find that SCon's architecture of fully-customizable plugins may work
> best: ship the system with prebaked rules for common tasks like
> compiling C/C++/D/Java/etc programs, packaging into tarballs / zips,
> etc., and expose a consistent API for users to make their own rules
> where applicable.
>
> If the scripting language is D, that opens up a whole new realm of
> possibilities like using introspection to auto-derive build
> dependencies, which would be so cool it'd freeze the sun.
>
> Now throw in things like built-in parallelization ala SCons (I'm not
> sure if tup does that too, I suspect it does), 100%-reproducible builds,
> auto-packaging, etc., and we might have a contender for Andrei's
> "winner" build system.
>
>
>> P.S.S autotools is the worse GNU project I know of
>
> +100! It's a system of hacks built upon patches to broken systems built
> upon other hacks, a veritable metropolis of cards that will entirely
> collapse at the slightest missing toothpick in your shell environment /
> directory structure / stray object files or makefiles leftover from
> previous builds, thanks to 'make'. It's pretty marvelous for what it
> does -- autoconfigure complex system-dependent parameters for every
> existing flavor of Unix that you've never heard of -- when it works,
> that is. When it doesn't, you're in for days -- no, weeks -- no, months,
> of hair-pulling frustration trying to figure out where in the metropolis
> of cards the missing toothpick went. The error messages help -- in the
> same way stray hair or disturbed sand helps in a crime investigation --
> if you know how to interpret them. Which ordinary people don't.
>
>
> T

If you have a passion and interest in this space and would like to collaborate, I would be thrilled.  We can also split this discussion off of this thread since it is not D specific.

On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
> I've been thinking of that too! I have in mind a hybrid between tup and
> SCons, integrating the best ideas of both and discarding the bad parts.
>
> For example, SCons is notoriously bad at scalability: the need to scan
> huge directory structures of large projects when all you want is to
> rebuild a tiny subdirectory, is disappointing. This part should be
> replaced by Tup-style OS file change notifications.
>
> However, Tup requires arcane shell commands to get anything done --
> that's good if you're a Bash guru, but most people are not.

Well, what I see here is there's no really good build system there. So then how can we interpret your long plea for dropping make like a bad habit and using "a properly-done" build system with these amazing qualities? To quote:

> I wish I could inspire them as to how cool a
> properly-done build system can be. Automatic parallel building, for
> example. Fully-reproducible, incremental builds (never ever do `make
> clean` again). Automatic build + packaging in a single command.
> Incrementally *updating* packaging in a single command. Automatic
> dependency discovery. And lots more. A lot of this technology actually
> already exists. The problem is that still too many people think "make"
> whenever they hear "build system".  Make is but a poor, antiquated
> caricature of what modern build systems can do. Worse is that most
> people are resistant to replacing make because of inertia. (Not
> realizing that by not throwing out make, they're subjecting themselves
> to a lifetime of unending, unnecessary suffering.)

So should we take it that actually that system does not exist but you want to create it?


Andrei

On Wed, Sep 24, 2014 at 11:02:51PM +0000, Cliff via Digitalmars-d wrote:
> On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d
> >wrote:
> >[...]
> >>If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome.
> >[...]
> >>P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs.
> >
> >I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts.
[...]
> If you have a passion and interest in this space and would like to collaborate, I would be thrilled.  We can also split this discussion off of this thread since it is not D specific.

I'm interested. What about Atila?


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

On Wednesday, 24 September 2014 at 19:38:44 UTC, H. S. Teoh via Digitalmars-d wrote:
> Wasn't Nick Sabalausky working on an automated (or automatable)
> packaging script some time ago? Whatever happened with that?

I think that's the one that keeps breaking.

https://github.com/D-Programming-Language/installer/tree/master/create_dmd_release

On Wed, Sep 24, 2014 at 04:16:20PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
> >I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts.
> >
> >For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications.
> >
> >However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not.
> 
> Well, what I see here is there's no really good build system there. So then how can we interpret your long plea for dropping make like a bad habit and using "a properly-done" build system with these amazing qualities? To quote:
> 
> >I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think "make" whenever they hear "build system".  Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.)
> 
> So should we take it that actually that system does not exist but you want to create it?
[...]

You're misrepresenting my position. *In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Your argument reduces to declining to replace a decrepit car that breaks down every other day with a new one, just because the new car isn't a flawlessly perfect epitome of engineering yet and still needs a little maintenance every half a year.


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg

On Wednesday, 24 September 2014 at 23:20:00 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 11:02:51PM +0000, Cliff via Digitalmars-d wrote:
>> On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via
>> Digitalmars-d wrote:
>> >On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d
>> >wrote:
>> >[...]
>> >>If I were to write a build system today that had to spell out all of
>> >>its commands, I'd go with tup or Ninja. That CMake has support for
>> >>Ninja is the icing on the cake for me. I wrote a Ninja build system
>> >>generator the other day, that thing is awesome.
>> >[...]
>> >>P.S. I've thought of writing a build system in D, for which the
>> >>configuration language would be D. I still might. Right now, dub is
>> >>serving my needs.
>> >
>> >I've been thinking of that too! I have in mind a hybrid between tup
>> >and SCons, integrating the best ideas of both and discarding the bad
>> >parts.
> [...]
>> If you have a passion and interest in this space and would like to
>> collaborate, I would be thrilled.  We can also split this discussion
>> off of this thread since it is not D specific.
>
> I'm interested. What about Atila?
>
>
> T

Yes, whoever has a passionate interest in this space and (of course) an interest in D.  Probably the best thing to do is take this to another forum - I don't want to further pollute this thread.  Please g-mail to: cliff s hudson.  (I'm assuming you are a human and can figure out the appropriate dotted address from the preceding :) )

On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
> You're misrepresenting my position.*In spite of their current flaws*,
> modern build systems like SCons and Tup already far exceed make in their
> basic capabilities and reliability.

Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei

On 9/24/2014 7:56 AM, Don wrote:
> For example: We agreed *years* ago to remove the NCEG operators. Why haven't
> they been removed yet?

They do generate a warning if compiled with -w.


>> What change in particular?
> I've got a nasty feeling that you misread what he wrote. Every time we say,
> "breaking changes are good", you seem to hear "breaking changes are bad"!

It would be helpful having a list of what breaking changes you had in mind.