Re: [cmake-developers] FindBZip2.cmake
On 08/25/2015 01:45 AM, Rolf Eike Beer wrote: >> 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. In that case I'm not able to reproduce the problem you're observing because the problem above is what happened when I tried it. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindBZip2.cmake
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 signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindBZip2.cmake
On 08/23/2015 07:36 AM, Rolf Eike Beer wrote: > you introduced in 7c912af2 that this module not only looks into the Windows > registry, but also added PATH_SUFFIXES include and lib for find_* calls. > Wouldn't CMake automatically append those to all paths given? No. The suffixes are only added after values found in CMAKE_PREFIX_PATH and similar variables, not to every path given. > 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/my1segqcq89k28en > https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.227/job/rnu1e71degn7snwm > > 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. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] FindBZip2.cmake
Brad, you introduced in 7c912af2 that this module not only looks into the Windows registry, but also added PATH_SUFFIXES include and lib for find_* calls. Am I gettings something wrong? Wouldn't CMake automatically append those to all paths given? 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/my1segqcq89k28en https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.227/job/rnu1e71degn7snwm 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. Everyone else interested may of course have a look, too. Greetings, Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
