On Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley <a...@openjdk.org> wrote:
>> Hamlin Li has updated the pull request incrementally with one additional >> commit since the last revision: >> >> skip TANH > >> Currently, >> >> * in [8329816: Add SLEEF version 3.6.1 >> #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef >> inline headers from sleef 3.6.1, which is tagged in sleef repo. >> >> * And with the script in [8329816: Add SLEEF version 3.6.1 >> #19185](https://github.com/openjdk/jdk/pull/19185), anyone with access to >> sleef repo can re-generate these inline headers by himself > > Right, but think about package builders. This isn't about J Random Hacker > doing it by hand. > > When a package gets built, the builder machine unpacks source code. If SLEEF > is included as part of JDK source, all the builder has to do is run the > script and overwrite whatever preprocessed source is in there. The > alternative is packaging the SLEEF source code tarball separately in the > OpenJDK source package. Sure, all of this can be done, but it's a question of > whether we do it once, here, now, or all the downstream builders have to do > it themselves. > >> ( in fact anyone can generate the inline headers from sleef from scratch >> without using scripts in [8329816: Add SLEEF version 3.6.1 >> #19185](https://github.com/openjdk/jdk/pull/19185), our script just make it >> easy for the future maintenance), so it's easy for anyone to verify these >> inline header files used in jdk. > > That script must be checked in to the OpenJDK tree. > >> With these 2 points, seems the traceability is fine to me, please kindly >> point out if I missed some points. Maybe we can add some more clear and >> specific information in README or createSleef.sh in #19185 to indicate which >> version of sleef source we're using in jdk. >> >> I'm also fine with your suggestion to add whole sleef repo into jdk (maybe >> we can remove some of files, but we can ignore the difference temporarily in >> the dicussion here). To copy the sleef repo into jdk, we still need to >> pre-generate the inline header files, and check them in jdk along with the >> sleef repo, I think you also think so too > > Yes. > >> (As without checking in these inline headers, we will have to bring some >> extra dependencies into jdk, and increase extra compilation time when >> building jdk). But from traceability point of view, seems to me it does not >> bring extra benefit than current #19185. For example, if someone want to >> verify the pre-generate inline headers in jdk, he need to first verify the >> sleef source in jdk, then the pre-generated sleef inline headers. > > You don't need to verify the pre-generated inline headers, just overwrite > them. The point is that the sleef source is di... @theRealAph Thanks for clarification. I think there are several different parts involved in the above discussion, please kindly correct me if I misunderstood. 1. package builders. This is about the release of jdk (both src and binary), by either openjdk, adoptium, or any other downstream vendors. 2. jdk daily development. This is about to modify, build, run/test jdk daily by jdk developers. For the package builders, original sleef source is necessary; for the jdk daily development, only pre-generated sleef inline headers are necessary. The script to pre-generate sleef inline headers is only triggerred by package builders (and I think it involves some scripts which are not part of jdk source ? e.g. the script to trigger pre-generating script), but for jdk daily development, we just need pre-generated sleef inline headers. Am I understanding correctly above? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230456463
