On Wed, Jun 26, 2019 at 9:22 AM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
I do not understand... In practice a package should not add by itself optimization or debug flags without consent (some --enable- argument), the fact that nettle is doing that is unexpected...
I'm open to discuss how to deal with CFLAGS. Currently, Nettle sets -ggdb3, various warning flags (if compiling with gcc), and it kind-of adds -fPIC, but via different autoconf and make variables.
I think GNU standard is to use something like -g -O by default.
As a developer, I find it convenient to have stricter warning flags and more debug info by default, but that could be tied to an explicit configure argument and disabled by default. When suggesting improvements, please consider recommendations in the GNU coding standards.
Also keep in mind that ./configure defaults are intended primarily to make life easy for the user that runs ./configure manually, perhaps to try out a modification of her own. If you have a packaging framework that runs configure for you, it's expected that package configuration needs to add a couple of explicit arguments to override the defaults.
One small nit... The user owns CFLAGS, and they should not be touched. The place to add library flags is AM_CLFAGS. Later, the Automake machinery will build a recipe like:
some_obj.o : ... $(CC) $(CPPFLAGS) $(AM_CLFAGS) $(CFLAGS) -c $<
The user's CFLAGS always overrides the library AM_CFLAGS to honor the user's freedom.
IF you have a flag that must be present to build an object, then it always gets added to the object. This would show up when building, say, x86 AES source file because the source file must have flags like "-msse4.1 -maes".
AES_FLAGS = -msse4.1 -maes aes.o : aes.c $(CC) $(CPPFLAGS) $(AM_CLFAGS) $(CFLAGS) $(AES_CFLAGS) -c $<
Some folks get quite upset when the freedom is not respected.
Also see https://www.gnu.org/prep/standards/html_node/Command-Variables.html .
Jeff