Just a friendly "ping", if someone could help us get this merged, say
it. If you see a big blocker after my last comment, say it.
Meanwhile, Leandro is working on generic webkit option, to be more
generic than my initial {ADD,DEL}_FEATURE().
BR,
On Mon, May 3, 2010 at 6:32 PM, Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> wrote:
> On Mon, May 3, 2010 at 6:09 PM, Patrick Roland Gansterer
> <par...@paroga.com> wrote:
>> Hi,
>>
>> On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
>> <barbi...@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: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
