Re: who uses idl stuff
I might suggest having a look at https://wiki.mozilla.org/Gecko:Overview for your general architectural questions. On Sun, Jul 23, 2017 at 12:00 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > Hi folks, > > > could anyone please give me some insight, where the the IDLs > (and the code generated from them) are actually used ? > > Javascript bindings ? > > > --mtx > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: who uses idl stuff
On 24.07.2017 02:18, Boris Zbarsky wrote: Hi, Brief summary. IDL: 1) Generates xptcall information for xpconnect to allow calling from JS and into JS (via synthetic vtables). 2) Generates headers that declare pure virtuals. 3) Is used for defining XPCOM interfaces. (you can do just #2 without #1 if the interface is not scriptable). I see *a lot* idl stuff here. Is that all scriptable ? And does it really need to be ? WebIDL: 1) Generates C++ glue code to allow calling from JS (or into JS in the case of callbacks or callback interfaces). 2) Is used for defining things that are part of the web platform. Is standardized at https://heycam.github.io/webidl/ What exactly is the diffence of the web platform and xpcom ? Why are both used ? I've noticed that webidl's seem to support preprocessor directives (eg. #ifdef), while the others dont. That is one of the many differences, yes. They also have different use cases, different syntax, different output. How can I add preprocessor to the XPCOM IDLs ? Problem is: there are lots of references to things I'd like to disable in here. For now, I'll have to directly patch it out. --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: who uses idl stuff
On 7/23/17 9:58 PM, Enrico Weigelt, metux IT consult wrote: what's the difference between idl and webidl ? Brief summary. IDL: 1) Generates xptcall information for xpconnect to allow calling from JS and into JS (via synthetic vtables). 2) Generates headers that declare pure virtuals. 3) Is used for defining XPCOM interfaces. (you can do just #2 without #1 if the interface is not scriptable). WebIDL: 1) Generates C++ glue code to allow calling from JS (or into JS in the case of callbacks or callback interfaces). 2) Is used for defining things that are part of the web platform. Is standardized at https://heycam.github.io/webidl/ I've noticed that webidl's seem to support preprocessor directives (eg. #ifdef), while the others dont. That is one of the many differences, yes. They also have different use cases, different syntax, different output. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: who uses idl stuff
On 24.07.2017 00:11, Enrico Weigelt, metux IT consult wrote: what's the difference between idl and webidl ? I've noticed that webidl's seem to support preprocessor directives (eg. #ifdef), while the others dont. --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: who uses idl stuff
On 23.07.2017 18:15, Botond Ballo wrote:
could anyone please give me some insight, where the the IDLs
(and the code generated from them) are actually used ?
Javascript bindings ?
They are typically used as an interface between C++ and JS code.
Ah, what I've already suspected.
While trying to disable media stuff (in 45.8 - the version in jessie),
I had already removed that stuff from the IDLs, but still after
regeneration these functions appeared again (but couldn't find them
anywhere else), leading to breaking build (pure virtuals that hadn't
been overwritten.
After doing a complete clean, the error didn't appear again.
Are there some cache files (binary/compressed or outside the src tree) ?
Now it breaks w/ LDAP stuff:
Executing: c++ -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare
-Wwrite-strings -Wno-invalid-offsetof -Wcast-align -g -O2
-fno-delete-null-pointer-checks -fno-schedule-insns2 -fno-exceptions
-fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections
-fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG
-DTRIMMED -g -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared
-Wl,-z,defs -Wl,--gc-sections -Wl,-h,libprldap60.so -o libprldap60.so
/home/nekrad/src/thunderbird/icedove-45.8.0/obj-thunderbird/ldap/c-sdk/libraries/libprldap/tmpvhq1t4.list
-lpthread -Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,--stats
-Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id
-Wl,-rpath-link,/home/nekrad/src/thunderbird/icedove-45.8.0/obj-thunderbird/dist/bin
-Wl,-rpath-link,/usr/lib ../libldap/libldap60.so
../../../../nsprpub/lib/ds/libplds4.so
../../../../nsprpub/lib/libc/src/libplc4.so
../../../../nsprpub/pr/src/libnspr4.so -ldl
/home/nekrad/src/thunderbird/icedove-45.8.0/obj-thunderbird/ldap/c-sdk/libraries/libprldap/tmpvhq1t4.list:
INPUT("ldappr-dns.o")
INPUT("ldappr-error.o")
INPUT("ldappr-io.o")
INPUT("ldappr-public.o")
INPUT("ldappr-threads.o")
/usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS): In
function `__stack_chk_fail_local':
(.text+0x10): undefined reference to `__stack_chk_fail'
collect2: error: ld returned 1 exit status
Meanwhile I'm trying a fresh start on 52esr branch.
Again trouble w/ IDLs: for example it couldn't find PFTPChannel.ipdl,
PTransportProvider.ipdl, etc.
--mtx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: who uses idl stuff
> could anyone please give me some insight, where the the IDLs > (and the code generated from them) are actually used ? > > Javascript bindings ? They are typically used as an interface between C++ and JS code. As an example, consider nsIDocShell.idl [1]. This defines an interface named "nsIDocShell" with a bunch of attributes and methods. The IDL compiler generates a C++ binding for this, in the form of a header file [2] that declares an abstract base class, also named "nsIDocShell", which has pure virtual C++ methods corresponding to the IDL methods and attributes (in the case of attributes, a getter/setter pair is generated). There is then a concrete C++ class, nsDocShell [3], which inherits from nsIDocShell and implements the methods. Finally, the interface is made available for JS code to use, which can access its methods, attributes, etc. [4] The methods can also be called from C++ code [5], though typically there are at least some JS callers, otherwise the IDL wouldn't be necessary. Let me know if that answers your question. Cheers, Botond [1] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/docshell/base/nsIDocShell.idl#58 [2] http://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIDocShell.h [3] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/docshell/base/nsDocShell.h [4] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/browser/base/content/content.js#603 [5] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/accessible/generic/DocAccessible.cpp#355 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
