Michael brought up some points about the incremental building that started getting me thinking about C++ & COM in general and how it fits/will fit into gradle.
COM in C++ manifests in manners that are quite different than standard library development. (COM can technically be used in plain C, but it's more cumbersome and generally not recommended) (COM in C# follows standard behaviours like other libraries, but that's a different topic for the future) Creating C++ COM (type) libraries: This is most typically started from .idl files [1] (which can include other COM libraries as part of referencing/derivation) the midl.exe utility [2] (usually) creates a .c, a .h, and a .tlb file The .c and .h files are for implementing the library and the .tlb file is the 'public' API that gets published/referenced by other code. There are some cases where the .tlb is unnecessary, such as when making an Add-on to some other application that has an established 'API contract' to interact with the library being created. Due to midl generating .c and .h files, doing this in the Visual Studio IDE becomes a bit odd as you include a .c file into the source compilation when it may not be there. However, Visual Studio also prioritizes .idl files and processes them before most other code, to prevent the potential of the .c and .h file being missing when being used in other code. Using COM (type) libraries: Traditional C/C++ dependencies are _linked_ against with shared or static libraries. COM libraries are handled in the _compile_ phase via the #import directive in the source code [3] In summary of the MSDN article, the #import directive is a relative powerful directive being capable of being used on a few different file types (such as .dll, .tlb. and .olb). #import can also however, directly go into the Windows registry and start pulling information out of it (such as with the libid: and progid: forms). #import generates a .tlh file, and depending on the library contents, a .tli can also be generated (and is automatically included by the .tlh in this scenario) - compiler interpretation-wise, the #import declarative is replaced by an #include declarative for the generated .tlh file. All in all, COM in C++ adds some amount of complexity to the overall process and paradigm. Affecting pieces such as * incremental building * dependency management * publishing At work we have a heavy involvement with COM, from a number of the applications we need to interact with having COM-based APIs (primarily CAD Applications), so the handling of COM in C++ is rather important to us. Has gradle already started any thinking about COM and how it'll fit into the native toolchain (C++) support? Thanks, Steven. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa367091(v=vs.85).aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa367300(v=vs.85).aspx [3] http://msdn.microsoft.com/en-us/library/vstudio/8etzzkb6(v=vs.100).aspx --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
