Junio C Hamano <gits...@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 <gits...@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
    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 <gits...@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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to