[Libguestfs] [PATCH 6/7] python: stop including config.h

[Pino Toscano]

On Friday, 10 January 2020 23:13:35 CET Richard W.M. Jones wrote:
> On Thu, Jan 09, 2020 at 06:37:49PM +0100, Pino Toscano wrote:
> > There is nothing in the Python bindings that require results from
> > configure, and gnulib is not used already.
> > ---
> >  generator/python.ml | 6 ------
> >  python/handle.c     | 2 --
> >  2 files changed, 8 deletions(-)
> 
> I guess the motivation is because we cannot create this header
> correctly from PyPi so it'll be wrong there?

That is the thing: config.h is not created at all when building the
Python binding (either as part of libguestfs, or when building the
standalone tar.gz dist), but instead the one from libguestfs is used.

> I still think we might
> need this header when compiling libguestfs Python bindings in the
> normal (not PyPi) case, even if it happens to work right now.

Actually, it happens to _not_ work right now:
https://bugzilla.redhat.com/show_bug.cgi?id=1627964
the libguestfs config.h is shipped in the tarball, and the content of
that file depends on the way the binding was configured from the
libguestfs build that created it. So in case of that bug, the tarball
was created with Python 2. And while patches #3, #4, and #5 should fix
the majority of the visible cases of this issue, there are still
potential issues: config.h defines a series of macros (_GNU_SOURCE,
__EXTENSIONS__, etc) that change the way things are built, and strictly
depend on the platform.

> Could we instead defend these with #ifdef HAVE_CONFIG_H?  That way the
> header shouldn't be used for PyPi and shouldn't need to be bundled (so
> patch #7 would be OK).

I'll reverse the question: if building the standalone tarball works fine
with no config.h, why shouldn't the build-in-libguestfs do the same?
The bindings do not use gnulib and use only few system headers and APIs,
and nothing of the config.h content really matters (the closest thing is
HAVE_PYTHON, which is obviously true...).
In the end, it is just a binding that wraps the C API for a different
language (Python in this case), so it definitely _ought to_ not depend
on the way libguestfs itself was configured/built.

Moreover: the same situation applies to the other bindings too (those
with C parts, of course).

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200113/e1982f43/attachment.sig>