This is a very handy feature of the JVM and JAR file structure. We can replicate it in C++, but it will require some platform-specific tooling. Some cursory search shows that ld can do this for us: https://stackoverflow.com/a/11622727
Interestingly, the asm then required to access the objects will need to be JIT compiled, so we'll have to see how well that works and if the symbols can be found.
I think there are other approaches which don't embed resource into the executable itself, such as AppImages, but they're even less cross-platform. I would like for jank's AOT compiled programs to just be standalone, but I will settle for AppImages if necessary.
So, the way this would look is that jank needs to:
Know the resource paths
Provide some functions á la io/resource
Search the resource paths (on the fs)
Fall back to searching the resource paths within the application
During AOT compilation, bundle all files within the resource paths into the application and build a map of file path -> pointer+size
Ensure all of this works on Linux and macOS (Windows will need special handling and is not a high priority for jank at this time)
This is a very handy feature of the JVM and JAR file structure. We can replicate it in C++, but it will require some platform-specific tooling. Some cursory search shows that
ldcan do this for us: https://stackoverflow.com/a/11622727Interestingly, the
asmthen required to access the objects will need to be JIT compiled, so we'll have to see how well that works and if the symbols can be found.I think there are other approaches which don't embed resource into the executable itself, such as AppImages, but they're even less cross-platform. I would like for jank's AOT compiled programs to just be standalone, but I will settle for AppImages if necessary.
So, the way this would look is that jank needs to:
io/resource