Re: [webkit-dev] WebKit Wishes

[Eric Seidel]

On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard  wrote:
> On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel  wrote:
>> I wish we only had one build system (it were easy to add/remove/move files).
>>
>> I believe changes like http://trac.webkit.org/changeset/74849 are an
>> unhealthy sign for the project.  Adam is not the only person who has chosen
>> to empty files instead of removing them.  The pain of updating 8 build
>> system is so great, we jump through hoops to avoid it.  Which means it took
>> us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
>> WebCore/platform.
>>
>>
>> I wish I felt like reviewers understood/trusted each other more.
>>
>> I’ve worked at both Apple and Google.  The WebKit community is full of
>> brilliant engineers.  Yet I frequently feel a lack of trust in my (or
>> others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
>> don’t think it’s that people don’t trust me after nearly 8 years (!?) on
>> this project, but rather that we forget, or fail to communicate trust among
>> ourselves.  Social problems are perhaps harder to solve for us technical
>> types, but I worry that for many of us it’s just become “us” and “them” and
>> we’ve stopped trying.
>>
>>
>> I wish it were easy to work on feature branches.
>>
>> We have no good solution for features.  For one-patch features, you do them
>> on your own.  For larger, you maybe use github or most likely you just land
>> on trunk behind a #define.  None of these have worked well.  Some of this is
>> the limits of SVN, but it should be trivial for someone to work on a new
>> feature a long time, w/o endangering trunk or having massive merge pain
>> every day.  Other projects can do this.  So should we.  This is both
>> impeding progress, and destabilizing trunk.
>>
>>
>> I wish we didn’t have to worry about platforms we couldn’t test.
>>
>> It can’t be the job of the core maintainers to care about all the peripheral
>> ports which contribute very little core code. Our code needs to be
>> structured in such a manner that its easy for the core to march forward,
>> while letting the ports catch up as they need to asynchronously.  Platform
>> support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
>> platform abstractions should be trivial, but core developers (which probably
>> 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
>> worry about keeping all ports working.
>
> Sure. I'm wondering how you would define a "peripheral" port? Anything
> not Apple or Google?

I guess I would go the other way and define some sort of "kernel"
ports which should never be broken by a patch.  Those ports are
defined as the ones which added-up account for 90% or 80% or something
of WebCore developers.

The idea here is not one of exclusion, but rather one of productivity.
 We need to keep our WebCore developers as productive as possible, so
we should not break their builds, but they shouldn't need to worry
about breaking uncommon builds.

As I've said in other mails, this is *completely our fault*.  And by
"our" I mean all of us who were around 6 years ago when we designed
the porting layer.  I think we didn't understand then how exposing the
details of a port into WebCore would bind us.

We can have our cake and eat it too!  We can have lots of ports and
yet never have to care about them (and never have them break!).  But I
don't believe we can do that with current WebCore designs, where
WebCore knows intimate details about each port. :(

In my dream WebCore would not have a single PLATFORM() #if.

> Many "little" ports are very active every day, sure some of them does
> not contribute as much as they should on common parts but some
> companies behind these are just limited on resources. They are not
> Google or Apple with an army of engineers who have time to take any
> spec of W3C and implements it.

Agreed!

> In WebCore the contribution is pain mostly because the buildsystem.
> For the rest if EWS goes red, in many cases it's a real bug, a real
> problem.
>
> Coming from a so called "peripheral" port I find very frustrating and
> demotivating that our contributions are devalorized the way they are
> or our reviews discredited. Many of us contributes important feature
> and improvements to WebCore and sure not as visible as Google or Apple
> in terms of log but still crucial or important.

I can only imagine.  I wish it were easier for you, not harder. :(

> I believe you and many people are not aware what "little" ports
> contribute because we don't work on high visibility feature such as
> Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR,
> media queries, viewport interactions, @viewport rule, various work on
> tests infrastructure, WebGL fixes) and I'm talking only of the people
> in my company and I'm probably forgetting some work. The number of
> contributions per day makes hard for me to see what others than Google
> or Apple are doing.

Oh, I

Re: [webkit-dev] WebKit Wishes

[Eric Seidel]

On Wed, Jan 30, 2013 at 3:24 PM, Patrick Gansterer  wrote:
> Hi,
>
> Am 30.01.2013 um 22:28 schrieb Eric Seidel:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
>
> I've created CMake files for two different ports at [1] and [2] already, but
> did't get positive feedback from the port-maintainer. So I stopped working
> on it. If any port is still interested in switching to CMake I'd like to
> help creating the required files, but only with feedback of the
> port-maintainer.

The only solution which matters is one which gets AppleMac to move.

Apple Mac WK2 accounts for a large portion of developers/reviewers,
and is also by far the hardest build system to edit.

> -- Patrick
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=72816
> [2] https://bugs.webkit.org/show_bug.cgi?id=73100
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Wishes

[Eric Seidel]

On Wed, Jan 30, 2013 at 2:11 PM, Xan Lopez  wrote:
> Hi Eric,
>
> On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel  wrote:
>> I wish we didn’t have to worry about platforms we couldn’t test.
>>
>> It can’t be the job of the core maintainers to care about all the peripheral
>> ports which contribute very little core code. Our code needs to be
>> structured in such a manner that its easy for the core to march forward,
>> while letting the ports catch up as they need to asynchronously.  Platform
>> support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
>> platform abstractions should be trivial, but core developers (which probably
>> 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
>> worry about keeping all ports working.
>
> I agree this is a hard problem. Also a stressful situation to get
> oneself into. Coming up with ways to allow port code to survive core
> changes would be excellent for everyone, even for the "small ports"
> people who hack on the core and also cannot easily test Mac WK2,
> Chromium Linux or any other port.
>
>>
>> I write less out of pain, and more out of hope for the future.  I believe
>> all of these are solvable problems, but I believe we need the will to solve
>> them.  Apple’s recent announcement of WebKit2 lockdown is clearly one
>> attempt at some of these.  But for the other 50% of WebKit developers who
>> don’t work on WebKit2, locking down WebCore is not a good solution.
>
> I agree the WebKit2 lockdown is one attempt at solving this, but
> hopefully we can agree it's not a particularly innovative one.
> Breaking builds and allowing bugs to pile up while they are fixed is a
> nasty situation, one that historically we have tried really hard to
> avoid for very well known reasons. I understand in the final analysis
> allowing the core to move fast could be more important than having an
> healthy ecosystem of minor ports without huge teams behind them, but I
> really hope that this is only a temporary solution and that in the
> future we'll be able to find better solutions like those that you
> suggest in your email.
>
> Also, on a personal note, I've been around for enough years to
> remember the time when people trying to get ports started were eagerly
> welcomed by Apple employees, who would go out of their way to help us
> get started, review our patches when we had no reviewers in our team,
> patiently explain this or that part of the code, etc. I made sure to
> tell everyone I knew that WebKit was one of the most well managed open
> source projects in existence, one of those rare combinations of
> success and fidelity to some of the best values that open source
> supposedly represents. It is with a bit of sadness that years later I
> find that the same project (even the same people) now has a very
> different attitude, and that long term contributors who I believe have
> modestly helped to make this project more robust and popular are
> mostly seen as part of a problem instead of as part of its thriving
> community. I suppose wild success has some unfortunate costs.

I would like to say that I agree with you.  I also have been around
long enough to remember days of helping new ports come to WebKit. :)

And I would argue that our current situation is all our own fault.
We've provided ports poor APIs to port with.  WebCore/platform is
nice, but as I've learned from Chromium, it's *way* too low a level to
hook into.

I believe that for WebCore/WebKit to be long-term successful, that
WebCore needs to know *nothing* about the platform that it's running
on.  That it should be completely abstracted from the outside world.
Right now we're no where close to that, and thus any major change in
WebCore requires changes and testing on all of our ports.

If WebCore had only one true-way to talk to the outside world, than I
believe we'd have a much easier time making large architectural
changes, and I believe that individual porting communities would have
a much easier time of maintaining their builds/tests.

> In any case, I don't want to end on a pessimistic note. I'm sure
> there's enough brilliance in this community to come up with better
> solutions for everyone, including future ports that do not exist yet
> but that might be very relevant in this world that moves at breakneck
> pace.
>
> Cheers,
>
> Xan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Wishes

[Eric Seidel]

On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak  wrote:
>
> Hi Eric,
>
> These are great thoughts. I agree with you on all points. One informative
> comment below:
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project.  Adam is not the only person who has chosen
> to empty files instead of removing them.  The pain of updating 8 build
> system is so great, we jump through hoops to avoid it.  Which means it took
> us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
> WebCore/platform.
>
>
> I wish I felt like reviewers understood/trusted each other more.
>
> I’ve worked at both Apple and Google.  The WebKit community is full of
> brilliant engineers.  Yet I frequently feel a lack of trust in my (or
> others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
> don’t think it’s that people don’t trust me after nearly 8 years (!?) on
> this project, but rather that we forget, or fail to communicate trust among
> ourselves.  Social problems are perhaps harder to solve for us technical
> types, but I worry that for many of us it’s just become “us” and “them” and
> we’ve stopped trying.
>
>
> I wish it were easy to work on feature branches.
>
> We have no good solution for features.  For one-patch features, you do them
> on your own.  For larger, you maybe use github or most likely you just land
> on trunk behind a #define.  None of these have worked well.  Some of this is
> the limits of SVN, but it should be trivial for someone to work on a new
> feature a long time, w/o endangering trunk or having massive merge pain
> every day.  Other projects can do this.  So should we.  This is both
> impeding progress, and destabilizing trunk.
>
>
> I wish we didn’t have to worry about platforms we couldn’t test.
>
> It can’t be the job of the core maintainers to care about all the peripheral
> ports which contribute very little core code. Our code needs to be
> structured in such a manner that its easy for the core to march forward,
> while letting the ports catch up as they need to asynchronously.  Platform
> support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
> platform abstractions should be trivial, but core developers (which probably
> 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
> worry about keeping all ports working.
>
>
> I wish that the tree always built and tested cleanly.
>
> Other (much larger) projects than WebKit accomplish this.  Yet somehow
> Google pays 2 full-time engineers to watch our bots and yet we fail.  I know
> other companies do similar.  Automated rollouts is one solution.
> Branched-based development, or trybots are others.  But at the size and
> scale we’re at now, every minute of a broken tree, is 100x or more minutes
> of potentially lost developer productivity.
>
>
> I wish I felt like I could follow what was going on (and trust WebKit to
> guard the web, instead of depending on Apple or Google).
>
> We’re the leading browser engine, with hundreds of committers, any of whom
> can add an API to 50% of internet browsers with a single commit.  I wish we
> had a public process for feature/web-api review.  I wish I felt like both
> major companies were willing participants in such.  (Google has an internal
> process, but it sees limited use, in part because it’s powerless -- a ‘yes’
> from our process is not a ‘yes’ from WebKit.)  I want to feel like I can
> better observe and participate in the development of our web-api (and trust
> that it’s being done well!) without scanning every changeset just to be able
> to comment post-facto.  (This is also reflected in the fact that the
> features enabled by the major Apple or Google ports are wildly different,
> with seemingly little rhyme or reason.)
>
>
> I wish WebCore was not trapped by Mac WebKit1’s legacy designs.
>
> WebKit2 is obviously a step towards the future.  But until we can kill the
> Widget tree, the insanely fragile loader complexity, and the limits imposed
> by the least-common-denominator on classes like ResourceRequest, we’re still
> trapped in the past. One of the things I’ve learned in working on Chromium,
> is that we were wrong many years ago to fold our platform abstraction
> (Qt-implementation) and khtml into one library.  In a sand-boxed
> multi-process world, the rendering library is just a hunk of code running
> the same on every platform.  And platform code has no place in our core
> engine code (aka WebCore).
>
>
> In designing WebKit2, we tried to avoid some mistakes in the WebKit1 Mac API
> design (such as exposing the underlying network library, exposing our NSView
> hierarchy as part of the API, and giving too much salience to frames). While
> we can't remove those parts of the API entirely, if we get more Mac API
> clients onto WebKit2, th

Re: [webkit-dev] WebKit Wishes

[Eric Seidel]

On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
> Thanks for sharing this.
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project.  Adam is not the only person who has chosen
> to empty files instead of removing them.  The pain of updating 8 build
> system is so great, we jump through hoops to avoid it.  Which means it took
> us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
> WebCore/platform.
>
>
> +1
>
> This is a hard problem.  It is a problem worth solving.
>
> Do you have more thoughts on this, particularly since you know quite well
> how both Xcode and gyp work?
>
> I suspect this is one of those things that it would be hard to achieve
> consensus on since there are so many stakeholders.  But it may be fruitful
> to have a "what if" discussion about what this might look like.

This has broken off into a separate thread.  If I were king of the
project, I would declare GYP as the one-true solution, not because I
like GYP, but because it has solved the problem for 50% of WebKit
developers, and seems reasonable for solving it for the other 50%.

I'm not king :) and thus would not wish to decree any specific
solution.  I think what really matters here is what multi-port
solution Apple believes they could use.  It's possible for Chromium to
move away from GYP.  I don't personally care too much what meta-build
system we end up using, so long as we end up with one.

I do not think that a script to add/move/remove files/folders is a
very robust solution, unfortunately.  Leaving a meta-build system as
the only obvious option in my mind.


> I wish I felt like reviewers understood/trusted each other more.
>
> I’ve worked at both Apple and Google.  The WebKit community is full of
> brilliant engineers.  Yet I frequently feel a lack of trust in my (or
> others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
> don’t think it’s that people don’t trust me after nearly 8 years (!?) on
> this project, but rather that we forget, or fail to communicate trust among
> ourselves.  Social problems are perhaps harder to solve for us technical
> types, but I worry that for many of us it’s just become “us” and “them” and
> we’ve stopped trying.
>
>
>
> I wish it were easy to work on feature branches.
>
> We have no good solution for features.  For one-patch features, you do them
> on your own.  For larger, you maybe use github or most likely you just land
> on trunk behind a #define.  None of these have worked well.  Some of this is
> the limits of SVN, but it should be trivial for someone to work on a new
> feature a long time, w/o endangering trunk or having massive merge pain
> every day.  Other projects can do this.  So should we.  This is both
> impeding progress, and destabilizing trunk.
>
>
> I've done this for JSC JIT optimization work before, and I think it worked
> quite well.  The pain of merging the branch back into trunk was bad, but the
> reward was that I had ~2 months of time where I didn't have to worry about
> breaking other people's junk.  Merging only took a week.  One week of pain
> in return for 2 months of bliss?  I'll take that.

Certainly.  I much prefer to work on branches.  Our current lack of
official branching solution (and tools) has left everyone to go their
own.  When I use GitHub for branching it feels like a very private
fork.  It's difficult for the rest of the project to know about or
follow my work.  Meaning that it's easy for me to go off into the
crazy-weeds the longer I'm out on my own branch. :)

Some of this is risks intrinsic with branching.  But imagine a world
in which every bug fix was its own branch?  Imagine a world where
branches were merged into trunk instead of committed as patches?  Some
of this is crazy-talk, I understand. :)  But I think we can do better
than our current tooling/process. :)

> I concur that we can do better on this.  I would especially love to see
> feature branching and merging follow a review process as if it were on
> trunk.  Creating a branch involves a bug and a review.  Patches that land on
> the branch are reviewed.  Merging is either reviewed or rubber stamped.

Correct!  Having branching always be off somewhere else is OK, but
lacks the connection to the rest of the project (and the review
process).

> I wish we didn’t have to worry about platforms we couldn’t test.
>
> It can’t be the job of the core maintainers to care about all the peripheral
> ports which contribute very little core code. Our code needs to be
> structured in such a manner that its easy for the core to march forward,
> while letting the ports catch up as they need to asynchronously.  Platform
> support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
> platform abstractions should be trivial, but core developers (which probably

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Benjamin Poulain]

On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  wrote:

> What I've learned from this thread, is that AppleWin and AppleMac are the
> only two ports which require lists of exported symbols.  If both were to
> convert to using EXPORT decorators instead, then we could remove needs for
> fixing export lists.
>
> Please correct me if I've misunderstood.
>

There is also iOS. The export file contains both Mac and iOS, they do not
export the same symbols.

There is unfortunately a need to have different exports for per platform;
the syntax will probably have to account for that.

Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Eric Seidel]

I should have been more clear.  By "which require lists of exported
symbols", I meant "which require lists of exported symbols for WebCore".
 The Internals discussion is obviously about WebCore symbols which are
exported through WebKit as well.  It seems no other symbols from WebCore
should ever be exported from WebKit on any port besides "Internals" symbols.

On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  wrote:

> What I've learned from this thread, is that AppleWin and AppleMac are the
> only two ports which require lists of exported symbols.  If both were to
> convert to using EXPORT decorators instead, then we could remove needs for
> fixing export lists.
>
> Please correct me if I've misunderstood.
>
> Other ports (including GTK), it seems need an internals-specific export
> macro, in order to export window.internals necessary symbols from their
> WebKit dynamic library.  I believe this is true of all ports (with the
> possible exception of Chromium).
>
>
> On Thu, Jan 31, 2013 at 5:55 PM, Martin Robinson wrote:
>
>> On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa  wrote:
>> > Doesn't GTK+ port also require symbol exports for WebKit2? In
>> particular, I
>> > thought all symbols used in Internals need to be exported there.
>>
>> WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
>> because WebCore is built as a static convenience library. We do need
>> to export symbols for the Internals library because it's built as a
>> separate object that links against libwebkitgtk. Adding an export
>> macro for Internals would be great for us, since we wouldn't have to
>> export so many symbols via Source/autotools/symbols.filter. It would
>> also decrease the maintenance burden for non-GTK+ port contributors.
>>
>> --Martin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Eric Seidel]

What I've learned from this thread, is that AppleWin and AppleMac are the
only two ports which require lists of exported symbols.  If both were to
convert to using EXPORT decorators instead, then we could remove needs for
fixing export lists.

Please correct me if I've misunderstood.

Other ports (including GTK), it seems need an internals-specific export
macro, in order to export window.internals necessary symbols from their
WebKit dynamic library.  I believe this is true of all ports (with the
possible exception of Chromium).


On Thu, Jan 31, 2013 at 5:55 PM, Martin Robinson wrote:

> On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa  wrote:
> > Doesn't GTK+ port also require symbol exports for WebKit2? In
> particular, I
> > thought all symbols used in Internals need to be exported there.
>
> WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
> because WebCore is built as a static convenience library. We do need
> to export symbols for the Internals library because it's built as a
> separate object that links against libwebkitgtk. Adding an export
> macro for Internals would be great for us, since we wouldn't have to
> export so many symbols via Source/autotools/symbols.filter. It would
> also decrease the maintenance burden for non-GTK+ port contributors.
>
> --Martin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
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)

[Eric Seidel]

+1

Ninja is beyond-words amazing.  http://martine.github.com/ninja/  For
better or worse, it is not designed to use human-editable build files,
but rather to be used by a meta build system, like GYP or CMake.  So
using ninja is really an orthogonal discussion to the "single build
system" discussion for WebKit. :)

Were the WebKit project to convert to using a single meta-build
system, ninja would become an option many users might choose.  I'm
told most Chromium hackers have GYP set to output ninja files these
days, with the exception of some folks who still want the MSVC build
environment. For WebKit ports already using CMake, they should
definitely try ninja today!


Anyway, my wish was not about arguing for a specific build solution.
I'm instead noting that for the project to continue to move quickly,
we need to stop needing to edit 8 build systems for every file
move/addition.  Whether that's GYP or CMake or something else, I don't
really care.  Adam and I tried GYP-for-WebKIt a while back.  But any
of these solutions will require buy-in from Apple, as they will have
to do the largest amount of work converting to use something other
than XCode.


On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber  wrote:
> On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth  wrote:
>> Ninja has extremely fast incremental builds and can be generated by
>> GYP.  Here are some stats from a year ago:
>>
>> https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
>>
>> Ninja has gotten even faster since then.  If you're interested in
>> trying it out, you can play around with incremental builds of the
>> Chromium port on Mac or Linux.
>
> You can also look at the build output from the chromium bots.
>
> Empty build in 1s:
> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio
> Build with a few files changed in 15s:
> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio
>
> …and this is on fairly slow bots. On my SSD-equipped laptop, I can do
> incremental rebuilds of all of chrome after touching one (cpp or mm)
> file in 2-6s.
>
>>
>> Adam
>>
>>
>> On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
>>> I think one important aspect of build systems was not considered yet int
>>> this conversation: speed. The time an incremental build takes has a great
>>> effect on developer productivity. I don't think any of the meta-build
>>> systems we use does a great job here - although I only have experiences with
>>> qmake, cmake and autotools (and I don't have an SSD that could help
>>> somewhat).
>>>
>>> The technic I found useful here is to avoid calling build-webkit always and
>>> instead just rebuild the subproject you have edited, so I think it is
>>> important to have a build system that supports it. Let me share my
>>> experiences here.
>>>
>>> With qmake nowadays this work perfectly. The developer build is producing a
>>> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
>>> which means you only need to call make in the specific subdirectory (i.e. if
>>> I only touched WebKit2 files I do "make -C
>>> WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still WebCore is
>>> so big that make is quite slowly find out the files you actually edited and
>>> need to be rebuilt. What could help here is to devide WebCore into smaller
>>> parts, like the ongoing work of extracting Platform. Maybe the next logical
>>> candidate could be svg (I don't have real knowledge about how feasible it
>>> is).
>>>
>>> Note that I don't come up with qmake because I would like to recommend it as
>>> the one and only build system (in fact it has a ridiculously inconvenient
>>> syntax, and a lot of bugs), just as an example.
>>>
>>> With Cmake fast incremental rebuilds are also possible, maybe in a bit more
>>> complicated way. When working with the EFL port I found a quick rule for
>>> WebKit2 in the generated makefile. Although the makefiles are usually call
>>> back to Cmake, and make is not faster than build-webkit, if you use the
>>> special fast target, which is something like eflWebKit/fast (i.e. make -C
>>> WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check
>>> dependencies but just rebuild the files that have changed. I did not find a
>>> similar thing for WebCore, I guess because it is not built as a shared
>>> library.
>>>
>>> What I dislike in Cmake is that I am disappointed by how slow a normal
>>> incremental build with it (i.e. build-webkit). qmake is not faster at all,
>>> but it generate plain makefiles that typically no call back to qmake if not
>>> specified explicitly to do so, and directly calling make is faster, yet it
>>> can handle most of the non-trivial changes, for example editing a generator
>>> file. I don't know gyp, so I wonder about how would it do in this comparison
>>> (but I guess it generates simple makefiles as well, so it's similar than
>>> qmake in this manner.)
>>>
>

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Darin Fisher]

On Sat, Feb 2, 2013 at 4:16 PM, James Robinson  wrote:

>
>
> On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen  wrote:
>
>> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>>
>>>
>>> It would be nice if, in the shared library build of chromium, webcore
>>> and perhaps the modules and platform were separate DLLs.
>>>
>>>
>> The shared library build is kind of a developer build, right? In this
>> case I believe you can solve this by setting the default visibility to
>> public at compiler/linker level, no need for exports.
>>
>
> That doesn't work on windows.
>
>
Right.

Yes, the shared library build of Chromium is a developer-only build mode.
 It is helpful to split the project up into separate DLLs to reduce build
times and to help enforce correct dependencies between modules.

-Darin



> - James
>
>
>>
>> -kbalazs
>>
>> __**_
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/**mailman/listinfo/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
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)

[Nico Weber]

On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth  wrote:
> Ninja has extremely fast incremental builds and can be generated by
> GYP.  Here are some stats from a year ago:
>
> https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
>
> Ninja has gotten even faster since then.  If you're interested in
> trying it out, you can play around with incremental builds of the
> Chromium port on Mac or Linux.

You can also look at the build output from the chromium bots.

Empty build in 1s:
http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio
Build with a few files changed in 15s:
http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio

…and this is on fairly slow bots. On my SSD-equipped laptop, I can do
incremental rebuilds of all of chrome after touching one (cpp or mm)
file in 2-6s.

>
> Adam
>
>
> On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
>> I think one important aspect of build systems was not considered yet int
>> this conversation: speed. The time an incremental build takes has a great
>> effect on developer productivity. I don't think any of the meta-build
>> systems we use does a great job here - although I only have experiences with
>> qmake, cmake and autotools (and I don't have an SSD that could help
>> somewhat).
>>
>> The technic I found useful here is to avoid calling build-webkit always and
>> instead just rebuild the subproject you have edited, so I think it is
>> important to have a build system that supports it. Let me share my
>> experiences here.
>>
>> With qmake nowadays this work perfectly. The developer build is producing a
>> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
>> which means you only need to call make in the specific subdirectory (i.e. if
>> I only touched WebKit2 files I do "make -C
>> WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still WebCore is
>> so big that make is quite slowly find out the files you actually edited and
>> need to be rebuilt. What could help here is to devide WebCore into smaller
>> parts, like the ongoing work of extracting Platform. Maybe the next logical
>> candidate could be svg (I don't have real knowledge about how feasible it
>> is).
>>
>> Note that I don't come up with qmake because I would like to recommend it as
>> the one and only build system (in fact it has a ridiculously inconvenient
>> syntax, and a lot of bugs), just as an example.
>>
>> With Cmake fast incremental rebuilds are also possible, maybe in a bit more
>> complicated way. When working with the EFL port I found a quick rule for
>> WebKit2 in the generated makefile. Although the makefiles are usually call
>> back to Cmake, and make is not faster than build-webkit, if you use the
>> special fast target, which is something like eflWebKit/fast (i.e. make -C
>> WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check
>> dependencies but just rebuild the files that have changed. I did not find a
>> similar thing for WebCore, I guess because it is not built as a shared
>> library.
>>
>> What I dislike in Cmake is that I am disappointed by how slow a normal
>> incremental build with it (i.e. build-webkit). qmake is not faster at all,
>> but it generate plain makefiles that typically no call back to qmake if not
>> specified explicitly to do so, and directly calling make is faster, yet it
>> can handle most of the non-trivial changes, for example editing a generator
>> file. I don't know gyp, so I wonder about how would it do in this comparison
>> (but I guess it generates simple makefiles as well, so it's similar than
>> qmake in this manner.)
>>
>> I hope I added something to this conversation that is worth to consider with
>> my late nightly brain dump.
>>
>> -kbalazs
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
>> I think one important aspect of build systems was not considered yet int
>> this conversation: speed. The time an incremental build takes has a great
>> effect on developer productivity. I don't think any of the meta-build
>> systems we use does a great job here - although I only have experiences with
>> qmake, cmake and autotools (and I don't have an SSD that could help
>> somewhat).
>>
>> The technic I found useful here is to avoid calling build-webkit always and
>> instead just rebuild the subproject you have edited, so I think it is
>> important to have a build system that supports it. Let me share my
>> experiences here.
>>
>> With qmake nowadays this work perfectly. The developer build is producing a
>> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
>> which means you only need to call make in the specific subdirectory (i.e. if
>> I only touched WebKit2 files I do "make -C
>> WebKitBuild/Release/So

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Adam Barth]

Ninja has extremely fast incremental builds and can be generated by
GYP.  Here are some stats from a year ago:

https://plus.google.com/101038813433650812235/posts/irc26fhRtPC

Ninja has gotten even faster since then.  If you're interested in
trying it out, you can play around with incremental builds of the
Chromium port on Mac or Linux.

Adam


On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
> I think one important aspect of build systems was not considered yet int
> this conversation: speed. The time an incremental build takes has a great
> effect on developer productivity. I don't think any of the meta-build
> systems we use does a great job here - although I only have experiences with
> qmake, cmake and autotools (and I don't have an SSD that could help
> somewhat).
>
> The technic I found useful here is to avoid calling build-webkit always and
> instead just rebuild the subproject you have edited, so I think it is
> important to have a build system that supports it. Let me share my
> experiences here.
>
> With qmake nowadays this work perfectly. The developer build is producing a
> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
> which means you only need to call make in the specific subdirectory (i.e. if
> I only touched WebKit2 files I do "make -C
> WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still WebCore is
> so big that make is quite slowly find out the files you actually edited and
> need to be rebuilt. What could help here is to devide WebCore into smaller
> parts, like the ongoing work of extracting Platform. Maybe the next logical
> candidate could be svg (I don't have real knowledge about how feasible it
> is).
>
> Note that I don't come up with qmake because I would like to recommend it as
> the one and only build system (in fact it has a ridiculously inconvenient
> syntax, and a lot of bugs), just as an example.
>
> With Cmake fast incremental rebuilds are also possible, maybe in a bit more
> complicated way. When working with the EFL port I found a quick rule for
> WebKit2 in the generated makefile. Although the makefiles are usually call
> back to Cmake, and make is not faster than build-webkit, if you use the
> special fast target, which is something like eflWebKit/fast (i.e. make -C
> WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check
> dependencies but just rebuild the files that have changed. I did not find a
> similar thing for WebCore, I guess because it is not built as a shared
> library.
>
> What I dislike in Cmake is that I am disappointed by how slow a normal
> incremental build with it (i.e. build-webkit). qmake is not faster at all,
> but it generate plain makefiles that typically no call back to qmake if not
> specified explicitly to do so, and directly calling make is faster, yet it
> can handle most of the non-trivial changes, for example editing a generator
> file. I don't know gyp, so I wonder about how would it do in this comparison
> (but I guess it generates simple makefiles as well, so it's similar than
> qmake in this manner.)
>
> I hope I added something to this conversation that is worth to consider with
> my late nightly brain dump.
>
> -kbalazs
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
> I think one important aspect of build systems was not considered yet int
> this conversation: speed. The time an incremental build takes has a great
> effect on developer productivity. I don't think any of the meta-build
> systems we use does a great job here - although I only have experiences with
> qmake, cmake and autotools (and I don't have an SSD that could help
> somewhat).
>
> The technic I found useful here is to avoid calling build-webkit always and
> instead just rebuild the subproject you have edited, so I think it is
> important to have a build system that supports it. Let me share my
> experiences here.
>
> With qmake nowadays this work perfectly. The developer build is producing a
> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
> which means you only need to call make in the specific subdirectory (i.e. if
> I only touched WebKit2 files I do "make -C
> WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still WebCore is
> so big that make is quite slowly find out the files you actually edited and
> need to be rebuilt. What could help here is to devide WebCore into smaller
> parts, like the ongoing work of extracting Platform. Maybe the next logical
> candidate could be svg (I don't have real knowledge about how feasible it
> is).
>
> Note that I don't come up with qmake because I would like to recommend it as
> the one and only build system (in fact it has a ridiculously inconvenient
> syntax, and a lot of bugs), just as an example.
>
> With Cmake fast incremental rebuilds are also possibl

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[James Robinson]

On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen  wrote:

> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>
>>
>> It would be nice if, in the shared library build of chromium, webcore and
>> perhaps the modules and platform were separate DLLs.
>>
>>
> The shared library build is kind of a developer build, right? In this case
> I believe you can solve this by setting the default visibility to public at
> compiler/linker level, no need for exports.
>

That doesn't work on windows.

- James


>
> -kbalazs
>
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Balazs Kelemen]

On 02/01/2013 02:28 AM, Darin Fisher wrote:


It would be nice if, in the shared library build of chromium, webcore 
and perhaps the modules and platform were separate DLLs.




The shared library build is kind of a developer build, right? In this 
case I believe you can solve this by setting the default visibility to 
public at compiler/linker level, no need for exports.


-kbalazs
___
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)

[Balazs Kelemen]

I think one important aspect of build systems was not considered yet int 
this conversation: speed. The time an incremental build takes has a 
great effect on developer productivity. I don't think any of the 
meta-build systems we use does a great job here - although I only have 
experiences with qmake, cmake and autotools (and I don't have an SSD 
that could help somewhat).


The technic I found useful here is to avoid calling build-webkit always 
and instead just rebuild the subproject you have edited, so I think it 
is important to have a build system that supports it. Let me share my 
experiences here.


With qmake nowadays this work perfectly. The developer build is 
producing a shared library for every subdir (WTF, JavaScriptCore, 
WebCore, WebKit2), which means you only need to call make in the 
specific subdirectory (i.e. if I only touched WebKit2 files I do "make 
-C WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still 
WebCore is so big that make is quite slowly find out the files you 
actually edited and need to be rebuilt. What could help here is to 
devide WebCore into smaller parts, like the ongoing work of extracting 
Platform. Maybe the next logical candidate could be svg (I don't have 
real knowledge about how feasible it is).


Note that I don't come up with qmake because I would like to recommend 
it as the one and only build system (in fact it has a ridiculously 
inconvenient syntax, and a lot of bugs), just as an example.


With Cmake fast incremental rebuilds are also possible, maybe in a bit 
more complicated way. When working with the EFL port I found a quick 
rule for WebKit2 in the generated makefile. Although the makefiles are 
usually call back to Cmake, and make is not faster than build-webkit, if 
you use the special fast target, which is something like eflWebKit/fast 
(i.e. make -C WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it 
will not check dependencies but just rebuild the files that have 
changed. I did not find a similar thing for WebCore, I guess because it 
is not built as a shared library.


What I dislike in Cmake is that I am disappointed by how slow a normal 
incremental build with it (i.e. build-webkit). qmake is not faster at 
all, but it generate plain makefiles that typically no call back to 
qmake if not specified explicitly to do so, and directly calling make is 
faster, yet it can handle most of the non-trivial changes, for example 
editing a generator file. I don't know gyp, so I wonder about how would 
it do in this comparison (but I guess it generates simple makefiles as 
well, so it's similar than qmake in this manner.)


I hope I added something to this conversation that is worth to consider 
with my late nightly brain dump.


-kbalazs

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code

[Sam Weinig]

Sounds good to me as well.

-Sam

On Jan 30, 2013, at 3:54 PM, Nico Weber  wrote:

> Hi,
> 
> I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
> nobody ever shipped this and nobody intents to. Please speak up if
> you'd like that code to stick around.
> 
> Nico
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev