cmake: Install cmake files in a more common path

[diizzyy]

Install cmake files in prefix/lib/cmake/pcre2 rather than prefix/cmake

[alexreinking]

As long as you're making a change like this, you might as well make the path configurable via a cache variable like PCRE2_INSTALL_CMAKEDIR. For example (sketch):

include(GNUInstallDirs)

set(PCRE2_INSTALL_CMAKEDIR "${CMAKE_INSTALL_LIBDIR}/cmake/pcre2"
    CACHE STRING "Relative path to PCRE2's CMake config files from the installation root")

install(
    FILES ${PCRE2_CONFIG_OUT} ${PCRE2_CONFIG_VERSION_OUT}
    DESTINATION "${PCRE2_INSTALL_CMAKEDIR}"
)

I go into a lot more detail on CMake packaging on my blog here: https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html

[zherczeg]

Is this still valid/needed?

[alexreinking]

Is this still valid/needed?

Yes, it looks like a change along the lines of my suggestion above would be a good one.

https://github.com/PCRE2Project/pcre2/blob/db95416ee87a7abc49b7856f806a1b48f901756d/CMakeLists.txt#L1135

[NWilson]

I am curious what your use-case is for "make install". Personally, it would never occur to me to use it for a library.

I mean, for a binary perhaps: you might want to check it out, build, and install it to ~/bin or /usr/local/bin, but a library? Who installs a library like that? Libs will come packaged by the OS (on Linux) or bundled by an application that builds in the library using its own toolchain.

I have never done a "make install" for a library, so I just don't understand the purpose of it.

In principle though, I think we'd be happy to go along with any suggestions users have.

[PhilipHazel]

@NWilson - More History! When PCRE was new, the only way to install it was "make install". It was only after it started to get widely used that distros started packaging it. So I guess you have never wanted to install an uncommon library. :-)

[NWilson]

If I were writing an Apache httpd plugin using PCRE (for example), and there wasn't a PCRE2 bundled by the OS, then I'd statically link it in.

That probably comes from my background shipping commercial software on Unix platforms. The apps are always shipped with dependencies included, so you don't get support requests from users on different Linux distros. I can see that the open-source way probably would instruct users to fetch and install the library globally, outside of the OS packaging system.

Things have moved on maybe. These days, open-source packages for Linux seem to be either bundled by distros, or the upstream project provides an apt/RPM feed of their own, or they provide a build with dependencies statically linked - precisely to avoid the hassle of incompatible library versions on the user's system.

[carenas]

If I were writing an Apache httpd plugin using PCRE (for example), and there wasn't a PCRE2 bundled by the OS, then I'd statically link it in.

That is very common in Windows but not so in Linux or the BSD.

Note that the OP is the FreeBSD packager for PCRE2, and they had (IMHO) mistakenly moved to use cmake instead of autotools to deploy those system wide.

[PhilipHazel]

Early versions of PCRE were indeed bundled with Exim because PCRE was then an unknown library, but I stopped doing that once other software started to use PCRE and needed a properly installed separate library.

[diizzyy]

Is this still valid/needed? Can also confirm that it is