Bug 105905 - [EFL][CMAKE] Remove duplicated conditionals
Summary: [EFL][CMAKE] Remove duplicated conditionals
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Gyuyoung Kim
URL:
Keywords:
Depends on:
Blocks: 106290
  Show dependency treegraph
 
Reported: 2013-01-01 20:12 PST by Gyuyoung Kim
Modified: 2013-01-09 13:57 PST (History)
5 users (show)

See Also:


Attachments
Patch (7.46 KB, patch)
2013-01-01 20:14 PST, Gyuyoung Kim
no flags Details | Formatted Diff | Diff
Patch (8.52 KB, patch)
2013-01-01 23:33 PST, Gyuyoung Kim
no flags Details | Formatted Diff | Diff
Patch (8.51 KB, patch)
2013-01-01 23:36 PST, Gyuyoung Kim
no flags Details | Formatted Diff | Diff
Patch for landing (8.51 KB, patch)
2013-01-02 16:18 PST, Gyuyoung Kim
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gyuyoung Kim 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.
Comment 1 Gyuyoung Kim 2013-01-01 20:14:47 PST
Created attachment 181007 [details]
Patch
Comment 2 Laszlo Gombos 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)"
Comment 3 Gyuyoung Kim 2013-01-01 23:33:59 PST
Created attachment 181010 [details]
Patch
Comment 4 Gyuyoung Kim 2013-01-01 23:36:02 PST
Created attachment 181011 [details]
Patch
Comment 5 Gyuyoung Kim 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.
Comment 6 Laszlo Gombos 2013-01-02 07:20:47 PST
Comment on attachment 181011 [details]
Patch

lgtm.
Comment 7 Gyuyoung Kim 2013-01-02 16:18:23 PST
Created attachment 181102 [details]
Patch for landing
Comment 8 WebKit Review Bot 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>
Comment 9 WebKit Review Bot 2013-01-02 17:01:58 PST
All reviewed patches have been landed.  Closing bug.
Comment 10 Laszlo Gombos 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.
Comment 11 Gyuyoung Kim 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.
Comment 12 Hugo Parente Lima 2013-01-09 09:14:07 PST
I think this can be closed now that the regression was fixed, right?