Re: [boost] Re: build system suggestions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-10-02 02:53:36

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?

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

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

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

The questions, therefore, are:
1. Is it expected that jam as Boost.Build backend will be obsolete in year, 
two, or five?
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?
3. If jam will be eventualy obsoleted, what is the transition path to a 
different tool?

> > Related question is relative pathes:
> > I used to get command line full of inline directives many of which refer
>
> to
>
> > the same place, only using different relative names. Some calls to
> > simplify-path-tokens will fix the situation.
>
> One problem with simplify-path-tokens right now is that it doesn't use
> knowledge of the path from the project root to the current subproject.
> Thus, paths like ../../foo/bar/baz/mumble.c will never be simplified to
> baz/mumble.c
> Fixing that will improve things.

Well, yes! I even made a local change to that effect.

-- 
Regards,
Vladimir