I have written a library and I use that library in a program. I often make a change in the program code, run tests with asserts turned on and then if the tests pass I run a benchmark with asserts turned off to measure the performance impact of the change I just made. I also want to turn the asserts on in my library for the tests and to turn them off in the library for the benchmark. So I frequently need to switch the assert setting simultaneously in the program and the library.
Matching the assert settings (NDEBUG) for the library and the program (that uses the library) must not be manual because getting it wrong means undefined behavior as there are asserts in the headers (conflicting definitions causes undefined behavior) and indeed I get a crashing program with GCC when I build an assert-off program with an assert-on library. I haven’t been able to find out what the standard way to do this is. I’m considering having my library build system install two binaries (and possibly headers that complain if they are included with the wrong assert setting (NDEBUG)) named libfoo-1.0 and libfoo-assert-1.0 or something like that.
What is the best way to match the assert setting between libraries and programs in such a way that switching the assert setting in both at the same time is easy, fast and not error prone?
Normally, build systems are set up to do different builds (e.g. debug/release, mutli/single threaded) anyway. The resultant libraries and executables are either placed in different directories or have different names to distinguish them. This is no different.
If you feel you need additional build types for assert/noassert, then just add this additional build type. The only question is the naming convention and what is done by default if no particular build type is specified.