Re: [PATCH] Allow generating a non-default set of documentation

From: Jeff King <peff@peff.net>
Date: Oct 7, 2012, 23:07 UTC
Message-ID: <20121007230703.GC3490@sigill.intra.peff.net>
In-Reply-To: <7vwqz1oqi4.fsf@alter.siamese.dyndns.org>

On Sun, Oct 07, 2012 at 03:40:19PM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> 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