Re: [boost] Re: Directory Structure

From: John (EBo) David (ebo_at_[hidden])
Date: 2000-12-15 14:32:21

Jeff Squyres wrote:
> 
> [snip...]
> 
> It is definitely true that moving the .hpp files back into each library
> subdirectory would necessitate more -I's for the boost developer.  Keeping
> the <boost/foo.hpp> nomenclature is certainly do-able, though:
> 
> boost_x.y.z/
>   src/
>     regex/
>       boost/
>         regex.hpp
>       src/
>         src1.cpp
>         src2.cpp
> 
> So the boost developer would need -I$top/boost_x.y.z/src/regex, and then
> 
>         #include <boost/regex.hpp>

I am perfectly happy with this solution.

> would still work.  However, an additional -I would be necessary for every
> boost sub library that you wanted to use.  Icky, annoying to type, and
> prone to mistakes (because, assumedly, there will be lots of -I's that
> you'll need).
>
> One solution for this is the "wrapper compiler" concept. 
>
> [snip: MPI compiler wrapper...]
>
>         boostCC myprogram.cpp -o myprogram
> 
> turns around and executes:
> 
>         CC -I/usr/local/include myprogram.cpp -L/usr/local/lib \
>                 -lboost_regex -o myprogram

For development that is fine, but I would still like to see installs
into a single install tree so that I would not have to explain (and
maintain) an additional compiler wrapper unless absolutely necessary.

Another way to do this is with a shell script that reports
configureation parameters.  Examples of this is the ImageMagick studio
and GTK

Magick-config.  For example, to generate all the ugly -I... -L...'s I
can just run:

  Magick-config --cppflags

which on my machine produces:
  -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64
-I/usr/local/src/ImageMagick-5.2.0/jpeg -I/usr/local/include
-I/usr/X11R6/include

and 

  Magick-config --ldflags --libs

which on my machine produces:
  -L/usr/local/src/ImageMagick-5.2.0/jpeg -L/usr/local/lib
-L/usr/X11R6/lib -L/usr/local/src/ImageMagick-5.2.0/magick -lMagick  
-ltiff -lttf -ljpeg -lpng   -lXext -lXt  -lSM -lICE -lX11  -lbz2 -lz   
-lm

Since I have not yet played with the Win* or Mac OS version of
ImageMagick I do not know how they deal with it in non-UNIX land, but am
sure I will find out very soon.

> 
> > [snim: make install and libname...]
>
> 
> This makes me thing about something Beman said in a previous post --
> several of the boost core libraries all depend on each other.  And some of
> the non-core boost libraries depend on one or two of the core libraries.
> You can easily imagine a dependency graph here.

If it were up to me ;-) I would probably do both and install a
libboost.a/.so (or boost.dll) and all the little libregx.a/.so...  For
the naieve users, and those who do not care to strip it all down, have
them just include -lboost or boost.dll.  Including each small one is
noted for advanced users only, but for those of you who want/need it, we
make it availible to you.  If you want to include each one seperately
for some reason then you need to deal with the dependencies yourself...
and it is the responsibility of the advanced user.

> Should the build/install infrastructure enforce this, and protect the user
> from themselves?  i.e., if you did:
> 
>         make install-libname1
> 
> should it fail with an error indicating that libname1 also depends on
> libname2, libname3, etc.?  Or automagically install libname2, libname3,
> etc.?

tracking down the dependencies would be kind, and should be able to set
up when building the make files and or configuration scripts.

> Installing piecemeal can be problematic; there should either be some
> protection for naieve users or it should not be allowed, IMHO.

true, but that is 1) for advanced users, and 2) we could set it up to
install all dependcies or possibly set up an option that warns that
there are unresolved depencies and give them yet another option that
installs all of the dependencies too like: 
install-libname1-dependencies.

EBo --