In message <072aaeb6-59b9-0e8a-f33e-35572350c...@openssl.org> on Mon, 26 Mar 2018 14:15:24 +0200, Andy Polyakov <ap...@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 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
