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

Rolf Eike Beer eike at sf-mail.de
Wed Jan 11 17:15:36 EST 2012


Am Mittwoch 11 Januar 2012, 22:03:52 schrieb 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_DEB
> >                           UG})
> 
> 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.

I decided to give this another try before reverting it. After I hopefully 
fixed up my messed up local branch I now pushed a fixed version upstream that 
hopefully will do the right thing (tm). If not I'll wipe all this tomorrow.

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/33f268a8/attachment.sig>


More information about the cmake-developers mailing list