On 1/06/2015 5:57 p.m., Manu via Digitalmars-d wrote:
On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
As for dub, I'd use it if it worked like a package manager; dub get
libcurl-d libqt-d zlib-d libsdl2-d etc
I have no use for it as a build system, and therefore it's expression
of dependencies is no use to me. I just want something that works the
same way as '-dev' packages already work perfectly well in linux, that
is, they fetch headers and libs, and put them in a standard location
that all the tooling can find.
I thought it does that.
If dub doesn't allow me to type one command to download and install all I
need about a package, we need to add that pronto. I consider it a
dealbreaker.
Andrei
dub fetch does this already (though probably not quite what you are thinking
of). You'd need to specify the paths manually because if it installed them
to the global compiler paths we'd have dependency hell (what if 5 projects I
have need 3 different versions of a library?). Also, you'd need root
permissions.
Yeah, but regardless, that's what I want.
I don't have version hell with C libs distributed this way...? Is this
a problem that people are specifically trying to avoid?
That's not really how you use dub though. dub simply isn't a good fit for
people who want it to be a system package manager. Its goals are different.
If people want that they should work on getting libraries added to their
preferred system's package registries.
Right, so, someone decide a path, we'll write it on dlang.org, and
then everyone will agree and fall in line :)
With dub you specify the dependencies in the dub config file, not in some
obscure section of an INSTALL file as a command the users need to run. You
can checkout a project using dub and with a single command have dub download
and build all the dependencies (and their dependencies) and then build your
project against them.
I get it, it sounds great... if your app suits the model.
I have no D-only projects, all my programs combine many languages and
ecosystems.
There are also existing build systems that are well established that I
prefer to use, integrate with IDE's, etc.
I don't mind if people use dub, but I just want a way to fetch libs
that the compilers will then find automatically.
dub is about making it easy for 99% of users. If you need your own build
system then using dub just to download packages is overkill. Use git
submodules or add something to do a download of your dependencies from
github as part of your custom build system.
Point is, I don't have to do this with C. I just install the dev
package, once, and I'm done. Package manager distributes updates
automatically, everything it exactly how I want it.
It's just not a wheel I have any interest in reinventing.
I'm not trying to heckle. I just want someone to declare the word on
where in the filesystem we put .d files, parallel to c includes.
I think the single most important thing is for bindings against C libs
that are installed by common -dev packages, it would be easiest if the
bindings were fetched and installed the same way as the libs they
refer to.
Perhaps a new dub command (--locate)?
$ dub build <package> --version=<version> --arch=<arch>
--compiler=<compiler> --locate
Base: ~/.dub/<package>-<version>/
Binary: ~/.dub/<package>-<version>/output.lib
ImportPath: ~/.dub/<package>-<version>/source
Pass
Well you get the general gist. Fetches and builds if necessary for
specific arch ext.
Really it just minimizes output and only output location info.
