WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
127169
If not running on Mac, build-webkit should not print Safari related output
https://bugs.webkit.org/show_bug.cgi?id=127169
Summary
If not running on Mac, build-webkit should not print Safari related output
Éva Balázsfalvi
Reported
2014-01-17 02:27:13 PST
If not runned on MAC, "Tools/Scripts/build-webkit" should not post Safari related informations.
Attachments
Patch
(2.50 KB, patch)
2014-01-17 06:56 PST
,
Éva Balázsfalvi
no flags
Details
Formatted Diff
Diff
Patch
(2.47 KB, patch)
2014-02-03 06:14 PST
,
Éva Balázsfalvi
no flags
Details
Formatted Diff
Diff
Patch
(2.66 KB, patch)
2014-02-06 07:35 PST
,
Éva Balázsfalvi
no flags
Details
Formatted Diff
Diff
Patch
(2.65 KB, patch)
2014-02-10 04:11 PST
,
Éva Balázsfalvi
no flags
Details
Formatted Diff
Diff
patch for landing
(2.42 KB, patch)
2014-02-10 04:40 PST
,
Éva Balázsfalvi
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Éva Balázsfalvi
Comment 1
2014-01-17 06:56:47 PST
Created
attachment 221463
[details]
Patch
Daniel Bates
Comment 2
2014-01-17 09:55:20 PST
Comment on
attachment 221463
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=221463&action=review
> Tools/ChangeLog:3 > + If not runned on MAC, "Tools/Scripts/build-webkit" should not post Safari related informations
Nit: MAC => Mac Mac is not an acronym. It's shorthand for Macintosh.
> Tools/Scripts/build-webkit:431 > + if ($launcherPath ne "0" && $launcherName ne "0") {
Without loss of generality, take $launcherName to be undefined (say launcherName() falls off the end of the function) then evaluating the condition of this if statement will cause an uninitialized value warning because we run this script with -w (see the first line in this script). Moreover, it seems weird to define "0" as an invalid value and compare to it. It's sufficient to look at the truth value of the variables: if ($launcherPath && $launcherName) { ... }
> Tools/Scripts/webkitdirs.pm:1290 > + } elsif (isDarwin()) {
Can you elaborate on this change?
> Tools/Scripts/webkitdirs.pm:1305 > + } elsif (isDarwin()) {
Ditto.
Éva Balázsfalvi
Comment 3
2014-01-21 02:38:24 PST
(In reply to
comment #2
) Thank you for your feedback.
> Mac is not an acronym. It's shorthand for Macintosh. > if ($launcherPath && $launcherName) { ... }
Thanks for noticing, you were absolutely right. I've modified the code.
>> Tools/Scripts/webkitdirs.pm:1290 >> + } elsif (isDarwin()) {
>Can you elaborate on this change?
isAppleWebKit() gives back a value depending on the values of isGtk(), isEfl(), isWinCE(), isNix(). If we're using the script without any switch, each of these fuctions will give back a false value. But because of this, isAppleWebKit() will return as true, regardless of where we were running the script. This is why the Safari related output was given. isDarwin()'s value doesn't depend on any of the previously mentioned functions, that is why I thought it might be a good idea to use it instead of isAppleWebKit().
Éva Balázsfalvi
Comment 4
2014-01-30 04:11:10 PST
Ping?
Csaba Osztrogonác
Comment 5
2014-01-30 04:14:06 PST
(In reply to
comment #4
)
> Ping?
You turn now. :) Please fix what Daniel mentioned in
https://bugs.webkit.org/show_bug.cgi?id=127169#c2
and then upload the fixed patch with r?
Éva Balázsfalvi
Comment 6
2014-02-03 06:14:08 PST
Created
attachment 222980
[details]
Patch
Darin Adler
Comment 7
2014-02-03 09:55:56 PST
Comment on
attachment 222980
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=222980&action=review
> Tools/Scripts/build-webkit:434 > + if ($launcherPath && $launcherName) { > + print " To run $launcherName with this newly-built code, use the\n"; > + print " \"$launcherPath\" script.\n"; > + }
I understand this change.
> Tools/Scripts/webkitdirs.pm:1290 > - } elsif (isAppleWebKit()) { > + } elsif (isDarwin()) {
Why this change? Unclear how this relates to what the change log says. This makes it look like it will use run-safari more often, for anyone running on a Darwin system. That seems like the opposite of what the change log says this patch does.
> Tools/Scripts/webkitdirs.pm:1307 > + } elsif (isDarwin()) { > + return "Safari"; > }
Same comment here.
Darin Adler
Comment 8
2014-02-03 09:57:04 PST
(In reply to
comment #3
)
> isAppleWebKit() gives back a value depending on the values of isGtk(), isEfl(), isWinCE(), isNix(). If we're using the script without any switch, each of these fuctions will give back a false value. But because of this, isAppleWebKit() will return as true, regardless of where we were running the script.
If this is the problem, then we need to fix the isAppleWebKit function to correctly return false in these cases, rather than changing how it’s used.
Brent Fulgham
Comment 9
2014-02-05 16:29:48 PST
Comment on
attachment 222980
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=222980&action=review
> Tools/Scripts/webkitdirs.pm:-1300 > - return "Safari";
We should change this to WinLauncher.
Éva Balázsfalvi
Comment 10
2014-02-06 07:35:14 PST
Created
attachment 223332
[details]
Patch
Csaba Osztrogonác
Comment 11
2014-02-10 02:47:33 PST
Comment on
attachment 223332
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=223332&action=review
Please fix the typo before landing.
> Tools/Scripts/webkitdirs.pm:1116 > + return return isDarwin() && !isGtk();
typo: return return
> Tools/Scripts/webkitdirs.pm:1121 > + return return (isCygwin() || isWindows()) && !isWinCairo() && !isGtk() && !isWinCE();
ditto
Éva Balázsfalvi
Comment 12
2014-02-10 04:11:40 PST
Created
attachment 223692
[details]
Patch
Éva Balázsfalvi
Comment 13
2014-02-10 04:40:28 PST
Created
attachment 223697
[details]
patch for landing
WebKit Commit Bot
Comment 14
2014-02-10 05:11:02 PST
Comment on
attachment 223697
[details]
patch for landing Clearing flags on attachment: 223697 Committed
r163780
: <
http://trac.webkit.org/changeset/163780
>
WebKit Commit Bot
Comment 15
2014-02-10 05:11:05 PST
All reviewed patches have been landed. Closing bug.
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