Re: [CMake] Protobuf Module
On Wed, Oct 12, 2011 at 8:46 AM, James Anderson
wrote:
> PROTOBUF_GENERATE_CPP does not seem to work at all in ubuntu. I was working
> with 2.8.3 and since it wasn't working I have compiled the latest cmake
> (2.8.6) but still no luck. I also tried with --debug-output but after
> finding protobuf no other related output.
>
> Here's the relevant segment:
>
> FIND_PACKAGE(Protobuf)
>
> IF(PROTOBUF_FOUND)
>
> INCLUDE_DIRECTORIES(${PROTOBUF_INCLUDE_DIRS})
>
> INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
>
> PROTOBUF_GENERATE_CPP(PROTO_SRCS PROTO_HDRS data.proto)
>
> ENDIF()
>
>
> Yet the protoc compiler is never invoked and the data.pb.cc and .h files are
> never created (even tried without the IF statement).
>
>
James,
PROTO_SRCS & PROTO_HDRS (in the code snippit you list above) are simply
lists of source & header files to generate. You need to use them in a
target in order for CMake to cause them to be generated.
E.g.
add_executable(foo foo.cc ${PROTO_SRCS} ${PROTO_HDRS})
target_link_libraries(foo ${PROTOBUF_LIBRARIES})
Hope that solves your problem.
--
Philip Lowman
--
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] FindBoost PATH_SUFFIXES fix
On Wed, Jun 15, 2011 at 12:06 PM, Todd Gamblin wrote: Hi Todd, I'm the FindBoost maintainer. I was somewhat perplexed that FindBoost doesn't properly search the default > install layout of the boost-cmake build. i.e. if you set BOOST_ROOT to > point to something that looks like this: > > things will break. This is, unfortunately, the default install layout for > the CMake build of boost. The script only checks path suffixes under the > *include* directory, and it expects them to use underscores instead of > periods, e.g.: > I'm not sure exactly why boost-cmake decided to make their output directories use periods instead of underscores. It seems like a first step towards replacing bjam would at least be to match its install path format, but I digress. I've pasted below a patch that adds the version numbers with periods to the > list of searched path suffixes, and that uses the path suffix list for both > the library search and the header search. Any objections to my submitting > this as a topic branch and pushing it out to next? I'm not sure I have > permission to do that with the FindBoost module, so let me know what the > right procedure is. > The patch looks good. Feel free to submit it and push it to next. Thanks for asking for permission, by the way. In general, feel free to propose changes via email or even topic stages for FindBoost. I do welcome the help. I would like to review changes before they are pushed to next though (mainly to prevent people from breaking things). -- Philip Lowman ___ 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] CMakeDetermineVSServicePack.cmake
Aaron,
Thanks. Please see my comments in the ticket you reopened with the patch
you sent in yesterday.
BTW -- If you would like to volunteer to take ownership of this module I
would be happy to hand it over to someone else. Since I no longer use
Visual Studio I'm probably the wrong maintainer for this module.
http://www.itk.org/Wiki/CMake:Module_Maintainers
On Tue, Jun 7, 2011 at 1:53 PM, wrote:
> I’ve reopened Issue 0011279. CMakeDetermineVSServicePack.cmake has been
> broken again, this time by VS2010 switching to MSBuild. This has caused the
> version string to change. I’ve created a patch and uploaded it to the
> Issue:
>
>
>
> --8ß
> -
>
>
>
> --- CMakeDetermineVSServicePack.cmake 2011-06-06 17:40:02.92300 -0500
>
> +++ CMakeDetermineVSServicePackWithVS2010MSBuild.cmake 2011-06-06 17:47:
> 04.057552300 -0500
>
> @@ -47,7 +47,9 @@
>
> set(_version "vc90")
>
> elseif(${_cl_version} VERSION_EQUAL "15.00.30729.01")
>
> set(_version "vc90sp1")
>
> - elseif(${_cl_version} VERSION_EQUAL "16.00.30319.01")
>
> + elseif(${_cl_version} VERSION_EQUAL "16.00.30319.01") # Pre-release
> VS2010 version number
>
> + set(_version "vc100pre")
>
> + elseif(${_cl_version} VERSION_EQUAL "4.00.30319.01") # Release version
> of VS2010 which uses MSBuild version number
>
> set(_version "vc100")
>
> else()
>
> set(_version "")
>
> @@ -74,6 +76,13 @@
>
> if(DETERMINED_VS_SERVICE_PACK AND _output)
>
> string(REGEX MATCH "Compiler Version
> [0-9]+.[0-9]+.[0-9]+.[0-9]+"
>
> _cl_version "${_output}")
>
> +
>
> +# If the above didn't work, this may be VS 2010, which has a
> different output with MSBuild
>
> +if(NOT _cl_version)
>
> +string(REGEX MATCH "Build Engine Version
> [0-9]+.[0-9]+.[0-9]+.[0-9]+"
>
> +_cl_version "${_output}")
>
> +endif()
>
> +
>
> if(_cl_version)
>
> string(REGEX MATCHALL "[0-9]+"
>
> _cl_version_list "${_cl_version}")
>
>
>
>
>
>
>
> *Aaron Meadows*
> Software Engineer
>
> *Thomson Reuters*
>
> Phone: 314.468.3530
> Mobile: 636.541.6139
> aaron.mead...@thomsonreuters.com
> thomsonreuters.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
>
--
Philip Lowman
___
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] [CMake General][FindBoost] CMake and Boost 1.46.1
On Mon, May 2, 2011 at 1:53 AM, Robert Nelson wrote: > > try ... setting Boost_DEBUG On > Great suggestion! > > I looked at the debug output as you recommended and discovered that > findboost only searches for filenames that start with "boost" while > all the files in the lib directory start with "libboost" > > I copied and renamed the regex files in the lib directory to start > with "boost" instead and it found the regex library but not the > others. So a possible solution would be to rename all the files in > the folder. This, however, is less than elegant. > > Is this a breaking change in the way the boost library files are > named, a bug in findboost, or did I install boost wrong somehow? > On Windows, the boost convention is to prefix shared libraries with "boost" and static libraries with "libboost". By default FindBoost searches for shared libraries since this matches CMake default behavior on Unix platforms. If you want FindBoost to search for static libraries instead, simply set: set(Boost_USE_STATIC_LIBS ON) -- Philip Lowman ___ 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] [CMake General][FindBoost] CMake and Boost 1.46.1
FindBoost is a bit of a pain to get working.
I'm wondering if the REQUIRED and 1.46 in the find_package() is causing it
to skip 1.46.1? You could clear your cache and try changing the version to
1.46.1 or remove the REQUIRED.
If that's not it, try clearing your cache, setting Boost_DEBUG On and having
a look at the output and/or pasting it in here.
On Sun, May 1, 2011 at 5:18 PM, Robert Nelson wrote:
> I just tried adding
> SET(Boost_ADDITIONAL_VERSIONS 1.46.1)
> clearing the cache, and running configure again. I still get the same
> error message as before. While I agree that your addition is
> necessary to make it work, it seems that something else is also
> needed.
>
>
> PROJECT(schema)
> cmake_minimum_required(VERSION 2.8.4)
>
>
> SET( Boost_NO_SYSTEM_PATHS true )
> SET( BOOST_INCLUDEDIR "C:/Boost/include/boost-1_46_1" )
> SET( BOOST_LIBRARYDIR "C:/Boost/lib" )
> SET(Boost_ADDITIONAL_VERSIONS "1.46.1" )
> find_package(Boost 1.46 COMPONENTS regex program_options pthread
> filesystem REQUIRED)
>
> link_directories(${Boost_LIBRARY_DIRS} )
> include_directories( ${Boost_INCLUDE_DIRS} )
>
> #if you don't want the full compiler output, remove the following line
> SET(CMAKE_VERBOSE_MAKEFILE ON)
>
> add_executable(schema
> main.cpp
> )
> ___
> 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
>
--
Philip Lowman
___
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] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 5:06 PM, David Cole wrote: > Hello CMake users and devs, > > (And now for something completely different...) > > Controversial questions: > > - Should we eliminate the bug tracker entirely and just do all > discussion and patches on the mailing list? (Why have two sources of > information...?) > > - Or, alternatively, should we eliminate the bulk of mailing list > traffic, and insist on issues in the bug tracker being the main > conversational forum for the whole community? > > I'd like to have this discussion here publicly, to try to get a good > sense of varous community members attitudes and feelings. I like the bug tracker. Even people that use it, however, know that hitting up the mailing list tends to improve the chance that the bug is actually researched and fixed. Also, sometimes it seems wrong to take an issue raised on the mailing list and force it into the bug tracker. It seems a little rude to the person that emailed about the issue because you might be asking them to deal with the rigmarole of creating a mantis account when they already went through the hassle of joining the mailing list and making the post. -- Philip Lowman ___ 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] FindBoost: find both win32 and x64 static libs
On Sunday, December 5, 2010, Hicham Mouline wrote: > I've built both win32 and x64 versions of boost thread library with the > following 2 lines: > > 1. 32bit cl.exe from msvc9 directory in the %PATH% > bjam --with-thread --layout=versioned toolset=msvc address-model=64 > variant=release link=static threading=multi runtime-link=shared > > 2. 64bit cl.exe from msvc9 directory in the %PATH% > bjam --with-thread --layout=versioned toolset=msvc address-model=64 > variant=release link=static threading=multi runtime-link=shared > > however, the resulting .lib files have identical names however: > libboost_thread-vc90-mt-1_44.lib > libboost_thread-vc90-mt.lib > > Dmytro, there is no distinction between 32bit and 64bit. The 64bit lib size > is approximately double the 32bit lib. > > boost-build, how to change this to include the bitness in the boost lib > name? > If it's impossible, Philip, perhaps FindBoost could be changed to allow for > different directories under BOOST_ROOT for the lib directories, something > like lib\win32 and lib\x64 or whatever names can be agreed on. If the user is compiling 32-bit code I could make FindBoost search "lib32" before "lib" and for 64-bit code I can make it search "lib64" before "lib". If the user had an empty lib64 directory for some reason, it would still find the boost libraries in "lib". Would this work for you? The BOOST_LIBRARYDIR variable is the only other workaround I can think to this issue. ___ 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] Wiki: version compatibility matrix
Wow. Thank you for making this. I think it will be a huge resource for CMake users. Nothing is more annoying than having to track down when something was added, or not realizing that the behavior that you rely upon did not exist in a previous version. On Saturday, December 4, 2010, Johannes Zarl wrote: > Hello, > > The compatibility matrix for different versions of cmake is now complete and > awaits review: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix > > Apart from factual errors and things I might have missed, I am also interested > if someone has a better idea for embedding the comments: they make the tables > broader than they need to be. Also, the wiki warns that the page might be to > big for some browsers. Should the page be divided into subpages? > > If no one objects, I will add a link to the main-page under "Development > Topics" by Wednesday next week (2010-12-08). > > Cheers, > Johannes > ___ > 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 > -- Philip Lowman ___ 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] FindBoost: find both win32 and x64 static libs
On Saturday, December 4, 2010, Hicham Mouline wrote: > > I was wrong. Dmytro pointed out that bjam allows building boost > libraries with the compiler and bitness in the boost library name > --layout=versioned. > > Therefore, I could have both 32 and 64bit versions in the same > directory. > > I wonder then if FindBoost is able to detect automatically the > right ones based on the name of the libs. I could probably add this feature, I'm pretty sure there isn't support for it now. Could you create a feature request on the CMake bug tracker and include what the filenames look like when generated by visual studio? If you want to try to patch FindBoost yourself, please make sure you're playing with the version from 2.8.3. http://www.cmake.org/Bug -- Philip Lowman ___ 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] FindBoost: find both win32 and x64 static libs
On Tue, Nov 30, 2010 at 5:37 PM, Hicham Mouline wrote:
> As boost libraries naming convention doesn't include in the lib names
> whether they are built by msvc9 win32 or x64, I am forced on a winxp 64 box
> where I hold both versions to have a different lib directory under
> boost_root.
>
> I set BOOST_ROOT then call FIND_PACKAGE(Boost 1.44 COMPONENTS ...).
>
> Am I supposed to detect which of vc9 32bit or 64bit am I generating for
> and then set BOOST_LIBRARYDIR depending on that before calling FIND_PACKAGE?
>
> How do I detect bitness?
>
You could try something like this:
include(CheckTypeSize)
CHECK_TYPE_SIZE(void* SIZEOF_PTR)
message("size of pointer = ${SIZEOF_PTR}")
Then if SIZEOF_PTR is 4, you would set BOOST_LIBRARYDIR to be
${BOOST_ROOT}/lib32 and if it is 8, you set it to ${BOOST_ROOT}/lib64.
--
Philip Lowman
___
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] Makefile to CMakeLists.txt (GTEST)
On Wed, Dec 1, 2010 at 10:59 AM, Kevyn-Alexandre Paré <
kap...@rogue-research.com> wrote:
> Philip,
>
> Thx for the reply. Neither of these solutions change a thing.
>
> I try to play with ADD_CUSTOM_TARGET but same error...
>
> ADD_CUSTOM_TARGET(RRThread.o ALL COMMAND ${CMAKE_C_COMPILER} -I
> ${MICRONTRACKER_COMMON_PATH} -I${GTEST_HEADER_PATH} -lpthread -c
> ${MICRONTRACKER_COMMON_PATH}RRThread.c
> ${UNIT_TEST_PATH}common/UT_RRThread.cc)
>
> ADD_CUSTOM_TARGET(UT_RRThread ALL COMMAND ${CMAKE_CXX_COMPILER} -I
> ${MICRONTRACKER_COMMON_PATH} -I${GTEST_HEADER_PATH} -lpthread RRThread.o
> UT_RRThread.o ${GTEST_LIB_PATH}gtest.a ${GTEST_LIB_PATH}gtest_main.a -o
> UT_RRThread)
>
> Result:
> UT_RRThread.o: In function `thread_proc(void*)':
> UT_RRThread.cc:(.text+0x28): undefined reference to `exitThread()'
> ...
>
>
I'm not sure what exactly has gone wrong here. You might want to try to
find the exitThread symbol to see where it lives using "nm" or "strings" on
the libraries that you have. If all else fails, perhaps check on a GTest
forum? I've never had this problem before but I don't recall ever using the
gtest static libraries either.
> I pretty sure that I'm missing little detail. How can I implicitly add
> dependency to the object during the linking?
>
I don't see anything wrong with what you have in terms of the GCC
invocation. You'll need to explicitly specify the libraries during compile
time to resolve those symbols and produce a binary as far as I know.
I'm not sure why you're using add_custom_target() when you could just use
add_executable() and target_link_libraries(), but I doubt this has anything
to do with your undefined symbol reference.
--
Philip Lowman
___
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] Makefile to CMakeLists.txt (GTEST)
Try adding the "gtest.a" library as well. Also, order does matter when you
are linking static libraries so you might need to play with the ordering.
Also, when you get some time, have a look at FindGTest.cmake. It may help
you simplify adding your tests.
On Mon, Nov 29, 2010 at 5:55 PM, Kevyn-Alexandre Paré <
kap...@rogue-research.com> wrote:
> Hi,
>
> /// -> What I trying to do is to compile my unit test with google test
> with cmake from a working Makefile.
>
> /// -> Here the Makefile
>
> RRThread.o : $(USER_DIR)/RRThread.c $(USER_DIR)/RRThread.h
> $(GTEST_HEADERS)
>$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/RRThread.c
>
> UT_RRThread.o : $(UNITTEST_DIR)/UT_RRThread.cc \
> $(USER_DIR)/RRThread.h $(GTEST_HEADERS)#
>$(CXX) $(CPPFLAGS) $(CXXFLAGS) -I$(USER_DIR) -c
> $(UNITTEST_DIR)/UT_RRThread.cc
>
> UT_RRThread : RRThread.o UT_RRThread.o gtest_main.a
>$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
>
>
> /// -> Here how I thought of doing it with CMakeLists.txt:::
>
> INCLUDE_DIRECTORIES(${GTEST_HEADER} ${USER_DIR})
>
> ADD_EXECUTABLE(UT ${USER_DIR}RRThread.c ${UNIT_TEST_PATH}UT_RRThread.cc)
>
> TARGET_LINK_LIBRARIES(UT pthread ${GTEST_LIB_PATH}gtest_main.a)
>
> /// -> My result:
>
> Linking CXX executable UT
> /usr/bin/cmake -E cmake_link_script CMakeFiles/UT.dir/link.txt
> --verbose=1
> /usr/bin/c++ CMakeFiles/UT.dir/common/RRThread.c.o
> CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o -o UT -rdynamic
> -lpthread
> /home/andromeda/rogue-research/3rdParty/gtest/trunk/Release/lib/gtest_main.a
> CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o: In function
> `thread_proc(void*)':
> UT_RRThread.cc:(.text+0x28): undefined reference to `exitThread()'
>
>
> /// -> My question and my problem is:
> Since I'm including the USER_DIR with INCLUDE_DIRECTORIES why is it
> complaining about not finding reference that is in that header file?
>
>
> Best Regards,
>
> --
> Kevyn-Alexandre Paré
>
> ___
> 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
--
Philip Lowman
___
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] Eciipse and multiple configuration
You really can't, unfortunately because only one configuration is possible per CMake build directory with the Makefile generator. Most people set CMAKE_BUILD_TYPE to Debug when using the Eclipse CDT4 Generator so they can debug. If you need to test regularly with release binaries, one solution is to create a second build directory with CMAKE_BUILD_TYPE set to Release pointing it to the same source tree as your Debug build. On Tue, Nov 16, 2010 at 7:09 AM, Andrea Galeazzi wrote: > I followed the tutorial at > http://www.cmake.org/Wiki/Eclipse_CDT4_Generator in order to generate an > Eclipse project. > The only difference is that I select eclipseCDT - MiinGW Makefiles instead > of eclipseCDT -Unix Makefiles". > What I don't understand is how can I manage multiple configurations in the > same project (for example Debug/Release) if the cmake-gui requires a > specific CMAKE_BUILD_TYPE. > Sorry but I'm a CMake newbie.. > ___ > 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 > -- Philip Lowman ___ 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...
On Sun, Nov 7, 2010 at 8:29 PM, Luigi Calori wrote: > On 07/11/2010 21.01, Philip Lowman wrote: > > On Fri, Nov 5, 2010 at 12:08 PM, Luigi Calori wrote: > >> +1 for FindBoost support to "CMakeified" version of Boost at " >>> http://gitorious.org/~denisarnaud/boost/denisarnauds-zeuners-boost-cmake/commits/1.44.0-denis<http://gitorious.org/%7Edenisarnaud/boost/denisarnauds-zeuners-boost-cmake/commits/1.44.0-denis> >>> ": >> >> > Luigi, > > Does the "CMakeified" version of Boost still not produce build outputs > that match bjam by default? I remember when I looked at it a year or two > ago there appeared to be only minor issues with the library names. I would > have hoped that these issues would have been resolved by now. > > I just tried the build with cmake 2.8.2 under MSVC9 using release build > and static linking: > There seem to be a minor inconsistency: when building Boost with cmake the > static libs do not have the prefix "lib" so boost the auto-linking fails. > I have resolved by > > 1) when building boos, configure with -DLIBPREFIX=lib, > > 2) configure the project that search for boost with > -DBoost_USE_STATIC_LIBS=ON > > During the installation step of "cmakefied" boost, Boost.cmake config > files get installed but not sure if FindBoost use it > > I' m not sure if this can be solved in FindBoost, but was just raising > attention on a (for me) much better build system for Boost > Luigi, Thanks for the additional information. It sounds like a bug in the CMake build system for Boost. On WIN32 (but not CYGWIN) it should create static boost libraries with the lib prefix and shared boost libraries without it to match the long-established Boost/bjam conventions. This allows static & shared libraries to exist alongside each other in the lib folder since otherwise their filenames would collide. -- Philip Lowman ___ 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...
On Fri, Nov 5, 2010 at 6:29 AM, Adam J Richardson wrote: > Could you guys have a chat with the Boost guys and fix the "future > safety" of FindBoost.cmake somehow? Fiddling with ADDITIONAL_VERSIONS > is really a pain on a build farm. > To implement this I think we would need wildcat version searching support for find_library() and friends. I had a proposal for this a while ago but it didn't go anywhere nor did I ever implement it. http://www.itk.org/Bug/view.php?id=8396 I suggested that support for searching for files or directories that match a particular regex that describes a version number be added. In other words, you could try to find: NAMES foo-([0-9])\.([0-9]) or PATHS bar([0-9]+) The module would be responsible of passing on the request to find the latest version number that matches, or it could specify an absolute version to find. It would probably have to be an extended form of the find_library(), find_path(), etc. commands. -- Philip Lowman ___ 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...
On Fri, Nov 5, 2010 at 12:08 PM, Luigi Calori wrote: > +1 for FindBoost support to "CMakeified" version of Boost at " >> http://gitorious.org/~denisarnaud/boost/denisarnauds-zeuners-boost-cmake/commits/1.44.0-denis >> ": > > Luigi, Does the "CMakeified" version of Boost still not produce build outputs that match bjam by default? I remember when I looked at it a year or two ago there appeared to be only minor issues with the library names. I would have hoped that these issues would have been resolved by now. Could you elaborate in a bug report what does and doesn't work between FindBoost.cmake and the branch of Boost that you're referring to and I would be more than happy to look into the issue. I've heard reports of people getting FindBoost and CMakeified boost to play nice together but it involved changing build settings in CMakeified Boost (not quite ideal). -- Philip Lowman ___ 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] Linking Boost on Linux on 64bit host and 32bit target
On Thu, Nov 4, 2010 at 12:31 PM, Michael Jackson < mike.jack...@bluequartz.net> wrote: > Clean out your build folder first. > export BOOST_ROOT=/home/kknox/sdk/boost_1_44_0 > ==> that needs to be an actual "installation", a staged area will probably > NOT work to find boost as FindBoost is looking for a very specific path > within BOOST_ROOT and if that path is NOT found then it will probably fall > back on the system paths. > FindBoost.cmake in CMake 2.8.3 supports a new option to prevent searching the system paths. You should enable it if you are 100% sure that you will never want to find something outside of BOOST_ROOT, CMAKE_PREFIX_PATH, etc. Boost_NO_SYSTEM_PATHS There was a bug related to not finding Boost libraries in a staging area. I believe this works now. Also, take a moment and set this new variable appropriately (nearly all users will want it to be OFF) Boost_USE_STATIC_RUNTIME -- Philip Lowman ___ 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] Linking Boost on Linux on 64bit host and 32bit
Can you grab the FindBoost.cmake with CMake 2.8.3, then set the following (new) variable and paste the debug output again? This will at least prevent it from finding stuff in /usr/lib which has been an issue for some people. Also there is more debugging now. http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindBoost.cmake;h=3ae4e1410b9ec04b81dc76ddf822601f17f173c1;hb=b58e44edfb8e4267028a4754a25114d3bfad0abe set(Boost_NO_SYSTEM_PATHS TRUE) Offhand, I think you're on the right track using BOOST_LIBRARYDIR to override the search path for your 32 vs. 64 bit directories. That should show up first in the search path list. On Thu, Nov 4, 2010 at 3:37 PM, Knox, Kent wrote: > [Michael] > # set( Boost_DEBUG ON ) > Uncomment that and send the output. Yes, it will be A LOT of output but I > am trying to figure out what is going wrong. > > [Kent] I took out the explicit setting of BOOST_LIBRARYDIR: > > kk...@ux2 ~/code/clAMD/trunk/bin/linux32 > 561 > InitCmake.sh > -- 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 > -- UNICODE feature disabled on linux > -- 64-bit build > -- [ FindBoost.cmake:373 ] Boost not in cache > -- [ FindBoost.cmake:376 ] _boost_TEST_VERSIONS = > 1.44;1.44.0;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 > -- [ FindBoost.cmake:378 ] Boost_USE_MULTITHREADED = ON > -- [ FindBoost.cmake:380 ] Boost_USE_STATIC_LIBS = ON > -- [ FindBoost.cmake:439 ] Declared as CMake or Environmental Variables: > -- [ FindBoost.cmake:441 ] BOOST_ROOT = /home/kknox/sdk/boost_1_44_0 > -- [ FindBoost.cmake:443 ] BOOST_INCLUDEDIR = > -- [ FindBoost.cmake:445 ] BOOST_LIBRARYDIR = > -- [ FindBoost.cmake:447 ] _boost_TEST_VERSIONS = > 1.44;1.44.0;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 > -- [FindBoost.cmake:496 ] Include debugging info: > -- [FindBoost.cmake:498 ] _boost_INCLUDE_SEARCH_DIRS = > /home/kknox/sdk/boost_1_44_0/include;/home/kknox/sdk/boost_1_44_0;C:/boost/include;C:/boost;/boost/include;/boost;/sw/local/include > -- [ FindBoost.cmake:500 ] _boost_PATH_SUFFIXES = > boost-1_44;boost-1_44_0;boost-1_41_0;boost-1_41;boost-1_40_0;boost-1_40;boost-1_39_0;boost-1_39;boost-1_38_0;boost-1_38;boost-1_37_0;boost-1_37;boost-1_36_1;boost-1_36_0;boost-1_36;boost-1_35_1;boost-1_35_0;boost-1_35;boost-1_34_1;boost-1_34_0;boost-1_34;boost-1_33_1;boost-1_33_0;boost-1_33 > -- [FindBoost.cmake:524 ] location of version.hpp: > /home/kknox/sdk/boost_1_44_0/boost/version.hpp > -- [FindBoost.cmake:543 ] version.hpp reveals boost 1.44.0 > -- [FindBoost.cmake:634 ] guessed _boost_COMPILER = -gcc44 > -- [FindBoost.cmake:644 ] _boost_MULTITHREADED = -mt > -- [FindBoost.cmake:661 ] _boost_STATIC_TAG = > -- [FindBoost.cmake:663 ] _boost_ABI_TAG = d > -- [FindBoost.cmake:696 ] _boost_LIBRARIES_SEARCH_DIRS = > /home/kknox/sdk/boost_1_44_0/lib;/home/kknox/sdk/boost_1_44_0/stage/lib;/home/kknox/sdk/boost_1_44_0/lib;/home/kknox/sdk/boost_1_44_0/../lib;C:/boost/lib;C:/boost;/boost > > /boost_1_44_0/lib;/boost/boost_1_44/lib;/boost/lib;/boost;/sw/local/lib > -- [ FindBoost.cmake:830 ] Boost_FOUND = TRUE > -- Boost version: 1.44.0 > -- Found the following Boost libraries: > -- program_options > -- Boost_PROGRAM_OPTIONS_LIBRARY: /usr/lib/libboost_program_options-mt.a > -- Found FFTW: /usr/lib/libfftw3f.so > -- Found GTest: /usr/lib/libgtest.so > -- Detected GNU fortran compiler. > -- CMAKE_CXX_COMPILER flags: -m64 > -- CMAKE_CXX_COMPILER debug flags: -g > -- CMAKE_CXX_COMPILER release flags: -O3 -DNDEBUG > -- CMAKE_CXX_COMPILER relwithdebinfo flags: -O2 -g > -- CMAKE_EXE_LINKER link flags: > -- Boost_LIBRARIES: /usr/lib/libboost_program_options-mt.a > -- Boost_PROGRAM_OPTIONS_LIBRARY: /usr/lib/libboost_program_options-mt.a > -- Configuring done > -- Generating done > -- Build files have been written to: /home/kknox/code/clAMD/trunk > /bin/linux32 > > I've shortened the FindBoost.cmake path to make it more readable: > originally > [/home/kknox/bin/cmake-2.8.2-Linux-i386/share/cmake-2.8/Modules/FindBoost.cmake] > > Kent > > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://ww
Re: [CMake] Disallowing in-source builds
On Thu, Oct 7, 2010 at 3:19 AM, Michael Wild wrote:
>
> On 6. Oct, 2010, at 20:10 , <
> aaron.mead...@thomsonreuters.com> wrote:
>
> > Hi all.
> >
> >
> >
> > Is there a good way to disallow in-source builds? Ideally, I'd like to
> > prevent it before any cruft is written into the source tree. I
> > experimented with writing a function into my CMakelists file and calling
> > it. The function checked if CMAKE_BINARY_DIR was equal to
> > CMAKE_SOURCE_DIR and messaged a FATAL_ERROR if that was the case. This
> > works ok, but still generates a CMakeFiles directory and a
> > CMakeCache.txt file.
>
> I don't think there's a way to prevent that from happening. The bad thing
> about this is that if the user doesn't clean away the in-source
> CMakeCache.txt file, subsequent out-of-source builds will fail. Perhaps you
> can do something like this:
>
> # check for polluted source tree
> if(EXISTS ${CMAKE_SOURCE_DIR}/CMakeCache.txt OR
>EXISTS ${CMAKE_SOURCE_DIR}/CMakeFiles)
> message(FATAL_ERROR
>"CMakeCache.txt or CMakeFiles exists in source directory!")
> endif()
> # make sure the user doesn't play dirty with symlinks
> get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH)
> get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH)
> # disallow in-source builds
> if(${srcdir} STREQUAL ${bindir})
> message(FATAL_ERROR "In-source builds are forbidden!")
> endif()
>
> >
> > The second half of the question is of course, is there an easy way to
> > clean out a source tree if an in-source build was accidentally kicked
> > off? (short of dividing the files by their timestamp and removing the
> > newer ones, etc..)
>
> No, simply because CMake cannot. Your build system might have something
> like the following:
>
> execute_process(COMMAND echo "BOOM" > ${CMAKE_BINARY_DIR}/boom.txt
> VERBATIM)
>
> CMake never knows that the file boom.txt is written, and therefor can't
> clean it away.
I think this is a bit of a red herring. CMake could be perfectly capable of
cleaning up after itself (i.e. its own files).
If the user is doing things like making a bunch of files that CMake isn't
aware of (that aren't generated), these could be added to
ADDITIONAL_MAKE_CLEAN_FILES, or a new property could be added for custom
files that are to be deleted on a distclean.
--
Philip Lowman
___
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] Disallowing in-source builds
On Wed, Oct 6, 2010 at 2:10 PM, wrote: > *Hi all.* > > * * > > *Is there a good way to disallow in-source builds? Ideally, I’d like to > prevent it before any cruft is written into the source tree. I experimented > with writing a function into my CMakelists file and calling it. The > function checked if CMAKE_BINARY_DIR was equal to CMAKE_SOURCE_DIR and > messaged a FATAL_ERROR if that was the case. This works ok, but still > generates a CMakeFiles directory and a CMakeCache.txt file.* > > * **The second half of the question is of course, is there an easy way to > clean out a source tree if an in-source build was accidentally kicked off? > (short of dividing the files by their timestamp and removing the newer ones, > etc..)* > CMake doesn't have a command to clean up after itself which seems to be what you're asking for (it would help for both use-cases you specify). This is kind of related to my ticket asking for a distclean target, so I'll just throw it out there in case anyone has some free time on their hands. http://www.cmake.org/Bug/view.php?id=6647 -- Philip Lowman ___ 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] Boost Library Search
On Wed, Oct 6, 2010 at 7:55 PM, assume_R wrote: > Hey all. So I noticed a possible bug with the way boost is searched in > findboost.cmake. > > Essentially, if you have the boost static runtimes installed, that's what > Visual Studio will require. For example, using the thread library, it will > need libboost_thread*-sgd* > > Yet the non-static-runtime versions are what are searched first, so it only > finds libboost_thread*-gd*, and visual studio will give you a link error. > Yes, this is issue #11204. FindBoost searches for static libraries first with the -gd & then -sgd prefix in that order when Boost_USE_STATIC_LIBS is enabled. There was no way to specify if you preferred the static library built against a dynamic runtime, or the static library built against a static runtime. http://www.cmake.org/Bug/view.php?id=11204 Changing the behavior the way you specified could potentially break people that prefer the static boost libraries but with a dynamic runtime, so a better solution was needed. The new version of FindBoost (which is in 2.8.3-rc2) allows you to set a new option (Boost_USE_STATIC_RUNTIME) which allows picking either a static or dynamic runtime. By default FindBoost maintains existing behavior of searching for dynamic then static on WIN32 (since that is the only platform we had this behavior before). On other platforms this wasn't an issue and the dynamic runtime was always used so the existing behavior is maintained there since the user must opt-in to setting Boost_USE_STATIC_RUNTIME. If you try out FindBoost in 2.8.3-rc2 you'll see a reference to Boost_COMPAT_STATIC_RUNTIME which disables the double search behavior if set to OFF. You can set this to OFF for now, but I realized the variable is redundant so if there are more RC's for CMake 2.8.3, I plan on removing it and just counting on if the user has defined Boost_USE_STATIC_RUNTIME or not (regardless if they set it ON or OFF) to disable the "double" search on WIN32. -- Philip Lowman ___ 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] CMakeDetermineVSServicePack.cmake support for vs2010
On Thu, Sep 30, 2010 at 11:04 AM, wrote: > *Done. Issue number 11279. [ > http://public.kitware.com/Bug/view.php?id=11279]* > > * * > > *I also noted that the script could be improved by calling the compiler > with the ‘/?’ switch and parsing it’s output instead of parsing the output > from try_compile’ing a simple c file it writes. That would make it quite a > bit faster.* > Aaron, Thanks for the patch. I've pushed it to git next. Regarding your idea to use the output of "cl /?" to determine the version number, I think it is a good one. If you have time to rewrite the module to do this instead and test it I would merge the changes for a future version of CMake. Some potential issues. 1. "cl /?" appears to pause waiting for input, this would have to be mitigated somehow in a safe way or perhaps just "cl" could be executed as that appears to include the output. 2. "cl" or "cl /?" output would have to be verified on VS8 to ensure it outputs there as well (it appears to be there in VS9/Express) 3. You couldn't just run "cl", you would have to find out the CMake variable for the compiler and run that. My time is really limited. If you're interested, please create a new ticket and submit a patch. It would save probably at least a second off of an initial configure. -- Philip Lowman ___ 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] CMakeDetermineVSServicePack.cmake support for vs2010
Aaron,
Thanks for posting. Could you open a new bug report and attach your patch
to it?
On Wed, Sep 29, 2010 at 9:33 PM, wrote:
> *Hi all. I noticed that CMakeDetermineVSServicePack.cmake only supports
> vs2005, vs2005 sp1, vs2008, vs2008 sp1. I wanted to use it for vs2010.*
>
> * *
>
> *I looked for a bug but the only one I found was the one that resulted in
> the scripts creation: http://public.kitware.com/Bug/view.php?id=8803*
>
> * *
>
> *I have a patch to fix it: (also attached)*
>
> * *
>
> CMakeDetermineVSServicePack.cmake 2010-06-28 09:42:36.0
> -0500*
>
> *--- CMakeDetermineVSServicePackWith2010.cmake 2010-09-29
> 20:26:20.530212900 -0500*
>
> *
>
> 47,52 *
>
> *--- 47,54 *
>
> * set(_version "vc90")*
>
> * elseif(${_cl_version} VERSION_EQUAL "15.00.30729.01")*
>
> * set(_version "vc90sp1")*
>
> *+elseif(${_cl_version} VERSION_EQUAL "16.00.30319.01")*
>
> *+set(_version "vc100")*
>
> * else()*
>
> * set(_version "")*
>
> * endif()*
>
> * *
>
> *Should I open a new bug for this and add a patch to it, or reopen the old
> bug (feature request) with this patch?*
>
> * *
>
> *Thanks!*
>
> * *
>
> *--aaron*
>
> * *
>
> *Aaron Meadows*
> Software Engineer
>
> *Thomson Reuters*
>
> Phone: 314.468.3530
> Mobile: 636.541.6139
> aaron.mead...@thomsonreuters.com
> thomsonreuters.com
>
>
>
> This email was sent to you by Thomson Reuters, the global news and
> information company.
> Any views expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of Thomson
> Reuters.
>
> ___
> 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
>
--
Philip Lowman
___
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] Volunteering to become maintainer of FindBoost.cmake
Part of the problem is that it's not clear if the user has built boost-thread against pthreads or win32 threads. See the fix for #11121, I've added a variable to control which threading library gets used if the user crosscompiles boost-thread using a thread-api that isn't native on their system. http://www.cmake.org/Bug/view.php?id=11121 <http://www.cmake.org/Bug/view.php?id=11121>Maybe we can just require users to specify pthreads for this and when they do we could link to pthreads? But is this regular pthreads or pthreads-win32 we're talking about? Really we need to fix 6399 first. For now I would just recommend adding the target_link_library manually against pthreads when you're using it and ensure we have a bug filed for this issue in the tracker. On Fri, Sep 10, 2010 at 1:29 PM, Matthew Woehlke < matthew.woeh...@kitware.com> wrote: > On 09/10/2010 09:02 AM, Philip Lowman wrote: > >> Hi everyone, >> I'm volunteering to become the primary maintainer of FindBoost.cmake. >> > > First off, thank you for volunteering! > > I hope I will not frighten you off with a request so soon :-). I've run > into a couple boost-using projects lately that fail to build because they > use pthread (often via boost templates), but don't explicitly link pthread. > (I think previously this was not an issue due to indirect linking, i.e. > MyProject links to boost which links to pthread, therefore MyProject can use > pthread. However, Fedora now disallows this sort of linking, such that > MyProject must link pthread itself - I believe this is an early-adoption of > new upstream practice.) > > Given how template-heavy boost is, I'm thinking the best solution is for > Boost_LIBRARIES to include pthread, rather than such projects needing to > find_package(threads) and link_libraries the libraries therefrom. > > What do you think? Any advice how to proceed patching FindBoost.cmake? > > -- > Matthew > -- Philip Lowman ___ 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] Volunteering to become maintainer of FindBoost.cmake
Hi everyone, I'm volunteering to become the primary maintainer of FindBoost.cmake. -- Philip Lowman ___ 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] Loop expansion in find_library() seems backwards
On Wed, Sep 8, 2010 at 8:56 AM, Michael Hertling wrote:
> ...which shows that 10718 is still alive. ;-)
>
> Hi Philip,
>
> what's your opinion on this topic, in particular
>
> - swapping loops and the required effort, the related risks
> and the expected results,
>
I'd like to know if there is a use case for the existing behavior. I don't
really have an opinion if this should be enabled optionally or by default
(or via policy) yet.
> - find modules with hardcoded magic numbers and the continuous
> need for maintenance,
> - globbing or regex support for FIND_{PROGRAM,LIBRARY,PATH,FILE}?
>
>
I've griped about this for a while. So much that I even started working on
a patch for the issue back when I had some free time last year (but never
finished). What little time I have these days to spend on CMake I choose to
spend on supporting find modules, so if anyone wants to take this over... It
was one approach for how to solve the version number problem...
http://www.cmake.org/Bug/view.php?id=8396
--
Philip Lowman
___
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] Loop expansion in find_library() seems backwards
Wow, that's pretty bad. I even replied to one of those threads. Sorry for
the noise. The official bug post for this issue is here:
http://public.kitware.com/Bug/view.php?id=10718
I agree with Alan Irwin that it will continue to haunt users well into the
future.
On Wed, Sep 8, 2010 at 2:38 AM, Michael Wild wrote:
>
> On 8. Sep, 2010, at 8:25 , Philip Lowman wrote:
>
> > Let's say I have many different potential names for a library and the
> > following filesystem
> >
> > /usr/lib/libnspr4.so
> > ${CMAKE_CURRENT_SOURCE_DIR}/libnspr4a.so
> >
> > find_library(TEST_LIBRARY
> > NAMES nspr4 nspr4a
> > HINTS ${CMAKE_CURRENT_SOURCE_DIR}
> > )
> >
> > I'm somewhat surprised that the following code finds /usr/lib/libnspr4.so
> > instead of the alternate name for it (libnspr4a.so). This tells me that
> the
> > loop is backwards. Shouldn't the find_library() command be iterating the
> > list of library names across each directory. For example, the above
> should
> > search:
> >
> > First ${CMAKE_CURRENT_SOURCE_DIR}...
> > ${CMAKE_CURRENT_SOURCE_DIR}/libnspr4.so
> > ${CMAKE_CURRENT_SOURCE_DIR}/libnspr4a.so
> > Then the system directories...
> > (system paths)/lib/libnspr4.so
> > (system paths)/lib/libnspr4a.so
> > Etc.
> >
> > The system is actually searching
> > ${CMAKE_CURRENT_SOURCE_DIR}/libnspr4.so
> > /usr/lib/libnspr4.so
> > ${CMAKE_CURRENT_SOURCE_DIR}/libnspr4a.so
> > /usr/lib/libnspr4a.so
> >
> > This is with CMake 2.8.2
> >
> > --
> > Philip Lowman
>
> Oh, no! This topic haunts the list ;-) See
>
> http://www.mail-archive.com/cmake@cmake.org/msg30602.html
> http://www.mail-archive.com/cmake@cmake.org/msg28946.html
> http://www.mail-archive.com/cmake@cmake.org/msg27838.html
> http://www.mail-archive.com/cmake@cmake.org/msg24565.html
>
> Michael
>
> --
> There is always a well-known solution to every human problem -- neat,
> plausible, and wrong.
> H. L. Mencken
>
>
--
Philip Lowman
___
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] Loop expansion in find_library() seems backwards
Let's say I have many different potential names for a library and the
following filesystem
/usr/lib/libnspr4.so
${CMAKE_CURRENT_SOURCE_DIR}/libnspr4a.so
find_library(TEST_LIBRARY
NAMES nspr4 nspr4a
HINTS ${CMAKE_CURRENT_SOURCE_DIR}
)
I'm somewhat surprised that the following code finds /usr/lib/libnspr4.so
instead of the alternate name for it (libnspr4a.so). This tells me that the
loop is backwards. Shouldn't the find_library() command be iterating the
list of library names across each directory. For example, the above should
search:
First ${CMAKE_CURRENT_SOURCE_DIR}...
${CMAKE_CURRENT_SOURCE_DIR}/libnspr4.so
${CMAKE_CURRENT_SOURCE_DIR}/libnspr4a.so
Then the system directories...
(system paths)/lib/libnspr4.so
(system paths)/lib/libnspr4a.so
Etc.
The system is actually searching
${CMAKE_CURRENT_SOURCE_DIR}/libnspr4.so
/usr/lib/libnspr4.so
${CMAKE_CURRENT_SOURCE_DIR}/libnspr4a.so
/usr/lib/libnspr4a.so
This is with CMake 2.8.2
--
Philip Lowman
___
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] FindBoost.cmake trouble with static libs (-gd vs -sgd issue)
Shane,
Thanks for opening ticket 11204 for this issue. My response is included
there.
http://public.kitware.com/Bug/view.php?id=11204
On Thu, Sep 2, 2010 at 4:08 PM, Dixon, Shane wrote:
> I found that when using the FindBoost.cmake and using the
> Boost_USE_STATIC_LIBS option, it wouldn’t find the static libs in my
> C:\Boost\libs folder. It kept coming back with files ending in –gd libs
> instead of –sgd libs even though the option Boost_USE_STATIC_LIBS was set.
> I found that it had to do with the order that the FIND_LIBRARY looks for the
> files. I had BOTH the –gd and the –sgd libraries installed so it found the
> –gd ones first and then ignores the next option. I fixed it by applying the
> following:
>
>
>
>
>
> 728,729c728,729
>
> < NAMES
> ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}-${_boost_ABI_TAG}-${Boost_LIB_VERSION}
>
> <
> ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_STATIC_TAG}${_boost_ABI_TAG}-${Boost_LIB_VERSION}
>
> ---
>
> > NAMES
> ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_STATIC_TAG}${_boost_ABI_TAG}-${Boost_LIB_VERSION}
>
> >
> ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}-${_boost_ABI_TAG}-${Boost_LIB_VERSION}
>
>
>
> I just switched the order to look for the more specific lib before the more
> general one. If ${_boost_STATIC_TAG} is empty when Boost_USE_STATIC_LIBS is
> OFF, then maybe this could just be one line:
>
>
>
>
> ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_STATIC_TAG}${_boost_ABI_TAG}-${Boost_LIB_VERSION}
>
>
>
> Which seems like it should find either –sgd or –gd files, but sould find
> –sgd files first if the option was provided. Any thoughts? I defer to
> anyone with more experience for the best way to do this.
>
>
>
> --
>
> Shane
>
> ___
> 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
>
--
Philip Lowman
___
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] [cmake-developers] Bug fix requests for the *next* release of CMake...
David, Thanks for enabling this. If anyone is wondering where to find the "Target Release" and "Fixed In Version" fields, they are under the Advanced Details link for each bug. When you mark a bug as fixed, it prompts you for "Fixed In Version" but the only way to set "Target Release" I can see is under Advanced (just an FYI for people). On Tue, Aug 31, 2010 at 6:35 PM, David Cole wrote: > Great idea! > > There is now a roadmap page in Mantis for the CMake project. > http://public.kitware.com/Bug/roadmap_page.php > > It has 33 issues listed as targeted for 2.8.3. 17 of these (51%) are > resolved: fixed in 'next' already, or "won't fix"... ever. > > The remaining 16 shall be fixed (or marked as postponed to the next > release) over the next couple of weeks, and then we'll be ready for the > first RC of CMake 2.8.3. > > Thanks to all of you who participated in this thread. It helped us organize > around what people think is most important. > > > Cheers, > David Cole > Kitware, Inc. > > > P.S. -- there were 40-something issues mentioned specifically in this > thread. The 33 listed on the roadmap plus the following 13, which we decided > should be looked at for a future release, if ever, but certainly not in the > time remaining before 2.8.3 > > http://public.kitware.com/Bug/view.php?id=5796 > http://public.kitware.com/Bug/view.php?id=7867 > http://public.kitware.com/Bug/view.php?id=7919 > http://public.kitware.com/Bug/view.php?id=8466 > http://public.kitware.com/Bug/view.php?id=8486 > http://public.kitware.com/Bug/view.php?id=10199 > http://public.kitware.com/Bug/view.php?id=10200 > http://public.kitware.com/Bug/view.php?id=10335 > http://public.kitware.com/Bug/view.php?id=10389 > http://public.kitware.com/Bug/view.php?id=10476 > http://public.kitware.com/Bug/view.php?id=10752 > http://public.kitware.com/Bug/view.php?id=10895 > http://public.kitware.com/Bug/view.php?id=10939 > > There should be a note attached to each of these that says something like > "not working on this for 2.8.3"... > > Thanks, > D. > > > > On Fri, Jul 30, 2010 at 4:18 PM, Brian Davis wrote: > >> Can a roadmap be posted for CMake? Such as is for other projects at: >> >> http://www.cmake.org/Bug/roadmap_page.php >> >> > > ___ > cmake-developers mailing list > cmake-develop...@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > > -- Philip Lowman ___ 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] detecting libc version info
On Tue, Aug 31, 2010 at 3:01 PM, Tim St. Clair wrote: > Is there a handy dandy marco for detecting libc details (e.g. version). Probably not. You can use preprocessor checks though. glibc: http://predef.sourceforge.net/prelib.html#sec3 gcc: http://predef.sourceforge.net/precomp.html#sec15 HTH -- Philip Lowman ___ 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] FindOpenSSL.cmake
Officially, CMake modules are supposed to mark cache variables like this as advanced so they disappear as soon as they are set. Since it is finding DLL files the cache variables are being set and immediately hidden in the advanced section of the cache. You should be able to get at them from the advanced section of the cache editor and change them to the appropriate .LIB files to work around the issue (choose advanced from the select dropdown). The reason why it is detecting DLL files should be investigated. Can you please open a bug ticket with the information here? Also it should contain: 1. What version of OpenSSL are you using (precompiled or did you build it yourself). If the former please point to the location on the net, if the latter please include a directory listing of the install prefix. 2. What generator/compiler are you using with CMake (MinGW? Visual Studio X?) http://www.cmake.org/Bug On Tue, Aug 31, 2010 at 4:35 PM, Dixon, Shane wrote: > I’m having some trouble with the FindOpenSSL.cmake. While > troubleshooting, I noticed that it has this line: > > > > MARK_AS_ADVANCED(OPENSSL_INCLUDE_DIR OPENSSL_LIBRARIES) > > > > Yet the OPENSSL_LIBRARIES never show up in the cmake-gui. I’m running > 2.8.2 on Windows XP. Can someone tell me if I’m wrong to expect that to > show up in the GUI when the “advanced” checkbox is checked? The > OPENSSL_LIBRARIES always gets populated with .dll files instead of .lib > files. I was going to manually set it to the correct thing (which seems to > be the point of setting a variable to advanced) and the variable doesn’t > show up at all. > > > > -- > > Shane > > ___ > 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 > -- Philip Lowman ___ 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] FindBoost.cmake in 2.8.2 _Boost_KNOWN_VERSIONS variable
Someone has included 1.44 in the latest FindBoost.cmake in git.
On Wed, Aug 25, 2010 at 3:35 PM, Dixon, Shane wrote:
> I was had trouble getting FindBoost.cmake to work correctly and I found
> that there was a variable I had to adjust in the FindBoost.cmake file:
>
>
>
> set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
>
> "1.41.0" "1.41" "1.40.0" "1.40" "1.39.0" "1.39" "1.38.0" "1.38"
> "1.37.0" "1.37"
>
> "1.36.1" "1.36.0" "1.36" "1.35.1" "1.35.0" "1.35" "1.34.1" "1.34.0"
>
> "1.34" "1.33.1" "1.33.0" "1.33")
>
>
>
> I’m using cmake 2.8.8. I had to add “1.44.0” to the list because that’s
> the newest version. From their website it looks like this file ought to be
> fixed to reflect the new versions:
>
>
>
> set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
>
> “1.44.0” “1.44” “1.43.0” “1.43” “1.42.0” “1.42” "1.41.0" "1.41"
> "1.40.0" "1.40"
>
> "1.39.0" "1.39" "1.38.0" "1.38" "1.37.0" "1.37" "1.36.1" "1.36.0"
> "1.36" "1.35.1" "1.35.0"
>
> "1.35" "1.34.1" "1.34.0" "1.34" "1.33.1" "1.33.0" "1.33")
>
>
>
> Maybe there’s a pre-release checklist of items that get updated before each
> list that this can be added to. It looks like this variable will need to be
> constantly updated. After I added “1.44.0” to the list, it works as
> expected.
>
>
>
> --
>
> Shane
>
> ___
> 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
>
--
Philip Lowman
___
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] CTest: Any way around the "one test == one program invocation" assumption?
On Tue, Jun 8, 2010 at 4:32 AM, Chris Hillery wrote: > On Tue, Jun 8, 2010 at 1:00 AM, Biddiscombe, John A. wrote: > >> I'm sure someone has a better answer ... but ... >> >> > I have complete control over the test >> > program and can make it output whatever I want. >> >> Have a look at the XML produced by ctest itself and generate it yourself? >> then submit it and you should see each test separately >> >> (Just thinking out loud) >> > > Yeah, worst case I'll head down that path. It's a hairy path though. For > instance, I'd still definitely want to run "normal" ctest tests as well, > which means the XML would need to be merged in some fashion. Also, it seems > like doing it that way opens you up to possible problems later if ctest or > cdash change the XML format at all. > > All in all it'd be much nicer if there was some kind of hook in ctest which > could be used to inform it that a number of tests had been run, and let it > populate and submit the XML report based on that information. But, if > there's any way to do that, it's highly undocumented... > It doesn't appear like there is a class for storing the test results before serializing the XML document to a file. Sounds like that's what would have to be written. cmCTestTestHandler::GenerateDartOutput Looks like it may be a place to start? -- Philip Lowman ___ 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] FindThreads.cmake
26<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l26>#
Do we have sproc?
27<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l27>IF(CMAKE_SYSTEM
MATCHES IRIX)
28<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l28>
CHECK_INCLUDE_FILES("sys/types.h;sys/prctl.h" CMAKE_HAVE_SPROC_H)
29<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l29>ENDIF()
30<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l30>
31<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l31>IF(CMAKE_HAVE_SPROC_H)
32<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l32>
# We have sproc
33<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l33>
SET(CMAKE_USE_SPROC_INIT 1)
34<http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindThreads.cmake;h=459129bc4ab0634c2c42feabbd6f37dc4110c700;hb=HEAD#l34>ELSE()
Clinton,
I would add a variable to FindThreads above that if set avoids the call to
CHECK_INCLUDE_FILES(). Then you can test the pthread functionality in the
ELSE() block and see if it works properly on IRIX and submit a patch to the
bugtracker.
On Tue, Jun 1, 2010 at 1:21 PM, Clinton Stimpson wrote:
>
> How can I make FindThreads.cmake find pthreads on IRIX instead of sproc?
>
> Thanks,
> Clint
> ___
> 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
>
--
Philip Lowman
___
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] FindBoost problem
Did you set Boost_ADDITIONAL_VERSIONS? Check the FindBoost documentation if you didn't do this. On Wed, May 26, 2010 at 1:52 PM, Nico Schlömer wrote: > Hi all, > > I'd like to use CMake for an application that I'm developing on an > Ubuntu machine which needs to link against Boost, i.e., a > custom-compiled installation at /opt/boost/1.43.0/. > > I compiled and installed CMake 2.8.1, FindBoost.cmake comes in handy. > Ubuntu ships with its own Boost development package (1.40.0) which I > cannot remove because it's used by other packages. By default, CMake > finds the stock-Boost (I guess b/c it sits in those default folders), > so I call cmake with > > cmake -DBOOST_ROOT:PATH=/opt/boost/1.43.0/ /path/to/source/ > > Boost is found, and the variables are set in CMakeCache.txt, e.g., > >Boost_INCLUDE_DIR:PATH=/opt/boost/1.43.0/include > > I however also notice that the actual libraries are *not* set correctly, as > >Boost_FILESYSTEM_LIBRARY:FILEPATH=/usr/lib/libboost_filesystem-mt.so > > This makes the build fail. Setting BOOST_LIBRARYDIR does not help. > > Could that be a bug in CMake? > > Cheers, > Nico > ___ > 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 > -- Philip Lowman ___ 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] Trying to link my project with Boost.Thread using CMake
I'm not sure what the problem is exactly, but I've seen that kind of error
message before so I think it's just a configuration problem. What version
of CMake are you running?
On Sun, May 23, 2010 at 11:38 AM, Clark Gaebel wrote:
> Yeah. Sorry, in my effort to remove the extra cruft I messed that up.
> Just image they're matching :)
>
> On 05/23/10 11:36, Philip Lowman wrote:
> > On Sun, May 23, 2010 at 10:31 AM, Clark Gaebel >wrote:
> >
> >
> >> When I link Boost.Thread to my boost_test executable, it gives me
> >>
> >> make[2]: *** No rule to make target `/usr/lib64/libboost_thread-mt.so',
> needed by `gogo/test/test_boost'. Stop.
> >>
> >> when I make it. Here's the offending CMake code, what am I doing wrong?
> >>
> >> add_executable(test_boost test_boost.cpp)
> >> add_test(test_boost test_boost)
> >> # Boost auto-links for MSVC, so we exclude
> it.if(CMAKE_COMPILER_IS_GNUCXX)
> >> target_link_libraries(test_boost #LINK_INTERFACE_LIBRARIES
> >> ${Boost_THREAD_LIBRARY}
> >> )
> >> endif()
> >>
> >>
> > Don't you want:
> > target_link_libraries(boost_test ${Boost_THREAD_LIBRARY})
> > instead of "test_boost"?
> >
> >
>
> --
> Regards,
> -Clark
>
>
--
Philip Lowman
___
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] Trying to link my project with Boost.Thread using CMake
On Sun, May 23, 2010 at 10:31 AM, Clark Gaebel wrote:
> When I link Boost.Thread to my boost_test executable, it gives me
>
> make[2]: *** No rule to make target `/usr/lib64/libboost_thread-mt.so',
> needed by `gogo/test/test_boost'. Stop.
>
> when I make it. Here's the offending CMake code, what am I doing wrong?
>
> add_executable(boost_test boost_test.cpp)
> add_test(boost_test boost_test)
> # Boost auto-links for MSVC, so we exclude it.if(CMAKE_COMPILER_IS_GNUCXX)
> target_link_libraries(test_boost #LINK_INTERFACE_LIBRARIES
> ${Boost_THREAD_LIBRARY}
> )
> endif()
>
> Don't you want:
target_link_libraries(boost_test ${Boost_THREAD_LIBRARY})
instead of "test_boost"?
--
Philip Lowman
___
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] CMake 2.8.1 / Win: Neither if nor else?`
On Sat, May 22, 2010 at 4:50 AM, Droscy wrote:
> The right construct is
> IF(ZLIB_FOUND)
>MESSAGE( WARNING "HAVE system zlib" )
> ELSE(ZLIB_FOUND)
> MESSAGE( WARNING "NO system zlib" )
> ENDIF(ZLIB_FOUND)
>
And if compatibility with CMake < 2.4.4 isn't a concern, an even better way
to do this is:
# set this at your topmost CMakeLists.txt
set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
if(ZLIB_FOUND)
message("HAVE system zlib")
else()
message("NO system zlib")
endif()
P.S.
The WARNING option to message() is new to CMake 2.8. For
better compatibility with CMake 2.6 and lower, simply omit it which should
give you a similar effect.
--
Philip Lowman
___
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] Linking error with VS2005
It also may be caused by linking code compiled with /MT against code compiled with /MD (or vice versa). On Fri, May 21, 2010 at 10:48 AM, Chuck Atkins wrote: > Does the problem happen in both Debug and Release builds? > > Visual C++ has a well known problem of mixing debug and release libraries > together. My suspicion is that you have some dependant libraries that are > only built in Debug or only built in Release. With Visual C++ it is > important that all libraries and dependencies as well as the project code > it's self be built in the same "Build Configuration" (Debug or Release). > Mixing the two will often give rise to problems such as these. > > Chuck Atkins > > > -- "Mathematicians are tools for turning coffee grounds into formulas.", > Paul Erdos > > > On Fri, May 21, 2010 at 8:01 AM, Daanen Vincent wrote: > >> Dear Cmake users, >> >> I'm facing to a problem I can't resolve. >> I'm developping on a windows XP SP3 box with Visual Studio 2005. >> >> I have a project using itk which compile fine. >> For some reason, I try to use cmake to generate the "same" project and I >> got linker error (conflict between msvcrtd.lib and libcmtd.lib) >> >> - I check that the librairies are declared in the same order in both >> project >> and it's ok >> - Try to ignore either msvcrtd.lib or libcmtd.lib but I does not work : >> other linker errors appear. >> >> I could not find what is specifically added by cmake so that the >> "cmake-generated" project fails to build the binray whereas the >> "manually-generated" project file succeeds... >> >> Is there someone who could help me ? >> >> Thanks >> >> Vince >> >> ___ >> 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 >> > > > ___________ > 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 > -- Philip Lowman ___ 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] VS-C++ Express Version
David, Thanks for the clarification. I missed the filters part in the original message and don't have VS10. Does VS10 still have the same problem with there not being a "Reload All" button for modified project files that previous versions of VS had? If this small feature were added by Microsoft there would be no need for all of the crazy macro stuff. On Fri, May 14, 2010 at 10:53 AM, David Cole wrote: > On Fri, May 14, 2010 at 8:02 AM, Philip Lowman wrote: > >> This is Microsoft's fault. You should complain to them. > > > Well, yes and no. It's a Visual Studio 2010 only thing... And it's partly > CMake's fault. The *.filters files are presently unconditionally re-written > at CMake time. We have a fix for that part of it that will be in the next > release of CMake. (It's not even in git master, yet, though.) I'll push it > today. > > And the reload macros are not working as well as they did in prior Visual > Studio versions. This is a VS change that we have not figured out yet how to > compensate for... > > > >> The only workaround for VS Express is to close your solution and run CMake >> manually then open your solution back up again. >> >> The problem doesn't affect VS Professional (and I believe Standard) >> because they have support for macros which CMake takes advantage of to >> reload all of the VS project files without a lot of user interaction. >> > > The *.filters problem affects all versions of Visual Studio 2010. The fix > will be in git master later today. > > > Thanks, > David Cole > > -- Philip Lowman ___ 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] VS-C++ Express Version
This is Microsoft's fault. You should complain to them. The only workaround for VS Express is to close your solution and run CMake manually then open your solution back up again. The problem doesn't affect VS Professional (and I believe Standard) because they have support for macros which CMake takes advantage of to reload all of the VS project files without a lot of user interaction. On Fri, May 14, 2010 at 7:55 AM, Micha Renner wrote: > There are some things in the cooperation of CMake and the Visual Studio > Express-version, which which bothers me. > > Each change in a CMakeLists.txt file results in a message of VS Express > like this: "The filter file of your project changed outside VS! Do you > want reload it?" > > I could live with this, but this message is presented also for > sub-projects whose CMakeLists.txt file was not changed. > > Let say one have a project with 5 sub-projects with one target. A change > of one CMakeLists.txt results in the five-fold display of the message > above plus the display for ALL_BUILD, RUN_TESTS, INSTALL and uninstall. > This means I have to confirm 9 times that I want to reload the filter > file of the projects. > > That is too much. > > More worse: If the the projects have more then one target, you have to > confirm the reload of the filter files for each target. > > Greetings > Micha > > > > > > ___ > 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 > -- Philip Lowman ___ 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] cmake: could NOT find Boost
Usually you can get away with deleting just the cached variables that a find module create (i.e. ZLIB_LIBRARY, etc.). Boost is one of the few modules where this doesn't always work because it creates internal cached variables that don't show up in the cache editor. On Wed, May 5, 2010 at 9:57 AM, Michael Hertling wrote: > On 05/04/2010 07:19 PM, Mike Ladwig wrote: > > The "clean build tree" seems to have been the problem. Looks as if I > needed > > to start clean every time I tried a new configuration approach. Much > > thanks! > > Typically, if FIND_PACKAGE() succeeds in locating a package the results > are cached, and if you reconfigure later FIND_PACKAGE() usually doesn't > search again, but reuses the previously found results from the cache. > Therefore, you must ensure that FIND_PACKAGE() is lead to the desired > package right at the first time. If this package is missed you should > actually restart the configuration from within a clean directory, i.e. > without a cache. In general, if you have installed multiple versions > of the same package be particularly careful w.r.t. which of them is > going to be found by FIND_PACKAGE(). > > Regards, > > Michael > > > > > On Tue, May 4, 2010 at 1:01 PM, S Roderick wrote: > > > >> On May 4, 2010, at 12:41 , Mike Ladwig wrote: > >> > >>> Hi. > >>> > >>> I'm having a problem compiling scantailor on CentOS 5.4. The version > of > >> cmake that comes with CentOS was too old, so I downloaded the current > cmake > >> binary, which seems to be working well. > >>> > >>> The problem is that the CentOS version of boost is also out-of-date, so > I > >> needed to download and build that, which I did successfully. I > installed > >> the new boost (1.42) in /usr/local and have been unable to get cmake to > >> recognize it. > >>> > >>> I have tried -DBOOST_ROOT=/usr/local/ -DBOOSTROOT=/usr/local/ > >> -DBOOST_INCLUDEDIR=/usr/local/include/ > -DBOOST_LIBRARYDIR=/usr/local/lib/ > >> -DBoost_ADDITIONALVERSIONS="1.42.0" and many variations on these. > >>> > >>> Am I missing something, or is cmake just unable to find boost anywhere > >> other than default locations? > >> > >> > >> Have you tried (in a clean build tree) > >> > >> export CMAKE_PREFIX_PATH=/usr/local > >> cmake ... > >> > >> The above works with MacPorts installed boost v1.42 in /opt/local for > Mac > >> OS X. > >> Stephen > >> > > > > > > > > ___ > > 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 > > ___ > 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 > -- Philip Lowman ___ 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_LIBRARY in FindBoost finds wrong library
On Mon, Mar 22, 2010 at 4:05 AM, Marcel Loose wrote: > Hi Chuck, > > Whatever way you look at it, problems will likely arise sooner or later > with different Boost versions. I ran into this problem > because /usr/lib/libboost_date_time-mt.so was found > before /home/loose/boost-1.40.0/lib/libboost_date_time.so. > > My point in turning the loop inside out stems from the fact that there > are dozens of FindXXX modules that may be vulnerable to the same > problem. To name a few: FindGTK, FindLua50, FindPNG, FindWxWindows, etc. > > W.r.t. FindBoost, maybe it's wise to use BOOST_ROOT exclusively when > specified. That would at least preclude the current problems. > > BTW: Is there a reason why I cannot specify options like > NO_CMAKE_ENVIRONMENT_PATH, NO_SYSTEM_ENVIRONMENT_PATH, etc. with > FIND_PACKAGE(), except when using config mode? You could modify the FIND_PACKAGE() interface to support options like these and then fix all of the CMake modules to handle the new options. Alternatively, there could be a global CMake property or variable for enabling these. A combination could also be used (if necessary, property is set at start of find_package() and subsequently unset at end). -- Philip Lowman ___ 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_LIBRARY in FindBoost finds wrong library
On Fri, Mar 19, 2010 at 10:22 AM, Chuck Atkins wrote: > /home/myuser/projects/boost-1.41.0/lib/libboost_date_time-mt.so > /home/myuser/projects/boost-1.41.0/lib/libboost_thread-mt.so > /usr/local/lib/libboost_filesystem-mt.so > /usr/local/lib/libboost_python-mt.so > > This mix and match is definitely not desired. It almost seems like if the > BOOST_ROOT variable is set then that should get used exclusively as the > search path and not just appended to the front. I've had the same thought (and wish it had been implemented that way) but refrained from changing the behavior of this in the past, mainly because it could break some people's builds (some people may treat BOOST_ROOT as a "use it if it's there" feature or have it accidentally set while building on certain platforms where Boost is provided in the system path). Also, FindBoost would need to check the environment variables BOOST_ROOT and possibly BOOST_LIBRARYDIR and BOOST_INCLUDEDIR as well and if they are set enable this new behavior. > Thoughts? I could add a public variable to FindBoost which disables searching the system paths and call it out in the documentation. It would basically set NO_CMAKE_SYSTEM_PATH on all of the find_library() and find_path() calls. Alternatively, we could make the module behave as you describe and hope that it doesn't break too many people. What do you think? -- Philip Lowman ___ 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_LIBRARY in FindBoost finds wrong library
Someone could add an option to FindBoost that will simply exclude the system paths from the search. This has never been implied by setting BOOST_ROOT. As long as the unversioned library names are being searched for with find_library they are likely going to be found. Currently the onus is on the user to double check what FindBoost discovers. On Mar 19, 2010 4:56 AM, "Marcel Loose" wrote: Well, in my case, the library name was not even that specific. It found /usr/lib/libboost_date_time-mt.so before /home/loose/boost/boost-1.40.0/lib/libboost_date_time.so, simply because libboost_date_time-mt.so is searched for in *all* paths before libboost_date_time.so. Anyway, I still think this is (also) a CMake issue. IMHO it would make sense to turn the loop in cmFindLibraryCommand::FindNormalLibrary() inside out. What's your opinion? Best regards, Marcel Loose. On Thu, 2010-03-18 at 10:05 -0400, Michael Jackson wrote: > I thought there was now an option the b... ___ 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] Skipping PATH when using find_library
On Thu, Mar 11, 2010 at 3:00 AM, wrote:
> More reading documentation and attempts... but still not working.
>
> Maybe there is no way?
The following works fine for me on CMake 2.8.0.
message("PATH = $ENV{PATH}")
find_library(FOO foo NO_SYSTEM_ENVIRONMENT_PATH)
If you place a foo.lib in your PATH CMake shouldn't find it with that
option. NO_DEFAULT_PATH should work as well although it excludes all
of the default search paths not just the ones specified by the PATH
environment variable.
See:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_library
--
Philip Lowman
___
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] set proxy with cmake file download
Have you tried setting the http_proxy environment variable? export http_proxy="http://host:port"; On Thu, Mar 11, 2010 at 7:47 AM, nader.akh...@laposte.net < nader.akh...@laposte.net> wrote: > Hi, > > is it possible to set proxy to use before downloading with cmake? > > file(DOWNLOAD url file [TIMEOUT timeout] [STATUS status] [LOG log]) > > Nad > > > > > Message du 11/03/10 10:28 > > De : cmake-requ...@cmake.org > > A : cmake@cmake.org > > Copie à : > > Objet : CMake Digest, Vol 71, Issue 49 > > > > Send CMake mailing list submissions to > > cmake@cmake.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.cmake.org/mailman/listinfo/cmake > > or, via email, send a message with subject or body 'help' to > > cmake-requ...@cmake.org > > > > You can reach the person managing the list at > > cmake-ow...@cmake.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of CMake digest..." > > > > > [ Today's Topics (7 messages) (0.5 Ko) ] > > [ Digest Footer (0.1 Ko) ] > > [ Re: [CMake] adding same subdirectory multiple times. (5.3 Ko) ] > > > > [image: Pieddemail] <http://www.laposte.net/rallye-des-gazelles> > ___ > 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 > -- Philip Lowman ___ 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] CMAKE_BUILD_TYPE should start as a drop-list option
The second line seems like a good idea to me. The user can always modify the property in their code if they have custom build types. The first line seems like a bad idea. I think the default build type should be left to the project. Currently you can set it manually before project(). I think a variable you could set before project() which initialized the cache variable for you isn't a bad idea so long as it says next to it in the docs not available in 2.8. On Mar 1, 2010 9:44 PM, "J Decker" wrote: set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Set build type") set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo") This could be added to some default startup macro, no? ___ 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 ___ 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] FindCurses wide
If it's not too much trouble, could you please open a ticket for this? http://www.cmake.org/Bug On Sat, Feb 27, 2010 at 10:53 PM, Gary Briggs wrote: > I found this thread from a while ago while searching for how to get > ncurses to support wide chars: > > http://www.mail-archive.com/cmake@cmake.org/msg15578.html > > Please find attached a modified version of FindCurses.cmake that looks > for the wide variants of curses if asked. It's working for me... [this > is against a 2.6 module. I checked the 2.8 and it looks like some > boilerplate has been added, but it's otherwise the same]. > > Thanks, > Gary (-; > > ___ > 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 > -- Philip Lowman ___ 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 Software\Microsoft\VisualStudio\8.0\vsmacros\OtherProjects7
I have visual studio 8 sp1 installed and have keys in HKCU/Software/Microsoft/VisualStudio/8.0/vsmacros/OtherProjects7 On Feb 22, 2010 10:32 AM, "Wheeler, Frederick W (GE, Research)" < whee...@ge.com> wrote: I did an uninstall/reinstall and have some more info on this problem. > From: David Cole > > Looking at the CMake source code, it does not appear that there is any way to suppress those "er... I'm the only person who has used the machine. > With the Pro Edition of VS, those keys should definitely be there. Perhaps a full uninstall / re-... I just did a complete uninstall of visual studio and all of the other packages it installs. I then reinstalled Visual Studio 2005 (8.0) Professional. During the install I did get one error message about Microsoft SQL Server 2005 Express Edition x86 failing to install. I doubt that is related to this issue. At this point, I ran Cmake on my project and the errors went away! So that was nice. However, as I had done before, I then also installed VS service pack 1 (VS80sp1-KB926601-X86-ENU.exe). The service pack installed without any error messages or anything unusual at all. After I installed the service pack I ran Cmake on the project again and the missing Software\Microsoft\VisualStudio\8.0\vsmacros\OtherProjects7 errors returned. I did not actually look at the registry entries before or after installing the service pack, but it seems that installing the service pack either A) removed the registry entries in question or B) did something else that causes Cmake to check the registry entries, but failed to create the registry entries. I would assume that most people who use VS 8.0 install service pack 1. It seems to fix a lot of problems. I'd welcome any suggestions on how to fix these errors if they are indeed a sign of a real problem with my system. Or, if anyone thinks this is a Cmake issue, I'm happy to do any tests/checks that might help the cause. As before, Cmake seems to configure the project fine, even with these error messages. Fred Wheeler ___ Powered by www.kitware.comVisit other Kitware open... ___ 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] Overwriting variables in cache.
You can use the CACHE & FORCE options to the set() command. This will overwrite the variable every time you configure regardless of what the user enters, however. On Thu, Feb 18, 2010 at 10:40 AM, Benoit Thomas wrote: > Hi, > > I am trying to overwrite some variables in the cache (without editing the > cache); it works well for variables like CMAKE_CXX_FLAGS, but I cannot > overwirte the CMAKE_CONFIGURATION_TYPES variable. Is there a way to do this > without having to edit the cache ? (or modifying it the first time the cache > is build, that would be correct also). > > (Sorry if this sound confusing, I just started using cmake) > > Thank you, > Ben. > > ___ > 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 > -- Philip Lowman ___ 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] CTest/CDash and miscellaneous post-build steps (was Re: continuous integration with CMake)
I've been meaning to add something like that to our nightly builds just using shell/batch scripting. You should be able to set CMAKE_PREFIX_PATH in the initial cache and then just make install or use the vs command line app to run the INSTALL project after calling ctest -S. Not sure on how to detect build failure via ctest directly. For us if the build fails we're not going to care about the contents of the install directory. On Feb 17, 2010 4:58 PM, "Tyler Roscoe" wrote: Next question: - CDash and miscellaneous post-build steps Now that I've got Continuous Integration up and running with CDash, I'd like to publish my Continuous builds to a central build archive so developers and testers can use them. I can write post-build rules to copy my _results directory to the build archive (or mess with CMAKE_INSTALL_PREFIX and the INSTALL target), but then the build will be copied as soon as compiling/linking are finished. I would prefer to run the tests first and only copy the build if it passes all the tests. I thought of doing the copy from my continuous integration script itself. I could copy after a successful build by making use of the NUMBER_ERRORS and NUMBER_WARNINGS parameters to ctest_build(). I was hoping I could do the same after ctest_test(), but that command doesn't seem to have anything like NUMBER_ERRORS that would let me evaluate if the tests completed successfully before performing the copy. How do other people handle this? I'd like to do more than just publish the builds (run the setup.exe and make sure it works, compare what is installed by setup.exe against a known-good install manifest, kick off component tests on another machine with this newly-generated build, etc.) but figuring out a method for publishing builds would be a great start. Thanks, tyler On Fri, Dec 04, 2009 at 01:07:23PM -0500, Bill Hoffman wrote: > Tyler Roscoe wrote: > The build scripts for CMake can be found on CDash itself, for example: > > http://www.cdash.org/CDash/viewNotes.php?buildid=485762 > > For each dashboard on the CMake dashboard if you click on the notes for > the build you can see the script that was used to drive the build. > > Here is the .bat file that is run for a scheduled task on that machine: > > > $ cat dash2win64.bat > setlocal > rem Update clapack driver script from clapck > pushd c:\Dashboards\clapack > svn up clapack_build.cmake > rem Run the clapack driver script > "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S > clapack_build.cmake -VV -O clapack.log > popd > endlocal > > call C:\cygwin\bin\bash.exe --login > c:/Dashboards/DashboardScripts/dash2win64cygwin.sh > > "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S > dash2Win64_cmake_vs10.cmake -O cmake_vs10.log > "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S > dash2Win64_cmake_vs10_x64.cmake -O cmake_vs10_x64.log > > setlocal > call "C:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\bin\vcvars32.bat" > "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S > dash2Win64_cmake_nmake10.cmake -O cmake_nmake10.log > endlocal > > setlocal > call "C:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\bin\amd64\vcvars64.bat" > "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S > dash2Win64_cmake_nmake10_x64.cmake -O cmake_nmake10_x64.log > endlocal > > "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S > dash2win64_libarchive_vs9.cmake -VV > libarchive_vs9.log 2>&1 > "c:\Program Files (x86)\CMake 2.9\bin\ctest.exe" -C Release -S > dash2win64_cmake_icl11_32.cmake -VV > cmake_icl11_32.log 2>&1 > "c:\Program Files (x86)\CMake 2.9\bin\ctest.exe" -C Release -S > dash2win64_cmake_icl11_64.cmake -VV > cmake_icl11_64.log 2>&1 ___ 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 ___ 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] FindBoost: trunk
Not that I know of. I think FindBoost expects only versioned releases. Please open a ticket with your requirements and preferably a patch. Http://public.kitware.com/Bug On Feb 14, 2010 5:34 PM, "Hicham Mouline" wrote: Hello, Is there a way to find the boost trunk include directories and lib directories? Regards, ___ 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 ___ 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] How to avoid continuous download while using ExternalProjects
On Thu, Feb 11, 2010 at 12:00 PM, Luigi Calori wrote: >> Also, for any that are interested, beta releases of zlib now have a >> CMakeLists.txt in them. It could use testing on Mac OSX and other >> unix systems. >> http://zlib.net/current/beta/ >> > > Did you tried that? I' did but seem to have a strange error on linking their > examples: > I got > zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol _snprintf > referenced in function _gzdopen > > that seem to get away by adding > # define snprintf _snprintf > to gzguts.h > Anyone has ever tested it under MSVC? It would be nice to have helpers to > build patches, as in CMakePorts... I was testing it on MSVC but it seems like they keep checking in code which breaks MSVC every 1.2.3.X and I haven't been checking X consistently. Your above comment is an example. If only they had a dashboard... sigh. -- Philip Lowman ___ 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] Bison extra headers
They could be if you want. Just open up a bug ticket with some info
on how to reproduce and your bison command line and I'll see what I
can do. I'm pretty sure all we would have to do is add position.hh,
location.hh and stack.hh as OUTPUTs for the custom command for them to
be automatically cleaned. All that would need to be known is how they
get generated (special flag to parse?).
On Thu, Feb 11, 2010 at 1:01 PM, Hilton Medeiros
wrote:
> FYI, I won't put these in the issues tracker because I really don't
> think these should be solved by the FindBISON module.
>
> On Thu, 11 Feb 2010 10:57:44 -0200
> Hilton Medeiros wrote:
>
>> Hello,
>>
>> I'm using bison_target() from FindBISON with the C++ bison interface,
>> on CMake 2.8.0. When using this interface the following extra files
>> are generated by bison:
>>
>> location.hh
>> position.hh
>> stack.hh
>>
>> They do not get listed in BISON_target_OUTPUTS and do not get erased
>> in 'make clean'.
>>
>> See here:
>> http://www.gnu.org/software/bison/manual/html_node/C_002b_002b-Bison-Interface.html
>>
>> Note that this manual seems outdated, there is no 'lalr1.c' for me,
>> only 'lalr1.cc' on bison 2.4.1. Anyway, this is a very small issue,
>> this is the workaround I'm using:
>>
>> set (BISON_EXTRA_HEADERS
>> ${PROJECT_BINARY_DIR}/position.hh
>> ${PROJECT_BINARY_DIR}/location.hh
>> ${PROJECT_BINARY_DIR}/stack.hh
>> )
>>
>> set_property(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
>> "${BISON_EXTRA_HEADERS}")
>>
>> By the way, I saw that the main header file generated on
>> bison_target() is always terminated by '.hpp'. I tried to bypass this
>> with:
>>
>> bison_target (PARSER ${PARSER_FILE} ${PROJECT_BINARY_DIR}/Parser.cpp
>> COMPILE_FLAGS
>> --defines="${PROJECT_BINARY_DIR}/Parser.h")
>>
>> But then both Parser.hpp and Parser.h are generated. But this is also
>> a very small issue.
>>
>> Finally, thanks a lot for supporting bison and flex in CMake.
>>
>> Kind regards,
>> visibility guy
> _______
> 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
>
--
Philip Lowman
___
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] How to findXXX libraries with debug suffix
On Wed, Feb 10, 2010 at 10:49 AM, Will Dicharry
wrote:
>> My only other comment is that some modules already use the following
>> form (usually due to someone adding DEBUG support later)
>> FOO_LIBRARY (cache variable)
>> FOO_LIBRARY_DEBUG (cache variable)
>> FOO_LIBRARIES (normal variable with debug/optimized keywords when
>> FOO_LIBRARY_DEBUG is available, else normal variable set to
>> FOO_LIBRARY)
>>
>> It would be nice to see a second macro that supports this format.
>
> I guess I'll have to think about that for a bit. But really, if other
> modules are going to need to modify code to use the macro, shouldn't they
> move to the more modern and descriptive form while they're at it? I know
> they probably have to maintain backwards compatibility, but they can do that
> by using the macro and setting FOO_LIBRARY to FOO_LIBRARY_RELEASE after the
> macro is called.
So if I understand correctly the code would do this?
find_library(FOO_LIBRARY ...)
find_library(FOO_LIBRARY_DEBUG ...)
set(FOO_LIBRARY_RELEASE ${FOO_LIBRARY})
call_the_macro()
# macro creates FOO_LIBRARIES debug/optimized keywords
# macro also sets FOO_LIBRARY with debug/optimized keywords *
I guess that probably would be safe and maintain backwards
compatibility with the module with the exception possibly of setting
FOO_LIBRARY to have the debug/optimized keywords (see below).
> I'm not sure I understand the situation you're describing here. Are you
> referring to the older backwards compatibility case, or something about the
> usual FOO_LIBRARY_DEBUG and FOO_LIBRARY_RELEASE case?
Sorry I wasn't very clear. This covers the older "backwards
compatibility" case. What I mean to say is that if the user was
relying on FOO_LIBRARY within existing target_link_libraries() calls
like below, they will get the warning below if FOO_LIBRARY is
redefined to contain debug/optimized keywords.
target_link_libraries(bar optimized ${FOO_LIBRARY})
# now FOO_LIBRARY contains
# optimized foo.so debug food.so
CMake Warning (dev) at CMakeLists.txt:8 (target_link_libraries):
Link library type specifier "optimized" is followed by specifier
"optimized" instead of a library name. The first specifier will be
ignored.
Removing the setting of FOO_LIBRARY to contain debug/optimized
keywords from your macro could break people. Leaving it in if
FOO_LIBRARY is used in the manor I illustrated causes warnings. You
might want to check with if(DEFINED FOO_LIBRARY) and if so not set it
maybe?
--
Philip Lowman
___
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] How to avoid continuous download while using ExternalProjects
On Wed, Feb 10, 2010 at 11:37 AM, David Cole wrote: > If anybody has other ideas to share downloads between "Release" and "Debug" > configurations, or other ways to avoid "unnecessary" downloads better, or > other ideas for any ExternalProject improvement, I'm all ears. :-) Caching for source tarballs would be a nice feature so that when you clean the project you don't have to redownload them. I pulled this off with stamp files in CMakePorts I think with some suggestions from you. The problem of course is if you really want to remove the downloads you need yet another target. Also, for any that are interested, beta releases of zlib now have a CMakeLists.txt in them. It could use testing on Mac OSX and other unix systems. http://zlib.net/current/beta/ -- Philip Lowman ___ 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] set “Whole Program Optimization”to Y es in VS 2005
On Tue, Feb 9, 2010 at 9:51 PM, wrote:
> When I use the blow statement for MSVC:
> SET (CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /GL")
>
> The corresponding statement in the .vcproj file generated by CMake is:
>
> AdditionalOptions=" /Zm1000 /GL"
>
> When I open the property pages in VS 2005，I can see /GL on the page on
> command line, but the item of“Whole Program Optimization”on the page of
> Optimization is still No.
>
> Why does not CMake generate WholeProgramOptimization="1" in the .vcproj
> file?
Not sure, probably an omission. "/GL" appears to be supported in
cmVS10CLFlagTable.h but not cmLocalVisualStudio7Generator.
Here's a patch
http://public.kitware.com/Bug/view.php?id=10263
P.S.
If it's not clear, CMake not supporting the WholeProgramOptimization
XML tag only affects what the Visual Studio GUI looks like and doesn't
affect the compiling of the code since the /GL shows up in the
additional options line and thus gets added to the command line when
the compiler is run.
--
Philip Lowman
___
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] How to findXXX libraries with debug suffix
On Tue, Feb 9, 2010 at 11:15 AM, Will Dicharry
wrote:
> Mike Jackson wrote:
>>
>> Here is one I wrote for Expat:
>>
>>
>> --8<
>> # - Find expat
>> # Find the native EXPAT headers and libraries.
>> #
>> # EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
>> # EXPAT_LIBRARIES - List of libraries when using expat.
>> # EXPAT_LIBRARY_DEBUG - Debug version of Library
>> # EXPAT_LIBRARY_RELEASE - Release Version of Library
>> # EXPAT_FOUND - True if expat found.
>
> The macro below has been generalized and placed in the standard set of CMake
> modules with the 2.8 release. I saw it duplicated in enough places that I
> added it for general use in the Modules directory. It's called
> SelectLibraryConfigurations, you can get information about it by typing
> cmake --help-module SelectLibraryConfigurations. You don't have to use the
> standard one, but it's there if you need it. Let me know if you run into any
> trouble with it.
Thank you for adding this and mentioning it! There are probably lots
of modules out there that need to be modified to take advantage of
this.
One minor thing I don't like about the module is this line (70) right here:
set( ${basename}_LIBRARY ${${basename}_LIBRARY} CACHE FILEPATH "The
${basename} library")
Presumably users of this module have already called
find_library(${basename}_LIBRARY_RELEASE) and
find_library(${basename}_LIBRARY_DEBUG) since it's expecting these
names. Why then add a 3rd cache variable? If the user were to change
${basename}_LIBRARY_DEBUG after an initial configure, the cache
variable will not get fixed since set() does not operate on cache
variables that have already been initialized unless FORCE is used.
This isn't a major issue since you define a ${basename}_LIBRARY normal
variable which overrides the cache variable immediately above it. At
best, line 70 where you declare the CACHE variable is superfluous. It
could also be a little confusing to some users who change it in the
CACHE and see no effect.
===
My only other comment is that some modules already use the following
form (usually due to someone adding DEBUG support later)
FOO_LIBRARY (cache variable)
FOO_LIBRARY_DEBUG (cache variable)
FOO_LIBRARIES (normal variable with debug/optimized keywords when
FOO_LIBRARY_DEBUG is available, else normal variable set to
FOO_LIBRARY)
It would be nice to see a second macro that supports this format.
Also, the redefinition of FOO_LIBRARY to have optimized & release
keywords in it may or may not be desired. The only harm I can see
this causing is if a user were to have done this already in his
CMakeLists.txt. In this case they might find themselves with a CMake
error or linking against liboptimized.so! :)
if(FOO_LIBRARY_DEBUG)
target_link_libraries(bar optimized ${FOO_LIBRARY} debug
${FOO_LIBRARY_DEBUG})
else()
target_link_libraries(bar ${FOO_LIBRARY})
endif()
--
Philip Lowman
___
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] Manual version vs CMake version
On Fri, Feb 5, 2010 at 4:31 PM, Mateusz Loskot wrote: > Bill Hoffman wrote: >> Eric Noulard wrote: >> >>> That's true, may be the site could indicate that the doc is for latest >>> 2.6.x serie. >>> However the most trustfull way to check the doc of your current cmake >>> version is the command line. >>> >>> cmake --help-command if >>> >>> should give you the doc for the cmake version you are using. >>> >>> if you want html you can use: >>> >>> cmake --help-html > cmake-doc.html >>> >>> then browse the cmake-doc.html file. >> >> Or cmake --version. > > Yes, all this is true and I've managed to find a solution myself quite > easily, but I've posted as from position of an average > (read, rather lazy) user who preferes pretty website to read doc > than dark console :-) Also, it might not be a bad idea to mention the version number within the documentation when features are added, especially if features are going to be added during a patch release. The same should probably be true of new find modules. -- Philip Lowman ___ 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] Warning D9025 : overriding '/W3' with '/W4'
On Mon, Jan 18, 2010 at 7:17 PM, Mateusz Loskot wrote:
> Hi,
>
> In CMakeLists.txt I have something like this:
>
> if(MSVC)
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
> endif()
>
> I configure my build using command prompt of Visual Studio 2005 (8.0):
>
> D:\dev\geos\_svn\build-nmake>cmake -G "NMake Makefiles" ..\trunk
>
> and the compiler flags look as follows:
>
> CMAKE_CXX_FLAGS= /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /W4 /MP
>
> I build and I'm getting D9025 warning:
>
> D:\dev\geos\_svn\build-nmake> nmake
>
> Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> [ 0%] Building CXX object src/CMakeFiles/geos.dir/algorithm/Angle.cpp.obj
> cl : Command line warning D9025 : overriding '/W3' with '/W4'
>
>
> Would it be possible to get rid of this warning with some CMake magic?
Yes, you can use a regular expression to search and replace the
contents of CMAKE_CXX_FLAGS "/W3" (or /W[0-9]) with /W4... see
string(REGEX REPLACE...) in the docs.
Alternatively (and slightly better), you can create separate files
that will set the default MSVC compilation flags for you. You'd do
something like in the example below, but instead of
CMAKE_CXX_FLAGS_DEBUG, CMAKE_CXX_FLAGS_RELEASE, etc., you would only
need to specify CMAKE_C_FLAGS and CMAKE_CXX_FLAGS and make them
whatever they are in the CACHE by default but with /W4 instead of /W3.
http://www.itk.org/Wiki/CMake_FAQ#Make_Override_Files
--
Philip Lowman
___
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] FindGTest patch
On Sat, Jan 16, 2010 at 10:16 AM, Stephan Menzel wrote: > please correct me if I'm wrong but in my impression the existing > FindGTest module is rather ignorant about finding 64 bit builds on > windows. It also doesn't handle Debug/Release linking very well. Also > it appears not to be quite consistent with it's API description. > Please find a patch attached that solves at least some of those > problems for your consideration. Thanks for adding the 64-bit support. I will merge it in soon but before I do I just wanted to confirm that the path for the 64-bit libraries is "msvc/x64/Debug" & "msvc/x64/Release" regardless of if the MD or MT project files are chosen? Also, not sure exactly what you mean by not handling debug/release linking very well. Where did you find that version of FindGTest and what was wrong with it? It looks different from the one that was released with CMake 2.8.0. Also, The latest version in CMake CVS (with some minor changes from 2.8.0) is here: http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindGTest.cmake?revision=1.4&root=CMake&view=markup -- Philip Lowman ___ 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] Visual Studio with static runtime
On Fri, Jan 15, 2010 at 1:21 PM, Dave Partyka wrote: > I think you just change the appropriate flag in > CMAKE_CXX_FLAGS_ variable to control this. By Default It uses > the Dll runtime via the MD/MDd flags. > See this table for the other variations of this flag. > http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.71).aspx For tips on how to change your CMakeLists.txt, see also: http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F -- Philip Lowman ___ 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] Proposal for new generator options
On Fri, Jan 15, 2010 at 3:20 PM, Jochen Wilhelmy wrote: > Hi! > > This proposal addresses the following issue: > currently there is no solution for creating Visual Studio project > files for static runtime without editing the cmake files. > As the goal of cmake is to define a project in an abstract way it should > be possible to generate for static runtime only via the command line > interface > since someone who never uses Visual Studio will probably not account > for this issue. > > A solution could look like this: > split the -G option into three options, e.g. > -G the generator > -V the Version > - T the Target platfrom > > some examples: > old: -G "Visual Studio 8 2005 Win64" > new: > -G "Visual Studio" -V 8 -T Win64 > or equivalent > -G "Visual Studio" -V 2005 -T Win64 > > old: -G "Eclipse CDT4 - Unix Makefiles" > new: -G "Eclipse CDT" -V4 -T "Unix Makefiles" > > in this new system the static runtime is a target: > -G "Visual Studio" -V 8 -T "Win32 static" > > of course the old generator names can continue to exist > for backward compatibility. There are at least 3 ways to solve this problem without introducing any changes to CMake. See the CMake FAQ. http://www.itk.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F If there is enough demand to add a feature to do this without requiring CMakeLists.txt modifications, at least do something simpler such as adding a variable like CMAKE_MSVC_COMPILE_WITH_MT or something like that. This way all that needs to be modified is Modules/Platform/Windows-cl.cmake to set the initial cache differently and perhaps adding a checkbox to the GUI when selecting the initial generator. -- Philip Lowman ___ 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] ANN: UseOcaml.cmake
On Thu, Jan 14, 2010 at 5:11 AM, Keyan wrote: > hi, > > ups ... i thought i replied to the list. thanks for the link. i will adapt my > find-script to the requirements and maintain the package. You should work with Judicaël to combine the best of both of your works together into one FindOCaml and UseOCaml script. There is no sense having two of them out there. -- Philip Lowman ___ 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] ANN: UseOcaml.cmake
On Mon, Jan 11, 2010 at 3:39 AM, Keyan wrote:
>> It looks like a couple of the macros don't have the OCAML_ name prefix
>> added to them. For example, COPY_FILE & GET_DEPENDENCIES. You should
>> add the prefix to them as well to prevent name collision when other
>> people use your code.
>
>thanks. wasnt aware of this coding standard, but it makes sense :)
>
>> For the INCLUDES feature, doesn't it just get turned into a list you
>> can iterate on? Couldn't you just use foreach() on it and add the
>> "-I" argument and path argument to a separate list that gets passed to
>> add_custom_command()?
>>
>> foreach(path ${includelist})
>> list(APPEND myargs "-I")
>> list(APPEND myargs "${path}")
>> endforeach()
>
> nice, it worked. my mistake was that i used:
> set(myargs "{$myargs} -I ${path}")
> instead.
>
> i will try to write a FindOcaml.cmake script soon. when i am done, what is
> the best practice to make it available?
Sorry, your email got accidently buried for 3 days. :) Also please
reply to all always so the list gets a copy of the thread.
I think the best way to get it available it to have it released as
part of CMake's Modules folder. To do this you have to volunteer to
maintain the module (basically to deal with patches and bugs) and
follow the process documented in Modules/README.txt to obtain CVS
commit access.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup
--
Philip Lowman
___
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] ANN: UseOcaml.cmake
On Sat, Jan 9, 2010 at 2:11 PM, Keyan wrote:
> Hi,
>
> adapted from UseLATEX.cmake, i wrote a UseOcaml.cmake script, which can be
> found here:
>
> http://yars.svn.sourceforge.net/viewvc/yars/branches/yars-refactoring/modules/UseOcaml.cmake?revision=509&view=markup
>
> it is not complete yet, but it allows to easily compile ocaml-binaries in the
> following way:
>
> ADD_OCAML_TARGET(
> OUTPUT loc
> MAIN loc.ml
> SOURCES file_node.ml files.ml io.ml file_statistics.ml
> message_node.ml
> HEADERS file_node.mli files.mli io.mli file_statistics.mli
> message_node.mli
> LIBRARIES unix.cmxa str.cmxa extLib.cmxa
> INCLUDES /opt/local/lib/ocaml/site-lib/extlib
> )
>
> one current problem is that i cannot add multiple entries to the INCLUDES.
>
> i am happy to receive comments.
It looks like a couple of the macros don't have the OCAML_ name prefix
added to them. For example, COPY_FILE & GET_DEPENDENCIES. You should
add the prefix to them as well to prevent name collision when other
people use your code.
For the INCLUDES feature, doesn't it just get turned into a list you
can iterate on? Couldn't you just use foreach() on it and add the
"-I" argument and path argument to a separate list that gets passed to
add_custom_command()?
foreach(path ${includelist})
list(APPEND myargs "-I")
list(APPEND myargs "${path}")
endforeach()
I would also recommend making all commands lowercase so it's consistent.
--
Philip Lowman
___
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] Can you add sources to a target library after add_library()?
I highly doubt it. Best practice is to just use conditionals to add the necessary source files to a list variable prior to the add_library() call. On Sat, Jan 9, 2010 at 5:48 PM, Marcel Loose wrote: > Hi all, > > I've been searching the manuals, but couldn't find a way to add sources > to a target library *after* the add_library() command, e.g., using > set_target_properties()? Is this possible at all? > > Best regards, > Marcel Loose. > > > ___ > 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 > -- Philip Lowman ___ 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] xxxxxSPAMxxxxx Simple Question Regarding Link Libraries on Linux
Whoever developed foo.a should call it libfoo.a instead so it meets
standards. All libraries on Linux are supposed to start with "lib"
with the possible exception of dynamically loaded shared libraries
(i.e. plugins).
If you still can't rename it, you can do target_link_libraries(bar
/full/path/to/foo.a).
To get the full path of your source tree you can use
${CMAKE_CURRENT_SOURCE_DIR}.
On Tue, Jan 5, 2010 at 5:57 PM, wrote:
> How do I link a *.a file that doesn't start with "lib" to an executable?
> For example, if I have a library named foo.a with a function called getnum,
> how do I link to foo.a in CMakeLists.txt?
>
> If my executable file is
> ---main.cpp---
> extern int getnum();
> int main(int, char**) { cout << getnum() << endl;}
>
> and my CMakeFile is
> ---CMakeLists.txt---
> PROJECT(TESTPROJECT)
> ADD_EXECUTABLE(test main.cpp foo.a)
> ---
> I'll get an error about an undefined reference to getnum when I run the
> makefile.
> If I use TARGET_LINK_LIBRARIES(test foo), I'll get an error about not begin
> able to find the library, since it's using the -l flag for the linker. I'd
> rather not have to rename foo.a, because it will affect other existing
> software.
>
> Thanks,
> -Ed
>
> ___
> 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
>
--
Philip Lowman
___
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] [New Module] FindGTK2.cmake call for testing
On Mon, Jan 4, 2010 at 10:48 AM, Michael Wild wrote: > On 8. Jan, 2009, at 9:54 , Philip Lowman wrote: >> If you use GTK2 in any of your projects and have time, please test this >> CMake module and post any issues to this thread. I intend to check it into >> CMake and support it. >> >> Tested systems: >> >> Ubuntu 8.10 >> Windows/MSVC (official gtkmm installer) > > A year late to the party, but here my problems (using cmake-2.8-0): > > 1. FindGTK2.cmake doesn't find the GLib-2/GTK+-2 headers installed by fink on > Mac OS X. Adding /sw/include and /sw/lib to the PATHS list of the find_path > call solves this for me. > > 2. The second thing is, that on Mac you also need to explicitly link agains > gobject, so adding the call > > _GTK2_FIND_LIBRARY (GTK2_GOBJECT_LIBRARY gobject false true) > > just after the one for glib solves that problem for me. Thanks for the email, I've checked in fixes for both of your issues into CMake CVS. Could you try the FindGTK2.cmake module there (see link below) and report back? http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindGTK2.cmake?root=CMake&view=log Here's the newly created bug report if the changes don't work. http://public.kitware.com/Bug/view.php?id=10092 -- Philip Lowman ___ 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] target_link_libraries: prefer static to dynamic
On Sun, Jan 3, 2010 at 2:26 PM, Alexander Neundorf wrote: > Isn't there some "binutil" which can tell what kind of library some .lib is ? > Or maybe every dll (and that way the accompanying lib) has some functions > which only dlls have ? > Or maybe they references some special functions which maybe could be checked > with something like nm ? If I recall correctly we discussed this a long time ago and there were some dll specific symbols present in the accompanying import library that weren't there in the static library. -- Philip Lowman ___ 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] cmake query
You're missing the mingw32-make program. If you used the installer there is a checkbox for it. Alternatively you can download and unzip it from here: http://sourceforge.net/projects/mingw/files/MinGW%20make/ 2010/1/3 sdfsdfs sdfsdfsd : > Hello, Im ttrying to install a program in windows using cmake gui. I get the > folloeing errors when im trying to configure it: > > > The C compiler identification is GNU > > The CXX compiler identification is GNU > > Check for working C compiler: C:/MinGW/bin/gcc.exe > > CMake Error: Generator: execution of make failed. Make command was: make > "cmTryCompileExec\fast" > > Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken > > CMake Error at > ../../cmake-2.8.0-win32-x86/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:50 > (MESSAGE): > > The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test > > program. > > It fails with the following output: > > Change Dir: L:/.rsrc/CMakeFiles/CMakeTmp > > Run Build Command:make "cmTryCompileExec\fast" > > The system cannot find the file specified > > Generator: execution of make failed. Make command was: make > > "cmTryCompileExec\fast" > > CMake will not be able to correctly generate this project. > > Call Stack (most recent call first): > > CMakeLists.txt:3 (project) > > Configuring incomplete, errors occurred! > > > > > > Anyone got any ideas what is going wrong and how to fix the problem? > > > Windows Live: Keep your friends up to date with what you do online. > ___ > 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 > -- Philip Lowman ___ 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] EXECUTE_PROCESS and relative path
On Sun, Dec 20, 2009 at 10:53 AM, Steve Chu wrote:
> Does EXECUTE_PROCESS support relative path to CMakeLists.txt file?
>
> Suppose we have this demo:
>
> EXECUTE_PROCESS(
> COMMAND /bin/cat ./xxx
> # WORKING_DIRECTORY /some/absolute/path
> )
>
> If we do not set WORKING_DIRECTORY to absolute path, this command does not
> work.
> But I do not want to introduce a fixed absolute path(or ENV) that is
> up to who builds the project.
>
> So does cmake have a feature of relative path? Such as:
> EXECUTE_PROCESS(
> COMMAND /bin/cat RELATIVE{./xxx}
> )
>
> here RELATIVE means relative to CMakeLists.txt file.
You can use ${CMAKE_CURRENT_SOURCE_DIR} and the path relative to that.
http://www.cmake.org/Wiki/CMake_Useful_Variables
--
Philip Lowman
___
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] cmake 2.8.0, FindGTK2 on mac
Hi, I wrote FindGTK2. You might try removing the "gtk/" from line 350? Line 345 where the include path is searched for may also need to be modified... I don't have a MAC so if anyone has any better ideas, help would be appreciated. On Dec 1, 2009 1:27 PM, "Aleksander Demko" wrote: I can't seem to get FindGTK2 working under a Mac. I've installed the latest shipping library for mac from gtk.org, and even with a CMakeLists.txt file that has nothing but "FIND_PACKAGE(GTK2)", I get the following errors: CMake Error at /Applications/CMake 2.8-0.app/Contents/share/cmake-2.8/Modules/FindGTK2.cmake:93 (file): file Internal CMake error when trying to open file: /Library/Frameworks/Gtk.framework/Headers/gtk/gtk/gtkversion.h for reading. Call Stack (most recent call first): /Applications/CMake 2.8-0.app/Contents/share/cmake-2.8/Modules/FindGTK2.cmake:467 (_GTK2_GET_VERSION) CMakeLists.txt:2 (FIND_PACKAGE) -- Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY GTK2_GLIB_LIBRARY GTK2_GDK_LIBRARY) There seems to be one extra gtk/ in the above path. I'm new to mac development, but it seems there are some interesting path manipulations that are done when searching for header files in framework directories. I'm just not sure how to go about fixing this. Any ideas would be super. Thanks! ___ 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 ___ 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] set_target_properties - compile flags problem
For suggestions re. how to do /MT see the FAQ
http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
For COMPILE_FLAGS_ if you still need it, see this bug report.
There is a patch there although I've never tried it before.
http://www.cmake.org/Bug/view.php?id=6493
2009/11/21 "Sören Freudiger" :
> Hello
> I'm in big trouble. I cannot change the cxx compile flags as I want.
>
> binary project for VS 2008 - example:
> ...
> ADD_EXECUTABLE( project ${source_files} )
> SET_TARGET_PROPERTIES(project PROPERTIES COMPILE_FLAGS_DEBUG "/MTd")
> SET_TARGET_PROPERTIES(project PROPERTIES COMPILE_FLAGS_RELEASE "/MT")
> -> the resulting flag in my project is still /MD for ALL configrations
>
> changing the flag like:
> ADD_EXECUTABLE( project ${source_files} )
> SET_TARGET_PROPERTIES(project PROPERTIES COMPILE_FLAGS "/MT")
> -> leads to /MT in my project file for ALL configurations
>
> but this would be only a sucking workaround and I really need to have:
> /MT for release and /MTd for debug
>
> I also tried this one:
> ADD_EXECUTABLE( project ${source_files} )
> SET_TARGET_PROPERTIES(project PROPERTIES COMPILE_FLAGS "/MT")
> SET_TARGET_PROPERTIES(serial PROPERTIES COMPILE_FLAGS_DEBUG "/MTd")
> SET_TARGET_PROPERTIES(serial PROPERTIES COMPILE_FLAGS_RELEASE "/MT")
> -> still all configs have /MT only
>
> I think the problem is the predefined CXX_FLAG of CMake "/MD"
> Adding "/MT" overwrites the "/MD" but adding different flags for other
> configurations doesn't has any effects.
>
> What can I do? Any clue?
>
> Best,
> SirAnn
>
>
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> ___
> 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
>
--
Philip Lowman
___
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] Compiling zlib and libpng with one command
On Thu, Nov 12, 2009 at 6:59 PM, Hugh Sorby wrote: > > I am trying to compile zlib and libpng with one command, or more > specifically one series of commands. My aim is to get as simple as possible > to the following > > cmake > make > make install > > This should work out of the box with the CMakePorts packaging of libpng & zlib if you want to try those. 1. Download libpng & zlib http://code.google.com/p/cmakeports/downloads/list 2. Add the following to your toplevel CMakeLists... add_subdirectory(zlib) add_subdirectory(png) 3. The standard CMake variables generated by a find_package() call are present... so just use ZLIB_FOUND, ZLIB_INCLUDE_DIR, etc. like you normally would as if you were calling find_package(). 4. If you want to control the install options of these libraries (ie. header files, executables, etc.) you can use SKIP_INSTALL_[HEADERS | LIBRARIES | EXECUTABLES | FILES | ALL]. -- Philip Lowman ___ 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] How to include Boost in Visual Studio cmake project
On Thu, Nov 12, 2009 at 5:43 AM, Martin Peter Christiansen < martin.p.christian...@gmail.com> wrote: > I just tried the advise I was given, and the result was the following > > C:\local\workspace\RobWork\build\release>cmake -G "Visual Studio 9 2008" > -DCMAKE_BUILD_TYPE=Release ../.. > -- RobWork version 0.4.0 > -- Build configuration: Release > -- No Default.cmake file loaded, using default settings from > config.cmake.template > > CMake Warning (dev) at CMakeLists.txt:20 (INCLUDE): > Policy CMP0011 is not set: Included scripts do automatic cmake_policy > PUSH > and POP. Run "cmake --help-policy CMP0011" for policy details. Use the > cmake_policy command to set the policy and suppress this warning. > The included script > C:/local/workspace/RobWork/build/ProjectSetup.cmake > affects policy settings. CMake is implying the NO_POLICY_SCOPE option > for > compatibility, so the effects are applied to the including context. > This warning is for project developers. Use -Wno-dev to suppress it. > -- RobWork ROOT dir: C:/local/workspace/RobWork > CMake Error at C:/Programmer/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:879 (message): > Unable to find the requested Boost libraries. > Boost version: 1.39.0 > Boost include path: C:/local/boost/include/boost-1_39 > The following Boost libraries could not be found: > boost_thread > No Boost libraries were found. You may need to set Boost_LIBRARYDIR to > the > directory containing Boost libraries or BOOST_ROOT to the location of > Boost. > Call Stack (most recent call first): > build/depends.cmake:8 (FIND_PACKAGE) > build/RobWorkSetup.cmake:32 (INCLUDE) > CMakeLists.txt:36 (INCLUDE) > > > When I was building boost this time, I did ran the following commands: > - "C:\Downloads\boost_1_39_0>bjam.exe --prefix=C:\local\boost -toolset=msvs > define="_SECURE_SCL=0" define="_HAS_ITERATOR_DEBUGGING=0" -d+2" > - "C:\Downloads\boost_1_39_0>bjam.exe install --prefix=C:\local\boost" > > I removed all the old enviromental variables for boost and created the > following variable > - BOOST_ROOT = C:\local\boost > > In "C:\local\boost\lib" I have > - libboost_thread-vc90-mt.lib > - libboost_thread-vc90-mt-gd-1_39.lib > - libboost_thread-vc90-mt-gd.lib > > In "C:\local\boost\include\boost-1_39" I have > - A folder named "boost", but no subfolder or file called "boost_thread" > > > I must missing some variable or setting, but I can't figure out what... > Your directory structure sounds good to me. Here are a couple of suggestions... Check the documentation to FindBoost.cmake. Have you specified Boost_USE_STATIC_LIBS and Boost_USE_MULTITHREADED appropriately? These affect which libraries are detected and certain ones like boost_thread can't be found if Boost_USE_MULTITHREADED is not true. If this doesn't help, delete your build tree, then add this line prior to calling find_package(Boost...) set(Boost_DEBUG TRUE) Paste the output here and the relevant portions of your CMakeLists.txt when you call find_package(Boost...). -- Philip Lowman ___ 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] How to include Boost in Visual Studio cmake project
On Thu, Nov 12, 2009 at 5:55 AM, Hendrik Sattler wrote: > Zitat von Martin Peter Christiansen : > > In "C:\local\boost\lib" I have >> - libboost_thread-vc90-mt.lib >> - libboost_thread-vc90-mt-gd-1_39.lib >> - libboost_thread-vc90-mt-gd.lib >> > > MSVC libs usually do not have the lib... prefix. I am not sure if CMake > does find them in this case. > > The static MSVC libraries always have the lib prefix on Windows, the dynamic MSVC libraries do not. You have to set this variable to enable searching for static libraries. set(Boost_USE_STATIC_LIBSON) -- Philip Lowman ___ 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] FindX11 and FindLibXml2: different behaviors when using static/dynamic libraries
These seem like bugs to me. I'm pretty sure you're going to have similar
luck across many find modules in CMake, however. I don't think static
linking is that widely tested, unfortunately.
For libxml2's dependency on pthread you should be able to use FindThreads or
FindPthreads. I'm not sure about xcb_get_request_sent, I would try libxcb?
Also, complicating this problem are questions about "optional"
dependencies. CMake find modules don't know if libxml2 was built with or
without pthreads support, for example.
I think if you're planning on doing static linking, you're probably going to
have to resolve dependencies manually in a lot of cases at least with the
way things currently are done.
On Tue, Nov 10, 2009 at 5:29 PM, wrote:
>
> Dear all,
>
> For the compilation of my project, I want to provide a static or dynamic
> linked final executable (e.g.: linking preferentially with .a or .so
> libraries on Linux). For this, I set up a cache variable which enables to
> modify CMAKE_FIND_LIBRARY_SUFFIXES (".a;.so" or ".so;.a"). By the way, I
> don't know if that's the good way ?
>
> In a find module that I wrote myself, I call FindX11.cmake and
> FindXml2.cmake (provided by my distribution - suse 10.3). Everything works
> perfectly for dynamically linked libraries but fails at final link when
> using static link. Among the numerous errors, I can find things like
> -
>
> /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../lib64/libX11.a(xcb_lock.o):
> In function `_XPutXCBBuffer':
> (.text+0xd9): undefined reference to `xcb_get_request_sent'
> -
>
> /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../lib64/libxml2.a(threads.o):
> In function `xmlInitThreads':
> (.text+0x3a): undefined reference to `pthread_key_create'
>
> I guess it means that a static library is missing in the final link. But
> such dependencies shouldn't be taken by the corresponding find Module ? In
> that case, could you provide me a reference site where I can find reliable
> find modules. Or Am I missing something in my own find module ?
>
> Thanks for your help !
>
> Olivier
> ___
> 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
>
--
Philip Lowman
___
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] FindBoost: FIND_PACKAGE ( Boost COMPONENTS filesystem )
Personally, I think FindBoost is complex enough without having to also keep
track of boost's internal dependencies as well. Maybe things would be
better if the boost people published this info with every release.
If you'd like to check in support for the feature and volunteer to maintain
it, however, that's fine by me. It would make so much more sense to do
within Boost itself, though.
On Nov 4, 2009 11:54 AM, "Marcel Loose" wrote:
Hi Philip,
I've been following this thread with interest. Your solution puts the
burden on the (ignorant) end-user's shoulders. How is that poor
developer going to solve the pre/post version 1.34 issue, which is a
Boost-internal issue? In an ideal world, Boost would provide the
FindBoost.cmake file, or would generate the BoostConfig.cmake file.
Anyway, IMHO this really should be solved in FindBoost.cmake. One
possible way to make maintenance less of a burden is to define Boost's
(version-dependent) inter-dependencies once in FindBoost.cmake and let
the macro resolve these dependencies. Something like:
set(Boost_filesystem_DEPENDENCIES)
set(Boost_wave_DEPENDENCIES)
set(Boost_serialization_DEPENDENCIES filesystem) # Just assuming
# Assume filesystem depends on system for Boost > 1.34
if(${_boost_maj}.${_boost_min} VERSION_GREATER 1.34)
list(APPEND Boost_filesystem_DEPENDENCIES system)
endif()
# Assume wave depends on system for Boost > 1.36
if(${_boost_maj}.${_boost_min} VERSION_GREATER 1.36)
list(APPEND Boost_wave_DEPENDENCIES system)
endif()
Does that make any sense?
Best regards,
Marcel Loose.
On Wed, 2009-11-04 at 11:14 -0500, Philip Lowman wrote: > Mathieu, > > It's
a nice idea, but give...
> ___ > Powered by
www.kitware.com > > Visit other Kitw...
___
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] FindBoost: FIND_PACKAGE ( Boost COMPONENTS filesystem )
Mathieu,
It's a nice idea, but given that Boost could make any one of its libraries
dependent on "system" at any time they want in the future (and for all I
know there are others already dependent on it, besides wave and filesystem),
I'd rather the user be responsible for adding "system" manually. It's not
too hard to figure this out from the link errors.
On Nov 4, 2009 9:40 AM, "Mathieu Malaterre"
wrote:
Philip,
I guess I was not very clear in my previous email. But here is my
proposed change:
@@ -322,8 +322,14 @@
if(Boost_VERSION AND Boost_FIND_COMPONENTS)
math(EXPR _boost_maj "${Boost_VERSION} / 10")
math(EXPR _boost_min "${Boost_VERSION} / 100 % 1000")
- if(${_boost_maj}.${_boost_min} VERSION_LESS 1.35)
- list(REMOVE_ITEM Boost_FIND_COMPONENTS system)
+ if(${_boost_maj}.${_boost_min} VERSION_GREATER 1.34)
+ # when use asked for filesystem or wave, automatically add
+ # system to the list of components
+ list(FIND Boost_FIND_COMPONENTS filesystem v1)
+ list(FIND Boost_FIND_COMPONENTS wave v2)
+ if(v1 OR v2)
+ list(APPEND Boost_FIND_COMPONENTS system)
+ endif(v1 OR v2)
endif()
endif()
Therefore calling
FIND_PACKAGE ( Boost COMPONENTS filesystem REQUIRED)
will work on boost 1.34 and boost > 1.34
Comments ?
On Tue, Nov 3, 2009 at 3:20 PM, Mathieu Malaterre
wrote: > The way I see it to address is that
'system' is an internal d...
--
Mathieu
___
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] help me to resolve this issue
On Tue, Nov 3, 2009 at 10:40 PM, Alex H wrote: > Okay here's what I've done so far: > > add_definitions(-DV_FILM) > add_executable(hassel-film has-main.cpp) > > remove_definitions(-DV_FILM) > add_definitions(-DV_DIGITAL) > add_executable(hassel-digital has-main.cpp) > > What I want to do is after running cmake . and typing it make. I want to > generate two executable, one is hassel-film which is has-main.cpp compiled > with the flag -V_FILM > and the other one is hassel-digital which is compiled with the flag > -V_DIGITAL. How can I do this? The above code will compile with V_DIGITAL > flag, which is not what I want. > It would sure be great if in a future policy of CMake, add_definitions() behaved the way you describe it. I remember trying something similar a long time ago and being equally dumbfounded. There are other inconsistencies in how CMake behaves. Changing the CMAKE_CXX_FLAGS in-between add_executable() calls also doesn't seem to work for me, for example. In the meantime you're probably can make do with set_target_properties(), specifically the COMPILE_FLAGS property. http://www.cmake.org/cmake/help/cmake2.6docs.html#command:set_target_properties -- Philip Lowman ___ 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] several executables with cmake
On Tue, Nov 3, 2009 at 8:40 PM, Alex H wrote: > I have several executables that I want to be able to run using ctest, how > can I do this? > > As far as I know I can only add one executable to one test, using the > add_test. > > Any ideas? > You should be able to add as many executables as you want and run as many tests as you want on each one. E.g. enable_testing() add_executable(foo foo.cc) add_test(footest foo) add_executable(bar bar.cc) add_test(bartest bar) add_test(extra_bartest bar -extra) See also the documentation for add_executable() and add_test() http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_executable http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_test -- Philip Lowman ___ 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] FindBoost: FIND_PACKAGE ( Boost COMPONENTS filesystem )
This was addressed on the mailing list and I thought had been resolved based on user feedback. The code which is supposed to fix this is on line 326 of FindBoost as checked into CVS. A patch would be appreciated if the code doesn't work for you. See also bug 8734 On Nov 3, 2009 5:05 AM, "Mathieu Malaterre" wrote: Hi Philip, That's where I stop understanding. I cannot state this: FIND_PACKAGE ( Boost COMPONENTS filesystem REQUIRED) # ideal If I follow your suggestion I need to express an internal dependencie at user level: FIND_PACKAGE ( Boost COMPONENTS filesystem system REQUIRED) which fails for Boost 1.34 with: ... CMake Error at Cmake/FindBoost.cmake:894 (message): Unable to find the requested Boost libraries. Boost version: 1.34.1 Boost include path: /usr/include The following Boost libraries could not be found: boost_system Some (but not all) of the required Boost libraries were found. You may need to install these additional Boost libraries. Alternatively, set Boost_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:33 (FIND_PACKAGE) ... Thanks On Mon, Nov 2, 2009 at 6:24 PM, Philip Lowman wrote: > Add system to the list of ... -- Mathieu ___ 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] selecting different libraries for different configuration types?
On Mon, Nov 2, 2009 at 7:36 PM, Roger Dannenberg wrote: > Tyler Roscoe wrote: > >> On Mon, Nov 02, 2009 at 06:32:19PM -0500, Roger Dannenberg wrote: >> >> >>> set_target_properties(mylib-static PROPERTIES CMAKE_C_FLAGS_DEBUG "/MTd") >>> >> >> > Thanks again. COMPILE_FLAGS seems to pass target-specific flags and > overrides CMAKE_C_FLAGS_, but COMPILE_FLAGS_ doesn't do > anything. I looked at the code in cmLocalVisualStudio7Generator.cxx and > found where it adds COMPILE_FLAGS, but I don't see anything that would > support flags that are both configuration-specific and target-specific. I > hope I'm missing something. Any other ideas? > Looks like there is a patch in the tracker for this very feature. http://public.kitware.com/Bug/view.php?id=6493 Barring the above working, you might be able to adapt something from options #2 or #3 below. http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F -- Philip Lowman ___ 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] FindBoost: FIND_PACKAGE ( Boost COMPONENTS filesystem )
Add system to the list of components. FindBoost should silently omit it on
older versions of boost w/o a system library. At least I think.
Sorry for brief messages, typing on mobile :)
On Nov 2, 2009 11:30 AM, "Mathieu Malaterre"
wrote:
I can reproduce with CMake / CVS.
FIND_PACKAGE ( Boost COMPONENTS filesystem )
ADD_LIBRARY( bla SHARED bla_use_filesystem.cxx)
TARGET_LINK_LIBRARIES( bla ${Boost_LIBRARIES} )
->
CMakeFiles/Csm.dir/Common/csmPathSet.cc.o: In function
`__static_initialization_and_destruction_0':
/usr/include/boost/system/error_code.hpp:205: undefined reference to
`boost::system::get_system_category()'
/usr/include/boost/system/error_code.hpp:206: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:211: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:212: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:213: undefined reference to
`boost::system::get_system_category()'
CMakeFiles/Csm.dir/IO/csmGraphLoader.cc.o: In function
`__static_initialization_and_destruction_0':
/usr/include/boost/system/error_code.hpp:205: undefined reference to
`boost::system::get_system_category()'
/usr/include/boost/system/error_code.hpp:206: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:211: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:212: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:213: undefined reference to
`boost::system::get_system_category()'
CMakeFiles/Csm.dir/IO/csmChessBoardLoader.cc.o: In function
`__static_initialization_and_destruction_0':
/usr/include/boost/system/error_code.hpp:205: undefined reference to
`boost::system::get_system_category()'
/usr/include/boost/system/error_code.hpp:206: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:211: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:212: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:213: undefined reference to
`boost::system::get_system_category()'
CMakeFiles/Csm.dir/IO/csmModelLoader.cc.o: In function
`__static_initialization_and_destruction_0':
/usr/include/boost/system/error_code.hpp:205: undefined reference to
`boost::system::get_system_category()'
/usr/include/boost/system/error_code.hpp:206: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:211: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:212: undefined reference to
`boost::system::get_generic_category()'
/usr/include/boost/system/error_code.hpp:213: undefined reference to
`boost::system::get_system_category()'
What should have I been writing instead ?
Thanks !
On Mon, Nov 2, 2009 at 4:41 PM, Philip Lowman wrote: >
Which FindBoost are you u...
--
Mathieu
___
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] FindBoost: FIND_PACKAGE ( Boost COMPONENTS filesystem )
Which FindBoost are you using? I'm pretty sure I fixed this issue a while ago. On Nov 2, 2009 9:46 AM, "Mathieu Malaterre" wrote: Hi there, I am wondering if I am missing something. I'd like to write: FIND_PACKAGE ( Boost COMPONENTS filesystem ) However using a recent boost (1.40), it gives a linker error. So I need to write something like: FIND_PACKAGE ( Boost COMPONENTS filesystem system ) but then it breaks compatibility with boost 1.34 (default package on one of my ubuntu machine). What is the synthetic way for writing this ? I am linking to filesystem, I do not want to explicitely search for an implementation detail. Thanks, -- Mathieu ___ 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 ___ 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] Make test an official dependency...
Are you looking for something like this...? if(TARGET foo) add_test(footest foo) endif() On Wed, Oct 21, 2009 at 2:33 PM, Theodore Papadopoulo < theodore.papadopo...@sophia.inria.fr> wrote: > From the documentation of add_dependencies: > > Make a top-level target depend on other top-level targets. A top-level > target is one created by ADD_EXECUTABLE, ADD_LIBRARY, or ADD_CUSTOM_TARGET. > A test is thus not a valid target to add dependencies to. > > Often, one wants to build an executable only for the purpose of a test. > Excluding the executable > from the all target is easy. However, there seems to be currently no way > of indicating that a test > depends on an executable. Would it be possible to add some target name to > tests ?? > > If not, would it be at least possible to make "test" (and for what is worth > "all") some valid targets to > which dependencies can be added ?? > > Thank's for any hint. > ___ > 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 > -- Philip Lowman ___ 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] GTest Integration
The version in CMake CVS supports a Unix make install or using a VS build tree the last I checked. You can also manually arrange the MSVC generated stuff into a Unix style prefix if you want. Please have a look at the latest GTest.cmake and post an example of your problem if you can't resolve it. I believe you should also be able to look at the latest 2. 8 rc. On Oct 22, 2009 12:27 PM, "Dixon, Shane" wrote: I'm trying to use the Gtest module to find GTest. Does the FindGTest module work for 1.4.0? I noticed that there's a variable _gtest_libpath_suffixes that points to "lib" and when you unpack the 1.4.0 .tar.gz, there's no folder called lib in there. Does the FindGTest module require one to build and manually arrange a few things before it works? I can use the msvc folder to build the .libs, but it seems strange that the module would require one to manually arrange a few files into specific directories before it works. Is this an issue with v1.4.0 of GTest? -- Shane ___ 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 ___ 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] COMPILE_FLAGS_
cmake.org/Bug/view.php?id=6493
On Oct 20, 2009 11:29 AM, "Steven Wilson"
wrote:
I am asking why CMake doesn't support the following:
set_target_properties(${TARGET} PROPERTIES COMPILE_FLAGS_
"-fmyflag")
> Would set_target_properties() work? Then you can do something like: > >
set_target_properties(...
___
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
___
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 with NO_DEFAULT_PATH issue
On Mon, Oct 19, 2009 at 5:52 AM, Alexey Tkachenko
wrote:
> Hi,
> I'm trying to search Boost with find_package as it's said in manual:
> # first I try to search boost in my folder
> find_package(Boost PATHS /path/to/my/libs NO_DEFAULT_PATH)
> #then I try to search in standard paths
> find_package(Boost)
>
> but cmake shoes warning message on first find_package:
> --
> CMake Warning at CMakeLists.txt:41 (find_package):
> Could not find a configuration file for package Boost.
>
> Set Boost_DIR to the directory containing a CMake configuration file for
> Boost. The file will have one of the following names:
>
>BoostConfig.cmake
>boost-config.cmake
> -
>
> How can I suppress search in standard paths? Thanks in advance for any
> help.
>
You can set BOOST_ROOT which will cause FindBoost to search that path first,
but it will still fallback to the standard paths. There is a bug for this
in the tracker. I believe most people who use BOOST_ROOT simply rely on
manual inspection to work around this potential problem.
NO_DEFAULT_PATH is not legal on a find_package() call which explains your
problems above. To suppress the fallback behavior, you could add a
conditional to FindBoost.cmake to include NO_DEFAULT_PATH anywhere there is
a find_path() or find_library() call. E.g.
if(Boost_SET_NO_DEFAULT_PATH)
set(_boost_find_options NO_DEFAULT_PATH)
endif()
...
find_library(. ${_boost_find_options} ...)
The only reason this hasn't been fixed is I keep wondering if we could just
make FindBoost do this automatically if BOOST_ROOT is being used. But
ultimately this will probably break some builds of people who rely on
BOOST_ROOT as a "use it if it's there" feature so fixing it via a public
conditional (defaulting off) is probably the only way to go.
--
Philip Lowman
___
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] Turning off extra Visual Studio options
Thanks for linking. Posting via mobile :) On Oct 16, 2009 4:27 PM, "John Drescher" wrote: On Fri, Oct 16, 2009 at 4:14 PM, Philip Lowman wrote: > You may want to also look ... Found that: http://www.itk.org/Wiki/CMake_FAQ#Make_Override_Files Thanks. I will have to bookmark that.. John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Pleas... ___ 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] Turning off extra Visual Studio options
You may want to also look into platform override files. See the FAQ and search for override. On Oct 16, 2009 3:50 PM, "Tyler Roscoe" wrote: On Fri, Oct 16, 2009 at 12:16:12PM -0600, Steven Wilson wrote: > Is there a way to turn off all the ... I don't know of an easy way. I guess the best way would be to just override all the appropriate flags (CMAKE_CXX_FLAGS and friends) for any of your buildables that need to override them. You could also modify the Platform/ files for Windows in your CMake installation. tyler ___ Powered by www.kitware.comVisit other Kitware open... ___ 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] Why FindBoost messaging not unified?
On Fri, Oct 9, 2009 at 9:14 AM, Michael Jackson wrote: > I'll admit up front that I have NOT tried out the latest CVS Cmake BUT > something that I sometimes have add into the FindBoost are outputs that > print all the variant names of the boost library that CMake is trying to > search for with the BOOST_DEBUG enabled. I think this would be useful for > when the mailing list has to help debug some one else's boost installation > (as happens often). Any chance of getting more DEBUG messages added into the > FindBoost.cmake ? > Things like where cmake is searching for boost, what library names it is > using, did it find environment variables. Things like that. Just a thought. > Feel free to attach a patch to the bugtracker for whatever you'd like added to Boost_DEBUG. -- Philip Lowman ___ 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] Targets organisation of complex project
On Sun, Oct 11, 2009 at 9:01 PM, Tyler Roscoe wrote:
> On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote:
> > The sources are organised in large number of subdirectories and
> > sort of logical sub-libraries, but the binary output of compilation
> > is a single library.
> [snip]
> > It looks like the best portable approach is to walk through the whole
> > tree of project, collect all .c and .cpp files (assigning list of files
> > to global variables) and, back in the main CMakeLists.txt, stream all
> > source files to single ADD_LIBRARY call.
>
> This is what I would do. IME, CMake works best when you do the simplest
> thing that can possibly work.
>
I would do what makes sense in terms of the end user. If those separate
subdirectories are meant to be separate libraries, then build separate
libraries. If the source code is scattered across multiple subdirectories
but is all supposed to be part of the same library then build it together.
You can use PARENT_SCOPE to hand lists of source files up a directory, if
that is of interest.
set(FOO_SRCS ${list_of_sources} PARENT_SCOPE)
--
Philip Lowman
___
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] How send linker options for STATIC LIBRARY?
On Fri, Oct 9, 2009 at 4:04 PM, Aleksandr Udovenko wrote:
> On Fri, Oct 9, 2009 at 5:33 PM, Philip Lowman wrote:
> > On Fri, Oct 9, 2009 at 4:15 AM, Aleksandr Udovenko >
> > wrote:
> >>
> >> On Fri, Oct 9, 2009 at 10:04 AM, Philip Lowman wrote:
> >> > On Wed, Oct 7, 2009 at 11:45 AM, Aleksandr Udovenko
> >> >
> >> > wrote:
> >> >>
> >> >> I try cmake 2.6, 2.8 for microsoft visual studio 2005,2008.
> >> >> creating library:
> >> >>
> >> >> add_library(my_lib STATIC ${CPP_FILES})
> >> >>
> >> >> I try send some linker options by set
> >> >>
> >> >> set_target_properties(my_lib PROPERTIES LINK_FLAGS "some_opt")
> >> >>
> >> >> or
> >> >>
> >> >> set_target_properties(my_lib PROPERTIES LINK_FLAGS_
> >> >> "some_opt")
> >> >>
> >> >>
> >> >> it's ignored, as i understand from source code of vc7generator - it
> >> >> ignored extended and unknown option for static library but it works
> >> >> for exe and shared.
> >> >>
> >> >> How i can send my option to linker for static library?
> >> >
> >> > You might be able to use this:
> >> >
> >> >
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:STATIC_LIBRARY_FLAGS
> >>
> >> It is not good for me, i NOT need to set linker options globally, i
> >> need to set depend on target. STATIC_LIBRARY_FLAGS don't have
> >> expansion.
> >
> > STATIC_LIBRARY_FLAGS is a target property and not global in scope.
> >
> > add_library(foo STATIC foo.cc)
> > set_target_properties(foo PROPERTIES STATIC_LIBRARY_FLAGS "/myflag")
> >
> > Could you elaborate on what you mean by " expansion"?
> >
> > Please reply to the list. Thanks.
>
> STATIC_LIBRARY_FLAGS has act on all target at once. For example on
> Debug and Release simultaneously.
> But i want same as CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE], when i
> use it i can set linker flag separately for debug and release.
> I need the same but for STATIC library.
>
This doesn't appear to be implemented. You could file a feature request if
there isn't one already. I believe what you are asking for is support for
STATIC_LIBRARY_FLAGS_. There are several target properties that
are already build-type aware, so implementing this probably wouldn't be
extremely difficult.
--
Philip Lowman
___
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] Why FindBoost messaging not unified?
On Fri, Oct 9, 2009 at 6:05 AM, Fabio Fracassi wrote: > Philip Lowman schrieb: > >> If you have any other CMake related suggestions please feel free to >> accompany your mailing list posts with a feature request and/or patch on the >> bugtracker if you have the time. >> >> >> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log< >> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log >> > >> >> I have always wondered why FindBoost doesn't add some speculative future > Versions into _Boost_KNOWN_VERSIONS so that at least the Boost versions that > are likely to appear during the lifecycle of the current CMake version are > found without resorting to user supplied Boost_ADDITIONAL_VERSIONS. There is > no harm in searching for versions that are never going to be released > (except maybe longer search time), is there? > > I was thinking of something along the lines of the attached patch. > Or is this a horrible idea? > The whole Boost_ADDITIONAL_VERSIONS thing is a kludge and I think a better solution is needed which is why I have refrained from kludging it even more by guessing at future version numbers. I'm not sure if this was the original approach of the writers of FindBoost or if they had something else in mind, however. There's nothing preventing you from doing this yourself using Boost_ADDITIONAL_VERSIONS though. You might even be able to come up with a way to do it using the MATH() command and a for-loop. I'm not sure how many versions you would have to add before noticing a slowdown. Probably quite a bit. What's really needed is find_path/find_library/etc. searches with versioned filename support. This could solve problems in many find modules where libraries (or directories in the case of Boost) contain version numbers. At one point I was working on a patch for this and would like to get back to it one day when I have more time (unless someone else feels like tackling the problem sooner). http://public.kitware.com/Bug/view.php?id=8396 -- Philip Lowman ___ 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] How send linker options for STATIC LIBRARY?
On Fri, Oct 9, 2009 at 4:15 AM, Aleksandr Udovenko wrote:
> On Fri, Oct 9, 2009 at 10:04 AM, Philip Lowman wrote:
> > On Wed, Oct 7, 2009 at 11:45 AM, Aleksandr Udovenko <
> udovenk...@gmail.com>
> > wrote:
> >>
> >> I try cmake 2.6, 2.8 for microsoft visual studio 2005,2008.
> >> creating library:
> >>
> >> add_library(my_lib STATIC ${CPP_FILES})
> >>
> >> I try send some linker options by set
> >>
> >> set_target_properties(my_lib PROPERTIES LINK_FLAGS "some_opt")
> >>
> >> or
> >>
> >> set_target_properties(my_lib PROPERTIES LINK_FLAGS_
> >> "some_opt")
> >>
> >>
> >> it's ignored, as i understand from source code of vc7generator - it
> >> ignored extended and unknown option for static library but it works
> >> for exe and shared.
> >>
> >> How i can send my option to linker for static library?
> >
> > You might be able to use this:
> >
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:STATIC_LIBRARY_FLAGS
>
> It is not good for me, i NOT need to set linker options globally, i
> need to set depend on target. STATIC_LIBRARY_FLAGS don't have
> expansion.
>
STATIC_LIBRARY_FLAGS is a target property and not global in scope.
add_library(foo STATIC foo.cc)
set_target_properties(foo PROPERTIES STATIC_LIBRARY_FLAGS "/myflag")
Could you elaborate on what you mean by " expansion"?
Please reply to the list. Thanks.
--
Philip Lowman
___
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] How send linker options for STATIC LIBRARY?
On Wed, Oct 7, 2009 at 11:45 AM, Aleksandr Udovenko wrote:
> I try cmake 2.6, 2.8 for microsoft visual studio 2005,2008.
> creating library:
>
> add_library(my_lib STATIC ${CPP_FILES})
>
> I try send some linker options by set
>
> set_target_properties(my_lib PROPERTIES LINK_FLAGS "some_opt")
>
> or
>
> set_target_properties(my_lib PROPERTIES LINK_FLAGS_ "some_opt")
>
>
> it's ignored, as i understand from source code of vc7generator - it
> ignored extended and unknown option for static library but it works
> for exe and shared.
>
> How i can send my option to linker for static library?
>
You might be able to use this:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:STATIC_LIBRARY_FLAGS
--
Philip Lowman
___
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
