Fixes for compiling on Windows

[traversaro]

The fixes are the following (tested on Visual Studio 12 on Windows 7):

• Properly define debug library postfix.
• Use of a proper cmake FindTinyXML.cmake configuration file, imported from https://github.com/ros/cmake_modules .
• Export headers used in the library API (TinyXML and Boost).
• Avoid recreating the source path in the library path during the call to configure_file.

There is still another issue preventing to use the library in Windows, but I opened a separated issue ( #42 ) because is involve a more invasive change to the library structure.

[isucan]

@j-rivero @tfoote ?

[davetcoleman]

Should cmake/FindTinyXML.cmake be replaced with the cmake_modules equivalent, or is that only for catkin packages and this package is a stand-alone package?

[traversaro]

@davetcoleman as far as I understand, cmake_modules is a pure catkin package that cannot be installed without catkin. Consequently is not suitable to add it as a urdfdom dependency, because then urdfdom would depend on catkin.

[davetcoleman]

i believe you're right, yes

[j-rivero]

Yes, urdfdom is consider as a stand-alone library and it is used outside ROS, in fact it is an official ubuntu package.

[tfoote]

This looks like a cleaner solution. It would be really nice if TinyXML installed it's own cmake but until then copying the Find rule will be the cleanest solution.

[j-rivero]

Seems like Tinyxml authors designed it to be embedded into other projects, in its own words:

TinyXML is designed to be easy and fast to learn. It is two headers and four cpp files. Simply add these to your project and off you go.

So I won't expect any upstream movement into the line of having a cmake module. In downstream, the things are not easy too, since depending on the distribution, they are shipping custom pkgconfig files which brings some cross distribution discussions.

So yes, +1 to Silvio approach.

[traversaro]

@j-rivero I was discussing with our local CMake expert (cc @drdanz ) and he was suggesting that perhaps distribution mantainers could be interested in having a CMake-specific patch.
Considering that upstream is not interested in adding this configuration files, it could make sense to add a TinyXMLConfig.cmake at distribution level, as they already add a pkg-config tinyxml.pc file.
Do you think it is a feasible path?

[tfoote]

@traversaro I think that would be a good idea, especially if they're already adding the pkg-config files. The CMake infrastructure is a parallel usage. Of course this will take a while and so we'll have to deal with it in the mean time and for other platforms if it's not being accepted upstream.

[j-rivero]

@traversaro if we speak about distribution level, I agree, I see no reason for providing a .pc file but no a .cmake file. In this cases is totally up to the maintainer. However, it will make things worse at cross-distributions level (see the comments of the Gentoo maintainer in my previous link) with probably a good bunch of problems for not keeping in sync all the tinyxml.cmake floating around.

Another option could be trying to send it to cmake developers as a module so we get it in cmake-data like we have FindPNG, etc.

[traversaro]

@isucan @tfoote @j-rivero given the fruitful discussion, I guess we agree that in the short term the solution proposed in this PR (include the proper FindTinyXML.cmake file in the urdfdom repo) is the cleanest solution.

[j-rivero]

@traversaro +1

[traversaro]

Merged with current master.
I also did a small modification to the directory of installation of CMake config file to make them easier to find for a default installation, see robotology-dependencies@5866273 .

[traversaro]

I also had several other Windows-related fixes that I did an year ago, but I stopped submitting PRs when I saw that upstream was not interested in Windows related patches, and I then simply forked the repo. [1] If now there is interest for Windows-related fix I would be apply to port some of them upstream .

[1] : https://github.com/robotology-dependencies/urdfdom/commits/master

[scpeters]

+1