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

From: Ilya Sokolov (fal_delivery_at_[hidden])
Date: 2006-09-28 10:58:04

Rene Rivera wrote:
> Vladimir Prus wrote:
> 
>>On Thursday 28 September 2006 18:40, Rene Rivera wrote:
>>
>>>Fabien Chêne wrote:
>>>
>>>>After a discussion on fr.comp.lang.c++ about Boost.[Build/Jam], James
>>>>Kanze pointed out that dependant macros do not cause dependencies.
>>>>According to §16.2.4, the following code is legal C++, and Boost.Jam
>>>>don't care about toto.hpp as a dependency :
>>>>
>>>>cat toto.cpp
>>>>//------------------------------
>>>>#define DEPENDANT_INCLUDE( s ) #s
>>>>#include DEPENDANT_INCLUDE( toto.hpp )
>>>>//------------------------------
>>>>
>>>>I think the documentation is not clear enough about this problematic
>>>>limitation (the problem is the same with classic Jam).
>>>
>>>bjam (and jam) do not have a restriction as to what to consider a header
>>>include dependency. The restriction is in formulating a search criteria
>>>in Boost.Build (or Jambase, respectively).
>>><http://engineering.meta-comm.com/resources/cs-win32_metacomm/doc/html/jam/
>>>language.html#jam.language.variables.builtins.hdrscan>
>>>
>>>>Someone to confirm/infirm that ? If confirmed, is there a workaround ?
>>>
>>>The work around is to define the HDRSCAN (and/or HDRPATTERN) accordingly
>>>for the kinds of headers you want to handle. Except for Boost.Build2
>>>which sets the HDRSCAN in a somewhat more complicated, but more modular,
>>>manner. Is it Boost.Build2 you are asking about?
>>
>>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