With save/load discussed in #11 raises a question about saving for portability purposes.
If a user has built a Selene instance, they may wish to send it to a friend, prebuilt and ready to go.
This is fairly trivial if the directory is self-contained, but this is not currently the case. Paths in selene.yaml are absolute and may depend on the user's setup. Build stages diverge between Linux, MacOS and Windows, and a full load may not be viable.
To solve this, we could do the following:
- change paths to paths relative to key directories (e.g. python module root directories)
- include more information about any external inputs, such as source code, into the artifacts directory
- provide a way of identifying an artifact that is a common ancestor on the source platform and the current platform. This could be e.g. HUGR or LLVM, or an object file, or even the final executable.
- build from that ancestor.
Use cases include:
- easy support for users running into problems
- single node build, multi node invocation
- fast demos of slow-to-compile programs
- sharing programs with long compile times
- sharing pre-built runners without requiring any additional toolkits on the destination machine
- the potential for a nix-inspired "selene store" for serving cached builds.
With save/load discussed in #11 raises a question about saving for portability purposes.
If a user has built a Selene instance, they may wish to send it to a friend, prebuilt and ready to go.
This is fairly trivial if the directory is self-contained, but this is not currently the case. Paths in selene.yaml are absolute and may depend on the user's setup. Build stages diverge between Linux, MacOS and Windows, and a full load may not be viable.
To solve this, we could do the following:
Use cases include: