CMake dependencies _FOUND tests are wrong. CMake variables are case sensitive

[HekyM]

Hi,

You are using CMake find_package(<PackageName> ...) to find dependencies. Based on documentation https://cmake.org/cmake/help/latest/command/find_package.html#basic-signature this call will define <PackageName>_FOUND variable.

find_package(BZip2)
find_package(ZLIB)
find_package(Readline)
find_package(Editline)

But later in pcre2 CMakeLists.txt, these are used as <PACKAGENAME>_FOUND (uppercase). CMake variables are case sensitive.

So for example find_package(BZip2) will define BZip2_FOUND, not BZIP2_FOUND as You use for example here https://github.com/PCRE2Project/pcre2/blob/master/CMakeLists.txt#L501C6-L501C17. So it will raise a FATAL_ERROR.

if(PCRE2_SUPPORT_LIBBZ2)
  if(BZIP2_FOUND)
    include_directories(${BZIP2_INCLUDE_DIR})
  else()
    message(
      FATAL_ERROR
      " libbz2 not found. Set BZIP2_INCLUDE_DIR to a compatible header\n"
      " or set BZip2_ROOT to a full bzip2 installed tree, as needed."
    )
  endif()
endif()

Here is how CMake builtin finder for BZip2 works https://cmake.org/cmake/help/latest/module/FindBZip2.html#result-variables

[carenas]

So it will raise a FATAL_ERROR.

on a macOS system (which provides bz2 as part of the base system), and using the defaults (which link pcre2 statically) I see:

% cmake -B build
...
-- Found BZip2: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libbz2.tbd (found version "1.0.8")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
...
--   Link pcre2grep with libbz2 ........ : ON
% otool -L build/pcre2grep
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)

which seems to be the same behaviour we always had (at least when compared with the last 2 versions).

do you see anything different or a regression?

[carenas]

looking at the documentation you provided, I see that cmake 4.2 (which hasn't been released yet) will be deprecating the alias, so I guess this will break on that release and you are an early adopter?

BZIP2_FOUND

    Deprecated since version 4.2: Use BZip2_FOUND, which has the same value.

[HekyM]

No, I'm not refering to deprecation in CMake 4.2. But that's another reason I missed.

I'm refering to find_package function https://cmake.org/cmake/help/latest/command/find_package.html#basic-signature

find_package(<PackageName> ...)

Regardless of the mode used, a <PackageName>_FOUND variable will be set to indicate whether the package was found.

and

In this mode, CMake searches for a file called Find<PackageName>.cmake ...
In this mode, CMake searches for a file called <lowercasePackageName>-config.cmake or <PackageName>Config.cmake. ...

As you can see <PackageName>_FOUND is result variable of find_package function, Its <PackageName> prefix is what you use in find_package(<PackageName>) - Case Sensitive.

So all your find_package calls for BZip2, Readline, Editline are later tested with wrong _FOUND variable. It was always wrong.
Depricated BZIP2_FOUND exists only for compatibility reasons, I beleave.

Reason why BZIP2_FOUND exists, I suppose, is because on windows you can use find_package(BZIP2) and it will works and actually create BZIP2_FOUND variable. But it should not work, because it will then search for FindBZIP2.cmake insteand of FindBZip2.cmake. Reason why it works is because windows filesystem itself is case insensitive. If you try same on macOS or Linux, it will fail.

[NWilson]

Thank you for reporting this.

Are actually observing any problems in practice, or any regressions in 10.47 compared to 10.46?

I can see that the correct variable name is <PackageName>_FOUND, but it appears that CMake sets a <PACKAGENAME>_FOUND variable as well, so things are currently working (for me).

I guess we should fix this for the next release, but if it is working as it is presently, then it isn't too serious.

[HekyM]

tbh, I'm a bit confused why builin finder in cmake <3.30 has only UPPERCASE variables https://cmake.org/cmake/help/v3.29/module/FindBZip2.html#result-variables

Because I thing find_package works always the same to create <PackageName>_FOUND

[NWilson]

I believe the find_package function itself sniffs to see what variables have been defined by the find-module itself; deduces whether the search succeeded; and then sets all the versions of the output variables itself.

[HekyM]

For context, I try to build pcre2 using conan package manager https://conan.io/center/recipes/pcre2?version=10.44

It not yet support version 10.47, but I try to update it and it starts failing because you add FATAL_ERROR. So it was always failing, but silently.

Conan not using builtin cmake finder, but own generated Config.cmake that has not that UPPERCASE compatibility.

I now understand why your BZIP2_FOUND works. But are you sure Readline, Editline also works? You have you onw finders in cmake/. Maybe I missing something.

I can't test it right now, but I beleve find_package always create BZip2_FOUND in your case, you just use the one created by finder.

At least you know when it stop working with cmake 4.2.

[NWilson]

I see! Does it work if you edit our CMake script to use "BZip2_FOUND" rather than "BZIP2_FOUND" (and similarly for the others)?

If you can confirm that fixes the issue, that would be helpful. I haven't ever used Conan.

[HekyM]

I use it only with BZip2. But yes, it works with simple "search & replace" BZIP2_FOUND -> BZip2_FOUND in your CMakeLists.txt.

[carenas]

I see that cmake 4.2 (which hasn't been released yet) will be deprecating the alias, so I guess this will break on that release and you are an early adopter?

FWIW, I tested with the cmake 4.2-RC1 in multiple systems with case sensitive filesystems and still doesn't break.

I also get the impression that the fact that older cmake versions ONLY set an all uppercase variable as stated above, and the fact that we support (and AFAIK are testing in CI) with 3.15 would indicate that blindly changing the case of those variables might not be the right solution.

[NWilson]

Hmm. So there are a couple of places where it could be relevant:

• Inside our own two find-modules (Readline and Editline), we call FindPackageHandleStandardArgs. This clearly sets both <PackageName>_FOUND and <PACKAGENAME>_FOUND, and has consistently done so in both 3.15 and 4.2:

  https://gitlab.kitware.com/cmake/cmake/-/blob/v4.2.0-rc1/Modules/FindPackageHandleStandardArgs.cmake?ref_type=tags#L661
  https://gitlab.kitware.com/cmake/cmake/-/blob/v3.15.7/Modules/FindPackageHandleStandardArgs.cmake?ref_type=tags#L384

• Then there are the two CMake-supplied find-modules, FindZLIB and FindBZip2. These also call FindPackageHandleStandardArgs

  https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindZLIB.cmake
  https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindBZip2.cmake

So, on exit from all four of the find-modules, we can guarantee that <PackageName>_FOUND and <PACKAGENAME>_FOUND are both being returned to the calling context.

However, what is that calling context? The find_package command is actually implemented in native C++ code. As far as I can tell, it basically "sources" the find-module files (rather than calling them in a child scope), and so whatever they return is just splatted up to the caller, rather than being cleaned up in a scope.

So, I believe that all the variables set by FindPackageHandleStandardArgs should be available in CMakeLists.txt.

Looking at the source:

https://gitlab.kitware.com/cmake/cmake/-/blob/v4.2.0-rc1/Source/cmFindPackageCommand.cxx?ref_type=tags#L1075

I see that in a few places the C++ code checks for either of original/upper case _FOUND being set. But it's not consistent. I would want to guess what would happen if a find-module were to set only the upper-case version (we set both, so it's fine).

It's also possible that Conan (or vcpkg) override the find_package or integrate with it in some special way however, so I don't know if we can assume that Conan handles the invocation and propagation of the find-module's results in the same way.

---

I basically think that switching to <PackageName>_FOUND conforms to the docs for 3.15, works with 3.15 and 4.2, and so we should probably just do it; it's more likely to work.

[NWilson]

Anyway - I'm curious why you need BZip2 (or Zlib, or Readline, or Editline) to work.

These libraries are not used by any of the exported PCRE2 functions. Clients importing PCRE2 as a dependency into their product should just set all of these to not-found/don't-care. The pcre2grep and pcre2test utilities make use of them... but anyone building a product depending on PCRE2 will be calling the library, not those tools. And if someone does want to build those utilities, then I guess as a workaround they can just build PCRE2 using CMake, standalone, rather than building those utilities as part of some containing workspace.

I'm not saying it's wrong to want to build those utilities via Conan.. but it's probably a rather rare requirement.