I understand the desire for purity. But we had to choose something closer to good deployment practices and implemented without stressing the packagers though so the packagers are able to deliver *working* packages. The problem is: Kexi is being packaged without the .rcc file as a runtime dependency leads to deployment failure. Then users are confused that Kexi refuses to start. 

It's hard to accept this approach in practice so I came up with the behaviour as you explained. openSUSE package maintainer who collaborated with me on these improvements was able to properly package the app and libs.

In the years of history it just happens that some packagers never actually run the app, I don't even dream about them always running autotests (before shipping). But in a pro world this is one of items on the check list.

If we have a way to ensure packager sets proper runtime dependencies, I'd happily change the FATAL_ERROR to just a warning. For now warnings are pretty much ignored by those deploying the software, and of course I am not surprised.

Requiring runtime dependencies at packaging time isn't something unusual if you assume that before finalizing the process of building Kexi running autotests is required (but still this cannot be forced because e.g. build systems lack $DISPLAY). When tests are executed, the icons have to be accessible (and all other runtime dependencies for that matter). This is why I am thinking there's not much to fight for.

Those, in rare cases, who want to take responsibility of disabling the check can patch the cmake script and then ensure ("by hand") that the runtime requirements are in proper version. But let's realize that for example in the KDb project in the future as we move on with features we would be checking exact features of dependencies such as SQLite in exactly the same way: by requiring the runtime deps at configure time. Some cmake's Find*.cmake actually check the software by building and running apps at configure stage to really know what features we have. So that's not a new thing.

Disclaimer: packagers are doing great work but just don't have the resources to study internal of requirements in given software. App maintainer on the other hand cannot accept software installation that are not working because of so simple reason/mistake as described.

PS: it would be best if the check was exported as a cmake script in breeze-icons.git.

I have to confess I am going a bit TLDR on the response but I think the key problem is that previously before cmake RUNTIME we didn't have a way to communicate runtime deps in a *standardized* way. Which means packagers had no chance to deal with them efficiently. They now do, exactly the way as we do with other dependencies. If they don't make use of that, then they are just being bad at their job.

find_package could even be made required and skipped with CMAKE_DISABLE_FIND_PACKAGE_$NAME  by the packagers. So you get the same end result but you do it in a standard fashion.

Regardless of any of this. I cannot think of a single packaging environment where build environment == run environment. The rcc being there at buildtime doesn't mean anything WRT runtime.
On deb/rpm the rcc would need to be a runtime dep. In snap/flatpak/appimage the rcc needs to end up in the bundle (which fortunately is the default), same on other platforms.

You need to assert it as runtime dependency in a standard fashion, everything else is just wishful thinking.

"I cannot think of a single packaging environment where build environment == run environment."

This is stronger requirement Kexi does not have. No need to use this argument.

"The rcc being there at buildtime doesn't mean anything WRT runtime."

Yes but only in worst case, when the intent of person compiling is rather wrong. Based on what I know packagers (with intent to ship properly) are rather grateful for pointers they get from the configure time. And people that build Kexi for the first time in order to start contributing. 
On top of that Kexi properly communicates what's required and recommended dependency at configure time, that's the case since the older times of KOffice and Calligra.

Thanks for double checking this.

Also I think we would change the subject "cmake fails on missing rcc" because it's failure in doing something, not overlook, it's a programmed behaviour with clear messages in English.

In addition, breeze-icons.rcc will be used for app-wide autotests, when the main GUI is invoked. For now we have one autotest like this. I rather consider running autotests and ensuring they pass as a prerequisite of packaging, or a post-build step. Therefore, configure-time check for presence of breeze-icons.rcc is not a bad thing.