GNOME Bugzilla – Bug 745754
Add gcc-style dependency output to glib-compile-resources
Last modified: 2016-10-22 08:03:15 UTC
Currently glib-compile-resources supports getting the list of dependency files with --generate-dependencies. However this is only usable in Makefiles (as described in the man page). In Ninja, for example, this does not work by design. The standard way of doing this that works everywhere is to print the dependencies to an external .d file in the same way as GCC's -M -MF flags do. I thus recommend adding a new flag that would be used like the following: --dependency-file=resdep.d
sure, we'd take a patch for that
Created attachment 319789 [details] [review] WIP: glib-compile-resources: generate .d-file style dependency output for build tools Add --dependency-file=foo.d option to generate a gcc -M -MF style dependency file for other build tools. The current output of --generate-dependencies is only useful for use directly in Makefile rules, but can't be used in other build systems like that. The generated dependency file looks like this: $ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=- test.gresource.xml: test1.txt test2.txt test2.txt test1.txt: test2.txt: test2.txt: ------------------------------------- Something like this? (*drive-by WIP patch alert*) Note that here test2.txt appears multiple times, which is probably not right, but I'm unsure if it's because test.gresource.xml is crafted like this as a test case on purpose or if it's a valid use case one needs to handle.
Comment on attachment 319789 [details] [review] WIP: glib-compile-resources: generate .d-file style dependency output for build tools Generates dependencies for the wrong target file I think, needs fixing.
Review of attachment 319789 [details] [review]: I don't think this is going to work. Firstly, the generated dependencies don't appear to have sense (we have dependencies for files we are not generating using make or a ninja build, but they are source files, like test.geresource.xml). Secondly, as done by GCC, the dependencies should be generated along with the target file, this is not only to have a similar behavior to GCC, but I think it adjust more to the reporter use case. So, for example $ glib-compile-resources test.gresource.xml --target=test.c --generate --dependency-file=- test.c: test.gresource.xml test1.txt test2.txt test3.txt
Jussi, FTR, I think that you could workaround your specific Ninja use-case by doing something like this: rule glib_compile_resources command = glib-compile-resources --generate-dependencies --sourcedir=$sourcedir $in | command-to-convert-to-make-deps $in > $out.d && glib-compile-resources --generate --sourcedir=$sourcedir --target $out $in depfile = $out.d deps = gcc I know it's ugly, but it could work. Proposing a new value for "deps" option (like "plain") to Ninja developers could save you to add the "command-to-convert-to-make-deps" command.
I'd love to switch to meson for my projects, but this bug is blocking *all* of them.
To clarify, this issue is not very common and will fix itself automatically eventually (which is why the message says that it won't work reliably rather than being broken). The steps to reach failure are the following. Create a resource file some resource, say a.png. Build. Everything works fine. Add b.png to the resource file. Build. Everything works fine. Now if you update a.png the dependency source files are rebuilt but altering b.png does not trigger a rebuild (because of the missing dependency file). Whenever Meson reconfigures itself (build definitions change, options are changed etc) the dependency tree is re-evaluated, b.png is added to the list of dependencies and future changes of b.png will trigger a recompile. For general development it will work just fine most of the time.
For comment #5, yes, that is exactly what should be done. One invocation of glib-compile-resources should both generate the source and the dependency file. So something like this: glib-compile-resources test.gresource.xml --target=test.c --generate --dependency-file=test.c.d This would generate test.c and test.c.d all in one go. For comment #6 we unfortunately can not do that as it has a shell pipeline and those are expressly forbidden in Meson because they are not portable (and there is a performance penalty for invoking the compiler twice, most notably on Windows).
Hrm, I don't think that patch was quite right/ready yet, that's why I marked it as needs-work.
Reverted in master, since the commit was breaking the build in Continuous as well: ../../../gio/tests/test.gresource.xml: Failed to locate 'test-generated.txt' in any source directory. Makefile:4678: recipe for target 'test.gresource' failed
(In reply to Tim-Philipp Müller from comment #9) > Hrm, I don't think that patch was quite right/ready yet, that's why I marked > it as needs-work. Thats why I've not committed it as-is, but fixed it to work. > Reverted in master, since the commit was breaking the build in Continuous as well: I'll have a look
Pushed again, with some further fixes.
Thanks a lot Matthias!
(In reply to Jussi Pakkanen from comment #8) > For comment #5, yes, that is exactly what should be done. One invocation of > glib-compile-resources should both generate the source and the dependency > file. So something like this: > > glib-compile-resources test.gresource.xml --target=test.c --generate > --dependency-file=test.c.d > > This would generate test.c and test.c.d all in one go. It seems like this was never actually resolved. Fixed in bug 773344.