Re: [Boost-build] Improving Boost Build?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-18 11:24:32

Hi Jurko!

On 5/17/07, Jurko Gospodnetiæ <jurko_for_boost_at_[hidden]> wrote:
>    Hi Dean.
>
> > If that's what needs to be done, then I guess someone's gotta do it
> > too... We'll see, if there's enough encouragement and support from the
> > (or a) community to keep this alive [CAN PEOPLE PLEASE CHIME IN NOW?!]
> > then maybe it just might be worth the effort.
>
>    Here's a CHIME for ya... :-)))
>

Weeee! :-)

>    We use Boost.Build in our projects and would definitely not like to
> see it abandoned. We are not afraid to get a little dirty to use the
> tool and so far we've managed to get it to do almost everything we
> wanted but a bit better documentation would definitely be a plus. Some
> information you can find only by running into it in old news archives,
> having someone tell you or by stumbling onto it in the source code.
>

I think the first order of business really is to document the
internals and the extension mechanisms -- as well as the architecture,
design decisions, features, and known bugs. I believe this can be
done: we just have to have a plan and stick with it. We can do it
piece-meal and definitely someday it's going to get done. I'm positive
about it. ;-)

So hopefully, when we do become successful in building on Boost.Build
and extending it to be the build system we want it to be, you won't
have to "get a little dirty to use the tool". ;-)

>    Our main test project automated using Boost.Build consists of a
> static library, 2 DLLs, about 5 different utilities linked to those
> libraries in different ways, some of the built products linking to
> external libraries like wxWidgets, Boost.Build automating external tools
> like wxFormBuilder for generating wxWidgets GUI code with most of the
> products buildable in two modes - client and admin (compile-time
> choice)... It uses our own customized msvc toolset (tried extending the
> msvc toolset - but did not work as we wanted so we cloned it for now and
> will try to extend msvc again at a later time)... And so far everything
> works. :-)
>

Sweet! I personally want to read more stuff like this... I believe
these kinds of encouragement will do wonders for the developers who
have been working long and hard to make Boost.Build what it already is
and still working harder to make it better and better.

Now separate (or special) site for Boost.Build sounds very attractive
at the moment. ;-)

>    Some problems we still have open are:
>
>      1. Is there an easy way to see a response file used for a failed
> build action? The best workaround we found so far is temporarily denying
>   ourselves the right to delete files from the target folder and so
> preventing Boost.Build to remove the file. :-)))
>

I don't know about easy, but I imagine using pipes on Unix... I'm not
sure I understand what you mean though by "see a response file used
for a failed build action". If you mean the outputs of an error for
building 'object.o' into a file named 'object_o_fail.log', then I
guess it's a nice to have worth exploring. :-)

>      2. We'd like the clean rule to remove all the created and now empty
> target folders.
>

I'd like this too. I think this is documented somewhere, having like a
special action for removing directories. I'd like this to be a
command-line-option for bjam myself though.

Right now I use rm -rf ./bin/ to make sure everything in the build
output directory is deleted. :D

>      3. Is there a way to allow a project to to build only with a
> specific feature value and have its build ignored in case a different
> feature is requested? E.g. if you have three subprojects: A, B & C, of
> which A & B are buildable in both debug and release mode while C can
> only be built in release mode. Then you'd like 'bjam' or 'bjam debug' to
> build projects A & B in debug mode, 'bjam release' to build all three
> projects in release mode and 'bjam debug release' to build projects A &
> B in both debug and release mode and project C only in release mode.
> Simply specifying <variant>release as a requirement for project C has
> different semantics and does not work at all in cases like 'bjam debug
> release'.
>

Sounds like an issue that's being discussed a while back about
alternatives. Having a '<variant>release:<ignore>true' feature sounds
like it would provide what you're requiring. Or maybe there's already
something in there which allows this behavior... We wouldn't know
until we start getting things documented and explained/understood
thoroughly. :-)

>    Hope this is taken as 'interest'. :-) Even though we currently do not
> have the resources to continue actively researching/developing boost
> build. :-( But... we can always hope...
>

Definitely taken as interest. :-)

I think we'll all do our best to keep Boost.Build moving and
improving, now that we're hearing praise and success stories left and
right. :-)

>    Best regards,
>      Jurko Gospodnetiæ
>

Thanks again Jurko! :-)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]