[boost] Re: Installing Boost Libraries

From: Braden N. McDaniel (braden_at_[hidden])
Date: 2000-02-23 18:40:04

On Wed, 23 Feb 2000, Jens Maurer wrote:

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

This is all true, but the current scheme of using "config.hpp" does have
the benefit of being cross-platform (more or less). If boost were to use
an autoconf-generated config header, things would be a bit tidier for
platforms with autoconf, yet it seems like we'd end up with
platform-specific config files for the other platforms.

Note to those unfamiliar with autoconf: This is not an issue that would
likely determine *whether* boost could use autoconf, just exactly how we
would employ it.

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

Right; I don't perceive any licensing issues with any of these tools.

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

It seems to me that this approach would likely rule out use of automake.
Considering the numerous handy targets that automake generates (not the
least of which is "install"), I'm not sure this wouldn't be more trouble
than it's worth.

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

I think a makefile probably doesn't adequately address installation issues
for Windows and Mac.

-- 
Braden N. McDaniel
braden_at_[hidden]
<URL:http://www.endoframe.com>