Re: [openssl-project] cppflags, cflags and ldflags

2018-03-25 Thread Andy Polyakov
>> Note: this mail follows the discussion on github started here:

In the light of the new evidence presented in one can argue in favour of
splitting -pthread flag to cppflags and ldflags. Yes, but I'd still be
reluctant to formulating it like that. As implied I'm kind of arguing
against too many options/variables/joints and call rather for
simplification than increased complexity. I feel that there are more
efficient ways to cover corner/odd-ball places...
openssl-project mailing list

[openssl-project] cppflags, cflags and ldflags

2018-03-25 Thread Richard Levitte
Note: this mail follows the discussion on github started here:
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

> 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

[1] Just in case you wonder, there is a use case for using the linker
directly instead of using cc as a frontend:


Richard Levitte
OpenSSL Project
openssl-project mailing list