On Tue, 16 Jul 2024 09:48:55 GMT, Andrew Haley <a...@openjdk.org> wrote:
>>> 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 ... > >> @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 > > may be > >> necessary; for the jdk daily development, only pre-generated sleef inline >> headers are necessary. > > Yes, most of the time. Some devs will want to be more thorough. > >> 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), > > No: all of the scripts to generate the preprocessed source from the SLEEF > source must in the OpenJDK source. > >> but for jdk daily development, we just need pre-generated sleef inline >> headers. Am I understanding correctly above? > > Yes, most of the time. > > Bear in mind that convenient daily development of OpenJDK is important, > because we don't want to discourage developers. But we've never treated the > size of the repo as one of our primary considerations. @theRealAph I see, I think now I understand the whole picture of your concerns. Thanks! > I think the key question is whether we're comfortable relying on/pointing at > an external repository which may or may not be there tomorrow and/or where > tags may change outside of our control. > The SLEEF source code looks to be around 7.5MB, give or take. That's not > enormous, but it's not exactly small when keeping in mind that if we #include > it in the jdk repo it's going to be there for every cloned repo in every > project/branch and very few will actually care about it. I agree that we'd > still have to include the pre-generated header files. > Hence my suggestion to consider putting it under our control, but in a > separate openjdk controlled repository. Based on @vidmik 's previous comments, I think we all agree original sleef source should be added into jdk, including pre-generated sleef inline headers, the only different opinions between us are about how to include sleef source into jdk, one is to just add it into jdk repo itself, another is to put it in another repo which is under control of jdk. Please kindly correct me if I misunderstood. I have not particular preference which options to take. My only concern is how long it will take to make that decision. If it could take rather long time, can we take several incremental steps to achieve the final goal? e.g. 1. add pre-generated sleef inline headers into jdk, which is done by https://github.com/openjdk/jdk/pull/19185 2. support vector math in jdk, which is done by this pr. 3. add sleef source into either jdk repo itself or another repo under control of jdk. I think we have plenty time to achieve the final goal in jdk-24. How do you think about it? @theRealAph @vidmik @luhenry @magicus @erikj79 ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230571779
