RESOLVED FIXED 72815
[CMake] Share build system options across ports
https://bugs.webkit.org/show_bug.cgi?id=72815
Summary [CMake] Share build system options across ports
Patrick R. Gansterer
Reported 2011-11-19 17:52:24 PST
[CMake] Share build system options across ports
Attachments
Patch (25.33 KB, patch)
2011-11-19 17:58 PST, Patrick R. Gansterer
no flags
Patch (25.33 KB, patch)
2011-12-02 03:09 PST, Patrick R. Gansterer
no flags
Patch (25.29 KB, patch)
2011-12-02 04:01 PST, Patrick R. Gansterer
no flags
Patch (25.90 KB, patch)
2011-12-02 04:12 PST, Patrick R. Gansterer
gyuyoung.kim: commit-queue-
Patch (26.93 KB, patch)
2012-04-09 02:42 PDT, Patrick R. Gansterer
no flags
Patrick R. Gansterer
Comment 1 2011-11-19 17:58:16 PST
Created attachment 115965 [details] Patch This patch depends on the patch at bug 72815.
Daniel Bates
Comment 2 2011-12-01 09:39:01 PST
Comment on attachment 115965 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=115965&action=review Yay for less duplication! > Source/cmake/WebKitFeatures.cmake:3 > +MACRO (WEBKIT_OPTION_DEFINE _name _description _initialvalue) Nit: I've noticed an inconsistency in the placement of a space between the directive name and the opening parenthesis '('. You seem to always place a space between the MACRO directive and its opening parenthesis, but you don't carry over this style to other directives such as MESSAGE, SET, and STRING throughout this patch. I suggest picking a style and being consistent.
Patrick R. Gansterer
Comment 3 2011-12-02 03:09:03 PST
Patrick R. Gansterer
Comment 4 2011-12-02 04:01:55 PST
Gyuyoung Kim
Comment 5 2011-12-02 04:10:08 PST
Patrick R. Gansterer
Comment 6 2011-12-02 04:12:59 PST
Gyuyoung Kim
Comment 7 2011-12-02 04:32:43 PST
Raphael Kubo da Costa (:rakuco)
Comment 8 2011-12-02 06:07:58 PST
(In reply to comment #1) > Created an attachment (id=115965) [details] > Patch > > This patch depends on the patch at bug 72815. I thought this was bug 72815? :) WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END don't sound very natural to me. Wouldn't it be possible to move the default options to OptionsCommon.cmake and then just override them in Options${PORT}.cmake?
Raphael Kubo da Costa (:rakuco)
Comment 9 2011-12-02 06:08:25 PST
+dbates in case he has anything to add to my comment.
Patrick R. Gansterer
Comment 10 2011-12-02 06:18:36 PST
(In reply to comment #8) > (In reply to comment #1) > > Created an attachment (id=115965) [details] [details] > > Patch > > > > This patch depends on the patch at bug 72815. > > I thought this was bug 72815? :) > > WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END don't sound very natural to me. Wouldn't it be possible to move the default options to OptionsCommon.cmake and then just override them in Options${PORT}.cmake? That's exactly what this patch does? It defines the default options in WebKitFeatures.cmake and then allows ports to overwrite the defaults. Thanks to the many includes, it's not possible to remove the WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END for now. I need to define them first, then overwrite the defaults and then call the CMake OPTION() to make them visible in CMake GUI.
Raphael Kubo da Costa (:rakuco)
Comment 11 2011-12-02 07:08:33 PST
(In reply to comment #10) > (In reply to comment #8) > > WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END don't sound very natural to me. Wouldn't it be possible to move the default options to OptionsCommon.cmake and then just override them in Options${PORT}.cmake? > That's exactly what this patch does? It defines the default options in WebKitFeatures.cmake and then allows ports to overwrite the defaults. > Thanks to the many includes, it's not possible to remove the WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END for now. I need to define them first, then overwrite the defaults and then call the CMake OPTION() to make them visible in CMake GUI. I know. My point is that I think it would look cleaner if OptionsCommon.cmake did what WEBKIT_OPTION_BEGIN does (or called it), then Options${PORT}.cmake overrode the options it needs to and WEBKIT_OPTION_END could be called by the top-level CMakeLists.txt after including Options*.cmake (or the code could be moved there). This would move the begin-end combo to a single place instead of the current 3.
Patrick R. Gansterer
Comment 12 2011-12-02 07:17:50 PST
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #8) > > > WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END don't sound very natural to me. Wouldn't it be possible to move the default options to OptionsCommon.cmake and then just override them in Options${PORT}.cmake? > > That's exactly what this patch does? It defines the default options in WebKitFeatures.cmake and then allows ports to overwrite the defaults. > > Thanks to the many includes, it's not possible to remove the WEBKIT_OPTION_BEGIN and WEBKIT_OPTION_END for now. I need to define them first, then overwrite the defaults and then call the CMake OPTION() to make them visible in CMake GUI. > > I know. My point is that I think it would look cleaner if OptionsCommon.cmake did what WEBKIT_OPTION_BEGIN does (or called it), then Options${PORT}.cmake overrode the options it needs to and WEBKIT_OPTION_END could be called by the top-level CMakeLists.txt after including Options*.cmake (or the code could be moved there). This would move the begin-end combo to a single place instead of the current 3. IMHO the current state of the CMake build system is far away from perfect. This is only a step in the right direction. For me the alternative is to write the whole CMake files starting with null. I also have many many troubles with other port (see bug 72816 and bug 73100). As you might know it's hard to change the current stuff in reviewable parts. The first commit of the system was easy since it didn't get a deep review. So if it's ok I'd like to get this in (with EFL fixes), since it is at least better than the current version.
Eric Seidel (no email)
Comment 13 2011-12-19 10:47:48 PST
Comment on attachment 115965 [details] Patch Cleared Daniel Bates's review+ from obsolete attachment 115965 [details] so that this bug does not appear in http://webkit.org/pending-commit.
Patrick R. Gansterer
Comment 14 2012-04-09 02:42:21 PDT
Created attachment 136202 [details] Patch It build on my machine; submit for EFL EWS analysis.
Patrick R. Gansterer
Comment 15 2012-04-09 03:45:26 PDT
Comment on attachment 136202 [details] Patch Clearing flags on attachment: 136202 Committed r113570: <http://trac.webkit.org/changeset/113570>
Patrick R. Gansterer
Comment 16 2012-04-09 03:45:35 PDT
All reviewed patches have been landed. Closing bug.
Eric Seidel (no email)
Comment 17 2012-05-02 23:14:07 PDT
Comment on attachment 136202 [details] Patch With a little refactoring to move the ENABLE_ declarations into their own file, this would be simple to autogenerate as per bug 85456.
Note You need to log in before you can comment on or make changes to this bug.