On Monday, 12 June 2017 at 06:38:34 UTC, ketmar wrote:
> 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 understand your point ; I was explaining to my colleagues yesterday that "1" was a "good step in the wrong direction".

I think dependencies should come from above, they should be forced at the build system level. No more 'include' or 'imports' (Bazel took one step into this direction).
The consequence is that now you can't consider the build system of your project as a second class citizen. It's the only place where you're forced to express something  vaguely resembling to a high-level architecture.

Instead of letting module implementations happily create dependencies to any other module implementation (which is an architectural sin!) and then resorting to system-level hacks to try to re-create the DAG of this mess (and good luck with generated files).

However: "1" is still a "good" step. Compared to where we are now, it's in theory equivalent to perfectly doing regexp/gcc-MM scanning, in a langage agnostic way. It's a net win!

On Monday, 12 June 2017 at 15:57:13 UTC, Meta wrote:
> 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

Thanks!

Please, tell me that the Digital Mars implementation of Make *does* support generic rules...

On Tuesday, June 13, 2017 05:38:37 Sebastien Alaiwan via Digitalmars-d wrote:
> On Monday, 12 June 2017 at 07:00:46 UTC, Jonathan M Davis wrote:
> > 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).
>
> Are you implying that we are currently keeping compatibility with
> NMAKE (the 'make' from MS)?
>
> GNU make inclusion mechanism makes it possible and easy to share a list of modules between makefiles.
>
> Before switching to a fancy BS, we might benefit from learning to fully take advantage of the one we currently have!

As I understand it, the make that we use on Windows is one that comes with dmc and is rather primitive in comparison to other versions of make, which is why win32.mak and win64.mak suck so much in comparison to posix.mak.

Regardless, IMHO, make is a terrible build solution regardless of which version of make you're using. It's better than using shell scripts, but in this day and age, there are a plethora of solutions which are vastly superior to make in terms of usability.

- Jonathan M Davis

Sebastien Alaiwan wrote:

> On Monday, 12 June 2017 at 06:38:34 UTC, ketmar wrote:
>> 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 understand your point ; I was explaining to my colleagues yesterday that "1" was a "good step in the wrong direction".
..
> However: "1" is still a "good" step. Compared to where we are now, it's in theory equivalent to perfectly doing regexp/gcc-MM scanning, in a langage agnostic way. It's a net win!

it is still a kludge. and it has a huge chance to stay with us for a very long time -- this is what usually happens with kludges. ;-)

On Mon, 2017-06-12 at 21:27 +0200, Jacob Carlborg via Digitalmars-d wrote:
> 
[…]
> the
> makefiles, just recently [1]. And not just the makefiles, now there's
> a
> Visual Studio project that needs to kept up to date as well.
> 
> [1] https://github.com/dlang/dmd/pull/6837


There should only ever be one specification of the project and how to build it. IDE project files should be generated from that specification, never hand built.

-- 
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, 2017-06-12 at 10:39 -0700, H. S. Teoh via Digitalmars-d 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. 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.

Ninja.

However good Tup may be, I think Ninja has the mindshare as the build engine underneath CMake, Meson, etc.

I am ambivalent about SCons. It is a huge improvement over Make, great strides are being made in performance along with the Python 2 → Python 3 thing (removing all the Python < 2.7 stuff and replacing with modern Python code), but it's model is from the 2000s and as you say the 2010s have new things which are not getting in to SCons, mostly because it is a pure volunteer project with no companies putting any resources in. I am doing work on it for D builds mostly because I can't really cope with Dub as a build tool.

> [...]
> 
> 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.

Forward looking is always good, this does not exclude leaving things as is, or bringing things that got forgotten from the past, it is about thinking about what is right next year, not what we have last year.

> 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.
> 
[…]

It all comes down to two things:

1. Is anyone willing to create the new build.
2. Will the new build be accepted and used.

Given some people's tone here, and the lack of contribution from Walter and Andrei on replacing Make, the answer to 2 is NO. Thus the answer to 1 is "don't bother". Thus this thread is useless. Thus D will continue to use an outdated and increasingly difficult to use build system. Not a way of attracting new contributors. Its not the outdated so much as the difficult to use.

-- 
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 Tuesday, 13 June 2017 at 06:05:16 UTC, Sebastien Alaiwan wrote:
> On Monday, 12 June 2017 at 15:57:13 UTC, Meta wrote:
>> 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
>
> Thanks!
>
> Please, tell me that the Digital Mars implementation of Make *does* support generic rules...

I have no idea. I'm not very well versed in Make to begin with, much less Digital Mars Make.

On Sun, Jun 11 2017, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

And where do existing D build systems fit into the picture, I seem to recall this general discussion around the announcement of "button", which seems interesting, potentially awesome even:

Button announcement https://forum.dlang.org/post/uhozcvatvyztfuhivrjq@forum.dlang.org

Features
https://code.dlang.org/packages/button
- Implicit dependency detection.
- Correct incremental builds.
- Can display a graph of the build.
- Recursive. Can generate a build description as part of the build.
- Very general. Does not make any assumptions about the structure of your project.
- Detects and displays cyclic dependencies.
- Detects race conditions.

example build description provided (the build description is done in
lua)
https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua

http://jasonwhite.github.io/button/

I have not used it, but if it works as described on the box most should be pleased to get to know and to use and promote, no?... I assume it will work well with dub if necessary? Other D based build systems have been mentioned, who is able to review them?

> On Sunday, June 11, 2017 16:47:30 Ali Çehreli via Digitalmars-d wrote:
>> On 06/11/2017 12:27 PM, ketmar wrote:
>>  > p.s.: or replacing make-based build system with D-based. as we need
>>  > working D compiler to compile dmd anyway, i see no reason to not use it
>>  > more.
>>
>> I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome team are aware of all pitfalls of all build systems and offer build*some* as an awe*some* ;) and correct build system:
>>
>>    http://buildsome.github.io/buildsome/
>
> 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's certainly a pain to edit the makefiles though, and I think that we'd be far better off in the long run if we switched to something like reggae - and since reggae is written in D and uses dub, we'd be dogfooding our own stuff in the process.
>
> - Jonathan M Davis
>
>

--
ralph.amissah@gmail.com

Ralph Amissah wrote:

> On Sun, Jun 11 2017, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> And where do existing D build systems fit into the picture, I seem to
> recall this general discussion around the announcement of "button", which
> seems interesting, potentially awesome even:
>
> Button announcement
> https://forum.dlang.org/post/uhozcvatvyztfuhivrjq@forum.dlang.org

"tracing system calls". a no-no for any general solution. no sane person with even rudimentary care for privaly will give *build* *system* privileges for injecting .so libraries or trace system calls.

actually, requiring such privileges is my main objection agains any "modern automagic build system".