[webkit-dev] Help with review of EFL CMake patches?

[Gustavo Sverzut Barbieri]

On Mon, May 3, 2010 at 6:09 PM, Patrick Roland Gansterer
<paroga at paroga.com> wrote:
> Hi,
>
> On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
> <barbieri at profusion.mobi> wrote:
>> Did you see this new version?  Leandro did the work on top of yours.
>> However he removed the .h from the source list, he did it before he
>> read that it may be useful to get some IDE to show it. If mandatory we
>> can add them back.
> Yes, I've seen it. He did a great job, but there a some parts which are
> not good for a "general buildsystem".
> E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
> ports share some parts. (There some other points too; I'll post them on the
> bug)
>
> My vision is that the root CMake file will do all the "WTF_USE_*" stuff.
> It has to decide all "port specific stuff". All other CMake files should
> only use this "defines". This will provide a central to switch the
> different implementations (e.g. switch between pthread and native threads
> on windows).

The point is to split this off to some ports as these things are
likely to get huge. As said we did some for GTK and EFL, although they
share a lot, the checks became big to make the file a PITA to read.
Although CMake does provide if() and indentation, the branches tend to
be quite long.

also, each folder, like JavaScriptCore/CMakeLists.txt have a
port-specific file included, that may be used to filter or extend the
lists, or to change some variables. This way we can turn on "*core
libraries as shared objects" and have  libJavaScriptCoreGtk.so and
libJavaScriptGtk.so installed. This is not so useful for deployment,
but definitely useful for development where link times tend to be
quite long if you don't have lots of RAM for linking.

Also, this is done in a way that we don't need to anticipate all kind
of different platform behaviors, they can just change the behavior as
intended.


> I already run in some problem with my JavaScriptCore CMake files, but I
> hoped for some feedback I didn't get.

Well, the bits you did were quite unchanged, except by delegating the
options to their own files due the above reasons. So consider these
patches as feedback that works (in the sense of you can try it)


> My big question is if CMake should be added as a universal buildsystem (to
> get rid of some other buildsystems) or if it is only for the EFL port?
> I think this depends on ther progress in the CMake vs. GYP discussion. The
> last post on the mailing list was [1].
>
> - Patrick
>
> [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012662.html

As I said, I really want to get out of the universal thing otherwise
it will not be merged. IMHO it is a much saner approach to do one
example and passively convert those that are willing to use CMake (ie:
Xan said if Gtk works without loss, then he'd be fine to use it).

Alternatively, if moving to GYP will make our build system be accepted
more easily, then just say and we'll take the burden of going that
route. We just want to have all we need in SVN, say to users "get svn,
type this and it is done". Also, maintaining the build off tree proved
painful over the last weeks when files were moved and we had to play
catch up (to fix this we need stuff in svn AND a build bot, i know...
but we'll get there).

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202