RFR: 7903933: Move sharable items from different generations to a common file [v4]

[Maurizio Cimadamore]

On Thu, 27 Mar 2025 10:36:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Then there's (6). The first reaction I got was: well, whether primitive layouts should be emitted or not seems like another filtering decision (e.g. let's add some options to filter these out). Except this would not work -- it's not just about filtering -- it's also about telling every other file where to find the layouts for such primitive types. If they are defined somewhere else, then jextract need to know _where_ to find them (e.g. if they are referenced by some other layout jextract is building). Which seems a similar problem as the one this PR is trying to solve anyway.

Also on this topic: for now we're mostly concerned about different extractions not repeating the code for primitive layouts and helper functions. This feels more like a "tip of the iceberg" kind of situation. For instance, you might have two libraries A and B, which both include the header of some third library C. Maybe you want to extract C separately, and then extract A and B so that they somehow magically point at the extracted bindings for C. Now sharing would be not just about primitive types, but about functions, structs and much more.

At the same time, going down this path can be very complex: A and B might pull in slightly different versions of C, or use some `#define` macro directives which would alter the shape of the generated bindings in C. In which case reusing the same bindings for C would be more difficult.

So, hidden somewhere in here there's a theme of: how do we move jextract to go from a per-extraction set of bindings to a multi-extraction friendly model. And going down this path will likely, I think, result in opening a big and complicated can of worms. I'm not saying we'll never get there -- but there's a limit with what we can express with simple command line options.

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

PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2757571433