Build boolector about boolector-sys

[fatemender]

Hi and thanks for your interest in the crate.

I'll have a look into automatically building boolector. If I remember right, there have been some issues with building on Windows in different environments which is why I decided against doing that in the first place, but I'll try again.

[finga]

Meanwhile, over the weekend, I created another crate (boolector-src). I will review it again and upload it and paste it here when I am done with work. We could use the crate I created or you can move it to your boolector-sys crate. It is your choice how you want to do it ;)

[finga]

So I have pushed what I have worked on so far regarding this issue.
The crate I created: https://github.com/finga/boolector-src-rs
and what I did on your boolector-sys crate in order to make it work: https://github.com/finga/boolector-sys/tree/boolector-src.

I believe that for some users the build will not work out of the box for example as you already said for Windows users there might be issues. And until now no options regarding dependencies are supported, it just builds the default. But I believe something like this is better than nothing and we can implement it as we go.

Regarding supporting other systems, in the group where we use Boolector we use Windows, MacOSX and Linux, so I plan to test and fix the build for those systems soon.

Let me know if I should stick to boolector-src-rs or if I should create a PR for merging it into your boolector-sys crate.

[fatemender]

Sorry for a late reply, been a really busy two weeks.

I've looked into how Boolector builds on Windows, and its seems to me that it's next to impossible to provide an automatic build for it in a crate. It relies heavily on GNU extensions, so we would need a MinGW toolchain ready, and that's limiting things even further.

That said, I'm not very happy with introducing a Linux-only feature. I think there might still be a way forward for your scenario: how about instead of boolector-sys depending on boolector-src we make it possible for a client crate depend on both at the same time? In that case, boolector-src would build Boolector and print additional Cargo lines through its build script and linking should be made possible without making any changes in boolector-sys. I haven't yet tried to do this but is seems possible and somewhat cleaner.

[fatemender]

@cdisselkoen do you have an opinion on this matter?

[cdisselkoen]

I'm generally in favor of anything that makes things easier for users. I don't have a particularly strong opinion about the technical details here - whether there is a separate crate for building or not, etc.

As an alternative to a separate crate, would it make sense to hide the build logic (and any Linux-only or Linux/macOS-only features) behind some Cargo feature in boolector-sys? I haven't thought through all the repercussions of having a Cargo feature vs. a separate crate, but it might be worth considering?

[ChristianMoesl]

Hi guys, I also have interest in this. Currently we use the boolector-src-rs of @finga to statically link it in. But I surely would like to have a solution published on crates.io . To make that happen, I can participate in developing this feature in the crate of @finga or @fatemender , once a decision is made.

Just as a side-note: in the crate for Z3, they used a Rust feature for conditionally statically linking in the library z3-sys. Personally I am fine with both approaches, but my opinion should be less important, since I do not have enough experience to judge. 😄

[fatemender]

Ok, I guess I am convinced now. Will do my best to merge code from @finga by the end of the week.

I think it is a good idea to be specific about the SAT solver we use in the build (currently Lingeling), so the cargo name feature will be something like vendor-lgl.

[ChristianMoesl]

@fatemender great! Yeah that would be neat, to be able to specify the SAT solver as well. Let me know, if you need someone to test your change. We have some workloads in our engine using Boolector: https://github.com/cksystemsgroup/monster

[fatemender]

@finga could you please bump the version of boolector-src to 0.1.0 and publish it on crates.io?

Or, alternatively, we could host the crate here, in boolector-sys tree, but I'd like to copy it here instead of linking as a submodule because otherwise we would end up with two possibly out-of-sync boolector submodules.

[finga]

@fatemender I can publish it but I am uncertain what is your prefered solution, also what makes most sense.

Wouldn't it be a good solution to move the code for building boolector into your boolector-sys crate without introducing a further boolector-src crate and using the boolector submodule thats already there? In this way we have one single source for bindings as well as for the build (Is that what you ment with copying it?).

[fatemender]

Have a look at the feature/vendor branch I've pushed. I've taken the liberty to rename boolector-src to boolector-build as it no longer hosts the actual source now.

If everything seems all right, I'll update the readmes, copyrights, etc. and publish.

[finga]

It seems fine to me. I believe this can be released so far.

Thank you @fatemender

[fatemender]

Done, thank you @finga!