wxGTK has a number of configure switches but those 3 are not implemented in the ebuild. So, as I am trying to remove all dependencies against tiff, here is a patch for wxGTK (next post).
Hmmm, where's the patch? :)
sorry, I had a problem with bugzilla while at uni so I couldn't submit it.
Created attachment 89239 [details, diff] wxGTK-2.6.2-r1.ebuild.patch Here it is, sorry for the delay.
I reopen this one because I provided the patch.
Hello, a couple observations: Why the addition of autotools inherit? Quite some applications depending on wxGTK will probably start breaking from no image support of said formats - PNG especially. But have done no tests to back that up. Can the patch be made against wxGTK-2.6.3.2 or whatever is the latest (~x86) ebuild in the tree? In there the --enable's were removed completely, relying on the presence of the library or dropping to the wx shipped versions (don't remember which ones were just disabled if no system one was available). However I agree that a USE flag might be better for removing any surprise effects, but there is the concern of apps depending on a certain image format provided by wx through wxImage to fail to work. Thanks for the report!
Umm the autotools might have slept in while testing. I'll try doing it against lastest ~x86. I've done this patch of the only stable box. It might break packages if you are fool enough to consider removing png or jpeg flag but the first intent of this patch is to remove tiff dependency, which is for me a very rarely encountered format. Considering USE flag brakage, this is also true for some packages depending on avahi and dbus (both need the be activated but one could have omitted the dbus one for example) Maybe an einfo would help user to figure out if something breaks.
Created attachment 90822 [details, diff] wxGTK-2.6.3.2.ebuild.patch I added expat and zlib flag because there are also available as USE flag. The first package which indeed breaks because of this patch is wxpython. The C++ wrapper doesn't like the removable of tiff support. I'm heading to upstream to ask why this is not as flexible as wxGTK itself.
Reply to comment #7: zlib is a package that is in the base system profile. It doesn't make much sense to have the ability to not use it - it's mandatory anyway to be present on the system. Also without zlib some virtual filesystem classes in wx won't be available, among other things. expat gets pulled in by many things (including python...), and disabling it will most likely result in the builtin version to be used (leading to the wxexpat dynamic library not shared with other stuff using system expat) or reduced functionality (likely no XRC support, etc) leading to the same maintenance hell that a png USE flag would be, or it will simply not compile (disabling of specific features isn't very well tested upstream - there are virtually millions of possible configure combinations with all the optionality that is exposed). tiff optionality can probably be considered if someone checks which packages need it, and make wxpython not demand it.
mostly agreed. I was working on a patch to remove tiff dep in wxpython but upstream is not really helping. I could only get a template that doesn't depend on tiff unconditionaly but regenerating the bindings was falling for some reason I couldn't get clear with upstream. It seems they are not very interested in this.
after doing some testing i've found png, jpeg, expat, and zlib are absolutely required. tiff would be great (i hate it too). if upstream wxpython ever cooperates, please reopen.
