cyclonedds-cxx
cyclonedds-cxx copied to clipboard
eclipse-cyclonedds
Add config option to skip idlcxx building if crosscompiling
Skip idlcxx module building if crosscompiling. A native one should be used in that case.
Signed-off-by: Matija Tudan [email protected]
This is somewhat similar to #183, but it also has some support in the Generate.cmake. Can you explain what the idea is? If cross compiling to include the native generator with the cross-compiled lib? @k0ekk0ek is that what you have in mind? It would make sense to not include it as well (in my use case I have to support multiple native and multiple "cross" architectures, so it doesn't make sense to bundle any one with the other, just have them separate).
Like @k0ekk0ek mentioned in https://github.com/eclipse-cyclonedds/cyclonedds-cxx/pull/183, the idea was to implement the same thing like in cyclonedds repo (commit a614bdebe0626326bad2d40e84adba937ec42a8f).
But, after discussing with @eboasson in https://github.com/eclipse-cyclonedds/cyclonedds-cxx/pull/191, we will implement more generic function in cyclonedds repo and use it in this C++ repo. So, this PR (https://github.com/eclipse-cyclonedds/cyclonedds-cxx/pull/189) will probably be closed and not merged in favor a new one. Which also means that your PR https://github.com/eclipse-cyclonedds/cyclonedds-cxx/pull/183 will probably be merged.
Combining them may not be the best way forward. I previously thought about the same thing but C++ is really different from C. I'm happy to review or provide input of course, but back then I thought it would introduce more problems then it solves. An example: C++ currently only generates a header, not a source file and a header like C. I know that'll change when X-Types lands, but still. Other than that, without having properly reviewed it yet, this seems like what I had in mind.
C++ currently only generates a header
This is not true anymore (after https://github.com/eclipse-cyclonedds/cyclonedds-cxx/pull/178 is merged). I'm hoping it's on the final straight :)
To be fair, about the C++ generation (and about idlc supporting multiple languages), it makes sense most options to be "bookkeeping" and apply to all languages, and if there are language-specific options it makes a lot of sense for them to be prefixed with the language (like --cxx-XXXXX ,or --python-XXXX or --c-XXXXX), so it is easy for plugins to list options that don't collide with other plugins, and easy for the base idlc to figure out which options go where.
Update: If at a later point some language-specific options are found to be present across multiple languages, then a 2nd variant --lang-XXXX that just means "pass to the respective language" can be used. But only if that is the case, currently there are no options (and it makes sense to keep options to a minimum).
Hi @ichernev, that's actually sort-of how it's implemented already. Options that apply to the parser or all backends are kept by the compiler, each backend can then add options (and annotations) that apply only to that backend. e.g. the C++ backend supports the use of custom containers for unions etc.
Excuse me, how did you compile the cross-compilation? I didn't find any relevant information.
