Git, the D package manager

[Atila Neves via Digitalmars-d]

+1 to all of this. Except for the part about CMake relying on 
Make. It doesn't, Make is just one of the backends. I haven't 
used CMake with anything other than Ninja in a very long time.

Atila

On Friday, 6 February 2015 at 11:04:59 UTC, Russel Winder wrote:
> On Thu, 2015-02-05 at 18:01 +0100, Sönke Ludwig via 
> Digitalmars-d wrote:
>> 
> […]
>>  I'm now just left wondering what it is that is "fundamentally 
>> flawed". Everything mentioned so far is either
>> bugs or missing functionality, or rather just mostly missing 
>> convenience.
>
> The core problem is the use of a JSON file to express the 
> definition
> of the project. This sort of specification is fine for 
> dependency but
> not sufficient for build.
>
> Make is a fine external DSL for dependencies, but everything 
> else
> relies on the action language, generally Bash. GNU Make adds 
> macros
> and a whole slew of things to try and make things better, all 
> of them
> adding more imperative aspects.
>
> Autotools is a wonderful M4 edifice, but not a solution to the
> problems of project management Make despite many years of people
> actually succeeding in doing it.
>
> CMake has a DSL for describing build, not so good on the project
> description side, but in the end the language is ugly, 
> underpowered
> and reliant on Make.
>
> SCons is not perfect, but it beats Make and CMake by creating an
> internal DSL on Python. Waf takes aspects of this further and 
> makes
> Autotools look a bit ill. There is a natural balance
>
> Go delegates to a DVCS all dependency issues, everything 
> build-wise is
> totally by convention. It works but the hassle people are 
> finding with
> repeatable builds leads to conventions as per gopkg.in.
>
> Ant, hummm… started out as a platform independent version on 
> Make,
> used XML for build specification and claimed to be declarative.
> Looking at Ant scripts these days, the hoops people go through 
> to
> construct imperative programs in XML are amazing. The only 
> alternative
> is to write a new task, which lots of people have to do.
>
> Maven tried to go the project specification, and partly 
> succeeded.
> Artefact repository approach a huge win. Specification in XML, 
> yuk.
> Attempt at totally convention based build only partly worked. 
> Lots of
> people have to write plugins to get the process they need for 
> their
> goals.
>
> Gradle fixed the transitive dependency tracking problems of 
> Maven and
> has Groovy specifications. Yes there is a lot of purely 
> declarative
> convention-based stuff, quite right too, but the ability to 
> trivially
> add the extra bit of imperative in the build specification, 
> stops the
> mess of Maven, Ant, CMake, Make.
>
> SBT tries to use Scala as a project and build specification 
> language.
> For simple projects, a few declarative lines are all that is 
> needed.
> However for anything complicated you end up going outside the
> convention-only, but like Gradle and unlike Maven you can do 
> this.
> SBTs major problem is Scala compile time for non-trivial project
> specification. Hence the need for a build daemon, a route 
> Gradle has
> had to go as well due to infrastructure start-up time.
>
> I could turn this into a better essay, but the above gives the 
> main
> threads of the argument: project specification can be 
> declarative,
> build specification is best as declarative as possible, 
> convention-
> based, but not totally declarative.
>
> (I now I should mention tup here but I still haven't used it 
> enough to
> know anything real about it.)
>
>> Things may not (yet) be ideal, but fundamentally DUB is 
>> nothing more than a tool built on a defined abstract package 
>> description format (vs. a procedural build description). If 
>> you (or anyone else for that matter)
>> want to say that using a descriptive format is fundamentally 
>> flawed then
>> I'd be grateful for some additional substantiation. Otherwise 
>> there is nothing "fundamental" in the system that I know of.
>
> The fundamental problem here is that project specification and 
> build
> specification is not either declarative or imperative.  From 
> 1977
> onwards we have a trail of evidence that shows it is part 
> declarative
> (as much as possible), but part imperative (as little as 
> possible, but
> necessary for non-trivial projects).
>
> Sticking with JSON as the only specification notation for Dub 
> will
> inevitably lead people to have to hack or find another tool. The
> solution would be to either:
>
> – Treat the JSON specification for dependency management only 
> and use
> something else for build description so as not to be 
> constrained by
> the only convention.
>
> – switch to an internal DSL so as to have mostly declarative but
> imperative as needed description of project, dependency and 
> build
> process.