Using libkml in portable C++ applications

[ziashan]

Has anyone used libkml in a C++ application on both Windows and Linux? I'm using MinGW for the Windows build environment and have been unsuccessful in getting libkml to build. For the past two days I too have been trying to give birth to a pineapple. My application must be portable, so Visual Studio is out of the questions (besides, it's not available in my development environment anyway). On Debian Linux, simply installing the packages (libkml-dev and libboost-dev) gets you up and running in minutes. Why are there no equivalent pre-compiled binaries for MinGW? At this point, I'm seriously considering just hacking the kml output together with a simple iostream, but is there any other way?

Please let me know if you had a similar problem and how you solved it.

[Joel Odom]

I have had great success building and using libkml on Windows, Linux
and Android, all from the same libkml 1.2 code and C++ calling code.
(I do have lightweight shims for each OS for drawing and other system
calls, but 90% of my code is cross platform.)

Go ahead and build in Visual Studio. There's no reason that your code
can't be portable as long as you write it portable, even if you are
using the Visual Studio IDE to develop and build.

---
Joel Odom
http://giscoder.blogspot.com/

> --
> You received this message because you are subscribed to the Google Groups
> "libkml" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libkml+un...@googlegroups.com.
> To post to this group, send email to lib...@googlegroups.com.
> Visit this group at http://groups.google.com/group/libkml.
> For more options, visit https://groups.google.com/groups/opt_out.



--
http://www.falconview.org/

[ziashan]

The pineapple is born. It took a while to identify and figure out how to remove the MSVC-specific stuff. There's a good solution for mkstemp here, putenv can be used in place of setenv, all the <xstring> stuff has to be redone, and (most annoyingly) DATADIR conflicts with MinGW header objidl.h. I still don't think it should be so difficult. Such a useful library ought to be easy to port to just about any environment, but it seems to suffer from a common problem: there's the standard way, and there's the Microsoft way.

I see a lot of blog posts out there saying: why use libkml, just write your own. It's too bad they make a compelling case.