[libvirt] [PATCH] Remove python binding

[Daniel P. Berrange]

On Fri, Nov 22, 2013 at 10:57:00AM -0700, Eric Blake wrote:
> On 11/22/2013 09:59 AM, Daniel P. Berrange wrote:
> >  run.in                                             |    9 -
> 
> and this (hmm, do we need a ./run counterpart added to libvirt-python to
> make it easy to import a built but uninstalled python bindings for
> testing purposes?)

I guess we could do - not sure if python's setup.py makes that easy
todo already or not.

> > diff --git a/.gitignore b/.gitignore
> > index 6b024e7..faabd33 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -91,17 +91,6 @@
> >  /mkinstalldirs
> >  /po/*
> >  /proxy/
> > -/python/generated.stamp
> > -/python/generator.py.stamp
> > -/python/libvirt-export.c
> > -/python/libvirt-lxc-export.c
> > -/python/libvirt-lxc.[ch]
> > -/python/libvirt-qemu-export.c
> > -/python/libvirt-qemu.[ch]
> > -/python/libvirt.[ch]
> > -/python/libvirt.py
> > -/python/libvirt_lxc.py
> > -/python/libvirt_qemu.py
> 
> Oddly enough, removing these lines will mean that someone with an
> incremental tree that likes to switch branches between master and any
> earlier branch (say v1.0.5-maint) will now see git complaining about
> untracked files.  I personally tend to avoid removing lines from
> .gitignore (if we've ever ignored a file in the past, then branch
> switching could leave the file around to still be ignored); but I won't
> complain too much if you make the deletion (I can always re-add the
> lines in my .git/info/exclude for my own environment).

I'm happy either way. Personally when I see dead files appearing
due to code re-orgs I usually just 'git clean' my working tree,
but if we want to leave the python stuff in gitignore for a while
we can do that too.

> > @@ -74,8 +73,6 @@ check-local: all tests
> >  
> >  tests:
> >  	@(cd docs/examples ; $(MAKE) MAKEFLAGS+=--silent tests)
> > -	@(if [ "$(pythondir)" != "" ] ; then cd python ; \
> > -	  $(MAKE) MAKEFLAGS+=--silent tests ; fi)
> 
> Did configure.ac clean up the setting of $(pythondir)?
> /me looks some more
> Wow - we never set $(pythondir) anywhere pre-patch, so it only ever did
> something if you invoked 'make pythondir=...', and since autobuild
> wasn't doing it, I think this was dead code.

Yeah, in fact I think this entire 'tests' rule can probably just
die. Testing should all be done via the standard 'make check' rule
not a custom target.

> 
> > +++ b/autobuild.sh
> > @@ -86,8 +86,7 @@ if test -x /usr/bin/i686-w64-mingw32-gcc ; then
> >      --prefix="$AUTOBUILD_INSTALL_ROOT/i686-w64-mingw32/sys-root/mingw" \
> >      --enable-expensive-tests \
> >      --enable-werror \
> > -    --without-libvirtd \
> > -    --without-python
> > +    --without-libvirtd
> 
> Hmm.  Was --without-python disabling _just_ the python bindings, or was
> it _also_ disabling our attempts to use $(PYTHON) for building things in
> our docs/ subtree?  We may STILL want to keep this setting for
> controlling whether to attempt to build generated docs (vs. using the
> pre-generated version shipped in the tarball).

It should only target the python bindings. If it has other side effects
that'd be a bug.


> > -AM_CONDITIONAL([WITH_PYTHON], [test "$with_python" = "yes"])
> > -AC_SUBST([PYTHON_VERSION])
> > -AC_SUBST([PYTHON_INCLUDES])
> > -
> >  dnl Allow perl overrides
> >  AC_PATH_PROG([PERL], [perl])
> 
> ...maybe all we need is a simple AC_PATH_PROG([PYTHON], [python]) for
> the sake of still using $(PYTHON) during doc generation?  And some of
> this goes back to whether deleting --without-python from autobuild makes
> sense.

Yeah, that simply PATH_PROG would likely be sufficient.

> > @@ -425,7 +424,6 @@ BuildRequires: gettext-devel
> >  BuildRequires: libtool
> >  BuildRequires: /usr/bin/pod2man
> >  %endif
> > -BuildRequires: python-devel
> 
> Ouch.  Don't we still need a buildreq on 'python' for doc generation
> purposes, possibly conditionally based on whether we have patches
> applied to a downstream rpm that warrant doc regeneration?

'python' is guaranteed in the default build roots for fedora/rhel
I believe.

> If you can answer the comments I raised above, and if everyone is okay
> with your libvirt-python.git patches, then I'm okay with this patch.
> Let's get it polished and in before freeze!
> 
> I also just kicked off a 'make distcheck' and will report back later if
> I saw anything fishy that needs fixing.

FYI I ran 'autobuild.sh' to validate the full RPM builds here.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|