Walter Landry wrote:
it's doesn't give users any improvements on functionality or ease of use than the current: "bjam install".
Except that you don't have to install bjam.
You don't have to install bjam, actually. Just tools/build/jam_src/build.sh && tools/build/jam_src/bin.linuxx86/bjam -sTOOLS=gcc install would work on Linux. And as Rene pointed out, this can be placed into file called "Makefile".
It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install,
Do you know stock autoconf macro which finds Python headers? If not, then the task of writing one is just as hard as writing this logic in Python's jamfile.
and it spits out annoying warning if I use a new version of gcc. This is a bit ridiculous.
It's a bit strange that you try to blame bjam for everything. This warning is produced by boost.config headers, for no good reason (IMO).
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".
Then solution like Rene's will work fine. It's not clear that we've arrived at the point where real configure system is better than current config.hpp. And if we've arrived, I'd much rather use Python-based system. Say, SCons has such module, which does no depend on SCons and can be adapted to Boost.Build. - Volodya