-
-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Adds conan support via a conan 2.0 recipe #1066
Conversation
✅ Deploy Preview for dpp-dev ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…into conan_support
… CMakeLists.txt, root CMakeLists now detects conan and uses its cmake if detected
a5aa313
to
0b193a1
Compare
…CE_SUPPORT by default
0b193a1
to
ffa9cd5
Compare
Can we automate the versioning to match the |
I've also added the "Help Wanted" label on this PR for anyone who wants to test the conan recipe (more specially on Windows). Like you said, we need people to test the conan recipe so asking for people to join in and test is ideal. |
-1073741819 is error C0000005 which is like a segmentation fault. |
any movement on this? |
Renamed PR to correctly align with our conventions. |
I'm going to run some tests on this PR for windows, just to make sure it all works. |
Even with the suggested changes, it appears Conan just can't find D++ (despite all the files being there and cmake loading all the variables). I end up getting:
As far as I understand, it's a Conan bug? I could be super wrong but I really don't understand. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest using the test_package
functionality that can test automatically the package when created with conan create .
cmake.install() | ||
|
||
def package_info(self): | ||
self.cpp_info.libs = ["dpp"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As commented in conan-io/conan#15985 (comment) this might need more info, as the folders generated in cmake.install()
are not matching the defaults.
library-conan/conanfile.py
Outdated
default_options = {"shared": False, "fPIC": True} | ||
|
||
def build_requirements(self): | ||
self.requires("nlohmann_json/3.11.2", headers=True, libs=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
headers=True, lib=True
is the default, it is recommended to drop them and use self.requires()
tc.cache_variables["CONAN_EXPORTED"] = True | ||
tc.cache_variables["BUILD_VOICE_SUPPORT"] = True | ||
tc.cache_variables["DPP_BUILD_TEST"] = False | ||
tc.cache_variables["BUILD_SHARED_LIBS"] = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is always going to be a static library, then better drop the shared
option and declare package_type = "static-library"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this one is an odd one, we normally don't allow static but for some reason, trying to build shared results in ZLib linking twice.
I do believe we would like to build as a shared library (as this is what we do normally) but, as seen, are kinda forced into static due to ZLib shenanigans.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be in Conan 1.X, that it was overlinking (propagating too much linkage requirements). In theory, Conan 2 with the right traits/package_type, Conan should avoid this overlinking, and allow shared builds to encapsulate zlib static libs as implementation detail if desired. Feel free to submit new tickets to Conan repo for further details or discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be in Conan 1.X, that it was overlinking (propagating too much linkage requirements). In theory, Conan 2 with the right traits/package_type, Conan should avoid this overlinking, and allow shared builds to encapsulate zlib static libs as implementation detail if desired. Feel free to submit new tickets to Conan repo for further details or discussion.
Sorry for the delayed reply, the zlib issue has been a thing as long as Mike has been trying to make this PR (I mentioned it in the issue that I posted on the conan page too!). When I then tested this PR a few days ago, it was still persisting on Conan 2.2.2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be great to isolate this issue, create a ticket for it in the Conan repos (hopefully with something that we can reproduce on our end) and investigate this properly.
message("-- INFO: Conan detected... finding packages") | ||
find_package(OpenSSL REQUIRED COMPONENTS SSL Crypto) | ||
find_package(ZLIB REQUIRED) | ||
find_package(libsodium REQUIRED) | ||
find_package(Opus) | ||
find_package(Threads REQUIRED) | ||
find_package(Git QUIET) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that using Conan might need some find_package()
that maybe are not used when not using Conan because some other strategy like FetchContent
is done, but why the big CMakeLists.txt and all the code below? In theory Conan can integrate quite cleanly, without requiring modifying CMakeLists code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We wanted the CMakeLists.txt to be separate (see library-vcpkg), this is just something we do with VCPKG so we wanted the same format to follow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should also be noted, our main CMakeLists.txt doesn't do everything hence why we have library/CMakeLists.txt
, library-vcpkg/CMakeLists.txt
, and now library-conan/CMakeLists.txt
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is a bit unexpected to me is that such a file wouldn't be way shorter, at least for Conan. Besides some potential minor differences in the dependencies (like the above commented possible find_package()
vs FetchContent
). So it shouldn't be necessary much different logic to build the project. There are full blocks of CMake code in library-conan/CMakeLists.txt
that are completely unrelated to Conan, and also seem completely unrelated to dependencies too, basic definition of the library like globbing files, handling compiler flags, etc. So I would expect that this would be common CMakeLists.txt, and the specializations for vcpkg or Conan would be way more minimal.
Am I missing something here?
If you need some other advice or help to move this forward, please let me know, I can keep reviewing and advising. Thanks! |
Hi there, sorry for the late reply, cheers for the shout! I'll be looking to pick this up again very shortly so I'll give you a shout if needs be, thanks for the help so far! |
This pull request has had no activity and is being marked as stale. If you still wish to continue with this pull request please comment to reopen it. |
is there any progress with this? |
This pull request has had no activity and is being marked as stale. If you still wish to continue with this pull request please comment to reopen it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all the cmakelists in here are now completely invalidated by the changes for DAVE and removal of libsodium. If we do proceed with this, it will need to be completely redone. I recommend closing this PR and making a new one.
Co-authored-by: James <[email protected]>
Co-authored-by: James <[email protected]>
This is being closed in preference of a new pr which is hopefully simpler. |
I went ahead and tested the conan package on macOS and linux with example programs(using conan). I also tested the existing build procedure on macOS to make sure I did not break anything. I did no testing on Windows as I do not currently have a Windows development machine ready for use.
I would personally like to see more testing done on other users machines before a package is submitted to the conan center.
A review of my CMakeLists.txt changes also is not be a bad idea since I will admit I am not a CMake expert.
How does versioning work? I used 0.1 as a placeholder until I got feedback.
Thanks!
Code change checklist