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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
