Bug 126919 - We generate DOM*.h ObjC headers for disabled features
Summary: We generate DOM*.h ObjC headers for disabled features
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Bindings (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-01-13 11:07 PST by Simon Fraser (smfr)
Modified: 2016-08-04 14:13 PDT (History)
8 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2014-01-13 11:07:01 PST 
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.
Comment 1 Radar WebKit Bug Importer 2014-01-22 10:13:05 PST 
<rdar://problem/15881908>
Comment 2 Alexey Proskuryakov 2014-01-22 10:17:06 PST 
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.
Comment 3 Simon Fraser (smfr) 2014-01-22 11:08:10 PST 
(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.
Comment 4 Alexey Proskuryakov 2014-01-22 11:18:48 PST 
Would not copying the headers into the framework in production builds also solve this, or is that more involved?
Comment 5 Anders Carlsson 2016-08-04 14:13:44 PDT 
This has been fixed now.