In D18167#398360, @aacid wrote:

In D18167#398343, @kossebau wrote:

only 3(?) days between proposal and commit was also a very rushy

Check your dates better please, it's 9 days

In D18167#398076, @graesslin wrote:

The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.

In D18167#398343, @kossebau wrote:

only 3(?) days between proposal and commit was also a very rushy

In D18167#398076, @graesslin wrote:

The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.

In D18167#398076, @graesslin wrote:

The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.

Almost every project has already been gone over with clang-tidy.
Including kwin which was then force-pushed back by you. This was back in June 2017.
I've got little sympathy if we have a warning after explicitly reverting the fix to the warning.

The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.

qhelpgenerator is back in Qt 5.12.1

In D18167#397319, @graesslin wrote:

For done code this warning is pointless and negative. I invite you to work with a code base like KWin where it is more important to have a working git blame than protection for theoretical problems. Nobody will be able to guarantee that a 500+ change to add override won't break. Human errors happen, nobody will be able to review something like that. Addressing this warning by adding override all over our legacy code base has a serious risk.

I'm seriously pissed that this is forced on us and we have to change code.

I'm totally fine with this warning for new code and new projects. But let projects opt in for it instead of forcing it on legacy code bases.

For done code this warning is pointless and negative. I invite you to work with a code base like KWin where it is more important to have a working git blame than protection for theoretical problems. Nobody will be able to guarantee that a 500+ change to add override won't break. Human errors happen, nobody will be able to review something like that. Addressing this warning by adding override all over our legacy code base has a serious risk.

In D18167#397020, @graesslin wrote:

This causes in KWin 500+ new warnings. Do you really think it's a good idea to spam all of KDE with new compiler warnings. KDE has an old code base. We cannot enable warnings for the way you developed C++ for 20 years.

This causes in KWin 500+ new warnings. Do you really think it's a good idea to spam all of KDE with new compiler warnings. KDE has an old code base. We cannot enable warnings for the way you developed C++ for 20 years.

As far as I understand the logic of the whole thing, it looks sane. At some point we ought to find a way to properly test that the generated code...

Since i have two +1 i'll commit this next saturday unless someone shouts in disagreement

+1 to me too.

IMHO a good idea, +1.

Not sure if there ever s a chance somebody would inject QObject code into such a generated file?

In D17863#384229, @tcberner wrote:

In D17863#384145, @cgiboudeaux wrote:

Why not fixing kstars instead?

include(ECMCheckLinkerFlags)
[...]
# Check for nodump support
SET(NODUMP_FLAGS "-Wl,-z,nodump")
ecm_check_linker_flags("${NODUMP_FLAGS}" NODUMP_SUPPORTED)
if (NODUMP_SUPPORTED)
    SET(SEC_LINK_FLAGS "${SEC_LINK_FLAGS} ${NODUMP_FLAGS}")
endif ()

Of course kstars could also just stop adding nodump ever :)

In D17863#384145, @cgiboudeaux wrote:

Why not fixing kstars instead?

Why not fixing kstars instead?

See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230603

qhelpgenerator is coming back in 5.12.1. You may simply tell people to skip the .0 release and upgrade.

Try to find qmake if qmake-qt5 is not found

Damn, I went too fast. This doesn't fix the issue.

Address review comments.

In D17015#363060, @kossebau wrote:

Good to see you caring for ECM documentation not getting broken with Qt 5.12 :)

Any idea how we could perhaps deduplicate the FindQHelpGenerator.cmake with the one from find-modules (which is a helper for runtime with the ECMAddQch macro)? No instant idea yet, perhaps also better to have dedicated variants for each purppse? Needs me another round of thinking.

Add the reason for looking for the executable

ping?

A more complete draft:

You will notice that I plan to maintain an option to disable the Apple-specific behaviour for anyone who depends on the current behaviour (that includes me, but your script would also continue to work). Cf. the APPLE_FORCE_X11 option

Can we set DATAROOTDIR=/Library/Application Support/KDE so that everything remains nicely bundled?

Good to see you caring for ECM documentation not getting broken with Qt 5.12 :)

Done. kfilemetadata was also changed to use FindLibExiv2.cmake.

Looks good to me.

Wow...

If anyone wonders:

This implements and uses my idea of an ecm_add_<lang>_compiler_flags_if_supported function set for C and C++. It uses compiler ID+version conditions to determine if flag(s) are supported when those conditions are known and reliable - otherwise and only then does it resort to querying the compiler.

Good find. No idea why it was not like this from the start.

Looks ok to me, less stuff to set manually is always good.

Something side-ways related: I went down this hole because cmake's generate_export_header failed because of an unsupported flag that was added.
Regardless of how we implement things here, shouldn't there be something like ecm_generate_export_header which empties CMAKE_CXX_FLAGS temporarily because calling CMake's version and then restores the variable? There's no feedback at all in this function, the generated export header just contains dummy EXPORT macros, leaving the user to wonder why the linker fails. Or should the visibility flags also be set conditionally, after setting all other compiler options?

Thus these places need to be turned into:

  ...
  if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS "3.8")
  elseif(CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS "8.1.0")

I don't like the hiding of the if-branches as argument to macro. We shouldn't to this as it makes the code harder to understand.

A simpler version, setting CMAKE_<LANG>_FLAGS directly (also fixes a persistence error in my previous implementation).

Don't worry, the commit message would have looked like that.
Or rather, it will say

Don't worry, the commit message would have looked like that.

The commit message is wrong. It should be Use STREQUAL "Clang" to detect the clang for compatibility with Apple systems.

If there are no further comments, I will push this on sunday.

In D15070#347945, @cgiboudeaux wrote:

In D15070#347944, @bruns wrote:

So, after another week, no reason has been given not to accept this.

1. It fixes broken behavior on several platforms
2. It does not break current setups
3. It is consistent with other config variables

That's not true, you're refusing to fix the issues. Why should we invest time reviewing your changes, exactly?

In D15070#347944, @bruns wrote:

So, after another week, no reason has been given not to accept this.

1. It fixes broken behavior on several platforms
2. It does not break current setups
3. It is consistent with other config variables

So, after another week, no reason has been given not to accept this.

In D15070#345218, @cgiboudeaux wrote:

In D15070#344900, @bruns wrote:

In D15070#344884, @cgiboudeaux wrote:

In D15070#344871, @bruns wrote:

As all the raised concerns have been dealed with, can we give this a try while the next KF release is still somewhat in the future?

No, the empty if must be removed. Code that does nothing is useless.

Its not empty, there is a comment inside. Of course I can add a set(KDE_INSTALL_PYTHON${pyversion}DIR ${KDE_INSTALL_PYTHON${pyversion}DIR}) if you insist ...

And if you restructure it you either end up with a lengthy if condition - if (NOT KDE_INSTALL_PYTHON${pyversion}DIR AND KDE_INSTALL_USE_PYTHON${pyversion}_SYS_PATHS) - or another nesting level. Both are significantly harder to read.

If KDE_INSTALL_USE_PYTHON${pyversion}_SYS_PATHS is true, KDE_INSTALL_PYTHON${pyversion}DIR can be ignored. This was in the review