[Build System][Anti-Pattern] Configuration fails without failing

[arkq]

I have a general question regarding the configuration of the project.

In many places I can see a pattern where a configuration failure of some component does not lead to built break. Instead it is silently (hard to spot status message does not count) ignored. This leads to very hard to spot problems during compilation and installation.

Few examples of such places:

• https://github.com/Samsung/ONE/blob/master/compiler/one-cmds/CMakeLists.txt#L13
• https://github.com/Samsung/ONE/blob/master/compiler/luci-compute/CMakeLists.txt#L6
• https://github.com/Samsung/ONE/blob/master/compiler/tflchef/CMakeLists.txt#L4

More can be seen by using simple grep: git grep -A 1 'message(STATUS.*FAILED'

Why not message(FATAL_ERROR ...)? This way user will know right away that something is missing and it's not possible to build the project (building only half of the project is not a successful built). In my case the installation of all onecc scripts silently failed without letting me know that something is wrong... The reason for that was the fact that I have only Python 3.13 available (Ubuntu 25.10)...

In the past I also struggled to build onnx2circle (now I know that this tool is deprecated, but my point here still holds) because I had to add all dependencies to the -DBUILD_WHITELIST= list. And even though the list of dependencies was not complete, the configuration stage succeeded. However, the ./nncc build command built nothing.

---

Also I've spotted different problematic code - the same category but different pattern:

• https://github.com/Samsung/ONE/blob/master/compiler/luci-compute/CMakeLists.txt#L44

If one will not spot this return() and add some code below that line, the code will not be executed unless tests are enabled... Why not wrap the test code in the if(ENABLE_TEST) code block? Such logic would be easier to read and is not error prone due to many return paths in the code.

[hseok-oh]

I did not maintained compiler's internal cmake script until last year, but I'll answer your question as I understand and remember.

git grep -A 1 'message(STATUS.*FAILED' was used first with nnas_find_package(...) to handle build condition on each dependent package's option, not on each project. BUILD_WHITELIST was introduced later to handle collection of compiler package. So BUILD_WHITELIST is used for special purpose, and default was try to build all project until introducing exclude.me. So there may still remain some conflict of your question's two gimmick.
I don't know why this pattern is used for python system package checking.

Why not wrap the test code in the if(ENABLE_TEST) code block?

if(NOT ENABLE_TEST) return() was replaced code of nnas_find_package(GTest QUIET) if(NOT GTest_FOUND). Fast return pattern is used to place all test cmake code under if(ENABLE_TEST), in other word, divide cmake code to two part. You mention that code block would be easier to read, but this pattern is still used because many maintainers and contributors think that current pattern is not difficult to read. If you don't think this, please collect others opinion.

[arkq]

'message(STATUS.*FAILED' was used first with nnas_find_package(...) to handle build condition on each dependent package's option, not on each project. BUILD_WHITELIST was introduced later to handle collection of compiler package. So BUILD_WHITELIST is used for special purpose, and default was try to build all project until introducing exclude.me.

So, as you say, that is not a design, but an end result of years of patching the code :) That's good to know. What would you say to straighten that out? The proper dependency tracking should be done by cmake itself, not by the BUILD_WHITELIST. Then, if you do not want to build something by default, such targets should not be added to ALL target (using EXCLUDE_FROM_ALL). Then, on top of that layering one can add cmake options's to enable features of the project (which application/modules to build). If app is enabled it will be added to ALL, otherwise not. Then, all dependencies will be tracked by cmake (no need for BUILD_WHITELIST) and not everything will be built by default (no need for exclude.me). And what's most important all return() should be replaces with proper build breaks to notify user that project's configuration is not complete.

You mention that code block would be easier to read, but this pattern is still used because many maintainers and contributors think that current pattern is not difficult to read.

As for if(NOT ENABLE_TEST) it's OK, but I'm just saying that one day it might backfire on you :)