[boost] Re: Installing Boost Libraries

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-02-23 17:38:21

"Braden N. McDaniel" wrote:
> GNU autoconf/automake/libtool cover a pretty broad range of platforms. Not
> Mac (though I think there's a good deal of hope for OS X support in the
> future), and Windows support is limited to Cygwin. 

For Unix, we should definitely go "autoconf".
With <boost/config.hpp>, we've got a "tell me the name of your compiler,
I tell you what features it has" approach.  "autoconf" has the
philosophy of "whatever is there, let's try out what it supports".
That means, "autoconf" has the (slight) chance to support more
platforms than those that were known to exist at <boost/config.hpp>
production time. Besides, the autoconf approach scales linearily with
the number of (mis-)features, while the (current) <boost/config.hpp> scales
with (number of (mis-)features) times (number of compilers/environments).

I can provide self-written autoconf macros (with boost-compatible copyright)
for some of the BOOST_* feature macros. autoconf itself should not be a
problem, because the configure files it generates are not GPL (as a special
exception, see the autoconf m4 macro files for details).

Anyway, limited remote access to several different platforms to do
package regression testing on the various commercial Unix compilers
(HP, Sun, SGI, AIX, whatever) would be cool, same with Windows (MSVC,
Borland, Metrowerks, etc.) and Mac, those probably with a Web/CGI
frontend due to their limited multi-user capability.

> > There needs to
> > be one single platform independent way of specifying what files (or
> > maybe just all the files in some directory) go into the build, so
> > that the platform specific portions don't have to be modified just
> > because an additional .cpp file is added to the library.
> 
> For platforms addressed by the GNU tools, this is automake's job.
> Unfortunately, I don't know of a solution that will meet this requirement
> for *all* platforms.

For Windows, all compilers should support some command-line mode
and make, so the problem reduces to generating the correct Makefile.
All makes have a (small) subset of features in common, so we can
probably define the names of the relevant files and/or subdirectories
in a common include file which all make variants understand.
For Unix, we put automake/autoconf/libtool on top, for Windows we
provide either one Makefile for MSCV, Borland, etc. each or one fits
all. (I don't know much about these.)
For Mac, someone else should comment.

If this doesn't work out, we can always have a "perl" script
to give us more flexibility.  If some platform doesn't have perl,
we generate the relevant files on Unix and put them in the
distribution package.  In general, we should take care that the
user's build requires only the most basic tools available on
all platforms (on Unix, Bourne shell and make, on Windows
command.com and the tools delivered with the compiler).

Jens Maurer.