Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-24 00:21:45


Michael Stevens wrote:

> > Yes, I think this might be the right solution. We also have to figure out
> > what to do with the shell -- I've just tried the "distcc g++" command and
> > shell barks, just like Jürgen has said.
>
> Yep the "distcc g++" gets used as the executable name (what would be
> argv[0]). I think the general solution to this would be to make 'command'
> n-element. That way the first element (the acutal command in any prefix)
> can have spaces in and be wrapped in "" in the action. The remaining
> elements (command line arguments to the prefix command can be used as they
> are in the action. I think this would work for all environments and shells.
> The n-th element would have to be the command from which the tool path is
> derived which may be a little resticting.

I think this solution is fine, except I think it's reasonable to quote *all*
elements of 'command'. Just in case ;-)

> > Well, we can state in docs that some toolset interpret "version"
> > specially, though it's a bit backward, after making sure that all toolset
> > interpret "command" in the same way ;-)
> >
> > I'm puzzled.
>
> I guess msvc as a special case would be reasonable solution.
> To puzzle you a bit more I have another multi-element solution! If
> 'version' is n-element then we can define the first as the only one which
> has semantic meaning to the toolset. The rest are simply freeform and the
> whole lot are concatenated together to provide the version string used as
> the build target.

I though about saying this in docs: "if you want some version-specific
behavior, version should be in form X.X-whatever, where X is digits". BTW, I
think this is not msvc-specific. For example, g++ 3.4 added support for PCH
(which I might add to gcc.jam soon). Of course, V2 should know it works with
3.4 to enable it.

- Volodya

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk