Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Junio C Hamano wrote: > >> For example, on my primary development box, I do not have any git >> installed from distribution, but I do have git on my $PATH. For such >> users, "make install" should be able to find out that the right place to >> install git-work.1 is in $HOME/some/where/man/man1 directory. > > Sorry to be dense, but: isn't the right place to install git-work.1 > one of > > /usr/local/share/man > /usr/share/man > /opt/man > $HOME/man > $prefix/man > > depending on where the git-work binary was installed? 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? -- 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