Re: [jamboost] Boost.Regex and warnings in general

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-23 02:50:34

On Wednesday 23 March 2005 10:11, Jürgen Hunold wrote:

> On Tuesday 22 March 2005 18:09, John Maddock wrote:
> > > recently, whenever I run "bjam", I get this:
> >
> > You mean whenever you build regex or something that depends upon it, not
> > whenever bjam is run I presume.
>
> Well, actually when you build anything that depends on boost with v2.
> This is due to the fact that Boost-Toplevel Jamfile.v2 has use-project
> rules for _all_ non-header-only libraries. 

Exactly.

> So V2 parses and checks these 
> projects. This bites me, too, because I use _none_ of those libraries...

Note that even if 'use-project' is modified to no load a Jamfile it refer too 
(which is theoretically possible), all users of Boost.Regex will get this 
warning. And unlike Boost.Python, it's possible to use Boost.Regex when the 
warning is issued, so users that don't want ICU will get annoyed.

> > > In general, we need some consistent policy about warning messages
> > > emitted by
> > > Boost.Build and Jamfiles. I'd favour either one-line warnings, or no
> > > warnings
> > > at all, because I don't see any obvious way to disable the warnings.
> > >
> > > Comments?
> >
> > If no message is output, it's rather a disservice to someone installing
> > Boost who would want to know that there are (optional) external
> > dependencies.
>
> Yes. These warnings should only appear when the stated libraries are
> actually _build_.
> Now, they are issued when these libraries are onle _referenced_ by some
> Jamfile which happens to have "use-project /boost $BOOT_ROOT" in it...

This is probably possible to fix, but them you'll get the warning whenever you 
use Boost.Regex, even though library is usable without ICU. 

Probably the right approach is either:

1. Boost has a top-level config.jam file that is included from Jamfile. When 
Boost.Regex is first built, it produces the big warning and appends some line 
to config.jam, indicating that the warning was emitted once. On subsequent 
invocations, the warning is not emitted.

2. Same as above, but user must manually edit config.jam to disable the 
warning.

3. Some initial "configure" step, which emits many warnings and disables the 
targets that can't be built. The configure step should be run once, of 
course.

- Volodya