WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
133102
Add option to run-jsc-stress-tests to use installed jsc
https://bugs.webkit.org/show_bug.cgi?id=133102
Summary
Add option to run-jsc-stress-tests to use installed jsc
Michael Saboff
Reported
2014-05-19 18:22:06 PDT
Typically run-jsc-stress-tests is used to test jsc and a JavaScriptCore built the user. We should have an option to use a system installed jsc.
Attachments
Patch
(3.81 KB, patch)
2014-05-19 18:25 PDT
,
Michael Saboff
no flags
Details
Formatted Diff
Diff
Updated patch with agreed upon changes
(4.65 KB, patch)
2014-05-22 13:20 PDT
,
Michael Saboff
ggaren
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Michael Saboff
Comment 1
2014-05-19 18:25:51 PDT
Created
attachment 231745
[details]
Patch
Geoffrey Garen
Comment 2
2014-05-19 19:01:09 PDT
Comment on
attachment 231745
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=231745&action=review
> Tools/Scripts/run-jsc-stress-tests:111 > + puts "--jsc (-j) Path to JavaScriptCore." > + puts "--system-jsc Use jsc installed on the system."
Why is this better than "--jsc /usr/local/bin/jsc"? It seems like you've conflated two things behind this option: (1) a built-in --jsc; (2) a --no-copy option for --remote.
Michael Saboff
Comment 3
2014-05-19 21:04:41 PDT
(In reply to
comment #2
)
> (From update of
attachment 231745
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=231745&action=review
> > > Tools/Scripts/run-jsc-stress-tests:111 > > + puts "--jsc (-j) Path to JavaScriptCore." > > + puts "--system-jsc Use jsc installed on the system." > > Why is this better than "--jsc /usr/local/bin/jsc"? It seems like you've conflated two things behind this option: (1) a built-in --jsc; (2) a --no-copy option for --remote.
There are three reasons for the two different options, 1) I don't want figure out that the path provided is for the system jsc in order to not package up and send it (and it's framework). 2) the path for jsc might be different or not existent on the local device compared to the remote device when --remote is used. 3) I could see where we might want to specify both "use the system jsc (--system-jsc)" and "here is it's path (--jsc)", since the script may not know where the system jsc happens to be. I think it is reasonable to change --system-jsc to --no-copy-jsc and require that that --jsc always needs to be given. What I posted eliminates the need for two options and assumes /usr/local/bin/jsc. That suites the needs we currently have.
Geoffrey Garen
Comment 4
2014-05-21 15:51:49 PDT
Comment on
attachment 231745
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=231745&action=review
> Tools/Scripts/run-jsc-stress-tests:128 > + ['--system-jsc', GetoptLong::NO_ARGUMENT],
Let's call this --no-copy, and have it modify the meaning of --jsc to be the final location where the framework already exists.
> Tools/Scripts/run-jsc-stress-tests:145 > + when '--system-jsc' > + $jscPath = "/usr/local/bin/jsc"
Let's use the jsc inside the framework, even in the system case. That removes a special case.
> Tools/Scripts/run-jsc-stress-tests:433 > + if !$systemJsc > + script += "export DYLD_FRAMEWORK_PATH=$(cd ../#{$frameworkPath.dirname}; pwd)\n"
I think we can remove this special case by using the jsc inside the framework.
Michael Saboff
Comment 5
2014-05-21 16:48:08 PDT
Comment on
attachment 231745
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=231745&action=review
>> Tools/Scripts/run-jsc-stress-tests:433 >> + script += "export DYLD_FRAMEWORK_PATH=$(cd ../#{$frameworkPath.dirname}; pwd)\n" > > I think we can remove this special case by using the jsc inside the framework.
We'll still need some special case, since the existing code is assuming a relative path and with the "--no-copy" option we'll now have an absolute path. That special case could be moved to the generation of frameworkPath and then eliminate the "../" everywhere it is used.
Michael Saboff
Comment 6
2014-05-22 13:20:20 PDT
Created
attachment 231905
[details]
Updated patch with agreed upon changes
Geoffrey Garen
Comment 7
2014-05-22 13:41:14 PDT
Comment on
attachment 231905
[details]
Updated patch with agreed upon changes View in context:
https://bugs.webkit.org/attachment.cgi?id=231905&action=review
r=me
> Tools/Scripts/run-jsc-stress-tests:110 > puts "--jsc (-j) Path to JavaScriptCore. This option is required."
Let's be clearer here: "Path to JavaScriptCore build product."
> Tools/Scripts/run-jsc-stress-tests:111 > + puts "--no-copy Use the existing JavaScriptCore specified by the --jsc option."
Let's be clearer here: "Do not copy the JavaScriptCore build product before testing. --jsc specifies an already present JavaScriptCore to test."
> Tools/Scripts/run-jsc-stress-tests:125 > +jscPathArg = ""
I'd call this "jscArg", since the argument is named "jsc" and not "jscPath".
> Tools/Scripts/run-jsc-stress-tests:178 > + $jscPath = Pathname.new(jscPathArg).realpath > + else > + $jscPath = Pathname.new(jscPathArg)
Why do these disagree about realpath?
> Tools/Scripts/run-jsc-stress-tests:1040 > + if !$remote > + $testingFrameworkPath = frameworkFromJSCPath($jscPath).realpath > + $jscPath = Pathname.new($jscPath).realpath > + else > + $testingFrameworkPath = frameworkFromJSCPath($jscPath)
Why do these disagree about realpath?
Michael Saboff
Comment 8
2014-05-22 14:07:41 PDT
(In reply to
comment #7
)
> (From update of
attachment 231905
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=231905&action=review
> > r=me > > > Tools/Scripts/run-jsc-stress-tests:110 > > puts "--jsc (-j) Path to JavaScriptCore. This option is required." > > Let's be clearer here: "Path to JavaScriptCore build product."
Done.
> > Tools/Scripts/run-jsc-stress-tests:111 > > + puts "--no-copy Use the existing JavaScriptCore specified by the --jsc option." > > Let's be clearer here: "Do not copy the JavaScriptCore build product before testing. --jsc specifies an already present JavaScriptCore to test."
Done.
> > Tools/Scripts/run-jsc-stress-tests:125 > > +jscPathArg = "" > > I'd call this "jscArg", since the argument is named "jsc" and not "jscPath".
Done.
> > Tools/Scripts/run-jsc-stress-tests:178 > > + $jscPath = Pathname.new(jscPathArg).realpath > > + else > > + $jscPath = Pathname.new(jscPathArg) > > Why do these disagree about realpath?
realpath will canonicalize the path by turning relative paths into absolute paths and resolving symbolic links. For example, providing "WebKitBuild/Release/JavaScriptCore/jsc" might become "/home/me/src/webkit/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc" This kind of full path breaks frameworkFromJSCPath() in the script and also generally doesn't work when the .realpath processing is done on the local machine and the --remote option was provided.
> > Tools/Scripts/run-jsc-stress-tests:1040 > > + if !$remote > > + $testingFrameworkPath = frameworkFromJSCPath($jscPath).realpath > > + $jscPath = Pathname.new($jscPath).realpath > > + else > > + $testingFrameworkPath = frameworkFromJSCPath($jscPath) > > Why do these disagree about realpath?
See above.
Michael Saboff
Comment 9
2014-05-22 14:13:06 PDT
Committed
r169217
: <
http://trac.webkit.org/changeset/169217
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug