[webkit-dev] Fwd: CMake WebKit-EFL: initial preview

[Gustavo Sverzut Barbieri]

On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer
<paroga at paroga.com> wrote:
> Hi,
>
> Gustavo Sverzut Barbieri:
>> Find attached 2 patches.
>>
>> ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that
>> implements CMake support for WebKit-EFL and also adds the missing
>> patches to make it compile (but runs with some bugs, needs updating to
>> some api changes). Apply it if you want to compile the port (also get
>> EFL from svn, see http://svn.enlightenment.org/)
>>
>> ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single
>> CMakeLists.txt and support *.cmake modules
>>
>> Please take a look if you are interested in CMake for WebKit-EFL.
>>
>> If you know CMake already, review it and send comments. My team just
>> started with CMake some days ago.
>
> Can you please post the patch at bugs.webkit.org.

will do as soon as we get the ".pc" generated and installed, otherwise
the external programs cannot know how to link to it.


> Maybe you can split it into a CMake and a "other stuff" part. (Was it already
> before you merged it?)

It is already, the patch is at
http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch


> I'd like to give you some feedback at the bug comments. The CMake file should
> be split into different projects for example.

Hum... I saw everywhere that it was common to split in multiple
directories, particularly for JavaScriptCore and WebCore. But given
that I wanted to keep it simple, I forced it to be one single file to
make merge into SVN easier. I was also worried about the propagation
of settings and flags to the sub-folders. But yes, I notice that it
will make easier to use INCLUDE_DIRECTORIES() as we'd just have one
target per directory.

Our primary goal is not to join into the recent GYP x CMAKE
discussion, but we need our EFL port fully landed to avoid the
overhead we're doing now. We were using the GTK autotools, as we were
more familiar with it, but given it is slow and messy, the GTK guys
did not want to merge our patches right away, requesting a cleanup of
existing code first. We did part of the cleanup and CMake in parallel,
but CMake worked out quite nice and we don't plan to use GTK's
autotools anymore (but we did send the cleanup we achieved until now).
   That is to say that making it simple to be merged is our first aim.

One more thing I'd like to kindly ask you is if you can also post
patches to the CMake files. This is because our team is already
suffering to match the latest WeKit changes (we have already a huge
queue waiting to be merged, and now patches have to be rebased and so
on). So the more help, the better! :-)

BR,

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