Summary: | [GTK][CMake] Unable to do make install | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Manuel Rego Casasnovas <rego> | ||||||||
Component: | WebKitGTK | Assignee: | 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
Manuel Rego Casasnovas
2014-03-13 03:45:18 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. Created attachment 230440 [details]
Patch
Created attachment 230556 [details]
Patch
(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. (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 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.
(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. (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 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. Committed r168304: <http://trac.webkit.org/changeset/168304> Re-opened since this is blocked by bug 132607 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. Created attachment 231163 [details]
Patch
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 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! :-) (In reply to comment #15) > > ChangeLog:6 > > + Reviewed by Carlos Garcia Campos. > > You see the future! :-) Hah. Left over from the old patch. :) Comment on attachment 231163 [details] Patch Clearing flags on attachment: 231163 Committed r168591: <http://trac.webkit.org/changeset/168591> All reviewed patches have been landed. Closing bug. How is make install supposed to work? $ make install make: *** No rule to make target `install'. Stop. 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. (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." (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. 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. (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? (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 (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? (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. (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. Yes, I've seen that too, though I've never debugged it. A clean build always fixes it. 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 |