Re: [Boost-build] Future development

From: Bill Hoffman (bill.hoffman_at_[hidden])
Date: 2007-10-15 23:39:55

David Abrahams wrote:
>
> [Bill, I hope you don't mind me picking nits, but your mailer has ugly
> linebreaks and you should leave a blank line before starting your
> reply (http://boost.org/more/discussion_policy.htm#effective)]
>   
Sorry about that.  I will try to be more careful about the line 
lengths.  I always notice
the poor formating after I send the mail.  
>
>
> First of all, let me just say, "ick, that's even uglier than your
> mailer's linebreaks" ;-).  And it's full of redundant boilerplate.
>
> Secondly, I don't think this has the same semantics.  Normally if you
> say
>
>         bjam
>
> it builds once, with the default toolset (the first you've
> configured).  If you say
>
>         bjam gcc msvc
>
> it will build with the default version of gcc and of msvc.  You don't
> need to edit your user-config.jam to get a different build as long as
> it can find the compilers you've requested.  If you say
>
>        bjam gcc-3.4 gcc-4.2 msvc-6.5
>
> it will build with those specific versions (if they are configured).
>
> Unless I'm misunderstanding, I don't think ctest has the right
> abstractions for this.
>
> Thirdly, why should I have to get involved with the testing system
> just to get this functionality, which is clearly a build system thing?
>
>   
>> I am not sure this works right now, because there might be some
>> dashboard specific stuff that might be required, but I don't think
>> it would be hard to make this work.  It all depends on if you folks
>> think it is useful.
>>     
>
> Not in that form, IMO.
>   
OK, I guess I was looking for a solution that we already had.   We have 
the ctest stuff,
and it was created for a similar reason.  I tend to be overly pragmatic 
and look for
solutions that can be done today with a release of cmake.  I have talked 
about adding
a cmake --build option that would do the build directly from cmake 
before on this list.
Perhaps if we did that and gave it a group of settings, it would work 
more like bjam.
But, if someone wants to try something today with a cmake release, a 
ctest script can
be used to drive the build right now.

I am thinking this is more like an interface to the build system rather 
than part of it.
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.

mkdir gcc-3.4; cd gcc-3.4; ccmake ..
make
cd ..;mkdir gcc-4.2; ccmake ..
make
cd ..;mkdir msvc-6.5; ccmake ..
make

After that initial configuration is done, if I change something, 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 basic
command line interface that was copied for cmake (mkdir, configure; make).
So, all that said, I don't think it would be hard to add something like what
you have in bjam, but maybe python scripts would be sufficient.  Certainly
in the short term, with release versions of CMake, it would have to be done
that way.

-Bill