WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
118195
[Tools] Add support for "webKitBranchBuild" git option when calculating jhbuildPath
https://bugs.webkit.org/show_bug.cgi?id=118195
Summary
[Tools] Add support for "webKitBranchBuild" git option when calculating jhbui...
Nick Diego Yamane (diegoyam)
Reported
2013-06-28 10:44:34 PDT
[Tools] Add support for "webKitBranchBuild" git option when calculating jhbuildPath
Attachments
Patch
(1.96 KB, patch)
2013-06-28 10:47 PDT
,
Nick Diego Yamane (diegoyam)
no flags
Details
Formatted Diff
Diff
Patch
(1.81 KB, patch)
2013-06-28 11:25 PDT
,
Nick Diego Yamane (diegoyam)
no flags
Details
Formatted Diff
Diff
Patch
(1.83 KB, patch)
2013-06-28 13:19 PDT
,
Nick Diego Yamane (diegoyam)
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Nick Diego Yamane (diegoyam)
Comment 1
2013-06-28 10:47:24 PDT
Created
attachment 205726
[details]
Patch
Nick Diego Yamane (diegoyam)
Comment 2
2013-06-28 10:48:53 PDT
Currently, ports that use jhbuild fail to determine jhbuild directory when "webKitBranchBuild" git configuration property is enabled. To reproduce that issue in Efl port, enable that flag in .git/config, switch to a git branch other than "master" and try to build webkit. The build will fail to locate dependencies due to lack of pkg-config paths which should be set by jhbuild. For more details about "webKitBranchBuild" option, see:
https://trac.webkit.org/wiki/UsingGitWithWebKit
Nick Diego Yamane (diegoyam)
Comment 3
2013-06-28 11:25:01 PDT
Created
attachment 205727
[details]
Patch Updated ChangeLog
Daniel Bates
Comment 4
2013-06-28 12:38:39 PDT
Comment on
attachment 205727
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=205727&action=review
> Tools/Scripts/webkitdirs.pm:1884 > + pop(@jhbuildPath);
This line is error prone as it depends on the implementation detail that baseProductDir() always appends a "/" to the end of the base product path when it's a Git branch build by line 239 of webkitdirs.pm (
r152104
), <
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitdirs.pm?rev=152104#L239
>. This detail is likely to change as we move towards using File::Spec operations to build a file system path instead of string concatenation to build a path. I suggest that we pop() the last directory only if it's a Git branch build and gitBranch() is a non-empty string.
Nick Diego Yamane (diegoyam)
Comment 5
2013-06-28 13:01:46 PDT
(In reply to
comment #4
)
> (From update of
attachment 205727
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=205727&action=review
> > > Tools/Scripts/webkitdirs.pm:1884 > > + pop(@jhbuildPath); > > This line is error prone as it depends on the implementation detail that baseProductDir() always appends a "/" to the end of the base product path when it's a Git branch build by line 239 of webkitdirs.pm (
r152104
), <
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitdirs.pm?rev=152104#L239
>. This detail is likely to change as we move towards using File::Spec operations to build a file system path instead of string concatenation to build a path. I suggest that we pop() the last directory only if it's a Git branch build and gitBranch() is a non-empty string.
Yes, you're right. I'll add that checking (non-empty gitBranch()). thanks
Nick Diego Yamane (diegoyam)
Comment 6
2013-06-28 13:19:36 PDT
Created
attachment 205736
[details]
Patch Added checking for non-empty git branch to determine jhbuild path.
Daniel Bates
Comment 7
2013-06-28 13:43:12 PDT
Comment on
attachment 205736
[details]
Patch r=me
WebKit Commit Bot
Comment 8
2013-06-28 15:21:40 PDT
Comment on
attachment 205736
[details]
Patch Clearing flags on attachment: 205736 Committed
r152191
: <
http://trac.webkit.org/changeset/152191
>
WebKit Commit Bot
Comment 9
2013-06-28 15:21:43 PDT
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