GNOME Bugzilla – Bug 773309
Export the C compiler for introspection
Last modified: 2016-10-21 11:35:17 UTC
The gobject-introspection cmake module used by e-d-s has a bug that causes a build failure when trying to generate introspection data.
Created attachment 338174 [details] [review] build: Export the C compiler for introspection If the C compiler environment variable 'CC' is unset, the Python distutils module used by GObject Introspection for portability falls back to the compiler arguments used to build itself. This breaks pretty spectacularly under build environments like GNOME Continuous because it won't be able to find system headers. We can use `${CMAKE_COMMAND} -E env` as a wrapper command to export CC in the custom command used to call g-ir-scanner in order to fix the issue.
Incidentally, the GObjectIntrospection.cmake module says it's been copied from libical, but libical has a newer version of the module itself, for which there's already a patch in Continuous and a PR upstream that fixes this issue: https://github.com/libical/libical/pull/246
Thanks for a bug report and patch. I'm not sure whether it's a real bug in the eds itself, because it works for me and for at least one other user I know of, but I'm not going to argue about it. :) Created commit 2be6f7d in eds master (3.23.1+)
The bug is in the cmake module not doing what the Makefile.introspection shipped with gobject-introspection does — i.e. inject 'CC' in the environment before calling g-ir-scanner. Since e-d-s is shipping a copy of the module, that's where I have to file the bug and the patch. Sadly, the cmake module itself has no known origin or bug tracker.
(In reply to Emmanuele Bassi (:ebassi) from comment #4) > The bug is in the cmake module not doing what the Makefile.introspection > shipped with gobject-introspection does — i.e. inject 'CC' in the > environment before calling g-ir-scanner. Ouch, was it? Then I overlooked it. My fault. I tried to keep the "compatibility" as much as possible.