Hi,
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
wrong.
If I looked to the rigth place, the standard (ISO/IEC 9899:TC3
page 161) does not specify how this works (if I understand
correctly):
# 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, <Ralf.Wildenhues@xxxxxx> 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 :-)
oki,
Steffen
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
