Handling deprecated GNOME symbols
Hi All,
A while ago I added checks in configure.ac to ensure that deprecated library symbols don't get used. However, this approach is probably *too strict* to be included in a stable release... for example, it will cause build-failures that are not "our fault" when the following conditions occur:
* inkscape depends on library-A and library-B * inkscape disables deprecated symbols from library-B * library-A depends on deprecated symbols in library-B.
This situation is currently causing build failures on Ubuntu Raring because it provides Glibmm 2.34.1, which depends on newly-deprecated symbols in glib 2.35.7.
So... we need to consider our approach. Options:
1. Unconditionally allow all deprecated symbols in all libraries. (i.e., remove all the checks I introduced in configure.ac). This would prevent breakage when new deprecations are introduced... but would potentially mean nightmarish migration tasks in the future (as with the GTK+ 3 migration)!
2. Keep the deprecation checks for all libraries: We'd then need to keep fire-fighting the build breakages in distros. Not a good idea in my opinion!
3. Keep the deprecation checks only for high-level libraries: i.e., Gtkmm depends on gtk+ and glib, so we can guard against using deprecated gtkmm stuff but not the others.
4. Add a configuration flag for developers' use (something like "--enable-strict-build") that introduces the deprecation checks. My preferred option... but would people actually use it?
5. Something else?
Any thoughts?
AV
2013/2/13 Alex Valavanis <valavanisalex@...400...>:
- Add a configuration flag for developers' use (something like
"--enable-strict-build") that introduces the deprecation checks. My preferred option... but would people actually use it?
This is the only workable solution, but the option should have the opposite sense, e.g. it should *disable* the checks. This way configuring without any options will enable these checks by default, while the release manager will run configure with a "--release" option and disable them when generating the tarball.
I think a similar option may already exist - if it does, disabling the checks could be hooked up to the existing option.
Regards, Krzysztof
Hi All,
I've added a configuration option for this. By default deprecated symbol usage is forbidden. Two alternative options are available:
# Use very strict deprecation checks that will cause builds to fail. This is useful for hunting down problems that will arise in future --enable-strict-build=high
# Don't check for deprecated symbol usage. This is useful for releases. --disable-strict-build
If anyone thinks we should do this differently, please speak up!
AV
On 22 February 2013 01:37, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2013/2/13 Alex Valavanis <valavanisalex@...400...>:
- Add a configuration flag for developers' use (something like
"--enable-strict-build") that introduces the deprecation checks. My preferred option... but would people actually use it?
This is the only workable solution, but the option should have the opposite sense, e.g. it should *disable* the checks. This way configuring without any options will enable these checks by default, while the release manager will run configure with a "--release" option and disable them when generating the tarball.
I think a similar option may already exist - if it does, disabling the checks could be hooked up to the existing option.
Regards, Krzysztof
participants (2)
-
Alex Valavanis -
Krzysztof Kosiński