Re: [boost] [ot] choosing a build system

Subject: Re: [boost] [ot] choosing a build system
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-05-23 08:47:11

On Mon, May 21, 2012 at 12:47 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Tue May 15 2012, Matthew Chambers <matt.chambers42-AT-gmail.com> wrote:
>
>> On 5/14/2012 2:36 AM, Dave Abrahams wrote:
>>>
>>> Right.  And 90% of use-cases don't want to take care of any of those
>>> things.  That's why we wrote the rules as we did.  Generating all the
>>> possible variants of a library is a packager's job, not part of the
>>> regular development workflow nor something that users regularly want.
>>
>> If multiple library variants are desired to be supported, then it
>> shouldn't just be part of the regular development workflow, it should
>> be part of continuous integration.
>
> Strike "just," and I agree with you.  Most CI should go on somewhere
> away from the average developer's machine, although it's always good to
> be able to duplicate that procedure locally.

My own local workflow is to develop via IDE (Visual Studio latest
production release) and then when those tests pass, kick off bjam
against many compilers (currently 7). For Filesystem, some of the
tests are static, some are shared. I really should test both debug and
release builds, although I'm not doing that now.

I prefer results to be reported via an HTML table, but am willing to
write the program to generate that HTML page, as long as the test
results are available in some easy to parse form.

>> Boost.Build makes it much easier for me to create various build
>> configurations targeting the different variants without cluttering the
>> build files.
>
> Right.  And Ryppl is going going to add what's necessary in a layer on
> top of cmake.  In fact, this would be a good time to find out what it is
> that you need so that we can implement it in the Ryppl build tool.

For me, it is pretty much what bjam does now. Such as being able to specify:
  * Test specs invoke build specs if needed.
  * Compile, link, or run test, where pass|fail can be a report of no
errors or errors.
  * Define macros, globally, per test, or per platform.
  * Define compiler or linker switches, globally, per test, or per platform.
  * Specify macros, switches, or other config details based on static,
shared, debug, or release builds.
  * Be able to add or override macros, switches, or other config
details from the command line.
  * Be able to add or override macros, switches, or other config
details from a user config file.

Presumably CMake already handles most of that.

--Beman