[openssl-project] rule-based building attributes (Re: cppflags, cflags and ldflags)

[Richard Levitte]

Branching a specific thread around these ideas.

In message <f46f0fd9-3d08-ae09-42b2-308dedfa3287 at openssl.org> on Sun, 25 Mar 2018 18:45:40 +0200, Andy Polyakov <appro at openssl.org> said:

appro> > Another side thing that I've been thinking of for quite a while, and I
appro> > think you may have argued for even though I feel a bit unsure, and
appro> > that's to support command line attributes as an alternative to that
appro> > increasing amount of specialised attributes, so something like this:
appro> > 
appro> > 	link => '$(CCLD) $(LDFLAGS) -o $@ ...',
appro> 
appro> You've mentioned once that it would take a special language to do that
appro> something, and I recall myself thinking "why not just use make syntax".
appro> I'm unsure if I actually said this, but I did think the thought. So that
appro> I for one wouldn't actually be opposed to something like this. It's just
appro> a way to specify "override" rule (and on per-toolchain basis:-).
appro> However! It all depends on whether or not straight make syntax would
appro> actually be expressive enough in the context. If it is, then it would be
appro> totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
appro> if-else in makefile template could turn out to be more appropriate.
appro> (Once again, each clause in if-else is isolated and complexity is
appro> linearly proportional to number of clauses in if-else, which is viewed
appro> as advantage.)

Straight make syntax will probably not cut it.  How would you pass a
list of object file names to something that might have a limited
command line length, for example?  With nmake, we do have a feature we
can use, the inline file text thing, but others may not be so lucky
(the nonstop case I mentioned is such a case), and one might need to
do a bit of pre-processing with perl-level variables (an idea could be
to have some well defined hooks that users can define values for, such
as function names...  again, this is a draft of an idea).  For
example, imagine that we have something that dumps object file names
into a text file and then expects that file name to appear in the
linking command line (for example, and typically in our case), how do
we pass the text file name to the command line, and where in the
command line?

So no, a straight makefile rule for a config attribute value isn't
going to be good enough.


Coming back to costs, I would think that this direction might actually
reduce it for us as it avoids all those gazillion specialized
attributes (I've grown to dislike them too, FYI), and at the same time
become general enough to help users who want to use our stuff for
their own oddball platform to do so, with our blessing...  and I hope
that it helps us as well.

But, this line of ideas is a major change in the how the config
targets work (although I can see a smooth transition from one to the
other, so it's not like we *have* to wait until OpenSSL 1.2 to
implement it), and it is some work to get through with it.  I see
enough benefits to want to, though, and am currently in the mood of
bouncing ideas as time permits (*).

Cheers,
Richard

(*) no, I haven't forgotten that we have a primary focus in fixing
    stuff that needs fixing before the final 1.1.1 release.  But it's
    Sunday right now, tomorrow will be more focused.

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