On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <[email protected]> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
>> optimize vector math operations by leveraging the SLEEF library. For legal 
>> reasons the actual contribution of the SLEEF files needs to be handled 
>> separately. This enhancement adds the relevant files, enabling the rest of 
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update README to include RISC-V

I think this will need some discussion to get it right, both from a
a) source layout/organization, and
b) build system perspective.

We're doing something that is quite new to the JDK source code base and build 
system, after all.

Some questions that needs to be answered:

* Do we store the full source code "off tree", e.g. like in `src/utils/spleef`, 
just for reference? And then store the generated files that are actually 
compiled in the "proper" place, like `src/java.base/native/libspleef`. Doing it 
this way will simplify the build. It will possibly also simplify for 
developers, since they can look at the actual code that is compiled and used.

* Or do we store the complete code base at e.g.  
`src/java.base/native/libspleef`, but filter out that from the build, and 
instead have the generated files in something like  
`src/java.base/native/libspleef/preprocessed-src`? I think that sounds like a 
bad idea, in general. It would be confusing, harder to implement in the build, 
and overall not generally helpful for the understanding of the code base.

* Or do we only store the complete code base at e.g.  
`src/java.base/native/libspleef`, and generate the preprocessed files at build 
time, every time we build? That would in effect mean we incorporate the 
libsleef build in our system, including all their dependencies. The advantage 
is that it would make the source code placement logical, but it would be a hard 
hit on how we build the product. 

* If we chose to check in pre-processed sources, where should the logic for 
doing the pre-processing reside? As part of configure, make, or a separate 
script? My spontaneous reaction is to have it as part of the build system, like 
 `make update-spleef-source`, but there might be more to it. For checking 
requirements, configure is the general go-to place.
I am not a fan of the idea of having a specially hacked shell script dropped 
down in the middle of the spleef sources. :-(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2315158159

Reply via email to