[openssl-project] rule-based building attributes
Richard Levitte
levitte at openssl.org
Mon Mar 26 14:37:19 UTC 2018
In message <072aaeb6-59b9-0e8a-f33e-35572350c8e0 at openssl.org> on Mon, 26 Mar 2018 14:15:24 +0200, Andy Polyakov <appro at openssl.org> said:
appro> > So no, a straight makefile rule for a config attribute value isn't
appro> > going to be good enough.
appro>
appro> How about this. We have touched this when discussing windows-makefile. I
appro> mean when I called it VC-specific, you disagreed, and I said that
appro> embedding manifest effectively makes it VC-specific. In the context I
appro> also suggested post-link stage, a command one could *add* to rule. Or
appro> let's rephrase this and say that you can simply specify multiple
appro> commands in an override rule. So with this in mind.
appro>
appro> link => [ 'script-that-composes-list-of-objects $@.$$',
appro> 'link -o $@ -list $@.$$' ]
So zooming in on this particular idea, I was concerned about how those
object file names would be passed to the script... but then you
mention manifests, and it dawns on me that there's *nothing* stopping
us from generating a file with the list of object files when building
the Makefile. That does make some kind of sense to me.
Or were you thinking something different? It would of course be
possible to have the script you suggest pull data from configdata.pm,
right? But considering we're talking about third parties building
their own, that raises another concern, that we suddenly give the
whole %unified_info structure public exposure that I'm not entirely
sure were ready for. Most of it is pretty straight forward (at least
to me, but that's no big surprise), but I have the nagging suspition
that there may be details that will get people stumped, and that will
hit us back. It's possible, though, that I'm more concerned than
necessary...
(quite frankly, I was hoping we could avoid the proliferation of a
gazillion little scripts, but perhaps that's too much to hope for.
C'est la vie)
appro> Of course I'm not suggesting to take this for immediate
appro> implementation, these are just ideas to ponder about. They
appro> might turn unusable (or give a spark for some other idea :-)
Agreed, and I have the same intention.
--
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project
mailing list