On 2/17/2012 12:09 PM, Alexander Neundorf wrote:
But another significant part of the reason is probably that beside upstreaming
a module to cmake, there is no other "official" way to distribute Find-
modules. So if somebody wrote a libblub, it is a relatively obvious choice to
install FindBlub.cmake as part of the library, so that whoever uses Blub, also
has FindBlub.cmake available.

If the Blub project is built with CMake then there should be no FindBlub
for it at all.  It should just install BlubConfig.cmake and be done.
Perhaps your work to make the files easier to write will help with that.

The only reason to distribute FindBlub for a CMake-aware project is
to wrap up find_package NO_MODULE to produce a nicer message, but that
is totally optional.  If a project does want to distribute one for
reference it should go in the -doc package, not in -dev, and should be
put in share/doc/blub or the distro's equivalent.

Additionally, the Config.cmake file feature of cmake is still relatively
unknown. It could use some more PR ;-)

I'll have to think about how to deal with that.

By having to use NO_MODULE, or the other way round, if by not using NO_MODULE
it is clear to cmake that a Find-module is needed, it could then print
something like:

Adding the explicit "MODULE" mode keyword could help with that.

  >  - search for FindFoo.cmake, use if found
  >  - if not found, check new policy setting
  >  - if not set, warn and follow OLD behavior
  >  - if set to OLD, enter config mode and use current error if not found
  >  - if set to NEW, present error about no FindFoo in module path

Yes, exactly.

We can adjust it slightly to avoid the policy warning when FooConfig
is found and Foo_DIR is set:

 - search for FindFoo.cmake, use if found
 - if not found, check new policy setting
 - if not set, enter config mode and emit both the policy warning
   and the current error if not found
 - if set to OLD, enter config mode and use current error if not found
 - if set to NEW, present error about no FindFoo in module path

One problem with the policy is that it favors module mode as the "normal"
case and makes "config" mode look like something special.  That will
not help with the perception that the latter is preferred.

-Brad
--

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

Reply via email to