Re: [jamboost] Re: Using bjam's builtin SHELL rule

From: Liam Routt (caligari_at_[hidden])
Date: 2005-09-28 01:42:01

Vladimir Prus wrote:
> > Respectfully, I would urge the team to consider this patch themselves.
> > It seem decidely odd to add a builtin command (with useful
> > functionality) that is hidden by pre-existing rules. And even if you
> > remove the compatibility rule you are still left with a piece of new
> > fucntionality sharing the same "word" with an existing default rule
> > (Shell), which can only lead to confusion. By using a different word
> > altogether you avoid all of those problems.
> 
> I'd prefer to remove the "SHELL" rule in Jambase. After all, it's 
> compatibility with some extra old version of Jam.

... which boost-jam has been compatible with up to now...
The SHELL builtin is a fairly recent addition, isn't it?

Anyone using boost-jam as standard jam will have seen no change in their 
processing of quite old jam files, as I understand it. Removing the rule 
would make the implementation incompatible with those old scripts.

Even if you do remove the rul you are still left with SHELL and Shell, 
which while syntactically legal, is confusing.

Again, as a I said before, this is a lot less of an issue for those who 
are not using Jambase, and I'm sure there are a lot of you out there. I 
fully accept that, and figure you will do what is best for your project, 
not what happens to make sense to me. :)

> > Obviously you are not using the default Jambase with BB, so this is not
> > an issue for your primary development, but it would be of use to those
> > who are leveraging off of your basic jam advances.
> 
> I'm sorry to say that, but unfortunately I'm not sure we can support using 
> bjam with stock Jambase in any reasonable way.

And yet that is the way it is distributed... I suppose in the recent 
releaess I have had to rename it to jam, haven't I (or provide a 
symlink) to get around bjam mode. But still, the Jambase is there, and 
jambase.c is compiled into the binary, so it is fundamentally part of 
it...

But again, I do see your point - bjam, and not jam, is your focus.

> Say, speaking of proposed 
> SHELL->COMMAND remane, we'd have to decide it's fine, apply patch, change 
> docs, and any code that might be using SHELL, and them some user might be 
> still unaware of the change and come pretty surprised and would ask where' 
> SHELL. I'm afraid I don't have much time for that.

Well, you could provide a pass-through rule for SHELL -> COMMAND for 
the bjam mode, so none of the non-Jambase users would notice a 
difference. And as you would not be removing SHELL from the Jambase 
side, you would simply be making available the funtionality described 
in the docs at the moment (which is hidden by the SHELL rule in Jambase) 
with a new name...
(jam_src/index.html indicates SHELL is a boost-added builtin, and
doesn't indicate it doesn't work in the non-bjam mode, nor are the 
compatibility rules mentioned anywhere in those docs, as far as I have 
found (although I think that compatibility is worth preserving, as I 
noted above))

> > As a followup question, I've noticed that the returned list has a
> > newline and a character (usually M or L?) appended to it. Is there a
> > particular reason for this (perhaps returning the status?)? Stripping it
> > off is not impossible (would be easier if MATCH recognised \n), but it
> > feels like an oversight in some way).
> 
> Are you using the most up-to-date version? There were a bug where random 
> character was added to result of SHELL, which was then fixed.

I'm using 3.1.11, as downloaded in tgz form from 
http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=72941

Is that not the most recent released version? Is there a better location 
to check?

> As for "\n" --
> well, I think it returns whatever the command outputs.

Not arguing that, really. It isn't useful within Jam, where you are not 
going to want a trailing \n, and there isn't any easy way to get rid of 
it (that I can see). It is a shame MATCH is limited in its regexp
implementation, but I can see how this is a minor issue in the greater 
scheme of things, and it is possible to work around the limitations.

Take care,

Liam
--
Liam Routt Ph: [phone]
Research Programmer caligari_at_[hidden]
Computer Science, Melbourne University (or liam_at_[hidden])