SQLITE_CORE macro consistency
(1) By anonymous on 2024-10-23 22:58:02 [source]
The discussion on statically_linking_a_run_time_loadable_extension states that the SQLITE_CORE macro can be defined using -D (without a value) for statically linked extensions.
In the amalgamation the macro is #defined to 1. While most checks for SQLITE_CORE either use #ifndef or if !defined, there are a few #if !, specifically in the fts3, rtree, and icu extension sections.
While it doesn't make a difference in the compiled code it would be nice if #ifndef was used throughout for consistency, especially as this seems to be the common approach to macros in the project- checking for definition rather than value save for those cases where the value has a meaning (e.g. SQLITE_THREADSAFE).
(2) By Stephan Beal (stephan) on 2024-10-23 23:27:48 in reply to 1 [link] [source]
specifically in the fts3, rtree, and icu extension sections.
We'll look into this and patch it accordingly after ensuring that it doesn't break anything. As it stands, we're not aware of any build breakage or misbehavior caused by the inconsistency you've pointed out, which argues for an approach of "if it ain't broke, don't fix it."
(3) By Gunter Hick (gunter_hick) on 2024-10-24 05:23:14 in reply to 2 [link] [source]
In our own custom builds we have several locations where we patch #if to #ifdef because we have set GCC to report all warnings as errors and it complains about an #if symbol not being defined
(4) By Stephan Beal (stephan) on 2024-10-24 05:25:47 in reply to 3 [link] [source]
In our own custom builds we have several locations where we patch...
That is helpful info, thank you. All your patches do is change those 3(?) instances from #if to #ifdef? If so, that's proof enough (for me!) that that's a safe change to make.
(5) By Gunter Hick (gunter_hick) on 2024-10-24 06:01:51 in reply to 4 [link] [source]
Unfortunately there are more than 3 instances and it is more than just the one symbol, but yes, all the patches replace #if with either #ifdef or #ifndef depending on the condition. We are using cvs to consistently apply patches. This will be fun to keep up when we switch to git...
(6) By Stephan Beal (stephan) on 2024-10-24 07:50:47 in reply to 5 [link] [source]
Unfortunately there are more than 3 instances
i was only able to spot the OP's reported 3 using grep:
$ find . -name '*.c' | xargs grep SQLITE_CORE | grep -w if
...
ext/fts3/fts3.c:#if !SQLITE_CORE
...
ext/icu/icu.c:#if !SQLITE_CORE
...
ext/rtree/rtree.c:#if !SQLITE_CORE
(Many other false positives snipped.)
and it is more than just the one symbol
If you'll point them out we can get them cleaned up.
i'll start icu and rtree. fts3's handling of SQLITE_CORE is unusual enough to make me suspect that there was a reason it's the way it is, and i'll wait on confirmation from Dan before touching that one.
src:/timeline?r=ifdef-SQLITE_CORE
This will be fun to keep up when we switch to git...
Help us weed them out and clean them up and you can eliminate that fun altogether :).