[cmake-developers] FindBZip2 (was: Dashboard issues with ExternalProject)

[Rolf Eike Beer]

Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
> On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
> > Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
> >> The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
> >> with whatever is needed to convince find_package(BZIP2) to use the
> >> CMake-built cmbzip2 library.  If you're changing the Find module for
> >> it then what needs to be pre-loaded may depend on which version of
> >> CMake is used to configure the build of CMake.  It's a bit tricky.
> > 
> > I pushed an updated version to topic improve-findbzip2, hopefully that
> > would do it. Does this look sane?
> 
> Since you're changing the way that module looks for libraries you should
> also fix up some historical wrongness in it.  The Module/readme.txt file
> explains that BZIP2_LIBRARIES should not be a cache variable.  Instead
> it should be a normal variable that collects the results from other
> single-library searches.  Ideally the module (with config support) should
> offer these cache entries for users to set:
> 
>   BZIP2_LIBRARY_RELEASE
>   BZIP2_LIBRARY_DEBUG
> 
> and the output should all be in a single
> 
>   set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
>                           debug ${BZIP2_LIBRARY_DEBUG})

That's the way we currently have in next.

> cmake variable (not cached) whose content is adjusted for various
> combinations of availability of each piece.  For compatibility you need
> to honor BZIP2_LIBRARIES if it is set before the module is loaded, but you
> do not need to cache it.
> 
>  > Should I merge it into next or revert the last patch on next?
> 
> Which is the "last patch"?

96ae584

The current problem is that CMake set BZIP2_LIBRARIES which is not cached. So 
if a user is used to set BZIP2_LIBRARIES this would only work the first time 
now. Since the variable is not cached it would eventually get lost and the 
user suddenly has an unexpected build failure. Or do I get something entirely 
wrong.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120111/b3efa4c5/attachment.sig>