Richard W.M. Jones
2020-Jan-10 22:13 UTC
Re: [Libguestfs] [PATCH 6/7] python: stop including config.h
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? 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. 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). Rich.> diff --git a/generator/python.ml b/generator/python.ml > index 0e1ed20d8..fd297321e 100644 > --- a/generator/python.ml > +++ b/generator/python.ml > @@ -119,8 +119,6 @@ and generate_python_structs () > generate_header CStyle LGPLv2plus; > > pr "\ > -#include <config.h> > - > #include <stdio.h> > #include <stdlib.h> > #include <assert.h> > @@ -251,8 +249,6 @@ and generate_python_actions actions () > generate_header CStyle LGPLv2plus; > > pr "\ > -#include <config.h> > - > /* It is safe to call deprecated functions from this file. */ > #define GUESTFS_NO_WARN_DEPRECATED > #undef GUESTFS_NO_DEPRECATED > @@ -542,8 +538,6 @@ and generate_python_module () > generate_header CStyle LGPLv2plus; > > pr "\ > -#include <config.h> > - > #include <stdio.h> > #include <stdlib.h> > #include <assert.h> > diff --git a/python/handle.c b/python/handle.c > index 21077bba9..8200adb52 100644 > --- a/python/handle.c > +++ b/python/handle.c > @@ -22,8 +22,6 @@ > * F<python/actions-*.c>). > */ > > -#include <config.h> > - > #include <stdio.h> > #include <stdlib.h> > > -- > 2.24.1 > > _______________________________________________ > Libguestfs mailing list > Libguestfs@redhat.com > https://www.redhat.com/mailman/listinfo/libguestfs-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Pino Toscano
2020-Jan-13 09:35 UTC
Re: [Libguestfs] [PATCH 6/7] python: stop including config.h
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
Richard W.M. Jones
2020-Jan-14 09:56 UTC
Re: [Libguestfs] [PATCH 6/7] python: stop including config.h
On Mon, Jan 13, 2020 at 10:35:53AM +0100, Pino Toscano wrote:> 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.So for clear terminology let's call these situations: - libguestfs build: Python bindings are built normally as part of libguestfs - PyPi build: Python bindings are built from the python-specific tar gz file For the libguestfs build case we create config.h from ./configure. For the PyPi build case we bundle config.h (which is wrong - not arguing with that). Because in the PyPi case there is no real equivalent of ./configure we cannot create config.h properly.> > 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.Yup, this is wrong, not arguing there.> 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 Python bindings probably don't need the contents of config.h at the moment, but that isn't to say that config.h might not be necessary on some more obscure platform either now or in the future. In the libguestfs build case using HAVE_CONFIG_H would ensure this keeps working, while also preventing us from needing to bundle the incorrect config.h for the PyPi build case. I think it achieves what you're trying to do (fix the PyPi case) with least risk.> 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).Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
Seemingly Similar Threads
- Re: [PATCH 6/7] python: stop including config.h
- Re: [PATCH 6/7] python: stop including config.h
- [PATCH 0/7] Various Python cleanups.
- Re: 1.39 proposal: Let's split up the libguestfs git repo and tarballs
- [common/libguestfs PATCH] utils: conditionally include config.h on HAVE_CONFIG_H