-
Notifications
You must be signed in to change notification settings - Fork 934
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
Provide CPRConfig.cmake to allow easy find_package() #28
Comments
Great suggestion @niklas88, CMake is definitely the build system of choice for this project, and supporting downstream projects easily through CMake is a high priority. |
Hey great seeing you work on this, I just tried using the cpr-config.cmake in my vendoring setting but sadly it failed. I used the following lines to embed it and compiled cpr in it's directory myproject/vendor/cpr:
Cmake somehow has really horrible error reporting:
I can send you the source tree if you like I tried to build a minimal example before integrating it in my other project. |
Hey @niklas88, thanks for giving it a try. If you can link me a github repo that's a minimal example you think should work, that'd help a lot. I'll take a look at this again in the morning. |
Ok, I have prepared my test as a github project https://github.com/niklas88/cprtest |
Have you built the project in the submodule? What were the steps you took in the build. I'm most interested in the root build directory, because that will tell me where to find the path to the cpr library. For instance, if you do an idiomatic build in |
My suggestion is that if you have |
In other words, using |
Yeah I realized building in vendor/cpr/build would create things in the wrong path, I tried vendor/cpr als the build directory too. I thought the first line in
would then set the correct path and at least it finds the cpr-config.cmake because this is what works with the same setup but using netlib-cpp:
|
Gotcha. I think I understand the issue now. I don't set an explicit location for putting libcpr.a. It just shows up in |
If you rebuild cpr from the latest |
@whoshuu ok we are definitely making progress. This is definitely an improvement, also sorry I missed adding the rapidjson header only library to the git project. Now it looks like the libcurl symbols aren't available through libcpr.a see this error output: If I link with my system libcurl (I'm on Arch and it may or may not be the same version) the executable works |
Yeah see my note about libcurl in this comment. I don't compile the curl sources into libcpr, so you still have to manually link libcurl to your project. This can be avoided if you use |
It's possible to manually add |
But then one would have to make sure that cpr uses the system library as well and not it's local clone so that non-matching versions are easier to discover. Personally I prefer linking with system libraries when available because that means one gets security updates to dynamic libraries but that might not be common on non Linux systems. |
There's something to be said for having defaults that almost never fail, and allowing customization beyond that for options that may fail. In my experience, libraries which have no external dependencies are highly preferred -- they're the easiest to get up and running, and C++ is notoriously bad at supporting plug and play libraries. While I sympathize with your concern, the most important thing for me is to encourage using submodules as the first choice for library integration. This method will have first-class support. If the library is built separately and included later, extra care must be taken by the integrator to make sure the dependencies are compatible, and I am perfectly okay with this. The library is pretty explicit about which dependencies are used from where, though the documentation could use some work with regard to build options. I'll note this and make a separate issue to address that. For now, I'm going to limit the scope of this issue to simply having a working |
Sorry for the delay I'm a bit busy working on my masters thesis. I can confirm it does indeed work wonderfully with my test project now, great work! |
I do not want a submodule. apparently the proj i am working on has all compiled deps system wide and i do not want just this perticular library as a submodule. Trying to install system wide:
From the root of the project:
Gives me an error:
|
I'm all but a cmake expert but if I interpret this
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages
link and my cmake output correctly, supplying CPRConfig.cmake
would allow downstream projects to include cpr as a dependency like this:
and then use ${CPR_LIBRARIES} in target_link_libraries(). Instead of vendoring it could also be installed in the system path getting rid of the first line in the snippet above.
The text was updated successfully, but these errors were encountered: