Make dub part of the standard dmd distribution
Sönke Ludwig via Digitalmars-d
digitalmars-d at puremagic.com
Thu Jun 4 01:39:00 PDT 2015
Am 01.06.2015 um 16:49 schrieb Jonathan M Davis:
> On Monday, 1 June 2015 at 06:20:18 UTC, Nick Sabalausky wrote:
>> Ditto. Dub's great if you let it be your buildsystem, but as soon as
>> you want to use it as a package-manager-only it becomes an uphill
>> battle with dub fighting back every step of the way (I speak from
>> experience). That problem is worse if your project is a library that
>> you want fetchable through dub.
>
> And this is when Jacob Carlborg chimes in and says "I told you so." ;)
> His favorite complaint about dub has always been that it combined
> package management and the build tool into one.
This is actually completely irrelevant to the issue. Making the build
part separate would not at all solve this. Any work on such a separate
build tool (e.g. to support other languages) could instead as well go
into DUB itself. 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.
>
> dub works fantastically if you want to do everything in the standard way
> without any funny stuff, but it clearly doesn't have the power of a tool
> like make, cmake, etc. As soon as you need to do anything funny - like
> include anything related to other languages in your build, or put things
> in a specific layout because of some company-specific thing, or anything
> that wasn't explicitly planned for by the folks writing dub, dub just
> won't work.
This is really not true. There is currently just one limitation w.r.t.
the directory structure and that is the naming scheme of the folder to
which packages are downloaded ("somepackage-1.0.0"). There are some
packages that put their sources into the root of the repository and
expect to be put into a folder with the name of the repository, which
will then be added as an import folder. We are going to solve that.
Everything else can be done with the sourcePaths, sourceFiles,
importPaths, ... settings. You basically have the same possibilities as
you have when directly invoking the compiler.
Separate language support is still missing, but you always have the
possibility to add generic "preBuildCommands" or "preGenerateCommands"
to invoke separate tools or scripts. Of course it's desirable to get
everything done with the same tool instead of relying on additional
build time dependencies, but it's still *possible* to do these things.
>
> Now, to be fair, I don't know how you can be pulling in all kinds of
> stray libraries with who-knows-what for their build systems and expect
> it to work very well via a single tool (at minimum, you have the problem
> that the machine that you're trying to build them on will likely be
> missing some of those tools), but that's pretty much what we need to
> handle the general case. Without that, dub will work great for the
> normal case (which _will_ be plenty for many, many projects), but it
> won't work in the general case - and corporate folks in particular are
> probably going to have to skip out on using it because of abnormal
> requirements on their part.
>
> 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 guess using the proper targetType and preBuildCommand settings it
should already be possible to invoke a separate build tool and still
integrate the generated object/library files into the rest of the DUB
build process. But I'd have to try that out - it would definitely be
good to have something like this added to the cookbook [1].
Of course things like these always potentially degrade interoperability.
DUB's build description was chosen explicitly to avoid unnecessary
dependencies on a particular compiler/platform, which is where the most
general build tools (especially "make") utterly fail.
>
> 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.
I don't see anything that wouldn't be fixable. In fact, there are really
few things that are not possible now, even if not in the most
comfortable way.
More information about the Digitalmars-d
mailing list