[illwieckz]

So before this PR,

• by default zlib was enabled, without any option to disable it.
• by default zstd was disabled, with an option to enable it.

We may not need zlib, we did not need it before, so we may want to be able to disable it:

• New Breakpad requires zlib Daemon#2012

When adding an option disable zlib, I would prefer that both zlib and zstd related options to be similar not confusing, so basically, not having one being enabled by default with a --disable option while the other is disabled by default with a --enable option.

So configure now enables both zlib and zstd by default but provides --disable-zlib and --disable-zstd options.

Picked from:

• Implement the CI in GitHub Actions #37

[slipher]

Optional zlib support in the headers and in the autoconf script should be a single commit because either commit would be broken without the other.

I don't favor making zstd enabled by default: seems annoying for us who presumably don't care about it, and it adds a needless difference against upstream.

[illwieckz]

Optional zlib support in the headers and in the autoconf script should be a single commit because either commit would be broken without the other.

Well, actually one could invert the commits and don't break the build, but then first commit would have disable zlib before the next commit re-enabling it. Now squashed.

I don't favor making zstd enabled by default: seems annoying for us who presumably don't care about it, and it adds a needless difference against upstream.

OK, so we have --disable-zlib and --enable-zstd. I still kept a commit rewording --enable-zstd the more idiomatic way.

About “it adds a needless difference against upstream”, I doubt upstream care about the autogen build anymore.

[illwieckz]

I doubt upstream care about the autogen build anymore.

Well, it looks like the only build system they have is autogen in their branch:

• https://chromium.googlesource.com/breakpad/breakpad/+/refs/heads/main/

There is no trace of any GN thing or things like that. Maybe the stacktrace generator is built as part of another project (like we do), but they likely never test the rest! I guess that explains why they uploaded some windows binaries in the repo, they may not know how to build them…

[illwieckz]

Hmm, actually, I'm doing some rework on the zstd thing, it doesn't work on some platforms (not found even when installed).

[illwieckz]

So, I noticed that zstd required pkg-config to be found on some systems (namely, macos-arm64). So I implemented it, as a fallback when direct linking doesn't work.

Just in case, I gave the same care to the zlib enablement (lib test first, pkg-config then, but only then).

I also fixed something I forgot in the first iteration of the PR: to not link against zlib. Zlib is almost everywhere, so even when the headers are not installed, it's very likely the library is there and the build would have succeeded, but there is no need to pass that link flag.

[slipher]

Chromium stopped using Breakpad crash generation years ago so it make sense there is no GN. ChromeOS might still be using it which would explain why it is maintained at all?

[illwieckz]

I forgot to mention it, but that also fixes that mistakes of those CFLAGS used instead of linker flags .