From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: Nathaniel P Dawson <nathaniel.dawson@gmail.com>,
Johannes Sixt <j.sixt@viscovery.net>,
git@vger.kernel.org
Subject: Re: [PATCH 0/5] Header includes cleanup
Date: Tue, 31 Mar 2009 09:04:38 -0700 [thread overview]
Message-ID: <7vk56565m1.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 200903310859.36035.chriscool@tuxfamily.org
Christian Couder <chriscool@tuxfamily.org> writes:
> I think it's a good thing that you started working on it even if in the end
> we decide that we want these cleanup to be done otherwise. At least we will
> hopefully have clarified our include header policy.
Before seeing a lot of patches to change #include all over the place, I'd
like to see a simple guiding principle described, not just a subjective "I
think this makes things better" but with "... because of X and Y and Z".
The document Documentation/CodingGuidelines describes the only policy that
exists currently: git-compat-util.h must be the first thing the compiler
sees. The language should probably be stronger than what appears there:
- The first #include in C files, except in platform specific
compat/ implementations, should be git-compat-util.h or another
well-known header file that includes it at the beginning, namely
cache.h or builtin.h.
Even though http.h may include "cache.h" at the very beginning, I'd rather
not to see http-walker.c lose inclusion of "cache.h". It will force us to
remember that http.h is Ok to include as the first file, and that won't
scale.
The reason git-compat-util.h must be the first is because inclusion of all
the system header files is supposed to happen there, and there are some
platforms that have broken system header dependencies we do not want
application writers to care about, and the compat-util header knows about
them.
next prev parent reply other threads:[~2009-03-31 16:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 9:55 [PATCH 0/5] Header includes cleanup Nathaniel P Dawson
2009-03-30 9:55 ` [PATCH 1/5] " Nathaniel P Dawson
2009-03-30 9:55 ` [PATCH 2/5] " Nathaniel P Dawson
2009-03-30 9:55 ` [PATCH 3/5] " Nathaniel P Dawson
2009-03-30 9:55 ` [PATCH 4/5] " Nathaniel P Dawson
2009-03-30 9:55 ` [PATCH 5/5] " Nathaniel P Dawson
2009-03-30 10:50 ` [PATCH 0/5] " Johannes Sixt
2009-03-30 17:33 ` Nathaniel P Dawson
2009-03-31 6:59 ` Christian Couder
2009-03-31 16:04 ` Junio C Hamano [this message]
2009-04-02 3:57 ` Christian Couder
2009-04-02 5:25 ` Junio C Hamano
2009-04-02 11:27 ` Jeff King
2009-04-03 4:14 ` Christian Couder
2009-04-03 12:24 ` Jeff King
2009-04-03 3:58 ` Christian Couder
2009-03-31 5:53 ` Christian Couder
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vk56565m1.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=nathaniel.dawson@gmail.com \
/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.
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 NNTP newsgroup(s).