> With the current build system, user-defined CFLAGS are accepted as any
> unrecognized command line argument passed to Configure. This seems a
> little dangerous to me since it means a simple typo could end up
> getting passed to the C compiler.

Is it more dangerous than interactive access? But on serious note I
don't quite grasp the problem. How do you pass CFLAGS? Or rather how is
it specific to OpenSSL? I mean you either set CFLAGS environment
variable and call 'make -e' or call 'make CFLAGS=something', right? But
this is the way *make* is. Or is suggestion that we should implement own
internal .ext1.ext2 rules independent on CFLAGS?

> As well, the current build system forcibly enables optimization (-O3)
> or debug symbols (-g) depending on the build type (--release or
> --debug).

Could you elaborate on the problem? If you need release build with debug
symbols you can simply add -g when configuring...

> There does not appear to be any method for the user to pass additional
> LDFLAGS to the build system.

You can pass them as arguments to ./Configure script. It recognizes -L,
-l and -Wl,.

> I would like to propose the following changes:
> 
> 1. Read CFLAGS and LDFLAGS from the environment within the Configure script.
> 2. Allow the user to opt-out of the default release or debug cflags,
> perhaps by adding a third build type (neither release nor debug).
> 
> These changes would my job as a distro maintainer on Gentoo Linux just
> a little bit easier.

Or maybe ("maybe" is reference to "I don't quite grasp" above) what we
are talking about is Configure reading CFLAGS and LDFLAGS and *adding*
them to generated Makefile. I mean we are not talking about passing them
to 'make', but "freezing" them to their values at configure time. Could
you clarify?



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to