From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Allow generating a non-default set of documentation
Date: Mon, 08 Oct 2012 09:33:33 -0700 [thread overview]
Message-ID: <7vpq4sncte.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7vhaq5onig.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 07 Oct 2012 16:44:55 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Oct 07, 2012 at 04:25:58PM -0700, Junio C Hamano wrote:
>>
>>> Yeah, modulo that the "defaults" is tracked and does not have to
>>> have the dash before "include" (it is an error if it is missing,
>>> no?). It may want to be named with s/defaults/autodetect/, though.
>>>
>>> > diff --git a/Makefile b/Makefile
>>> > index e3e3cd5..c00fd32 100644
>>> > --- a/Makefile
>>> > +++ b/Makefile
>>> > ...
>>> > -endif
>>> > -
>>> > +-include config.mak.defaults
>>> > -include config.mak.autogen
>>> > -include config.mak
>>
>> Yeah, sorry, mindless copying on my part from the lines below. It
>> clearly should not have the "-".
>>
>> I'm fine with something besides "defaults". I meant it to be "these are
>> the config defaults before you tweak them", but yeah, it is more like
>> "these are the config options we picked up from uname".
>
> Let's put this on hold in the "possibly a good direction to go in"
> pile, and defer it to post 1.8.0; I haven't even looked at (and do
> not plan to before the release) these "auto-detect" bits are all
> safe to be included in Makefiles in subdirectories.
Oh by the way, by "this (on hold)" I meant not just your "move the
default-by-platform to a separate include", but the whole "a
platform may not want manpages" topic. The patch posted was merely
me wanting to format git-push.txt and nothing else when sanity
checking a patch to that file, and it is insufficient for the
purpose of "a platform may not want manpages" without a matching
change to the install target.
Even though your "include" thing was primarily done to make it
easier to include it from Makefiles in subdirectories, I very much
like it even without that benefit. The change makes it clear that
there is another platform specific bit after '-include config.mak'
(yes, I am looking at you, Darwin), which is a huge eyesore we would
want to do something about.
prev parent reply other threads:[~2012-10-08 16:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-07 20:39 [PATCH] Allow generating a non-default set of documentation Junio C Hamano
2012-10-07 21:48 ` Jeff King
2012-10-07 22:32 ` Junio C Hamano
2012-10-07 22:45 ` Junio C Hamano
2012-10-07 23:01 ` Jeff King
2012-10-07 22:40 ` Junio C Hamano
2012-10-07 23:07 ` Jeff King
2012-10-07 23:11 ` Jeff King
2012-10-07 23:25 ` Junio C Hamano
2012-10-07 23:29 ` Jeff King
2012-10-07 23:44 ` Junio C Hamano
2012-10-08 16:33 ` Junio C Hamano [this message]
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=7vpq4sncte.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 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.