Re: [boost] Re: build system suggestions

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-02 19:58:48

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> > > Ok too. I think some variable (DEFAULT_REQUIREMENTS?) might be
inveneted,
> > > which will allow to conveniently set options, e.g.
> > > DEFAILT_REQUIREMENTS = <borland><*><cxxflags>-K ;
> >
> > How do you envision this being used? I'm still not clear on what
> > you're trying to accomplish.
>
> Unless I miss something, in order to make all the exe and lib targets with
> particular feature, you need to mention it in requirements for every
target.
> I'm trying to avoid this.

Well, you can set the feature up as part of BUILD if it isn't really a
requirement.

Do you envision that DEFAULT_REQUIREMENTS is overridden by the manual
specification of any requirement?

Do you envision that DEFAULT_REQUIREMENTS is a per-project setting, so that
if I build part of Boost as a dependency of MyProject, MyProject's
DEFAULT_REQUIREMENTS don't affect the requirements of the Boost component?

> There are two matters which I don't like
> 1. Creation of dependence graph is done in an odd way. It would be much
> better if e.g. Depends rules was taking a third argument -- name of
updating
> action.

#1:
rule depends ( sources + : targets + : action )
{
    DEPENDS $(sources) : $(targets) ;
    local ignored = [ $(action) $(sources) : $(targets) ] ;
}

# or, without argument lists
rule depends
{
    DEPENDS $(<) : $(>) ;
    local ignored = [ $(3) $(<) : $(>) ] ;
}

#2: Why? It seems to me that if you can build the functionality you want in
terms of primitives, it's better to have the primitives.

> Jam can update one target twice.

If you mean that there can be multiple actions associated with updating a
target, that can actually be useful. I use it for expected-failure tests. It
could be useful in other ways, too.

> Official one can't handle recursive
> includes correctly.

Okay, but I fixed that.

> There was a bug with NOCARE handling recenly.

It wouldn't be the first time a mistake slipped into a release.

> To many
> problems for a program created a long time ago.

BTW, that long list of complaints is more than one item. You seem to keep
doing that...

> 2. Jam's language is a way too simple, I think.

I agree, meaning I wish that the language was more powerful. Still, I've
also found that I can write the primitives I need, and they run fast enough.
I built a lot of primitives (including sort) for Boost.Build. It should be
easy to build lots more now that we have the SUBST rule (e.g. arithmetic, if
you need it). If they're too slow, we can easily move them into 'C' code.

> Some time ago, to remove the
> last element from a list, I had to reverse it, remove the first and
reverse
> it again. I'm not sure that the language will be adequate for a long time.

# untested
rule remove-last ( list + )
{
    if $(list[2])
    {
        return $(list[1]) [ remove-last $(list[2-]) ] ;
    }
}

>
> > > 3. Looking at http://software-carpentry.codesourcery.com/sc_build, I
> > > think that not all features that suggested are there can be
implemented
> > > with current Jam.
> >
> > Which ones, in particular?
> I quote:

> How does the tool handle changes in the dependency specification itself
(e.g.
> the makefile)?

We could make targets depend on their Jamfiles.

> Can the tool use techniques other than timestamps (e.g.
> checksums or differencing) to make sure only the files that have really
> changed spawn build actions?

How important is this?

> Does the tool allow users to specify more than
> one way to resolve a dependency, e.g. patching a binary in place rather
than
> recompiling an entire library if certain criteria are met?

How important is this?

> How do users debug
> their build process, or profile its performance?

Is that a feature?

> Can the tool provide
> feedback on how much work it has done, and how much remains to be done?

How important is this?

> > > Which are the final goals for Boost.Build.
> >
> > Personally, I want a portable tool which I can use for build/test/debug
> > (and possibly installation) with a wide variety of compilers. I want
> > to be able to easily fit together multiple large projects with
> > automatic resolution of dependencies across projects (e.g. just plug
> > the boost project tree into your project, and make your executable
> > depend on $(BOOST_ROOT)/libs/regex/build/regex - the correct
> > subvariant will be built and linked in). I want it to be easy to use
> > for developers interested in trying variations on a build, and also by
> > people who "just want to build boost".
>
> Good goals indeed. But how will you decide if a particular feature should
be
> implemeted? Take for example the questions above.

I will implement the features neccessary for Boost and important to me
personally.
I will happily accept features that others want to implement.

> > > Will jam be modified as needed, how many changes are needed
> >
> > I think all of the /strictly/ neccessary changes to the 'C' source
> > have already been made (see the boost CVS tree), but if others are
> > needed it shouldn't be hard. I already added the following:
> > [snip]
>
> How will problem with building the same target several time be handled? It
> can be worked around in Boost.Build code, but I find it to be rather bug
in
> jam.

I'm not sure there is a problem. If there is, I'm sure I don't understand
the problem. Maybe you could explain in more detail.

And finally, do you have a proposal for how it should be handled?

> > > 3. If jam will be eventualy obsoleted, what is the transition path to
a
> > > different tool?
> >
> > Sheesh, ready to give up on Jam already! Do you have some other tool in
> > mind?
>
> If I had, I'd have asked if jam will be obsolete in week, month or year
:-).
> I find Software Carpentry's decision to use Python everywhere to be very
> reasonable and can only hope that build system backend will eventually be
> implemented in Python. But this depends on other's position.

Scons is moving along nicely, but as we've said Boost has rejected it, at
least for the time being. Although Python is much more powerful than Jam, I
think that the Scons front-end will be less user-friendly than Jam's in many
ways. The momentum seems to be headed toward using pure Python syntax for
Sconscript files, which means lots of quoting, commas, list delimiters, and
calls to string.join().

-Dave

===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams_at_[hidden]
===================================================