WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug