www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Packaging, /usr/lib/phobos vs. /usr/include/d

Just in case someone else (using Linux) is wondering,

the reason why I install the Phobos import modules to
"/usr/include/d" is because I use that same directory
for all system D modules. That is, I can install stuff
like Dool or Mango or OpenGL or SDL etc. there too...

By calling it "/usr/lib/phobos", it implies that only
Phobos files are located there (which is correct in
the default installation, but limits the usability ?)
Adding 3rd party libraries to a "phobos" dir feels wrong.

Why it's in "/usr/include/d" is strictly a FHS* issue,
otherwise it could have been "/usr/import" or whatever.
But adding new directories to /usr is not allowed... ?
(and it's kinda similar to "/usr/include/c++", as well)

Note that I say "import modules". The implementation
modules (such as the Phobos ones in internal/*.d)
are *not* installed, they just end up in the library.
This is somewhat similar to C headers, in concept.

I didn't include all the C library source code either.
(no idea why those directories are in the Phobos tree:
etc/c/recls etc/c/stlsoft etc/c/zlib, full of .c/.h ?)
I understand why they are in source, but not in import ?

The module etc.c.zlib seems to have gotten lost in the
woods, as it should probably be in std.c.zlib instead ?
(in any case, it is being included by std.zlib now...
Or should *that* module perhaps be etc.zlib instead ?)

Hopefully, this can all be sorted out when (if?)
Phobos gets a decent makefile that knows how to:
1) compile (with -unittest) and run the unittest
2) install the .d import modules and the .a library
As well as the other Makefile problems reported earlier,
that are currently being patched out by the RPM builds...

It would also be nice if one could use the same Phobos
files for both DMD and GDC, but that's less important.

Another trick is building Phobos without first installing
DMD/GDC to the global location, but I've shown how to do
that in the RPM specfiles (by using a temp install dir)
The only thing I missed there was that I ran the unittest
against the source directory, and thus failed to notice
that the zlib files were not all being installed by GDC)

I think good packaging is at least as important as
good documentation. This probably includes a Windows
DMD installer, and a Mac OS X GDC installer as well...
(eg. http://noirotm.free.fr/soft/dmd.iss for Inno Setup,
and eg. http://www.algonet.se/~afb/d/gdc-installer.jpg)

Having a .tar.gz file for Linux with UNIX linebreaks,
in addition to the .zip for Windows with DOS linebreaks,
could be a nice addition ? It's not really required...
(zip is available on Linux too, and perl can do the rest)
But a little choice couldn't hurt, and help spread D too ?

Then all that is neeeded is for DMD to be distributable ;-)



* FHS (Filesystem Hierarchy Standard)

* RPM specfiles (included in the SRPMS)

* Inno Setup (Win32)

* RPM2PKG (Mac OS X)
Feb 23 2005