1

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?

Bjarke H. Roune
  • 3,667
  • 2
  • 22
  • 26
  • "I run a benchmark with asserts turned off" In order to have a legitimate benchmark, you need to do a *lot* more than turn asserts on and off. You should be using debug builds for debugging and release builds for benchmarking. – Nicol Bolas Jul 27 '12 at 20:22
  • @nicol bolas That's certainly true! I didn't mention these other issues because I wanted to focus on asserts. – Bjarke H. Roune Jul 27 '12 at 20:36
  • But your problem *isn't* with asserts. It's with linking a debug build with a release build. – Nicol Bolas Jul 27 '12 at 20:38
  • @NicolBolas Release builds can have asserts turned on and indeed this is the default with most autotools projects as far as I can tell - the user is expected to instruct configure to turn asserts off if that is desired. I don't use a debug build (with no optimization) for tests until I actually find an error. Is what you mean that I could instead have asked a question about side-by-side installation of debug/release builds since they have the same sort of issue in that you can't mix them? – Bjarke H. Roune Jul 27 '12 at 21:03

1 Answers1

1

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.

Anon Mail
  • 4,660
  • 1
  • 18
  • 21
  • The issue is that I haven't run into libraries that define different versions on unix systems other than a version number, so I don't know what the standard practice is in terms of naming convention. Would it usually be libfoo-assert-1.0 or libfoo_assert-1.0 or libfoo-1.0-assert or ...? – Bjarke H. Roune Jul 27 '12 at 22:09
  • Other than version numbers, I don't think there is a standard naming convention on Linux but I could be wrong. Look to the boost build system to see what they do. On my system, the various boost library build identifiers (e.g mt for mutithreaded, d for debug) are separated by dashes, not underscores. I'm not sure if my system admins came up with their own naming convention or used something defined in the boost build system. Hope that helps. – Anon Mail Jul 27 '12 at 22:27
  • Found this link on boost naming conventions: http://stackoverflow.com/questions/2715164/how-can-i-decode-the-boost-library-naming – Anon Mail Jul 27 '12 at 22:33