On 02/11/2018 09:01 PM, Jonathan M Davis wrote:
On Sunday, February 11, 2018 20:30:19 Nick Sabalausky via Digitalmars-d
wrote:
The langauge-based package managers just simply need to keep
"buildsystem" OUT of the package manager's scope. That's all. THAT is
why system-level packages can be built with whatever tool: because the
one thing the system package managers actually do get right is NOT
rolling their own mandatory buildsystem.
I'm not sure that it's entirely a bad thing that dub includes a build system
in it, since it's the ease of use of its build system that is part of why
it's so worth using. It's just that its simplicity is also part of why it
doesn't work well once you get out of the basic situation of "here's a group
of D files that need to be compiled together as a library or application."
You're right, of course. I guess I wasn't clear about this, and frankly
I even lost sight of it, but if it HAD been easy and clear to just say
"hey, dub, I'm bringing along my own buildsystem and opting out of
yours, ok? thanks dude" and that was that, no muss, no fuss, no
"tricking" dub into doing what I need, I would've been fine with that.
The problem is that, in my experience, dub's assumptions about it doing
your build for you tend to be so deeply ingrained into the way it and
its configuration format all work, that I just don't see attempts to
separate them out as likely work out all that well. If even at all.
Heck, at this point I feel like most of my attempts to get dub to do
anything I have in mind have wound up being less "what is the directive
to do that?" and more "How to I nudge, persuade, or outright trick dub
into doing what I need?" Even if I just have a compiler switch I want to
use, or not use, I can't *just use it*. Best case scenario, dub will
brand my library with a big ugly warning when anyone uses it. More
likely, I have to go translate it into dub-speak (if I'm LUCKY), or, all
too frequently, I find myself flailing around, trying to find just the
right combination of settings to *coax* dub's behavior.
This is a completely *typical* dub experience for me, and frankly, one
of the more *pleasant* ones:
https://github.com/atilaneves/unit-threaded/issues/106
Did you know dub behaves *differently* if your test configuration is
named "unittest" verses when it has a different name? I didn't.
Principle of most surprise, I guess.
THIS is me using dub. Flawless illustration:
https://www.youtube.com/watch?v=QvcFRgJwE2k&t=0m12s
The problem with that approach though (and part of why I think dub doesn't
do that) is that if dub really is set up with the idea that you use whatever
build system you want, then you have the issue of whether the system doing
the build has all of the necessary software to do the build. Dub doesn't
completely avoid that as-is, since you can depend on certain libraries being
on the system,
> [...]But if dub itself were designed with the idea that you could
> use cmake, scons, make, or whatever build system anyone felt like putting
> together, then there's a fairly high chance when you go to pull in a
package
> from dub that it's going to require stuff to build that you don't have on
> your system, and since you frequently end up pulling in packages
recursively
That's why the way it *should* work is: If your build has a dependency
(another .d lib, a C lib, cmake, rake, scons, whatever), you make a dub
package for it if there isn't already one. Problem solved.
But once again, dub's assumption that *everything* is a set of *.d files
for it to complile gets in the way here too.
So, dub's solution of targeting a single build system side steps that issue
to a great extent - not entirely, but enough that it doesn't tend to be a
problem. And on some level, that's a good thing,
No, all it does it create problems and prevent workarouds, as described
above. If a package needs, ex, scons, to build, it should be simple to
create a dummy dub package for scons that (best case) offers to install
scons for you, maybe even a local non-system-wide installation, or at
the very least, tells the user, "hey, scons not detected, it's a
dependncy of this package, so you need to install it."
After all, managing dependencies are what package managers are all
about, and dub isn't handling it very well when it comes to tool
dependencies (as opposed to "a library of .d files to be linked in"
dependencies, which is really all it's designed for).
So, I don't know what the right solution is.
The right solution is to give up on dub, as it's too far down the wrong
design road, and have a package manager that's designed from the ground
up to be a package manager (not a simplified buildsystem that happens to
also include dependency-handling features). As a package manager,
*anything* the package needs, a D library, a C library, an external
tool, even a compiler version and the package manager itself...is just
another dependency for the package manager to handle.
I should point out, strong as I may feel about all this, I don't mean to
be too much of a dick about dub. I'm well aware how much effort went
into dub, and I *do* respect that. Frankly, I've always been absolutely
*stunned* by just how much Sonke accomplishes. Beyond me how he manages
to do all that: I know I certainly couldn't. It seems superhuman! And I
am grateful there's been at least SOMETHING for D package management.
It's just, from a technical perspective looking toward the
near/mid-future, I just have a hard time seeing dub getting to where we
really need a D package manager to be, and I admit I've gotten to the
point of real frustration.
