[libvirt] [PATCH] examples: Fix installation on Windows

[Andrea Bolognani]

On Tue, 2019-05-14 at 11:59 +0200, Andrea Bolognani wrote:
> On Tue, 2019-05-14 at 10:16 +0100, Daniel P. Berrangé wrote:
> > On Tue, May 14, 2019 at 09:21:12AM +0200, Andrea Bolognani wrote:
> > > On Mon, 2019-05-13 at 16:14 +0100, Daniel P. Berrangé wrote:
> > > > I wonder if we should just directly use the _SOURCES vars instead of making
> > > > the assumption that binary names match source files. eg
> > > > 
> > > >   EXAMPLE_SRCS = \
> > > >       $(dominfo_info1_SOURCES) \
> > > >       $(dommigrate_dommigrate_SOURCES) \
> > > >       .....
> > > 
> > > That would (probably, I haven't actually tested it) work, however it
> > > seems to me like it would be much more likely that such a solution
> > > would eventually fall out of sync than the one I'm proposing, since
> > > when adding a new example you'd only notice the missing file if you
> > > actively performed an installation and checked the contents of the
> > > documentation directory, rather than not seeing the binary you're
> > > working on which is a much more obvious failure.
> > 
> > I don't think such a bug is any more likely here than anywhere else
> > in our makefiles & we cope fine in general. We need a list of source
> > files & we have variables defining the source files, so it just feels
> > wrong to instead use a list of binary names and infer the source files
> > from that.
> 
> As I tried to explain above, the difference is that if you're adding
> a new example and you forget to update $(noinst_PROGRAMS) or add the
> corresponding $(whatever_SOURCES), you'll immediately figure out that
> something is wrong because your example program will either fail to
> compile or just not show up.
> 
> On the other hand, if you fail to update $(EXAMPLE_SRCS), nothing
> obviously wrong will happen, your example program will compile and
> run just fine, but the source code for it will not be installed as
> documentation.
> 
> Given that we have failed to ship and install Devhelp-compatible
> documentation correctly for literally *years* (since 2014 AFAICT)
> without anyone noticing, I have little confidence we won't break it
> again in the future, and when that happens I'd prefer if it didn't
> just stay silently broken for ages.
> 
> If your approach is the only one you consider acceptable, though,
> I'll cave in and adopt it: better broken, possibly, in the future
> than broken, for sure, right now :)

So how should I proceed? Either way, I'd like to get the CI back
to green sooner rather than later.

-- 
Andrea Bolognani / Red Hat / Virtualization