2011/6/20 Eric Blake <eblake@xxxxxxxxxx>: > On 06/19/2011 04:55 PM, Javier Jardón wrote: >> Hello, >> >> I'm looking for the best solution to deal with the deprecation flags >> for Glib/GTK+. >> Most project use them incodiotionally, so releases will break if a in >> Glib/GTK+ deprecation is introduced. I think most projectrs do not use them at all. :-) In fact, I have intentionally left them out from configures of all the packages I maintain. gtk+ deprecation usually happens at the same time than new way to achieve something is introduced. So by fixing deprecations you at the same time make that version of gtk+ minimum requirement for your package. Usually some backward compatibility is prefered over code that uses no gtk+ features that have been deprecated in latest version. I ever set deprecation flags only when I have specifically set up environment with our minimum gtk+ requirement. Anything that's deprecated in that gtk+ version already, can (and should) be fixed. To make those rare builds there's hardly need for specific support in configure script, setting CFLAGS is enough. - ML _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
