Re: [PATCH 1/2] Makefile: Use the same source directory for "ln -s" as for "ln" / "cp"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 5, 2015, 20:59 UTC
- Message-ID
- <xmqqvbjgjcqw.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <4CF52072-713F-4456-B894-B874B0EFFC6B@gmail.com>
"Kyle J. McKay" <mackyle@gmail.com> writes:
> Now, can you do that easily in a Makefile? ;)
Or is it worth doing it?
I do not mind a full symbolic link as long as it points at the correct place (Sebastian's version did not under DESTDIR which was the only issue I had against it), but is there a good reason why we would prefer a relative one (or we would want to avoid a full one)?
> I'm not sure exactly why, but I think: > > On Jan 30, 2015, at 13:10, Junio C Hamano wrote: >> That would make me feel dirty.
That is a confusing style of quoting. I suspect that I said the above in a totally different context.
> Having a user-facing binary that is actually a symlink can potentially > cause problems on OS X if the binary it refers to locates its > libraries using a relative path.
I am not sure what problem you are trying to single out by repeating "user-facing" here.
As doing this is still fully supported:
$ PATH=$(git --exec-path):$PATH
$ export PATH
$ git-cat-file -t HEADYou can arrange things in different ways:
- /usr/libexec/git-core/git-cat-file can a symbolic link to /usr/bin/git (cross directory)
- /usr/libexec/git-core/git-cat-file can a symbolic link to "git" (in the same directory) and then /usr/bin/git may be a symbolic link to /usr/libexec/git-core/git (cross directory)
No matter what, as long as you have these two directories, you would have the issue that a symbolic link that is given to execv(2) might misbehave somewhere anyway, no?
I do not know (and I am not quite sure if I want to know) how serious your "potential" problems would be, and I do not doubt you know OS X quirks much better than I do and do not intend to argue there aren't such problems. I am just curious how "user-facing" comes into the picture.