[cmake-developers] FindBZip2.cmake

Rolf Eike Beer eike at sf-mail.de
Tue Aug 25 01:45:21 EDT 2015


Brad King wrote:
> On 08/23/2015 07:36 AM, Rolf Eike Beer wrote:

> > Another thing which I found is that there seems to be an obscure problem
> > in FindBZip2.cmake to not find the library on Windows if the path contains
> > backslashes. Yes, really. Just compare the cmake part of these 2 links (no
> > idea how long they will present, as they are CI logs):
> > 
> > https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.228/job/my1segq
> > cq89k28en
> > https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.227/job/rnu1e7
> > 1degn7snwm
> > 
> > I have no clue what happens there, why it happens only for that module,
> > and
> > why noone noticed that before. I do not have access to a Windows system
> > where I can test easily, but maybe you can have a look (or find someone
> > to)? I thought that it may be "\b", because that would be unique to that
> > module in that build configuration, but if I pass the CMAKE_PREFIX_PATH
> > with forward slash at that point it still fails, while all other modules
> > work.
> 
> The BZIP2_NEED_PREFIX check generates a CMakeLists.txt file that
> refers to the raw path given without re-escaping the backslashes.
> Then the check fails to configure due to the backslashes being
> interpreted as invalid CMake escape sequences.

No, this is not the problem. That happens if FPHSA succeeds, but that fails 
because it can't find the library, which means the problem is actually happen 
before FPHSA.

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/20150825/48e31932/attachment.sig>


More information about the cmake-developers mailing list