Build should succeed if QT_NO_CAST_FROM_ASCII is defined
This is going to regress unless `make check` checks it.
(In reply to comment #1) > This is going to regress unless `make check` checks it. > Indeed, but this is an optional flag that we support. We can't make it mandatory. I can't think of any Qt application that makes QT_NO_CAST_FROM_ASCII mandatory. What happens is that from time to time we should build using this flag and check if everything is ok.
(In reply to comment #2) > (In reply to comment #1) > > This is going to regress unless `make check` checks it. > > Indeed, but this is an optional flag that we support. We can't make it > mandatory. Am I right in thinking that QT_NO_CAST_FROM_ASCII is like G_DISABLE_DEPRECATED or -Wsomething, in that it disables questionable functionality without altering the API/ABI that we export? If so, why can't we make it mandatory for the compilation of telepathy-qt4 itself? (I agree that we shouldn't make it mandatory for the compilation of *projects that depend on* telepathy-qt4.) If the cast-from-ascii version needs testing too, perhaps we could re-enable casting to/from ASCII in $(DISTCHECK_CONFIGURE_FLAGS), so the best-practice version happens normally, and the other version happens during distcheck? (This mirrors the situation for debug code in telepathy-glib, which is on by default, but is switched off during distcheck to check that the library still builds.) If that's also problematic for some reason, doing the opposite (checking QT_NO_CAST_FROM_ASCII at distcheck time) could be used as a last resort.
Branch updated. Added -DQT_NO_CAST_FROM_ASCII to ERROR_CXXFLAGS
Fixed upstream. It will be in next version 0.3.0
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.