On Sat, Jan 12, 2019 at 6:01 PM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
I recommend making folks explicitly ask for a debug build with -DNETTLE_DEBUG or similar.
"Debug build" vs "release build" is a bit alien to the way GNU packages are usually built, and I suspect it partly dates to times where optimization and useful debugging info were mutually exclusive. Default builds include both optimization and debugging symbols (and I think that's still what GNU coding standards recommend, perhaps with the option to strip debug symbols at install time).
Regarding asserts, I generally recommend to build with asserts enabled. I know you disagree about that, but I really do *not* want any of us to repeast arguments on that topic on this list. Don't go that way.
I'm happy to support builds with asserts turned off (that's the only reason I'm considering adding a ci builds for that configuration), but it's not going to be the default config.
Not sure a --disable-asserts configura option is that useful, if it's only an alias for -DNDEBUG. What other effects do you suggest --disable-debug or --disable-assert should have?
Don't define it in terms of "not Posix NDEBUG " or "not Nettle NODEBUG".
I'm not following. As far as I understand, assert.h and NDEBUG are part of the C language, not Posix.
(To go out on a tangent, there may be some projects where it's useful to include a *lot* of extra sanity code, and then have a way to exclude it for a "release" build. I think that's a bit rare, though, and I don't think Nettle is that type of project. I seem to recall one of the openbsd developers advocating always deleting the extra sanity check code and debug printfs after the code is in working state, before checking it in, to not distract from the actual code. In contrast to the fairly common practice to leave it in in under some #ifdef under the theory that it might be nice to have in some future debugging session. If it's really motivated to have that sanity check code in at all, because bugs are expected to have particularly subtle and hard-to-debug effects, one may well want that extra correctness assurance also when using the installed program in a "release" build).
My bad, I was speaking to the proposed -DNODEBUG macro presented earlier:
I'm also considering adding a few more configurations to the ci, including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. Anything I have to keep in mind (e.g., limits on builder resources?)
Jeff