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 :
>>>>#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).
>>>>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.
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