* Why <config.h> and not "config.h" ?
@ 2010-07-28 2:23 Óscar Fuentes
2010-07-28 2:30 ` Miles Bader
` (3 more replies)
0 siblings, 4 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 2:23 UTC (permalink / raw
To: emacs-devel
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" ?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 2:23 Why <config.h> and not "config.h" ? Óscar Fuentes
@ 2010-07-28 2:30 ` Miles Bader
2010-07-28 3:25 ` Óscar Fuentes
2010-07-29 14:26 ` Stefan Monnier
2010-07-28 7:06 ` Andreas Röhler
` (2 subsequent siblings)
3 siblings, 2 replies; 23+ messages in thread
From: Miles Bader @ 2010-07-28 2:30 UTC (permalink / raw
To: emacs-devel
Ó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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 2:30 ` Miles Bader
@ 2010-07-28 3:25 ` Óscar Fuentes
2010-07-28 6:30 ` Jan Djärv
2010-07-29 14:26 ` Stefan Monnier
1 sibling, 1 reply; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 3:25 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 3:25 ` Óscar Fuentes
@ 2010-07-28 6:30 ` Jan Djärv
2010-07-28 6:46 ` Óscar Fuentes
0 siblings, 1 reply; 23+ messages in thread
From: Jan Djärv @ 2010-07-28 6:30 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Ó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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 6:30 ` Jan Djärv
@ 2010-07-28 6:46 ` Óscar Fuentes
2010-07-28 7:06 ` Jan Djärv
2010-07-28 8:29 ` Andreas Schwab
0 siblings, 2 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 6:46 UTC (permalink / raw
To: Jan Djärv; +Cc: Óscar Fuentes, emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 2:23 Why <config.h> and not "config.h" ? Óscar Fuentes
2010-07-28 2:30 ` Miles Bader
@ 2010-07-28 7:06 ` Andreas Röhler
2010-07-28 7:10 ` Óscar Fuentes
2010-07-28 7:15 ` Yavor Doganov
2010-07-28 19:50 ` Dan Nicolaescu
3 siblings, 1 reply; 23+ messages in thread
From: Andreas Röhler @ 2010-07-28 7:06 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
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" ?
>
>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 6:46 ` Óscar Fuentes
@ 2010-07-28 7:06 ` Jan Djärv
2010-07-28 7:35 ` Óscar Fuentes
2010-07-28 8:29 ` Andreas Schwab
1 sibling, 1 reply; 23+ messages in thread
From: Jan Djärv @ 2010-07-28 7:06 UTC (permalink / raw
To: Óscar Fuentes; +Cc: Óscar Fuentes, emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:06 ` Andreas Röhler
@ 2010-07-28 7:10 ` Óscar Fuentes
0 siblings, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 7:10 UTC (permalink / raw
To: emacs-devel; +Cc: Andreas Röhler
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."
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 2:23 Why <config.h> and not "config.h" ? Óscar Fuentes
2010-07-28 2:30 ` Miles Bader
2010-07-28 7:06 ` Andreas Röhler
@ 2010-07-28 7:15 ` Yavor Doganov
2010-07-28 7:46 ` Óscar Fuentes
2010-07-28 19:50 ` Dan Nicolaescu
3 siblings, 1 reply; 23+ messages in thread
From: Yavor Doganov @ 2010-07-28 7:15 UTC (permalink / raw
To: emacs-devel
Óscar Fuentes wrote:
> Emacs sources use the idiom
>
> #include <config.h>
The Autoconf manual recommends this practice.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:06 ` Jan Djärv
@ 2010-07-28 7:35 ` Óscar Fuentes
2010-07-28 7:57 ` Jan Djärv
0 siblings, 1 reply; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 7:35 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:15 ` Yavor Doganov
@ 2010-07-28 7:46 ` Óscar Fuentes
0 siblings, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 7:46 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:35 ` Óscar Fuentes
@ 2010-07-28 7:57 ` Jan Djärv
2010-07-28 8:04 ` immanuel litzroth
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Jan Djärv @ 2010-07-28 7:57 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:57 ` Jan Djärv
@ 2010-07-28 8:04 ` immanuel litzroth
2010-07-28 8:19 ` Jan Djärv
2010-07-28 9:38 ` Óscar Fuentes
2010-07-28 10:07 ` Óscar Fuentes
2 siblings, 1 reply; 23+ messages in thread
From: immanuel litzroth @ 2010-07-28 8:04 UTC (permalink / raw
To: Jan Djärv; +Cc: Óscar Fuentes, emacs-devel
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 8:04 ` immanuel litzroth
@ 2010-07-28 8:19 ` Jan Djärv
0 siblings, 0 replies; 23+ messages in thread
From: Jan Djärv @ 2010-07-28 8:19 UTC (permalink / raw
To: immanuel litzroth; +Cc: Óscar Fuentes, emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 6:46 ` Óscar Fuentes
2010-07-28 7:06 ` Jan Djärv
@ 2010-07-28 8:29 ` Andreas Schwab
2010-07-28 8:59 ` Óscar Fuentes
1 sibling, 1 reply; 23+ messages in thread
From: Andreas Schwab @ 2010-07-28 8:29 UTC (permalink / raw
To: Óscar Fuentes; +Cc: Fuentes, Jan Djärv, emacs-devel
Ó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."
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 8:29 ` Andreas Schwab
@ 2010-07-28 8:59 ` Óscar Fuentes
0 siblings, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 8:59 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:57 ` Jan Djärv
2010-07-28 8:04 ` immanuel litzroth
@ 2010-07-28 9:38 ` Óscar Fuentes
2010-07-28 10:07 ` Óscar Fuentes
2 siblings, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 9:38 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 7:57 ` Jan Djärv
2010-07-28 8:04 ` immanuel litzroth
2010-07-28 9:38 ` Óscar Fuentes
@ 2010-07-28 10:07 ` Óscar Fuentes
2 siblings, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2010-07-28 10:07 UTC (permalink / raw
To: Jan Djärv; +Cc: emacs-devel
[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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 2:23 Why <config.h> and not "config.h" ? Óscar Fuentes
` (2 preceding siblings ...)
2010-07-28 7:15 ` Yavor Doganov
@ 2010-07-28 19:50 ` Dan Nicolaescu
3 siblings, 0 replies; 23+ messages in thread
From: Dan Nicolaescu @ 2010-07-28 19:50 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Ó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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-28 2:30 ` Miles Bader
2010-07-28 3:25 ` Óscar Fuentes
@ 2010-07-29 14:26 ` Stefan Monnier
2010-07-30 9:21 ` Stephen J. Turnbull
1 sibling, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2010-07-29 14:26 UTC (permalink / raw
To: Miles Bader; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-29 14:26 ` Stefan Monnier
@ 2010-07-30 9:21 ` Stephen J. Turnbull
2010-07-30 9:55 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Stephen J. Turnbull @ 2010-07-30 9:21 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, Miles Bader
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-30 9:21 ` Stephen J. Turnbull
@ 2010-07-30 9:55 ` Eli Zaretskii
2010-08-01 9:31 ` Stephen J. Turnbull
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2010-07-30 9:55 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Why <config.h> and not "config.h" ?
2010-07-30 9:55 ` Eli Zaretskii
@ 2010-08-01 9:31 ` Stephen J. Turnbull
0 siblings, 0 replies; 23+ messages in thread
From: Stephen J. Turnbull @ 2010-08-01 9:31 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2010-08-01 9:31 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-28 2:23 Why <config.h> and not "config.h" ? Óscar Fuentes
2010-07-28 2:30 ` Miles Bader
2010-07-28 3:25 ` Óscar Fuentes
2010-07-28 6:30 ` Jan Djärv
2010-07-28 6:46 ` Óscar Fuentes
2010-07-28 7:06 ` Jan Djärv
2010-07-28 7:35 ` Óscar Fuentes
2010-07-28 7:57 ` Jan Djärv
2010-07-28 8:04 ` immanuel litzroth
2010-07-28 8:19 ` Jan Djärv
2010-07-28 9:38 ` Óscar Fuentes
2010-07-28 10:07 ` Óscar Fuentes
2010-07-28 8:29 ` Andreas Schwab
2010-07-28 8:59 ` Óscar Fuentes
2010-07-29 14:26 ` Stefan Monnier
2010-07-30 9:21 ` Stephen J. Turnbull
2010-07-30 9:55 ` Eli Zaretskii
2010-08-01 9:31 ` Stephen J. Turnbull
2010-07-28 7:06 ` Andreas Röhler
2010-07-28 7:10 ` Óscar Fuentes
2010-07-28 7:15 ` Yavor Doganov
2010-07-28 7:46 ` Óscar Fuentes
2010-07-28 19:50 ` Dan Nicolaescu
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.