The ebuild file of imlib states a dependency on gtk. It is good, so far. However using gnome/gtk2 with sawfish for example will depend on imlib, wich will pull in gtk. This is not good.
Created attachment 24992 [details, diff] gtk dependency patch This patch makes use of the "gtk" USE variable. Imlib *can* be compiled without gtk.
Created attachment 25002 [details, diff] gtk and tiff dependency patch Even better, use the tiff variable, too. This time I didn't test whether imlib configure fails without libtiff...
A note here: its not enough to patch dependencies like this, You -must- also make sure that the case where: a) I have tiff installed, USE="-tiff" - doesn't - link to libtiff. Because if it uses automagic (oh, I see tiff in the system, lets link to it) there is no dependency tracking and you can, and may, uninstall tiff and thereby break things that -explicitly doesn't depend- on tiff. b) same for gtk+. so in conclusion, doing the DEPEND/RDEPEND magic only is -bad- and broken behaviour. if you want this without gtk+ and tiff, make sure the build doesn't link them if USE="-gtk -tiff" and they are installed. If you cannot guarantee this, the hard dependencies are rule, because even if they don't give you the fullest of choices, they guarantee a stable and functional system.
Created attachment 25065 [details, diff] gtk dependency patch I was irresponsible. According to the README libtiff is required for imlib. So I removed the tiff USE variable. Because imlib doesn't support "--without-gtk" I made the script look for gtk-config where it isn't supposed to find it.
What do you think, Spider, is this patch mature enogh to be merged into the portage tree?
it's an interesting approach. Do you happen to know what imlib's gtk support consists of ? It should not break any applications using it like that.
I don't know really but I think if someone is using USE="-gtk" imlib should not force gtk anyway.
well, the problem isn't as much "force or not" as "what breaks due to expecting imlib+gdk-pixbuf" , since gdk-pixbuf is the loader-code for PNG, jpeg and others (those it doesn't have native support for) , thats why things sorta. As i recall gdk was used for fallback rendering when it didn't find anything. I do like the approach though, creative.
Please note that there is a --disable-gtktest-switch to imlib, which should also be disabled when USE="-gtk" is set. Beside that, I really think this fix is important to get into the tree, because at the moment, it's impossible to build kde without installing gtk-1.2.
The econf_args="--with-gtk-prefix=/dev/null" did not work for me, but replacing it with econf_args="--disable-gtktest-switch" worked great.
*** Bug 60361 has been marked as a duplicate of this bug. ***
I didn't really looked into the code, but may it be, that gtk is not optional? If gtk-test is performed or not is not of interest and the GTK_CONFIG variable seems to be set via --with-gtk-exec-prefix. I testet --without and =/dev/null, but with USE=-gtk the ebuild fails always.
On my sparc64 at least imlib won't compile without gtk (USE="-gtk").
same on my amd64 system. /etc/make.conf has USE="-gtk", but I have to add media-libs/imlib gtk in /etc/portage/packages.use in order to get imlib to build.
Just a 'me too' that the prepending '/dev/null' results in a compilation failure with USE="-gtk". The build thinks it finds gtk, then later blows up because it cant find the gdk headers: (see the 'yes' at the end) checking for gtk-config... /dev/null/bin/gtk-config checking for GTK - version >= 1.2.1... ./configure: line 1: /dev/null/bin/gtk-config: Not a directory ./configure: line 1: /dev/null/bin/gtk-config: Not a directory ./configure: line 1: /dev/null/bin/gtk-config: Not a directory ./configure: line 1: /dev/null/bin/gtk-config: Not a directory ./configure: line 1: /dev/null/bin/gtk-config: Not a directory yes ^^^ I am on x86 arch. And gtk is installed. Now, if I take the '--disable-gtktest' out of the econf_args line, then it ends with 'no', and complains about the test failing, but goes on and builds without the gtk stuff. To clarify, 'use gtk || econf_args="--with-gtk-prefix=/dev/null"' seems to work. Of course, then 'xzgv' fails to build because it depends on a gtk-ified imlib.....;) So, at this point, one wonders how many of imlibs clients actually need gtk support...
*** Bug 61022 has been marked as a duplicate of this bug. ***
Why does emerge -vp imlib list there are no use flags for imlib but enabling the gtk use flag for it fixes the problems?
Because the flag is not listed in IUSE variable. The ebuild as it is now is broken for USE="-gtk". Further look into imlib's configure.in reveals that gtk-1.2 is mandatory.
This configure flag: econf_args="--with-gtk-prefix=/dev/null" causes imlib not to compile for me. Though if i remove it imlib works perfectly without gtk.
*** Bug 61281 has been marked as a duplicate of this bug. ***
*** Bug 61421 has been marked as a duplicate of this bug. ***
the macro invloved (configure.in): AM_PATH_GTK([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) if gtk is not installed GDB_IMLIB will be set to "" because gtk-config was not found and gdk_imlib won't be built. This macro: * Determines the location of GTK using gtk-config, which is either found in the user's path, or from the environment variable GTK_CONFIG * Tests the installed libraries to make sure that there version is later than MINIMUM-VERSION. (A default version will be used if not specified) * If the required version was found, sets the GTK_CFLAGS [...] and then executes ACTION-IF-FOUND. * If the required version was not found, sets GTK_CFLAGS and GTK_LIBS to empty strings, and executes ACTION-IF-NOT-FOUND. but if gtk is installed (and so gtk-config exists) and we don't want to build gdk_imlib: --with-gtk-prefix="" or any other path with bin subdir not /dev/null if we want to follow that approach. sorry for my bad english
Created attachment 38234 [details, diff] gtk dep: --with-gtk-prefix patch
well, ok i looked at it again. The breaking 'fix' which was discussed but not tested & approved by spider or me (but thats alright i guess because we aren't the official maintainers) was introduced by hanno. So with that i assume he took maintenance (although it's not noted in metadata as it should be) ? Hanno, please fix the obviously broken hack that seems unneeded anyway, just disabling the test should be enough on gtk1-less systems. As for a 'hard' switch, resetting the gtk path (what the initial patch tried to do) doesn't seem to work. Anyway, the reasons for our hesitation is that imlib without gtk+ exposes a much smaller API and this -iirc- used to give problems with basic gnome applications/libs that unconditionally depend on this extened api. So it's not so much the question if the switch is in theory possible or that it is in practice a wise thing to apply. On the other hand the amount of recent KDE users vs oldskool gnome users maybe justifies having the flag. @ comment 22 : you just concat two strings, it's a happy coincidence that it does what you intended to do & it still doesn't do what it is supposed to do.
*** Bug 60961 has been marked as a duplicate of this bug. ***
I've now switched back to the old behaviour, sorry for causing so much trouble. I'll probably add a -r2-ebuild if I find a really working way to make the gtk-support optional.
yes,but "" with /bin/gtk-config = "/bin/gtk-config" is a valid path,if you have /bin directory ;) but the file not exists, while concat "/dev/null" to "/bin/gtk-config" ="/dev/null/bin/gtk-config" is not a valid path. i attach a simple patch for imlib/configure.in which add --enable/disable-gdk options to configure
Created attachment 38241 [details, diff] add --enable-gdk and --disable-gdk to imlib-1.9.14/configure.in
Comment on attachment 38241 [details, diff] add --enable-gdk and --disable-gdk to imlib-1.9.14/configure.in sorry: AC_MSG_RESULT() inverted yes/no
Bug #60961 is /not/ a duplicate of this bug. That bug is about giflib/libungif. The imlib ebuild has a dependency on giflib but won't build properly unless libungif is installed. I'd been having unrelated problems with both giflib and libungif and happened to notice that libimlib-gif was actually linked with libungif - not libgif. Since I've just successfully rebuilt imlib with *only* libungif installed, I'd say the ebuild's dependency should be changed to libungif. The imlib configure script doesn't look for libgif and it doesn't provide any options to use it instead of libungif either. No doubt it /could/ use libgif but it's not set up to do so at the moment, so it's README is rather misleading.
Please ignore the 2nd paragraph of comment #30.
Nice work Simone. I've recently committed an ebuild for imlib-1.9.15, including your patch to enable/disable Gdk and hence making the gtk+-1.2 dependency optional. This ebuild is hardmasked for testing, so please do try it out. A couple of things to review: a) It should not install /usr/lib/pkgconfig/imlibgdk.pc if Gdk support is disabled. b) The tests for -ljpeg, -tiff, -lpng, etc. are unnecessary if Gdk support is disabled (and therefore those dependencies should be optional too). Apart from that, this ebuild will remain hardmasked until we fully test the result of installing imlib without the libimlib-* and libgdk_imlib* libraries. P.L.Hayes, if the bug you mention is not a duplicate, please mention it in that bug, and make sure to explain your reasons and the current state of the problem so we can re-open it. Thanks.
*** Bug 82310 has been marked as a duplicate of this bug. ***
*** Bug 100817 has been marked as a duplicate of this bug. ***
Another bug with no status update. What's the status here ?
# Leonardo Boshell <leonardop@gentoo.org> (31 May 2005) # Masked for testing, it includes an experimental patch to make Gtk+ # dependency optional. See bug #40453. =media-libs/imlib-1.9.15 Zzzzz... Maybe it's tested enough, so someone could unmask it?
yes, please, it's just working!
(In reply to comment #37) > yes, please, it's just working! Feel free, gnome herd doesn't want this anymore...
Fixed teh ebuild and unmasked it.
