[openssl-project] cppflags, cflags and ldflags

[Andy Polyakov]

> 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.

There is glue that holds it together, and it's makefile template.
Besides, question also is if there is a set of flags that we *have to*
pass at *all* stages. I.e. not just "do", but "have to". Yes, there is,
one example being -m64. One can as well say that it just so happens that
it's now called cflags. Very natural and intuitive choice. *If* we
choose to change that, I'd still argue that collecting multi-stage flags
in one variable would be totally appropriate, at least for platforms
where it works. Like Linux, Solaris, AIX, HP-UX, BSD, Mac OS X,
effectively *all* the platforms we actually directly support. So that in
a sense, this question and reference to odd-ball problem are not
actually that tightly interwoven as suggested. I mean odd-ball problem
is used as an argument *for* excessive variables fragmentation on *all*
platforms, but collecting any specific flag in one variable on vast
majority of platforms doesn't actually contradict the suggestion to
introduce a variable that would be meaningful to one [and fragmenting on
that one].

> 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.

Well, it's no news that life is not fair. Two points.

We already touched this in Windows context, one option (more suitable in
my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
cube into circular hole, just make square hole on the side. For example
*if* target has ldonly attribute, just emit link rule without CFLAGS,
but with those listed in ldonly.

Another option is wrapper. Instead of struggling with ever-increasing
amount of options to accommodate one[!!!] odd-ball platform, why can't
*they* provide a wrapper script that would omit offending options prior
calling the linker? [BTW, we do have an odd-ball platform, VMS, so why
can't this odd ball handled similarly, i.e. with own template? Too
expensive you'd say. Well, why not make *them* bare the cost? But even
if not, formally speaking ever-increasing amount of
variables/options/joints and complex relationship among them all has its
cost too. And by suggesting to solve it in this specific way you kind of
imply that cost is not an issue here. How come?]

> 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...)

It has already been established that it doesn't work. Because there are
flags that are customarily viewed as compile-time, but that affect
pre-defined macros that we relay upon. In other words pre-processing has
to be performed with cppflags *and* cflags, just like compiling.

> - 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!)

As implied above, there are (and always will be) flags that are required
at *all* stages on quite a number[!] of platforms. So that one can argue
in favour of adding one to capture specifically this. "target_arch"
might be appropriate if one follows the make's lead. In such case it
would be possible to arrange it as cflags+cppflags+target_arch for
pre-processing and compiling, and as ldflags+target_arch for linking. As
it can be seen cppflags can actually be merged with cflags, so that
cflags+target_arch and ldflags+target_arch would suffice(*). However,
target_arch poses a non-trivial practical problem. Namely how do we know
which of the additional flags user passes as additional arguments to
configure belong in target_arch? With this in mind, i.e. as long as we
don't want to get into business of tracking which additional flags
should be assigned to target_arch, we would be better off passing cflags
at all stages. [And handling odd-ball platform as exception, not rule.]

(*) Obviously modulo fact that we probably want to keep CPPFLAGS,
because that's what users would expect they can affect.