Topic: Concerns on "CONFIG_DEFINED" introduced for rel-2.2
I just saw the last commit
http://www.oofem.org/gitweb/?p=oofem.gi … 776348b924
and I'm positive that this will lead to problems.
oofemcfg and Ecfg doesn't check for the same things. Some parts are overlap (thus the warnings), but this approach with a common "CONFIG_DEFINED" will break any defines that don't overlap
For example;
1. If any of the Elixir headers are ever included before oofemcfg.h in OOFEM, then it would most definitely break OOFEM, since the defines will change for anything that doesn't overlap. (HAVE_MACRO_VA_ARGS, __ENABLE_COMPONENT_LABELS, HAVE_ACCESS, etc.)
2. If oofemcfg.h is included first, then it lead to all the HAVE_X-variables undefined in Elixirs headers. The only case where this breaks is probably when HAVE_BOOLEAN is defined when compiling Elixir.
Conclusion
A library should never have conditional macros in its public headers, so I insist that this is an unfortunate design flaw in Elixir.
However, its just a very small problem actually; Its just HAVE_BOOLEAN in Etypes.h which actually depend on configuration defines. No other header actually needs Ecfg.h.
Comparing to for example PETSc, or glibc, we find appropriately namespaced variables; "PetscBool" and "gboolean" respectively. Elixir should have done something similar itself, e.g. "typdef int E_BOOLEAN;", removing the need to check HAVE_BOOLEAN, and completely rid all Elixirs headers from Ecfg.h dependencies.
A simple search and replace is enough to take care of this.
I have attached a modified a modified Elixir, which uses E_BOOLEAN
It will work without warnings and wont effect any defines in OOFEM.