Bug 105905

Summary: [EFL][CMAKE] Remove duplicated conditionals
Product: WebKit Reporter: Gyuyoung Kim <gyuyoung.kim>
Component: WebKit EFLAssignee: Gyuyoung Kim <gyuyoung.kim>
Status: RESOLVED FIXED    
Severity: Normal CC: hugo.lima, laszlo.gombos, lucas.de.marchi, rakuco, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 106290    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch for landing none

Gyuyoung Kim
Reported 2013-01-01 20:12:23 PST
Some files have used unneeded macros though same macros are already wrapped around files. It messes up cmake file.
Attachments
Patch (7.46 KB, patch)
2013-01-01 20:14 PST, Gyuyoung Kim
no flags
Patch (8.52 KB, patch)
2013-01-01 23:33 PST, Gyuyoung Kim
no flags
Patch (8.51 KB, patch)
2013-01-01 23:36 PST, Gyuyoung Kim
no flags
Patch for landing (8.51 KB, patch)
2013-01-02 16:18 PST, Gyuyoung Kim
no flags
Gyuyoung Kim
Comment 1 2013-01-01 20:14:47 PST
Laszlo Gombos
Comment 2 2013-01-01 21:30:25 PST
Comment on attachment 181007 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=181007&action=review Overall looks good to me - I like the idea of sharing build rules with other ports and moving logic from the port specific build system into common C/C++ files make sense to me. > Source/WebCore/ChangeLog:9 > + Some files have used unneeded macros though same macros are already wrapped around files. It > + messes up cmake file. More precise description would be better - e.g. "Remove conditionals from CMake build system, where the files being built are already wrapped with the conditionals." > Source/WebCore/PlatformEfl.cmake:-305 > - It seems to me that we can than remove the CMake variables as well - e.g. no need for the following line "cmake/OptionsEfl.cmake: set(WTF_USE_GLX 1)"
Gyuyoung Kim
Comment 3 2013-01-01 23:33:59 PST
Gyuyoung Kim
Comment 4 2013-01-01 23:36:02 PST
Gyuyoung Kim
Comment 5 2013-01-01 23:42:44 PST
(In reply to comment #2) > (From update of attachment 181007 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=181007&action=review > > Overall looks good to me - I like the idea of sharing build rules with other ports and moving logic from the port specific build system into common C/C++ files make sense to me. It looks GNUMakefile also tries not to use conditionals for .cpp / .h files. But, I'm not sure if I can guide this rule to all C/C++ files now. It looks each port has own policy. > > Source/WebCore/ChangeLog:9 > > + Some files have used unneeded macros though same macros are already wrapped around files. It > > + messes up cmake file. > > More precise description would be better - e.g. "Remove conditionals from CMake build system, where the files being built are already wrapped with the conditionals." > > > Source/WebCore/PlatformEfl.cmake:-305 > > - > > It seems to me that we can than remove the CMake variables as well - e.g. no need for the following line "cmake/OptionsEfl.cmake: set(WTF_USE_GLX 1)" Fix all. Thanks.
Laszlo Gombos
Comment 6 2013-01-02 07:20:47 PST
Comment on attachment 181011 [details] Patch lgtm.
Gyuyoung Kim
Comment 7 2013-01-02 16:18:23 PST
Created attachment 181102 [details] Patch for landing
WebKit Review Bot
Comment 8 2013-01-02 17:01:53 PST
Comment on attachment 181102 [details] Patch for landing Clearing flags on attachment: 181102 Committed r138681: <http://trac.webkit.org/changeset/138681>
WebKit Review Bot
Comment 9 2013-01-02 17:01:58 PST
All reviewed patches have been landed. Closing bug.
Laszlo Gombos
Comment 10 2013-01-07 17:22:51 PST
I just noticed that some of the files under accessibility/atk/ are not guarded with HAVE(ACCESSIBILITY). This is a regression for builds where ACCESSIBILITY is not enabled. REOPEN the bug to fix the regression.
Gyuyoung Kim
Comment 11 2013-01-07 18:26:15 PST
(In reply to comment #10) > I just noticed that some of the files under accessibility/atk/ are not guarded with HAVE(ACCESSIBILITY). This is a regression for builds where ACCESSIBILITY is not enabled. REOPEN the bug to fix the regression. Ooops, ok, I'm gonna prepare a patch to fix this regression. But, I prefer to use HAVE(ACCESSIBILITY) guard inside file.
Hugo Parente Lima
Comment 12 2013-01-09 09:14:07 PST
I think this can be closed now that the regression was fixed, right?
Note You need to log in before you can comment on or make changes to this bug.