Feature/conan2 #863
Feature/conan2 #863
Conversation
schaubh
added
enhancement
schaubh
force-pushed
the
feature/conan2
branch
2 times, most recently
from
b67b165 to
47ee8da
Compare
|
@dpad , thank for the help creating a build script earlier this summer that worked with conan 2.x. I was able to now upgrade our latest conanfile.py to use the existing build system that supports creating wheels and IDE projects to support conan 2.x. I'm inviting you to look at this branch as well in case you have feedback. I'm making BSK require conan>2.0.5 at this point and dropping support for conan 1.x. I didn't see a need for continued conan 1 support as conan themselves said they are no longer updating conan 1.x packages. @sassy-asjp, you mentioned the urgent need for conan 2 support, so I'm inviting you as well to take a look. My next step is to break up the requirements.txt file into a requirements file for developers to build basilisk, and a requirements file to run the core BSK capability (i.e. if installed via wheel.) |
schaubh
force-pushed
the
feature/conan2
branch
from
47ee8da to
521a433
Compare
schaubh
force-pushed
the
feature/conan2
branch
from
521a433 to
79e8e75
Compare
Only use Xcode default if the user says to not build the project and doesn't provide a generator string. In Xcode 16 there is an issue where Xcode is not finding "python.h". Appears to be a regression. This change in compiling BSK does not impact users using "python conanfile.py", the terminal output is actually easier to read when compiled with makefile, and there are no issues with not finding "python.h".
swig 4.2.1 or great is ok with Basilisk
This issue has been fixed in the current version of conan.
schaubh
force-pushed
the
feature/conan2
branch
from
79e8e75 to
ac4c4b4
Compare
| try: | ||
| subprocess.check_output(["conan", "profile", "new", "default", "--detect"]) | ||
| # XXX: This fixes a linker issue due to the dual C++ ABI. | ||
| subprocess.check_output(["conan", "profile", "update", "settings.compiler.libcxx=libstdc++11", "default"]) |
There was a problem hiding this comment.
@schaubh (This is only minor) Just FYI, this command does not work on Conan2, so this will always fail. There is no conan profile update anymore.
There was a problem hiding this comment.
Howdy @dpad , thanks for the feedback. The Linux CI builds seem to run fine. Are you recommending I remove this Linux specific conan command? It is actually specifying c++11 which doesn't look right to me.
There was a problem hiding this comment.
If I'm not mistaken, with Conan 2, this line will always fail and go straight into the exception, which does nothing. So this line is doing nothing.
There was a problem hiding this comment.
I'll make a branch to remove this dead code. Thanks for the feedback, especially on Linux systems.
There was a problem hiding this comment.
@schaubh The c++11 actually refers to the breaking change specific to gcc libstdc++ ABI implemented for c++11. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
FWIW, I just tried conan profile detect on a Linux VM (Ubuntu 24.04) and it automatically chooses libstdc++11, so even if the command worked, it would be redundant.
|
Good to know @sassy-asjp , thanks for sharing this info. In my PR #872 the CI build worked fine across all the Linux versions that we test against. |
Description
The Basilisk build system was not compatible with conan 2.x. The conan project now is no longer updating conan 1.x recipes.
Verification
The build system works again with conan 2.x installed. All the CI tests passed. Wheels were built and installed with the expected results.
Documentation
The build documentation was updated to say that the latest version of conan can be installed. The release notes were updated. The known issue file has a comment that because conan 2.x uses a new
.conan2folder for the dependencies, the first time this BSK commit is built the conan dependencies are downloaded and installed. This is a one-time action.Future work
Hopefully conan 3.x won't break conan 2.x scripts...