| Summary: | [EFL] Bump EFL libraries to 1.9 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Ryuan Choi <ryuan.choi> | ||||||||||||||||||||||||
| Component: | WebKit EFL | Assignee: | Ryuan Choi <ryuan.choi> | ||||||||||||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||||||||||||
| Severity: | Normal | CC: | buildbot, bunhere, changseok, commit-queue, eflews.bot, gyuyoung.kim, gyuyoung.kim, llango.u-szeged, lucas.de.marchi, mhodovan.u-szeged, ossy, rakuco, rniwa, sergio | ||||||||||||||||||||||||
| Priority: | P2 | ||||||||||||||||||||||||||
| Version: | 528+ (Nightly build) | ||||||||||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||
| Bug Depends on: | 134102 | ||||||||||||||||||||||||||
| Bug Blocks: | |||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
|
Description
Ryuan Choi
2013-12-09 17:38:39 PST
Created attachment 218817 [details]
Patch
Comment on attachment 218817 [details] Patch Attachment 218817 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/46518013 Comment on attachment 218817 [details] Patch Attachment 218817 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/47338063 when I tried to build EFL port with this patch, elementary couldn't be built. Could you check it ? Alternatively, you may set the environment variables ELEMENTARY_CFLAGS and ELEMENTARY_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. *** Error during phase configure of elementary: ########## Error running ./configure --prefix /home/gyuyoung/webkit/WebKit/WebKitBuild/Dependencies/Root --libdir '/home/gyuyoung/webkit/WebKit/WebKitBuild/Dependencies/Root/lib' --disable-emap --disable-eweather --with-elementary-web-backend=none --disable-static --disable-gtk-doc *** [13/22] *** Checking out libxml2 *** [14/22] *** Skipping libxml2 (not updated) *** [14/22] *** Checking out gstreamer *** [15/22] *** Skipping gstreamer (not updated) *** [15/22] *** Checking out gst-plugins-base *** [16/22] *** Skipping gst-plugins-base (not updated) *** [16/22] *** Checking out gst-plugins-good *** [17/22] *** Skipping gst-plugins-good (not updated) *** [17/22] *** Checking out gst-plugins-bad *** [18/22] *** Skipping gst-plugins-bad (not updated) *** [18/22] *** Checking out gst-libav *** [19/22] *** Skipping gst-libav (not updated) *** [19/22] *** Checking out libseccomp *** [20/22] *** Skipping libseccomp (not updated) *** [20/22] *** Checking out atk *** [21/22] *** Skipping atk (not updated) *** [21/22] *** module webkitefl-testing-dependencies not built due to non buildable fonts *** [22/22] *** module webkitefl-testing-dependencies not built due to non buildable e_dbus *** [22/22] *** module webkitefl-testing-dependencies not built due to non buildable elementary *** [22/22] *** the following modules were not built *** [22/22] fonts efl e_dbus elementary webkitefl-testing-dependencies Running jhbuild-wrapper build failed. Died at /home/gyuyoung/webkit/WebKit/Tools/Scripts/update-webkitefl-libs line 23. No such file or directory at /home/gyuyoung/webkit/WebKit/Tools/Scripts/webkitdirs.pm line 2073. On my linux box, efl library can't be built with existing libraries. I should install "libfribidi-dev and libgif-dev" in order to build *efl* library. Though I installed them to my linux box, the *efl* library requires "gstreamer-0.10" that we don't use anymore. Could you check it ? configure: error: Package requirements (gstreamer-0.10) were not met: No package 'gstreamer-0.10' found (In reply to comment #5) > On my linux box, efl library can't be built with existing libraries. I should install "libfribidi-dev and libgif-dev" in order to build *efl* library. > > Though I installed them to my linux box, the *efl* library requires "gstreamer-0.10" that we don't use anymore. Could you check it ? > > > configure: error: Package requirements (gstreamer-0.10) were not met: > > No package 'gstreamer-0.10' found I see, I think that we can disable gstreamer from efl. I will check once more from scratch. Created attachment 218911 [details]
Patch
Comment on attachment 218911 [details] Patch Attachment 218911 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/47568055 Comment on attachment 218911 [details] Patch Attachment 218911 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/45898444 In my linux box, I needed to install "libxp-dev" and "x11proto-print-dev" so that efl-1.8 library can include X11/extensions/Print.h. Anyway, I succeed to build WebKit EFL port based on this patch after installing them. Could you add them to install-dependencies as well ? (In reply to comment #10) > In my linux box, I needed to install "libxp-dev" and "x11proto-print-dev" so that efl-1.8 library can include X11/extensions/Print.h. > > Anyway, I succeed to build WebKit EFL port based on this patch after installing them. > > Could you add them to install-dependencies as well ? BTW, MiniBrowser shows nothing when we use efl 1.8. I think we can't land this after fixing it. (In reply to comment #11) > BTW, MiniBrowser shows nothing when we use efl 1.8. I think we can't land this after fixing it. s/after/before/g (In reply to comment #11) > (In reply to comment #10) > > In my linux box, I needed to install "libxp-dev" and "x11proto-print-dev" so that efl-1.8 library can include X11/extensions/Print.h. > > > > Anyway, I succeed to build WebKit EFL port based on this patch after installing them. > > > > Could you add them to install-dependencies as well ? > > BTW, MiniBrowser shows nothing when we use efl 1.8. I think we can't land this after fixing it. Yes, I reproduced and webProcess looks terminated with it. I will check what's happened. Created attachment 220989 [details]
Patch
(In reply to comment #10) > In my linux box, I needed to install "libxp-dev" and "x11proto-print-dev" so that efl-1.8 library can include X11/extensions/Print.h. > > Anyway, I succeed to build WebKit EFL port based on this patch after installing them. > > Could you add them to install-dependencies as well ? I added x11proto-print-dev into install-dependencies. (libxp-dev is already in install-dependencies) (In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > In my linux box, I needed to install "libxp-dev" and "x11proto-print-dev" so that efl-1.8 library can include X11/extensions/Print.h. > > > > > > Anyway, I succeed to build WebKit EFL port based on this patch after installing them. > > > > > > Could you add them to install-dependencies as well ? > > > > BTW, MiniBrowser shows nothing when we use efl 1.8. I think we can't land this after fixing it. > > Yes, I reproduced and webProcess looks terminated with it. > > I will check what's happened. It looks a bug of EFL with crypto=gnutls (default configuration is openssl). I removed it from jhbuild and looks fine. Comment on attachment 220989 [details] Patch Attachment 220989 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/6518719899500544 Comment on attachment 220989 [details] Patch Attachment 220989 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/4618763806703616 View in context: https://bugs.webkit.org/attachment.cgi?id=220989&action=review > Tools/efl/install-dependencies:43 > + libgcrypt11-dev Missing backslash at the end of this line. Created attachment 224358 [details]
Patch
(In reply to comment #18) > View in context: https://bugs.webkit.org/attachment.cgi?id=220989&action=review > > > Tools/efl/install-dependencies:43 > > + libgcrypt11-dev > > Missing backslash at the end of this line. Oops, fixed mistake. Thanks. (In reply to comment #4) > when I tried to build EFL port with this patch, elementary couldn't be built. Could you check it ? > > > Alternatively, you may set the environment variables ELEMENTARY_CFLAGS > and ELEMENTARY_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > *** Error during phase configure of elementary: ########## Error running ./configure --prefix /home/gyuyoung/webkit/WebKit/WebKitBuild/Dependencies/Root --libdir '/home/gyuyoung/webkit/WebKit/WebKitBuild/Dependencies/Root/lib' --disable-emap --disable-eweather --with-elementary-web-backend=none --disable-static --disable-gtk-doc *** [13/22] I have the same issue. There are some missing packages: checking for ELEMENTARY... no configure: error: Package requirements ( eina >= 1.8.0 eet >= 1.8.0 evas >= 1.8.0 ecore >= 1.8.0 ecore-evas >= 1.8.0 ecore-file >= 1.8.0 ecore-input >= 1.8.0 edje >= 1.8.0 eo >= 1.8.0 ethumb_client >= 1.8.0 emotion >= 1.8.0 ecore-imf >= 1.8.0 ecore-con >= 1.8.0 eio >= 1.8.0 eldbus >= 1.8.0 efreet >= 1.8.0 efreet-mime >= 1.8.0 efreet-trash >= 1.8.0 ) were not met: No package 'eina' found No package 'eet' found No package 'evas' found No package 'ecore' found No package 'ecore-evas' found No package 'ecore-file' found No package 'ecore-input' found No package 'edje' found No package 'eo' found No package 'ethumb_client' found No package 'emotion' found No package 'ecore-imf' found No package 'ecore-con' found No package 'eio' found No package 'eldbus' found No package 'efreet' found No package 'efreet-mime' found No package 'efreet-trash' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Should I set PKG_CONFIG_PATH manually? Where are those packages? (In reply to comment #21) > (In reply to comment #4) > > when I tried to build EFL port with this patch, elementary couldn't be built. Could you check it ? > > > > > > Alternatively, you may set the environment variables ELEMENTARY_CFLAGS > > and ELEMENTARY_LIBS to avoid the need to call pkg-config. > > See the pkg-config man page for more details. > > *** Error during phase configure of elementary: ########## Error running ./configure --prefix /home/gyuyoung/webkit/WebKit/WebKitBuild/Dependencies/Root --libdir '/home/gyuyoung/webkit/WebKit/WebKitBuild/Dependencies/Root/lib' --disable-emap --disable-eweather --with-elementary-web-backend=none --disable-static --disable-gtk-doc *** [13/22] > > I have the same issue. There are some missing packages: > > checking for ELEMENTARY... no > configure: error: Package requirements ( > eina >= 1.8.0 > eet >= 1.8.0 > evas >= 1.8.0 > ecore >= 1.8.0 > ecore-evas >= 1.8.0 > ecore-file >= 1.8.0 > ecore-input >= 1.8.0 > edje >= 1.8.0 > eo >= 1.8.0 > ethumb_client >= 1.8.0 > emotion >= 1.8.0 > ecore-imf >= 1.8.0 > ecore-con >= 1.8.0 > eio >= 1.8.0 > eldbus >= 1.8.0 > efreet >= 1.8.0 > efreet-mime >= 1.8.0 > efreet-trash >= 1.8.0 > > ) were not met: > > No package 'eina' found > No package 'eet' found > No package 'evas' found > No package 'ecore' found > No package 'ecore-evas' found > No package 'ecore-file' found > No package 'ecore-input' found > No package 'edje' found > No package 'eo' found > No package 'ethumb_client' found > No package 'emotion' found > No package 'ecore-imf' found > No package 'ecore-con' found > No package 'eio' found > No package 'eldbus' found > No package 'efreet' found > No package 'efreet-mime' found > No package 'efreet-trash' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > > Should I set PKG_CONFIG_PATH manually? Where are those packages? No. if you are using jhbuild (after Tools/efl/install-dependencies) , it will be because of build failure of efl. Maybe some packages looks still required for efl build. :( Because my laptop already have missing packages, it's little bit difficult to me to reproduce it. (I already tested using virtualbox.) I will check it once more. If you can provide more logs of jhbuild, it will be very useful. Created attachment 224359 [details]
update-webkitefl-libs_1.8.error
View in context: https://bugs.webkit.org/attachment.cgi?id=224358&action=review > Tools/efl/jhbuild.modules:175 > + <deb package="efl"/> I think this should be '<dep package="efl"/>' instead of '<deb ...' There are some <deb ...> tags in the current Tools/efl/jhbuild.modules. Created attachment 225776 [details]
Patch
(In reply to comment #25) > Created an attachment (id=225776) [details] > Patch Ryuan and Laszlo, whose patch is final ? (In reply to comment #25) > Created an attachment (id=225776) [details] > Patch Just a nit: Could you add a credit for the original author in the changelog? I let the technical review for the EFL experts. (In reply to comment #27) > (In reply to comment #25) > > Created an attachment (id=225776) [details] [details] > > Patch > Just a nit: Could you add a credit for the original author in the changelog? > I let the technical review for the EFL experts. Sure. I noticed it after uploaded the proposed patch. If the patch is good, I'll add it before land. :) Comment on attachment 225776 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=225776&action=review > Source/cmake/FindEldbus.cmake:1 > +# - Try to find Eldbus Are these required? EFL 1.8 should install EldbusConfig.cmake, EthumbConfig.cmake and EthumbClientConfig.cmake > Source/cmake/OptionsEfl.cmake:161 > +find_package(Eldbus ${EFL_REQUIRED_VERSION} REQUIRED ${EFL_CONFIG_MODE}) > +find_package(Ethumb ${EFL_REQUIRED_VERSION} REQUIRED ${EFL_CONFIG_MODE}) > +find_package(Ethumb-client ${EFL_REQUIRED_VERSION} REQUIRED ${EFL_CONFIG_MODE}) Can we move them to Tools/MiniBrowser/efl/CMakeLists.txt ? And I think that they shouldn't be "REQUIRED". Created attachment 225975 [details]
Patch
(In reply to comment #29) > (From update of attachment 225776 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=225776&action=review > > > Source/cmake/FindEldbus.cmake:1 > > +# - Try to find Eldbus > > Are these required? > > EFL 1.8 should install EldbusConfig.cmake, EthumbConfig.cmake and EthumbClientConfig.cmake > > > Source/cmake/OptionsEfl.cmake:161 > > +find_package(Eldbus ${EFL_REQUIRED_VERSION} REQUIRED ${EFL_CONFIG_MODE}) > > +find_package(Ethumb ${EFL_REQUIRED_VERSION} REQUIRED ${EFL_CONFIG_MODE}) > > +find_package(Ethumb-client ${EFL_REQUIRED_VERSION} REQUIRED ${EFL_CONFIG_MODE}) > > Can we move them to Tools/MiniBrowser/efl/CMakeLists.txt ? > > And I think that they shouldn't be "REQUIRED". I checked and you are right, we don't need those new cmake files. Updated the patch. Created attachment 228043 [details]
Patch
Comment on attachment 228043 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > ChangeLog:17 > + * Source/cmake/FindEcore.cmake: Removed. > + * Source/cmake/FindEdje.cmake: Removed. > + * Source/cmake/FindEet.cmake: Removed. > + * Source/cmake/FindEeze.cmake: Removed. > + * Source/cmake/FindEfreet.cmake: Removed. > + * Source/cmake/FindEina.cmake: Removed. > + * Source/cmake/FindElementary.cmake: Removed. > + * Source/cmake/FindEvas.cmake: Removed. Should we remove them? Although we bumped, we don't decide yet whether we drop support of EFL 1.7. (In reply to comment #33) > (From update of attachment 228043 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > > > ChangeLog:17 > > + * Source/cmake/FindEcore.cmake: Removed. > > + * Source/cmake/FindEdje.cmake: Removed. > > + * Source/cmake/FindEet.cmake: Removed. > > + * Source/cmake/FindEeze.cmake: Removed. > > + * Source/cmake/FindEfreet.cmake: Removed. > > + * Source/cmake/FindEina.cmake: Removed. > > + * Source/cmake/FindElementary.cmake: Removed. > > + * Source/cmake/FindEvas.cmake: Removed. > > Should we remove them? > > Although we bumped, we don't decide yet whether we drop support of EFL 1.7. If we don't want to drop EFL 1.7, then we shouldn't remove those files. I misunderstood this. Are the other parts of patch good? Comment on attachment 228043 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > Tools/efl/jhbuildrc:26 > + > +# FIXME: MAKEFLAGS must be set to '-j1' because the EFL 1.9 dependency. Without this the > +# install part of EFL fails. Remove it, when a newer version of EFL can build without this. > +os.environ['MAKEFLAGS'] = '-j1' Other parts are fine although it is little bit interesting. Can you show what is complained? Anyway, I will try it also. (In reply to comment #35) > (From update of attachment 228043 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > > > Tools/efl/jhbuildrc:26 > > + > > +# FIXME: MAKEFLAGS must be set to '-j1' because the EFL 1.9 dependency. Without this the > > +# install part of EFL fails. Remove it, when a newer version of EFL can build without this. > > +os.environ['MAKEFLAGS'] = '-j1' > > Other parts are fine although it is little bit interesting. > Can you show what is complained? > > Anyway, I will try it also. I agree, if there's some problem with the dependencies in EFL's build system it would be good to fix it there and add a patch until it makes it into a release. (In reply to comment #35) > (From update of attachment 228043 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > > > Tools/efl/jhbuildrc:26 > > + > > +# FIXME: MAKEFLAGS must be set to '-j1' because the EFL 1.9 dependency. Without this the > > +# install part of EFL fails. Remove it, when a newer version of EFL can build without this. > > +os.environ['MAKEFLAGS'] = '-j1' > > Other parts are fine although it is little bit interesting. > Can you show what is complained? > > Anyway, I will try it also. There are many linker errors in the build. I've already uploaded the error log: https://bugs.webkit.org/attachment.cgi?id=224359 I don't know why the MAKEFLAGS option breaks the build with a higher -j setting. But that was the only way that worked for me. The main problem is that, I've set MAKEFLAGS=-j30 in my .bashrc file for icecc builds, so I had to override this, because someone can do the same and run into this build failure. It is really strange because I can use the NUMBER_OF_PROCESSORS environment variable for multi-thread build, and works fine. Btw, I'm still using Ubuntu 12.04 if it matters. Comment on attachment 228043 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > Tools/efl/jhbuildrc:30 > +# Enforce use_lib64 as False because CMake can't find lib64/cmake/<name> folder > +# where EFL libraries install their <Name>Config.cmake. > +use_lib64 = False Are you sure? From `cmake --help-command find_package': CMake constructs a set of possible installation prefixes for the package. Under each prefix several directories are searched for a configuration file. The tables below show the directories searched. Each entry is meant for installation trees following Windows (W), UNIX (U), or Apple (A) conventions. <prefix>/ (W) <prefix>/(cmake|CMake)/ (W) <prefix>/<name>*/ (W) <prefix>/<name>*/(cmake|CMake)/ (W) <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U) <prefix>/(lib/<arch>|lib|share)/<name>*/ (U) <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U) (In reply to comment #38) > (From update of attachment 228043 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=228043&action=review > > > Tools/efl/jhbuildrc:30 > > +# Enforce use_lib64 as False because CMake can't find lib64/cmake/<name> folder > > +# where EFL libraries install their <Name>Config.cmake. > > +use_lib64 = False > > Are you sure? > > From `cmake --help-command find_package': > > CMake constructs a set of possible installation prefixes for the > package. Under each prefix several directories are searched for a > configuration file. The tables below show the directories searched. > Each entry is meant for installation trees following Windows (W), UNIX > (U), or Apple (A) conventions. > > <prefix>/ (W) > <prefix>/(cmake|CMake)/ (W) > <prefix>/<name>*/ (W) > <prefix>/<name>*/(cmake|CMake)/ (W) > <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U) > <prefix>/(lib/<arch>|lib|share)/<name>*/ (U) > <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U) sure, Like above explained, cmake only search lib/arch or lib or share not lib64 but EFL install <Name>Config.cmake to libdir which jhbuild override as 'lib64' (In reply to comment #39) > sure, Like above explained, cmake only search lib/arch or lib or share not lib64 but EFL install <Name>Config.cmake to libdir which jhbuild override as 'lib64' Not really; CMake should also look in lib64 if FIND_LIBRARY_USE_LIB64_PATHS is set, and it is most of the time (see Modules/Platform/UnixPaths.cmake). It's probably causing problems for you guys because CMake explicitly sets this to false on Debian-based systems. I'd update the comment to reflect this fact. Something like "explicitly disable use_lib64, as whether CMake will look into lib64 depends on the distro: Debian-based systems have FIND_LIBRARY_USE_LIB64_PATHS set to false. jhbuild, on the other hand, unconditionally installs files into lib64, which causes problems for us". One potential problem of changing use_lib64 is that users who have existing jhbuild build directories with stuff installed into lib64 may have problems with CMake's detection since Tools/jhbuild/jhbuildrc_common.py will not use lib64 when setting CMAKE_LIBRARY_PATH and PKG_CONFIG_PATH. I'm not sure how serious this might be other than some people getting confused. If it really is, another workaround would be appending "prefix/_library_dir" to CMAKE_PREFIX_PATH in jhbuildrc_common.py, but it's not very beautiful. Created attachment 228160 [details]
Patch
Comment on attachment 228160 [details] Patch Attachment 228160 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5774572892717056 New failing tests: media/adopt-node-crash.html Created attachment 228166 [details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Comment on attachment 228160 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228160&action=review > Source/cmake/OptionsEfl.cmake:2 > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > + This will cause problems for downstreams such as Debian-based distros, as this basically reverts what CMake itself is doing. It's better to change CMAKE_PREFIX_PATH or just disable use_lib64 instead as before with a better comment. (In reply to comment #45) > (From update of attachment 228160 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=228160&action=review > > > Source/cmake/OptionsEfl.cmake:2 > > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > > + > > This will cause problems for downstreams such as Debian-based distros, as this basically reverts what CMake itself is doing. It's better to change CMAKE_PREFIX_PATH or just disable use_lib64 instead as before with a better comment. +1. For me, disabling use_lib64 is better but I don't object to specify CMAKE_PREFIX_PATH. I heard that someone use both GTK and EFL port as one jhbuild directory. (In reply to comment #46) > (In reply to comment #45) > > (From update of attachment 228160 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=228160&action=review > > > > > Source/cmake/OptionsEfl.cmake:2 > > > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > > > + > > > > This will cause problems for downstreams such as Debian-based distros, as this basically reverts what CMake itself is doing. It's better to change CMAKE_PREFIX_PATH or just disable use_lib64 instead as before with a better comment. > > +1. > For me, disabling use_lib64 is better but I don't object to specify CMAKE_PREFIX_PATH. > > I heard that someone use both GTK and EFL port as one jhbuild directory. Lango ? Are you still working for this ? (In reply to comment #47) > (In reply to comment #46) > > (In reply to comment #45) > > > (From update of attachment 228160 [details] [details] [details]) > > > View in context: https://bugs.webkit.org/attachment.cgi?id=228160&action=review > > > > > > > Source/cmake/OptionsEfl.cmake:2 > > > > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > > > > + > > > > > > This will cause problems for downstreams such as Debian-based distros, as this basically reverts what CMake itself is doing. It's better to change CMAKE_PREFIX_PATH or just disable use_lib64 instead as before with a better comment. > > > > +1. > > For me, disabling use_lib64 is better but I don't object to specify CMAKE_PREFIX_PATH. > > > > I heard that someone use both GTK and EFL port as one jhbuild directory. > > Lango ? Are you still working for this ? Sorry for the late reaction. I have not much time for this at the moment, but my colleague (hmartin) will update the patch soon. :) Created attachment 230907 [details]
Proposed patch
(In reply to comment #49) > Created an attachment (id=230907) [details] > Proposed patch gyuyoung, could you try this once more? 1.10 is out now, do we really want to still use the old 1.7? https://phab.enlightenment.org/phame/live/3/post/efl_1_10_is_out/ Comment on attachment 230907 [details]
Proposed patch
Sorry for too late review. LGTM. However, this patch looks out of date. Please rebase this patch.
(In reply to comment #52) > (From update of attachment 230907 [details]) > Sorry for too late review. LGTM. However, this patch looks out of date. Please rebase this patch. thanks, I will rebase and land it. Committed r169785: <http://trac.webkit.org/changeset/169785> Comment on attachment 230907 [details]
Proposed patch
landed after resolving conflict.
|