|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-04-18 09:55:19
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk