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
> > 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
> > 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
> HDRPATTERN =
> "^[ ]*#[ ]*include[ ]*[<\"]([^\">]*)[\">].*$" ;
> So it should be finding <...> includes.
> But, the headers that actually need to be searched are determined
> HdrRule rule, which gets the header search path from the HDRSEARCH
> as set on the source file.
> Generally, the HDRSEARCH variable is set to $(HDRS) $(h)
> $(h) is a directory used for generating intermediate headers (e.g.
> generated by lex/yacc).
> If your <> header search path isn't getting incorporated into
> $(STDHDRS), that could explain things. Otherwise, I may have
> bug in the build system (not unlikely). I would like to try to
> you've been doing - please send a pointer to the latest with
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk