Bug 130188 – [GTK][CMake] Unable to do make install

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Manuel Rego Casasnovas]

After building WebKit with:
Tools/Scripts/build-webkit --gtk --prefix=/opt/gnome --libdir=/opt/gnome/lib64

I've gone to WebKitBuild/Release/ folder and tried to run "ninja install", this is the output:
[1/6] cd /home/rego/checkout/WebKit/WebKitBuild/Release/Source/WebCore && ln -n -s -f /home/rego/checkout/WebKit/Source/WebCore/bindings/gobject/*.h /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom
[2/6] cd /home/rego/checkout/WebKit/WebKitBuild/Release/Source/WebKit2 && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Source/WebKit2 /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders gtk && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Source/WebKit2 /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders soup && ln -n -s -f /home/rego/checkout/WebKit/Source/WebKit2/UIProcess/API/gtk /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders/webkit2gtk/webkit2 && ln -n -s -f /home/rego/checkout/WebKit/Source/WebKit2/WebProcess/InjectedBundle/API/gtk /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders/webkit2gtk-webextension/webkit2
[3/6] cd /home/rego/checkout/WebKit/WebKitBuild/Release/Tools/WebKitTestRunner && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Tools/WebKitTestRunner /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders gtk && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Tools/WebKitTestRunner /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders soup
[4/6] cd /home/rego/checkout/WebKit/WebKitBuild/Release/Tools/TestWebKitAPI/Tests/WebKit2Gtk && glib-compile-resources --target=/home/rego/checkout/WebKit/WebKitBuild/Release/bin/TestWebKitAPI/WebKit2Gtk/resources/webkit2gtk-tests-resources.gresource --sourcedir=/home/rego/checkout/WebKit /home/rego/checkout/WebKit/Tools/TestWebKitAPI/Tests/WebKit2Gtk/resources/webkit2gtk-tests.gresource.xml
[5/6] cd /home/rego/checkout/WebKit/WebKitBuild/Release/Tools/TestWebKitAPI && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Source/WebKit2 /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders gtk && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Tools/TestWebKitAPI /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders gtk && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Source/WebKit2 /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders soup && /usr/bin/perl /home/rego/checkout/WebKit/Source/WebKit2/Scripts/generate-forwarding-headers.pl /home/rego/checkout/WebKit/Tools/TestWebKitAPI /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/ForwardingHeaders soup
[6/6] Install the project...
FAILED: cd /home/rego/checkout/WebKit/WebKitBuild/Release && /usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "Release"
CMake Error at Source/cmake_install.cmake:36 (FILE):
  file INSTALL cannot find
  "/home/rego/checkout/WebKit/WebKitBuild/Release/Documentation/webkitgtk/html".
Call Stack (most recent call first):
  cmake_install.cmake:37 (INCLUDE)


ninja: build stopped: subcommand failed.

[Martin Robinson]

Switching this to 'make install' since it seems there might be bugs in the ninja generator that preclude running the install target successfully. Meanwhile, we need to fix 'make install' for sure.

[Martin Robinson]

Created attachment 230440 [details]
Patch

[Martin Robinson]

Created attachment 230556 [details]
Patch

[Martin Robinson]

(In reply to comment #3)
> Created an attachment (id=230556) [details]
> Patch

After discussion with Carlos, we decided that gtkdoc-no-html should never be part of the default target. Instead, build-webkit should manually build it so that we don't introduce gtkdoc as a downstream dependency, but still get early warning when the documentation is broken.

[Carlos Garcia Campos]

(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=230556) [details] [details]
> > Patch
> 
> After discussion with Carlos, we decided that gtkdoc-no-html should never be part of the default target. Instead, build-webkit should manually build it so that we don't introduce gtkdoc as a downstream dependency, but still get early warning when the documentation is broken.

Right, tarball users don't need to build the HTML documentation, because it's already included in the tarball.

[Carlos Garcia Campos]

Comment on attachment 230556 [details]
Patch

So building with gtk-doc enabled should be a pre-requisite of distcheck, right? That's how all other gtk-doc based projects work indeed.

[Martin Robinson]

(In reply to comment #6)
> (From update of attachment 230556 [details])
> So building with gtk-doc enabled should be a pre-requisite of distcheck, right? That's how all other gtk-doc based projects work indeed.

What happens is that gtkdoc is a dependency of 'make dist,' so if you run 'make dist' and haven't used ENABLE_GTKDOC, the documentation will be generated for you.

[Carlos Garcia Campos]

(In reply to comment #7)
> (In reply to comment #6)
> > (From update of attachment 230556 [details] [details])
> > So building with gtk-doc enabled should be a pre-requisite of distcheck, right? That's how all other gtk-doc based projects work indeed.
> 
> What happens is that gtkdoc is a dependency of 'make dist,' so if you run 'make dist' and haven't used ENABLE_GTKDOC, the documentation will be generated for you.

Perfect.

[Carlos Garcia Campos]

Comment on attachment 230556 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=230556&action=review

> Source/cmake/OptionsGTK.cmake:20
> +set(ENABLE_GTKDOC OFF CACHE BOOL "Whether or not to use generate gtkdoc.")

hmm, we use generate-gtkdoc even when this is off no? This actually to decide whether to call generate-gtkdoc with --skip-html or not, right? Please improve this message before landing to avoid confusions.

[Martin Robinson]

Committed r168304: <http://trac.webkit.org/changeset/168304>

[WebKit Commit Bot]

Re-opened since this is blocked by bug 132607

[Carlos Garcia Campos]

My guess is that before this patch, we were not using any target as argument, so 'all' was used as default. Now we are using a target 'gtkdoc-no-html', and it's the only one built. That means that there's no binaries in bin, the bots are using the binaries from previous builds to run the tests.

[Martin Robinson]

Created attachment 231163 [details]
Patch

[Martin Robinson]

I have changed my mind about using build-webkit for this. I think it is better to simply handle everything in CMake. The new patch is simpler and adds gtkdoc-no-html to the default target when developer mode is active and ENABLE_GTKDOC is off (to avoid building the documentation twice).

[Carlos Garcia Campos]

Comment on attachment 231163 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=231163&action=review

Ok, let's try again. Thanks!

> ChangeLog:6
> +        Reviewed by Carlos Garcia Campos.

You see the future! :-)

[Martin Robinson]

(In reply to comment #15)

> > ChangeLog:6
> > +        Reviewed by Carlos Garcia Campos.
> 
> You see the future! :-)


Hah. Left over from the old patch. :)

[Martin Robinson]

Comment on attachment 231163 [details]
Patch

Clearing flags on attachment: 231163

Committed r168591: <http://trac.webkit.org/changeset/168591>

[Martin Robinson]

All reviewed patches have been landed.  Closing bug.

[Carlos Garcia Campos]

How is make install supposed to work?

$ make install
make: *** No rule to make target `install'.  Stop.

[Carlos Garcia Campos]

Ah! it's ninja install (I guess only when building with ninja, we need to document this somewhere). Still doesn't seem to work:

[6/6] Install the project...
FAILED: cd WebKitBuild/Release && /usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "Release"
-- Installing: /home/cgarcia/gnome/lib64/pkgconfig/javascriptcoregtk-3.0.pc
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JavaScript.h
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSBase.h
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSContextRef.h
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSObjectRef.h
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSStringRef.h
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSValueRef.h
-- Installing: /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/WebKitAvailability.h
-- Installing: /home/cgarcia/gnome/share/gir-1.0/JavaScriptCore-3.0.gir
-- Installing: /home/cgarcia/gnome/lib64/girepository-1.0/JavaScriptCore-3.0.typelib
CMake Error at Source/JavaScriptCore/cmake_install.cmake:92 (FILE):
  file INSTALL cannot find
  "WebKitBuild/Release/Source/JavaScriptCore/CMakeFiles/CMakeRelink.dir/libjavascriptcoregtk-3.0.so.0.16.2".
Call Stack (most recent call first):
  Source/cmake_install.cmake:38 (INCLUDE)
  cmake_install.cmake:37 (INCLUDE)


ninja: build stopped: subcommand failed.

[Martin Robinson]

(In reply to comment #20)
> Ah! it's ninja install (I guess only when building with ninja, we need to document this somewhere). Still doesn't seem to work:

Yep, this is what I was referring to in comment #1. We still need to fix the "ninja install."

[Carlos Garcia Campos]

(In reply to comment #21)
> (In reply to comment #20)
> > Ah! it's ninja install (I guess only when building with ninja, we need to document this somewhere). Still doesn't seem to work:
> 
> Yep, this is what I was referring to in comment #1. We still need to fix the "ninja install."

Do we really need to use ninja to install? After ninja install fails, running cmake -P cmake_install.cmake fails with the same error, but running cmake -P cmake_install.cmake after a clean build works perfectly, so it seems ninja is doing something else?

Also when using ninja, cmake is run again (running the 5 targets that are always run due to bug #130075, which is also annoying), but when running cmake -P cmake_install.cmake it starts the install phase directly.

[Carlos Garcia Campos]

It seems that sometimes, when the cmake_install.cmake files are generated, cmake thinks it's not possible to use rpath and creates the files like if it needed to relink before install. I'm not sure why it happens though, but there's something that makes cmake think it needs to relink instead of just removing the rpath.

[Martin Robinson]

(In reply to comment #22)
> Also when using ninja, cmake is run again (running the 5 targets that are always run due to bug #130075, which is also annoying), but when running cmake -P cmake_install.cmake it starts the install phase directly.

I'm not sure why CMake is run again. That should only happen when the build files change. What are the steps to reproduce that?

[Carlos Garcia Campos]

(In reply to comment #24)
> (In reply to comment #22)
> > Also when using ninja, cmake is run again (running the 5 targets that are always run due to bug #130075, which is also annoying), but when running cmake -P cmake_install.cmake it starts the install phase directly.
> 
> I'm not sure why CMake is run again. That should only happen when the build files change. What are the steps to reproduce that?

Simply run ninja install after build-webkit, maybe it's related to bug #130075

[Martin Robinson]

(In reply to comment #25)

> Simply run ninja install after build-webkit, maybe it's related to bug #130075

Just to be clear, is CMake (the configuration) run again or just those 5 targets?

[Carlos Garcia Campos]

(In reply to comment #26)
> (In reply to comment #25)
> 
> > Simply run ninja install after build-webkit, maybe it's related to bug #130075
> 
> Just to be clear, is CMake (the configuration) run again or just those 5 targets?

hmm, I've lost the log, maybe it was "only" the 5 steps. It doesn't happen when running cmake directly, that's for sure.

[Mario Sanchez Prada]

(In reply to comment #20)
> Ah! it's ninja install (I guess only when building with ninja, we need to
> document this somewhere). Still doesn't seem to work:
> 
> [6/6] Install the project...
> FAILED: cd WebKitBuild/Release && /usr/bin/cmake -P cmake_install.cmake
> -- Install configuration: "Release"
> -- Installing: /home/cgarcia/gnome/lib64/pkgconfig/javascriptcoregtk-3.0.pc
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JavaScript.h
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSBase.h
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSContextRef.h
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSObjectRef.h
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSStringRef.h
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/JSValueRef.h
> -- Installing:
> /home/cgarcia/gnome/include/webkitgtk-3.0/JavaScriptCore/WebKitAvailability.h
> -- Installing: /home/cgarcia/gnome/share/gir-1.0/JavaScriptCore-3.0.gir
> -- Installing:
> /home/cgarcia/gnome/lib64/girepository-1.0/JavaScriptCore-3.0.typelib
> CMake Error at Source/JavaScriptCore/cmake_install.cmake:92 (FILE):
>   file INSTALL cannot find
>  
> "WebKitBuild/Release/Source/JavaScriptCore/CMakeFiles/CMakeRelink.dir/
> libjavascriptcoregtk-3.0.so.0.16.2".
> Call Stack (most recent call first):
>   Source/cmake_install.cmake:38 (INCLUDE)
>   cmake_install.cmake:37 (INCLUDE)
> 
> 
> ninja: build stopped: subcommand failed.

Just for the record: I've also got exactly this error message today, while trying to do ninja-build install after building on top of a new commit (and not having done ninja-build install for a while).

I'm now doing a clean build (I eventually would have to do it anyway) and hopefully it will work after it, but thought I would report this issue anyway, just in case.

[Michael Catanzaro]

Yes, I've seen that too, though I've never debugged it. A clean build always fixes it.

[Carlos Garcia Campos]

Yes, that problem was never fixed, but the error is different to the one described in this bug, so let's use a different bug for this.

https://bugs.webkit.org/show_bug.cgi?id=144902