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.
