Re: Missing dependencies in GLib build system

Hi Jasper,

Thanks for your feedback! My replies are inline below.

On Aug 4, 2015, at 12:22 PM, Jasper St. Pierre <jstpierre 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 -- should have
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, 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:

All the best,

On Tue, Aug 4, 2015 at 8:05 AM, Shane McIntosh <mcintosh 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:

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,
gtk-devel-list mailing list
gtk-devel-list gnome org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]