On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry <luhe...@openjdk.org> wrote:
>>> > I can't tell what problem we're trying to solve by not simply checking in >>> > the source code, in its preferred form, to the OpenJDK tree. Thhis has >>> > practical advantages to do with traceability and security, and >>> > in-principle reasons to do with basic Open Source practice too. On the >>> > other side, there are no disadvantages. >>> >>> Do you suggest to copy the whole sleef source repo into jdk? >> >> I think so, along with scripting that generates the preprocessed file we >> use. It might be the case that there are some sleef files not used at all >> they could be omitted, but I'm not sure it would be useful, and from a >> traceability point of view it's probably best to grab it all, unless it's >> really huge > >> > > I can't tell what problem we're trying to solve by not simply checking >> > > in the source code, in its preferred form, to the OpenJDK tree. Thhis >> > > has practical advantages to do with traceability and security, and >> > > in-principle reasons to do with basic Open Source practice too. On the >> > > other side, there are no disadvantages. >> > >> > >> > Do you suggest to copy the whole sleef source repo into jdk? >> >> I think so, along with scripting that generates the preprocessed file we >> use. It might be the case that there are some sleef files not used at all >> they could be omitted, but I'm not sure it would be useful, and from a >> traceability point of view it's probably best to grab it all, unless it's >> really huge > > Given the Sleef build system currently uses cmake, we would have two choices > to build the header files as part of the OpenJDK build system: > 1. take a dependency on cmake in order to build the Sleef headers > 2. write a custom build system for Sleef to integrate into OpenJDK > > Neither approach sound good to me as a mandatory option. > > However, if we are to allow the person building OpenJDK to _optionally_ > generate the headers from a Sleef source checkout (provided by the user with > a `--with-sleef-src=/path/to/sleef`), we can then more easily take the > assumption that the user has installed the necessary dependencies. That would > also be in line with how binutils is being built and integrated. > _On a slightly separate note (and I see @luhenry is in this comment thread > too and has contributed to SLEEF) it will be good if this can be used to > enhance the performance on RISC-V too in the future ;-)_ We already had a prototype which depends on this pr, and the performance gain is promising. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230579500
