|
Boost : |
From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-02-23 21:01:30
Would it make sense to:
1) Get autoconf/automake/libtool in place for those platforms that it works on.
2) Run it on those platforms.
3) Provide the results of those runs as well -- preconfigured, as it were.
4) Provide manually constructed configurations for the remaining platforms.
That said, I hope the whole structure can remain simple enough for people to
find and extract what they need from Boost and fold it into whatever build
process they already have without suffering too much brain damage.
From: Braden N. McDaniel <braden_at_[hidden]>
> On Wed, 23 Feb 2000, Beman Dawes wrote:
>
> > Isn't the issue of how to configure for a given platform separable
> > from how to build the binary library for the platform? Of course, if
> > any configuration has to be done, it must be done first.
>
> I don't think autoconf/automake/libtool are sufficiently non-intrusive to
> fully mesh with the process you described in your other posting. Here is a
> rough overview of the process...
>
> If one is using automake, one writes Makefile.am scripts. You'll need one
> of these in each directory involved in the build process. Running automake
> in the top-level directory recurses the subdirectories and generates a
> Makefile.in from each Makefile.am. If you're not using automake, you
> author the Makefile.in's directly.
>
> In the top-level directory, you write a script called configure.in.
> Running autoconf on this yields the configure script. Running the
> configure script checks a bunch of stuff about your system, and generates
> Makefile's from the Makefile.in's. If you're using an autoconf config
> header, it gets generated at this point, too.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk