WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
153528
[EFL] All API tests are broken on 15.10
https://bugs.webkit.org/show_bug.cgi?id=153528
Summary
[EFL] All API tests are broken on 15.10
Gyuyoung Kim
Reported
2016-01-26 19:02:02 PST
When running EFL API tests on Ubuntu 15.10, all tests are failed. Need to fix it to bump Ubuntu version.
Attachments
Patch
(1.92 KB, patch)
2016-01-31 06:40 PST
,
Joonghun Park
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Joonghun Park
Comment 1
2016-01-29 21:48:32 PST
It seems that this issue is caused by
https://bugs.webkit.org/show_bug.cgi?id=153211
. When I revert it, I found that API tests execution works well in 15.10 as well as 15.04.
Joonghun Park
Comment 2
2016-01-31 06:40:01 PST
Created
attachment 270340
[details]
Patch
Gyuyoung Kim
Comment 3
2016-01-31 16:23:02 PST
Comment on
attachment 270340
[details]
Patch rs=me.
WebKit Commit Bot
Comment 4
2016-01-31 17:21:01 PST
Comment on
attachment 270340
[details]
Patch Clearing flags on attachment: 270340 Committed
r195945
: <
http://trac.webkit.org/changeset/195945
>
WebKit Commit Bot
Comment 5
2016-01-31 17:21:05 PST
All reviewed patches have been landed. Closing bug.
Michael Catanzaro
Comment 6
2016-01-31 19:48:30 PST
Hm, this defeats the point of putting those statements in conditionals, and will break Windows. See the bottom of
bug #153211
. We should think about how to make this work for both EFL and Windows. It's also rather fragile to have code that depends on include order. Maybe we should just set the directories for Windows in the toplevel CMakeLists.txt, to make this more clear.
Gyuyoung Kim
Comment 7
2016-01-31 20:57:11 PST
(In reply to
comment #6
)
> Hm, this defeats the point of putting those statements in conditionals, and > will break Windows. See the bottom of
bug #153211
.
Now I don't know this change still causes to copy files to bin instead of bin64 on win port. Now I'm checking it.
Joonghun Park
Comment 8
2016-01-31 20:59:36 PST
(In reply to
comment #6
)
> Hm, this defeats the point of putting those statements in conditionals, and > will break Windows. See the bottom of
bug #153211
. > > We should think about how to make this work for both EFL and Windows. It's > also rather fragile to have code that depends on include order. Maybe we > should just set the directories for Windows in the toplevel CMakeLists.txt, > to make this more clear.
(In reply to
comment #6
)
> Hm, this defeats the point of putting those statements in conditionals, and > will break Windows. See the bottom of
bug #153211
. > > We should think about how to make this work for both EFL and Windows. It's > also rather fragile to have code that depends on include order. Maybe we > should just set the directories for Windows in the toplevel CMakeLists.txt, > to make this more clear.
First of all, OptionsEfl.cmake:46's statement add_definitions(-DWEBKIT-EXEC_PATH=\"${CMAKE_RUNTIME_OUTPUT_DIRECTORY}\") uses the value otherwise all the api tests goes to be blocked, so I put this change in. I have seen the bottom of the link you had left,
https://bugs.webkit.org/show_bug.cgi?id=153211
. And as you said, this change makes the conditional meaningless truly, but it seems that current cmake working is fine because the CMAKE_FOO_OUTPUT_DIRECTORY will be overwritten by OptionsWin.cmake and then the values will be used. So I think this change is not breaking Windows, but if I missed something please let me know. And as you said some changes would be needed including removing the conditionals or the ordering dependency causing the code fragile.
Gyuyoung Kim
Comment 9
2016-01-31 21:48:22 PST
(In reply to
comment #7
)
> (In reply to
comment #6
) > > Hm, this defeats the point of putting those statements in conditionals, and > > will break Windows. See the bottom of
bug #153211
. > > Now I don't know this change still causes to copy files to bin instead of > bin64 on win port. Now I'm checking it.
In my local win port build is fine after merging this change. Besides MiniBrowser works well. But unfortunately my local windows box is 32bit. So I'm not sure if my test is fine or not. Alex, could you let check if this changes breaks something on win port ?
Michael Catanzaro
Comment 10
2016-02-01 06:51:22 PST
I think Joonghun is right, Windows should be fine since it will overwrite these values after they're set. We should still clean this up, though.
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