configure fails to find zfs.h on Ubuntu without --prefix=/usr about py-libzfs HOT 6 OPEN

Okay, I did a quick stab at fixing this. Beforehand, the solution is to run pkg-config --cflags libzfs to infer CFLAGS.

A workaround mentioned in #90 was to set --prefix. I figured, when it's set, this branch that changes CFLAGS gets executed, so some modifications around it required.

Unfortunately I have no idea why is there even a branch matching libzfs.h specifically, nor I have any guess what the variable $zof means. All of that requires further digging and I'm out of time I could dedicate to this problem. Hopefully it will help someone.

from py-libzfs.

To future readers: there are further bugs in build system: if you apply the workaround with prefix, make still gonna fail with make: /usr/local/bin/python2.7: Command not found. But what's notable in this output is that apparently the bindings this project provides are for old and unmaintained python 2. So using py-libzfs is not future proof.

I've heard 0.8.x ZFS versins provide some python bindings of their own, so I think this is the way forward. For older versions apparently one have to fallback to parsing zfs commands output manually.

from py-libzfs.

@Hi-Angel FWIW, this is just a bug, I just tested it on Py 3.7 and it appears to work fine after modifying the Makefile to point at a py 3 venv. Probably rather than a configure script and a Makefile, the project could use setuptools-ish processes for building the extensions, just a matter of missing roundtuits likely.

from py-libzfs.

But what's notable in this output is that apparently the bindings this project provides are for old and unmaintained python 2. So using py-libzfs is not future proof.

You can build py-libzfs for whatever Python version you like. We are targeting 3.8 at the moment, but you can use make PYTHON=python3.7 for example to build for Python 3.7, or whatever version you have installed. Defaulting to 2.7 is probably just an oversight.

Unfortunately I have no idea why is there even a branch matching libzfs.h specifically, nor I have any guess what the variable $zof means. All of that requires further digging and I'm out of time I could dedicate to this problem. Hopefully it will help someone.

The reason for this complexity is twofold: partly that libzfs is not supposed to be a public interface in ZFS, it's an internal private library that has an unstable and unclean API; and on top of that there are several different ZFS implementations on different platforms that put headers in different places, require different build flags, and have different function signatures within libzfs. $zof is referring to https://github.com/zfsonfreebsd/ZoF

from py-libzfs.

I see, thanks

there are several different ZFS implementations on different platforms that put headers in different places, require different build flags

Doesn't pkg-config cover this?

from py-libzfs.

No, there are a few configurations where ZFS isn't a package at all, it's part of the FreeBSD base system. There is no pkg-config in that case.

from py-libzfs.