Am 04.06.2015 um 17:03 schrieb Nick Sabalausky:
On 06/04/2015 04:39 AM, Sönke Ludwig wrote:
Of course you could make the system completely build
tool agnostic, but then you'd basically lose interoperability between
packages, as each package might choose its own build tool.
With this PR and the upcoming follow-up to add
--format=(list|some_compiler|whatever), there is NO issue with package
interoperability (as long as a package's "import-paths" is correct):
https://github.com/D-Programming-Language/dub/pull/572
Just to get this straight: Supporting external build tools like that and
by writing the proper generator has always been the goal of DUB (being
build tool agnostic). The built-in builder is basically mainly there for
convenience (although there is no reason not to improve it to the point
where it is a worthy competitor). But you still use DUB's build
description in that case.
What I really meant (and didn't really say) was if you completely remove
all build description related fields from dub.json - then you lose
interoperability.
Note that even WITHOUT dub, packages from different buildsystems
*already* interop just fine. Even in C-land. All you ever need for
packages to work together is the appropriate "build this package"
command and the import/lib paths for the compiler/linker. Buildsystem is
a package-local issue, not a cross-package issue.
That's not what I had in mind with "interoperability". That would rather
be gluing them together manually. Of course you can always do that, but
then you lose a lot of potential for avoiding useless/redundant work. It
means you are doing the job that the tool should (could) do.
This also gets especially interesting and annoying when compiler flags
(e.g. version identifiers) don't match, or the dependencies require
advanced compiler flags. I really think C/C++ is the last thing we
should take as our role model when it comes to this topic (apart from
C's strict ABI perhaps).
