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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-13 12:50:55

My last message was mistakenly cut off (sorry!)

----- Original Message -----
From: <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
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.

Note that AFAICT, Jam does not support separate search paths for "" and <>
headers. I think this is a good candidate for a feature enhancement.

-Dave