Re: [PATCH 0/3] Fix installation paths with "make install-doc"

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 12, 2013, 22:57 UTC
Message-ID: <7vip5xdtt6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vmwv9ducx.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> I _think_ exporting mandir/html/infodir from the top-level Makefile
> is wrong to begin with.  We should drop the "export mandir" from
> there.

Ah, it is this thing, isn't it?

commit d8cf908cb6012cd4dc3d1089a849daf646150c2e
Author: Junio C Hamano <gitster@pobox.com>
Date:   Sat Feb 2 17:58:49 2013 -0800

    config.mak.in: remove unused definitions
    
    When 5566771 (autoconf: Use autoconf to write installation
    directories to config.mak.autogen, 2006-07-03) introduced support
    for autoconf generated config.mak file, it added an "export" for a
    few common makefile variables, in addition to definitions of srcdir
    and VPATH.
    
    The "export" logically does not belong there.  The make variables
    like mandir, prefix, etc, should be exported to submakes for people
    who use config.mak and people who use config.mak.autogen the same
    way; if we want to get these exported, that should be in the main
    Makefile.
    
    We do use mandir and htmldir in Documentation/Makefile, so let's
    add export for them in the main Makefile instead.
    
    We may eventually want to support VPATH, and srcdir may turn out to
    be useful for that purpose, but right now nobody uses it, so it is
    useless to define them in this file.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

config.mak.in shouldn't have exported mandir in the first place, and the commit made it worse by moving that broken export to the main Makefile, and also added an export to htmldir as well, which was totally wrong.

Let me revert that bit first.

I still think making "mandir" to have the real path in both the top-level Makefile and Documentation/Makefile and renaming the variable that is used to form the -DGIT_MAN_PATH=<path> to optionally compile in a path relative to an unspecified location that is discovered at runtime to something else is the sane thing to do, but that is a separate issue, I think.