make generation on linux and compilation on win32 possible #105
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…HECK This makes it easy-ish to generate at one point and then compile the package as a CMake package somewhere else.
…RGETS CMake 3.9 on Windows complains otherwise
The symbolic links are not portable towards Windows, and are actually not needed at compile time (apart from polluting the namespace). Create them at build-time in a cross-platform way (using mklink on windows).
We don't need them in Rock because we have base/orogen/std. Disable it only on win32 for now as win32 is a new (and alpha) platform, so we won't break anything
It currently causes trouble at link time.
The include path was relative to the package root instead of relative to the __include_dir__ fake install dir. This was due to user_options taking precedence if both options and user_options have a value and it is not an Array Handle :include explicitely instead
The old code was full of weird assumptions that have been made at least partially obsolete by the latest changes. Update the codegen.
This was referenced Oct 31, 2017
One major improvement is that the full-to-include mapping is saved in the pending_loads array, instead of re-guessing what had already been guessed in #load. Other than this, it's basically cleaning up the mess little by little
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.