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.

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

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++")

-----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-----

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.

You mean /usr/include/d/### then, I think ? (looking at "c++")
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

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

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

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/

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/)

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