Bug 130188

Summary: [GTK][CMake] Unable to do make install
Product: WebKit Reporter: Manuel Rego Casasnovas <rego>
Component: WebKitGTKAssignee: Martin Robinson <mrobinson>
Status: RESOLVED FIXED    
Severity: Normal CC: aperez, bunhere, cgarcia, commit-queue, dbates, gyuyoung.kim, mario, mcatanzaro, mrobinson, rakuco, sergio
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 132607    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description Manuel Rego Casasnovas 2014-03-13 03:45:18 PDT
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.
Comment 1 Martin Robinson 2014-04-29 15:43:52 PDT
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.
Comment 2 Martin Robinson 2014-04-29 16:54:50 PDT
Created attachment 230440 [details]
Patch
Comment 3 Martin Robinson 2014-04-30 19:52:20 PDT
Created attachment 230556 [details]
Patch
Comment 4 Martin Robinson 2014-04-30 19:53:24 PDT
(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.
Comment 5 Carlos Garcia Campos 2014-05-01 01:06:22 PDT
(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.
Comment 6 Carlos Garcia Campos 2014-05-01 01:10:24 PDT
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.
Comment 7 Martin Robinson 2014-05-01 07:31:58 PDT
(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.
Comment 8 Carlos Garcia Campos 2014-05-03 03:56:24 PDT
(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.
Comment 9 Carlos Garcia Campos 2014-05-03 04:00:43 PDT
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.
Comment 10 Martin Robinson 2014-05-05 11:38:33 PDT
Committed r168304: <http://trac.webkit.org/changeset/168304>
Comment 11 WebKit Commit Bot 2014-05-06 06:31:09 PDT
Re-opened since this is blocked by bug 132607
Comment 12 Carlos Garcia Campos 2014-05-06 06:34:07 PDT
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.
Comment 13 Martin Robinson 2014-05-09 10:30:20 PDT
Created attachment 231163 [details]
Patch
Comment 14 Martin Robinson 2014-05-09 10:40:12 PDT
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).
Comment 15 Carlos Garcia Campos 2014-05-09 23:46:32 PDT
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! :-)
Comment 16 Martin Robinson 2014-05-10 19:00:11 PDT
(In reply to comment #15)

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


Hah. Left over from the old patch. :)
Comment 17 Martin Robinson 2014-05-10 19:14:35 PDT
Comment on attachment 231163 [details]
Patch

Clearing flags on attachment: 231163

Committed r168591: <http://trac.webkit.org/changeset/168591>
Comment 18 Martin Robinson 2014-05-10 19:14:42 PDT
All reviewed patches have been landed.  Closing bug.
Comment 19 Carlos Garcia Campos 2014-05-11 00:55:46 PDT
How is make install supposed to work?

$ make install
make: *** No rule to make target `install'.  Stop.
Comment 20 Carlos Garcia Campos 2014-05-11 06:58:20 PDT
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.
Comment 21 Martin Robinson 2014-05-11 09:31:28 PDT
(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."
Comment 22 Carlos Garcia Campos 2014-05-12 04:30:17 PDT
(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.
Comment 23 Carlos Garcia Campos 2014-05-12 06:22:38 PDT
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.
Comment 24 Martin Robinson 2014-05-12 07:44:57 PDT
(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?
Comment 25 Carlos Garcia Campos 2014-05-12 08:03:13 PDT
(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
Comment 26 Martin Robinson 2014-05-12 08:05:01 PDT
(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?
Comment 27 Carlos Garcia Campos 2014-05-12 08:12:22 PDT
(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.
Comment 28 Mario Sanchez Prada 2015-05-11 09:37:24 PDT
(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.
Comment 29 Michael Catanzaro 2015-05-11 10:16:21 PDT
Yes, I've seen that too, though I've never debugged it. A clean build always fixes it.
Comment 30 Carlos Garcia Campos 2015-05-11 23:32:02 PDT
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