search

ta0kira / zeolite

Zeolite is a statically-typed, general-purpose programming language.
Apache License 2.0
18 stars 0 forks source link

Figure out how to make modules relocatable rather than requiring them to stay where they were built. #197

Open ta0kira opened 2 years ago

ta0kira commented 2 years ago

The goal is to be able to create a prebuilt zeolite package that isn't going to complain about out-of-date libraries the first time the user attempts to compile something.

Since .zeolite-cache/compile-metadata for those modules would be included in such a package, one possibility is to add a flag that can be manually edited to disable timestamp checks. Importantly, the flag shouldn't exist in a file that will be checked into the repo, e.g., .zeolite-module.

Related to this, it might be necessary to allow a custom Config.LocalConfig.rootPath during cabal install and a temporary override during zeolite-setup so that the compiled binaries and libraries can be packaged and then installed in a different location. Maybe this can be a special mode that automatically disables timestamp checks for the standard libraries.

ta0kira commented 2 years ago

One additional problem with making modules "relocatable" is that file paths are absolute in .zeolite-cache/compile-metadata, and dynamic linking also uses absolute paths.

So, actually making it so that you can prebuild the compiler+libraries and also prebuild other packages containing binaries/libraries that depend on it could require a lot of compiler changes.

That said, I think the issues below are the only ones that can't be solved by just editing compile-metadata:

  1. Freshness check. It would be easy enough to add a field to compile-metadata to change the freshness check to only check for existence of the files required to compile/link to the module, i.e., .0rp, .hpp, .so, .o, .a files.
  2. Absolute vs. -rpath path resolution for dynamic linking. IT would be easy to use -rpath-link during linking, but then it's less clear how to refer to the library and where to actually put it, since the names are public_12345.so, etc.

On the other hand, there's a reason for how Zeolite modules are structured, and it doesn't make much sense to try to make it look like a C library with headers in one place and libraries in another. For comparison, Python has its own way to structure/resolve modules.