wjwwood
commented
6 years ago One thing I'll say about this approach is that relying on generated code to make pretty much all of your headers compilable is annoying in editors that try to do code completion, since you often are working from a source copy and don't have the generated code on your path. On the other hand, if you write this file yourself or generate it once and commit it, then you don't have this problem. My experience has been that these files basically don't change (or if they do they don't need to do so) build to build.
Also, you now need cmake for generating code that is required for your package to compile. This happens in other cases too, but if avoidable is nice to do so because it makes your source stand on it's own better, and for instance if someone wants to rewrite this package to use bazel or pure make they can do that more easily.
Neither of the above are reasons to not use generate_export_headers by themselves, but I think they're worth noting.
ijnek
clalancette
The CMake-3 way to do export symbols (
attribute('default')on Linux,declspec(dllexport)on Windows) is to use a function calledgenerate_export_headers(documentation). The basic pattern would be to put something like this inCMakeLists.txt:which would generate a file called
urdf_export.h. In theory, cmake generates the correct export symbols for the platform. From there,urdf_export.hneeds to be included in each file that needs the export declarations, and the symbols to be exported need to be marked withURDF_EXPORT(this may already be done).