[webkit-dev] SFX instructions emission slow cases

[wingoog moon]

Hi!
As I understand there are two passes to translate SFX bytecode to the
native code(functions privateCompileMainPass() and
  privateCompileSlowCases()).
So whats the purpose of privateCompileSlowCases(). Why we need
slow cases for each bytecodeInstruction? Is it needed when arguments of
instruction not integer or something else?

Thanks for attention!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SFX instructions emission slow cases

[Filip Pizlo]

JavaScript is a dynamically typed language. Therefore, we cannot know for sure 
what types of values may flow into an instruction at the time we compile it. a 
+ b may be an integer addition that produces an integer result, an integer 
addition that overflows and produces a double, an addition of a double to an 
integer, an addition of an integer to a double, a double addition, a string 
concatenation, or an "object-to-value" conversion followed by any of the 
previous.

But the common case is typically going to be an integer addition or a double 
addition.

Therefore, the baseline JIT (which you seem to be looking at) has a fast path 
for the common cases and a slow path for the uncommon ones.  The slow path 
almost always results in a C function call, which then does all of the magic 
necessary to satisfy JS semantics.

Similar things happen for almost all other JS instructions: there is a simple 
path for the cases we have found to be common and a slow-path C function call 
for the rare cases.

The slow paths are emitted as a separate piece of out-of-line code because that 
optimizes instruction cache locality for the main path, and helps a bit with 
branch prediction.

However, if you want to see how JSC actually makes JavaScript run fast, you 
should probably also look at either the LLInt (which enables very fast start-up 
by using a well-tuned threaded OSR-capable interpreter) or the DFG (which 
enables high throughput for longer-running code by leveraging value profiling 
to avoid having to deal with JS's dynamism in most cases). The baseline JIT is 
still probably important for performance, but this is becoming less and less 
true as the LLInt is likely to get faster and the DFG is likely to expand 
coverage to more kinds of code (DFG still cannot compile some functions at all 
due to missing opcode support).

-F



On Apr 18, 2012, at 1:39 AM, wingoog moon wrote:

> Hi!
> As I understand there are two passes to translate SFX bytecode to the native 
> code(functions privateCompileMainPass() and   privateCompileSlowCases()).
> So whats the purpose of privateCompileSlowCases(). Why we need slow cases for 
> each bytecodeInstruction? Is it needed when arguments of instruction not 
> integer or something else?
> 
> Thanks for attention! 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] github mirror

[Shezan Baig]

Hi WebKit,

I've been using a fork of the following repo:
https://github.com/WebKit/webkit

However, yesterday there was discussion on #webkit that the SHA-1 checksums
on this repo are different from repo at git.webkit.org, which means folks
working on both need to have both versions checked out.

I believe the answer to this problem is in:
http://help.github.com/move-a-repo/

(look at the last section titled "Manual clone and push")

Anyone in the "WebKit" organization on https://github.com/WebKit should be
able to push this.  Once this is pushed, we can retire the existing repo on
github.  This means the existing forks will be unusable, but I think it
will be good to do this earlier rather than later, so we just have "one"
repo, and this will make it easier for existing git.webkit.org users to
switch to github.

Thanks,
-shez-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SFX instructions emission slow cases

[wingoog moon]

Thanks for anwers.
Can you please tell more about  LLInt and is it turned on by default?
On Wed, Apr 18, 2012 at 12:48 PM, Filip Pizlo  wrote:

> JavaScript is a dynamically typed language. Therefore, we cannot know for
> sure what types of values may flow into an instruction at the time we
> compile it. a + b may be an integer addition that produces an integer
> result, an integer addition that overflows and produces a double, an
> addition of a double to an integer, an addition of an integer to a double,
> a double addition, a string concatenation, or an "object-to-value"
> conversion followed by any of the previous.
>
> But the common case is typically going to be an integer addition or a
> double addition.
>
> Therefore, the baseline JIT (which you seem to be looking at) has a fast
> path for the common cases and a slow path for the uncommon ones.  The slow
> path almost always results in a C function call, which then does all of the
> magic necessary to satisfy JS semantics.
>
> Similar things happen for almost all other JS instructions: there is a
> simple path for the cases we have found to be common and a slow-path C
> function call for the rare cases.
>
> The slow paths are emitted as a separate piece of out-of-line code because
> that optimizes instruction cache locality for the main path, and helps a
> bit with branch prediction.
>
> However, if you want to see how JSC actually makes JavaScript run fast,
> you should probably also look at either the LLInt (which enables very fast
> start-up by using a well-tuned threaded OSR-capable interpreter) or the DFG
> (which enables high throughput for longer-running code by leveraging value
> profiling to avoid having to deal with JS's dynamism in most cases). The
> baseline JIT is still probably important for performance, but this is
> becoming less and less true as the LLInt is likely to get faster and the
> DFG is likely to expand coverage to more kinds of code (DFG still cannot
> compile some functions at all due to missing opcode support).
>
> -F
>
>
>
> On Apr 18, 2012, at 1:39 AM, wingoog moon wrote:
>
> Hi!
> As I understand there are two passes to translate SFX bytecode to the
> native code(functions privateCompileMainPass() and
>   privateCompileSlowCases()).
> So whats the purpose of privateCompileSlowCases(). Why we need
> slow cases for each bytecodeInstruction? Is it needed when arguments of
> instruction not integer or something else?
>
> Thanks for attention!
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] SFX API.

[wingoog moon]

Hi.
Does SFX API cover all bytecode instructions.
i.e. can I implement all SFX bytecode Instructions trough SFX API?

Thanks.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] github mirror

[Jarred Nicholls]

Wouldn't we need to continually mirror git.webkit.org to github as well?  I
presume github is mirroring directly from svn right now.  I'd think the
out-of-sync issue would simply occur again unless we started to mirror git.
webkit.org to github instead of svn to github.

I don't know what all Git takes into account when creating the sha1 outside
of content, tree and commit meta data, so I'm unsure if doing this git.
webkit.org => github forced push would mean that future svn commits - being
mirrored to both repos in parallel - would result in identical sha1 hashes
going forward...?

Jarred

On Wed, Apr 18, 2012 at 6:53 AM, Shezan Baig  wrote:

> Hi WebKit,
>
> I've been using a fork of the following repo:
> https://github.com/WebKit/webkit
>
> However, yesterday there was discussion on #webkit that the SHA-1
> checksums on this repo are different from repo at git.webkit.org, which
> means folks working on both need to have both versions checked out.
>
> I believe the answer to this problem is in:
> http://help.github.com/move-a-repo/
>
> (look at the last section titled "Manual clone and push")
>
> Anyone in the "WebKit" organization on https://github.com/WebKit should
> be able to push this.  Once this is pushed, we can retire the existing repo
> on github.  This means the existing forks will be unusable, but I think it
> will be good to do this earlier rather than later, so we just have "one"
> repo, and this will make it easier for existing git.webkit.org users to
> switch to github.
>
> Thanks,
> -shez-
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] github mirror

[Shezan Baig]

(resending to all)

Yes, I think it would be better to mirror git.webkit.org to github instead
of mirroring from svn to github.
In theory, it really shouldn't make a difference though, so i'm actually
surprised that the sha1 are out of sync.
But mirroring from git.webkit.org will guarantee they are the same,
regardless of any wierdness that git-svn might do.


On Wed, Apr 18, 2012 at 10:00 AM, Jarred Nicholls  wrote:

> Wouldn't we need to continually mirror git.webkit.org to github as well?
>  I presume github is mirroring directly from svn right now.  I'd think the
> out-of-sync issue would simply occur again unless we started to mirror
> git.webkit.org to github instead of svn to github.
>
> I don't know what all Git takes into account when creating the sha1
> outside of content, tree and commit meta data, so I'm unsure if doing this
> git.webkit.org => github forced push would mean that future svn commits -
> being mirrored to both repos in parallel - would result in identical sha1
> hashes going forward...?
>
> Jarred
>
> On Wed, Apr 18, 2012 at 6:53 AM, Shezan Baig wrote:
>
>> Hi WebKit,
>>
>> I've been using a fork of the following repo:
>> https://github.com/WebKit/webkit
>>
>> However, yesterday there was discussion on #webkit that the SHA-1
>> checksums on this repo are different from repo at git.webkit.org, which
>> means folks working on both need to have both versions checked out.
>>
>> I believe the answer to this problem is in:
>> http://help.github.com/move-a-repo/
>>
>> (look at the last section titled "Manual clone and push")
>>
>> Anyone in the "WebKit" organization on https://github.com/WebKit should
>> be able to push this.  Once this is pushed, we can retire the existing repo
>> on github.  This means the existing forks will be unusable, but I think it
>> will be good to do this earlier rather than later, so we just have "one"
>> repo, and this will make it easier for existing git.webkit.org users to
>> switch to github.
>>
>> Thanks,
>> -shez-
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] github mirror

[Simon Hausmann]

On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
> Hi WebKit,
> 
> I've been using a fork of the following repo:
> https://github.com/WebKit/webkit
> 
> However, yesterday there was discussion on #webkit that the SHA-1 checksums
> on this repo are different from repo at git.webkit.org, which means folks
> working on both need to have both versions checked out.

I believe the reason for them being different is because in the github repo the 
commit author fields are resolved.


Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] github mirror

[Shezan Baig]

On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann
wrote:
>
> I believe the reason for them being different is because in the github
> repo the
> commit author fields are resolved.
>
>


That would certainly explain it :)  I don't have a git.webkit.org checkout,
so I couldn't tell
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] github mirror

[Jarred Nicholls]

(from correct address)

On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls  wrote:

> On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann  > wrote:
>
>> On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
>> > Hi WebKit,
>> >
>> > I've been using a fork of the following repo:
>> > https://github.com/WebKit/webkit
>> >
>> > However, yesterday there was discussion on #webkit that the SHA-1
>> checksums
>> > on this repo are different from repo at git.webkit.org, which means
>> folks
>> > working on both need to have both versions checked out.
>>
>> I believe the reason for them being different is because in the github
>> repo the
>> commit author fields are resolved.
>>
>
> Yeah that's totally it.  So svn.webkit.org => git.webkit.org => github
> would need to be the mirroring strategy.  Sounds dicey :)
>
>
>>
>>
>> Simon
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
> --
> 
>
> *Sencha*
> Jarred Nicholls, Senior Software Architect
> @jarrednicholls
> 
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SFX instructions emission slow cases

[Oliver Hunt]

LLInt is on if the target platform is a supported architecture (currently only 
x86, x86-64, and ARM w/Thumb2 I believe) on a platform with an ABI we 
understand (which I believe is normal unix-derivative cdecl)

--Oliver

On Apr 18, 2012, at 4:35 AM, wingoog moon wrote:

> 
> Thanks for anwers.
> Can you please tell more about  LLInt and is it turned on by default?
> On Wed, Apr 18, 2012 at 12:48 PM, Filip Pizlo  wrote:
> JavaScript is a dynamically typed language. Therefore, we cannot know for 
> sure what types of values may flow into an instruction at the time we compile 
> it. a + b may be an integer addition that produces an integer result, an 
> integer addition that overflows and produces a double, an addition of a 
> double to an integer, an addition of an integer to a double, a double 
> addition, a string concatenation, or an "object-to-value" conversion followed 
> by any of the previous.
> 
> But the common case is typically going to be an integer addition or a double 
> addition.
> 
> Therefore, the baseline JIT (which you seem to be looking at) has a fast path 
> for the common cases and a slow path for the uncommon ones.  The slow path 
> almost always results in a C function call, which then does all of the magic 
> necessary to satisfy JS semantics.
> 
> Similar things happen for almost all other JS instructions: there is a simple 
> path for the cases we have found to be common and a slow-path C function call 
> for the rare cases.
> 
> The slow paths are emitted as a separate piece of out-of-line code because 
> that optimizes instruction cache locality for the main path, and helps a bit 
> with branch prediction.
> 
> However, if you want to see how JSC actually makes JavaScript run fast, you 
> should probably also look at either the LLInt (which enables very fast 
> start-up by using a well-tuned threaded OSR-capable interpreter) or the DFG 
> (which enables high throughput for longer-running code by leveraging value 
> profiling to avoid having to deal with JS's dynamism in most cases). The 
> baseline JIT is still probably important for performance, but this is 
> becoming less and less true as the LLInt is likely to get faster and the DFG 
> is likely to expand coverage to more kinds of code (DFG still cannot compile 
> some functions at all due to missing opcode support).
> 
> -F
> 
> 
> 
> On Apr 18, 2012, at 1:39 AM, wingoog moon wrote:
> 
>> Hi!
>> As I understand there are two passes to translate SFX bytecode to the native 
>> code(functions privateCompileMainPass() and   privateCompileSlowCases()).
>> So whats the purpose of privateCompileSlowCases(). Why we need slow cases 
>> for each bytecodeInstruction? Is it needed when arguments of instruction not 
>> integer or something else?
>> 
>> Thanks for attention! 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] run-webkit-tests --pixel-tests and text-based tests

[Milian Wolff]

Hey all,

I'm working on isPrinting() support for the Qt port and noticed that if I do 
something like this:

./Tools/Scripts/run-webkit-tests -p LayoutTests/printing/

Then I get lots of "failures" due to missing image baselines for tests like 
printing/page-rule-css-text-expected.html.

Thing is: Tests like the above are not pixel-based. So how do other test 
suites detect this?

I've mainly looked at chromium's TestShell and could not find anything obvious 
that detects this (the url does not contain /dumpAstText/ nor is the returned 
mimetype text/plain)...

Even when I add --skip-pixel-test-if-nseline to the invocation above, the 
images are still created.

How is this supposed to be handled? How do other ports handle this?

Thanks
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] run-webkit-tests --pixel-tests and text-based tests

[Dirk Pranke]

On Wed, Apr 18, 2012 at 10:40 AM, Milian Wolff  wrote:
> Hey all,
>
> I'm working on isPrinting() support for the Qt port and noticed that if I do
> something like this:
>
> ./Tools/Scripts/run-webkit-tests -p LayoutTests/printing/
>
> Then I get lots of "failures" due to missing image baselines for tests like
> printing/page-rule-css-text-expected.html.
>
> Thing is: Tests like the above are not pixel-based. So how do other test
> suites detect this?
>

You should only get complaints about missing image baselines if DRT
thinks that the test should generate a PNG. The way DRT detects that
is if --pixel-tests is passed on the command line and
layoutTestController.dumpAsText() is *not* called (i.e., PNGs are the
default).

Assuming there's a typo in your email, and you meant to refer to
printing/page-rule-css-text.html (not -expected.html, which is the
convention we use for reference tests), that test is supposed to be a
text-only test.

*However*, it's possible that there's a bug occuring when you run the
test such that dumpAsText() is not actually getting invoked. In that
case, you'll get the MISSING baselines warning.

There is not a good way to fix this (i.e., to not get these false
warnings) that I'm aware of.

I hope that's helpful,

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature announcement: Font Boosting

[Kenneth Rohde Christiansen]

I think it would be great to talk about this at the WebKit summit tomorrow,
if you are there.

Cheers
Kenneth

On Tue, Apr 17, 2012 at 10:17 PM, John Mellor  wrote:

> Hi webkit-dev,
>
> You may have heard  that Chrome for
> Android includes a "Font Boosting" feature. This is similar in intent to
> the text size 
> adjustfeature
>  in Mobile Safari, that the QT port also seems
> interested in . Other mobile browsers have
> corresponding features: Mobile Firefox uses font 
> inflationand IE Mobile applies 
> text
> size 
> adjustment
> .
>
> Font Boosting increases the font size in wide blocks, so that you can
> easily read the text after double-tapping to fit the block to the screen,
> instead of having to zoom in further then scroll from side to side for each
> line you read.
>
> The details are subtle (since web text layout is complicated), and there's
> still a lot of tweaking to do. We chose to boost font sizes more than
> Mobile Safari (which has various limits), producing easily legible text,
> more in line with IE Mobile and Firefox Mobile.
>
> This is core functionality for mobile browsers, so we would like to
> upstream our implementation of Font Boosting to WebCore. We are keen to
> share code with other ports (e.g. QT and Mobile Safari) that are interested
> in this feature, and will be happy to incorporate suggestions on how to
> make this easier.
>
> I've opened webkit.org/b/84186 to track this effort.
>
> Best wishes,
> John
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit. org

http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake for Apple's Windows port

[Patrick Gansterer]

Am 12.04.2012 um 20:06 schrieb Dirk Pranke:
> Patrick, have you documented what all you need to install on a Win box
> in order to be able to run CMake and do the build?

You need to install CMake and the same tools listed at 
http://trac.webkit.org/wiki/WinCE#Build and 
http://www.webkit.org/building/tools.html (but without cygwin).


Am 12.04.2012 um 23:47 schrieb Mark Rowe:
> On 2012-04-12, at 14:28, Dirk Pranke  wrote:
>> Interesting.  Can you comment further on why this is needed, instead of just 
>> checking out the whole repo?
>> 
> 
> The short answer is that doing so would violate internal policies that we 
> have about what sorts of files are acceptable in the source of production 
> builds (for example, precompiled libraries are not acceptable). We also don't 
> have any desire to shuffle multiple gigabytes of layout tests around machines 
> that are only used for building.

Is it possible to get a (detailed) list of requirements? It's hard for people 
don't knowing the internal Apple build process to work on it.

Why isn't it possible to checkout only the Source directory?
Since the current system has more than 1 VS solution too, I don't think it will 
be a problem to have more than one "root CMakeLists.txt" too.

Is there a interest in getting rid of the Visual Studio files? Are there any 
points agains CMake we know already? I don't want to put (much) work into the 
CMake files for a simple "No, thanks" at the end. ;-)

-- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake for Apple's Windows port

[Mark Rowe]

On 2012-04-18, at 18:43, Patrick Gansterer  wrote:

> 
> Am 12.04.2012 um 20:06 schrieb Dirk Pranke:
>> Patrick, have you documented what all you need to install on a Win box
>> in order to be able to run CMake and do the build?
> 
> You need to install CMake and the same tools listed at 
> http://trac.webkit.org/wiki/WinCE#Build and 
> http://www.webkit.org/building/tools.html (but without cygwin).
> 
> 
> Am 12.04.2012 um 23:47 schrieb Mark Rowe:
>> On 2012-04-12, at 14:28, Dirk Pranke  wrote:
>>> Interesting.  Can you comment further on why this is needed, instead of 
>>> just checking out the whole repo?
>>> 
>> 
>> The short answer is that doing so would violate internal policies that we 
>> have about what sorts of files are acceptable in the source of production 
>> builds (for example, precompiled libraries are not acceptable). We also 
>> don't have any desire to shuffle multiple gigabytes of layout tests around 
>> machines that are only used for building.
> 
> Is it possible to get a (detailed) list of requirements? It's hard for people 
> don't knowing the internal Apple build process to work on it.

We don't have anything of this nature available for external consumption at 
this time.

> Why isn't it possible to checkout only the Source directory?
> Since the current system has more than 1 VS solution too, I don't think it 
> will be a problem to have more than one "root CMakeLists.txt" too.

That's the direction we're heading in for the Mac build system. If this can be 
made to work with CMake then that's wonderful.

> Is there a interest in getting rid of the Visual Studio files? Are there any 
> points agains CMake we know already? I don't want to put (much) work into the 
> CMake files for a simple "No, thanks" at the end. ;-)

I'll let someone else speak to these points.

- Mark


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

Re: [webkit-dev] CMake for Apple's Windows port

[Patrick Gansterer]

Am 19.04.2012 um 03:46 schrieb Mark Rowe:
>> 
>> Is it possible to get a (detailed) list of requirements? It's hard for 
>> people don't knowing the internal Apple build process to work on it.
> 
> We don't have anything of this nature available for external consumption at 
> this time.

Does that mean that only Apple folk can work on it at the moment?
Is it possible that someone at Apple have a deeper look into the current state 
to provide more information about the missing/bad/good parts?
I'd like to put more work into it, but I need feedback from the people who use 
it.

>> Why isn't it possible to checkout only the Source directory?
>> Since the current system has more than 1 VS solution too, I don't think it 
>> will be a problem to have more than one "root CMakeLists.txt" too.
> 
> That's the direction we're heading in for the Mac build system. If this can 
> be made to work with CMake then that's wonderful.

It's not the most elegant way, since root usually means root, but if it's a 
strong requirement it should be possible.

-- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake for Apple's Windows port

[Thomas Fletcher]

I will say Thank You ... we use cmake as the base for nearly every new
WebKit port we engage in.

We have a native Windows build that is cmake to replace the Apple/CF based
one and it is so much
easier to maintain than the previous collection of VS property pages and
build configurations.  Not
only that but we can quickly generate multiple build variants (CF vs GDI for
example) very quickly
and also share project content in ways that make sense (such as with WinCE).

We can count at least 6 ports we have done using cmake.  We have rolled our
own a couple of times
on early ports, but on the last few with the 'in tree' initial base from
WinCE and EFL we're now using
that as a basis.

So Patrick (and whomever else kicks in keeping the cmake builds running) ...
THANK YOU.

Thomas
-
Crank Software Inc.
Office: 613-595-1999 x511
Mobile: 613-878-4659
Online: www.cranksoftware.com 
Check out: Crank Software¹s Blog 
 
There is a better way to build user interfaces for embedded devices.
Download a 30 day evaluation
  of Crank Storyboard Suite
today

From:  Patrick Gansterer 
Date:  Thu, 19 Apr 2012 03:43:28 +0200
To:  Mark Rowe 
Cc:  Dirk Pranke , WebKit Development

Subject:  Re: [webkit-dev] CMake for Apple's Windows port


Am 12.04.2012 um 20:06 schrieb Dirk Pranke:
> Patrick, have you documented what all you need to install on a Win box
> in order to be able to run CMake and do the build?

You need to install CMake and the same tools listed at
http://trac.webkit.org/wiki/WinCE#Build and
http://www.webkit.org/building/tools.html (but without cygwin).


Am 12.04.2012 um 23:47 schrieb Mark Rowe:
> On 2012-04-12, at 14:28, Dirk Pranke  wrote:
>> Interesting.  Can you comment further on why this is needed, instead of just
>> checking out the whole repo?
> 
> The short answer is that doing so would violate internal policies that we have
> about what sorts of files are acceptable in the source of production builds
> (for example, precompiled libraries are not acceptable). We also don't have
> any desire to shuffle multiple gigabytes of layout tests around machines that
> are only used for building.

Is it possible to get a (detailed) list of requirements? It's hard for
people don't knowing the internal Apple build process to work on it.

Why isn't it possible to checkout only the Source directory?
Since the current system has more than 1 VS solution too, I don't think it
will be a problem to have more than one "root CMakeLists.txt" too.

Is there a interest in getting rid of the Visual Studio files? Are there any
points agains CMake we know already? I don't want to put (much) work into
the CMake files for a simple "No, thanks" at the end. ;-)

-- Patrick
___ webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] Where to call Codeblock::dump from within webcore

[pgsery]

I want to call CodeBlock::dump from webcore in addition to the jsc 
shell. I've compiled webkit-1.6.1 with the --enable-debug option, 
modified dump to print to a file, instead of stdout, and set 
options.dump=true. This works from the shell, but now I need to find 
where to call dump from within webkit.


Ultimately, I want to use use webkitgtk to dump javascript information 
from html.


Thanks,
Paul

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