On Thu, 20 Feb 2014 05:16:55 -0500 Alexandre Rostovtsev <tetrom...@gentoo.org> wrote:
> The other unfortunate aspect of the gtk3 flag is that it encourages > using flags instead of slotting for libraries that can support both gtk > and gtk3, resulting in needless rebuilds of when one of the flags is > switched on/off. But again, that could be addressed with a bit of > documentation. Slotting a library by toolkit rather than by version just doesn't work in a lot of cases. Having multiple versions of a library installed is common enough practice and upstreams will often take that into account and version their library names, include paths, pkgconfig files, etc. Most don't do that for different toolkits. So if you're slotting by toolkit you have to start installing one in a non-standard location to prevent file collisions (and it's always the newer toolkit since you don't want to break existing packages), and every new ebuild using that toolkit needs to be changed to look in the right place, and you have to start futzing around with symlinks, and wrapper scripts, and eselect, and eclasses, and every time some dev uses the wrong depend atom you get a bug about it, and it goes on and on and on. Or you can add USE=gtk3, deal with collisions internally, install one set of headers, and go do something productive with your life. wxGTK not only splits up libraries by version and toolkit, but also by charset and debug/release. If we had to use different SLOTs rather than USE flags we would need eight of them for 2.8 alone. And I don't know how we would name the ebuilds (-r100,-r200,... ugh). -- Ryan Hill psn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
