I am currently developing a library in C, using meson.build. The library contains several dependencies and I'm using wrap-files and fallback-arguments in the meson-build to integrate these dependencies as subprojects.
I'm now aiming to build the entire project, including its dependencies, in one build-step in order to e.g. consistently build and link everything with -fsanitize=address (another use-case may be differing compiler-/linker-flags). In order to do so, I use the -Dwrap_mode=forcefallback flag for meson.
However, one of the dependencies is harfbuzz (https://github.com/harfbuzz/harfbuzz). I figured out that it is impossible to build harfbuzz with the given flag. This is mainly caused by multiple config.h-files. Specifically I overall get this list of config-files in my build-directory after the configuration step:
$ find . -name config.h
./config.h
./subprojects/pixman/pixman/config.h
./subprojects/glib-2.74.1/config.h
./subprojects/gperf/config.h
./subprojects/pcre2-10.40/config.h
./subprojects/cairo/config.h
The pixman-library itself will check the include-order and as a different config.h-file is chosen in contrast to the pixman-specific one, it will complain with an #error-directive. It is therefore currently impossible to build harfbuzz with the -Dwrap_mode=forcefallback-flag.
Libpixman itself does not use meson-build-subprojects, despite offering meson-build files. Otherwise the problem might have been visible therein already (it contains the glib-2 dependency by itself already).
My question is therefore related to meson-build best practices: How could I ensure in such a scenario that every subproject will always choose its own config.h? Or is it better to create a config.h in the upstream project that - depending on the chosen subproject structure - is always able to replace every config.h of every subproject?
