From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-05-09 15:17:33
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 /
>>> ... 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
> I don't understand this requirement. Are you saying that something like:
> Does not meet the build-system requirements?
What I'm saying is that this doesn't meat the requirement:
cmake --use-nmake-vc80 ..\boost-root
cmake --use-nmake-vc71 ..\boost-root
cmake --use-gmake-gcc345 ..\boost-root
Why should we give up the current:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk