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 use. 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: T:\boost\include\boost-1_32\boost>autoconf '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 install.
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 like. 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. jon