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

[Adam Treat]

I'd really like to see this on bugs.webkit.org with a proper patch splitting 
out the CMake portion.  I understand that this is primarily motivated by your 
desire to see EFL port build, rather than to solve the build system problem, 
but this *DOES* add a new build system to the tree.  I think we have to see if 
we can get the Apple showstopper cleared up.  I think installing CMake sources 
and getting Bill's help to create a streamlined CMake binary is a great idea.

Adam

On Tuesday 20 April 2010 08:29:55 am Gustavo Sverzut Barbieri wrote:
> 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,