Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#67739 - [re2] Build with cmake so that it provides re2Config.cmake for other cmake-based projects

Attached to Project: Arch Linux
Opened by Massimiliano Torromeo (mtorromeo) - Friday, 28 August 2020, 08:45 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 10 September 2020, 18:56 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

re2 only provides /usr/lib/pkgconfig/re2.pc but while upgrading the grpc package to the latest 1.31.1 release I had to add the "-DgRPC_RE2_PROVIDER=package" flag to make and the build then fails while looking for re2Config.cmake.

re2 can already be compiled with cmake which ends up generating the re2Config.cmake file that grpc needs.

Sadly this ends up not automatically installing the re2.pc file anymore but it's something that is easily fixable since a template is in the source directory and it can be compiled with a simple sed like:
sed 's#@includedir@#/usr/include#;s#@libdir@#/usr/lib#' re2.pc

The inverse task of manually generating a re2Config.cmake while still building with make is not feasible IMO.

Another thing that needs a fix is the versioning of the so libraries. By default only re2.so is installed. The SOVERSION is only specified in the original Makefile.
I used a simple grep to extract the version and then append the required line in CMakeLists.txt.

The final PKGBUILD should be this https://gist.github.com/mtorromeo/1d48de16534dc8ee29cd872f94b070e5

Also a warning on the tests. I noticed that with cmake it seems like there are additional "extensive" tests being run that take a lot of time. They all pass just fine though.
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Thursday, 10 September 2020, 18:56 GMT
Reason for closing:  Won't implement
Additional comments about closing:  re2 upstream contributed cmake detection code to grpc that works with ./configure-built re2. 🎉
Comment by Evangelos Foutras (foutrelis) - Friday, 28 August 2020, 11:03 GMT
Do you want to create a patch for this upstream? I mean the soname version and installing the pkg-config file.
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 28 August 2020, 11:06 GMT
I was going to but they don't use github for merge requests and you have to submit them through https://code-review.googlesource.com/ which I am not familiar with...
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 28 August 2020, 11:09 GMT
I would probably just report the issues upstream and let them fix it. They are simple enough to not need a patch I think...
Comment by Eli Schwartz (eschwartz) - Friday, 28 August 2020, 12:44 GMT
Wouldn't it make more sense for grpc to also check the pkg-config file?

find_package(PkgConfig)
pkg_check_modules(RE2 re2 IMPORTED GLOBAL)

target_link_libraries then uses the PkgConfig::RE2 target.
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 28 August 2020, 14:16 GMT
I would be an alternative solution, sure.

Would it make MORE sense? I don't think so.
I mean, the fact that re2 provides a pkgconfig file if you build it one way and re2Config.cmake if you build it with cmake does not seem right to me.
Comment by Eli Schwartz (eschwartz) - Friday, 28 August 2020, 14:31 GMT
You're right it doesn't make sense, but the conclusion *I* drew from it is that their CMake stuff is not production ready and should not be used. Likely it only exists to ease things for people vendoring it into their cmake project using add_subdirectory, which also explains the hot mess of not providing a soname.

Basically typical cmake garbage...

(If upstream properly supported cmake, then I guess there wouldn't be much harm in using it. But they don't, which seems like a dealbreaker to me.)
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 28 August 2020, 14:58 GMT
The impression I got from both re2 and grpc is that they want to migrate to make but probably cannot make the jump yet (I can only assume for internal integration reasons).

Switching grpc to use cmake was even more of a mess but there were literally parts of the stacks that were not buildable without cmake, which almost suggest that they support more cmake in this case.

The grpc package is already a very complex software to build that I actually managed to clean-up to a reasonable state and I would just strongly prefer not having to patch anything else there.

I realize that this would mean patching this instead but I am not suggesting this to just push the burden on someone else.

If I were the maintainer of both packages I would find it way easier to maintain a patch of re2 rather than in grpc, and, like I said, it also seems the "right" thing to patch to me.

@foutrelis let me know what you want to do here and if I should just patch grpc. I appreciate it either way!
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 28 August 2020, 14:58 GMT
Typo: want to migrate to Cmake
Comment by Evangelos Foutras (foutrelis) - Friday, 28 August 2020, 21:27 GMT
Let's see what upstream thinks: https://github.com/google/re2/issues/274
Comment by Eli Schwartz (eschwartz) - Friday, 28 August 2020, 21:35 GMT
@mtorromeo, seems like at least part of the reason is due to cmake not supporting something like meson's -Ddefault_library=both or autotools' --enable-shared --enable-static.

(Aside: meson actually supports generating cmake config files in addition to pkg-config ones.)

Loading...