FindPackage not found persists [Reopen]

[jjcasmar]

I reopen this issues because I think that your answer doesn't solve it and I think it's not correct. Of course I may be wrong, but in any case, proves that the original answer didn't solve my doubts. For anyone looking at this, the original question and answer are below.

I have just done a really simple plain CMake project

cmake_minimum_required(VERSION 3.5)
PROJECT(StupidCMake)

find_package(SUtils REQUIRED)

If SUtils is not found, CMake will complains saying that you should provide a FindSUtils.cmake or point SUtils_DIR to a dir containing SUtilsConfig.cmake.

If, without deleting the cache, you try to reconfigure providing that dir, it will find the library. You can try it with any of your libraries, I have check it with mine. This is the behavior I would expect from CMakeCommon also. As this is not the case, I would say that this is a CMakeCommon feature/bug. How can I make it work in the original way?

[Original question]
Imagine that you have a library which doesn't provide a FindFoo.cmake and therefore you use FooConfig.cmake. You should provide Foo_DIR for CMake to find it. If you forget to add it, CMake will complain, but if you add it after the first configuration, it will stay says that it can't be found.

The only way I've found to solve this is to remove the CMakeCache (or remove just the entries related with Foo) and reconfigure, but its really annoying to have to do this.

Is this a bug or am I using it wrong?

[Original answer]
Regretfully, this is a CMake "feature". The variables that decide that a library was not found are cached, so next time CMake runs it doesn't need to resolve them again. Forcing CMake to ignore these variables will basically render the cache useless.
Another example is changing the compiler used for building. Once a compiler is detected, you cannot change it without removing the cache.

[hernando]

I'm surprised your example works, maybe they fixed the behavior to do the reasonable thing in a later version of CMake than the last one I used when I stumbled upon this problem. If you're right, then there's something to be fixed in CMakeCommon.

[jjcasmar]

So an example like that is working for you?

[hernando]

I tried something similar with another package and I can confirm that configuration works at the second attempt with vanilla CMake but it doesn't with CMake/common.

[jjcasmar]

Then we can confirm there is a bug in how CMakeCommon handle find package.

[hernando]

Or a feature :P