Why <config.h> and not "config.h" ?

Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Emacs sources use the idiom

#include <config.h>

Is there a specific reason for this? Usually the curly braces are for
headers that live outside the project. Some code analysis tools assume
that. And some compilers (including gcc, AFAIK) use a different
procedure for locating headers surrounded by curly braces, which may
produce unexpected results for headers included from config.h.

Any objections to replacing <config.h> and <epaths.h> with "config.h"
and "epaths.h" ?

Re: Why <config.h> and not "config.h" ?

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> #include <config.h>
> Is there a specific reason for this?

I think this was discussed recently, and I seem to recall that the
reason given was that "config.h" doesn't work if the user tries to build
with an out-of-tree object directory _after_ having previously built in
the source tree (without an intervening "make distclean" in the source
dir).

Seems very silly to me ("don't do that!") but ...

-Miles

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> I think this was discussed recently, and I seem to recall that the
> reason given was that "config.h" doesn't work if the user tries to build
> with an out-of-tree object directory _after_ having previously built in
> the source tree (without an intervening "make distclean" in the source
> dir).

Thanks.

BTW, following that logic, shouldn't buildobj.h be included with curly
braces as well?

> Seems very silly to me ("don't do that!") but ...

At this point I wonder how dangerous is to make that (an out of source
build after an in-source build) since the out of source build puts lots
of products on the source tree directory (.el, .elc, DOC...) Maybe those
are identical on most cases, but think on the possibility of a bug on
the Elisp machinary of the emacs executable created by one of the
builds, being masked by the .el[c] files created by the other.

So I agree that "don't do that" should be the right answer.

Re: Why <config.h> and not "config.h" ?

[Jan Djärv]

Óscar Fuentes skrev 2010-07-28 05.25:
> Miles Bader<miles@gnu.org>  writes:
>
>> I think this was discussed recently, and I seem to recall that the
>> reason given was that "config.h" doesn't work if the user tries to build
>> with an out-of-tree object directory _after_ having previously built in
>> the source tree (without an intervening "make distclean" in the source
>> dir).
>
> Thanks.
>
> BTW, following that logic, shouldn't buildobj.h be included with curly
> braces as well?

Yes, I think it should.

>
>> Seems very silly to me ("don't do that!") but ...
>
> At this point I wonder how dangerous is to make that (an out of source
> build after an in-source build) since the out of source build puts lots
> of products on the source tree directory (.el, .elc, DOC...) Maybe those
> are identical on most cases, but think on the possibility of a bug on
> the Elisp machinary of the emacs executable created by one of the
> builds, being masked by the .el[c] files created by the other.

That doesn't happen.  elc-files are portable, and DOC should be also.
elc-files are in-tree even with an out-tree build, that is one of the nice 
things, not having to do make bootstrap all the time.

But for the most part, what starts as an in-tree build gets moved to an 
out-build tree, mostly because a bug fix became a longer project than just the 
simple quick-fix.

>
> So I agree that "don't do that" should be the right answer.
>

Considering that <> enables a real use-case and "" does not, and the fact that 
using "" gives exactly no benefits what so ever, please stick to <>.  It is 
not even less to type.  I can't imagine any reason for switching now.

	Jan D.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

>>> Seems very silly to me ("don't do that!") but ...
>>
>> At this point I wonder how dangerous is to make that (an out of source
>> build after an in-source build) since the out of source build puts lots
>> of products on the source tree directory (.el, .elc, DOC...) Maybe those
>> are identical on most cases, but think on the possibility of a bug on
>> the Elisp machinary of the emacs executable created by one of the
>> builds, being masked by the .el[c] files created by the other.
>
> That doesn't happen.  elc-files are portable, and DOC should be also.
> elc-files are in-tree even with an out-tree build, that is one of the
> nice things, not having to do make bootstrap all the time.

As explained above, if the .elc files are corrupted by a buggy Emacs or
a buggy Emacs ends using healthy .elc files, by sharing the produced
.elc/.el files among several builds you are hiding a bug. Mixing the
products of different builds is never a good idea.

[snip]

>> So I agree that "don't do that" should be the right answer.
>>
>
> Considering that <> enables a real use-case and "" does not, and the
> fact that using "" gives exactly no benefits what so ever, please
> stick to <>.  It is not even less to type.  I can't imagine any reason
> for switching now.

Maybe is my hideous English, but as explained on my original message <>
is giving me problems with some tool.

Re: Why <config.h> and not "config.h" ?

[Andreas Röhler]

Am 28.07.2010 04:23, schrieb Óscar Fuentes:
> Emacs sources use the idiom
>
> #include<config.h>
>
> Is there a specific reason for this? Usually the curly braces

Hi,

just a language question, not to get non-native english speakers -as you 
and me :-) bewildered.
Does "<...>" really mean curly?

IMHO these "{...}" are curly...

Do I misunderstand something?

Best regards,

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/




>   are for
> headers that live outside the project. Some code analysis tools assume
> that. And some compilers (including gcc, AFAIK) use a different
> procedure for locating headers surrounded by curly braces, which may
> produce unexpected results for headers included from config.h.
>
> Any objections to replacing<config.h>  and<epaths.h>  with "config.h"
> and "epaths.h" ?
>
>
>
>    

Re: Why <config.h> and not "config.h" ?

[Jan Djärv]

2010-07-28 08:46, Óscar Fuentes skrev:
> Jan Djärv<jan.h.d@swipnet.se>  writes:

>> That doesn't happen.  elc-files are portable, and DOC should be also.
>> elc-files are in-tree even with an out-tree build, that is one of the
>> nice things, not having to do make bootstrap all the time.
>
> As explained above, if the .elc files are corrupted by a buggy Emacs or
> a buggy Emacs ends using healthy .elc files, by sharing the produced
> .elc/.el files among several builds you are hiding a bug. Mixing the
> products of different builds is never a good idea.

Didn't you read what I wrote?  Out-of-tree builds use the *SAME* elc files, 
those located in the tree.  Adding another out-of-tree build does not remake 
the elc-files.  That is one of the strong reasons to use out-of -tree builds 
for different configurations.

BTW, I used Emacs for more than 20 years and have yet to see a corrupted elc-file.

>
> [snip]
>
>>> So I agree that "don't do that" should be the right answer.
>>>
>>
>> Considering that<>  enables a real use-case and "" does not, and the
>> fact that using "" gives exactly no benefits what so ever, please
>> stick to<>.  It is not even less to type.  I can't imagine any reason
>> for switching now.
>
> Maybe is my hideous English, but as explained on my original message<>
> is giving me problems with some tool.

Some code analysis tools is too vague.  We are building Emacs right now 
out-of-tree.  If you are going to impose a change on that process again just 
after it was changed recently, you have to come up with something better than 
that.  As for the gcc thing, that is intentional, it is how it is supposed to 
work.

	Jan D.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Andreas Röhler <andreas.roehler@online.de> writes:

> just a language question, not to get non-native english speakers -as
> you and me :-) bewildered.
> Does "<...>" really mean curly?
>
> IMHO these "{...}" are curly...
>
> Do I misunderstand something?

You are right. `<>' are usually called "angle brackets."

Re: Why <config.h> and not "config.h" ?

[Yavor Doganov]

Óscar Fuentes wrote:
> Emacs sources use the idiom
> 
> #include <config.h>

The Autoconf manual recommends this practice.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> As explained above, if the .elc files are corrupted by a buggy Emacs or
>> a buggy Emacs ends using healthy .elc files, by sharing the produced
>> .elc/.el files among several builds you are hiding a bug. Mixing the
>> products of different builds is never a good idea.
>
> Didn't you read what I wrote?  Out-of-tree builds use the *SAME* elc
> files, those located in the tree.  Adding another out-of-tree build
> does not remake the elc-files.  That is one of the strong reasons to
> use out-of -tree builds for different configurations.

Yes, I read what you wrote. It seems that you are not trying to
understand what I say, though.

The fact that several builds share the same .elc files is, precisely, a
potential source of problems. If you can't see that, well, lucky you,
because then it is clear that you never experienced a problem caused by
a setup like that.

> BTW, I used Emacs for more than 20 years and have yet to see a
> corrupted elc-file.

Corrupted in any sense? Is the byte compiler so robust that it never
miscompiled an .el file on 20 years?

>>> Considering that<>  enables a real use-case and "" does not, and the
>>> fact that using "" gives exactly no benefits what so ever, please
>>> stick to<>.  It is not even less to type.  I can't imagine any reason
>>> for switching now.
>>
>> Maybe is my hideous English, but as explained on my original message<>
>> is giving me problems with some tool.
>
> Some code analysis tools is too vague.

Are you suggesting that I'm making up the issue? Or maybe the issue is
irrelevant to you because it doesn't affect the tools you use?

> We are building Emacs right now out-of-tree.

No, you are building on a mixed setup, both out of tree and in-tree.

Anyways, if you are building out of tree, there is no problem with the
change because, as Miles explained, the angle brackets are used
precisely for supporting simultaneous out of tree and in-tree
builds. Removing the angle brackets is no problem for simultaneous out
of tree builds.

> If you are going to impose a change on that process again just after
> it was changed recently, you have to come up with something better
> than that.

Here we go again. No matter how small is the change one proposes,
somebody will extract terrible cosequences from it, or refuse to
evaluate the benefits dismissing it as useless, or both.

> As for the gcc thing, that is intentional, it is how it is
> supposed to work.

Yes, I know, I was caught there. AFAIK the algorithm used by GCC assumes
that angle brackets are for system headers.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Yavor Doganov <yavor@gnu.org> writes:

>> Emacs sources use the idiom
>> 
>> #include <config.h>
>
> The Autoconf manual recommends this practice.

Yes, for the very same reason Miles explained. Quoting from the manual:

"With the appropriate -I option, you can use ‘#include
<config.h>’. Actually, it's a good habit to use it, because in the rare
case when the source directory contains another config.h, the build
directory should be searched first."

I'll emphasize the phrase "With the appropriate -I option." Otherwise
having a config.h on the source directory in a out of tree build is
asking for trouble.

Re: Why <config.h> and not "config.h" ?

[Jan Djärv]

2010-07-28 09:35, Óscar Fuentes skrev:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>>> As explained above, if the .elc files are corrupted by a buggy Emacs or
>>> a buggy Emacs ends using healthy .elc files, by sharing the produced
>>> .elc/.el files among several builds you are hiding a bug. Mixing the
>>> products of different builds is never a good idea.
>>
>> Didn't you read what I wrote?  Out-of-tree builds use the *SAME* elc
>> files, those located in the tree.  Adding another out-of-tree build
>> does not remake the elc-files.  That is one of the strong reasons to
>> use out-of -tree builds for different configurations.
>
> Yes, I read what you wrote. It seems that you are not trying to
> understand what I say, though.
>
> The fact that several builds share the same .elc files is, precisely, a
> potential source of problems. If you can't see that, well, lucky you,
> because then it is clear that you never experienced a problem caused by
> a setup like that.

As I said, it is a feature not having to run make bootstrap in every build 
tree.  I usually have five of them (Gtk, Lucid, Motif/Lesstif, X, no-X).

>
>> BTW, I used Emacs for more than 20 years and have yet to see a
>> corrupted elc-file.
>
> Corrupted in any sense? Is the byte compiler so robust that it never
> miscompiled an .el file on 20 years?

No, I read on this list of bytecompiler errors from time to time.  They seem 
to be few and far between though.  I haven't experienced it though.

>
>>>> Considering that<>   enables a real use-case and "" does not, and the
>>>> fact that using "" gives exactly no benefits what so ever, please
>>>> stick to<>.  It is not even less to type.  I can't imagine any reason
>>>> for switching now.
>>>
>>> Maybe is my hideous English, but as explained on my original message<>
>>> is giving me problems with some tool.
>>
>> Some code analysis tools is too vague.
>
> Are you suggesting that I'm making up the issue? Or maybe the issue is
> irrelevant to you because it doesn't affect the tools you use?

No, I don't think you are making up things, there are a lot of buggy tools out 
there.  But which tools are we going to make this change for?  Are they free 
and generally useful for all developers?  Most analysis tools I've used does 
not have any problem with <> and "".  You usually can pass -I. to them if that 
is needed.

>
>> We are building Emacs right now out-of-tree.
>
> No, you are building on a mixed setup, both out of tree and in-tree.
>

Yes, but not from the same source tree.  However, I do from time to time 
migrate from in-tree to out-tree.

> Anyways, if you are building out of tree, there is no problem with the
> change because, as Miles explained, the angle brackets are used
> precisely for supporting simultaneous out of tree and in-tree
> builds. Removing the angle brackets is no problem for simultaneous out
> of tree builds.

And having them there is no problem either.

>
>> If you are going to impose a change on that process again just after
>> it was changed recently, you have to come up with something better
>> than that.
>
> Here we go again. No matter how small is the change one proposes,
> somebody will extract terrible cosequences from it, or refuse to
> evaluate the benefits dismissing it as useless, or both.

Motivating a change to cater for some broken analysis tool isn't terribly 
convincing too me.
And, as pointed out, autoconf recommends <>.

>
>> As for the gcc thing, that is intentional, it is how it is
>> supposed to work.
>
> Yes, I know, I was caught there. AFAIK the algorithm used by GCC assumes
> that angle brackets are for system headers.
>

No, it does not.  The search for include files with <> does not start in the 
current directory, where as for "" it does.  That is the only difference.  If 
the headers are system headers or not is not the difference.

	Jan D.

Re: Why <config.h> and not "config.h" ?

[immanuel litzroth]

> No, it does not.  The search for include files with <> does not start in the
> current directory, where as for "" it does.  That is the only difference.
>  If the headers are system headers or not is not the difference.

All this stuff is completely implementation dependent.
Immanuel

Re: Why <config.h> and not "config.h" ?

[Jan Djärv]

2010-07-28 10:04, immanuel litzroth skrev:
>> No, it does not.  The search for include files with<>  does not start in the
>> current directory, where as for "" it does.  That is the only difference.
>>   If the headers are system headers or not is not the difference.
>
> All this stuff is completely implementation dependent.

That is what ANSI-C says, yes.  But do you know of any implementation that 
differs from what I said above?  I do not.

	Jan D.

Re: Why <config.h> and not "config.h" ?

[Andreas Schwab]

Óscar Fuentes <oscarfv@telefonica.net> writes:

> Maybe is my hideous English, but as explained on my original message <>
> is giving me problems with some tool.

The only difference between <> and "" is that the latter first searches
in the same directory as the containing file, before any -I directories.
Since for an out-of-src build config.h is never found in the source
directory this should not make any difference in practice.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <oscarfv@telefonica.net> writes:
>
>> Maybe is my hideous English, but as explained on my original message <>
>> is giving me problems with some tool.
>
> The only difference between <> and "" is that the latter first searches
> in the same directory as the containing file, before any -I directories.
> Since for an out-of-src build config.h is never found in the source
> directory this should not make any difference in practice.

Precisely, it seems that Emacs is using <> because some people ends
having a config.h on the source directory, and even they defend this
practice as a convenience.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

[snip]

> As I said, it is a feature not having to run make bootstrap in every
> build tree.  I usually have five of them (Gtk, Lucid, Motif/Lesstif,
> X, no-X).

I see that it can save lots of compile time, but it is not a safe
practice.

[snip]

> No, I don't think you are making up things, there are a lot of buggy
> tools out there.  But which tools are we going to make this change
> for?  Are they free and generally useful for all developers?  Most
> analysis tools I've used does not have any problem with <> and "".
> You usually can pass -I. to them if that is needed.

In this case, the tool is CMake. I'm not sure if it is a bug or a
feature, I've asked about that on their ml. People used to complain
about the time required for checking depedencies on large projects (this
is specially aggravating on Windows) and maybe they decided headers
included with <>, which usually are external to the project. It seems a
bit extreme to me, but may be. IIRC some tools of the style of the late
SourceNavigator have switches for not diving into headers included with
<>, which is very convenient as today a simple #include can bring in
tens of thousands of LoC from some big library.

Yesterday I had an issue with MinGW using a build specification that
worked fine on GNU/Linux and, on addition, was formally correct. Through
some intermediate steps, the compiler ended picking up src/process.h
instead of mingw/include/process.h. Replacing <config.h> with "config.h"
fixed the problem.

[snip]

> No, it does not.  The search for include files with <> does not start
> in the current directory, where as for "" it does.  That is the only
> difference.  If the headers are system headers or not is not the
> difference.

With <> the search does not start on the current directory for avoiding
collisions with the headers there. That means that the "external"
headers take precedence. You can call it system headers or library
headers, but the intention is that they do not belong to the set of
source files being compiled at the moment. However, I agree with you
that it is convenience, nor stylistic theory, what matters here.

As an anecdote, I'll say that, as others mentioned, what <> means is
implementation-dependant. Long time ago this issue arised on the Borland
newsgroups because some user discovered the hard way that their compiler
had slightly different rules from GCC. After some minutes reading the
C++ standard it was clear that when the compiler finds #include
<stdio.h> it can reformat your hard disk and be perfectly
conformant. They write it on a very technical, serious-looking language,
though.

Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

[Seems that gmane ate my post. Sorry if this is a duplicate]

Jan Djärv <jan.h.d@swipnet.se> writes:

[snip]

> As I said, it is a feature not having to run make bootstrap in every
> build tree.  I usually have five of them (Gtk, Lucid, Motif/Lesstif,
> X, no-X).

I see that it can save lots of compile time, but it is not a safe
practice.

[snip]

> No, I don't think you are making up things, there are a lot of buggy
> tools out there.  But which tools are we going to make this change
> for?  Are they free and generally useful for all developers?  Most
> analysis tools I've used does not have any problem with <> and "".
> You usually can pass -I. to them if that is needed.

In this case, the tool is CMake. I'm not sure if it is a bug or a
feature, I've asked about that on their ml. People used to complain
about the time required for checking depedencies on large projects (this
is specially aggravating on Windows) and maybe they ignore headers
included with <>, which usually are external to the project. It seems a
bit extreme to me, but may be. IIRC some tools of the style of the late
SourceNavigator have switches for not diving into headers included with
<>, which is very convenient as today a simple #include can bring in
tens of thousands of LoC from some big library.

Yesterday I had an issue with MinGW using a build specification that
worked fine on GNU/Linux and, on addition, was formally correct. Through
some intermediate steps, the compiler ended picking up src/process.h
instead of mingw/include/process.h. Replacing <config.h> with "config.h"
fixed the problem.

[snip]

> No, it does not.  The search for include files with <> does not start
> in the current directory, where as for "" it does.  That is the only
> difference.  If the headers are system headers or not is not the
> difference.

With <> the search does not start on the current directory for avoiding
collisions with the headers there. That means that the "external"
headers take precedence. You can call it system headers or library
headers, but the intention is that they do not belong to the set of
source files being compiled at the moment. However, I agree with you
that it is convenience, nor stylistic theory, what matters here.

As an anecdote, I'll say that, as others mentioned, what <> means is
implementation-dependant. Long time ago this issue arised on the Borland
newsgroups because some user discovered the hard way that their compiler
had slightly different rules from GCC. After some minutes reading the
C++ standard it was clear that when the compiler finds #include
<stdio.h> it can reformat your hard disk and be perfectly
conformant. They write it on a very technical, serious-looking language,
though.

Re: Why <config.h> and not "config.h" ?

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Emacs sources use the idiom
>
> #include <config.h>
>
> Is there a specific reason for this? Usually the curly braces are for
> headers that live outside the project. Some code analysis tools assume
> that. And some compilers (including gcc, AFAIK) use a different
> procedure for locating headers surrounded by curly braces, which may
> produce unexpected results for headers included from config.h.
>
> Any objections to replacing <config.h> and <epaths.h> with "config.h"
> and "epaths.h" ?

Given that this is for your own needs, it seems that this is a change
that you can make in your local tree.  The code in question is very
unlikely to change otherwise, so you can always safely stash it/unstash it

Re: Why <config.h> and not "config.h" ?

[Stefan Monnier]

> I think this was discussed recently, and I seem to recall that the
> reason given was that "config.h" doesn't work if the user tries to build
> with an out-of-tree object directory _after_ having previously built in
> the source tree (without an intervening "make distclean" in the source
> dir).

Actually, I'd be happy to have a recipe to reproduce the problem.
This way we can fix it in the Makefile, so that the choice between the
two becomes "irrelevant", rather than being based on "avoid a poorly
understood problem in some rare corner case".


        Stefan

Re: Why <config.h> and not "config.h" ?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Actually, I'd be happy to have a recipe to reproduce the problem.

bzr brunch emacs
cd emacs
./configure
mkdir +build
cd +build
./configure --without-x11    # or other spectacular configuration difference
make bootstrap
src/emacs                    # of course, you need an X11 platform
                             # to see the difference

should do the trick.

 > This way we can fix it in the Makefile,

You can't fix it (nothing's broken), you can only prevent it.  Eg,
make everything depend on sane-builddir

sane-builddir:
	if -e src/emacs.c; then
            echo "Dr. Bader thinks you're insane."
            echo "For a second opinion, we recommend"
            echo "mkdir +build"
            echo "cd +build"
            echo "../configure"
            echo "make bootstrap"
            echo "src/emacs -f doctor"
            exit -1
        fi

You might want to use a more polite, informative error message, of course.

Re: Why <config.h> and not "config.h" ?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 30 Jul 2010 18:21:29 +0900
> Cc: emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
> 
> bzr brunch emacs

Does it also make coffee?

Re: Why <config.h> and not "config.h" ?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Fri, 30 Jul 2010 18:21:29 +0900
 > > Cc: emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
 > > 
 > > bzr brunch emacs
 > 
 > Does it also make coffee?

wideload:~ 18:30$ bzr help coffee
bzr: ERROR: No help could be found for 'coffee'.
wideload:~ 18:31$ 

Apparently not.