On 06/10/2015 08:11 AM, Sönke Ludwig wrote:
Am 04.06.2015 um 17:47 schrieb Atila Neves:
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've found the opposite to be true.
We can *already* get packages in code.dlang.org that work with a custom
buildscript, but then fail when doing "dub build". I know this because
I've *already* done it by accident multiple times. And then I get bug
reports of "X or Y build problem under dub".
But if we can easily tell dub via dub.json, "Hey, don't use your
internal build system to build this, I've stuck the appropriate command
in pre/postBuildCommands", then "dub build" will automatically just
simply work. Major bonus compatibility points the more information we
can pass from dub to the custom command (ex: "Which 'built type' did the
user request with '--build='?" or...well, everything provided by dub
describe --data).
Remember, libraries do NOT need to use the same build system to be used
together. As long as there's a common interface to...
1. Trigger a build, and
2. Get the lists of import paths and output binaries (and maybe any
other required flags),
...then everything's golden. This is the job of a package manager. Each
library author tells the package manager:
1. "When someone asks you to build me, here's how you do it" and
2. "When someone asks you for my import paths and output binaries
(etc.), this is what you tell them...".
For DUB, #1 above can be done via pre/postBuildCommands as long as we
can tell it "Don't go trying to build this yourself". (I'm wondering if
"targetType": "none" would help here.) And for #2, DUB can do that via
my --data= pull request.
Ok, only one possible issue left: Source libraries (as opposed to binary
libraries) *could* be an issue just because of the differences in
collecting the list of files to be compiled. But that's solvable two ways:
1. If your lib *requires* something like RDMD-style dependency
collecting, then the lib must be a binary lib.
Or much, much better yet: 2. Option in dub.json to say "when you collect
this package's list of source files, do it RDMD-style". Sure, that may
not be appropriate for ALL packages, but that's exactly why it'd be a
per-package OPTION.
And there it is, the *existing* issues of splitting the dub ecosystem
are thus eliminated, without creating new splits.
