[libvirt] [PATCH] tests: stub out virfilewrapper.c on Win32

Daniel P. Berrange berrange at redhat.com
Thu May 11 13:52:18 UTC 2017


On Thu, May 11, 2017 at 03:40:37PM +0200, Martin Kletzander wrote:
> On Thu, May 11, 2017 at 02:16:11PM +0100, Daniel P. Berrange wrote:
> > On Thu, May 11, 2017 at 03:13:03PM +0200, Martin Kletzander wrote:
> > > On Thu, May 11, 2017 at 11:46:01AM +0100, Daniel P. Berrange wrote:
> > > > The Win32 platform can not do link time overrides in the same way
> > > > that we can on POSIX / ELF based platforms, so we cannot build
> > > > the virfilewrapper.c code reliably. Just stub it out on Win32
> > > > so it is a no-op. Tests that use this file are already written
> > > > to skip on Win32.
> > > >
> > > 
> > > I understood we wanted to see that some tests were skipped on a
> > > particular platform.  But we already have so many tests build
> > > conditionally, why don't we just exclude all of them in a Makefile?
> > > That way we wouldn't need to make whole file inside a condition.  I can
> > > walk through them and clean it up, I just want to know if it makes
> > > sense.
> > 
> > The benefit of compiling the tests, but having them exit status 77
> > is that it means automake test harness then clearly reports which
> > tests are being skipped on each platform.  If we do conditionals
> > in the makefile, them skipped tests are invisible - they just
> > disappear entirely from output. So I prefer that we use the exit
> > status 77
> > 
> 
> Yes.  As I said, I understand that.  But we already have bunch of
> test_programs appended only conditionally.  And I felt like mixing the
> approach is not really intuitive for readers.

My vote would be to get rid of the makefile conditionals because they
often lead to bugs in 'make dist' missing out files.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list