Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

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

 



John Keeping wrote:
> > I also think that there should be a way to make it really easy to
> > install these third-party tools to augment the installed version of
> > Git without having the source tree of Git.  We have ways for them to
> > ask us where things are expected to be, e.g.
> > 
> >     $ git --html-path
> >     $ git --man-path
> >     $ git --exec-path
> > 
> > but I am not sure if these are enough, or if it would help them to
> > add a bit more, then what these "a bit more" are.
> 
> I think this is enough - now I need to go and make git-integration's
> Makefile use them by default rather than just using the same defaults as
> git.git.

This is wrong. Subprojects should use /usr/bin/ and /usr/share/man/ and
not rely on the output of `git --exec-path` and so on.

For example if the user has installed Git in his $home, when building a
package the package manager would use ~/libexec/git-core, which is
wrong.

Moreover, if you are cross-compiling you won't be able to run the
target's `git` binary.

If anything, it should be `pkg-config --variable=exec-path git`.

-- 
Felipe Contreras
--
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]