Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-01 09:20:48


Hi Jurko,

> --- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> > I wonder, though, if we should issue an error if there are
> > several --build-system switches?
>
> I guess that would have to be a more general coding-standard
> decision. Are there any coding standards established for this
> project that relate to this? In general do you disallow multiple
> options or take the last one as valid. I see pros and cons for
> eather of these choices but nothing too important. I guess the most
> important thing would be to get it standardized and consistent
> across the system. Ofcourse any special switches that apsolutely
> need to be handled differently can easily be made to deviate from
> the standard (well, a simple comment would be useful too :-) ).

Nope, we don't have any standard for this. And BTW --help is the only family
of options that take argument. For all others, like --clean, there's no
question which one to use.

> > > 7. The IMPORT built-in rule is used in kernel/modules.jam with an
> > > extra fifth parameter LOCALIZE which I can not find documented
> > > anywhere and I have no idea what it does. Any hints?
> >
> > The rule which is localized will access variables from the module
>
> to which
>
> > it's imported. I've attaches a small example to illustrate the
>
> different,
>
> > which can be run with
> >
> > bjam -flocalization.jam
> >
> > This was undocumented for some time already, unfortunately.
>
> Ok, thanks! I get it now, but that one really needs documenting.
>
> :-)

True. Noted.

> I played with it a bit and gathered that the value of this
>
> fifth parameter is not important but only its existance. That is,
> if any value is passed as the fifth parameter then the new
> localization behaviour is triggered. Is this correct? Or are there
> any 'special' values that can modify this behaviour further?

No. Any non-empty string is "true" value and no special values exist.

> > > 8. A funny side effect of the help system. If you do
> > > bjam --help --help
> > > the help screen is displayed twice :-))
> >
> > Funny... but how to fix it. For example, should
> >
> > bjam --help doc --help doc
> >
> > produce help on "doc" twice, or not ;-)
>
> My bet would be on not. The help options already affect all of the
> help actions - whether triggered by parameters before setting those
> options or after. So I guess all the help parameteres should be
> processed first and only then should all the needed actions be
> triggered. But whether this behaviour can be implemented at all
> using the current parameter processing system - I can not tell. I
> can look into it later if you wish.

Let's start by solving the first issue you've raised about help system
(--help-all option). I'm waiting for Rene to comment on it, and if he's busy
will dive there myself.

- 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