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 > > <[email protected]> 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, _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
