Re: [boost] jam build system

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-24 09:42:58

----- Original Message -----
From: "John Maddock" <John_Maddock_at_[hidden]>

> >Can it be done automatically? I'm not sure how David Turner feels about
> >this, but FTJam is currently in the Perforce public depot, and he's been
> >talking about an independent CVS host at SourceForge. The potential for
> >things getting out of synch is not to be underestimated.
>
> I know. I just want this as easy as possible for new users...

Agreed. There's still some distance to go in that direction ;-)
For now, the sources are available in our files area.

> >"complete" pain? I agree that it's ugly, but it sounds like you're
> >exaggerating a little bit. We're looking at alternatives (one involves
> >compiling allyourbase.jam into Jam so you don't need the -f option), but
> in
> >the meantime I suggest you write yourself a little batch file or shell
> >script that hides the need for the -f option.
>
> Well that's exactly what I did, I think I could even write a shell install
> script that automates the production of a wrapper that sets environment
> options and adds the necessary -f option, even so "allyourbase.jam" is
> really ugly name IMHO, sorry :-(

At the time this made working on the system a little more enjoyable:

http://www.planettribes.com/allyourbase/AYB2.swf

> >Can you give me some idea what you mean by "step by step instructions for
> >particular compilers"? Users shouldn't have to know much of anything
about
> >particular compilers to use the system. That's the goal, at least.
>
> Sure but what options are available for particular compilers?

As currently designed, there are no compiler-specific features, though it
would be easy enough to add a gcc-flags feature, for example. The goal,
however, is to try to normalize feature selection wherever possible so that
a user doesn't have to remember compiler-specific options.

> what options are available for all compilers?

All features are listed in tools/build/features.jam.

> How do I insist that a build is multi-threaded only? etc

-sBUILD=<threading>multi

or, if it's part of the target requirements, you put <threading>multi in the
requirements section for the target, as described in the doc.

> OK, but I would still like an "idiots first user guide to setting things
> up", I found it less than intuitive in the current docs, mainly because
the
> information I needed was scattered around a bit, or at least that's how it
> felt at the time, maybe I was just in a rush :-)

Please try to be patient. A comprehensive build system is neccessarily
complex, and it can be difficult to present simply. Concrete suggestions for
how to improve the documentation would be helpful, though. Even better, if
some early adopter(s) would write the idiots first guide, I'd be happy to
edit and incorporate it.

> >Well, you need to add it to the requirements for the target. Requirements
> >come in a section following the sources, and might look like this for
your
> >case:
> >
> >: <msvc><*><define>BOOST_RE_BUILD_DLL
> <borland><*><define>BOOST_RE_BUILD_DLL
>
> That's what I figured but BOOST_RE_BUILD_DLL should not be defined for
> static lib builds - your example sets it for all build options, yes?

I think you're confused about the meaning of the lib rule. The lib rule used
in my example just defines a static library target. If you want to define a
dynamic library target, use the dll rule. If you want to define both with
the same base name, you can supply the suffix explcitly (this is
undocumented functionality which raw Jam supports and I have preserved):

{   # local scope for fastidious name protection
    local SOURCES = c_regex_traits c_regex_traits_common cpp_regex_traits
       cregex fileiter posix_api regex regex_debug
       regex_synch w32_regex_traits wide_posix_api ;

    lib libboost_regex$(SUFLIB) : ../src/$(SOURCES).cpp :
<include>$(BOOST_ROOT) ;
    dll libboost_regex$(SUFDLL[1]) : ../src/$(SOURCES).cpp
            : <include>$(BOOST_ROOT)
               <define>BOOST_RE_BUILD_DLL
               ;
}

Okay, this could be easier. The reason for $(SUFDLL[1]) is that the
$(SUFDLL) is a 2-element list to account for the generation of import libs
under Windows. We could add a new target rule that wraps up this
functionality:

# library target-base-name : sources : DLL-defines : requirements :
default-BUILD
#
# build static and dynamic libs from the same sources
rule library
{
    lib $(<)$(SUFLIB) : $(>) : $(4) : $(5) ;
    dll $(<)$(SUFDLL[1]) : $(>) : <define>$(3) $(4) : $(5) ;
}

# example:
library libboost_regex : ../src/$(SOURCES) : BOOST_RE_BUILD_DLL ;

I realize that this is probably more detail than you ever wanted to see, but
I don't think we'll ever get the build system to the neccessary level of
refinement if I am the only one who understands how it works ;-)

> >How you link to the runtime is independent of whether you're building a
> >static or dynamic library, right?
>
> Um OK, I think, I when I saw "dynamic" I thought it applied to the built
> library, not the runtime, my mistake.

It's important to look at the feature name as well as its value:
<runtime-link>dynamic

> OK, is it possible to produce a static lib with a dynamic runtime using
> this method?

Sure: that's what the lib rule does by default on platforms that support
dynamic linking with the runtime, since the default value of <runtime-link>
is dynamic.

Maybe it would be a good idea to rename the lib rule to "static-lib" or
"archive"?

-Dave