Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-15 12:35:23

On Fri, 15 Dec 2000, John Maddock wrote:

> If you mean retain all the headers in a boost/ sub-directory then yes
> absolutely.  IMO messing with the current include file structure is a
> serious mistake, the #include <boost/name.hpp> method works very well,
> and works accross a variety of platforms as well, in fact on most
> systems it's a complete no-brainer as far as I'm concerned.

No, that's not quite what I'm saying.

I think changing the current directory structure would be a good idea.
There are some management shortcomings to the current approach (IMHO).
But I also think that having a separate installation tree is also a good
idea.  This allows the user to have a single -I and still have their code
do what they did before:

        #include <boost/regex.h>

and this will continue to work across all OSs.

> They're also easy to "install" if that's what you want on linux
> systems with a simple:
>
> cp <boost-path>/boost /usr/include/boost

Not really; there's a few more things that really should be done:

-----
su
if test ! -d /usr/include/boost
  mkdir /usr/include/boost
  chmod 755 /usr/include/boost
fi
cp -r <boost-path>/boost /usr/include/boost
find /usr/include/boost -type f -exec chmod 644 {} \;
find /usr/include/boost -type d -exec chmod 755 {} \;
-----

Installing properly frequently requires a few more steps than you want to
have to tell users to do.  Who wants to explain about permissions and
whatnot?  Automation is good -- a user can execute a simple command and
rely on the developers to have supplied a good enough tool to do the
complex tasks for them.  And then they have less questions on how to use
boost on the mailing list.  :-)

Indeed, we also have to install the .a/.so files as well.

The script shown above is very crass, and shortened for example purposes;
you can't necessarily assume that "-r" works for "cp", and I'm not 100%
sure about the portability of find.  Indeed, a better language choice for
the installer would be python so that we could use it in Windows as well,
in which case "cp -r" and "find" will have to use python equivalents.

> I worry that some of this discussion is getting seriously linux
> oriented, I'm not saying that we shouldn't do this, only that linux
> support does not define the library structure - there are other
> platforms out there :-)

Yes; we certainly should not focus on Linux.  If nothing else, Linux is
only one flavor of Unix.  What works on Linux does not necessarily work
under other flavors of Unix.  And of course, there's Windows, which has a
very large user base.

Is it a true statement to say that python exists on all platforms that
boost wants to be on?

For any type of tools -- building, installing, or anything else -- *some*
kind of scripting language will be required.  I certainly hope that we can
rely on more than just "make".

> The main requirement is that the source files required to be built can
> be found automatically by scripts so that this does not constitute a
> maintenance overhead (because then makefiles can be auto-generated).
> That requirement is met either by putting the source in
> "boost-root/libs/libname/src" or in "boost-root/src/libname".
> Personally I am happy with the former, but will change to latter if
> required.

That's not a bad thing.  If all .hpp files can be assumed to be installed,
and all .cpp files be assumed to be compiled into some .a/.so file,
makefiles and whatnot can be auto-generated.  You might still need an
auxillary file to specify some meta data, such as the name of the .a/.so
file, etc.

{+} Jeff Squyres
{+} squyres_at_[hidden]
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"