Re: [boost] Re: Build Success on Boost.Python

From: David Turner (david.turner_at_[hidden])
Date: 2001-07-18 11:24:13

Hello all,

David Abrahams a écrit :
> 
> Ulli,
> 
> the problem with this approach is that the Jam architecture does not allow
> the running of shell commands at any point where this information can be
> used. The info would have to be located in an environment variable at the
> time Jam is invoked in order to be interpreted by any of the Jam code.
> 
> I have often wished for some way to call into the system during the rule
> evaluation phase, so I could find out things like "which version of Python
> is installed", etc., but this would be a fairly significant change to the
> Jam architecture and would certainly invite abuse. Maybe the best thing
> would be to invoke Jam from a script that does a few of these jobs and
> passes the results in variables on the Jam command-line. On the other hand,
> there's something to be said for being able to do the whole job with a
> single tool. I wonder what David Turner thinks of this?
> 
The solution would be to implement a new built-in (let's name it "EXEC" or "SHELL")
that would return the output of a shell command like in:

   uname = [ EXEC "uname -a" ] ;

the built-in SUBST could also be used to filter the fields then :o)

The problem is that we need to redirect the standard output to a Jam
string (if it's small enough). GNU Make already provides something similar
with its "shell" function, but the Win32 implementation is definitely
_not_ pretty.

And I don't know if that's easy to implement in the Jam architecture
It seems that we'll need some more sophisticated execution back-end anyway
to be able to deal with long command lines on NT.. I'll try to research this
question next week (after a new FTJam release though..)

Regards,

- David