RESOLVED FIXED 236024
[WPE] Fix for non-unified builds with ACCESSIBILITY=OFF
https://bugs.webkit.org/show_bug.cgi?id=236024
Summary [WPE] Fix for non-unified builds with ACCESSIBILITY=OFF
Pablo Saavedra
Reported 2022-02-02 09:31:07 PST
in the code you can see many blocks safeguarded by: #if ENABLE(ACCESSIBILITY) && USE(ATSPI) But, at the same time, there is in many other places another variation of those checks without the ENABLE(ACCESSIBILITY) only checking the USE_ATSPI or USE_ATK values. This generates inconsistencies because missing definitions when ACCESSIBILITY is OFF. For example here where the definition of the "class AccessibilityObjectAtspi" is safeguarded in Source/WebCore/accessibility/atspi/AccessibilityObjectAtspi.h with "#if ENABLE(ACCESSIBILITY) && USE(ATSPI)" but later in the the Source/WebCore/accessibility/AccessibilityObjectInterface.h: #if PLATFORM(COCOA) OBJC_CLASS WebAccessibilityObjectWrapper; typedef WebAccessibilityObjectWrapper AccessibilityObjectWrapper; typedef struct _NSRange NSRange; typedef const struct __AXTextMarker* AXTextMarkerRef; typedef const struct __AXTextMarkerRange* AXTextMarkerRangeRef; #elif USE(ATSPI) typedef WebCore::AccessibilityObjectAtspi AccessibilityObjectWrapper; <<<<<<<< Missing definition of WebCore::AccessibilityObjectAtspi #elif USE(ATK) typedef struct _WebKitAccessible WebKitAccessible; typedef struct _WebKitAccessible AccessibilityObjectWrapper; #else class AccessibilityObjectWrapper; #endif The patch uploaded in this sets TRUE USE_ATK or USE_ATSPI as mutually exclusive when ENABLE_ACCESSIBILITY=ON and forces both to FALSE if case of ENABLE_ACCESSIBILITY=OFF: -if (ENABLE_ACCESSIBILITY AND NOT USE_ATSPI) - SET_AND_EXPOSE_TO_BUILD(USE_ATK TRUE) +if (ENABLE_ACCESSIBILITY) + if (USE_ATSPI) + SET_AND_EXPOSE_TO_BUILD(USE_ATK FALSE) + else () + SET_AND_EXPOSE_TO_BUILD(USE_ATK TRUE) + endif () +else () + SET_AND_EXPOSE_TO_BUILD(USE_ATK FALSE) + SET_AND_EXPOSE_TO_BUILD(USE_ATSPI FALSE) This simplifies the checks in the code since from now on a simple "#if USE(ATSPI)" is equivalent to a "#if ENABLE(ACCESSIBILITY) && USE(ATSPI)"
Attachments
patch (24.97 KB, patch)
2022-02-02 09:33 PST, Pablo Saavedra
no flags
patch (24.94 KB, patch)
2022-02-02 09:36 PST, Pablo Saavedra
no flags
Pablo Saavedra
Comment 1 2022-02-02 09:33:29 PST
Pablo Saavedra
Comment 2 2022-02-02 09:36:11 PST
Darin Adler
Comment 3 2022-02-02 12:34:19 PST
This solution is fine. But I have a slight preference for solving as many of these problems as possible in C++ headers rather than in CMake. For example, we could have this code in one of the platform headers: #if !ENABLED(ACCESSIBILITY) #undef USE_ATK #undef USE_ATSPI #endif Then we would not have to be careful about those settings in the build/make environment because the header would fix it. My view is that generally speaking our main implementation language is C++, and we should only do the things in the build system that cannot be cleanly done with C++ code.
Pablo Saavedra
Comment 4 2022-02-02 13:58:04 PST
(In reply to Darin Adler from comment #3) > This solution is fine. > > But I have a slight preference for solving as many of these problems as > possible in C++ headers rather than in CMake. For example, we could have > this code in one of the platform headers: > > #if !ENABLED(ACCESSIBILITY) > #undef USE_ATK > #undef USE_ATSPI > #endif > > Then we would not have to be careful about those settings in the build/make > environment because the header would fix it. My view is that generally > speaking our main implementation language is C++, and we should only do the > things in the build system that cannot be cleanly done with C++ code. Sounds reasonable and Normally I might tend to agree with you and found your suggestion much more convenient. However those USE_ATK/USE_ATSPI are also used by other .cmake files like here: ./WebCore/PlatformWPE.cmake if (USE_ATSPI) set(WebCore_AtspiInterfaceFiles ... In summary, if we don't set those definitions early in the Source/cmake/OptionsWPE.cmake then we could generate again inconsistencies because the differences between the values of those definitions in the cmake and then in the .h .cpp sources.
Carlos Garcia Campos
Comment 5 2022-02-02 22:51:17 PST
Comment on attachment 450661 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=450661&action=review > Source/WebCore/ChangeLog:3 > + [WPE] Fix for non-unified builds with ACCESSIBILITY=OFF Why is this wpe specific?
EWS
Comment 6 2022-02-02 23:06:44 PST
Committed r289029 (246737@main): <https://commits.webkit.org/246737@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 450661 [details].
Radar WebKit Bug Importer
Comment 7 2022-02-02 23:07:22 PST
Note You need to log in before you can comment on or make changes to this bug.