Cc: gimp-print-devel@xxxxxxxxxxxxxxxxxxxxx From: Roger Leigh <roger@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 24 May 2004 01:18:30 +0100 Robert L Krawitz <rlk@xxxxxxxxxxxx> writes: > From: Roger Leigh <roger@xxxxxxxxxxxxxxxxxxxxxx> > Date: Sun, 23 May 2004 14:03:36 +0100 > > Does anyone know how (for the Debian packaging) I could build it > statically? configure allows --enable-shared=lib1,lib2 and > --enable-static=lib1,lib2,... but this doesn't work as I'd like: if > you say you want a library built one way, it builds every other > library the opposite way. For example, if I do > --enable-static=gimpprintui, every other library is dynamic only. > What I'd like is everything built both dynamically and statically, > except for libgimpprintui, which should be static only. I'd like > to do that or link print with the static version. > > The reason for this is that I don't want two extra packages > (libgimpprintui1 and libgimpprintui-dev) unless there's actually a > use for them, and I don't believe there is at present. > > Why would it force a separate package? If the library is shared, it needs to be in a separate library package, and the headers and static library need to go in a development package. If it's static-only, I can just link it with the plugin and not package any libraries at all. This isn't strictly required AFAIK, but is the recommended practice, since if the library is packaged with a program, it makes it harder for other packages to depend on it, since you force the user to have the program it is packaged with installed, whether they want it or not (e.g. including GTK+ in the GIMP package). (The point is moot for the 1.2 plugin, since GIMP 1.2 is not available in Debian any longer, but the same might need to apply to the new libgimpprintui, at least initially.) So I think I've finally figured out how to factor the GIMP plugin. This may be of interest to the GNOME and KDE folks, also. Bottom line: the GIMP folks should own src/gimp (the GIMP-specific code), and we should own libgimpprintui (which should be renamed libgimpprint-gtk2 for the gtk2 version). The advantage of this is that we can upgrade the plugin to take advantage of any new features in Gimp-Print (profiles, what have you) without GIMP users having to even recompile the plugin. For this to work, obviously libgimpprintui *must* be dynamic. So what do we need to do for this to be practical? 1) I need to finish what I'm doing, which is what I proposed last week (and nobody took me up on), to clean up the queue-handling stuff. For coding I'm probably 50-75% there. I created a new CVS branch for this. 2) We need to define exactly what the interface is between the GIMP and libgimpprintui (i. e. the stpui layer). This should be a very thin layer, certainly much thinner than libgimpprint and possibly even thinner than what it is now. We may even want to not expose the libgimpprint layer at all to the plugin. Part of this is making the stpui_plist_t opaque, like we've done for the various "classes" in libgimpprint. Whatever we do, I don't think we're far away here. 3) Roger and/or Jody need to finish their libgimpprintui2/libgimpprint-gtk2 port. If we do this right, then we can change libgimpprint to our heart's content and the GIMP plugin will go merrily on its way, without ever having to be recompiled or relinked. When the GIMP supports 16 bits, only the plugin needs to change, and that would be owned by the GIMP. If we add color management, then as long as we don't rely on the GIMP for any of that there should be no problem. Then when we go to 5.2 or even 6.0 or whatever GIMP users shouldn't have to worry about an upgrade. The KDE and GNOME folks may find this kind of thing interesting. For example, if KDE wants to offer Kimp-Print as an alternate (richer) printing KPart that isn't limited by what PPD files can describe, but can take advantage of Gimp-Print's functionality, they could write their libkimpprint and do the same kind of thing. What do folks think? -- Robert Krawitz <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx Project lead for Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
