Re: WebIDL consts now generate C++ definitions
On 10/27/17 12:33 PM, Steve Fink wrote: Within Spidermonkey, our rule is to never #include windows.h directly, but always via jswin.h Ah, I thought I'd seen this sort of thing somewhere; I had recalled a header that you could include to under "all the bad windows.h stuff"... This approach doesn't work for Gecko out of the box, because there's third-party code Gecko uses whose headers include windows.h, as you note. 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? Expediency, in this case... 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 The hard part is finding where all "those header files" are included. They're everywhere, unfortunately, because the chromium-ipc headers include windows.h. :( And you can't easily use try to get your way around this, because msvc very helpfully doesn't give include paths for its errors. 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. Yes, this would be absolutely ideal from my point of view. It's a much bigger project than I could justify asking Kyle to do for what was fundamentally a spare-time patch -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebIDL consts now generate C++ definitions
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 # 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
WebIDL consts now generate C++ definitions
As of Bug 792059 landing, If you're adding new WebIDL interfaces to gecko,
we will now generate constant definitions in the binding namespace of the
C++ binding headers.
For example, if you have a WebIDL interface that looks like
---
interface TestExampleInterface {
...
[NeedsWindowsUndef]
const unsigned long NO_ERROR = 0x;
...
}
---
This will now be accessible in C++ as
mozilla::dom::TestExampleInterfaceBinding::NO_ERROR. You will no longer
need to copy constant definitions into your binding implementations.
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.
This information will be in the MDN WebIDL Bindings page soon.
Bug 1407106 has been created to clean up the interface const definitions
already in gecko.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
