From: Johannes Sixt <j.sixt@viscovery.net>
To: Kacper Kornet <kornet@camk.edu.pl>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/1] Honor $(prefix) set in config.mak* when defining ETC_GIT* and sysconfdir
Date: Wed, 04 May 2011 16:39:54 +0200 [thread overview]
Message-ID: <4DC1653A.7000000@viscovery.net> (raw)
In-Reply-To: <20110504135827.GC18585@camk.edu.pl>
Am 5/4/2011 15:58, schrieb Kacper Kornet:
> On Wed, May 04, 2011 at 07:52:30AM +0200, Johannes Sixt wrote:
>> Looking closer, the patch introduces git_etcdir for no good reason,
>> IIUC.
>> It should just re-use sysconfdir (the meaning of this variable is to
>> point
>> to the etc directory).
>
> And the first version of my patch did it. However Junio has written:
>
>> But this part in the Makefile outside the context of the patch bothers
>> me. It seems to imply that sysconfdir is _not_ that variable you want
>> to
>> define later.
>>
>> # Among the variables below, these:
>> # gitexecdir
>> # template_dir
>> # mandir
>> # infodir
>> # htmldir
>> # ETC_GITCONFIG (but not sysconfdir)
>> # ETC_GITATTRIBUTES
>> # can be specified as a relative path some/where/else;
>>
>> So I have a suspicion that your patch as is will break when prefix is
>> set
>> to something other than /usr directory. I don't think anybody in-tree
>> currently uses sysconfdir, but that does not mean nobody will ever do.
>
>>From that I understood that he prefers sysconfdir to be always an
> absolute path.
Junio's worries should not be discarded lightly. But in this case they are
unfounded. Digging the history shows:
b51b8bbf (Create a sysconfdir variable, and use it for ETC_GITCONFIG,
2007-04-24) introduced the variable to be able to treat the special case
where prefix == /usr. It was never intended as a user-settable value.
In 49fa65a7 (Allow the built-in exec path to be relative to the command
invocation path, 2008-07-23), I added the comment above because at that
time, a relocatable build should be requested by setting ETC_GITCONFIG to
a relative path, but not by changing sysconfdir. (The comment sounds as if
the user can set sysconfdir, but I did not intend to say that.)
026fa0d5 (Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX), 2009-01-18) practically obsoleted
sysconfdir. In particular, it removed one of the cases where the value of
sysconfdir mattered, leaving only the reference where it is guaranteed to
be set to /etc. This commit could have removed sysconfdir entirely.
6df42ab9 (Add global and system-wide gitattributes, 2010-09-01) added
another consumer of sysconfdir, but in the same spirit as ETC_GITCONFIG.
So, I don't think that sysconfdir must survive. It was always only a
helper variable to shorten the code.
-- Hannes
next prev parent reply other threads:[~2011-05-04 14:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-28 2:29 [PATCH] Respect definition of prefix from autotools in ETC_GITCONFIG and ETC_GITATTRIBUTES Kacper Kornet
2011-04-28 16:54 ` Junio C Hamano
2011-04-28 17:49 ` Kacper Kornet
2011-04-28 19:27 ` [PATCH 1/1] Honor $(prefix) set in config.mak* when defining ETC_GIT* and sysconfdir Kacper Kornet
2011-04-28 20:01 ` [PATCH] Honor sysconfdir when set as an configure option Kacper Kornet
2011-04-28 21:05 ` Junio C Hamano
2011-04-28 21:22 ` Kacper Kornet
2011-05-03 6:42 ` [PATCH 1/1] Honor $(prefix) set in config.mak* when defining ETC_GIT* and sysconfdir Johannes Sixt
2011-05-03 17:32 ` Junio C Hamano
2011-05-04 5:52 ` Johannes Sixt
2011-05-04 13:58 ` Kacper Kornet
2011-05-04 14:39 ` Johannes Sixt [this message]
2011-05-04 18:21 ` Junio C Hamano
2011-05-05 2:26 ` Junio C Hamano
2011-05-05 5:58 ` Johannes Sixt
2011-05-05 16:17 ` Junio C Hamano
2011-05-06 7:03 ` Johannes Sixt
2011-05-05 14:29 ` Kacper Kornet
2011-05-05 14:45 ` Johannes Sixt
2011-05-05 15:00 ` Kacper Kornet
2011-05-05 15:46 ` Junio C Hamano
2011-05-09 8:24 ` Johannes Sixt
2011-05-09 11:56 ` Kacper Kornet
2011-05-27 8:17 ` Kacper Kornet
2011-05-05 15:25 ` Kacper Kornet
2011-05-04 14:29 ` Kacper Kornet
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=4DC1653A.7000000@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kornet@camk.edu.pl \
/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.