* 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 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 ` 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: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 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 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 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
* 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 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: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 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
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.