[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why not #include "config.h"?

From: Steffen Dettmer
Subject: Re: why not #include "config.h"?
Date: Wed, 23 Sep 2009 11:26:33 +0200


thank you for the detailed explanations.

It seems my assumption (which could be a common one) that <> are
for system includes and "" are for user includes, essentially is

If I looked to the rigth place, the standard (ISO/IEC 9899:TC3
page 161) does not specify how this works (if I understand

   # include <h-char-sequence> new-line
  searches a sequence of implementation-defined places for a
  header identified uniquely by the specified sequence between
  the < and > delimiters, and causes the replacement of that
  directive by the entire contents of the header

    # include "q-char-sequence" new-line
  causes the replacement of that directive by the entire contents
  of the source file identified by the specified sequence between
  the " delimiters. The named source file is searched for in an
  implementation-defined manner.

On Tue, Sep 22, 2009 at 10:35 PM, <address@hidden> wrote:
> * Steffen Dettmer wrote on Tue, Sep 22, 2009 at 05:06:41PM CEST:
> > - with -I (and gcc), #include <config.h> is not correct but works
> >   anyway, because gcc searches system headers in user directories
> >   if it was not found in system directories
> Not AFAIK.  It works because automake adds -I. by default.

Yes, unfortunately it adds it.

>> - if #include <config.h> is really desired, I think for gcc it
>>   would be correct to use -isystem $(top_builddir)
> No, don't use -isystem.  It is not intended for this situation.

(yes sure, was an example only)

>> - other compilers may not distinguish that much or that flexible
>>   or not configurable where <file.h> is searched
> Which compiler(s) are you thinking of?  Thanks.

If I remember correctly, KEILs C51 COMPILER X4.13 (also 3.07,
5.02 and 6.14) had some limitations like that. I couldn't test
because at the moment I don't have a dongle here, because not
using it at the moment (and was never used with autoconf anyway).

I tested now gcc-2, gcc-3, gcc-4, CL.EXE-12, tcc 1.21 and all
work as you describe.

So at least in all practical relevant situations the
"implementation-defined places" of <> do work and have nothing to
do with system directories.

>> - on other compilers, #include <config.h> may not even work
>>   (when they use a fixed system directory and support no fallback
>>   search to user directories)
> Again, do you have examples?

I though even tcc, but I was wrong, at least for config.h. With
tcc a thing is that you can include e.g. string.h even if no such
file exists anywhere (built-in).

We had issues with a platform (toolchain) that had a config.h in
system includes (right beside string.h and so on). In the end we
renamed it and patched the include files to use the new name.

> > Could * please correct my assumptions?
> Quoting the SUSv3 manpage for c99:

Thanks for this citation. So it seems what I considered "system
and user directories" actually is "-I specified directories and
the directory where the compiled file is in".

> This means,
>  #include "config.h"
> would, even with
>  c99 -I. -I$(srcdir) -c $(srcdir)/foo.c
> try to open $(srcdir)/config.h before trying to open ./config.h.  That
> would be wrong, however unlikely it would be to have config.h files in
> both the build and the source tree.

Is this just unlikely? I though it would be forbidden, because
then it would be required to build with builddir != srcdir but I
though this is optional? Well, but a detail only.

Thanks a lot for you nice explanation. Now I will tell my team mates :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]