From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-10-16 14:12:20
On 10/15/07 22:39, Bill Hoffman wrote:
> The use case you are talking about, is not that common. Most users
> have one compiler they work with per system. I happen to work with
> many compilers on one system. I create a binary directory for each
> of them, running ccmake or CMakeSetup to configure it for that
> compiler, and after that I run make, and cmake is re-run if it needs
> to and the software is built correctly.
But this would require the user to understand the flags for all the
compilers that are targeted. Bjam saves the users this chore by
providing a uniform name for all these flags. (Although admittedly,
that's not my usual case.)
> mkdir gcc-3.4; cd gcc-3.4; ccmake ..
> cd ..;mkdir gcc-4.2; ccmake ..
> cd ..;mkdir msvc-6.5; ccmake ..
> After that initial configuration is done, if I change something,
by 1) hand editing the CMakeCache.txt or 2) using ccmake (but only if
not modifying the compiler), presumably? I say not modifying the
compiler for 2) because, as pointed out here:
it can't be done without rm'ing the CMakeCache.txt file.
> I do this:
> cd gcc-3.4;make
> cd gcc-4.2;make
> cd msvc-6.5; make
> This actually should be quite familiar to autoconf users. That is the
> command line interface that was copied for cmake (mkdir, configure;
> So, all that said, I don't think it would be hard to add something
> you have in bjam, but maybe python scripts would be sufficient.
> in the short term, with release versions of CMake, it would have to
> that way.
Maybe this would be sufficient: a python script which, given the bjam
uniform name and compiler, translates that to the corresponding
compiler option? Or maybe the script should take a filename of a file
containing the uniform names and their values, and then produce the
compiler options or command?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk