On Sun, 2 Nov 2008, David Abrahams wrote:
on Sat Nov 01 2008, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
- users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway.
This has bitten me a couple times. You'd be surprised how many people know which flags autoconf needs for a quirky platform.
So, I'd like to suggest a solution where building of boost involves three steps: ... Anybody has comments about this plan?
I like the idea of having a script to compile bjam and copy it to the top directory.
Yeah. For a surprisingly large number of *nix users, if the process doesn't look like ./configure && make && make install, they will get upset. That's the reason the configure script was created.
:) Happy autotools user here.
Only a small subset of those users may try to set CXXFLAGS et. al, and even a smaller subset needs to do cross-compilation, so I believe we're making more people happy than angry. I would be very, very cautious about removing the configure script.
I've had the misfortune of installing boost on several "unusual" boxes (mostly old Sparc/Solaris). I quickly learned to ignore Boost's configure script (had to edit some gcc jam rules). Would it be possible to leave in the configure script and have it print a banner at the end? Something like "" # ./configure ... # compiling bjam, detecting settings, ... Boost configuration complete Configuration summary bjam compiled to path/to/bjam ... # summary of settings To modify these settings, edit user-config.jam. To build, run `make` or bjam --enable-this --disable-that To install, run `make install` or bjam --enable-this --disable-that install "" - Daniel