Fix #if/#ifdef confusion, detected by -Werror=undef

[dfaure-kdab]

(yes, same commit title as commit fcda088)

[krf]

To avoid the confusion maybe one should also do:
target_compile_definitions(libhotspot-perfparser PRIVATE HAVE_DWFL_GET_DEBUGINFOD_CLIENT)
instead of:
target_compile_definitions(libhotspot-perfparser PRIVATE HAVE_DWFL_GET_DEBUGINFOD_CLIENT=1)?

[dfaure-kdab]

To avoid the confusion maybe one should also do: target_compile_definitions(libhotspot-perfparser PRIVATE HAVE_DWFL_GET_DEBUGINFOD_CLIENT) instead of: target_compile_definitions(libhotspot-perfparser PRIVATE HAVE_DWFL_GET_DEBUGINFOD_CLIENT=1)?

Good point, done.

[GitMensch]

Can you please rebase this, so that only the actual changing commit(s) are part of this PR?

[dfaure-kdab]

@GitMensch done

[milianw]

this really should be using a config file with #cmakedefine01... could you do that? otherwise we can merge this as-is and hope for someone to fix this properly eventually 🤞

[dfaure-kdab]

this really should be using a config file with #cmakedefine01... could you do that?

Fair point, I totally agree.
However, there's a potential for breakage, AFAICS:
target_compile_definitions(perfparser_lib PUBLIC HAVE_ZSTD)
means that anyone who links to perfparser_lib gets the HAVE_ZSTD define. This would no longer be the case if one has to include a header for that (and usually such headers are not installed).

In fact, this is all because that define is used in a header, perfdata.h.
We could easily move CAN_DECOMPRESS_ZSTD to the .cpp (no idea why it's in the header -- at least hotspot doesn't use it, do we have a way to check other users of this header?), and we could pimpl m_zstdDstream I guess (or all the members, while at it?), to remove that other ifdef in the header.

It's all a bit more involved than one might have hoped, but it's all feasible, if we're OK with breaking apps that would indirectly rely on HAVE_ZSTD for their own use (that would be a rather bad thing to do), or apps that might use CAN_DECOMPRESS_ZSTD...

Input welcome.

[milianw]

the library is internal, i.e. noone outside this repo links against any lib herein (and no libs are installed)

[dfaure-kdab]

OK I just had another look.... Isn't there a blocker for the idea of letting cmake generate a config-foo.h file, coming from the fact that there are also qmake and QBS buildsystems for this code?
Not that either of them sets HAVE_ZSTD or HAVE_DWFL_GET_DEBUGINFOD_CLIENT though.
But at least they might build (*), which they won't do anymore after I add #include <config-perfparser.h>
Do we care?

(*) actually, app.pro says c++11 which isn't enough, so it doesn't build.
And no, I don't care enough about qbs to even have that one.

[dfaure-kdab]

#29 created for the port to configure_file
Separate in case it turns out it's not wanted, but it includes this commit, so this MR can be discarded if #29 is merged.

[milianw]

I really don't care about either qbs or qmake, meaning I prefer the alternative approach.

let's close this here then