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

[Andy Polyakov]

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

These are actually two different problems, aren't they? I mean a) how do
you pass, and b) what if there is some limitation. As for former. Even
though it spells "use make syntax", it would still be rather
"make-*like* syntax". In other words it doesn't mean that you will be
able to just copy referred line into makefile, it would still have to be
processed somehow first. Well, in case at hand it might be possible to
drop a rule with $+ if you know you'll use GNU make, but others don't
understand it, so $+ would have to be processed. (And even in GNU make
case to keep things unified.) So you end up using mostly-make-like
syntax to formulate an override rule, but you do some replacements
before emitting actual rule into makefile. Naturally one might have to
make up more internally recognized make-looking idioms, in addition to
$+ that is...

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

Do you mean that you have like 'libcrypto.so: all-the-object-files' and
want a rule that would put all-the-object-files into text file and
invoke linker with that file name as argument? And putting them into
text file may not exceed a length limit either, so that you can't say
for example 'echo $+ > o-files.$$.' either...

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

How about this. We have touched this when discussing windows-makefile. I
mean when I called it VC-specific, you disagreed, and I said that
embedding manifest effectively makes it VC-specific. In the context I
also suggested post-link stage, a command one could *add* to rule. Or
let's rephrase this and say that you can simply specify multiple
commands in an override rule. So with this in mind.

link => [ 'script-that-composes-list-of-objects $@.$$',
          'link -o $@ -list $@.$$' ]

Well, in this particular case you'd probably be more interested to
specify multi-line command instead of multiple commands. As '(trap "rm
-f $@.* INT 0; script ... && link ...)', because you might want to clean
up temporary file even if make is interrupted. But multi-line can be
useful if different lines reside in different templates. I mean base
template can say "link" and target can add a post-link command.

Of course I'm not suggesting to take this for immediate implementation,
these are just ideas to ponder about. They might turn unusable (or give
a spark for some other idea :-)