Hi Jasper, Thanks for your feedback! My replies are inline below.
> On Aug 4, 2015, at 12:22 PM, Jasper St. Pierre <jstpie...@mecheye.net> wrote: > > The first specifies source files shipped with the tarball. It should > be extremely difficult to get into this position, so we rarely specify > files in this way. Our tool marks this as a potential issue because these python files are read by the gdbus-codegen generator when it’s producing the gdbus-daemon-generated.h and gdbus-daemon-generated.c files. However, make isn’t aware of these dependencies, so even if the python files are updated, the gdbus-daemon-generated.h and gdbus-daemon-generated.c will not be regenerated. > The second looks wrong -- libgio-2.0.la should have libgmodule-2.0.la > as a dependency. None of the tools use libgmodule directly, it's GIO > that needs GModule. That dependency might change in the future, since > it's a private dependency of GIO. It doesn't make sense to specify as > a dependency of the binaries to me. Ah, I can understand that perspective. On the other hand, from make’s perspective, it is the binaries that must be relinked when GModule is changed, not GIO. To make it easier to remove the dependency if you do restructure things, perhaps we can store the gmodule dependency in a make variable? Would that help? > The third patch, unfortunately, seems bizarre as well -- > $(glib_compile_resources) is found and set by configure.ac, so it must > be there in order for the Makefile to have been generated. It doesn't > make much sense to me to also check it in the Makefile. For this one, we have added a dependency here so that if the tool itself is updated, running make will update the generated code. > Let me know if you have any other questions. I forgot that we recently logged another bug, which is a similar flavour as #3 above: https://bugzilla.gnome.org/show_bug.cgi?id=752981 All the best, -Shane > On Tue, Aug 4, 2015 at 8:05 AM, Shane McIntosh <mcint...@cs.queensu.ca> wrote: >> Hi all, >> >> I’m part of a research team that's working on a tool that scans build >> systems for missing dependencies. We ran a prototype of our tool on the GLib >> build system, and detected a few bugs: >> >> https://bugzilla.gnome.org/show_bug.cgi?id=752239 >> https://bugzilla.gnome.org/show_bug.cgi?id=752232 >> https://bugzilla.gnome.org/show_bug.cgi?id=752227 >> >> We’ve attached patches that address the missing dependencies to those bug >> reports. We hope that the patches are useful. It would be great if a GLib >> maintainer could have a look, and get back to us! The feedback would be very >> helpful for when we scale the approach out to larger build systems — perhaps >> even scanning the whole of GTK+ or GNOME if there is interest. >> >> All the best, >> -Shane >> >> http://shanemcintosh.org/ >> _______________________________________________ >> gtk-devel-list mailing list >> gtk-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > -- > Jasper _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
