From: David Abrahams (dave_at_[hidden])
Date: 2007-03-19 18:25:11
on Mon Mar 19 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
> Looking at python.jam, I see this:
> includes ?= [ path-to-native $(:E=python$(version):R=$(:E=include:R=$(prefix))) ] ;
> and I have not the slightest clue what this is supposed to do. I suspect it
> concatenates, $(prefix), "include" and "python$(version),
Yes, bingo! Maybe it was clearer than you thought?
> but the meaning of $(:E) syntax is not obvious for me,
is the same as
local tmp = xxx ;
> and use of nested expansions does not seem clear.
It seemed clearer to me than writing it in multiple steps.
> Would it be better to stay away from arcane features of bjam, rather
> than use them like that?
Perhaps. However, I understand what they do, and I know they will
work with what the user writes in user-config.jam whether he uses
native path syntax or just sticks with forward slashes.
I've never been able to get comfortable with the use of "normalized"
paths as in path.jam; I'm always afraid of losing track of whether I'm
working with native or "normalized" syntax, and I end up with a
dilemma: if I write functions that only accept "normalized" paths, I
can't expose them to end-users without explaining how to form such
paths on windows. If I write functions that accept native paths and
translate them into normalized paths, I can't call them from other
internal functions that use normalized paths without first translating
the paths back to native. So I've never found a way to use path.jam
that's both consistent and forgiving.
In general I think $(X:Y=...) is an arcane syntax, but once you learn
what it does, it's not too hard to read. The same applies to
$(:E=...), and it's actually a pretty natural way to view what happens
with bjam variable expansion. After all, wouldn't you expect
local x ;
to yield "foo"? Since x is empty, it seems obvious to me that
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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