Based on the bug report submitted to meson, I've analyzed the geany build.
The problem is here: https://github.com/geany/geany/blob/f0e3ee273e67387f85506ea629b9dbe34d47b8ca...
All `HAVE_` cdatas are defined to be either integer 1 or boolean false. This means it's impossible to refer back to them.
The purpose of the cdata is to generate config.h, so the consequence of this looks like this:
meson.build: ```meson cdata.set('HAVE_BOOL', true) cdata.set('HAVE_NO_BOOL', false) cdata.set('HAVE_INT', 1) cdata.set('HAVE_NO_INT', 0) ``` produced config.h: ```h #define HAVE_BOOL
#define HAVE_INT 1
#undef HAVE_NO_BOOL
#define HAVE_NO_INT 0 ```
The logic you are using assumes that if you have a feature, the code is using `#if HAVE_THING` and the value must be 1, defining it without setting a value is not sufficient. Conversely, that if you don't have a feature, the code is using `#ifdef HAVE_THING` and the value is irrelevant, so setting the value to 0 would erroneously report the feature as available.
These states can't both be true, though... it is either or. Alternatively, it could be "either or, but on a per define basis".
However, grepping through the codebase quickly I can only find cases where `#ifdef` / `#if defined()` are used, plus scintilla/gtk/ScintillaGTKAccessible.cxx which is only using its own defines set at the top of that file. Can you just use true instead of 1?
...
Unfortunately, doing a version check will not accomplish anything whatsoever, the value isn't different depending on the version of meson -- the value is different depending on what headers and functions your system has.