Re: [boost] Re: build system suggestions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-10-02 08:41:49

David Abrahams wrote:

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

Got the idea.

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

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.

> > 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
> ;-)

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. Jam can update one target twice. Official one can't handle recursive 
includes correctly. There was a bug with NOCARE handling recenly. To many 
problems for a program created a long time ago. 

2. Jam's language is a way too simple, I think. 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.

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

The fact the there are only two commits to jam in 2001 strongly backs your 
expectations.

> > 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)? 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? 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 do users debug 
their build process, or profile its performance? Can the tool provide 
feedback on how much work it has done, and how much remains to be done? 

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

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

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

Maybe you're right. 

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

Regards,
Vladimir