On 06/01/2015 10:49 AM, Jonathan M Davis wrote:
Even simply splitting dub out so that it can pull in packages without
necessarily being able to build them would be nice (maybe adding a flag
to the dub.json file indicating whether dub can be used as a build tool
for the project or whether it's supposed to just act as a package
manager for it), though that does add the problem of code.dlang.org
becoming more confusing, since you wouldn't be able to rely on all
projects on it being built for you by dub as part of the process of
grabbing packages.
I've brought up something like that, but it was met with very strong
opposition. :(
It's a complicate problem, and dub went a route which works in the 90%
case, but doesn't work for more complicated cases, which will make dub
unusable for some projects - especially corporate ones. I don't know how
fixable it is without a major redesign of dub.
Personally, I think "90%" is generous here, but I admit that's splitting
hairs.
Unfortunately, "less than 100%" is a big problem in this case because
those libs/projects that don't fit the "90%" effectively cannot even
participate in the dub repository for others to use (at the very LEAST,
they get pounded with "fails to build via dub"). So NOT using dub to
build is freaking viral.
And *using* certain dub-based projects inside one which doesn't build
via dub can be a major pain, as anyone who's tried to use vibe.d from a
non-dub-based project should be able to attest (just *try* to figure out
all the -I... and linker flags you need *and* double-check/maintain them
every time you upgrade vibe.d).
So anything less than 100% effectively splits the whole damn ecosystem.
NOT acceptable.
Dub's project generation feature is NOT a solution here, because you
still have to manage builds dub's way, *exactly* as if you were using
dub's build system, because...really...you still ARE. So all the
dealbreakers for those 10+% projects still apply equally.
On the plus side though, I *do* think this is basically solvable. The
most immediate way (and what I'm working towards) is to create a
dub.json that feeds dub a 'dummy-src/dummy.d' to keep dub's build system
happy and safely away from the real source files, and then use:
"(pre|post)-build-command-posix": "./my-real-buildscript"
"(pre|post)-build-command-win": "my-real-buildscript"
To trick dub into using a different build tool.
It'd be easily to design/publish a skeleton dub.json to do exactly that.
(Kinda sucks to NEED that, but at least it'll work, and once it's in
place them maybe it can be made easier. The non-buildsytem parts of
dub.json really ARE very trivial, and if someone had a problem with even
that trivial little bit, then I don't see how they could develop any
useful software in the first place.)
I'm fairly certain the ONLY real thing still preventing all that above
from actually working is that dub currently provides no (practical) way
to retrieve the necessary compiler/linker args in order to actually use
your dependencies (again, try using vibe.d in, say, an rdmd-based
project). I say no "practical" way here because "dub describe -> parse
the JSON -> extract the needed info -> convert the needed info to
compiler flags" is NOT exactly practical or reasonable to expect people
to do *just* to use RDMD or otherwise opt-out of dub's build-system.)
Again though, I'm working on that:
https://github.com/D-Programming-Language/dub/pull/572
That lets you directly grab any build info you need from dub. My next PR
will then let you ask dub to automatically format the output for your
compiler's CLI. And then one last one to provide convenience switches
for the most likely configurations (like
"--just-gimme-whatever-flags-I-need-to-pass-to-rdmd-so-I-can-actually-use-my-dependencies",
but obviously less verbose :))
With all that, any project should be able to participate in the dub
ecosystem AND opt-out of dub's build system WITHOUT segregating the
ecosystem in any way.
