[openssl-project] cppflags, cflags and ldflags

Sun Mar 25 15:08:01 UTC 2018

In message <7e8cc500-3739-e32a-e036-4c3eb8f28d44 at openssl.org> on Sun, 25 Mar 2018 15:20:54 +0200, Andy Polyakov <appro at openssl.org> said:

appro> > My spin on it goes in a different direction.  It's true that we
appro> > *currently* pass cflags to all stages.  I would argue, though, that
appro> > this is mostly because we assume that the cc command is an appropriate
appro> > frontend for everything involving building the stuff.
appro> 
appro> There is glue that holds it together, and it's makefile template.
appro> Besides, question also is if there is a set of flags that we *have to*
appro> pass at *all* stages. I.e. not just "do", but "have to". Yes, there is,
appro> one example being -m64. One can as well say that it just so happens that
appro> it's now called cflags. Very natural and intuitive choice. *If* we
appro> choose to change that, I'd still argue that collecting multi-stage flags
appro> in one variable would be totally appropriate, at least for platforms
appro> where it works. Like Linux, Solaris, AIX, HP-UX, BSD, Mac OS X,
appro> effectively *all* the platforms we actually directly support. So that in
appro> a sense, this question and reference to odd-ball problem are not
appro> actually that tightly interwoven as suggested. I mean odd-ball problem
appro> is used as an argument *for* excessive variables fragmentation on *all*
appro> platforms, but collecting any specific flag in one variable on vast
appro> majority of platforms doesn't actually contradict the suggestion to
appro> introduce a variable that would be meaningful to one [and fragmenting on
appro> that one].
appro> 
appro> > Enters the odd
appro> > ball that needs to use the linker (som form of ld) directly [1],
appro> > because that's what makes practical sense, or simply because that's
appro> > how things work on that platform, and suddenly, it's obviously
appro> > *inappropriate* to pass cflags on that command.  In assuming that we
appro> > can always pass cflags, we're making live difficult for those who want
appro> > to make things work on platforms that don't quite meet that assumption.
appro> 
appro> Well, it's no news that life is not fair. Two points.
appro> 
appro> We already touched this in Windows context, one option (more suitable in
appro> my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
appro> cube into circular hole, just make square hole on the side. For example
appro> *if* target has ldonly attribute, just emit link rule without CFLAGS,
appro> but with those listed in ldonly.

So you want some kind of flag attributes in the config targets?
That's what 'ldonly' sounds like.  I don't understand how that goes
together with not wanting fragmentation, it mostly seems that you're
arguing for another kind, which results in more hackery in the
Makefile template (another type of fragmentation).

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

Actually, I do imply that cost is an issue.  For example, I think it's
quite costly for *them*, who do have enough of a sh like environment
for unix-Makefile.tmpl to be useful with the exception of a few lines
of changes, to have to make a copy of that template and maintain it
against whatever changes we throw in for the sake of those few lines,
and for this to be repeated by everyone who has a different enough
setup, when changing those few lines wouldn't be that hard on our end.

(VMS' descrip.mms.tmpl is quite different in that way, as it's
designed for a completely different shell (DCL), quite different
commands and a different enough make implementation (mms or mmk), so
there are very practical reason why it's a separate template.  The
same goes, btw, for windows-makefile.tmpl, which is designed for yet a
different shell (cmd), yet a different set of commands and yet another
make implementation (nmake), so same practical reasons there.
I know that you're arguing that they are also designed for specific
compilers, but that was never the intention when I designed them, so
it's more of an incidental thing that really comes down to my
laziness.  And frankly, I have *zero* desire to lock them in
permanently for specific compilers and will not work for such lock
in).

And yeah, I get that the config targets need to be reshaped for this.
That's your main argument, isn't it?  Is that so actually so costly?

Another side thing that I've been thinking of for quite a while, and I
think you may have argued for even though I feel a bit unsure, and
that's to support command line attributes as an alternative to that
increasing amount of specialised attributes, so something like this:

	link => '$(CCLD) $(LDFLAGS) -o $@ ...',

Note that I haven't really thought it through, this is really a draft
of a possible idea, and it might end up having a very different form.
But still, that might be better than the proliferation of gazillions
of little flags, and would probably also help those who want or need
to do certain things slightly differently.

Also, note that I don't think this is appropriate to introduce for
1.1.1, it's waaaaay too late for that.

appro> > So following my spin, I would rather say that any flag that affects
appro> > preprocessing should go into cppflags, any flag that affects linking
appro> > should go into ldflags (the attribute lflags), the rest can go to
appro> > cflags.  And for compartmentalization, I'd like to see that:
appro> > 
appro> > - for preprocessing, only cppflags are used.  (note: this is more of a
appro> >   wishlist, not really terribly important for now...)
appro> 
appro> It has already been established that it doesn't work. Because there are
appro> flags that are customarily viewed as compile-time, but that affect
appro> pre-defined macros that we relay upon. In other words pre-processing has
appro> to be performed with cppflags *and* cflags, just like
appro> compiling.

And do note that I said "wishlist"...  I'm not sure all agree with
you, but not important enough to fight about.

appro> > - for compiling (i.e. source code to object code), cppflags and cflags
appro> >   are used (I cannot see how one would make that differently).
appro> > - for linking, only ldflags should be used.  (this I think is
appro> >   important!)
appro> 
appro> As implied above, there are (and always will be) flags that are
appro> required at *all* stages on quite a number[!] of platforms. So
appro> that one can argue in favour of adding one to capture
appro> specifically this. "target_arch" might be appropriate if one
appro> follows the make's lead. In such case it would be possible to
appro> arrange it as cflags+cppflags+target_arch for pre-processing
appro> and compiling, and as ldflags+target_arch for linking. As it
appro> can be seen cppflags can actually be merged with cflags, so
appro> that cflags+target_arch and ldflags+target_arch would suffice(*).

(I was about to argue, but noticed the '(*)' at the last moment...)

However, you're saying it yourself:

appro> However, target_arch poses a non-trivial practical problem.
appro> Namely how do we know which of the additional flags user passes
appro> as additional arguments to configure belong in target_arch?
appro> With this in mind, i.e. as long as we don't want to get into
appro> business of tracking which additional flags should be assigned
appro> to target_arch, we would be better off passing cflags at all
appro> stages. [And handling odd-ball platform as exception, not
appro> rule.]

Newsflash: it's actually possible to repeat the same flag in more than
one variable!  And this is also something I see people do a little now
and then, so I wouldn't be at all surprised to see something like
CPPFLAGS='-m64 ...' LDFLAGS='-m64 ...' (that would cover all the
bases)...

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

Yes.

You know, while bouncing ideas, whatever we end up doing will be
post-1.1.1, so we have time to argue some more and hopefully end up
with a bunch of ideas to do things better, going forward.  That is,
after all, my desire (as well as generalization as much as possible,
that should probably be clear by now)

Going back to the 'link' attribute as an alternative to a gazillion
specialise attributes, does that seem like an idea to you?  Was that
what you have been trying to argue for some time?  Either way, this
said without locking into a particular form.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/