Bug 126919
| Summary: | We generate DOM*.h ObjC headers for disabled features | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
| Component: | Bindings | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | andersca, ap, dbates, ddkilzer, mrowe, sam, simon.fraser, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Simon Fraser (smfr)
Our OS X DerivedSources has files like DOMTouch.h, DOMDeviceMotionEvent.h with fully-formed contents, even though the IDL files are using the appropriate "Conditional=" statements. This seems wrong; we should not generate these headers if the features are disabled.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/15881908>
Alexey Proskuryakov
Generally, I would say that all ports should always generate all headers, so that we wouldn't have to #ifdef at incude sites - ifdefs would be inside the headers.
Simon Fraser (smfr)
(In reply to comment #2)
> Generally, I would say that all ports should always generate all headers, so that we wouldn't have to #ifdef at incude sites - ifdefs would be inside the headers.
But we can't put ENABLE() or USE() macros in public headers. Those switches control what features WebKit exposes, so for me it makes sense to not have headers for nonexistent features.
Alexey Proskuryakov
Would not copying the headers into the framework in production builds also solve this, or is that more involved?
Anders Carlsson
This has been fixed now.