On Sat, Jan 12, 2019 at 6:01 PM Niels Möller <[email protected]> wrote: > > Jeffrey Walton <[email protected]> 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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
