From: "Jan Djärv" <jan.h.d@swipnet.se>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Why <config.h> and not "config.h" ?
Date: Wed, 28 Jul 2010 08:30:31 +0200 [thread overview]
Message-ID: <4C4FCE87.4090600@swipnet.se> (raw)
In-Reply-To: <87sk34s2ws.fsf@telefonica.net>
Ó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.
next prev parent reply other threads:[~2010-07-28 6:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C4FCE87.4090600@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).