On Mon, 2015-02-02 at 16:50 +0000, Atila Neves via Digitalmars-d wrote: […]
> 
> I have ideas that go beyond this, but this is useful input. I wonder how to proceed now about gathering actual requirements from D devs and seeing which ones are important.

Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build system using Scala programs as input.

Some Scala folk got religious about Scala being the only right language for Scala builds, and created what has become SBT. Because of the way statically typed Scala works as a domain specific languages there are performance and expression issues that means SBT is getting a reputation in the very companies that should be supporting it that it is "the enemy".

A D build system must trivially support C, C++(, and Fortran?).

Transitive dependency management needs careful consideration. I haven't investigated whether Dub does this right, it may well do. Maven does not, Gradle does.

Define package, artefact, dependency carefully. Go has a strong model (even if it is wrong). Ceylon improves on Java/Scal/etc. Python got it woefully wrong: eggs were a mess, and PyPI is not curated well enough (the vast majority of stuff on PyPI is unusable rubbish).

Worry about platform specific packagers: MacPorts, Homebrew, Debian, Fedora, FreeBSD, OpenBSD, etc. will (hopefully) want to package. Java is generally a disaster for them, and Python isn't that much better. Go is ignoring al this and creating a monoculture based on Git and Mercurial as packages are shipped as source. I see Debian and Fedora trying to package Go things and predict the same mess as Java and Python.

Support principally a declarative DSL, but with imperative structure possible. A build specification is a meta-program which when executed creates the program and hence the build process.

Have no clearly silly constraints, cf. the needs for SBT specification lines always to be separated by blank lines.

Be convention over configuration, but allow configuration.

Use BinTray and Artifactory as well as the current Dub repository.

Do not be afraid to change the meta-data specification so that. Dub may well be a good start, but it may need work. Gradle has changed it's meta-data specifications many times despite being constrained by compatibility with Maven POMs and Ivy specification.

Stand on the shoulders of giants, but do not assume they are always right, be prepared to change stuff for the better.

Get alpha testers in early and let them drive things – albeit within the
boundaries of your vision for the system. Dub did well here if I
remember correctly and created a group of people who did and emailed
rather than just emailing.

I better finish my essay at this point I have a London D User Group meeting to go to :-)

http://www.meetup.com/London-D-Programmers/


-- 
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, 2015-02-02 at 20:05 +0000, Dragos Carp via Digitalmars-d wrote: […]
> Why not building on cmake? You have experience with it.

I would argue because the CMake build description language really, really suck.

Yes, you can describe builds using it, but only once you have entered a state of Stockholm Syndrome.

> trentforkert made very good progress with D support in cmake and has good chances to merge it upstream [1].

OK, positive progress is good progress. Making a bad system better is better than leaving it bad.

> If we look at the Vision/2015H1 goals, we see a couple of points, where cmake already has the necessary support:
> 
> - C++ integration (hybrid projects)
> - alternative compilers
> - embedded systems
> 
> This features would take a lot of effort/time to be implemented in a pure D solution, nevertheless any of these points is a niche in the D community.
> 
> Apart from the ugly script language, cmake would be a pretty good fit.

As would SCons.

(You just knew I was going to say that didn't you :-)

> 
> [1] - https://github.com/trentforkert/cmake

-- 
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 Tue, 2015-02-03 at 13:19 +0000, Tofu Ninja via Digitalmars-d wrote: […]
> Why not invest your time into improving dub and adding these features, we don't need another tool. Improving dub would have a much bigger impact than making another tool that is almost certainly never going to get used because very few tools ever get to that level.

Because they feel that Dub is fundamentally flawed as the future
solution to D (C++/C) build?
> 
> Honestly it seems like a huge waist of time and very counter productive.

I disagree. This sort of argument was made before Dub and yet Dub happened.

If people want to improve on Dub and replace it by doing exactly that, that seems like the best way forward.

I have just realized why I think Dub will not be the future of D build…

-- 
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 02/02/2015 10:44 AM, Andrej Mitrovic wrote:
> What's worse, I have to wait 15-20 minutes for the latest tagged version
> of a dependency to finally show up on code.dlang.org.

Filed as https://github.com/D-Programming-Language/dub-registry/issues/92.
Please comment if you have any other ideas to improve this.

On 02/03/2015 09:51 AM, ketmar wrote:
> 'cause it really sux as a build tool.

Not getting into any of the lengthy discussions of yours, but 'it sux' isn't really helping anyone to improve it.

On 02/02/2015 12:00 PM, Manu via Digitalmars-d wrote:
> If my D project depends on a C lib, then what am I supposed to do to
> make dub useful for me?

This is a simple problem to solve.
All package tools support a way to build "native" extensions, mostly by scripting the builds.
You can already add preBuildCommands and use whatever you like, e.g. a D script to build your C library.
It wouldn't be too hard to compile just a few C files, but if you already need this, chances are you need more flexibility anyhow.

On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:

> On 02/03/2015 09:51 AM, ketmar wrote:
>> 'cause it really sux as a build tool.
> 
> Not getting into any of the lengthy discussions of yours, but 'it sux' isn't really helping anyone to improve it.

repeating the reasons why it sux doesn't help too. this thread alone has some of them, including inability to do separate compilation (and the reason why this can be needed). choosing to answer to my "sux" message instead of that will surely help alot.

On Tuesday, 3 February 2015 at 17:34:05 UTC, Russel Winder wrote:
> The issue is though that Dub was created because someone did something
> rather than just talking (and emailing) about it. As Hans and colleagues
> took knowledge and experience and created Gradle, somebody, or group of
> people, need to take the practical experience of Make, CMake, Jam,
> SCons, Waf, Ant, Gant, Maven, Gradle and Dub, and do something.
>
> I will also say that Bintray and Artifactory may be better
> artefact/dependency stores that trying to build something D-specific
> from scratch.

Don't forget tup!!! [1]

[1] http://gittup.org/tup/

On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi wrote:
> [1] http://gittup.org/tup/

I don't know who wrote that site but they are quite hilarious :)

"Unfortunately, tup is so fast that your chair mounted jousting might suffer. I apologize in advance if someone besmirches your honor and you are unable to properly defend yourself as a result."

"In tup, the arrows go up. This is obviously true because it rhymes. "

On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi wrote:
> Don't forget tup!!! [1]
>
> [1] http://gittup.org/tup/

This is first time I hear about tup but I must admit it looks really cool. It has all the good thing I love about make but with more thinking being put into it and no awkward legacy.

And it is honest natively compiled program with no extra annoying dependencies.

It would tempting to include something like that in Phobos as a library - sadly, it is licenced under GPL and thus this option is not available :(