www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to install D libraries ?

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
What is the *preferred* installation
location for D libraries and modules ?


Is it like C/C++ libraries, under e.g.
/usr/local/lib and /usr/local/include ?
(with a subdirectory for all the D code,
like "include/dmd" or "include/d" or so)

Or is it like Java, where you scatter
them anywhere* and mess with parameters ?
(CLASSPATH in java, -I and -L in GDC)
DMD seems to prefer this way, itself.


I'm noticing most of the Makefiles
are lacking the "install" target...
Which kinda sucks for making RPMS,
for instance ? (as I like packages)

--anders

* Most likely they would end up under
   /usr/share/d, or something similar.
Dec 16 2004
parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:


 What is the *preferred* installation
 location for D libraries and modules ?
 


Good question.


 Is it like C/C++ libraries, under e.g.
 /usr/local/lib and /usr/local/include ?
 (with a subdirectory for all the D code,
 like "include/dmd" or "include/d" or so)


Do you mean the import modules or the object archives (*.a like
libphobos.a)?

I think the object archives should go in the same spot as the C/C++ ones
(/usr/local/lib preferred or maybe /usr/local/lib/d).  Since dmd uses
gcc/ld to link still, the libraries should be found in the place these
tools look first.  Unless, of course, it's decided that a new location for
d libraries are preferred; then the linker environment variables should be
updated for the new location.

For library imports, I've created a directory off my dmd installation
called /opt/dmd/imports.  Optimally, this should contain just the stripped
import modules for the library.  It seems unwieldy to have to maintain the
complete source for library merely for symbol lookup when my project needs
to use that library.

When stripped headers aren't supported by a library, /opt/dmd/src is the
default holder for source files referenced with the -I option.


 Or is it like Java, where you scatter
 them anywhere* and mess with parameters ?
 (CLASSPATH in java, -I and -L in GDC)
 DMD seems to prefer this way, itself.
 
 
 I'm noticing most of the Makefiles
 are lacking the "install" target...
 Which kinda sucks for making RPMS,
 for instance ? (as I like packages)


I agree... it would be nice to decide an a stardard locotion for those
files.

- John
Dec 16 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


Is it like C/C++ libraries, under e.g.
/usr/local/lib and /usr/local/include ?
(with a subdirectory for all the D code,
like "include/dmd" or "include/d" or so)


 
 Do you mean the import modules or the object archives
 (*.a like libphobos.a)?


Both.

I put the ("stripped") modules into: /usr/include/d.
(Note: changed from "dmd" in my earlier RPM release!)

 /usr/include/d
 /usr/include/d/etc
 /usr/include/d/etc/c
 /usr/include/d/internal
 /usr/include/d/internal/gc
 /usr/include/d/std/c
 /usr/include/d/std/c/linux
 /usr/include/d/std/c/windows
 /usr/include/d/std/typeinfo
 /usr/include/d/std/windows


Then I put the (compiled) libraries in: /usr/lib.

 /usr/lib/libphobos.a


See the source RPM package:
http://www.algonet.se/~afb/d/dmd-0.109-3.nosrc.rpm
(it actually uses %{_includedir}/d and %{_libdir})

Had I installed manually, it would be /usr/local ?
(i.e. I set prefix=/usr, to speak in "make" terms,
or Prefix: /usr, to speak in RPM "spec" terms...)


 I think the object archives should go in the same spot as the C/C++ ones
 (/usr/local/lib preferred or maybe /usr/local/lib/d).  Since dmd uses
 gcc/ld to link still, the libraries should be found in the place these
 tools look first.  Unless, of course, it's decided that a new location for
 d libraries are preferred; then the linker environment variables should be
 updated for the new location.


/usr/lib/libphobos.a is the location that DMD uses:
http://www.digitalmars.com/d/dcompiler.html#linux
(or perhaps /usr/local/lib/libphobos.a for manual ?)

The above page is a little split-minded, since it
puts the binaries in /usr/local and the lib in /usr ?
(it should probably say: "copy the programs to /usr/bin")

But playing with linker flags is no fun, since they
vary between the compilers and between the platforms...
So it's easier to put the libraries in the default dir.


 For library imports, I've created a directory off my dmd installation
 called /opt/dmd/imports.  Optimally, this should contain just the stripped
 import modules for the library.  It seems unwieldy to have to maintain the
 complete source for library merely for symbol lookup when my project needs
 to use that library.


Indeed, but it has been decided that .h headers are
unnecessary - so that's the way it is (at least until
someone provides that handy "code stripper" utility ?)

All these are put in /usr/include/d (and subdirectories thereof)
in the structure that I proposed (could be /opt/dmd/include/d ?)

In fact, it probably will be /opt/gdc since I run into several
conflicts with the installed system gcc compiler otherwise...

And -I%{_prefix}/include/d will be in the global DFLAGS,
so one won't be needing an extra -I per installed module.


 When stripped headers aren't supported by a library, /opt/dmd/src is the
 default holder for source files referenced with the -I option.


With or without source code, they all go in /usr/include/d
(since D doesn't really separate between them anyway, and
since the original source code does *not* get installed.
That is, wouldn't "src" contain the original directories ?)

i.e. /opt/dmd/imports, /opt/dmd/src => %{_prefix}/include/d

Or it's back to "plan B", with a directory for each library...
(the way Java does it) And set -I and -L accordingly, usually
linking straight to the source dir - with no chance of packaging.


I would prefer: (for instance, for Ant's "dool" library)

 /opt/gdc/include/d/dool
 /opt/gdc/lib/libdool.a


Where /opt/gdc is the prefix (which is configurable/relocatable)
It could just as well be /usr, when using the "offical" X86 DMD.

--anders

PS. Reason why it's "include/d" is that in GDC it is shared
     with the gcc and g++ compiler that also come with gdc...
     (they have their files in "include" and "include/c++")
Dec 16 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am Thu, 16 Dec 2004 22:37:51 +0100:

 When stripped headers aren't supported by a library, /opt/dmd/src is the
 default holder for source files referenced with the -I option.


 With or without source code, they all go in /usr/include/d
 (since D doesn't really separate between them anyway, and
 since the original source code does *not* get installed.
 That is, wouldn't "src" contain the original directories ?)

 i.e. /opt/dmd/imports, /opt/dmd/src => %{_prefix}/include/d

 Or it's back to "plan B", with a directory for each library...
 (the way Java does it) And set -I and -L accordingly, usually
 linking straight to the source dir - with no chance of packaging.


 I would prefer: (for instance, for Ant's "dool" library)

 /opt/gdc/include/d/dool
 /opt/gdc/lib/libdool.a


 Where /opt/gdc is the prefix (which is configurable/relocatable)
 It could just as well be /usr, when using the "offical" X86 DMD.

 --anders

 PS. Reason why it's "include/d" is that in GDC it is shared
      with the gcc and g++ compiler that also come with gdc...
      (they have their files in "include" and "include/c++")


We have to differentiate between Phobos - dmd/gdc version dependent -
and general "applications".

For Phobos we should use a versioned include a la gcc.
e.g.: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/include/d
This way multiple DMD and GDC versions can coexist.

"libphobos.a" should be either versioned itself or be placed in a
versioned dir.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFBwgoD3w+/yD4P9tIRAjSxAKDQ87UM8t6LAwildStDnXAyHd6UXgCeIG8q
stxwbgXXPj+PVNbbQ6v5ghw=
=viTJ
-----END PGP SIGNATURE-----
Dec 16 2004
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:


PS. Reason why it's "include/d" is that in GDC it is shared
     with the gcc and g++ compiler that also come with gdc...
     (they have their files in "include" and "include/c++")


 
 We have to differentiate between Phobos - dmd/gdc version dependent -
 and general "applications".


Right, the original question was about "applications"...
(They could still go in e.g. /usr/include/d and /usr/lib)


 For Phobos we should use a versioned include a la gcc.
 e.g.: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/include/d
 This way multiple DMD and GDC versions can coexist.



Such as "include/d/gdc-0.8-gcc-3.4.3" or "include/d/dmd-0.109" ?

I have the libs in /usr/lib/gcc-lib/i386-redhat-linux/3.4.3
(the internal libs that is, like libgcc or libstdc++ and so)

Sure, that can be done. Just didn't know you wanted several
different versions of GDC to be installed at the same time ?

Will hook the DFLAGS up, to include the version by default.
(-I%{_prefix}/d/%{name}-%{version}, or even worse for GDC)


 "libphobos.a" should be either versioned itself or be placed in a
 versioned dir.


There is a conflict in "libphobos.a" and "dmd",
since all D compilers will need to provide them...

Both DMD and GDC place them into "lib" and "bin",
of the corresponding default install location.

So their names needs to be versioned and symlinked,
or some similar (somewhat ugly) workaround like that...

Most users would expect to just run "dmd" and -"lphobos" ?

--anders
Dec 16 2004
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:


 For Phobos we should use a versioned include a la gcc.
 e.g.: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/include/d
 This way multiple DMD and GDC versions can coexist.


On second thought, I will just ignore this for the packages...


Since DMD installs under "/usr", and GDC under "/opt/gdc",
(i.e. with the default definition of the Prefix for gdc)
there isn't a conflict between the two different compilers -
just between multiple versions installed at the same time.

And that is not something that I had planned on doing...
(easy enough to do local installs for such extra testing?)

So: "include/d", "bin/dmd" and "lib/libphobos.a" it is.


I also had gdc-0.8 provide dmd-0.102, for later testing...
(so that other packages can check the installed "dialect")

As in: "BuildRequires: dmd >= 0.109"


I think most people will only use one of them anyway, right ?
(similar with GDC constructed using different versions of GCC)

--anders
Dec 16 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Anders F Björklund wrote:

 Thomas Kuehne wrote:
 

 For Phobos we should use a versioned include a la gcc.
 e.g.: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/include/d
 This way multiple DMD and GDC versions can coexist.




I'd rather have a directory called 'import' instead of using 'include'.

Lars Ivar Igesund
Dec 16 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lars Ivar Igesund wrote:


 For Phobos we should use a versioned include a la gcc.
 e.g.: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/include/d
 This way multiple DMD and GDC versions can coexist.




 
 I'd rather have a directory called 'import' instead of using 'include'.


That was just the way that GDC is setup by default, I just think that
it has something to do with that g++ used "include/c++" or something ?

For DMD, anything goes. (it is being specified in /etc/dmd.conf anyway)
But I'm not sure that e.g. /usr/import would fit into the FHS standard ?


Java uses /usr/share/java, so I suppose that /usr/share/d could be used.
Or even /usr/lib, like used by "/usr/lib/perl5" and "/usr/lib/python2.2"

Objective-C used another approach with hacking the compiler and adding
Frameworks bundles with headers inside of them. For its: #import <x/y.h>


Or it can just be a free-for-all... -I/wherever/the/files/are/today ?
Windows probably doesn't have any central directory for them anyway.

I'll just use "include/d" and "lib".
--anders


PS. FHS = Filesystem Hierarchy Standard, http://www.pathname.com/fhs/
Dec 17 2004
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <49e992-us3.ln1 kuehne.cn>, Thomas Kuehne says...

We have to differentiate between Phobos - dmd/gdc version dependent -
and general "applications".


Preferably one should be able to have both dmd and gdc on the same
machine.

Right now I'd be most comfortable if the two would be totally 
separate. This would of course mean two sets of libraries, etc.,
but hey, hard disks are cheap.

Both should still be FHS compliant. (http://www.pathname.com/fhs/)
Dec 17 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 Preferably one should be able to have both dmd and gdc on the same
 machine.
 
 Right now I'd be most comfortable if the two would be totally 
 separate. This would of course mean two sets of libraries, etc.,
 but hey, hard disks are cheap.
 
 Both should still be FHS compliant. (http://www.pathname.com/fhs/)


I ended up installing:

DMD under /usr/bin and /usr/include/d and /usr/lib, as well as
GDC under /opt/gdc/bin and /opt/gdc/include/d and /opt/gdc/lib

Totally separate and FHS compliant, but only 1 version of each.

--anders
Dec 17 2004