GNOME Bugzilla – Bug 647729
Gdk-3.0.gir incorrectly generated with separate build dir
Last modified: 2018-05-02 15:05:31 UTC
If you do the following: tar xvfj gtk+-3.0.8.tar.bz2 mkdir builddir cd builddir ../gtk+-3.0.8/configure make You will notice that the contents of Gdk-3.0.gir doesn't contain the gtype info for enumerations (for example "EventType"). This breaks deb packaging because it uses a separate build dir. This has to do with there being a gdkenumtypes.h in the distribution tarball, and also one created in the build dir. I think the appropriate solution would be to not have gdkenumtypes.[ch] in the EXTRA_DIST. But it is sort of hard to decrypt the reasoning for different bits in Makefile.am.
The problem seems to be that in a separate build dir you have gdk/gdkenumtypes.h, but not gdk/gdkenumtypes.c. So the g-ir-scanner only sees the .h file.
Created attachment 195965 [details] [review] Consistently treat gdkenumtypes.[hc] as source files This patch fixes it by always generating and using the files from $(srcdir). It might be debatable if gdkenumtypes.[hc] should really count as "source" or as "built files", but it seems more intuitive/correct to me have them in srcdir. I tested the patch in the following cases: - the scenario in the bug description, i. e. the release tarball with separate build dir (after applying the patch and autoreconf) - git master, in-tree - git master, separate build dir - jhbuild - Debian package build with the patch applied Does that look ok to you?
Pretty sure that will break with readonly srcdir, no ? Have you tried distchecking ?
Created attachment 196231 [details] [review] Consistently treat gdkenumtypes.[hc] as source files Ah, it indeed breaks distcheck, with a "no permission to write ../../gdk/gdkenumtypes.h" error. As gdkenumtypes.[hc] is already shipped in the tarballs, there is no real need to regenerate it. But Makefile.am's extra "stamp-gdkenumtypes.h" rule forces the regeneration. This is rather unnecessary, as gdkenumtypes.h already depends on the template and all input source files, so it will already be rebuilt if anything changed. This now works with distcheck, git in-tree, git separate build tree, and patched upstream tarball (i. e. original scenario from this bug report). The alternative would be to consistently treat these as built files, stop shipping them in the tarballs, and don't create them in $(srcdir). As this file is really not that expensive or hard to generate, it could just always be built. Would you like this better?
Any opinion about this? This bug breaks the Gdk gir, and the patch didn't cause any problems in our packages in more than two months. If you would like to see a different approach here, I'm happy to change it. Thank you in advance!
I always try to consistently follow this rule: there is one place for a file. If the file is disted then that place is the srcdir and it must be there and never in destdir. Otherwise, the place is probably destdir. This means that we must take care not to regenerate files that were in the tarball if no timestamps have changed. This may mean imply that we must dist the stamp file or rewrite the rule in order not to require it.
Review of attachment 196231 [details] [review]: to be slightly more explicit: I think this patch only makes sense if we also dist the stamp
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/357.