NEW 21443
Allow HAVE_ACCESSIBILITY to be overridden at build time
https://bugs.webkit.org/show_bug.cgi?id=21443
Summary Allow HAVE_ACCESSIBILITY to be overridden at build time
Amanda Walker
Reported 2008-10-07 13:13:44 PDT
Allow the HAVE_ACCESSIBILITY build setting to be overridden at build time, rather than keying only off of the platform, as a number of other build settings already permit.
Attachments
patch to allow HAVE_ACCESSIBILITY to be overridden at build time. (2.34 KB, patch)
2008-10-07 13:14 PDT, Amanda Walker
alp: review-
Amanda Walker
Comment 1 2008-10-07 13:14:43 PDT
Created attachment 24155 [details] patch to allow HAVE_ACCESSIBILITY to be overridden at build time.
Darin Adler
Comment 2 2008-10-07 13:22:01 PDT
Comment on attachment 24155 [details] patch to allow HAVE_ACCESSIBILITY to be overridden at build time. I don't think this is correct. The HAVE_ macros are supposed to represent the presence of a certain underlying capability, not whether we want to take advantage of it or not. If we want ACCESSIBILITY to be something we can turn on and off, then it probably needs to be an ENABLE thing instead. Or this might be yet an another PLATFORM(MAC) and PLATFORM(WIN) snafu of some sort. Also, tabs in ChangeLog.
Alp Toker
Comment 3 2008-10-07 13:33:32 PDT
As Darin says, accessibility should probably have been an ENABLE, not a HAVE. Would be nice if the patch could address that. Moreover, the #if PLATFORM(MAC) && HAVE(ACCESSIBILITY) change doesn't make much sense. If you don't want accessibility in your port, you probably don't want to compile the Accessibility* classes in the first place. Can you try wrapping the entire classes with HAVE/ENABLE(ACCESSIBILITY) guards instead? Thanks
Alp Toker
Comment 4 2008-10-07 13:34:17 PDT
Comment on attachment 24155 [details] patch to allow HAVE_ACCESSIBILITY to be overridden at build time. r- based on Darin's comments and mine
Amanda Walker
Comment 5 2008-10-07 13:39:28 PDT
(In reply to comment #2) That makes sense, though the purpose is to suppress the underlying capability at build time. I don't object to adding an ENABLE flag as well and requiring both to be set, but it seems unnecessarily verbose at first glance (since it would just change every occurrence of "HAVE(ACCESSIBILITY)" to "HAVE(ACCESSIBILITY) && ENABLE(ACCESSIBILITY)". Will fix tabs in changelog--oversight. (In reply to comment #3) > Moreover, the #if PLATFORM(MAC) && HAVE(ACCESSIBILITY) change doesn't make much > sense. If you don't want accessibility in your port, you probably don't want to > compile the Accessibility* classes in the first place. Can you try wrapping the > entire classes with HAVE/ENABLE(ACCESSIBILITY) guards instead? Great suggestion. Will try that and upload a new patch.
David Kilzer (:ddkilzer)
Comment 6 2008-11-08 04:40:55 PST
(In reply to comment #2) > (From update of attachment 24155 [details] [edit]) > I don't think this is correct. > > The HAVE_ macros are supposed to represent the presence of a certain underlying > capability, not whether we want to take advantage of it or not. If we want > ACCESSIBILITY to be something we can turn on and off, then it probably needs to > be an ENABLE thing instead. (In reply to comment #3) > As Darin says, accessibility should probably have been an ENABLE, not a HAVE. > Would be nice if the patch could address that. > > Moreover, the #if PLATFORM(MAC) && HAVE(ACCESSIBILITY) change doesn't make much > sense. If you don't want accessibility in your port, you probably don't want to > compile the Accessibility* classes in the first place. Can you try wrapping the > entire classes with HAVE/ENABLE(ACCESSIBILITY) guards instead? (In reply to comment #5) > (In reply to comment #2) > That makes sense, though the purpose is to suppress the underlying capability > at build time. I don't object to adding an ENABLE flag as well and requiring > both to be set, but it seems unnecessarily verbose at first glance (since it > would just change every occurrence of "HAVE(ACCESSIBILITY)" to > "HAVE(ACCESSIBILITY) && ENABLE(ACCESSIBILITY)". See Bug 21802. I think the underlying assumption is that most (all?) platforms have some kind of an accessibility layer, so changing HAVE(ACCESSIBILITY) to ENABLE(ACCESSIBILITY) is the desired fix. I don't think we want to be sprinkling "#if HAVE(ACCESSIBILITY) && ENABLE(ACCESSIBILITY)" everywhere, which seems redundant. :)
David Kilzer (:ddkilzer)
Comment 7 2008-11-08 04:55:51 PST
See also Bug 22137.
Darin Adler
Comment 8 2008-11-08 09:14:06 PST
(In reply to comment #6) > I think the underlying assumption is that most (all?) platforms > have some kind of an accessibility layer, so changing HAVE(ACCESSIBILITY) to > ENABLE(ACCESSIBILITY) is the desired fix. I'd say it differently. I'd say that we expect people to only enable accessibility on platforms that have an accessibility layer, and thus we don't need any indication of the presence or absence of the layer.
Note You need to log in before you can comment on or make changes to this bug.