GNOME Bugzilla – Bug 688678
Add option to build gcr without gtk
Last modified: 2019-02-22 11:58:25 UTC
Platforms like Tizen don't provide GTK+. Still GNOME components like Evolution Data Server are useful for those platforms. As gcr is used we would like to add a switch to build gcr without having GTK+ installed.
Created attachment 229415 [details] [review] proposed patch Wondering if I shall do another patch, grouping the automake statements that less conditionals are needed.
Review of attachment 229415 [details] [review]: Thanks. ::: configure.ac @@ +82,3 @@ GTK_DOC_CHECK(1.9) +AC_ARG_ENABLE(gtk, I'd like this to be a --without-gtk/--with-gtk option pair. The reason is that in the future, we'll probably support a --with-gtk=4.0 option, at least temporarily. So I want to reuse this option. ::: gcr/tests/Makefile.am @@ +88,3 @@ frob-unlock-options +endif Could you add a comment referring to the conditional? endif # WITH_GTK
Created attachment 229444 [details] [review] updated patch
Could you build with '--without-gtk --enable-gtk-doc' and then do a 'make distcheck'. I get the following errors: /data/projects/gcr/docs/reference/gcr/gcr-scan.c:50: undefined reference to `gcr_certificate_renderer_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:51: undefined reference to `gcr_certificate_widget_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:53: undefined reference to `gcr_collection_model_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:54: undefined reference to `gcr_combo_selector_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:57: undefined reference to `gcr_import_button_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:59: undefined reference to `gcr_key_renderer_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:60: undefined reference to `gcr_key_widget_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:61: undefined reference to `gcr_list_selector_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:65: undefined reference to `gcr_prompt_dialog_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:66: undefined reference to `gcr_renderer_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:67: undefined reference to `gcr_secure_entry_buffer_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:72: undefined reference to `gcr_tree_selector_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:74: undefined reference to `gcr_unlock_options_widget_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:75: undefined reference to `gcr_viewer_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:76: undefined reference to `gcr_viewer_widget_get_type' /data/projects/gcr/docs/reference/gcr/gcr-scan.c:77: undefined reference to `gcr_viewer_window_get_type' collect2: error: ld returned 1 exit status Linking of scanner failed: make[4]: *** [scan-build.stamp] Error 1 make[4]: Leaving directory `/data/projects/gcr/docs/reference/gcr' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/data/projects/gcr/docs/reference' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/data/projects/gcr/docs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/projects/gcr' make: *** [all] Error 2
Created attachment 229606 [details] [review] updated patch
Created attachment 229611 [details] [review] updated patch messed up the previous one...
Created attachment 229904 [details] [review] build: Permit building without GTK+ Thanks for all that work. However, I should have been more clear. I didn't mean that we should be able to do a 'make distcheck' with --without-gtk, only that it shouldn't fail so haplessly. Does the attached patch work for you? It prints out an error message if you try to 'make distcheck' with --without-gtk similar to how you that you get a message when you try to 'make distcheck' without --enable-gtk-doc.
No worries, happens all the time. Online communication isn't trivial. Back on topic: I think "distcheck" worked for me both when passing "--without-gtk", but also if not passing it. Seems I need to take another look... ;-)
Created attachment 230506 [details] [review] build: Permit building without GTK+ (another try) This should obsolete the previous patches, but leaving them there currently just in case the maintainer may prefer otherwise. Changes over the previous patches are: o This patch conditionally installs the pkgconfig file for gcr only if gcr is built with GTK+, i.e. we dont want to install a pkg-config file onto the system referring to libraries we didn't build (would have obviously bad effects for other modules depending on gcr.pc). o Change distcheck approach, remove the added distcheck hook and instead provide --with-gtk as a preferred distcheck configure option (I'll provide the rationale for this in the next comment).
(In reply to comment #7) > Created an attachment (id=229904) [details] [review] > build: Permit building without GTK+ > > Thanks for all that work. However, I should have been more clear. > I didn't mean that we should be able to do a 'make distcheck' with > --without-gtk, only that it shouldn't fail so haplessly. > > Does the attached patch work for you? It prints out an error message > if you try to 'make distcheck' with --without-gtk similar to how you > that you get a message when you try to 'make distcheck' without > --enable-gtk-doc. This does not work, however other bugs may make the patch appear to work as you expected it to under certain conditions. Let me explain in a bit more detail, 2 bugs are at work here, making results very confusing. A.) libtool in-tree linking bug. The gtk-doc build essentially links to $(topbuilddir)/gcr/libgcr-3.la, which is a libtool linker script. If you have installed into $(prefix) a version of libgcr-3.so, then libtool will prefer the library installed in $(prefix) and not the library freshly built in-tree. This is a definite bug which is apparent in most projects I've seen, I'm wondering if there is a proper way to configure things to avoid this but thus far I don't have any fix for this bad behavior. B.) distcheck target is severely wrong for gtk-doc When making test cases work for distcheck for example, it's important to both ensure that test directories run after building software in the relocated distcheck build, and also to ensure the environment for testing is correct, most importantly, it's important that test cases actually load the relocated, freshly built library to test against. gtk-doc fails this on both counts, first off the gtk-doc distcheck hooks somehow run *before* building the relocated gcr, and when attempting to build the gtk-doc scanner it links directly against $(gcr_checkout)/gcr/gcr-3.la ... instead of $(gcr_checkout)/gcr-3.7.1/build/gcr/gcr-3.la In order to test this reliably, you need to: 1.) make uninstall (ensure there is no stale libgcr.so in the install prefix) 2.) ./configure ... --without-gtk 3.) make 4.) make distcheck Doing the above in my jhbuild shell proved that the gtk-doc build fails before your added distcheck hook ever gets a chance to run, if your warning does appear, it's because a previous build with GTK+ widgets enabled exists before reconfiguring --without-gtk and then doing 'make distcheck' My general opinion of the situation as a whole: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since I see no good option to reliably detect this, or that in doing so we end up adding more confusion to the build scripts than is needed, we should simply pass '--with-gtk' in the DISTCHECK_CONFIGURE_FLAGS defined in the toplevel Makefile.am. This will ensure that at least GTK+ widgets will be enabled for the relocated build which is built during distcheck. If and when gtk-doc makefiles get fixed to run properly in the distcheck context, then they will link against the libgcr-3.la which is built *during distcheck* and hopefully link against the freshly build library --with-gtk which was built during distcheck (of course there is another chance for this to fail, if the libtool bug is not fixed, and libgcr-3.so is in the install prefix, then both linker scripts: $(gcr_checkout)/gcr/gcr-3.la _and_ $(gcr_checkout)/gcr-3.7.1/build/gcr/gcr-3.la would both direct the linker to the wrong libgcr-3.so which is already installed, so libtool also needs to be fixed). So, my opinion is, make this patch *not* add more confusion around distcheck hooks, but instead just specify that --with-gtk is needed for distcheck to run... then we should ideally say "gtk-doc build is currently broken for distcheck", that's why we might encounter this unexpected error (which I suggest we just live with until the problem is fixed in the appropriate places).
Well, can we just use the dist-hook to tell people they can't dist when --without-gtk? In any case, with the last patch I get this build error: CCLD libgcr-testable.la CC gcr_viewer-gcr-viewer-tool.o CCLD gcr-viewer CC gcr_prompter-gcr-prompter-tool.o CC gcr_prompter-gcr-debug.o CCLD gcr-prompter make[5]: *** No rule to make target `gcr-viewer.desktop.in.in', needed by `gcr-viewer.desktop.in'. Stop. make[5]: Leaving directory `/data/projects/gcr/gcr-3.7.2/_build/gcr' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/data/projects/gcr/gcr-3.7.2/_build/gcr' make[3]: *** [all] Error 2 make[3]: Leaving directory `/data/projects/gcr/gcr-3.7.2/_build/gcr' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/data/projects/gcr/gcr-3.7.2/_build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/data/projects/gcr/gcr-3.7.2/_build'
Created attachment 230730 [details] [review] build: Permit building without GTK+ Updated patch with a check in configure which disallows --without-gtk and --enable-gtk-doc to be used together.
Created attachment 230731 [details] [review] build: Permit building without GTK+ Obsoleting the other patches. This one halts the configure with an informative error message if --without-gtk is passed with --enable-gtk-doc
Comment on attachment 230731 [details] [review] build: Permit building without GTK+ I've applied the patch to 3.6.2 and pushed the result to a bgo688678 branch, to make it easier to use the patch with jhbuild.
Pushed a somewhat different patch. Refactored the directory structure of the project to split out the ui stuff into a separate directory. Reworked how introspection is built (now split) and how libraries are split up. More details here, very large commit: http://git.gnome.org/browse/gcr/commit/?id=41d96e69e8b56aa88e36e8bd176c51c5aa93caf9