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.
From mine and Andrei's results it seems to be a much better
default.
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.
I'm working on the syntax ;)
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.
I'd have to go back to my old work project and read all the CMake
code...
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.
I think that if a project is a dub package, then it needs to be
able to be built with dub. If anything on code.dlang.org doesn't
(correctly) build with `dub build` then that would be incredibly
wrong.
Also, I'm not as sure as you that reggae will catch on that much
:)
Atila
