[haiku-commits] Re: haiku: hrev44595 - build/jam

  • From: Alexandre Deckner <alex@xxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 02 Sep 2012 22:46:56 +0200

Le 01/09/12 16:25, Rene Gollent a écrit :
I really need to get a WebKit build environment going. If you have any
tips or tricks with the latest source let me know. What kind of Haiku
do you use for that? Just the usual gcc2/4 hybrid?

Doesn't matter so long as you have gcc4 available, just grab the
github repo (https://github.com/aldeck/haiku-webkit , branch
lastgood).

Yep, the readme is up to date, well sort of, i just need to remove references to building WebPositive since it's now in the Haiku tree.

Also it would be helpful if you or aldeck can describe the general
workflow for updating against origin webkit.

Well, the git merge goes smoothly in general. Then you need to add/remove new/old sources files from the Jamfile. And of course adopt new refactorings etc... Be carefull, recent revs might bring fixes but also lots of issues, for example if they deprecated old platform "api"s and need new graphic ops we don't necessarily support natively. I've been bitten by that during my contract, and with such a long build time / big repo you can waste a lot of time, even with git and a brand new i7.

This is in fact a vast subject, and a process that we need to formalize somehow. I've had to think a lot about it by the force of things, but i haven't found a complete solution yet. We can of course take a random revision and be lucky (that's what i did initially) as there's no such thing as a stable revision in webkit. I found out that there are test bots that can tell you that some rev passes all tests, that helps a bit (but those are not haiku tests). I've been looking at how the other projects do. The other ports (i.e browsers) maintain their own release branches, branching at some revision then picking fixes from upstream and a few of their own. For example, stable chromium or safari are based on relatively old webkit revisions, with hundreds of fixes from upstream (be careful they work in svn branches, revision numbers are interleaved with the trunk revs, and they don't have git clones). Anyway, i think we should adopt a similar strategy, with our specificities, and formalize it because will never have a stable browser otherwise. For the time being i'd be careful merging too recent revs, just cherry pick a fix for your problem, i'd personally be very happy even with a 2 years old webkit browser, with all features supported!

More could be said, but i'm short on time unfortunately and i'd best use my time on coding. I just fixed rounded rectangles by the way. I hope it's not too late for A4 (not sure about the dates).

Regards,
Alex


Other related posts: