On Monday, 1 June 2015 at 05:27:00 UTC, Manu wrote:
On 1 June 2015 at 14:57, weaselcat via Digitalmars-d
<[email protected]> wrote:
On Monday, 1 June 2015 at 03:48:31 UTC, Manu wrote:
On 1 June 2015 at 09:01, Andrei Alexandrescu via Digitalmars-d
<[email protected]> wrote:
Let's make this part of 2.068:
https://issues.dlang.org/show_bug.cgi?id=14636
It's preapproved. Who would want to work on it?
Please declare a standard unix location for D 'includes'.
Nobody
agrees where in the filesystem D files should be.
I use /usr/include/d2/ for my stuff (I saw it precedented a
few times
before, but it doesn't seem that great), but I want a
standard place
that stuff bundled by linux package managers can agree on.
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.
run dub fetch --help
Interesting. I'm amazed this never came up before in
discussion...
I've talked about this so many times.
So, DMD/LDC/GDC know where to look to find these packages? What
happens if the package includes a binary lib?
No. But dub knows where the packages are, and the usual way to
use it is to use dub to compile. If not, there's always `dub
describe`, which will tell you exactly where the dependencies are.
Atila
That that, I still want someone to declare an official path for
D
'includes' in the *nix filesystem, so D lib packages have
somewhere to
install...
