Doug Gregor wrote:
On May 9, 2007, at 2:53 PM, Rene Rivera wrote:
Doug Gregor wrote:
On May 9, 2007, at 2:20 PM, Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make. ... and it works better for the CMake model, where one generates build rules for a specific environment (makefiles, VC++ solutions, XCode projects, etc.). Speaking of that, another requirement:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process.
I don't understand this requirement. Are you saying that something like:
configure make
Does not meet the build-system requirements?
What I'm saying is that this doesn't meat the requirement: cd boost-root-nmake-vc80 cmake --use-nmake-vc80 ..\boost-root NMAKE NMAKE test NMAKE install cd boost-root-nmake-vc71 cmake --use-nmake-vc71 ..\boost-root NMAKE NMAKE test NMAKE install cd boost-root-gmake-gcc345 cmake --use-gmake-gcc345 ..\boost-root gmake gmake test gmake install Why should we give up the current: cd boost-root bjam msvc-8.0 test install bjam msvc-7.1 test install bjam gcc-3.4.5 test install (ignoring that those could be done in one command for comparison sake) ? The *only* benefit I see from using generation system like cmake, or wxWidget bakefile, is for end users where the Boost release manager creates a bunch of makefiles, nmake files, vc project files, etc. and hence the user doesn't have to use cmake, or bakefile. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo