Make dub part of the standard dmd distribution

[Sönke Ludwig via Digitalmars-d]

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.