[CMake] #13204 should not be sent to the backlog
Just fix the documentation, please. -- Dave Abrahams BoostPro Computing Software DevelopmentTraining http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] A way to set default compiler, etc.?
When I invoke cmake for the first time in a project, I normally use -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ I'm tired of typing that every time I blow away my CMakeCache.txt. Is there a place I can register these preferences so I don't have to? Thanks, -- Dave Abrahams BoostPro Computing Software DevelopmentTraining http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
http://www.cmake.org/Bug/view.php?id=13204 http://www.cmake.org/Bug/view.php?id=13162 -- Dave Abrahams BoostPro Computing Software DevelopmentTraining http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Mon Jun 04 2012, Peter Kümmel wrote: > On 04.06.2012 21:13, Dave Abrahams wrote: >>> >>> OK, but I can't reproduce it on Ubuntu 12.04 64bit, >>> so I thought it must be something else- >> >> Oh, now that's odd. I wonder why it isn't working for me? >> > > I've not tested on Ubuntu but LinuxMint 13, but I think that > should make no difference. > > If you have the time, maybe it's better to start from scratch. > Attached the CMakeLists.txt which I've used. > It produces this output in an empty build folder > (after apt-get install libbz2-dev): > > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so > -- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so > -- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so - > found > -- Configuring done > -- Generating done > -- Build files have been written to: /home/synth/sandbox/cmake/test > > If you don't have a this output I will also set up a Ubuntu 12.04 and > see what happens. dave@Ubu12:/media/psf/tmp/kummel/build$ ~/bin/cmake .. -- The C compiler identification is GNU 4.6.3 -- The CXX compiler identification is GNU 4.6.3 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - failed CMake Error at /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE): Could NOT find BZip2 (missing: BZIP2_LIBRARIES) (found version "1.0.6") Call Stack (most recent call first): /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE) /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindBZip2.cmake:43 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:2 (Find_PACKAGE) But when I install cmake the traditional way it works. It looks like CMake doesn't tolerate being installed in a path containing "=". -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Mon Jun 04 2012, Peter Kümmel wrote: > On 04.06.2012 18:37, Dave Abrahams wrote: >> >> on Sun Jun 03 2012, Peter >> Kümmel wrote: >> >>> On 03.06.2012 02:05, Dave Abrahams wrote: >>>> > >>>> /tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(50): >>>> SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES ) >>>> >>> >>> Somehow the complete search patch is empty, it should look like this: >>> >>> CMakeFiles/CMakeCCompiler.cmake(50): >>> SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES >>> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2;/usr/lib/x86_64-linux-gnu >>> ) >>> >>> Do you run a plain stock Ubuntu 12.04? >> >> Yes. But this is a known bug >> http://public.kitware.com/Bug/view.php?id=12049 as I mentioned in an >> earlier message, with a known workaround. So, problem "solved." >> > > OK, but I can't reproduce it on Ubuntu 12.04 64bit, > so I thought it must be something else- Oh, now that's odd. I wonder why it isn't working for me? -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Sun Jun 03 2012, Peter Kümmel wrote: > On 03.06.2012 02:05, Dave Abrahams wrote: >> >> /tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(50): >> SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES ) >> > > Somehow the complete search patch is empty, it should look like this: > > CMakeFiles/CMakeCCompiler.cmake(50): > SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2;/usr/lib/x86_64-linux-gnu > ) > > Do you run a plain stock Ubuntu 12.04? Yes. But this is a known bug http://public.kitware.com/Bug/view.php?id=12049 as I mentioned in an earlier message, with a known workaround. So, problem "solved." -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Sat Jun 02 2012, Peter Kümmel
wrote:
> On 02.06.2012 21:21, Peter Kümmel wrote:
>> On 02.06.2012 19:54, Rolf Eike Beer wrote:
>>>
>>> It will look into e.g. /usr/lib and /usr/lib64
>>> (depending on your system), but not into /usr/lib/x86_64-linux-gnu. You
>>> can tell it to try by setting CMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu
>
>>> before calling CMake.
>>
>> But the doku says it looks into "/lib/ if
>> CMAKE_LIBRARY_ARCHITECTURE is set",
>> and when I test it with cmake 2.8.8 and 2.8.5 this simple CMAkeLists.txt,
>>
>> cmake_minimum_required(VERSION 2.8)
>> message(STATUS "CMAKE_LIBRARY_ARCHITECTURE: ${CMAKE_LIBRARY_ARCHITECTURE}")
>> Find_PACKAGE(BZip2 REQUIRED)
>>
>> finds libbzip2:
>>
>> -- CMAKE_LIBRARY_ARCHITECTURE: x86_64-linux-gnu
>> -- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so (found version "1.0.5")
>> -- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so
>> -- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so -
>> found
>>
>> Dave is CMAKE_LIBRARY_ARCHITECTURE set on your system?
>
> $ cmake .. --trace 2>&1 | grep x86
>
> gives here:
>
> /home/synth/t/CMakeFiles/CMakeSystem.cmake(6): SET(CMAKE_SYSTEM_PROCESSOR
> x86_64 )
> /home/synth/t/CMakeFiles/CMakeSystem.cmake(11):
> SET(CMAKE_HOST_SYSTEM_PROCESSOR x86_64 )
> /home/synth/t/CMakeFiles/CMakeCCompiler.cmake(32):
> SET(CMAKE_C_LIBRARY_ARCHITECTURE x86_64-linux-gnu )
> /home/synth/t/CMakeFiles/CMakeCCompiler.cmake(43):
> SET(CMAKE_LIBRARY_ARCHITECTURE x86_64-linux-gnu )
> /home/synth/t/CMakeFiles/CMakeCCompiler.cmake(50):
> SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES
> /usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib
> )
Further:
--8<---cut here---start->8---
dave@Ubu12:/tmp/qb/build$ ~/bin/cmake ../src --trace 2>&1 | grep
CMakeCCompiler.cmake
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(1): SET(CMAKE_C_COMPILER
/usr/bin/gcc )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(2): SET(CMAKE_C_COMPILER_ARG1 )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(3): SET(CMAKE_C_COMPILER_ID GNU )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(4): SET(CMAKE_C_COMPILER_VERSION
4.6.3 )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(5): SET(CMAKE_C_PLATFORM_ID
Linux )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(7): SET(CMAKE_AR /usr/bin/ar )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(8): SET(CMAKE_RANLIB
/usr/bin/ranlib )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(9): SET(CMAKE_LINKER /usr/bin/ld
)
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(10): SET(CMAKE_COMPILER_IS_GNUCC
1 )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(11): SET(CMAKE_C_COMPILER_LOADED
1 )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(12): SET(CMAKE_COMPILER_IS_MINGW
)
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(13):
SET(CMAKE_COMPILER_IS_CYGWIN )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(14): IF(CMAKE_COMPILER_IS_CYGWIN
)
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(19):
SET(CMAKE_C_COMPILER_ENV_VAR CC )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(21): IF(CMAKE_COMPILER_IS_MINGW )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(24): SET(CMAKE_C_COMPILER_ID_RUN
1 )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(25):
SET(CMAKE_C_SOURCE_FILE_EXTENSIONS c )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(26):
SET(CMAKE_C_IGNORE_EXTENSIONS h;H;o;O;obj;OBJ;def;DEF;rc;RC )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(27):
SET(CMAKE_C_LINKER_PREFERENCE 10 )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(30): SET(CMAKE_C_SIZEOF_DATA_PTR
)
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(31): SET(CMAKE_C_COMPILER_ABI )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(32):
SET(CMAKE_C_LIBRARY_ARCHITECTURE )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(34): IF(CMAKE_C_SIZEOF_DATA_PTR )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(38): IF(CMAKE_C_COMPILER_ABI )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(42):
IF(CMAKE_C_LIBRARY_ARCHITECTURE )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(46): SET(CMAKE_C_HAS_ISYSROOT )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(49):
SET(CMAKE_C_IMPLICIT_LINK_LIBRARIES )
/tmp/qb/build/CMakeFiles/CMakeCCompiler.cmake(50):
SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES )
--8<---cut here---end--->8---
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Sat Jun 02 2012, Peter Kümmel
wrote:
> On 02.06.2012 21:21, Peter Kümmel wrote:
>> On 02.06.2012 19:54, Rolf Eike Beer wrote:
>>>
>>> It will look into e.g. /usr/lib and /usr/lib64
>>> (depending on your system), but not into /usr/lib/x86_64-linux-gnu. You
>>> can tell it to try by setting CMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu
>
>>> before calling CMake.
>>
>> But the doku says it looks into "/lib/ if
>> CMAKE_LIBRARY_ARCHITECTURE is set",
>> and when I test it with cmake 2.8.8 and 2.8.5 this simple CMAkeLists.txt,
>>
>> cmake_minimum_required(VERSION 2.8)
>> message(STATUS "CMAKE_LIBRARY_ARCHITECTURE: ${CMAKE_LIBRARY_ARCHITECTURE}")
>> Find_PACKAGE(BZip2 REQUIRED)
>>
>> finds libbzip2:
>>
>> -- CMAKE_LIBRARY_ARCHITECTURE: x86_64-linux-gnu
>> -- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so (found version "1.0.5")
>> -- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so
>> -- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so -
>> found
>>
>> Dave is CMAKE_LIBRARY_ARCHITECTURE set on your system?
>
> $ cmake .. --trace 2>&1 | grep x86
>
> gives here:
>
> /home/synth/t/CMakeFiles/CMakeSystem.cmake(6): SET(CMAKE_SYSTEM_PROCESSOR
> x86_64 )
> /home/synth/t/CMakeFiles/CMakeSystem.cmake(11):
> SET(CMAKE_HOST_SYSTEM_PROCESSOR x86_64 )
> /home/synth/t/CMakeFiles/CMakeCCompiler.cmake(32):
> SET(CMAKE_C_LIBRARY_ARCHITECTURE x86_64-linux-gnu )
> /home/synth/t/CMakeFiles/CMakeCCompiler.cmake(43):
> SET(CMAKE_LIBRARY_ARCHITECTURE x86_64-linux-gnu )
> /home/synth/t/CMakeFiles/CMakeCCompiler.cmake(50):
> SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES
> /usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib
> )
>
> -- x86_64-linux-gnu
> -- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so
--8<---cut here---start->8---
dave@Ubu12:/tmp/qb/build$ ~/bin/cmake ../src --trace 2>&1 | grep x86
/tmp/qb/build/CMakeFiles/CMakeSystem.cmake(6): SET(CMAKE_SYSTEM_PROCESSOR
x86_64 )
/tmp/qb/build/CMakeFiles/CMakeSystem.cmake(11):
SET(CMAKE_HOST_SYSTEM_PROCESSOR x86_64 )
dave@Ubu12:/tmp/qb/build$
--8<---cut here---end--->8---
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Sat Jun 02 2012, Dave Abrahams wrote: > Heh, fair enough. I'll file a bug report. Looks like they already know about this one: http://public.kitware.com/Bug/view.php?id=12049 -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Sat Jun 02 2012, "Rolf Eike Beer" wrote: >> >> on Sat Jun 02 2012, "Rolf Eike Beer" >> wrote: >> >>>> > >>>> I don't understand what I'm seeing here. How can the bzip2 libraries >>>> be >>>> both missing and found simultaneously? How should I go about debugging >>>> this? >>>> >>> >>>> Thanks, >>>> Dave >>>> >>>> >>>> $ dpkg -L libbz2-dev >>>> /. >>>> /usr >>>> /usr/lib >>>> /usr/lib/x86_64-linux-gnu >>>> /usr/lib/x86_64-linux-gnu/libbz2.a >>>> /usr/include >>>> /usr/include/bzlib.h >>>> /usr/share >>>> /usr/share/doc >>>> /usr/lib/x86_64-linux-gnu/libbz2.so >>>> /usr/share/doc/libbz2-dev >>>> dave@Ubu12:/tmp/qb/build$ LD_LIBRARY_PATH=/usr/lib/x86_64-gnu >>>> ~/bin/cmake >>>> . >>>> CMake Error at >>>> /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 >>>> (MESSAGE): >>>> Could NOT find BZip2 (missing: BZIP2_LIBRARIES) (found version >>>> "1.0.6") >>>> Call Stack (most recent call first): >>> >>> FindBZip2 has found the header and detected that it has version 1.0.6, >>> but >>> it hasn't found the library itself because it is hidden in that >>> subdirectory. >> >> That's very odd, considering that's a standard directory in which >> libraries are installed on my distro. Also I note that >> >> LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu cmake . > > LD_LIBRARY_PATH is for the dynamic linker when you start something. CMake > doesn't look at this. I know it doesn't, but I thought perhaps it would be invoking g++ to test for availability of the library and /that/ would be looking at it. > It will look into e.g. /usr/lib and /usr/lib64 (depending on your > system), but not into /usr/lib/x86_64-linux-gnu. You can tell it to > try by setting CMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu before > calling CMake. I set CMAKE_LIBRARY_PATH, and it worked. >> didn't work any better than the other command. >> >>> Assuming that you have CMake 2.8.8 you can tell it where the library >>> is with that command in the build dir: >>> >>> cmake -D BZIP2_LIBRARY_RELEASE=/usr/lib/x86_64-linux-gnu/libbz2.so . >> >> I'l try that... but it seems wrong. autoconf would be able to find that >> library, right? > > I have no idea about autoconf, that's why I use CMake ;) Heh, fair enough. I'll file a bug report. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
on Sat Jun 02 2012, "Rolf Eike Beer" wrote: >> >> I don't understand what I'm seeing here. How can the bzip2 libraries be >> both missing and found simultaneously? How should I go about debugging >> this? >> > >> Thanks, >> Dave >> >> >> $ dpkg -L libbz2-dev >> /. >> /usr >> /usr/lib >> /usr/lib/x86_64-linux-gnu >> /usr/lib/x86_64-linux-gnu/libbz2.a >> /usr/include >> /usr/include/bzlib.h >> /usr/share >> /usr/share/doc >> /usr/lib/x86_64-linux-gnu/libbz2.so >> /usr/share/doc/libbz2-dev >> dave@Ubu12:/tmp/qb/build$ LD_LIBRARY_PATH=/usr/lib/x86_64-gnu ~/bin/cmake >> . >> CMake Error at >> /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 >> (MESSAGE): >> Could NOT find BZip2 (missing: BZIP2_LIBRARIES) (found version "1.0.6") >> Call Stack (most recent call first): > > FindBZip2 has found the header and detected that it has version 1.0.6, but > it hasn't found the library itself because it is hidden in that > subdirectory. That's very odd, considering that's a standard directory in which libraries are installed on my distro. Also I note that LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu cmake . didn't work any better than the other command. > Assuming that you have CMake 2.8.8 you can tell it where the library > is with that command in the build dir: > > cmake -D BZIP2_LIBRARY_RELEASE=/usr/lib/x86_64-linux-gnu/libbz2.so . I'l try that... but it seems wrong. autoconf would be able to find that library, right? -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] (missing: BZIP2_LIBRARIES) (found version "1.0.6")??
I don't understand what I'm seeing here. How can the bzip2 libraries be both missing and found simultaneously? How should I go about debugging this? Thanks, Dave $ dpkg -L libbz2-dev /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libbz2.a /usr/include /usr/include/bzlib.h /usr/share /usr/share/doc /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev dave@Ubu12:/tmp/qb/build$ LD_LIBRARY_PATH=/usr/lib/x86_64-gnu ~/bin/cmake . CMake Error at /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE): Could NOT find BZip2 (missing: BZIP2_LIBRARIES) (found version "1.0.6") Call Stack (most recent call first): /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE) /home/dave/.cache/0install.net/implementations/sha1new=f0c7800e5e264c5d96d1cd6151de92dfc74f65bb/share/cmake-2.8/Modules/FindBZip2.cmake:43 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) .dependencies/ryppl/cmake/Modules/RypplFindPackage.cmake:26 (find_package) .dependencies/iostreams/CMakeLists.txt:10 (ryppl_find_package) -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja generator is Linux-only?
on Wed May 16 2012, Bill Hoffman wrote: > Ninja is currently not totally working on mac and windows. > > The limitations are: > > Windows: file level dependencies are not working. > Mac: Frameworks and application bundles are not working. > > Here are the dashboards with the failing tests: > > http://open.cdash.org/viewTest.php?onlyfailed&buildid=2281938 > http://open.cdash.org/viewTest.php?onlyfailed&buildid=2280676 > > The Mac fix should be pretty simple. It involves moving some code out > of the makefile generator into a shared place with the ninja generator > so that it can create the frameworks and bundles. > > The windows fix requires a change in upstream ninja. Right now the > ninaj cmake dashboard is using a fork of ninja to get response > files. There is some version of that in the upstream ninja. There is > some discussion of some work that adds the depend information to > ninja, but I don't think it is quite there. > > Both of these issues are serious enough that the support for ninja on > these platforms is broken as far as cmake is concerned. A shame. Thanks for the explanation, though. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja generator is Linux-only?
on Tue May 15 2012, Michael Jackson wrote: > There was a long discussion about the limitations of ninja on each > platform on the mailing list just before the last release. That is > where the decisions were made to limit ninja to Linux only at this > point. > > That last thread was on April 17, 2012 with the title "Re: [CMake] > CMake Ninja generator issues: any showstoppers?" I found that thread; it seems to have 3 or 4 messages. None of them really explains the issue, but I can take your word for it. It's surprising that there would be problems on the Mac that aren't present on Linux, but I guess it's plausible. Thanks, > -- > Mike Jackson > > On May 15, 2012, at 8:31 AM, Dave Abrahams wrote: > >> >> Can someone explain why a ninja generator isn't available everywhere >> that ninja runs? Can this be remedied? >> >> Thanks, >> >> -- >> Dave Abrahams >> BoostPro Computing >> http://www.boostpro.com >> >> >> -- >> >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake > > -- -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Ninja generator is Linux-only?
Can someone explain why a ninja generator isn't available everywhere that ninja runs? Can this be remedied? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
on Mon May 14 2012, Robert Dailey wrote: > Is improvement desired in this area? By me, yes. > Is the current implementation really satisfactory? For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
Thanks, everybody, for your help. Eventually the CMake expert I've been
working with became available again and he solved the problem easily.
Cheers,
on Wed May 09 2012, Michael Wild
wrote:
> On 05/08/2012 11:13 PM, Dave Abrahams wrote:
>>
>> on Tue May 08 2012, Alexander Neundorf
>> wrote:
>>
>>> On Tuesday 08 May 2012, Dave Abrahams wrote:
>>>
>
>>>> Here's another one!
>>>>
>>>> Scenario:
>>>>
>>>> * I am running CMake under 0install to build and install libraries
>>>>
>>>> * Each library builds a package SomePackage for the library binaries
>>>> and another package SomePackage-dev for the library headers (and
>>>> import libraries on Windows)
>>>>
>>>> * The FindSomePackage.cmake file is part of the -dev package
>>>>
>>>> * After building, 0install moves each package's build products into a
>>>> mostly-unpredictable subdirectory of its otherwise-read-only "cache"
>>>> (~/.cache/0install.net/). The subdirectory's name is determined by a
>>>> hash of the files.
>>>>
>>>> * To get this working, I followed the scheme discussed here:
>>>>
>>>> http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l
>>>> uannocracy.com%3e
>>>>
>>>> Summary:
>>>>
>>>> 1. Create a 0install "SomePackage-preinstall" package. Building this
>>>> package involves CMake building and installing both SomePackage and
>>>> SomePackage-dev into separate subdirectories (main/ and dev/) of
>>>> some prefix. 0install thereafter moves the whole directory tree
>>>> into its cache in a directory called sha1=someuglyhash
>>>>
>>>> 2. SomePackage's 0installation procedure is to copy
>>>> sha1=someuglyhash/main/ into its distribution directory (which then ends
>>>> up in
>>>> ~/.cache/0install.net/sha1=otheruglyhash)
>>>>
>>>> 3. SomePackage-dev's 0installation procedure is to copy
>>>> sha1=someuglyhash/dev/ into its distribution directory
>>>>
>>>> Problem: FindSomePackageConfig.cmake now has the wrong path to the
>>>> library binaries.
>>>>
>>>> Any help most appreciated.
>>>
>>> Can you please summarize what you actually want to achieve ?
>>
>> Well, I tried to, above.
>>
>> In short, I want to create separate main and -dev packages without
>> building twice, under the constraints imposed by 0install.
>>
>>> Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ?
>>>
>>> If that's the case, then this is wrong.
>>
>> I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
>> libFoo.devel
>>
>>> FindFoo.cmake must be part of the using software, not of the software to be
>>> searched.
>>>
>>> Why do you have to find the installed library in this cache directory
>>> ?
>>
>> Because, in a 0install world, that's where things go when you "install"
>> them.
>>
>
> Ok, how you do it along these lines:
>
> CMakeLists.txt:
> #-- BOF
>
> cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
> project(Foo)
>
> set(FOO_VERSION 1.2.3)
>
> # initialize (absolute) installation directory variables
> set(INSTALL_BIN_DIR bin CACHE PATH "Install path for binaries")
> set(INSTALL_LIB_DIR lib CACHE PATH "Install path for libraries")
> set(INSTALL_INCLUDE_DIR include CACHE PATH "Install path for headers")
> # this is for UNIX systems, see docs of find_package() for the search
> # paths on APPLE and WIN32
> set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
> "Install path for CMake files")
> foreach(t BIN LIB INCLUDE CMAKE)
> if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
> set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
> endif()
> mark_as_advanced(INSTALL_${t}_DIR)
> endforeach()
>
> # configure FooConfig.cmake and friends. FooConfig.cmake must be able
> # to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
> # directory without using absolute paths.
> configure_file(cmake/FooConfig.cmake.in
> ${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
> configure_file(cmake/FooConfigVersion.cmake.in
> ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
>
> # configure the headers into the build tree so the package can b
Re: [CMake] Package installation conundrum
on Tue May 08 2012, Alexander Neundorf wrote: > On Tuesday 08 May 2012, Dave Abrahams wrote: > >> Here's another one! >> >> Scenario: >> >> * I am running CMake under 0install to build and install libraries >> >> * Each library builds a package SomePackage for the library binaries >> and another package SomePackage-dev for the library headers (and >> import libraries on Windows) >> >> * The FindSomePackage.cmake file is part of the -dev package >> >> * After building, 0install moves each package's build products into a >> mostly-unpredictable subdirectory of its otherwise-read-only "cache" >> (~/.cache/0install.net/). The subdirectory's name is determined by a >> hash of the files. >> >> * To get this working, I followed the scheme discussed here: >> >> http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l >> uannocracy.com%3e >> >> Summary: >> >> 1. Create a 0install "SomePackage-preinstall" package. Building this >> package involves CMake building and installing both SomePackage and >> SomePackage-dev into separate subdirectories (main/ and dev/) of >> some prefix. 0install thereafter moves the whole directory tree >> into its cache in a directory called sha1=someuglyhash >> >> 2. SomePackage's 0installation procedure is to copy >> sha1=someuglyhash/main/ into its distribution directory (which then ends >> up in >> ~/.cache/0install.net/sha1=otheruglyhash) >> >> 3. SomePackage-dev's 0installation procedure is to copy >> sha1=someuglyhash/dev/ into its distribution directory >> >> Problem: FindSomePackageConfig.cmake now has the wrong path to the >> library binaries. >> >> Any help most appreciated. > > Can you please summarize what you actually want to achieve ? Well, I tried to, above. In short, I want to create separate main and -dev packages without building twice, under the constraints imposed by 0install. > Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ? > > If that's the case, then this is wrong. I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of libFoo.devel > FindFoo.cmake must be part of the using software, not of the software to be > searched. > > Why do you have to find the installed library in this cache directory > ? Because, in a 0install world, that's where things go when you "install" them. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Package installation conundrum
Here's another one! Scenario: * I am running CMake under 0install to build and install libraries * Each library builds a package SomePackage for the library binaries and another package SomePackage-dev for the library headers (and import libraries on Windows) * The FindSomePackage.cmake file is part of the -dev package * After building, 0install moves each package's build products into a mostly-unpredictable subdirectory of its otherwise-read-only "cache" (~/.cache/0install.net/). The subdirectory's name is determined by a hash of the files. * To get this working, I followed the scheme discussed here: http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.luannocracy.com%3e Summary: 1. Create a 0install "SomePackage-preinstall" package. Building this package involves CMake building and installing both SomePackage and SomePackage-dev into separate subdirectories (main/ and dev/) of some prefix. 0install thereafter moves the whole directory tree into its cache in a directory called sha1=someuglyhash 2. SomePackage's 0installation procedure is to copy sha1=someuglyhash/main/ into its distribution directory (which then ends up in ~/.cache/0install.net/sha1=otheruglyhash) 3. SomePackage-dev's 0installation procedure is to copy sha1=someuglyhash/dev/ into its distribution directory Problem: FindSomePackageConfig.cmake now has the wrong path to the library binaries. Any help most appreciated. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] relocatable build directory: howto?
on Sat May 05 2012, Clinton Stimpson wrote: > On May 5, 2012, at 5:52 AM, Dave Abrahams wrote: > >> >> on Sat May 05 2012, Michael Wild >> wrote: >> >>> On 05/05/2012 07:25 AM, Dave Abrahams wrote: >>>> >>>> I need to preserve the built-but-not-yet-installed state of some >>>> projects, and the tool I'm driving CMake with moves the result of every >>>> build step from a read-write build directory into a readonly cache. The >>>> result is that the generated cmake_install.cmake files no longer work, >>> >>>> because they are full of absolute paths. I wrote a simple program to >>>> adjust the paths in the cmake_install.cmake files as a postprocessing >>>> step, replacing $CWD, where it is found, with a cmake variable. The >>>> only problem: on my Mac, /tmp is a symlink to /private/tmp, and in some >>>> scenarios the absolute path in cmake_install.cmake is the short one >>>> wheras while $CWD is the long one. No match :( >>>> >>>> I started to write some code to address this problem, but it's getting >>>> complex to the point where it seems like "there must be a better way." >>>> So I ask: is there? >>>> >>>> Thanks in advance, >>>> >>> >>> I'm afraid that the answer is no. There is the variable >>> CMAKE_USE_RELATIVE_PATHS, but that is broken and does not work in >>> general. Just out of curiosity: Why do you need to cache the build tree >>> in the first place? >> >> I'm driving CMake with a package installation system (0install) that >> doesn't allow for subpackages (it may someday, but that's not supported >> as of now). This system installs packages into a cache. It's >> undesirable to have to build a cmake package twice just to produce its >> -dev (on windows, includes import libraries) and -bin (includes >> DLLs/so's) incarnations. The way we deal with that now is to make the >> preinstall (built) state a separate 0install package and let 0install >> put that in the cache, then come back later and install from that >> package. >> >> Which reminds me; it would be awesome if there were a way to get cmake >> to clean everything but the leaves in its dependency graph. IOW, I'd >> like to throw out all the .o files after having built libraries. Is >> there a way? >> >>> Would it be enough to "make install DESTDIR=/path/to/cache"? >> >> Only if I want to build twice. >> > > In case its applicable, I just thought I'd mention that you can run > "cmake -P cmake_install.cmake " I am in fact using that command to do the final installation... > if you want to customize the installation of the files, even putting > the -dev files in one place and the -bin in another, then run you own > packaging tool on those directories afterwards. ...but I hadn't thought of "installing" everything as part of creating the pre-installed state and then having the "installed" state draw from those results. That's a very interesting idea. I'll try it, thanks. The other advantage is that we won't keep a bunch of .o files around in the cache (though we will still have two copies of the libraries until we can figure out how to flush the preinstalled state). > Maybe you could cache those directories instead of the build tree, or > was there something else you still needed from the build tree? No, as far as I know, that's going to work. P.S. The people on this list are terrific. I'm very grateful for the responsive help I've gotten over the past few days. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] relocatable build directory: howto?
on Sat May 05 2012, Michael Wild wrote: > On 05/05/2012 07:25 AM, Dave Abrahams wrote: >> >> I need to preserve the built-but-not-yet-installed state of some >> projects, and the tool I'm driving CMake with moves the result of every >> build step from a read-write build directory into a readonly cache. The >> result is that the generated cmake_install.cmake files no longer work, > >> because they are full of absolute paths. I wrote a simple program to >> adjust the paths in the cmake_install.cmake files as a postprocessing >> step, replacing $CWD, where it is found, with a cmake variable. The >> only problem: on my Mac, /tmp is a symlink to /private/tmp, and in some >> scenarios the absolute path in cmake_install.cmake is the short one >> wheras while $CWD is the long one. No match :( >> >> I started to write some code to address this problem, but it's getting >> complex to the point where it seems like "there must be a better way." >> So I ask: is there? >> >> Thanks in advance, >> > > I'm afraid that the answer is no. There is the variable > CMAKE_USE_RELATIVE_PATHS, but that is broken and does not work in > general. Just out of curiosity: Why do you need to cache the build tree > in the first place? I'm driving CMake with a package installation system (0install) that doesn't allow for subpackages (it may someday, but that's not supported as of now). This system installs packages into a cache. It's undesirable to have to build a cmake package twice just to produce its -dev (on windows, includes import libraries) and -bin (includes DLLs/so's) incarnations. The way we deal with that now is to make the preinstall (built) state a separate 0install package and let 0install put that in the cache, then come back later and install from that package. Which reminds me; it would be awesome if there were a way to get cmake to clean everything but the leaves in its dependency graph. IOW, I'd like to throw out all the .o files after having built libraries. Is there a way? > Would it be enough to "make install DESTDIR=/path/to/cache"? Only if I want to build twice. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automatable way to specify parallel --builds
on Sat May 05 2012, Michael Wild wrote: > On 05/05/2012 08:25 AM, Dave Abrahams wrote: >> >> I am driving invocations of cmake with another tool, and I would like to >> pass the equivalent of -jN for the "cmake --build" step, but I don't >> seem to be about to find out what generator will be used, which makes it >> hard to even write code to generate the right command line options. Can >> anyone help? >> >> Thanks! >> > > When you run CMake to configure the project, you can select the > generator with -G. Does that help? Hmm, for some reason I didn't think of doing that, but I guess it might help, thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] automatable way to specify parallel --builds
I am driving invocations of cmake with another tool, and I would like to pass the equivalent of -jN for the "cmake --build" step, but I don't seem to be about to find out what generator will be used, which makes it hard to even write code to generate the right command line options. Can anyone help? Thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] relocatable build directory: howto?
I need to preserve the built-but-not-yet-installed state of some projects, and the tool I'm driving CMake with moves the result of every build step from a read-write build directory into a readonly cache. The result is that the generated cmake_install.cmake files no longer work, because they are full of absolute paths. I wrote a simple program to adjust the paths in the cmake_install.cmake files as a postprocessing step, replacing $CWD, where it is found, with a cmake variable. The only problem: on my Mac, /tmp is a symlink to /private/tmp, and in some scenarios the absolute path in cmake_install.cmake is the short one wheras while $CWD is the long one. No match :( I started to write some code to address this problem, but it's getting complex to the point where it seems like "there must be a better way." So I ask: is there? Thanks in advance, -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_package scoping mystery
on Mon Apr 16 2012, Andreas Pakulat
wrote:
> On 16.04.12 06:04:33, Dave Abrahams wrote:
>>
>> on Mon Apr 16 2012, Andreas Pakulat
>> wrote:
>>
>> > On 16.04.12 01:37:58, Dave Abrahams wrote:
>> >>
>
>> >> consider this simple wrapper:
>> >>
>> >> function(my_find_package)
>> >> find_package(${ARGV})
>> >
>> >> endfunction()
>> >>
>> >> If I replace all the calls to find_package in my project with calls to
>> >> my_find_package, everything breaks. It appears variable settings in any
>> >> found Config.cmake files are visible inside
>> >> my_find_package, but disappear from the point of view of the caller,
>> >> unless I "manually" hoist them into the parent scope using
>> >>
>> >> function(my_find_package)
>> >> find_package(${ARGV})
>> >> set(some_variable ${some_variable} PARENT_SCOPE)
>> >> endfunction()
>> >>
>> >> I've tried hoisting everything as in
>> >> https://github.com/ryppl/ryppl-cmake/blob/find-package-hook/Modules/Ryppl.cmake#L9,
>> >> but apparently that is too much and it clobbers some variables that it
>> >> shouldn't.
>> >>
>> >> Can anyone explain to me what I'm failing to grasp, here?
>> >
>> > Functions have their own scope and the find module are written to be
>> > executed in the global scope. (functions are still a relatively new
>> > feature in cmake)
>>
>> That's one way of saying it. The other way of saying it is that
>> built-in functions are special and can't be emulated or wrapped if they
>> end up include()ing anything. The built-ins don't create a dynamic
>> scope, so set() commands in files they include end up having an effect
>> at global scope. The other other way of saying it is @#&(!&!%%*!... but
>> I digress.
>
> Well, thats the price to pay to keep existing CMake code still
> running.
It doesn't have to be. If there was a way to say "this function doesn't
create its own scope," I could create a wrapper for find_package that
doesn't interfere with its meaning. Then I wouldn't have to pay that
price.
> Backwards compatibility is valued very high for CMake and IMHO thats a
> good thing most of the time.
No doubt about it.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_package scoping mystery
on Mon Apr 16 2012, Andreas Pakulat
wrote:
> On 16.04.12 01:37:58, Dave Abrahams wrote:
>>
>> consider this simple wrapper:
>>
>> function(my_find_package)
>> find_package(${ARGV})
>
>> endfunction()
>>
>> If I replace all the calls to find_package in my project with calls to
>> my_find_package, everything breaks. It appears variable settings in any
>> found Config.cmake files are visible inside
>> my_find_package, but disappear from the point of view of the caller,
>> unless I "manually" hoist them into the parent scope using
>>
>> function(my_find_package)
>> find_package(${ARGV})
>> set(some_variable ${some_variable} PARENT_SCOPE)
>> endfunction()
>>
>> I've tried hoisting everything as in
>> https://github.com/ryppl/ryppl-cmake/blob/find-package-hook/Modules/Ryppl.cmake#L9,
>> but apparently that is too much and it clobbers some variables that it
>> shouldn't.
>>
>> Can anyone explain to me what I'm failing to grasp, here?
>
> Functions have their own scope and the find module are written to be
> executed in the global scope. (functions are still a relatively new
> feature in cmake)
That's one way of saying it. The other way of saying it is that
built-in functions are special and can't be emulated or wrapped if they
end up include()ing anything. The built-ins don't create a dynamic
scope, so set() commands in files they include end up having an effect
at global scope. The other other way of saying it is @#&(!&!%%*!... but
I digress.
>
> I can see a few options:
> - Don't run find_package inside a function.
> - Use a macro instead of a function, macro's do not create a new scope
Yeah... these are two ways of saying the same thing. I ended up with a
macro.
> - inspect all the find-modules you use and adapt them to use
> PARENT_SCOPE for variables when they do not end up in the cache.
Thanks for your help,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] find_package scoping mystery
consider this simple wrapper:
function(my_find_package)
find_package(${ARGV})
endfunction()
If I replace all the calls to find_package in my project with calls to
my_find_package, everything breaks. It appears variable settings in any
found Config.cmake files are visible inside
my_find_package, but disappear from the point of view of the caller,
unless I "manually" hoist them into the parent scope using
function(my_find_package)
find_package(${ARGV})
set(some_variable ${some_variable} PARENT_SCOPE)
endfunction()
I've tried hoisting everything as in
https://github.com/ryppl/ryppl-cmake/blob/find-package-hook/Modules/Ryppl.cmake#L9,
but apparently that is too much and it clobbers some variables that it
shouldn't.
Can anyone explain to me what I'm failing to grasp, here?
Thanks,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to identify MSVC-compatible compiler?
Is there a variable that will tell me when the compiler supports MSVC-compatible command-line flags? I'd like to have something cleaner than checking for WINDOWS AND ( MSVC OR INTEL ) If not, I can of course roll my own, but this seems like something that should be in CMake's "standard library." -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Support for MacRuby?
Macruby (http://macruby.org)'s installer is a bit unusual: It will install MacRuby in /Library/Frameworks and provide shortcuts to its executable utilities in /usr/local/bin, with a "mac" prefix. For example, "ruby" will be available as "macruby", and "irb" as "macirb". It would be nice if the find_package(ruby) command were able to find and use MacRuby if that is the newest Ruby installation. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
