Re: Boost.Build - #include <> vs. ""

From: williamkempf_at_[hidden]
Date: 2001-07-13 13:08:53

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> My last message was mistakenly cut off (sorry!)
> 
> ----- Original Message -----
> From: <williamkempf_at_h...>
> To: <boost_at_y...>
> Sent: Friday, July 13, 2001 11:00 AM
> Subject: [boost] Boost.Build - #include <> vs. ""
> 
> 
> > I've just noticed something strange using the Boost.Build system.
> > Used to be when I changed a header file in Boost.Threads the build
> > system realized this and forced a compile for any source files 
that
> > included them.  Today I noticed that this was no longer working.
> > With a little experimentation I discovered that when the header is
> > included with quotes ("") it considered it a dependency but when
> > included with angle brackets (<>) it wasn't.  I don't know if this
> > changed in the Boost Jam stuff or changed because we've switched 
to
> > using FTJam, so I don't know the cause of this change.
> 
> It's probably a boost build system thing.
> Headers are searched for based on a regular expression defined like 
this in
> allyourbase.jam:
> 
>   HDRPATTERN =
>         "^[     ]*#[    ]*include[      ]*[<\"]([^\">]*)[\">].*$" ;
> 
> So it should be finding <...> includes.
> 
> But, the headers that actually need to be searched are determined 
by the
> HdrRule rule, which gets the header search path from the HDRSEARCH 
variable
> as set on the source file.
> 
> Generally, the HDRSEARCH variable is set to $(HDRS) $(h) 
$(STDHDRS), where
> $(h) is a directory used for generating intermediate headers (e.g. 
those
> generated by lex/yacc).
> 
> If your <> header search path isn't getting incorporated into 
$(HDRS) or
> $(STDHDRS), that could explain things. Otherwise, I may have 
introduced a
> bug in the build system (not unlikely). I would like to try to 
debug what
> you've been doing - please send a pointer to the latest with 
instructions.

Just using the Jamfiles from Boost.Threads (CVS branch "thread-
initial").  I think you're right about it being a path thing.  A 
little more experimentation has shown that the choice of "" and <> 
really don't make a difference (I thought it did because I tested 
changing one #include, which happened to be for timeconv.inl, a file 
local to the source files).  The headers in /boost/thread can be 
modified and this won't trigger a rebuild of source files that 
include them.  This did work for me in the past, but I can't tell you 
precisely when the behavior changed.

It will be nice to get this working again, but the main point of my 
post was to discuss the policy on which form to use in source.  Some 
tools do act precisely in the manner that I though Boost.Build was 
working here.

Bill Kempf