Added support of building using the deps fetched from pkg-config.

[KOLANICH]

No description provided.

[searchivarius]

Hi @KOLANICH thank you. A couple of questions/notes:

1. This compiles an old version of the library, so it won't work with headers from fastpfor. Some work would be needed to link the original code by having it as, e.g., a submodule.
2. What's the distribution mode of pkgconfig? Is it like pip or conda? One would need to upload source code somewhere? Sorry, I don't know anything: I haven't used it before.

[KOLANICH]

This compiles an old version of the library, so it won't work with headers from fastpfor.

It works, the test has returned no error. BTW, the test itself is done wrong. One needs to use unittest module and assertEqual instead of just a func and asserts.

Some work would be needed to link the original code by having it as, e.g., a submodule.

It would require changes in the original library code. The dir with the headers has incorrect layout.

What's the distribution mode of pkgconfig? Is it like pip or conda? One would need to upload source code somewhere? Sorry, I don't know anything: I haven't used it before.

It is a kind of a standard. Just text files of a certain format in specifjc location. Can be distributed by any package manager and even without them, but to distribute them one has to generate them.

Their main use is on nix systems, but they can also be used on other systems, if there is a preaggreed location where pkgconfig gonna search them (it is likely hardcoded into the binary).

The original library CMake scripts generate them and install them (but I don't recommend to use cmake install , make install, ninja install and stuff like this, instead generate packages with CPack and install them).

BTW, it may be possible to get rid of a cext and use ctypes. It would allow using the lib in other implementations of python without recompilaion, and also would elimjnate any need in compilation of the cext, so users without compilers in their system (Visual Studio is shit, though for lot of packages MinGW-w64 works fine even on pythons compiled with VS) would be able to install the lib.

[searchivarius]

Ohh, there's a fastpfor header link, so it's ok.

Regarding pkgconfig: how does it interact with pip install?

The library isn't particular popular, so I wouldn't bother about shipping a windows version.

[KOLANICH]

Regarding pkgconfig: how does it interact with pip install?

1. First one builds and installs libfastpfor-dev (debian) or libfastpfor-devel (ubuntu). For windows one can also build packages, i.e. using NSIS, or Qt IFW, or WiX.
2. There exist pkg-config impls for Windows: https://cygwin.com/packages/summary/pkg-config.html , https://packages.msys2.org/package/pkg-config .
3. Then one can build a wheel, and then install it with pip. The in Windows the shared library should be available in PATH though, but installers can take care about it, and CMake has a pref for that, CPACK_NSIS_MODIFY_PATH , but it is only for NSIS backend, for IFW backend there is no such a pref. Headers are not needed to be installed to use a shared library.

[searchivarius]

Ok, I will need to come back to this a bit later. BTW, I am not really eager to support Windows for this project unless it (for some reason) becomes popular.