Re: [PATCH 1/2] Makefile: Use the same source directory for "ln -s" as for "ln" / "cp"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]