On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole wrote:
On 11/02/2018 11:40 AM, Jonathan M Davis wrote:
On Sunday, February 11, 2018 11:26:30 rikki cattermole via Digitalmars-d
wrote:
On 11/02/2018 11:18 AM, Russel Winder wrote:
Clearly though there is a problem with Dub as a build system for many
of it's users – or rather people who try and reject.


Put simply, they expect far too much.
Dub's scope is limited, lets not forget that.

The problem with that is that if dub is the way to build D projects in general, then it needs to be able to do pretty much whatever you need to do for pretty much any project - even if that involves backdoors. You need to
be able to do arbitrary stuff with your builds.

It's not as critical for applications so long as dub provides an easy way to link in any libraries that it pulls in, but dub needs to be able to build libraries no matter what crazy stuff you need to do, otherwise, those libraries can't interact with the dub ecosystem, and dub is how D projects
in general pull in their dependencies.

So, for instance, if your D library has to build C or C++ code and link that in as part of what it does, that needs to be possible with dub, even if dub itself doesn't handling building code that isn't D. Also, if you need to generate code as part of your build and then build those files, that needs to be possible. And the way that dub is set up at this point, that sort of
stuff is rather difficult to do.

dub wouldn't have to be all that powerful if it were simply a handy build tool for the average use case, but when it's tied in to package management for D libraries and is the primary way that D projects pull in libraries, it needs to be far more than a simple build tool. And right now, it's not far
enough away from being a simple build tool.

- Jonathan M Davis

Dub can do everything that you have described.
You are fully free to run cmake if you wish before the build.
I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub, then a lot is possible. Those edge cases can be ironed out.

Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage.

At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains.


Will it result in binaries that are decent? Probably not for most use cases.
Can you file a bug report on this?


Its a hard problem to solve, I just wish people respected dub's scope more. Because it is very decently well scoped for its job already.
Same opinion here.


Reply via email to