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

2018-03-26 Thread 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 :-)
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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

2018-03-25 Thread Richard Levitte
Branching a specific thread around these ideas.

In message  on Sun, 25 Mar 
2018 18:45:40 +0200, Andy Polyakov  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project