Allow static library builds

[jslee02]

This PR enables urdfdom to build static libraries by:

• adding shared/static build option
• adding URDFDOM_STATIC definition for static build
• removing explicit build type specification from add_library(~)

This does not change the default build behavior (i.e., shared build) when the build type is not specified.

[traversaro]

Adding the definition only here will mean that client binaries that link urdfdom as a static library will import the headers with URDFDOM_DLLAPI set to __declspec(dllimport).
This at least by inspection of https://github.com/ros/urdfdom/blob/master/urdf_parser/include/urdf_parser/exportdecl.h and knowing that client libraries will not have the URDFDOM_STATIC definition set.
Are you sure this is ok and not causing linking problems?

[jslee02]

You are correct. This cannot resolve the linking problems since the client libraries will not have URDFDOM_STATIC.

There are two possible ways I can think:

• pass the definition set to the client through urdfdom.pc or FindUrdfdom.cmake
• directly config exportedcl.h to define proper preprocessors in the cmake process

I'm not sure which one is preferred way.

Edit: It seems urdfdom.pc is not generated for Windows though.

[traversaro]

I checked how is this implemented in YARP (a library that we use that I am 100% sure that supports building as static library in Windows) and apparently the approach used is the second one that you suggested : https://github.com/robotology/yarp/blob/master/conf/template/yarp_config_api.h.in .
Basically the exportdecl.h equivalent file is configured at cmake time and proper definition is added with a #cmakedefine command.

[jslee02]

Thanks for the guide.

I added distinct config.h file instead of configuring exportdecl.h because I prefer to use config.h file to includes all the definitions configured at cmake time. But I'm fine with using exportdecl.h for if this is not a preferable way to urdfdom.

[traversaro]

I guess your approach is sound. 👍

[traversaro]

By the way I just noticed that in exportdecl.h a strange console_bridge_EXPORTS macro is used

urdfdom/urdf_parser/include/urdf_parser/exportdecl.h

Line 77 in ccc7d2f

# ifdef console_bridge_EXPORTS

... How it is possible that the dll generation works?

[scpeters]

@jslee02 can you resolve conflicts?

[jslee02]

I resolved the conflicts in the latest commit.

console_bridge_EXPORTS seems to need to be specified somewhere. Do we need to add an option for console_bridge_EXPORTS like URDFDOM_STATIC?

[scpeters]

Should console_bridge_EXPORTS be handled by the console_bridge code?

[jslee02]

I think it should be.

One concern is that the definition console_bridge_EXPORTS wouldn't be passed to the client libraries such as urdfdom. So we might need to pass the definition to console_bridge-config.cmake and
console_bridge.pc.in, or create a config.h file in console_bridge and add the definition to config.h.

Alternatively, since URDFDOM_DLLAPI is not used in urdfdom anywhere, so we could consider to remove it.

[scpeters]

console_bridge_EXPORTS is in include/console_bridge/exportdecl.h, but I don't know why it would be in urdfdom. I'm guessing that @thomas-moulard wrote the console bridge exportdecl.h first then did a search and replace with urdfdom and committed in 75078b8, but missed a piece? We should probably replace console_bridge_EXPORTS with urdfdom_EXPORTS

[scpeters]

cc @j-rivero we have a question about a weird console_bridge_EXPORTS symbol

[j-rivero]

I buy Steve's hypothesis about what Thomas did. He was the first implementing packaging for urdfdom and console_bridge.

Makes no sense to me to mix different variable names in an exportdecl file.

[scpeters]

I've submitted #75 to fix console_bridge_EXPORTS

[thomas-moulard]

I am not sure how I introduced this bug but I believe replacing console_bridge_EXPORTS with urdfdom_EXPORTS is the correct solution, sorry for that!