Note: this mail follows the discussion on github started here:
https://github.com/openssl/openssl/pull/5742#discussion_r176919954
That discussion started as a simple side note, but I should probably
have known better... it ends up derailing a PR that shouldn't really
be affected, so I'm bringing the discussion here.
The discussion is about the division of flags for the different parts
of building programs, shared libraries and DSOs.
So we have one side that argues for putting the majority of the flags
in the cflags variable / config attribute. To quote from the github
discussion:
> Or to put a little bit more practical spin on it. Since we *do* pass
> cflags at *all* stages, it's only appropriate to assign multi-stage
> flags [such as -pthread] to cflags. Viewing it from another angle,
> only pure single-stage flags [such as -L ,-l, -I, -D] are
> appropriate to separate as make variables. And to variables specific
> to corresponding stage, not some other grouping. Last remark is
> reference to the fact and if one follows suggested logic [that
> presented classification imposes specific separation as make
> variables], you'd have to pass -L at pre-processor stage and -I at
> linker, because they both are listed in "Directory Options".
My spin on it goes in a different direction. It's true that we
*currently* pass cflags to all stages. I would argue, though, that
this is mostly because we assume that the cc command is an appropriate
frontend for everything involving building the stuff. Enters the odd
ball that needs to use the linker (som form of ld) directly [1],
because that's what makes practical sense, or simply because that's
how things work on that platform, and suddenly, it's obviously
*inappropriate* to pass cflags on that command. In assuming that we
can always pass cflags, we're making live difficult for those who want
to make things work on platforms that don't quite meet that assumption.
So following my spin, I would rather say that any flag that affects
preprocessing should go into cppflags, any flag that affects linking
should go into ldflags (the attribute lflags), the rest can go to
cflags. And for compartmentalization, I'd like to see that:
- for preprocessing, only cppflags are used. (note: this is more of a
wishlist, not really terribly important for now...)
- for compiling (i.e. source code to object code), cppflags and cflags
are used (I cannot see how one would make that differently).
- for linking, only ldflags should be used. (this I think is
important!)
[1] Just in case you wonder, there is a use case for using the linker
directly instead of using cc as a frontend:
https://github.com/openssl/openssl/issues/5087
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
