Sebastien Alaiwan wrote:

> The selling points, to me, are:
> 1) the automatic dependency detection through filesystem hooks
> 2) recipes also are dependencies
> 3) the genericity/low-level. I believe build systems should let me define my own abstractions, instead of trying to define for me what an "executable" or a "static library" should be.

i'm not that all excited by "1", though. tbh, i prefer simplier things, like regexp scanning. while regexp scanners may find more dependencies than there really are, they doesn't require any dirty tricks to work.

i have my own fork of Perforce Jam, and such scanners works surprisingly well with it (for years). i even extended it to support D.

one of the great things in Jam is that it can simply call a "rule" (this is jam's name for something like function) when it need to get dependencies. and i can do regexp scan there, or run arbitrary system command and get it's result. also, while my jam comes with a set of predefined rules, there is nothing hardcoded, and everything can be redefined. it is also highly extensible via special "hook rules", which are empty by default.

the simpliest Jamrule can be as simple as this:

	Main myapp : [ Glob src/*.c ] ;

it also correctly processes subdirs (not via recursive invocations), can replace "configure" to some extend, and so on. i was using it exclusively for years before i completely switched to D (and even after the switch, to build projects with GDC).

Sebastien Alaiwan wrote:

> On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:
>> Jonathan M Davis wrote:
>>
>>> It's certainly a pain to edit the makefiles though
>>
>> and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice...
>
> I don't get it, could you please show an example?

ah, lol, those lists were killed some time ago, and i failed to notice it. silly me. sorry. but they *were* a PITA back then, and memory remains. ;-)

Sebastien Alaiwan wrote:

> On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:
>> Jonathan M Davis wrote:
>>
>>> It's certainly a pain to edit the makefiles though
>>
>> and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice...
>
> I don't get it, could you please show an example?

ah, nope, not killed. it's just me being blind. look at druntime/mak directory, for example. those lists are *required*, and they are maintained MANUALLY.

On Monday, June 12, 2017 06:34:31 Sebastien Alaiwan via Digitalmars-d wrote:
> On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:
> > Jonathan M Davis wrote:
> >> It's certainly a pain to edit the makefiles though
> >
> > and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice...
>
> I don't get it, could you please show an example?

posix.mak is a lot better than it used to be, but with win{32,64}.mak, you have to list the modules all over the place. So, adding or removing a module becomes a royal pain, and it's very easy to screw up. Ideally, we'd just list the modules once in one file that was then used across all of the platforms rather than having to edit several files every time we add or remove anything. And the fact that we're using make for all of this makes that difficult if not impossible (especially with the very limited make that we're using on Windows). IMHO, switching to something like reggae would be an enormous improvement.

It's true that we don't have to constantly edit the makefiles, so it's not a constant pain point, but it does come up every time we add or remove any modules, and the pain in dealing with the makefiles and the time wasted with them adds up over time.

- Jonathan M Davis

On 2017-06-11 21:17, Andrei Alexandrescu wrote:
> Phobos' posix.mak offers the ability to only run unittests for one module:
>
> make std/range/primitives.test BUILD=debug -j8
>
> ... or package:
>
> make std/range.test BUILD=debug -j8
>
> It runs module tests in parallel and everything. This is definitely
> awesome. But say I misspell things by using a dot instead of the slash:
>
> make std.range.test BUILD=debug -j8
>
> Instead of an error, I get a no-op result that looks like success. How
> can that situation be converted to an error?

Wouldn't it be more natural if the following syntax was used:

make test std/range/primitives.d

That is, "make test" then the path to a file or directory.

But I rather see the make build system completely replaced with something else.

-- 
/Jacob Carlborg

On Monday, 12 June 2017 at 00:19:18 UTC, Jonathan M Davis wrote:
> On Sunday, June 11, 2017 16:47:30 Ali Çehreli via Digitalmars-d wrote:
>>    [...]
>
> Atila did some work to get dmd, druntime, phobos, etc. building with reggae/dub, and I _think_ that he had it all working. As I understand it, the main barrier to switching to it officially was political. A number of us would _love_ to see the makefiles killed off, and there's really no technical barrier to doing so. It's really a question of convincing folks like Walter, Andrei, and Martin, and I get the impression that to an extent, there's an attitude of not wanting to mess with what's working (though I dispute that it works all that well from a maintenance perspective).

It was only phobos, but other than that, correct.

Atila

On Monday, 12 June 2017 at 06:34:31 UTC, Sebastien Alaiwan wrote:
> On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:
>> Jonathan M Davis wrote:
>>
>>> It's certainly a pain to edit the makefiles though
>>
>> and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice...
>
> I don't get it, could you please show an example?

https://github.com/dlang/phobos/pull/3843

On Mon, 2017-06-12 at 13:18 +0200, Jacob Carlborg via Digitalmars-d wrote:
> […]
> 
> But I rather see the make build system completely replaced with something else.

Make was a revelation and revolution in 1977.

Make is the assembly language of build.

There are much better abstractions of build these days.

CMake/Make
CMake/Ninja
Meson/Ninja
SCons

to name some obvious high profile examples. And then there are:

Gradle
Bazel
Cargo
Go
Dub

to name some alternate models of build.

That Chapel and D chose Make as their build system is rather annoying, so backward looking, for supposedly forward looking systems. Oh well.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, Jun 12, 2017 at 06:09:52PM +0100, Russel Winder via Digitalmars-d wrote:
> On Mon, 2017-06-12 at 13:18 +0200, Jacob Carlborg via Digitalmars-d wrote:
> > […]
> > 
> > But I rather see the make build system completely replaced with something else.

+1.


> Make was a revelation and revolution in 1977.
> 
> Make is the assembly language of build.
> 
> There are much better abstractions of build these days.
> 
> CMake/Make
> CMake/Ninja
> Meson/Ninja
> SCons

Don't forget tup, and others inspired by it, which use modern OS features to reduce the cost of determining what to build to an O(1) database lookup rather than an O(n) whole-source tree scan. I.e., much faster code-compile-test cycle.  Much as I have come to love SCons, I think ultimately the build system of the future will be something derived from the tup model.


[...]
> That Chapel and D chose Make as their build system is rather annoying, so backward looking, for supposedly forward looking systems. Oh well.
[...]

I don't agree with the notion that everything must be "forward looking" in order to be "good".  If something existing works well and does what we need it to do, there's no reason to keep reinventing the wheel.

However, I do agree that where there is room for improvement, improvements ought to be made. On this front, make leaves a lot to be desired.  It requires far too much babysitting, manual work, and dependence on human infallibility (which we all know works all too well). Not to mention that it fails the basic tenet of a reliable build system: reproducible builds, i.e., given *any* arbitrary workspace state, running the build command ought to produce products (executables, etc.) that are *guaranteed* to reflect the current state of the source code.

Just working with a dmd PR these past few days brought me right back to the bad ole days of always running `make clean` before `make`, just to be sure that the executables accurately reflect the source. I had shed such redundant steps long ago when I adopted SCons as my go-to build system, but it didn't take long working with the dmd sources to discover that sometimes make doesn't produce the correct executable, but picks up detritus from the environment (stale object files from previous builds, temporary files that the bash script snippets expect to be absent or don't expect to be still lingering, etc.).

(It's not as bad in druntime/Phobos where all the makefile does is basically to pass all the source files to a single invocation of dmd. More or less. But if you have to work with documentation or running the test suite, the flaws of make surface all over again pretty soon. Updating the interminable lists of files in posix.mak, for example, is quite reminiscient of working with a C source tree that's heavily dependent on leaky macros. Quite the nostalgia trip, I have to say.)

One can always argue that make is time-tested and everybody knows it, therefore it can't be all that bad.  Well, programming in C is also time-tested, a large number of veteran programmers know it, so it can't be all that bad, can it?  I mean, all you have to do is to make sure your arrays are never overrun, avoid poorly-designed standard library features that lead to security holes, make sure you manage your own memory well to avoid leaks and double-frees, make sure your pointers are always valid, make sure you don't write leaky macros, memorize the operator precedence table, learn the intricacies of 100 different gotchas that can come back and bite you in the behind, and ... There's really no need to program in another language, like D, right? :-P

Another common objection is, there's no clear "winner" among the make alternatives to have an obvious choice to pick, so we better just stick with make for now. Well, arguably, from a certain perspective, there's no obvious "winner" among successors to C/C++ either... there's D, Go, Rust, Java, etc.. So let's just stick with C, the lowest common denominator, until a clear winner emerges.


T

-- 
Жил-был король когда-то, при нём блоха жила.

H. S. Teoh wrote:

> Don't forget tup, and others inspired by it, which use modern OS
> features to reduce the cost of determining what to build to an O(1)
> database lookup rather than an O(n) whole-source tree scan.

added complexity for nothing. disks gradually replacing with ssd, amount of RAM allows to cache alot, and CPUs are faster and faster (and has more cores).

i still have HDD, 8GB of RAM, and 32-bit system. and it even worse some time ago. in the last ~8 years i was using my k8jam for various projects: several kb to multimegabytes of code and thousand files/alot of subdirs. source tree scanning and dependency resolving NEVER was any significant factor.

and i really mean it: it was less than a second even for a huge projects, where linking alone took long enough that i could get coffee and cigarette. ;-)

worse is better. i hate to admit it, but most tricks we're learned over the years becomes more and more useless. it doesn't matter if the program will do it's work in 0.001 msecs or in 0.0001 msecs: this is not even a difference between 10 minutes and 5 minutes anymore.