Bug 125479 – [EFL] Bump EFL libraries to 1.9

• Component: WebKit EFL
• Status: RESOLVED FIXED

[Ryuan Choi]

Now, EFL was released 1.8.X

So, I believe that WebKit/EFl development environment should be moved to EFL 1.8.

[Ryuan Choi]

Created attachment 218817 [details]
Patch

[EFL EWS Bot]

Comment on attachment 218817 [details]
Patch

Attachment 218817 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/46518013

[EFL EWS Bot]

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

[Gyuyoung Kim]

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.

[Gyuyoung Kim]

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

[Ryuan Choi]

(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.

[Ryuan Choi]

Created attachment 218911 [details]
Patch

[EFL EWS Bot]

Comment on attachment 218911 [details]
Patch

Attachment 218911 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/47568055

[EFL EWS Bot]

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

[Gyuyoung Kim]

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 ?

[Gyuyoung Kim]

(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.

[Gyuyoung Kim]

(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

[Ryuan Choi]

(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.

[Ryuan Choi]

Created attachment 220989 [details]
Patch

[Ryuan Choi]

(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.

[EFL EWS Bot]

Comment on attachment 220989 [details]
Patch

Attachment 220989 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/6518719899500544

[EFL EWS Bot]

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

[László Langó]

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.

[Ryuan Choi]

Created attachment 224358 [details]
Patch

[Ryuan Choi]

(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.

[László Langó]

(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?

[Ryuan Choi]

(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.

[László Langó]

Created attachment 224359 [details]
update-webkitefl-libs_1.8.error

[László Langó]

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.

[László Langó]

Created attachment 225776 [details]
Patch

[Gyuyoung Kim]

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

Ryuan and Laszlo, whose patch is final ?

[Csaba Osztrogonác]

(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.

[László Langó]

(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. :)

[Ryuan Choi]

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".

[László Langó]

Created attachment 225975 [details]
Patch

[László Langó]

(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.

[László Langó]

Created attachment 228043 [details]
Patch

[Ryuan Choi]

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.

[László Langó]

(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?

[Ryuan Choi]

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.

[Raphael Kubo da Costa (:rakuco)]

(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.

[László Langó]

(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.

[Raphael Kubo da Costa (:rakuco)]

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)

[Ryuan Choi]

(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'

[Raphael Kubo da Costa (:rakuco)]

(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".

[Raphael Kubo da Costa (:rakuco)]

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.

[László Langó]

Created attachment 228160 [details]
Patch

[Build Bot]

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

[Build Bot]

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

[Raphael Kubo da Costa (:rakuco)]

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.

[Ryuan Choi]

(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.

[Ryuan Choi]

(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 ?

[László Langó]

(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. :)

[Martin Hodovan]

Created attachment 230907 [details]
Proposed patch

[Ryuan Choi]

(In reply to comment #49)
> Created an attachment (id=230907) [details]
> Proposed patch

gyuyoung, could you try this once more?

[Csaba Osztrogonác]

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/

[Gyuyoung Kim]

Comment on attachment 230907 [details]
Proposed patch

Sorry for too late review. LGTM. However, this patch looks out of date. Please rebase this patch.

[Ryuan Choi]

(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.

[Ryuan Choi]

Committed r169785: <http://trac.webkit.org/changeset/169785>

[Ryuan Choi]

Comment on attachment 230907 [details]
Proposed patch

landed after resolving conflict.