Question

We have a (very large) existing codebase for a custom ActiveX control, and I’d like to integrate libkml into it for the sake of interacting with KML mapping data, rather than reinventing the wheel. The problem is, I’m a relatively new Windows developer, and coming from the Linux world, I’m really not sure what the right way of integrating a third party library is. Thankfully, libkml does provide MSVCC projects for compiling it, so porting isn’t a problem. I guess I have a couple choices that I can think of:

1. Build and link the library directly. We already have a solution with project files in it for the “main” project; I could add the libkml projects to that solution, but I’d rather not. It’s very unlikely that the libkml code will change in relation to our app’s code.

2. Statically link to the .lib files produced by the libkml build. This is unattractive, since there are six .lib files that come out of the libkml solution and it seems inelegant to manually specify them in the linker options, etc.

3. Package the code as-is in a DLL. Maybe with COM? It seems like if I did this without any translation, I’d end up with a lot of overhead, and since I’m fairly unfamiliar with COM, I don’t know how much work would be involved in exposing all the functionality I’d like to use via COM. The library is fairly big, has a lot of classes it uses, and if I had to manually write code to expose it all, I’d be hesitant to go this route.

4. Write wrapper code to to abstract the functionality I need, package that in a COM DLL, and interact with that. This seems sensible, I suppose, but it’s difficult to determine how much abstraction I need since I haven’t written the code that would use libkml yet.

Let me reiterate: I haven’t yet written the code that will interact with libkml yet, so this is mostly experimental. Options 1 and 2 are also complicated by the fact that libkml relies additionally on three more external libraries that are also in .lib files (that I had to recompile anyways to get the code generation flags to line up). The goal obviously is to get the code to work, but maintainability and source tree organization are also goals, so I’m leaning towards options 3 and 4, but I don’t know the best way to approach those on Windows.

Answer 1

Typing six file names, or using the declarative style with #pragma comment(lib, “foo.lib”) is small potatoes compared to the work you’ll have to do to turn this into a DLL or COM server.

The distribution is heavily biased towards using this as a static link library. There are only spotty declarations available to turn this into a DLL with __declspec(dllexport). They exist only in the 3rd party dependencies. All using different #defines of course, you’ll by typing a bunch of names in the preprocessor definitions for the projects.

Furthermore, you’ll have a hard time actually getting this DLL loaded at runtime since you are using it in a COM server. The search path for DLLs will be the client app’s when COM creates your control instance, not likely to be anywhere near close to the place you deployed the DLL.

Making it a COM server is a lot of work, you’ll have to write all the interface glue yourself. Again, nothing already in the source code that helps with this at all.