Skip to content
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

CMake install does not substitute or install the pkgconfig file #349

Closed
AdamWill opened this issue Jan 10, 2022 · 6 comments
Closed

CMake install does not substitute or install the pkgconfig file #349

AdamWill opened this issue Jan 10, 2022 · 6 comments

Comments

@AdamWill
Copy link

If you do a CMake build/install of re2 on *nix, nothing substitutes @includedir@ and @libdir@ in re2.pc, or installs the file. This only happens in a Makefile-driven installation.

@junyer
Copy link
Contributor

junyer commented Jan 11, 2022

This has come up every so often and in varying ways, but this comment and this comment might be the most relevant to you. It still seems to me that CMake is unsuitable for packaging RE2, unfortunately, but the latter comment will hopefully help you. If there's a solution nowadays to the problem noted in the former comment, please let me know to reconsider my position. :)

@junyer junyer closed this as completed Jan 11, 2022
@AdamWill
Copy link
Author

Thanks. Well, I am a package maintainer (for Fedora). In Fedora at least, building and shipping static libraries is explicitly discouraged, so that's not an issue at all.

I ran across this because our re2 maintainer switched from Makefile to CMake building and inadvertently, uh, broke the entire distribution, so I was cleaning that up. The given reason for switching to CMake was "I'm in the preliminary phase of adding apache ORC and apache arrow. Both build with cmake only, and both need cmake style pkg info in/usr/lib*/cmake/re2/*". Presumably in order to switch back to Makefile building, if that's preferred, we'd need some solution for building those two things.

@AdamWill
Copy link
Author

Oh, thanks for the reference to the make common-install trick. For now I just re-created the sed substitution the Makefile does in the spec file, but that might be a better solution. Do you know what the other things that don't get installed with CMake are? The phrase "everything else" implies there may be more than the pkgconfig file...

@junyer
Copy link
Contributor

junyer commented Jan 12, 2022

With Makefile: static-install installs libre2.a; shared-install installs libre2.so; and common-install installs the .h files and re2.pc.

With CMakeLists.txt: install installs libre2.so (when BUILD_SHARED_LIBS is true), the .h files and re2Config.cmake. (cb5bbb2 added re2ConfigVersion.cmake, but isn't in a tagged release yet.)

A while back, I helped gRPC folks (and package maintainers) by contributing Findre2.cmake, which attempts to find RE2 via CMake and via pkg-config. Is that an approach that would work for your use case as well?

@AdamWill
Copy link
Author

Thanks. I guess it would, but we'd need to patch them into the apache projects downstream and ideally get them merged upstream. Since the only thing we need to 'fix' when using CMake to install re2 seems to be the pkgconfig file, I guess we'll just stick with the CMake approach for now. It seems like fixing the pkgconfig made everything that builds against it happy again.

@junyer
Copy link
Contributor

junyer commented Jan 13, 2022

I was thinking more in the sense of trying to package Findre2.cmake on its own, but what you have now is a simple, effective solution, so if you're happy, then I'm happy. :)

bkuhls pushed a commit to bkuhls/buildroot that referenced this issue Feb 13, 2022
The cmake build appears to be missing features, such as pkg-config
generation support which is needed for some packages to find re2, like
qt5webengine.

Upstream is not keen on fixing the CMake-based buildsystem [0]

Instead of patching it on our side, and then have to carry the patch
forever, we switch to the Makefile-based generic buildsystem.

Note that previously some packages like grpc failed when the generic
Makefile was used, because they would not find the cmake-equivalent
of pkg-config, but this is now fixed [1].

[0] google/re2#349
[1] grpc/grpc@45e413d

Signed-off-by: James Hilliard <[email protected]>
[Peter: Reword commit message as suggested by Yann]
Signed-off-by: Peter Korsgaard <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants