Could the indentation perhaps be turned to be 4 spaces while copying it here? While https://community.kde.org/Policies/CMake_Coding_Style#Indentation allows the choice of 2,3, or 4 spaces, using 4 is more in line with the indentation used in C++ sources, so IMHO more expected to read.

I just realized there is a much older version of this in attic/modules already, should that be removed as part of adding this?

In D18943#410391, @cgiboudeaux wrote:

I'm not sure to understand the commit message, does qtbase look for ECM ?

Add since tag.

I'm not sure to understand the commit message, does qtbase look for ECM ?

LGTM, thanks!

Now tested more exhaustively and with unittest.

Addressed comments

You also need to change '-Xclang -add-plugin -Xclang clang-lazy' to '-Xclang -add-plugin -Xclang clazy' for the plugin to actually be used.

Note: this will break with older clazy versions. I'm not sure how to prevent that.
One could argue that a developer interested in clazy should probably run the latest version anyway...

So according to you, this line is useful ? from my point of view, it's needless and just looks like a syntax error.

In D16894#402901, @rjvbb wrote:

Forget that. The syntax is confusing, please remove this HASFLAG

That I'm not going to do. The goal is to both to have useful feedback like below, and to avoid caching issues that would cause on the first query to be performed (if you were to use a single result variable):

-- Performing Test Clang++_ACCEPTS-Wvla
``

Forget that. The syntax is confusing, please remove this HASFLAG

In D16894#402701, @rjvbb wrote:

There are tests for other ECM modules in the **tests** subdir.

That's not the expected answer, so let me rephrase: which existing test can I clone and adapt (which is about the only thing I know how to do in this domain)?

There are tests for other ECM modules in the **tests** subdir.

In D16894#402364, @rjvbb wrote:

Updated as requested.

Right, but I was saying all this because I think IF_SUPPORTED (the keyword in the arguments) should be SUPPORTED_IF.

In D16894#402209, @rjvbb wrote:

In that sentence, one can read "if supported" for the macro name, ...

That was my idea too, and the reason the macro ends in "_if_supported".

PS: don't forget the unit test for the new module.

In that sentence, one can read "if supported" for the macro name, ...

SUPPORTED_IF : add the flag(s) if the expression is true?

Yes.

This follows David's suggestion, but using QUERY_IF instead of the suggested TRY_IF to make it clear that this parameter controls the querying of the compiler.
I haven't yet tested the new logic exhaustively but the as far as I can tell the macro behaves as intended as used in the two compiler settings modules.

Usually if you have a conditional behaviour the associated condition specifies when to trigger it, no?
You're right that the names don't suggest exactly how the condition is being evaluated (with extra checks or not), but that was also a bit the idea.
Don't bother the user with such details, just provide a macro that will add the flag(s) if they are supported, with an optional conditional expression that can make things faster.

Ah. You meant an "OR", I thought it was an "AND". (as in our known selection of compilers OR/AND appleclang supports it)
But things are certainly not clearer now with the name CONDITION, which doesn't imply either one.

Renamed macro and parameter names as announced in my last comment.

In D16894#400949, @dfaure wrote:

This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading that, one thinks "well, if we know the compiler flag is supported, why are we testing that it is?".

like René says, this is quite surprising

Hmmm, did I say exactly that? :)

This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading that, one thinks "well, if we know the compiler flag is supported, why are we testing that it is?". I think this should be something like TRY_IF.
Then it's clearer that no harm will occur if we set a too low compiler version after TRY_IF, it's just an optimization to avoid e.g. testing all gcc flags on MSVC and vice-versa.

If it fixes the issue, this can go in, but like René says, this is quite surprising, since the default behavior (CMP0025 off) is that the compiler is called "Clang" on Apple platforms as well.
See cmake --help-policy CMP0025

This is in fact cmake's fault, or ECM's for not taking a cmake quirk into account.

Oh, Hannah updated the summary, so an unknown option makes visibility stuff fail?

You sure about that? AFAICS from https://binary-factory.kde.org/view/MacOS/job/Kate_Release_macos/346/console it's just a warning, otherwise, ninja would stop after the first error, and it continues until a linking failure happens

This change is somewhat urgent - as can be seen at https://binary-factory.kde.org/view/MacOS/ all Mac builds are currently broken due to this issue.

See also https://phabricator.kde.org/D16894 which (initially) aimed to tackle this in a more general fashion.

In D18547#400298, @aacid wrote:

Why?

Why?

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.