On 10/26/17 8:22 PM, Kyle Machulis wrote:
This addition also creates the new [NeedsWindowsUndef] extended attribute,
as some WebIDL constant names conflict with windows.h macros, and undef'ing
them in the binding generation is easier than tracking down include order
issues.
Gecko seems to handle windows.h in (what feels to me like) an ad hoc
way, where individual files will #undef whatever macros interfere with
them. Within Spidermonkey, our rule is to never #include windows.h
directly, but always via jswin.h, which is just
#ifdef XP_WIN
# include <windows.h>
# undef min
# undef max
# undef assert
.
.
.
#endif
Now the Gecko approach is being extended to creating a WebIDL attribute
for this. What are the objections to doing things the jswin.h way? I
understand there may be difficulties with third party code including
windows.h, but that just means that you additionally need to include
mozwin.h (or whatever we choose to call it) after including those header
files, and before any code that might make use of those tokens -- no
different than the decision of where to place an #undef.
Then if you need to define a webidl constant that conflicts with
windows.h damage, you'd add it to mozwin.h with no magic attribute required.
I am not confident that the mozwin.h approach is fully workable, as
there may be cases where the windows.h macros are used by other headers
or something. That is why I'm asking for objections.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
