From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Allow generating a non-default set of documentation
Date: Sun, 7 Oct 2012 19:07:03 -0400 [thread overview]
Message-ID: <20121007230703.GC3490@sigill.intra.peff.net> (raw)
In-Reply-To: <7vwqz1oqi4.fsf@alter.siamese.dyndns.org>
On Sun, Oct 07, 2012 at 03:40:19PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote:
> > ...
> >> but it is not so far-fetched to imagine that Windows users may want to
> >> omit manpages with
> >>
> >> $ DEFAULT_DOC_TARGET=html make doc
> >
> > That use case makes a lot more sense to me (or more likely setting it in
> > config.mak).
>
> I actually had "ifeq ($(uname_S),Windows)" at the top-level in mind,
> not config.mak. I think that is far more important use case than
> going down to Documentation yourself and run make there (which is
> not a workflow I deeply care about in the first place).
Hmm. Unfortunately that does not work from within Documentation, because
Documentation/Makefile never gets to see our default-system tweaks (it
sees only config.mak).
I know it is a case you do not care about (and nor do I; if I use this
at all, it would be to limit my build by setting the variable in my
config.mak), but it highlights a subtle issue. The subdir Makefiles
receive their config from config.mak.autogen and config.mak, but never
get to see any of the default tweaks we do based on $(uname). Which the
contents of config.mak could very well depend on, if somebody were
trying to be very clever.
Would it make sense to pull all of our platform-specific tweaks out into
a config.mak.platform (right before config.mak.autogen)? That would be
less surprising for cases like this, and I think it would make the
Makefile a lot more readable.
-Peff
next prev parent reply other threads:[~2012-10-07 23:07 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 [this message]
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
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=20121007230703.GC3490@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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.