"Kyle J. McKay" <mackyle@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html