Boost logo

Boost-Build :

From: Zbynek Winkler (zw-bjam_at_[hidden])
Date: 2005-01-26 07:27:26

Vladimir Prus wrote:

>all most of you know, Jam is sensitive to spaces. A typical first user's error
> exe a : a.cpp;
>The attached patch attempts to fix that. Now, whenever bjam sees ';' outside
>of quited string, it terminates the current token.
It was my first user error too ;-). However, the rule is simple and
works for all cases - just put spaces everywhere. I think there is a
certain beauty to the simplicity. I'd suggest instead to detect this
particular case but return error saying that this is the most often
first time error and that spaces are needed everywhere. I think it would
help the users more in this way...

>It would be good to handle other symbols ( '[', ']', ':' ) in the similar way,
So currently any character can be a part of string as long as there are
no spaces in it? Or what is the exact rule? I don't see it in the
documentation :(. I think it should be as understandable as possible -
so either go with "no special characters outside of nonquoted string"
(like all the other languages I know) or leave it the way it is (and
document it).

>but unfortunately, they can appear inside variable accesses, for example:
> gFILES($(targets[1])) = fff ;
>During scanning, it's not easy to find if we're inside variable access or
>not, so those symbols can't be safely handled.
Unfortunatelly, I do not understand what the problem is here. Going with
the least surprise behaviour I'd say that 'targets' is an array, we take
item with index '1' and give that as a parametr to function call of
'gFILES', take its return value and assign 'fff' to it. But then it
would be php and not jam and there would be no problem with the
scanning... Is it just me or is the jam language "strange"? I am eagerly
waiting for the python port... ;-)

>Opinions? Should I commit this?
All is above.


Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at