Re: build system suggestions

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-02 07:55:21

From:  Vladimir Prus <ghost_at_[hidden]>

> David Abrahams wrote:
> > > Custom features can be implemented with:
> > >  1. Making variable CUSTOM_FEATURES name the file describing custom
> >> [snip]
> > I've been thinking of a different approach to customization. I thought
> > there should be a JAMPATH environment variable which tells the system
how
> > to find the build system files. You could then write your own
features.jam
> > which includes the boost one.
>
> This is ok for for me. But since it is desirable not to force users to
> populate project root with shadow version of every file, there should be a
> way to see if a file exists in project root and to include it only if
> present. But...does jam support "file exists?" querry?

Not exactly. Included files are treated as targets, and bound to
locations in the filesystem using SEARCH and LOCATE just like other
targets. You can also add grist as usual to distinguish files of the
same name. The following will look for bar.jam in the directories
my_dir_1/my_dir_2, then /usr/local, then whatever is given by
$(BOOST_ROOT).

SEARCH on <foo>bar.jam = my_dir_1/my_dir_2 /usr/local $(BOOST_ROOT) ;
include <foo>bar.jam ;

One way to allow optionally-supplied files (e.g. to make Jamrules
optional, or allow jamrules or JamRules as well) is to shadow the file
somewhere in the build system, and put that location at the end of the
SEARCH path. Of course, we could also just extend Jam's "C" source. It
turns out to be pretty easy.

> > Also, for quick specification of compiler features which really don't
apply
> > to more than one compiler, I'm thinking of supplying a <cxxflags> free
> > feature which allows you to add raw options to the command-line.
>
> 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.

> > > Say I've made 'unsigned-char' feature, and made it free feature. If
this
> > > feature is not mentioned in build variant, then targets will be
generated
> > > in something/unsigned-char-off/.... directory
> > [snip]
> > I agree that it's a bad thing. Do you have an example for me?
> Yes, see attachment.

OK, I'll have a look. That should be fixed.

> >> [snip]
> > > It should be quite simple to implement.
> >
> > If you are interested in working on Jam/Boost.Build development, let me
> > know. I've been meaning to check my latest work into CVS for some time
now;
> > I will do that and set you up to press forward with it.
>
> I'm interested -- I would like to use Boost.Build myself and is willing to
> help with its development, if my help can be of any use. Yet, I would like
to
> see the big picture:
> 1. I like Boost.Build "look and feel". Seems like it can be very usefull
when
> then few missing features are implemented.

Agree.

> 2. I don't like jam -- it's bad tool as it is, IMO. Moreover, looks like
the
> author considers jam to be almost finished.

"Bad" is a relative term. It's remarkably good considering its
simplicity and the amount of development effort that's gone into it
;-)

In theory, Perforce  hired someone to work on Jam and other
open-source projects in August, so I don't think they believe it's
done. I haven't seen or heard anything new from them in some time,
though, and I expect them to be much more conservative about changes
and features than I would like.

> 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 am subscribed to the Scons (they changed
the name slightly) developers' mailing list, but I still don't have a
complete picture of it.

> The questions, therefore, are:
> 1. Is it expected that jam as Boost.Build backend will be obsolete in
year,
> two, or five?

I think that as long as the following three conditions hold, Jam will
continue to be used for Boost.Build:

1. The boost membership strongly rejects the idea of requiring the
   installation/porting of anything seen as a whole language
   environment (e.g. Python). Never mind for a minute that Jam
   contains its own specialized language ;-)

2. One or more boosters are prodding the build system source code
   along

3. No superior prepackaged solutions exist.

> 2. Which are the final goals for Boost.Build. Will jam be modified as
needed,
> how many changes are needed, is compatibility with existing jam required,
> will compatibility with "official" jam prevent implementing of any good
> features?

Whoa, that's more than one question!

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

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

1. if the BINDRULE variable is set on a target, when the target is
   bound, the rule named by $(BINDRULE) is called with the target name
   and its location in the filesystem. This should be enough to handle
   the problem you mention in
   http://groups.yahoo.com/group/boost/message/15863.

2. Argument lists! I really wanted to increase the robustness of my
   Jam code (for example, to detect missing semicolons), but the
   amount of ugly Jam code required to check for valid arguments would
   have presented its own maintenance hassles. Instead, I built it
   into Jam. It was surprisingly easy.

3. A fix for the NT line-length limitation. It works for single-line
   commands only, and maintains backward compatibility.

4. Scripts for building debug versions of the Jam executable under NT,
   so I could get JIT debugging if/when Jam crashes.

Look in tools/build/test for Jamfiles which test the above features.

I would like to clean and rewrite much/all of the Jam code in the
build system to use argument lists, and use names different from those
in the built-in Jambase. I think if we had that, and some simple way
to get Jam to use our Jambase instead of the built-in one (e.g. an
environment variable), it could be mostly finished.

> , is compatibility with existing jam required,

IMO, it is important to support the existing Jam features and ruleset
in some way. One reason is that Jam bootstraps itself, and I don't
want to have to rewrite its bootstrap Jamfile.

> will compatibility with "official" jam prevent implementing of any good
> features?

I don't think it should have to, in any significant way. There are
always subversive ways of throwing new features in without disturbing
things too much.

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

-Dave