Re: RFC: a plugin architecture for git extensions?

> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Junio C Hamano wrote:
>
> I was thinking it, and the location git-work binary gets installed, should
> depend on where "git" and its subcommand binaries are installed.  The word
> plug-in mentioned in the thread implied that whatever plugs in is not by
> itself full fledged thing that is useful standalone, so it seemed a very
> natural thing to do.
>

>> In the $prefix
>> case, the same snippet in .profile that adds $prefix/bin to the $PATH
>> would also say
>>
>>       MANPATH=$prefix/man:$(manpath)
>
> You are correct only if "git" the user is building is _not_ changed to
> look for other places for its own manpages.  If "git" was built to look at
> somewhere else, the relationship between the output of "git --exec-path"
> and that location shouldn't be assumed to be ../../share/man or anything.
>
> The layout should be discoverable, by exposing system_path(GIT_MAN_PATH)
> and friends (see builtin/help.c), just like we expose GIT_EXEC_PATH.
>
>> Or is the idea to blindly install (a symlink to) git-work to $(git
>> --exec-path)/ rather than a place on the $PATH?
>
> You can call it _blindly_ if you like, but that is what I meant.  "git"
> tells where the binary and help material for a "plugin" to be installed,
> so that it can find them where it expects to.
>

> After all, I am not interested at all in adding "git pm" or other crap.  I
> am just trying to help people write their own "make install" of a plugin
> project, like "git work".  And writing "make uninstall" for that project
> should be doable with the same information I am trying to give in this
> thread, no?