1. The clean rule doesn't delete the generated .html file.
2. The clean rule returns an error if some of the output files are missing. It needs a -f adding.
3. It doesn't implement dependency tracking of the header files or the Makefile itself.
4. On my clean Ubuntu 16 LTS install, the .o:.c rule doesn't get called. Instead Make uses its built-in rule which doesn't include -fPIC, so the build fails. I guess it is missing some % symbols.
More controversially, I think Makefiles for simple purposes like this are a form of premature optimization. It would be simpler to create a bash script called build.sh containing:
CFLAGS="-Wall -Werror -fpic"
gcc $CFLAGS -shared Point.c Line.c -o libline.so
gcc $CFLAGS -shared Point.c -o libpoint.so
For the "embedding" part (C to Python) it's very important to get the GIL stuff right, but it's not totally obvious how to do so and it's hard to debug when you get it wrong. For the "extending" part (Python to C) the issue is going to be maintaining references for Python objects. Dealing with all of the edge cases (e.g. decorators and ctypes-generated function wrappers) was quite educational. Mixing C and Python is definitely a fun exercise.
PYTHON_WRAP(myfunc, void, float, float...)
If all you need is a simple interface to a couple of functions and you want portability across system variants, that might be the path of least resistance and the performance is often negligible if the amount of work being done in the C code is significant.
Unless the PyO3 documentation is completely leaving out a major application, it doesn't support this scenario.
Pyo3 uses rust refs ownership to enforce proper Gil usage. You code won’t compile if you use Gil in wrong way