`On Thu, 2015-05-07 at 22:14 +0200, Paul Bolle wrote:> Tomorrow, after a (western European) night of sleep, I hope to explain> why the error in dad's file makes sense. I'm not much of a teacher so I> need a clear head to do that.Let's start with mom's Kconfig file. It triggers	error: recursive dependency detected!	symbol GYM depends on ROCK_CLIMBING	symbol ROCK_CLIMBING depends on LOCKER	symbol LOCKER depends on GYMNow you should realize that the kconfig tools have to answers questionslike these, for each (tristate) symbol:	- must it be 'n'; or	- can it be 'm'; or	- can it be 'y'.Take, for example: can GYM be 'y'? Since GYM depends on ROCK_CLIMBING,it can only be 'y' if ROCK_CLIMBING is 'y' (both being tristate). AndROCK_CLIMBING depends on LOCKER, so ROCK_CLIMBING can only be 'y' ifLOCKER is 'y' (ditto). And LOCKER, in its turn, depends on GYM, so itcan only be 'y', if GYM is 'y'.But we can't say whether GYM is 'y' yet, as it can still be 'n', 'm', or'y' for all we know. So we can't answer that question. Hence therecursive dependency error. (There must be a term for this obviousproblem in formal logic, but I'm not trained in formal logic.)On to dad's Kconfig file (which is your example, but simplified). Thattriggers:	error: recursive dependency detected!	symbol GYM is selected by ROCK_CLIMBING	symbol ROCK_CLIMBING depends on LOCKER	symbol LOCKER depends on GYMLet's try to determine whether GYM should be 'n'. Well, GYM is selectedby ROCK_CLIMBING so it cannot be 'n' if ROCK_CLIMBING is 'm' or 'y'. (IfROCK_CLIMBING is 'm' it can be 'm' or 'y', but not 'n', and ifROCK_CLIMBING is 'y' it must be 'y'.) Do we know whether ROCK_CLIMBINGshould be 'n'? It should be 'n' only if LOCKER is 'n'. And LOCKER shouldin its turn be 'n' if GYM is 'n'. But we don't know yet what GYM willbe. So, again, we can't answer this question. Recursive dependencyerror!The complicated error you ran into was	error: recursive dependency detected!	symbol CRYPTO is selected by SYSDATA_SIG	symbol SYSDATA_SIG is selected by FIRMWARE_SIG	symbol FIRMWARE_SIG depends on FW_LOADER	symbol FW_LOADER is selected by CRYPTO_DEV_QAT	symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTOI'm lazy, so I haven't gone through this error step by step. But I'msure it's just a complicated version of what I tried to explain in theabove two examples. But if you're unconvinced I'll try to go throughthis error too.Now I'm sure the point I'm trying to make can be made more convincinglyand more elegantly. But the thing is, I think, that given how "select"works and how "depends on" works, some setups will trigger these errors.One might wish that "select" or "depends on" behaved differently, butwith the thousands of Kconfig symbols now in use, that really looksunfeasible.(Now let's see how all the, mostly German, people trained in formallogic that appear to care about the kconfig tools shoot holes in myreasoning.)Hope this helps,Paul Bolle`