Re: Future development

> on Mon Oct 15 2007, Bill Hoffman
<bill.hoffman-AT-kitware.com> wrote:
> 
>>> into the system.  My question is, do we really
need to be able to
>>> specify arbitrary combinations of tools on the
bjam/cmake command
>>> line, or is it enough to configure the
combinations we're interested
>>> in, each using its own build tree?

Hi,

I'm a bit of a lurker on this list...I've been using
Boost.Build on and 
off for a few years now for a couple of projects on which I
work.  I 
thought I'd chime in on my particular use case since it
applies here.

I have software which needs to be built differently
depending on the 
environment in which it will run.  Some variants (all
Linux/gcc):

- an executable that runs on a 32-bit platform with some OS
version
- an executable that runs on a 64-bit platform as a fully
64-bit program 
  with a different OS version
- an executable that runs on a 64-bit platform as a 32-bit
program with 
yet another OS version
- a shared library that gets linked into another program
that runs in 
any of the above configurations
- many of the above have different compile options,
includes, etc.

The reason for the many versions is that my code needs to
compile on and 
run in a heterogeneous lab environment with many different
machines.

The different OS versions on Linux implies (for me)
different libc 
versions, which means I need to use different versions of
gcc.  I have 
found the ability to make any or all of these variants
simply using the 
command line an indispensable feature.

Also, though it's slightly outside this particular
discussion, I'd like 
to add that my experience with Boost.Build resonates with
the 
perceptions mentioned on this list before:

1) The documentation needs work (thought I have seen
incredible 
improvements in it since I first started....bravo!)

2) It is too hard to extend the system (or more precisely I
guess, there 
is too large a learning curve).  I found myself taking _way_
too long 
trying to customize the code to do something I thought would
be somewhat 
trivial once I got the basics down...it wasn't.  I was
digging in the 
guts of the Boost.Build trying to figure out what I needed
to do, which 
is never fun.

Anyway, I hope these comments from this casual user helps.

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

On Tuesday 16 October 2007 20:15:36 Jordan Rosenthal wrote:

> Also, though it's slightly outside this particular
discussion, I'd like 
> to add that my experience with Boost.Build resonates
with the 
> perceptions mentioned on this list before:
> 
> 1) The documentation needs work (thought I have seen
incredible 
> improvements in it since I first started....bravo!)
> 
> 2) It is too hard to extend the system (or more
precisely I guess, there 
> is too large a learning curve).  I found myself taking
_way_ too long 
> trying to customize the code to do something I thought
would be somewhat 
> trivial once I got the basics down...it wasn't.  I was
digging in the 
> guts of the Boost.Build trying to figure out what I
needed to do, which 
> is never fun.

I think two problems with the current extender's guide are:

1. It does not describe all the levels and how they
interact. So, while
it tells what you can create a generator, it's not obvious
what generator
takes, and when it's called and what it can produce.

2. There's no textual documentation of the important methods
of
generators (that one might want to override), or in
virtual-target 
and action class (that one might want to use).

So, the next result is that in parts, extender's guide hints
on solutions,
but does not explain it in details. 

I've added those points to: 
https://zigzag.cs.msu.su:7813/boost.build/ticket/151
Feel free to add other points that you might want covered.

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