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.
