We currently have ifdefs in implementation files, but SPI headers ship as is.
Created attachment 302775 [details] proposed fix
Comment on attachment 302775 [details] proposed fix We purposefully avoid using EXCLUDED_SOURCE_FILE_NAMES to exclude individual C-family source files in this project (it’s unfortunate that in the mad rush to “upstream” the iOS port, we ended up doing this in other projects and never fully recovered). I suggest adding appropriate preprocessor guards to the files instead.
Is it actually desirable to ship SPI headers that are fully ifdef'ed out? Using EXCLUDED_SOURCE_FILE_NAMES seems like a better solution to me.
(In reply to comment #3) > Is it actually desirable to ship SPI headers that are fully ifdef'ed out? > Using EXCLUDED_SOURCE_FILE_NAMES seems like a better solution to me. EXCLUDED_SOURCE_FILE_NAMES is an out-of-band signal (as opposed to preprocessor macros which are in-band). Its disadvantages include: it is not trivial for people and for the IDE to be aware of it, and it is specified in terms of glob patterns (I suspect many contributors don’t even know what matching rules they obey) that don’t follow the code across renames and refactoring. I believe that those disadvantages outweigh the nicety of excluding the headers from the SDK.
Normally, I would disagree, as the quality of API/SPI is more important than implementation details. But WebKit2 SPI is in need of much larger cleanup, so this one detail wouldn't make it appreciably better.
Created attachment 302800 [details] proposed patch
Comment on attachment 302800 [details] proposed patch Clearing flags on attachment: 302800 Committed r213022: <http://trac.webkit.org/changeset/213022>
All reviewed patches have been landed. Closing bug.