From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-04-18 13:54:19
On Mon, Apr 18, 2005 at 10:48:20AM -0700, Victor A. Wagner Jr. wrote:
> >Except that you don't have to install bjam.
> or install autoconf
You only need to install autoconf if you want to generate configre
scripts, not if you want to use them. Think of it as a JamFile
generator, except the output is a script.
Users have to install bjam to install boost - that is not the case
with autoconf, only the developers need autoconf, which they use to
prepare a script that the users will use.
To quote from the autoconf RPM description on my system:
Note that the Autoconf package is not required for the end-user who
may be configuring software with an Autoconf-generated script;
Autoconf is only required for the generation of the scripts, not their
Conversely, end-users *are* required to build or install bjam to make
use of the JamFiles that come with Boost.
> > It would also have a
> >chance of working properly. On my system, bjam could not find the
> >development headers for my python install, and it spits out annoying
> >warning if I use a new version of gcc. This is a bit ridiculous.
> on my system autoconf results in:
> 'autoconf' is not recognized as an internal or external command,
> operable program or batch file.
> and the last time I -did- have it installed, it got run 5 times by an
> install script and tested the same damned stuff over and over and
> over. IMO a worthless piece of junk.
Are you sure? Are you that what was running wasn't a configure script?
(probably generated by autoconf, yes, but not running autoconf)
> >> If people are willing to devote some effort we'd welcome what I would
> >> consider the optimal solution of just: "install". Which would use a
> >> system similar to the Linux Kernel configurator of providing a UI,
> >> graphical or curses, to select parts to install, to build, and to
> >I don't need that much. Just "configure; make; make install".
> as I said, "configure" don't exist on my systems, and like it or not, *nix
> is a _very_ small portion of the market.
Each package comes with its own "configure" script that does what it
needs to, you don't have a single "configure" that lives on your system.
Once you've built and installed the software you can delete the
configure script, along with the rest of the sources.
I'm not arguing that Boost should switch, as I have no experience of
using on non-unix platforms, but I do find bjam less scrutable than I'd
More important than changing how the Boost libs are built and installed
(which is something you do at most once per system, per release) is
pkgconfig support to make it easier to use an installed Boost. You use
the installed headers and libs far more frequently than you install them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk