Currently, the wxGTK ebuild builds with compatibility for the 2.4 version of the library. This could be an issue since the library doesn't enforce 2.6 clean code. A developer could make the mistake to mix 2.4 and 2.6 features, so a good way to avoid such a possible mistake is to disable 2.4 compatibility. See it as an aid for the wxWidgets developer. Actually, there's a config flag called --disable-compat-24 or something, so I guess it could be straight forward.
This has several problems: a) We need to ensure no wx using applications in portage use deprecated API and patch everything that does b) It changes ABI compared to the 2.6 versions we already have, and that's a no go, as everything linking to wx would break on a wxGTK revbump c) Users will be unable to use the system wxGTK for out of tree applications that need the deprecated methods. Remember that not everyone is a programmer, but many using Gentoo know how to ./configure && make
(In reply to comment #1) > This has several problems: > > a) We need to ensure no wx using applications in portage use deprecated API and > patch everything that does > b) It changes ABI compared to the 2.6 versions we already have, and that's a no > go, as everything linking to wx would break on a wxGTK revbump > c) Users will be unable to use the system wxGTK for out of tree applications > that need the deprecated methods. Remember that not everyone is a programmer, > but many using Gentoo know how to ./configure && make > There is the possibility that most of the wxGTK based applications are being developed using wxGTK-2.4 library, then, dependency for those applications could point to that specific version of wxGTK.The only problematic situation is for those bad written applications that use wxGTK-2.6 library as wxGTK-2.4. But then again, wxGTK-2.8 has been released today, so... you know what that means... in the immediate future I'll do ./configure && make I'm not sure Qt-2 based applications are being available in portage, what will be the issue with wxGTK-2.4 now that wxGTK-2.8 is ready ? Is wxGTK-2.8 backward compatible with wxGTK-2.4 ? and if it's not ? How many applications/dev-tools use wxGTK ?
(In reply to comment #2) > There is the possibility that most of the wxGTK based applications are being > developed using wxGTK-2.4 library, then, dependency for those applications > could point to that specific version of wxGTK.The only problematic situation is > for those bad written applications that use wxGTK-2.6 library as wxGTK-2.4. Many applications compile and work with both wxGTK-2.4 and wxGTK-2.6, but often for that to be easily possible without patching is to have 2.4 compatibility in 2.6. > But then again, wxGTK-2.8 has been released today, so... you know what that > means... in the immediate future I'll do ./configure && make > I'm not sure Qt-2 based applications are being available in portage, what will > be the issue with wxGTK-2.4 now that wxGTK-2.8 is ready ? wxWidgets standard is to enable the previous stable series compatibility by default, and default to off for 2 series back, and remove the code that is 3 series back. That is, in wxWidgets-2.6 the defaults are --enable-compat-24 and --disable-compat-22, while in wxWidgets-2.8 they are --enable-compat-26 and --disable-compat-24, while the 2.2 compatibility code is removed. Note that this stuff goes for API compatibility, not ABI, and just for some things for easier initial porting, while some porting is historically been always needed to work with a newer stable series (compatibility isn't retained with the flags for everything, just for things that are easy to keep around) > Is wxGTK-2.8 backward compatible with wxGTK-2.4? As the default is --disable-compat24 for 2.8, then not directly. > and if it's not ? How many applications/dev-tools > use wxGTK ? Do you mean wxGTK-2.4, that don't work with newer? Then the answer is that quite a bit still in portage, and they have to be dealt with. wxGTK-2.4 is being phased out and work is starting to be ongoing for getting 2.8 in. To get a good start with the 2.8 SLOT, quite some heavy lifting has to happen before it can be added - one of those includes p.masking or removing 2.4.
We try to stay as close as possible to upstream, and will thus be using the upstream defaults for --enable-compat-2.X.
