Re: build system suggestions

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

--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
>
> I've some suggestions about build system and it seems their're not in
TODO.
> Moreover, they don't require any significant changes.
>
> 1. Custom features.
> Say I need to pass 'char is unsigned' option to the compiler. The most
clear
> way to accoplish this would be to allow for 'custom features' to be
provided.
> I don't think that changing existing toolset descriptions and features.jam
to
> anticipate any custom feature user might want is practically feasible.
>
> Custom features can be implemented with:
>  1. Making variable CUSTOM_FEATURES name the file describing custom
features,
>  (with some default)
>  2. Include $(CUSTOM_FEATURES) from features.jam and every toolset
>  description.
>  3. Check if duplicate features declaration work (maybe it works now,
haven't
>  tried this)
>  4. Somehow make flags declaration for various toolsets in custom features
>  file work. Options:
>   i) Make
>   flags borland CFLAGS ......
>   do nothing if $(gCURRENT_TOOLSET) is different from borland
>   ii) Instruct the users to emulate semantics of i) by hand
>
> I've actually implemented 1) 2) and 4) ii)

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.

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.

> There's another related matter: currently
>  flags something CFLAGS : -foobar
> sets -foobar flag unconditionally. It's good when, e.g. one wants to
disable
> some odd warning in compiler without touching the build system:
> you put one string in custom features file and it works. Probably this
> behaviour should be documented.

Yep. I used that in several toolset definitions.

> 2. Free features.
> 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

No, that shouldn't happen. If it does, it's a bug. Normally, free features
are not supposed to generate subvariant directories.

> , and, of cause,
> unsigned-char-on directory will never be generated as the feature is free.
> Can we get rid of this directory completely? IMO, it only makes pathes
longer
> and confuses people.

I agree that it's a bad thing. Do you have an example for me?

> 3. Borland toolset.
> Command lines for the compiler contain -w- flag, which disables warning.
Why
> is it so? I've already got several bugs because of that.

I'm not an expert with the Borland compiler; I've been expecting someone
like you to come along and make it right ;-)

> 4. Command line length limitation
> Is there any plans to allow for response file on toolset which suport
them?

Yes, but all Boost.Build development is on the back burner at the moment
while I seek employment ;-)

Anyway, the current situation is this:

I have a version of the Jam source which gets around the limitation for
single-line build commands. I plan to use this feature for Cygwin/GCC, which
doesn't support response files. For other compilers, I plan to try the
response file route.

David Turner is looking into longer-term solutions to the problem (i.e. ways
to simply lift the restriction altogether).

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

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

-Dave

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

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