Ideally, tf2_ros should also export tf2_msgs as dependencies.
in the CMakeLists.txt

ament_export_include_directories(include)
ament_export_libraries(${PROJECT_NAME})
ament_export_dependencies(tf2_msgs)

We also need this constructor for the StaticTransformBroadcaster btw.

I filed another PR for my changes and rebased on top of this one.
#204

The non-static TransformBroadcaster should initiate the publisher to tf. Right now it also does publish to tf_static

What's the current state of this PR? Can we merge this soonish? I'll open a bunch of PRs in the near future for the robot_state_publisher, which relies on that PR.

@Karsten1987 I should be able to finish this tomorrow.

ec04e3e fixes the topic name in the non-static broadcaster.

http://ci.ros2.org/job/ci_linux/2315/
http://ci.ros2.org/job/ci_osx/1770/
http://ci.ros2.org/job/ci_windows/2344/

Windows is sad about linking:

21:55:18     15>LINK : fatal error LNK1181: cannot open input file 'Release\tf2.lib' [C:\J\workspace\ci_windows\ws\build\tf2\test_static_cache_unittest.vcxproj]

http://ci.ros2.org/job/ci_windows/2344/consoleFull

After debugging with @tfoote, the underlying problem appears to be a lack of visibility macro usage in the library. When no symbols are explicitly exported, the Windows linker doesn't bother producing a tf2.lib.

I'll add in visibility control as we've done in the other packages (won't get to this until next week).

tf2.lib implies a static library, is that on purpose? Or do you want to build a .dll ?

Previously the tf2 lib was being built static. Part of this PR switches it to by shared, for two reasons:

1. That's generally what we do.
2. I had linking problems on Linux trying to use the static lib.

In retrospect, my linking problems likely could have been addressed by modifying tf2 to export more dependencies. But I think that making it work as a shared lib is the better answer.

[My understanding of Windows linking is poor at best, so I might be wrong here:] The problem now is that because tf2 doesn't explicitly export any symbols using the usual declspec boilerplate, the linker does build the tf2.dll, but decides not to produce the tf2.lib file that usually accompanies the DLL. The LIB is the one containing the exported symbols, and its absence is causing the link step to fail when you try to use the library. The current approach works on Linux because the default is to export everything in a shared lib (we could change that default with appropriate linker flags if we wanted), while on Windows the default is to not export anything.

So the fix, I believe is to:

1. Add a file like this that provides appropriate macros for controlling symbol visibility.
2. Go through the API and use those macros appropriately.

That's what I'm planning to do.

I failed to correctly operate git, so I created a new branch fix_build2 with the same changes and opened a new PR #208. Let's continue there.