Re: Future development

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Bill Hoffman wrote:

> 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.
> 
I think part of the issue here is that cmake is not a direct
build tool. 
  It is a build tool generator.  You run it once to
configure for a 
setup, then you can build lots of times.  With bjam it does
the 
configure and build all at once.  So, it makes more sense to
have bjam 
compiler1 compiler2.  Not that can not be done with cmake,
but it does 
not exist today in cmake, other than in the ctest stuff.

-Bill

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 10/15/07 22:39, Bill Hoffman wrote:
[snip]

 > 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 ..
 > 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,

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:

http://archives.free.net.ph/message/20070816
.184219.64126ddd.en.html

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 
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.

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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Mon Oct 15 2007, Bill Hoffman
<bill.hoffman-AT-kitware.com> wrote:

>>> 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.  

Always a good thing to try first.  Just doesn't work in this
case.

> 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.  

Depends on a lot of detail you've left out.  I don't know
what "gave
it a group of settings" means, for example.

> 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.  

Not sure what that means.

> The use case you are talking about, is not that
common.

Yes, as I said.  However, it is very important for Boost
developers
and other developers of highly portable C++.

> 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.

IIUC you run ccmake or CMakeSetup for each member of the
compiler/project cross-product, right?  If it were just once
for each
compiler, it *might* be acceptable, if suboptimal.  If it's
once for
each compiler for each project, it's totally unacceptable.

> 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, 

like what?  Change a source 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
> basic command line interface that was copied for cmake
(mkdir,
> configure; make).  

Yes, and despite the fact that Boost.Build has superior
abstractions,
I think most users are far more comfortable with that
model.

> 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.

Hm.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build