Re: Questions regarding jam + boost

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-10 07:41:08

CC'ing this to the jamboost list where it belongs
(jamboost_at_[hidden], news://gmane.comp.lib.boost.build).

Jens Maurer <Jens.Maurer_at_[hidden]> writes:

> Hello David,
>
> I'm just making sure that Windows doesn't overtake Linux in
> terms of successful tests.

Good idea, and nice to have you back!

> It would be helpful if I could call an external program
> (gcc in this case) and get stdout back into a Jam variable,
> similar to the Bourne shell
> var=`my_program_echos_something`
>
> That way, I want to find out the gcc version number to
> plug in -fabi-version=0 for gcc 3.3 and above.

Yes, everyone would like this, but it isn't implemented in the Jam
core. Care to volunteer? We'd like to have a Win32 implementation
as well, which is not a huge challenge for NT but might be much
harder for legacy OSes like Win98. Maybe the solution for Win98
users is "install cygwin"; I don't know.

> Another remark: I notice that all toolsets allow
> for its path to be configured, but not the name of
> the actual compiler driver invoked. 

That's not universally true (see gcc) but it's true for some BBv1
toolsets.

> This seems reasonable for most Windows-based software, that puts
> itself into a fresh path everytime it is installed.
>
> Under Unix, I can have three gcc versions installed
> in /usr/local that then differentiate via either
> -V x.y.z option or via a different name for the
> compiler driver executable.
>
> In general, I'd expect people who want a different
> compiler setup to produce a wrapper program/script
> in a well-known location such as /usr/local/bin
> and perform all the necessary configuration in the
> shell script. Of course, that requires that I am
> able to define the name of the compiler driver.

That's why we have the GXX variable. Is it not working?

In BBv2 we have much better support for building with multiple
toolset versions.

> Having a wrapper shell script allows that particular
> compiler setup/config to be run independently of boost
> or jam, for example when compiling non-boost libraries
> or programs, and still be link-compatible with boost-
> compiled libraries.

Sure, I understand that.

> Here are some application areas:
>
> - Have como with libcomo and stlport
> named como-libcomo and como-stlport ,
> the rest of the configuration is within the
> two shell scripts.

I don't believe users should have to set up scripts for combinations
such as that one. Boost.Build should be able to combine a the como
and stlport toolsets for you. I'm pretty sure v2 takes care of this.

> - Have different gcc versions (already works)
>
> - Have different backend C compilers for como.

That's certainly achievable even with v1, but not the way that the
como toolset development has proceeded up 'til now. I've tried a few
times to suggest that como should use 

extends-toolset $(backend) ;

but it's hard to criticize people who are actually willing to devote
effort to getting como working for doing what they're more
comfortable with.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com