[openssl-project] cppflags, cflags and ldflags

[Andy Polyakov]

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

Well, I didn't say I liked it, but I'd say it would be more appropriate,
because we compare complex relationships between multiple variables vs.
limited amount of "override" rule. Or in other words. Complexity of
working "override" rules is "linear" in sense that it depends on limited
amount of "override" rules, each being isolated[!] so that it doesn't
affect other platforms. While complexity of working with
one-size-supposedly-fits-all thing is "superlinear" and depends on
amount variables times platforms involved.

> 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*,

But my question was about *our* costs.

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

Keyword is "would" here. Since it's obviously not possible (otherwise we
wouldn't have this discussion), then you can only say that it *would*
cost us a little. But this happens in the parallel would-universe, not
here. Of course one can argue that it's appropriate to make this
"investment", because it would solve other problems in future. But thing
is that I do feel that build system complexity is growing beyond
reasonable proportion, and it's because that there is tendency to
consider our costs as negligible to none. Well, one can also say that
letting somebody else do things never worked, as you end up fixing it
anyway. But is it because nobody else can actually solve it, or because
you're not forcing them to work harder for *their* cause. [BTW, wouldn't
the fact that nobody else can solve it be a sign of excessive complexity?]

And once again, [in this odd-ball case] why not a wrapper script that
omits offending options?

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

If we have to upon every introduction of an odd-ball community platform,
then yes.

> 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 $@ ...',

You've mentioned once that it would take a special language to do that
something, and I recall myself thinking "why not just use make syntax".
I'm unsure if I actually said this, but I did think the thought. So that
I for one wouldn't actually be opposed to something like this. It's just
a way to specify "override" rule (and on per-toolchain basis:-).
However! It all depends on whether or not straight make syntax would
actually be expressive enough in the context. If it is, then it would be
totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
if-else in makefile template could turn out to be more appropriate.
(Once again, each clause in if-else is isolated and complexity is
linearly proportional to number of clauses in if-else, which is viewed
as advantage.)

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

You say it yourself, gazillions of little options :-) That's my whole
point :-)

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

Right, I was talking exclusively about non-overridables that *we* rely
upon, those we do not let user override.

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

Right, it's argument for *not* doing it. Note that I opened with "*one*
can argue argue in favour of adding one to capture specifically this."
This is because *I* am *not* doing that, i.e. *not* arguing in favour.
In the essence what I'm saying is that *if* we are to introduce another
variable, then it should rather be something else.

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

I wouldn't be surprised if people end up doing this because there was no
*better* or more adequate solution at some point. I mean humans are
creatures of habit, so it's easy to imagine that somebody had to do
something like this at some occasion and now just keep doing everywhere.
And it can be "multiplied" thanks to Internet. Either way it shouldn't
be something we encourage, because in general case it's error-prone
practice. Just imagine cross-compiling situation...

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

To recap. I'm not suggesting to remove controls that users expect to
find, but at each point consider reducing amount of variables and
dependencies that we use. [And also to not introduce controls that users
don't customarily expect to find, such as CPPDEFINES.]

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

See above.