Re: How to force location of headers

[James K. Lowden]

On Sat, 14 Apr 2012 13:39:04 -0700
Russ Allbery <address@hidden> wrote:

> "James K. Lowden" <address@hidden> writes:
> > Russ Allbery <address@hidden> wrote:
> 
> >> "" is primarily a source of bugs and annoyances
> 
> > Based on what?
> 
> Problems just like the one on this thread, or the breakage Debian saw
> with multiarch and headers that relied on "", or similar problems
> that we've seen over the years with software using -I- to try to work
> around problems with "".  I've also seen it cause problems with
> non-recursive make and with VPATH builds with different compilers
> that disagreed over what the local directory is for "" in different
> situations.

Ah, VPATH.  Don't use it, always found better ways.  

Portability issues, hmm.  I see the standard doesn't define exactly
where "here" is, where #include "" looks before consulting the regular
search path.  Every compiler I've ever used defined "here" as "the
directory in which the source file resides", irrespective of object
location or cwd.  

The project I maintain, FreeTDS, uses "" includes quite a bit:

$ find . -name \*.c | xargs grep '#include.*"' | wc -l
     513

and has done for many years.  It's never caused anyone to complain
about it on the message list.  But we *do* #include <config.h> because
of course it's never in the same directory as the .c file.  And we make
sure the autotools output can be processed by BSD and GNU make.  

Debian has packaged FreeTDS for a long time.  We've made changes at the
packager's behest.  Include file notation never came up.  

I don't doubt what you say about your own experience.  I do doubt that
"" is the real culprit given all the shenanigans and interpolation that
go into crafting and producing a Makefile.  I certainly wouldn't want
to extrapolate from some rare experience -- not carefully isolated,
unless I misunderstand, from all other possibilities -- to the general
case that it's not perfectly safe and useful in most circumstances.  

--jkl