Am 04.06.2015 um 17:47 schrieb Atila Neves:
On a related note, it's also a pity that Reggae mixes incremental
build improvements (from which DUB itself could greatly profit, too -
just as a Ninja generator for DUB would be a nice feature) with a
separate, layered build description. I mean there is of course no
reason to not have alternative approaches for build descriptions
available in general, but when mixed with a public package repository,
it just leads to fragmentation.
I can add a ninja generator to dub if you want, with the default being
per-package compilation (since right now for dub it's one file or
everything at once).
That would be great! If the per-package mode has such practical
benefits, we could also simply make it the general default, for all
generators that can support it. However, I just briefly looked at your
benchmark results, the performance boost seems to be solely because of
parallel compiler invocations. We already had issues with per-module
parallel compilation and out-of-memory errors, so this optimization
seems to be only suitable for certain projects or build machines. So at
least with the current compiler memory requirements I'm not sure if this
would be a good default build mode.
But I wrote reggae because:
1. Declarative is preferable but imperative is needed. My (our?)
favourite imperative language is D, so I want to specify builds in it.
This is of course perfectly fine and reasonable (although I personally
find the D syntax to be a bit too verbose for this task, but thats
really just personal taste - oh, and JSON is awful, too ;). The problems
just start to creep in as soon as public DUB packages start to depend on
Reggae - then we'll possibly get another split in the ecosystem. I'd say
we should generally try to focus on a single standard solution, however
that looks and however the tool is split into executables or packages.
2. I want a build tool that builds on dub but doesn't require it
Fair enough.
3. I wanted it to make it easy to link with C and C++
This really also needs to be solved within DUB (i.e. without resorting
to preBuildCommands). That is going to be the next priority after
getting the 1.0.0 features ready.
As I've mentioned before, I know the kind of things I'd want to do with
the build system if I had a large and complicated enough project, and I
know I wouldn't be able to do it easily using dub alone. As I've also
mentioned before, building with dub is just fine for most people.
Getting some of those use cases on a Wiki page or something would be
great. There have been some ideas to approach the procedural aspect from
a different angle - using procedural DUB plugins that can be invoked
from within the declarative build description. This would have the
advantage that a lot of information can be gathered about a package
without executing procedural code (with the possible accompanying
security risks and performance issues or the efforts needed to mitigate
those).
I don't know if fragmentation would be an issue. The packages are still
dub packages and I for one will use dub.json/sdl to list my dependencies
even if reggae is actually generating the build.
Yeah that would definitely not be an issue. I just fear (maybe
unnecessarily) that people might start to put packages in the registry
that can *only* be built using Reggae (or some other build tool). At
least for libraries that would really be bad.
