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

From: Fabien Chêne (fabien.chene_at_[hidden])
Date: 2006-09-28 15:16:15

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.

-- 
Fab