Re: [webkit-dev] compact ICU unicode
Hi Mark, I think some Qt port's platform doesn't use ICU either so you might want to coordinate with their maintainer to do this. In fact, WTF had an abstraction layer around ICU to do this the last time I checked. Qt port of WebKit trunk can only be built with Qt v5, which has a hard dependency on ICU. Older version of Qt and WebKit (v4.8) had an option to build with or without ICU. See [1] an [2] for more background information. [1] https://lists.webkit.org/pipermail/webkit-qt/2011-November/002165.html [2] https://bugs.webkit.org/show_bug.cgi?id=76821 Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Christophe Dumez is now a WebKit reviewer
Hi, I'm happy to announce that Christophe Dumez is now a WebKit reviewer. Chris has done great work on WebKit2 (test infrastructure, support for new device APIs) and one of the driving forces behind the EFL port. Lately he has been doing work on the Soup and GStreamer backends and the binding generators. Please join me in congratulating Chris ! Thanks, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Hi ! I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. I think this would be a nice related project, but I wouldn't necessarily want to lump the two goals together without understanding what we'd be shooting for first. From what I know, CMake's support for feature configuration is much more mature than what you can do w/ GYP. It could certainly be a good motivator, though. My recent e-mail ( https://lists.webkit.org/pipermail/webkit-dev/2013-January/023368.html) to the list was an attempt to address the feature configuration problem - assuming that that a single build system is not an option. The idea was to use C macros to describe the rules for feature configurations and figure out a way to populate them to the various build systems (potentially using a C precompiler to eval the macros). Some of feature configuration flags does not need to be exposed to the build system these can just be #include-d to the source. I do not think that this is a technical superiors solution but perhaps it worth considering to discuss as it relies on tools and syntax we happened to already agree on and I felt that what might come out of it is better what we have now. Best, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature configurations
Hi, I wanted to give a heads up that I'm planning to land a patch that moves the ENABLE feature macros out from Platform.h into its own file - see https://bugs.webkit.org/show_bug.cgi?id=105735. After the patch lands I will update our wiki with the changes at http://trac.webkit.org/wiki/AddingFeatures. I consider this as a first step for some other (incremental) changes. I created a meta bug to collect the work - see https://bugs.webkit.org/show_bug.cgi?id=105734 . The (long term) goals are: - Potentially decrease the scope of the flags - e.g. WebCore flags do not need to be visible to JavaScriptCore - Maintain a full list of feature flags in the source code - replace the existing Wiki that is disconnected from the source code - Make it easier to introduce/remove a build flag Any feedback on the goals and/or the approach is welcome here or on the bugs. Thanks, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
