On Sunday 17 February 2013, Brad King wrote: > On 2/15/2013 5:54 PM, Alexander Neundorf wrote: > > The thing is, if I generate an error at configure time if at the end of a > > directory a target has been used but has not been defined, i.e. a target > > Foo has been imported which links against a missing imported target, it > > would still be possible that the project can build successfully if this > > bad imported target Foo is simply not used, e.g. because Foo_FOUND is > > set to FALSE. > > Just to make sure I understand correctly, you're bringing up a use case > where an imported target's dependencies are not satisfied but it does > not matter when the imported target is not used by the project?
Yes. But I wouldn't call it use case, but a case which accidentially works right now, and which a new cmake release should not break. > > How about that: when in the exported and then imported Target.cmake a > > used target is not yet defined, this target name is added to a cmake > > variable. When then cmake calculates the linking, and it can't find a > > target, it checks whether the name is contained in this cmake variable. > > If so, it errors out instead of assuming it is the name of a library. > > Yes, the variable would simply be collecting names that, in the scope > of its directory, are expected to be target names. It may be better > to use a directory property and then have the generate-time check > look in the current directory and up. That will avoid problems with > scoping of the variable if the project loads the file from inside > a function scope. Oh, right, from inside a function scope... Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
