Bug 112522 - [EFL][jhbuild] Build Evas with EGL and GLES2 support.
Summary: [EFL][jhbuild] Build Evas with EGL and GLES2 support.
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Kalyan
URL:
Keywords:
Depends on:
Blocks: 105286
  Show dependency treegraph
 
Reported: 2013-03-17 15:24 PDT by Kalyan
Modified: 2013-03-20 04:47 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kalyan 2013-03-17 15:24:50 PDT
I have been able to build evas with EGL and GLES2 support by changing the following line in jhbuild.modules in Tools\efl 

Original:

  <autotools id="evas" autogen-sh="configure">

Changed:

  <autotools id="evas" autogen-sh="configure" autogenargs="--enable-gl-flavor-gles --enable-gles-variety-sgx --disable-doc">

I am not so familiar as to how jhbuild works. There are various scenarios to take care of:

1)Build Evas with EGL and GLES2 support only when it is explicitly requested during compiling of Efl port. i.e "-DENABLE_EGL=ON -ENABLEGLES2=ON". 
2)If underlying system doesn't support EGL and GLES2 combination, intimate the user (with compile time error). We might want to fallback to GLX automatically or let the user configure again without EGL and GLES2 support.
3)If last configuration was with EGL and GLES2 support and user re-compiles with GLX support. In this case we should probably re build the complete dependencies (at least EFL libraries). Would this be covered by re-compiling efl port with ----update-efl flag??
Comment 1 Raphael Kubo da Costa (:rakuco) 2013-03-18 05:30:23 PDT
(In reply to comment #0)
> 1)Build Evas with EGL and GLES2 support only when it is explicitly requested during compiling of Efl port. i.e "-DENABLE_EGL=ON -ENABLEGLES2=ON".

We normally just try to keep the dependencies we build with jhbuild aligned with the defaults we set when building WebKit with build-webkit. That is, if we enable EGL/GLES2 by default when using build-webkit, Evas should enable them as well.

> 2)If underlying system doesn't support EGL and GLES2 combination, intimate the user (with compile time error). We might want to fallback to GLX automatically or let the user configure again without EGL and GLES2 support.

Is this something jhbuild-specific or do you mean EGL/GLES2 are always required? From what I could understand, you mean the build system should check if Evas has EGL/GLES2 support and act accordingly depending on the result.

> 3)If last configuration was with EGL and GLES2 support and user re-compiles with GLX support. In this case we should probably re build the complete dependencies (at least EFL libraries). Would this be covered by re-compiling efl port with ----update-efl flag??

If the user is manually changing the configuration options in jhbuild.modules, I think we can assume he is well aware of what needs to be rebuilt. In any case, we always check jhbuild.module's MD5 checksum when update-webkitefl-libs (which is invoked by build-webkit --update-efl is called), so if the file is changed all modules are rebuilt anyway.
Comment 2 Kalyan 2013-03-18 05:49:45 PDT
(In reply to comment #1)
> (In reply to comment #0)
> > 1)Build Evas with EGL and GLES2 support only when it is explicitly requested during compiling of Efl port. i.e "-DENABLE_EGL=ON -ENABLEGLES2=ON".
> 
> We normally just try to keep the dependencies we build with jhbuild aligned with the defaults we set when building WebKit with build-webkit. That is, if we enable EGL/GLES2 by default when using build-webkit, Evas should enable them as well.

Probably we are not ready for it yet and we wont have these as default params for Desktop at least. This was to make life easy, while improving support for EGL+ GLES combination. The main idea was to be able to build our port with GLES support on Desktop.

> > 2)If underlying system doesn't support EGL and GLES2 combination, intimate the user (with compile time error). We might want to fallback to GLX automatically or let the user configure again without EGL and GLES2 support.
> Is this something jhbuild-specific or do you mean EGL/GLES2 are always required? From what I could understand, you mean the build system should check >if Evas has EGL/GLES2 support and act accordingly depending on the result.

EVAS does check if the underlying system has support for GLES2, before trying to compile with the support enabled. I was wondering if we can somehow do this check before Jhbuild is invoked to pass in the right params for building EVAS.

For example:

1)User enables EGL and GLES2 support during configure time.
2)We could check if underlying system(i.e DeskTop) has EGL and GLES2 support. If it does have the support, than we should use the following args while compiling EVAS :
 <autotools id="evas" autogen-sh="configure" autogenargs="--enable-gl-flavor-gles --enable-gles-variety-sgx --disable-doc">
 
else if the system doesn't have support for it than <autotools id="evas" autogen-sh="configure"> should be preferred.

The other way is to have these instructions(JHBuild change and EFL config params) written to our wiki page  and any developers interested in this could try it out themselves.
Comment 3 Raphael Kubo da Costa (:rakuco) 2013-03-18 09:08:56 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > 1)Build Evas with EGL and GLES2 support only when it is explicitly requested during compiling of Efl port. i.e "-DENABLE_EGL=ON -ENABLEGLES2=ON".
> >
> > We normally just try to keep the dependencies we build with jhbuild aligned with the defaults we set when building WebKit with build-webkit. That is, if we enable EGL/GLES2 by default when using build-webkit, Evas should enable them as well.
>
> Probably we are not ready for it yet and we wont have these as default params for Desktop at least. This was to make life easy, while improving support for EGL+ GLES combination. The main idea was to be able to build our port with GLES support on Desktop.

Can't we always pass these parameters to evas' configure script (in the sense that if EGL/GLES2 is not supported in the system nothing breaks)? It then becomes a matter of enabling those in CMake by default when we can finally do so.

> 1)User enables EGL and GLES2 support during configure time.
> 2)We could check if underlying system(i.e DeskTop) has EGL and GLES2 support. If it does have the support, than we should use the following args while compiling EVAS :
>  <autotools id="evas" autogen-sh="configure" autogenargs="--enable-gl-flavor-gles --enable-gles-variety-sgx --disable-doc">
>
> else if the system doesn't have support for it than <autotools id="evas" autogen-sh="configure"> should be preferred.

It is not possible to do that easily, I think. jhbuild simply reads an XML file and builds stuff. Detecting what is present in the system ourselves would amount to duplicating what's already done by the build systems we use -- even if we do manage to write some lines of Perl and detect the presence of EGL/GLES2 it does not look like a good solution to me.

> The other way is to have these instructions(JHBuild change and EFL config params) written to our wiki page  and any developers interested in this could try it out themselves.

From what I understood, we can just always try to enable support for EGL/GLES2 in Evas and tell developers to activate some flags in CMake if they want to build WebKit with support for it as well, right? If so, just documenting things on the wiki sounds perfectly reasonable.
Comment 4 Kalyan 2013-03-20 04:47:20 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > > 1)Build Evas with EGL and GLES2 support only when it is explicitly requested during compiling of Efl port. i.e "-DENABLE_EGL=ON -ENABLEGLES2=ON".
> > >
>

Adding instructions to Wiki seems more practical to me. I will mark this as Wont Fix.