From: Junio C Hamano Date: Thu, 05 Feb 2015 20:59:35 GMT Subject: Re: [PATCH 1/2] Makefile: Use the same source directory for "ln -s" as for "ln" / "cp" Message-ID: In-Reply-To: <4CF52072-713F-4456-B894-B874B0EFFC6B@gmail.com> "Kyle J. McKay" 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 HEAD You 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.