On 08/06/2015 06:01 PM, Krzysztof Kosiński wrote: > 2015-08-03 14:59 GMT+02:00 Kalev Lember <[email protected]>: >> How does this play with gtkmm 2.4? If glibmm now requires C++11, does it >> mean that gtkmm 2.4 and legacy apps that are still on gtkmm 2.4 need to >> be built with std=c++11 as well? > > My understanding is that using C++11 and the ABI break are independent > of each other.
Yes; that's actually not what I wanted to know :) Thanks for the very detailed answer though! Let me try to reword my question: First of all, this is with my Fedora package maintainer hat on. Fedora and other distros ship a number of applications based on the gtkmm stack. But it's not just one gtkmm stack; there's actually two: we ship parallel installable gtkmm-2.4 and gtkmm-3.0 and a large number of apps; some of which use gtkmm-2.4 and some of which use gtkmm-3.0. Both the gtkmm-2.4 stack and the gtkmm-3.0 stack use the same glibmm version. Now, my question was what happens with the older gtkmm-2.4 if we end up importing a new, C++11 using glibmm into Fedora. glibmm hasn't (at least yet) changed ABI, so things should continue running fine. However, are things going to continue to _build_ fine? Does the gtkmm-2.4 stack (and, more importantly, apps that are using it) need any code changes to continue building with the updated glibmm? Just trying to find out here if legacy apps are going to need code changes to continue building. What I am getting at here is that if legacy gtkmm-2.4 apps are going to need code changes, I am wondering if it might make sense to deliberately break glibmm API (make it parallel installable with older glibmm) so that new C++11 based gtkmm can use the newer C++11 glibmm API and gtkmm-2.4 and apps based on that can continue using the older glibmm-2.4 API without needing code changes. Thanks, Kalev _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
