Support building projects for FreeBSD

[kxepal]

This adds basic FreeBSD support. Basic, because it works for my few
cases. There are two major differences from how things works for Linux
and rest platforms:

The first is that there is no custom suffix for produced .so files
and imp.get_suffixes() confirms that.

The second is more complicated. There is no universal platform tag which
covers some OS release. In fact, it includes information about:

• OS version (11_2, 12_0),
• release type (RELEASE, STABLE)
• and patch set (p1, p7, etc).

While first two are pretty well known and could be simply hardcoded
to maintain support for a many years, patch set is very generic and
changes once any security or system fixes get issued for specific
release. From point of FreeBSD it's the same system with the same
compatibility guarantees. From point of Python it's a completely
different platform which is not compatible with the others patches
for the same OS version and release.

That means that wheels need to be rebuild (or just renamed) if system
receives any patch set update.

[konstin]

Thank you for your pull request! I wasn't even aware that python supports native wheels on platforms other than windows/linux/mac, but that definitely something I'd like to support.

Does cargo test or cargo test --features skip-nightly-tests pass locally? And would it be possible to add continuous integration for freebsd, so that I don't accidentally break the freebsd support? py-spy for examples uses this cirrus ci config.

[kxepal]

Hi! Sorry for late response. The integration tests fails producing bad wheels - that's strange, but will fix them. Also will add Cirrus CI to run tests since we can have such kind of problems. Will handle this on the weekends.

[konstin]

I've added some basic cirrus ci support in #183

[kxepal]

Oh, great! Thank you! I didn't managed this yet /: Rebased in order to trigger those build.

I also rewrote implementation to use Rust-way to get the release tag instead of Python one - otherwise it just wouldn't work.

[konstin]

I also rewrote implementation to use Rust-way to get the release tag instead of Python one - otherwise it just wouldn't work.

Could you tell a bit more about that? I'm collecting all of those weird cases as documentation. The output of python3 -m sysconfig for freebsd would also be very interesting (There are some for linux and windows in the sysconfig folder)

[kxepal]

Could you tell a bit more about that? I'm collecting all of those weird cases as documentation.

Well, the reason is simple. There are two places where wheel tags get created: on PythonInterpreter side for platform specific tags and on Target side for universal ones. FreeBSD has no stable release tag, so previously I returned from Target template string to format it later on PythonInterpreter side. But this makes universal tags broken as well as the tests. And I feel not ready to refator PythonInterpreter-Target relationship now.

So I had to take platform-info crate and a bit break Target.get_platform_tag signature. Not really sure how to preserve old &'static str doing stringy operations inside.

The output of python3 -m sysconfig for freebsd would also be very interesting

Here is my output for 3.6 on FreeBSD 11.2: https://gist.github.com/kxepal/c8cfbbeade7cd4fb9a45d3ed82c04d71

[konstin]

Thank you for detailed explanation and the sysconfig!