DUB - call to arms

[H. S. Teoh]

On Fri, Apr 19, 2019 at 03:54:45PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 4/19/19 2:19 AM, Russel Winder wrote:
> > 
> > Looking at Gradle, Maven, Cargo, Go, Conan, the choice is for
> > integrated dependency management and build. Dub it would seem has
> > taken the right overall approach,
> 
> Well, it certainly seems to have taken a *popular* approach. I
> wouldn't necessarily take that as implying the "right" approach (for
> us).
[...]

Yes. I for one dumped Gradle shortly after starting my Android project,
because it just didn't let me do what I need to do, or at least not
easily.  Gradle expects your typical Java codebase with standard source
tree structure.  I needed D codegen and cross-compilation as integral
parts of my build.  The two ... let's just say, don't work very well
together.  It's the "my way or the highway" philosophy all over again.
Yes it hides away a lot of complexity, and does a lot of nice things
automatically -- when what you need to do happens to match the narrow
use case Gradle was designed to do.  But when you need to do something
*other* than the One Accepted Way, you're in for a long uphill battle --
assuming it's even possible in the first place.  To that, I say, No
Thank You, I have other tools that fit better with how I work.

(Not to mention, I have a hard time justifying to myself installing a
multi-GB program just to be able to compile a tiny bit of code. And the
bare act of invoking Gradle soaks up GBs of RAM and takes forever and 64
days just to decide what it should be doing.  Perhaps I'm just a cranky
old antiquated ape who needs to just get with the times, but I seriously
cannot swallow that this is now the Accepted Way of Doing Things.  And
with D compile times supposedly being one of its top selling points, I
seriously cannot see how such an approach will work well in the long
run.  (Though OTOH perhaps it will finally get rid of that
cringe-inspiring fast-fast-fast motto.))

In any case, with all the work being poured into betterC and C++
interop, any proposed universal D build / package system MUST take into
account interacting with C/C++ codebases, which generally do *not* use
this integrated package/build approach.  At the very least, a D build
system that has pretensions of being universal must allow easy
integration of C/C++ codebases, and that means accepting the possibility
of other build systems, and at least making an effort to work with them
nicely.

This is why I proposed a standard "API" for the package manager to
interact with arbitrary codebases with arbitrary build systems.  Rather
than imposing arbitrary restrictions on how packages ought to be built,
it should acknowledge that other build systems exist, and provide a
simple, consistent way of interacting with them that will *still* work
well with those who prefer the integrated approach.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.