Opened 15 years ago
Closed 15 years ago
#393 closed defect (fixed)
Consider disabling deprecation warnings when building xapian-core
Reported by: | James Aylett | Owned by: | Olly Betts |
---|---|---|---|
Priority: | normal | Milestone: | 1.0.20 |
Component: | Build system | Version: | 1.0.14 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description
It was reported that Xapian 1.0.14 failed to build in maintainer mode on Mac OS X with recent XCode toolchains because of a deprecation warning on a constructor; when building that constructor, the warning apparently is emitted differently by the XCode gcc build than other warnings, and due to maintainer mode is promoted to an error.
Xapian's own deprecation warnings are unnecessary when building xapian-core itself, since then don't actually mean anything in that context.
We should either disable deprecation warnings when building xapian-core (but obviously retain them when building *against* xapian-core), or have a reason why we aren't doing that. One possible reason is that disabling the warning makes it harder for us to detect internal use of deprecated methods and functions in future.
Change History (3)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Milestone: | → 1.0.20 |
---|---|
Status: | new → assigned |
Type: | task → defect |
Version: | → 1.0.14 |
The actual rune required is:
make 'CPPFLAGS="-DXAPIAN_DEPRECATED(X)=X"'
I've noted this in deprecation.rst in trunk r14339.
Marking for backport for 1.0.20.
comment:3 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Backported to 1.0 as r14340.
It certainly is useful to be warned of uses of deprecated code in xapian-core, as otherwise it would linger until we were forced to remove it by the removal of the deprecated feature, at which point it's more work due to the issues not being fresh in the mind.
The "dogfood" aspect is also potentially useful - the process of updating xapian-core provides some experience of what it is like to migrate away from the deprecated feature, which could catch problematic API changes before we nail them down in a release.
So given I'm only aware of this single instance of this being an actual problem, and they are potentially useful, I'm hesitant to disable them wholesale.
BTW, I think you can temporarily disable them when needed with:
If that works, we could at least document it.