cmake: Don't forcibly export C++ version#52
Conversation
|
Travis reports a compile error: |
|
Another option would be to set public |
|
Rats. It looks like now the C++ version isn't being set to 11 when it should be. The problem with using I've tried tweaking it to see if this fixes things. |
|
Ok, got it on the third attempt! It seems that Travis wasn't correctly setting the C++ version for gcc -- not sure why (it's a new version of cmake but an old version of gcc so maybe that's the problem). So now we set the C++ version in two ways, which is a bit gross, but at least works and solves the original problem. |
CMakeLists.txt
Outdated
| # CMake on Travis seems not to be setting the C++ version correctly, even | ||
| # when specified as below (maybe because it's an old version of gcc?). So | ||
| # let's set this as a private compile option for a belt-and-braces approach. | ||
| target_compile_options(ev3dev PRIVATE -std=c++0x) |
There was a problem hiding this comment.
Are you sure it is safe to compile the library with c++11 and then link it with the code that was compiled with c++14? Are there no ABI incompatibilities?
There was a problem hiding this comment.
I don't think there should be (C++ is supposed to be backwards compatible with this kind of thing...) and it does work for me.
Also it's quite a common thing to do: lots of C++ libs are compiled for C++11 but you can still link against them with programs using newer versions of C++.
|
I did a quick test in 11c2063, and it seems that just defining https://travis-ci.org/ddemidov/ev3dev-lang-cpp/builds/524885989 So may be there is no need to test for |
|
Sorry, forgot to also remove |
|
That would be cleaner, but I believe |
|
Looks like Debian stretch (the current distribution used by ev3dev) has cmake 3.7: https://packages.debian.org/stretch/devel/cmake so bumping the required version to 3.1 should be ok. |
|
That all looks good to me. I've tested it with my project and now it works fine. Cheers :-) |
|
Can you update this PR so I can merge to master? |
|
Done :-) |
|
Thank you! |
|
Thanks for being so responsive. |
This PR fixes issue #51, if the user has cmake v3.1 or newer, which is almost certainly most users.
For older versions of cmake there doesn't seem to be a nice way to check if the user has already specified a C++ version, so I have preserved the old behaviour where the C++ version is also set for any parent projects.