> 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?
Well, when I said "manifest embedding" I meant specifically $(MT) step of the link rule. But if you want to call $@.$$ output from 'script-that-composes-list-of-objects' for manifest, sure you can do that. > It would of course be > possible to have the script you suggest pull data from configdata.pm, > right? Or from Makefile, whichever simplest. > 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. You mean not ready to commit to not changing it as our discretion? Well, then maybe grep-ing Makefile for libcrypto.a: would be more appropriate... _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project