GNOME Bugzilla – Bug 310565
wanted: a link to gimptool named by version
Last modified: 2005-08-13 23:24:32 UTC
Respectfully requesting that gimp-2.x install gimptool-2.x in addition to installing gimptool-2.0. (Presumably one would be a link to the other.) I have GIMP 2.0, 2.2, and 2.3 on my system. Each one of them includes a program called gimptool-2.0. These three programs with the same name do different things (install to ~/.gimp-2.0, -2.2, and -2.3 respectively). It's impossible to install a plug-in to all three of these, or to one specific one if it's not first in the path, without knowing the full path to each one. In my C plug-in's Makefile. I want to make it easy for users to install to any or all of their gimp versions (either with one command or with several). But currently, there's no way for gimptool to install to any version besides the one that happens to be first in $path, since the others are hidden from it. What would be perfect is if GIMP installed a gimptool-2 and a gimptool-2.x, but I suppose it's probably too late for that since 2.2 has already shipped with a gimptool-2.0 even though it's not 2.0. I am hoping, though, that even in 2.2 versions it'll be possible to add this link, so 2.2 doesn't hide 2.3/2.4 or vice versa as far as plugin installation goes.
This is an enhancement.
There isn't much point in keeping different versions of GIMP 2.x installed. I don't see why we should add support for this. There is always exactly one gimptool binary in the PATH and your Makefile should assume that this is the only gimp-2.x installation. The fact that gimptool has the 2.0 version number is intentional. gimp-2.2 is source and binary compatible to gimp-2.0. The API version is 2.0 and that's what gimptool is all about. Closing as WONTFIX.
I have found this confusing as well. Would it do any harm to rename the command gimptool-2 instead of gimptool-2.0?
Of course it would do harm. The name of the executable is part of the API and renaming it would break scripts and Makefiles and thus would break backward compatibility. There is also a good reason why it is called gimptool-2.0 and not gimptool-2. After all the API version is 2.0 and not 2.
I should mention that I filed this at yosh's request after some discussion on bugzilla. Reopening for yosh's comment. I'd also like to stress that I did not ask for the existing name to be removed. I do think it's misleading, but I understand that it's too late to change that. This bug is asking for a link to a clearer file name, not a replacement of the existing name.
But the filename isn't misleading and there's absolutely no point in changing it or providing an alternative. I don't understand the reason behind your request. The handful of people who actually have different versions of GIMP installed on their system know very well what they are doing and should be able to handle plug-in installation w/o the need to introduce the ugliness of another gimptool binary with a completely wrong name.
*strongly disagree*. The plugin api is backwards but not forwards compatable. There really is a difference between linking against 2.0 and 2.2, because 2.2 provides symbols 2.0 does not. To express this simply: 2.0 API != 2.2 API instead, 2.0 API < 2.2 API The subset symbol would be more appropriate, but < is good enough. A plugin written to the 2.2 API is not necessarily written to the 2.0 API; if it avoids deprecated parts of the API, this is even more likely. A script or Makefile that calls gimptool-2.0 is buggy if the plugin contains even one 2.2+ function. The user will get a bewildering linker or compiler error which gives no indication about how to fix it. It's easy to figure out if your plugin can't compile because "gimptool-2.4 not found" and you only have gimp 2.2 on your system what the problem is and how to fix it. That aside, I also find your comment about gimptool being an end-user tool puzzling; supporting developers has always been an important, nay, primary aspect of this tool. In real life, developers have multiple versions of gimp installed, and there are very legitimate reasons to want to link against a particular version; it it arrogant to assume you know what is best for them. Core developers are not the only ones that find gimptool useful, either. Any plugin developer that wants to test their code against or use the new features of the developer version of gimp can use this tool. It's especially important to have a version of gimptool for the unstable version since the prefered method of installing developer gimp requires on linux the use of rpath linker options, and remembering this kind of trivia is exactly what gimptool was designed to do. You find a binary called gimptool-2.2 ugly. I find compiling a plugin that does not work for the binary called gimp-2.0 with a program called gimptool-2.0 ugly. There is no accounting for taste. As a personal suggestion, writing there is no reason for something in response to several reasons given for it, even if they are reasons you for some reason dislike, is a much uglier behavior than version numbering adminstrivia. Respecting other's opinions is an essential skill for working on an open-source project, especially one as large as GIMP.
Well, going for gimptool-2.2 would not only deviate from what other projects are doing but also from the version numbering scheme that we decided on for gimp-2.x. I don't see any reason to do that change. None of the arguments given here hold up. If you have multiple versions of gimp-2.x on your disk (which is rather unlikely), than you have them in different paths anyway and can easily distinguish the gimptool binaries that way. Plug-in authors are best advised to use pkg-config to check for the GIMP version and also to compile their plug-ins. The only remaining use of gimptool nowadays is to install scripts and plug-ins to the user's gimp directory. Anything else can be better done using pkg-config. Probably the best thing we can do is to finally deprecate gimptool.
Hm, when we initially discussed this on IRC, I thought it would be ok, but thinking it through now I don't think this is such a good idea. Having multiple 2.x versions installed has enough caveats already, adding one more source of confusion doesn't seem wise. As it stands, you can't reliably have out-of-tree compiled plug-ins working in with a GIMP using non-system libraries, without doing LD_LIBRARY_PATH tricks. Perhaps there should be a ~/.gimp-2-plugins dir searched too.