Bugzilla Bug 40453

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 an attachment (id=24992) [details]
gtk dependency patch

This patch makes use of the "gtk" USE variable.  Imlib *can* be compiled
without gtk.

Created an attachment (id=25002) [details]
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 an attachment (id=25065) [details]
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 an attachment (id=38234) [details]
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 an attachment (id=38241) [details]
add --enable-gdk and --disable-gdk to imlib-1.9.14/configure.in

(From update of attachment 38241 [details])
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.