Boost logo

Boost-Build :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-09-28 10:54:13

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

   "^[ \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.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at