On 6/9/2011 8:50 AM, Alexander Neundorf wrote: > Calling FindQt4 in some directory with components A and B, and in some other > directory with component C, and the second one doesn't do anything because > the > first one has already set something to "I am done" already so the second one > doesn't do anything.
Yeah, that's a per-package implementation detail which is not well-handled in all the scripts. > Maybe we have the same issue when somebody calls > find_package(Foo 2.0.0 NO_MODULE) > in some directory, and it finds eg. version 2.0, > and > find_package(Foo 3.0.0 NO_MODULE) > in some other directory ? > Foo_DIR (which is in the cache) has been already set then. > This could be also mixed with different components, which may are only > installed for one of the two versions... Yes, but this is not the same as finding the same version twice with different options. Mixing third-party dependency versions within the same project is hard for more reasons than this. >> What if the FindFoo.cmake script calls find_package(Bar) and does >> not require it but the project also does find_package(Bar) and does? I'm >> sure there are more cases I haven't listed here. > > I think this can be handled. > find_package() should error out in this case, because Bar was required but it > was disabled. > Maybe this option to disable a find_package() could even be provided for all > find_package() calls, and for each REQUIRED one it will cause an error. This > would create a bunch of unusable options, but would be very consistent ;-) Okay. However, the option does not need to be "provided" as a gui-settable value for packagers to be able to disable things from build scripts. The command could honor the value if it is present but not advertise it. >> That kind of auto-cache-cleanup logic will be problematic in non-toy >> cases. If two different find_package() calls lead transitively to >> the same cache values then one could erase the other's results. > > Are you sure ? I think there will be all kinds of interactions that we cannot predict leading to mysterious hard-to-find behavior. The stated goal of this feature is for packagers to disable things. That does not require any action when the state of an option changes because packagers use one-shot build scripts. -Brad _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
