With this, I could succcessfully compile on win32 (with Visual Studio) a package generated on Linux.
The only caveat so far is the lack of dependency support. It is a major change in how the generation happens. There are now no symbolic links left in the generated code. The symbolic links were designed to provide a "fake" include tree, which is now generated at configuration time instead. Moreover, the messy recursive links are replaced by a proper include tree generated under e.g..orogen/typekit/__include_dir__.
@meyerj: this most likely breaks typegen. I've started a rock build test suite, which builds various packages and can run post-build validation tests. If you want, you could put on GH some CMake packages that check the typegen support from RTT's macros, I would include them in the same build tests.
Depends on:
With this, I could succcessfully compile on win32 (with Visual Studio) a package generated on Linux. The only caveat so far is the lack of dependency support. It is a major change in how the generation happens. There are now no symbolic links left in the generated code. The symbolic links were designed to provide a "fake" include tree, which is now generated at configuration time instead. Moreover, the messy recursive links are replaced by a proper include tree generated under e.g.
.orogen/typekit/__include_dir__.@meyerj: this most likely breaks typegen. I've started a rock build test suite, which builds various packages and can run post-build validation tests. If you want, you could put on GH some CMake packages that check the typegen support from RTT's macros, I would include them in the same build tests.