Amazing, thank you! I’m building right now and I’ll try to incorporate this in my work tonight.
(In fact, while writing my reply the build finished. It looks like libswipl_static.a is being built, but it is not yet copied to the destination directory when I do
ninja install. For now I’ll just copy manually.)
Regarding the library naming, I’m fine with either solution. As it is, I already need special build code to get things to build on windows, because libraries already end up in a different location (everything in the bin dir, instead of
lib/<arch>/) and different environment variables are needed to locate them during build. Having to use a different library name just on windows is not an insurmountable barrier. But yes, consistency is good, so probably using the same name on all platforms is best.
Regarding MSVC, I don’t really have good opinions here. I personally do not care about MSVC as it is not part of my toolchain on windows. That said, I don’t know exactly how the rust toolchain on windows interacts with static libraries, so it may matter for me. I’ll have to test this.
Regarding rust, it may be useful to talk a bit about how the ecosystem works.
Rust development is centered around the cargo package manager. Cargo packages are entirely source based. People specify their dependencies in a
Cargo.toml file, and the cargo tool downloads and compiles these dependencies at build time.
I’m developing the interface as a collection of crates, collected in the swipl-rs project. A low-level crate, swipl-fli, auto-generates bindings at compile-time from the
SWI-Prolog.h header. A high-level crate, swipl, depends on this crate to implement an easy to use interface. Users of this interface would in turn depend on the
swipl crate to build their own things.
So anyone that builds rust crates that depend on either the low-level
swipl-fli or the high-level
swipl crate will need to have SWI-Prolog installed, or their build will fail.
The primary use case for
swipl-rs is implementing foreign libraries, ideally as part of SWI-Prolog’s pack system. So for that case the dynamic build is required. A secondary goal is supporting embedding of SWI-Prolog. Here either dynamic or static linking could be used, but I think static would really be preferred, as the resulting binary could then be used independently.
My plan is to support such a static build through a feature flag. Cargo crates can define a bunch of features that other crates can depend on. I intend to expose a
static feature flag for people to opt into a static build.
For that to work though, I need to rely on the static library already being part of people’s installs. While I can probably document that people need a very recent version of SWI-Prolog for this library to be there, asking people to rebuild their SWI-Prolog from source won’t always be possible or convenient. That’s why I very much hope that libswipl.a (or libswipl_static.a) finds its way back into standard distributions.