Re: [Boost-build] Boost.Jam problem with dependant includes

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-29 01:37:41

On Thursday 28 September 2006 23:16, Fabien Chêne wrote:
> Rene Rivera <grafikrobot_at_[hidden]> writes:
> > Ilya Sokolov wrote:
> >> Rene Rivera wrote:
> >>> Vladimir Prus wrote:
> >>>> Can we really handle macro sustitution with just patterns?
> >>>
> >>> No, but we can handle macro parsing with just patterns. For example:
> >>>
> >>> HDRSCAN =
> >>>    "^[ \t]*#[ \t]*include[ \t]+DEPENDENT_INCLUDE\([ \t]([^)]+).*$" ;
> >>>
> >>> Would handle the above case. Of course it would be more complicated to
> >>> handle the regular includes plus a bunch of additional macros. Hence
> >>> why we only handle the regular includes.
> >>
> >> see http://freetype.sourceforge.net/jam/changes.html#builtin-hdrmacro
> >
> > Interesting, but "Scan filename for #define directives and filter those
> > that do not define a potential filename (e.g., it discards macros with
> > parameters)." And rest of their examples indicates that it won't handle
> > the OPs use case. Or for that matter most of the use cases I'm familiar
> > with in Boost. Arbitrarily parsing algorithmic header dependencies is by
> > definition language dependent. So it's a rather hard/impossible problem
> > to solve generically.
>
> It is certainly hard to solve, but maybe that it's not impossible to
> emit a warning as an option when a dependency is silently ignored ?
> I mean modifying HDRRULE to not applied NOCARE on a missing dependency
> or something like this.

Ah, then then we'd need a mechanism to disable this warning on Boost, since 
users will object to getting 100 warnings ;-) 

- Volodya