Broken logic in FindMINIZIP.cmake

[hosiet]

We look into what FindMINIZIP.cmake does:

libxlsxwriter/cmake/FindMINIZIP.cmake

Lines 92 to 95 in f43e53e

	if(MINIZIP_FOUND)
	file(STRINGS "${MINIZIP_INCLUDE_DIRS}/zlib.h" MINIZIP_VERSION_CONTENTS REGEX "Version [0-9]+\\.[0-9]+(\\.[0-9]+)?")
	string(REGEX REPLACE ".*Version ([0-9]+)\\.[0-9]+" "\\1" MINIZIP_VERSION_MAJOR "${MINIZIP_VERSION_CONTENTS}")
	string(REGEX REPLACE ".*Version [0-9]+\\.([0-9]+)" "\\1" MINIZIP_VERSION_MINOR "${MINIZIP_VERSION_CONTENTS}")

When enabling USE_SYSTEM_MINIZIP and system libminizip is found, these lines basically look through system's /usr/include/zlib.h and look for strings like Version [0-9]+\\.[0-9]+(\\.[0-9]+)?.

---

However, the zlib.h header never had such lines:

-> % cat /usr/include/zlib.h | grep Version
#define zlib_version zlibVersion()
ZEXTERN const char * ZEXPORT zlibVersion OF((void));
/* The application can compare zlibVersion and ZLIB_VERSION for consistency.

This condition actually applies to all recent zlib releases.

I believe the logic in FindMINIZIP.cmake must be broken somewhere. Can you take a look?

[jmcnamara]

Thanks. I'll take a look.

[jmcnamara]

There was a "Version/version" typo in the regex that prevented FindMINIZIP.cmake from reporting the library found even if it was. I fixed that and the compilation works on macOS and Ubuntu 22.04. I want to do a bit more digging to see why this didn't turn up in the past since that code has been there since 2017 (maybe cmake behaviour has changed?).

Anyway, if you get a chance can you test main to see if it works on your OS.

[jmcnamara]

I think I found the reason this didn't fail before. It was due to another change/fix in #398.

Anyway, the good news is that the CI is passing again so I'm going to close this.