[CMake] How to work around broken Find module

[Marcel Loose]

Hi Alex,

On Sun, 2010-10-31 at 10:20 +0100, Alexander Neundorf wrote:
> On Thursday 28 October 2010, Marcel Loose wrote:
> > Hi all,
> >
> > What is the best way to work around a broken Find module?
> >
> > A technique I've used up till now is to wrap the broken module in a
> > module with the same name that I store in my own module directory.
This
> > way, my wrapper module will be picked up first.
> 
> Yes.
> 
> > Problem with this
> > approach is, of course, that this might break when someone is using
a
> > newer CMake in which the broken module has been fixed.
> 
> Where is the breakage there ?

I really wrap the Find module. Hence, I do a 

  include(${CMAKE_ROOT}/Modules/FindXXX.cmake)

in my own FindXXX.cmake file. Therefore, things might break when a new
version of CMake is released.

> Your module, which does what you want, still overrides the one coming
from 
> cmake, no matter whether that one is better or worse.
> We don't have a problem with this in KDE, where we have many modules.
> 
> Do you have a specific problem with some module currently ?
> If so, which one, what is the exact problem ?

I've written a couple of wrapper scripts:
* FindBLAS.cmake and FindLAPACK.cmake to let it conditionally check for
the Fortran compiler.
* FindBoost.cmake to set several BOOST_* variables, because only Boost_*
variables are set.

The latest problem I had was with FindJNI.cmake. The one distributed
with CMake < 2.8.1 doesn't honour the REQUIRED option. Furthermore, even
the latest FindJNI.cmake always sets JNI_INCLUDE_DIRS and JNI_LIBRARIES
even if JNI was not completely found, which I think is wrong.

> 
> > A different approach would be to copy the fixed module from the
newer
> > CMake and store it in my own module directory. But this might also
> > break, when newer versions of CMake are released.
> 
> How does that differ from using a module which you modified ?
> It is still a module which is preferred over the ones shipped with
CMake.

It's different, because in that case I do not wrap the original macro.

> 
> Alex

Regards,
Marcel Loose.