On Thu, Nov 28, 2013 at 12:58 PM, Steven Walters <kemu...@gmail.com> wrote:
> 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? > I didn't realise that gradle had developed the capacity for thought :). But yes, there's been some initial thoughts on this: https://github.com/gradle/gradle/blob/master/design-docs/continuous-delivery-for-c-plus-plus.md#story-generate-source-from-microsoft-idl-files > > 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 > > >
