Re: [CMake] Need some directions for non-trivial setup
Hi Klaim, I would try to start with just one (base-)project, try to get everything in place and building the way you want it. If you're new to CMake, that's really the way to go. Once you have this base-project ready, you can think of starting a second project, using the base-project as EXTERNAL_PROJECT(), etc. Good luck. Marcel Loose. On 6-12-2010 at 21:46, in message aanlktimmvbbx-bq1kceahsxd=pkz-aagkbsj5dscu...@mail.gmail.com, Klaim mjkl...@gmail.com wrote: It's a bit clearer to me now ;-) Reading between the lines I get the feeling that you're probably better off using just a single project anyway. A developer doesn't need to continuously update the whole project when working on his subproject. Building the whole thing once in his working copy should suffice. Most of those projects (and future related projects) are not interdependent. I had a repository with everything inside before (using MSVC10 projects files) but it don't suit the developpement as each project really need a separate repository with separate history and separate teams working on it. I know I could use branches but that would make things harder when managing the different projects separately. They have to be separate. That's not a question to me anymore. Personally, I have not yet gained any experience with EXTERNAL_PROJECT(), so I cannot really help you there. If your subsystems are *really* stand-alone pieces of software, then you should create different CMake projects for them. However, like I said, I get the feeling that that's not the case in your situation. It is this very case. I need them to be separate projects, sometime linked because sometime you need some dependencies and maybe those dependencies are in the same family of projects or something. Those dependencies might be from outside too, but those projects have to be isolated. You might consider to use multiple PROJECT() commands inside your source tree. It will make your life slightly easier when you later decide you do want to split things up. That's already what I do. Well that's what's i'm trying but until now I can't find a way to say to CMake where are the other projects. I think I'm misusing EXTERNAL_PROJECT() but I'm not sure how. I'll get back on this issue in the week, see if I can make EXTERNAL_PROJECT() work as I need. I really think I don't have all the pieces of the puzzle. I'm reading the other thread about how to make libraries works correctly with CMake and I think I don't know a lot about what's really required. Anyway, thanks for your help. On 3-12-2010 at 13:13, in message aanlktimfweyejp+maqkzcg-7a92bebvxhgo0bxrlj...@mail.gmail.comAANLkTimfWeyEJP%2 bmaqkzcg-7a92bebvxhgo0bxrlj...@mail.gmail.com, Klaim mjkl...@gmail.com wrote: Thanks for pointing EXTERNAL_PROJECT , I've looked at it but can't understand how to get the path from outside. I'll try again see if I missed something about this feature and get back to you. The projects are almost all independent and I need to allow working with a clone of one subproject without retrieving everything, just it dependencies. I'll try to be more clear : - there is a common language used to describe a Sequence (it's not important so just understand that the important projects in the framework will require this) - there are tools, all made to manipulate the sequences, so each project is independant (separate repo) but some projects need to use other projects, so we need to provide their path in their Cmake - there are players that are like tools but are just interpreter projects - anyway they are as indpendant or dependant as tools projects/subrepos - now I have central repository (default) that is just meant to gather everything together; That's for people wanting everything but they are few. Most subproject developers will just get their dependencies and work from their, without updating the dependencies while developping. If you get the default repo, you have synchronized repos togethere (read: we use specific tags for each subrespo). So the default repository is mainly for the developers needing to touch everything. Like me. Is it more clear? On Fri, Dec 3, 2010 at 11:16, Marcel Loose lo...@astron.nl wrote: On 2-12-2010 at 16:12, in message aanlktimju5wav=ekxnbmkplnl7dn_c+xssgkoefm5...@mail.gmail.comEKxnbmkpLnL7dN_c% 2bxssgkoefm5...@mail.gmail.com EKxnbmkpLnL7dN_c% 2bxssgkoefm5...@mail.gmail.com, Klaim mjkl...@gmail.com wrote: Hi! I'm currently trying to understand how to use CMake for a non-trivial setup of multiple-projects-framework. I'm a beginner at CMake (as developer I mean, not as library user). I've read the docs and I tried to read the Ogre project CMake organization but it's a bit overkill for my project I think. Anyway, I'm lost here because I think I don't understand all I need to achieve what I
[CMake] Pass exclude test regex in visual studio
Hello, Is there a way to pass the ctest -E flag to a visual studio 10 configuration to prevent certain tests from running in the regressions? Thanks, Juan ___ 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
Hicham, Sorry for confusing. I supposed you asked about how to handle different versions of the Boost (1.42, 1.44 etc) on the same build server. On 6 December 2010 00:16, Hicham Mouline hic...@mouline.org wrote: -Original Message- From: philiplow...@gmail.com [mailto:philiplow...@gmail.com] On Behalf Of Philip Lowman Sent: 05 December 2010 04:54 To: Hicham Mouline Cc: Philip Lowman; CMake mailing list Subject: Re: [CMake] FindBoost: find both win32 and x64 static libs On Saturday, December 4, 2010, Hicham Mouline hic...@mouline.org 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 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. rds, -- Dmytro Ovdiienko e-mail: dmitriy.ovdie...@gmail.com skype: dmitriy.ovdie...@gmail.com mobile: +38050-1909731 ___ 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] Need some directions for non-trivial setup
I would try to start with just one (base-)project, try to get everything in place and building the way you want it. If you're new to CMake, that's really the way to go. Once you have this base-project ready, you can think of starting a second project, using the base-project as EXTERNAL_PROJECT(), etc. Yes, I started like that exactly. I've setup a simple library project, with the minimum CMakeLists.txt file. It generates correctly, find all required sources, correctly build when I try to build with MSVC2010. Now I tried to setup an executable project using this library project. Maybe I'm kind of stupid but I can't find a clear exlpaination/documentation about using EXTERNAL_PROJECT() so I failed so far to use it. Do you have a simple example somewhere? I'm sure I missed something in the doc but can't find what. I'm also looking for a way to provide/retreive the include paths of those external projects. ___ 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] Need some directions for non-trivial setup
By the way, I'm using a set of test projects to play with CMake and understand clearly how it works, so I can experiment. On Tue, Dec 7, 2010 at 11:59, Klaim mjkl...@gmail.com wrote: I would try to start with just one (base-)project, try to get everything in place and building the way you want it. If you're new to CMake, that's really the way to go. Once you have this base-project ready, you can think of starting a second project, using the base-project as EXTERNAL_PROJECT(), etc. Yes, I started like that exactly. I've setup a simple library project, with the minimum CMakeLists.txt file. It generates correctly, find all required sources, correctly build when I try to build with MSVC2010. Now I tried to setup an executable project using this library project. Maybe I'm kind of stupid but I can't find a clear exlpaination/documentation about using EXTERNAL_PROJECT() so I failed so far to use it. Do you have a simple example somewhere? I'm sure I missed something in the doc but can't find what. I'm also looking for a way to provide/retreive the include paths of those external projects. ___ 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
-Original Message- From: Dmytro Ovdiienko [dmitriy.ovdie...@gmail.com] Date: 07/12/2010 10:57 AM To: Hicham Mouline CC: Philip Lowman , CMake mailing list , boost-bu...@lists.boost.org Subject: Re: [CMake] FindBoost: find both win32 and x64 static libs Hicham, Sorry for confusing. I supposed you asked about how to handle different versions of the Boost (1.42, 1.44 etc) on the same build server. As a reminder, we have both 32bit and 64bit builds of the boost libraries and the attempt is to make FindBoost recognize both. I guess it makes more sense to me the have the bitness checked for inside FindBoost rather than in the caller's cmake file. Opinions? Given that one can't generate the bitness in the name of the boost libs, then the 32bit / 64bit libs need to be separate. In which case, we can just use BOOST_LIBRARY_DIR or whatever it's called explicitly. I can't see a nicer interface to provide, 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
Re: [CMake] FindBoost: find both win32 and x64 static libs
On Sunday, December 5, 2010, Hicham Mouline hic...@mouline.org 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] How to apply the --as-needed linker flag?
On 11/28/2010 09:10 AM, Alan W. Irwin wrote:
On 2010-11-28 06:39+0100 Michael Hertling wrote:
On 11/27/2010 06:45 PM, Alan W. Irwin wrote:
I just discovered that many Linux distros these days use the
--as-needed Linux linker option by default. At first glance that
option makes a lot of sense since it tends to reduce startup times.
But I guess there are some caveats as well which is probably why CMake
does not adopt this linker option by default for Linux builds.
However, I would at least like to try this option for my own Linux
builds without forcing it using target_link_libraries. Is it possible
to specify linker options such as --as-needed using environment
variables and/or -D options?
On Linux, CMake takes account of the LDFLAGS environment variable
for the initial configuration of the build directory, so saying
LDFLAGS=-Wl,--as-needed cmake path/to/srcdir
enables --as-needed for this build directory - forever.
Thanks, Michael, that was exactly what I needed. I was completely
unaware that environment variable worked for CMake despite many years
of using CMake on Linux. Is the LDFLAGS environment variable
documented for CMake anywhere? I couldn't find it in the
documentation you get with cmake --help-full, and it is also not
documented at http://www.cmake.org/Wiki/CMake_Useful_Variables. The
useful environment variables CXXFLAGS, CFLAGS, and FFLAGS that allow
you to specify general compiler flags in a convenient way are
undocumented as well, and that is a real shame.
AFAIK, these variables aren't documented anywhere apart from
occasionally appearing on the mailing list. However, a quick
grep \\\$ENV{[A-Za-z0-9_]\+} -r . | sed
s%^.*\\\$ENV{\([A-Za-z0-9_]\+\)}.*\$%\1% | sort -u
in the modules' directory reveals all of them which are read from
the environment. Apparently, the relevant ones are CC/CFLAGS, CXX/
CXXFLAGS, FC/FFLAGS, LDFLAGS, and RC/RCFLAGS for WIN32. Because of
their special meaning for a project's initial configuration, there
should be an enhancement of the useful-variables section, indeed.
Regards,
Michael
___
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] CPack WiX(.msi) Patch round 2
Folks - I've opened a ticket http://public.kitware.com/Bug/view.php?id=11575 to include my WiX patch I made a while back, and updated to target 2.8.3 src. Please update said ticket with your questions/comments/complaints as I'm determined to get this in your next point release. -- Cheers, Timothy St. Clair ___ 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] CPack WiX(.msi) Patch round 2
See my comments in the bug report. Thanks, David On Tue, Dec 7, 2010 at 9:00 AM, Tim St. Clair timoth...@gmail.com wrote: Folks - I've opened a ticket http://public.kitware.com/Bug/view.php?id=11575 to include my WiX patch I made a while back, and updated to target 2.8.3 src. Please update said ticket with your questions/comments/complaints as I'm determined to get this in your next point release. -- Cheers, Timothy St. Clair ___ 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] Pass exclude test regex in visual studio
On Tue, Dec 07, 2010 at 02:39:18AM -0600, j s wrote:
Is there a way to pass the ctest -E flag to a visual studio 10 configuration
to prevent certain tests from running in the regressions?
I don't know of a good way (and I'm not 100% sure what you mean by
prevent certain tests from running in the regressions) but what I
usually do is just edit the command associated with the RUN_TESTS target
and add command-line args (-E, -VV) there.
If you have a permanent set you like to exclude, you can just create
your own target MY_RUN_TESTS or whatever that runs
${CMAKE_CTEST_COMMAND} with your preferred arguments.
hth,
tyler
___
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] Best way to sniff for Fortran compiler?
Any suggest for the most-proper way, in a CMakeLists.txt file, to determine whether the Intel vs. GNU fortran compiler will be used? I need to use different sets of source files, and different compiler flags, depending on that detail. Christian Convey Scientist, NUWC Division Newport 1176 Howell St., Newport, RI 02842 email: christian.con...@navy.mil phone: (401) 832-6824 fax: (401) 832-4749 smime.p7s Description: S/MIME cryptographic signature ___ 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] Best way to sniff for Fortran compiler?
On 12/07/2010 05:15 PM, Convey, Christian J CIV NUWC NWPT, B-171 wrote: Any suggest for the most-proper way, in a CMakeLists.txt file, to determine whether the Intel vs. GNU fortran compiler will be used? I need to use different sets of source files, and different compiler flags, depending on that detail. Christian Convey I think the CMAKE_Fortran_COMPILER_ID variable should do the job... if(CMAKE_Fortran_COMPILER_ID STREQUAL GNU) message(STATUS Using GNU Fortran compiler) elseif(CMAKE_Fortran_COMPILER_ID STREQUAL Intel) message(STATUS Using Intel Fortran compiler) else() message(STATUS Using unknown Fortran compiler) endif() Michael ___ 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)
Yes it's true I didn't think of this one. It work nicely, here what I
have done:
wget http://googletest.googlecode.com/files/gtest-1.5.0.tar.bz2
tar xjvf gtest-1.5.0.tar.bz2
cd gtest-1.5.0
mkdir my-test
vim CMakeLists.txt # Add ADD_SUBDIRECTORY(my-test)
cd my-test
# SIMPLE HEADER FILE
vim source.h
void function ();
# SIMPLE SOURCE
vim source.c
#include stdio.h
void function ()
{
printf(my function to test\n);
}
# SIMPLE TEST
vim ut_source.cc
#include limits.h
#include unistd.h
#include gtest/gtest.h
#include source.h
static int something()
{
function();
return 0;
}
TEST(RRThread, CreateThread)
{
EXPECT_EQ(0, something());
}
vim CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(UnitTests)
INCLUDE_DIRECTORIES(~/gtest-1.5.0/my-test)
ADD_EXECUTABLE(UT ut_source.cc source.c)
TARGET_LINK_LIBRARIES(UT pthread ~/gtest-1.5.0/my-build/libgtest.a
~/gtest-1.5.0/my-build/libgtest_main.a)
cd ..
mkdir my-build
cd my-build
ccmake ..
make
Best Regards,
Kevyn-Alexandre Paré
On Wed, 2010-12-01 at 10:43 -0800, Ben Medina wrote:
Note that recent versions of gtest come with a CMakeLists.txt, so you
can just use add_subdirectory on the gtest source tree.
- Ben
On Wed, Dec 1, 2010 at 7: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 pretty sure that I'm missing little detail. How can I implicitly add
dependency to the object during the linking?
Regards
--
Kevyn-Alexandre Paré
On Mon, 2010-11-29 at 18:17 -0500, Philip Lowman wrote:
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
Re: [CMake] Makefile to CMakeLists.txt (GTEST)
Thx for replying,
But it didn't change by switching it.
Regards,
Kevyn-Alexandre Paré
On Wed, 2010-12-01 at 22:14 +, Fraser Hutchison wrote:
Hi Kevyn-Alexandre,
I think moving the -lpthread to after ${GTEST_LIB_PATH}gtest.a
${GTEST_LIB_PATH}gtest_main.a should help.
Cheers,
Fraser.
On 01/12/2010 3:59 PM, Kevyn-Alexandre Paré 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 pretty sure that I'm missing little detail. How can I implicitly add
dependency to the object during the linking?
Regards
--
Kevyn-Alexandre Paré
On Mon, 2010-11-29 at 18:17 -0500, Philip Lowman wrote:
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
___
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)
Thx for replying,
It seem that my simple example and using a add_subdirectory and reusing
CMakelists.txt of the gtest source solved my problem.
Regards,
On Sat, 2010-12-04 at 05:48 -0500, Philip Lowman wrote:
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
[CMake] Creating CMakeLists files from Solutions, Projects and Makefiles
I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. I can't imagine any programmer that would not love that ability. I think it would be something great to add to CMAKE. What are everyones thoughts on that? Paul Dean I.T. Professional 714-341-4519 p...@pdcomputertech.com aquawic...@hotmail.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating CMakeLists files from Solutions, Projects and Makefiles
Funny timing - I just did that today, at least in a crude manner. Long story short: On Unix/Linux/Mac, you can use the command-line tools (grep, sed, cut, xargs, etc.) to get the list of all source file that comprise the solutions' projects. If your needs aren't too fancy, it's pretty trivial to make a simple CMakeLists.txt file out of that list of files. Granted it's just a start, but my point is, it may not me as tough of a nut to crack as you fear, at least for relatively simple projects. -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Paul Dean Sent: Tuesday, December 07, 2010 14:14 To: cmake@cmake.org Subject: [CMake] Creating CMakeLists files from Solutions,Projects and Makefiles I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. I can't imagine any programmer that would not love that ability. I think it would be something great to add to CMAKE. What are everyones thoughts on that? Paul Dean I.T. Professional 714-341-4519 p...@pdcomputertech.com aquawic...@hotmail.com smime.p7s Description: S/MIME cryptographic signature ___ 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] Creating CMakeLists files from Solutions, Projects and Makefiles
On Tue, Dec 7, 2010 at 2:14 PM, Paul Dean aquawic...@hotmail.com wrote: I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. I can't imagine any programmer that would not love that ability. I think it would be something great to add to CMAKE. What are everyones thoughts on that? I would love to see a working QMake to CMake converter. And I mean one that works for complicated QMake projects not just a simple executable with a few headers and a few source files. John ___ 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] Pass exclude test regex in visual studio
Thanks. I have examples (for documentation) which run much longer than the
standard regressions.
Juan
On Tue, Dec 7, 2010 at 10:15 AM, Tyler Roscoe ty...@cryptio.net wrote:
On Tue, Dec 07, 2010 at 02:39:18AM -0600, j s wrote:
Is there a way to pass the ctest -E flag to a visual studio 10
configuration
to prevent certain tests from running in the regressions?
I don't know of a good way (and I'm not 100% sure what you mean by
prevent certain tests from running in the regressions) but what I
usually do is just edit the command associated with the RUN_TESTS target
and add command-line args (-E, -VV) there.
If you have a permanent set you like to exclude, you can just create
your own target MY_RUN_TESTS or whatever that runs
${CMAKE_CTEST_COMMAND} with your preferred arguments.
hth,
tyler
___
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)
Just want to say that since I want to test C code i need this in my
header file (for more details see
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%
2B#Linking_C_and_C.2B.2B_code):
#ifdef __cplusplus /* If this is a C++ compiler, use C linkage */
extern C {
#endif
void function ();
#ifdef __cplusplus /* If this is a C++ compiler, end C linkage */
}
#endif
On Tue, 2010-12-07 at 12:10 -0500, Kevyn-Alexandre Paré wrote:
Yes it's true I didn't think of this one. It work nicely, here what I
have done:
wget http://googletest.googlecode.com/files/gtest-1.5.0.tar.bz2
tar xjvf gtest-1.5.0.tar.bz2
cd gtest-1.5.0
mkdir my-test
vim CMakeLists.txt # Add ADD_SUBDIRECTORY(my-test)
cd my-test
# SIMPLE HEADER FILE
vim source.h
void function ();
# SIMPLE SOURCE
vim source.c
#include stdio.h
void function ()
{
printf(my function to test\n);
}
# SIMPLE TEST
vim ut_source.cc
#include limits.h
#include unistd.h
#include gtest/gtest.h
#include source.h
static int something()
{
function();
return 0;
}
TEST(RRThread, CreateThread)
{
EXPECT_EQ(0, something());
}
vim CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(UnitTests)
INCLUDE_DIRECTORIES(~/gtest-1.5.0/my-test)
ADD_EXECUTABLE(UT ut_source.cc source.c)
TARGET_LINK_LIBRARIES(UT pthread ~/gtest-1.5.0/my-build/libgtest.a
~/gtest-1.5.0/my-build/libgtest_main.a)
cd ..
mkdir my-build
cd my-build
ccmake ..
make
Best Regards,
Kevyn-Alexandre Paré
On Wed, 2010-12-01 at 10:43 -0800, Ben Medina wrote:
Note that recent versions of gtest come with a CMakeLists.txt, so you
can just use add_subdirectory on the gtest source tree.
- Ben
On Wed, Dec 1, 2010 at 7: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 pretty sure that I'm missing little detail. How can I implicitly add
dependency to the object during the linking?
Regards
--
Kevyn-Alexandre Paré
On Mon, 2010-11-29 at 18:17 -0500, Philip Lowman wrote:
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
Re: [CMake] FindBoost: find both win32 and x64 static libs
From: philiplow...@gmail.com [mailto:philiplow...@gmail.com] On Behalf Of Philip Lowman Sent: 07 December 2010 13:17 To: Hicham Mouline Cc: Philip Lowman; Dmytro Ovdiienko; CMake mailing list; boost-bu...@lists.boost.org Subject: Re: [CMake] FindBoost: find both win32 and x64 static libs On Sunday, December 5, 2010, Hicham Mouline hic...@mouline.org 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. Well I'd like to have other FindBoost users opinions. In terms of niceness (I believe there is no equivalent to Linux Standard Base which says where files should be on windows), I am flipping between: 1. c:\Program Files\boost\lib for 64bit libs and c:\Program Files (x86)\boost\lib for 32bit libs. I don't know where to put the headers then, maybe duplicate them in both directories. Then BOOST_ROOT is kind of irrelevant here. 2. C:\boost and then have lib32 lib64 under those, then BOOST_ROOT is c:\boost and your proposed change would be nice, though this somehow seems a little less standard to me. Shall we hear what other boosters say? 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
Re: [CMake] Creating CMakeLists files from Solutions, Projects and Makefiles
Hi, On Tue, Dec 07, 2010 at 02:25:18PM -0500, cmake-requ...@cmake.org wrote: Message: 4 Date: Tue, 7 Dec 2010 13:14:19 -0600 From: Paul Dean aquawic...@hotmail.com Subject: [CMake] Creating CMakeLists files from Solutions,Projects and Makefiles I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. http://sourceforge.net/projects/vcproj2cmake/ ? OK, it's not integrated, it's got its sizeable share of warts considering its current sorta-pre-beta status (I've currently got lots of notes for improvements in the near future though), but... it might just help after all, you know ;) Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. some sorcecode == 2MLOC on my side of the fence. It's working ok so far. Andreas Mohr ___ 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] Creating CMakeLists files from Solutions, Projects and Makefiles
On 07.12.10 14:31:56, John Drescher wrote: On Tue, Dec 7, 2010 at 2:14 PM, Paul Dean aquawic...@hotmail.com wrote: I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. I can't imagine any programmer that would not love that ability. I think it would be something great to add to CMAKE. What are everyones thoughts on that? I would love to see a working QMake to CMake converter. And I mean one that works for complicated QMake projects not just a simple executable with a few headers and a few source files. If I recollect my lessons in computer-theory correctly from university, then this is not possible for the general case. The problem is that QMake's language is very close to a general-purpose programming language, in particular it supports loops and conditions. This (again IIRC) makes it impossible for a program to decide wether two qmake projects or a qmake and a cmake project are semantically equal. It might be possible to do a bit-by-bit conversion of qmake project files to cmake, but I doubt the resulting cmake project is very useful except for pure building. Maintaining those cmake-files is not going to be easy or fun, nor would they match what a cmake developer would write if he set up stuff from scratch for cmake to build the project. And without the goal of switching from qmake to cmake, I don't see any point in doing a conversion in the first place - after all qmake can build the project on all interesting platforms already (else it would've been replaced). And that doesn't even consider a configure-script which I think most larger qmake projects have (like Qt itself). Andreas -- You are as I am with You. ___ 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] Creating CMakeLists files from Solutions, Projects and Makefiles
On 07.12.10 13:14:19, Paul Dean wrote: I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. I can't imagine any programmer that would not love that ability. I think it would be something great to add to CMAKE. What are everyones thoughts on that? See my answer to John, basically I doubt this is actually possible, except for very static project-files like may VS solutions are. For Makefile's or other build-tools like qmake its not going to work as they allow arbitrary commands to be executed at any point. You may be able to convert the files on a syntactic level, but that doesn't guarantee you they're semantically equivalent. And I bet in most cases (except very trivial ones) the generated CMake files will look very un-cmake'ish. Not to mention configure-scripts written in some shell-language or as C++ app... Also whats the point of being able to generate cmake files from any project files? If I just want to build the project then I can just as well use the existing buildsystem to build. Why bother installing cmake, if VS is already installed and the project has a solution file? If you want to port a project to cmake, you'll probably also end up restructuring some things wrt. the buildsystem, so a human needs to do the conversion anyway (and automatic conversion will be ugly, see above). This is similar to automatic translation of languages. Yes todays tools that do this are good enough so that you can get the meaning of a text for many cases. But they're still not good enough to match what a native speaker would've written or to be able to translate any arbitrary text (especially 'slang', scientific texts etc. are causing problems for such tools). Andreas -- You need more time; and you probably always will. ___ 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] Creating CMakeLists files from Solutions, Projects and Makefiles
And without the goal of switching from qmake to cmake, I don't see any point in doing a conversion in the first place - after all qmake can build the project on all interesting platforms already (else it would've been replaced). The reason I want this is there are a few QMake based libraries I would like to use with my projects but in their current form (without proper cmake support / finders ...) it becomes difficult to integrate them into projects that use CMake. John ___ 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] Creating CMakeLists files from Solutions, Projects and Makefiles
On 07.12.10 23:52:10, Andreas Pakulat wrote: On 07.12.10 13:14:19, Paul Dean wrote: I've been using CMAKE for a few years now and I absolutley LOVE it. It makes my life as a programmer so much easier to be able to generate project files on any platform. What hurts is doing the reverse. I can't count how many hours I've spent converting Solutions, Projects and Makefiles into CmakeLists files. I think if CMAKE could generate CMakeLists files from Solutions, Projects and Makefiles, it would be the ULTIMATE make system. Just think. Any time you run into some sorcecode that does not have a CMakeFile, you could generate it from the Makefile or Project. I can't imagine any programmer that would not love that ability. I think it would be something great to add to CMAKE. What are everyones thoughts on that? See my answer to John, basically I doubt this is actually possible, except for very static project-files like may VS solutions are. For Makefile's or other build-tools like qmake its not going to work as they allow arbitrary commands to be executed at any point. You may be able to convert the files on a syntactic level, but that doesn't guarantee you they're semantically equivalent. And I bet in most cases (except very trivial ones) the generated CMake files will look very un-cmake'ish. Not to mention configure-scripts written in some shell-language or as C++ app... Also whats the point of being able to generate cmake files from any project files? If I just want to build the project then I can just as well use the existing buildsystem to build. Why bother installing cmake, if VS is already installed and the project has a solution file? If you want to port a project to cmake, you'll probably also end up restructuring some things wrt. the buildsystem, so a human needs to do the conversion anyway (and automatic conversion will be ugly, see above). This is similar to automatic translation of languages. Yes todays tools that do this are good enough so that you can get the meaning of a text for many cases. But they're still not good enough to match what a native speaker would've written or to be able to translate any arbitrary text (especially 'slang', scientific texts etc. are causing problems for such tools). PS: All the above doesn't mean I think conversion-tools are totally useless. In fact the automake-to-cmake tool I think is very useful to get a basic skeleton cmake project up in no time. That way one can concentrate on the 'real work', i.e. porting the library/feature checks and making sure that includes and link-libs are set up correctly. Andreas -- You are so boring that when I see you my feet go to sleep. ___ 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 Dec 7, 2010, at 4:27 PM, Hicham Mouline wrote: From: philiplow...@gmail.com [mailto:philiplow...@gmail.com] On Behalf Of Philip Lowman Sent: 07 December 2010 13:17 To: Hicham Mouline Cc: Philip Lowman; Dmytro Ovdiienko; CMake mailing list; boost-bu...@lists.boost.org Subject: Re: [CMake] FindBoost: find both win32 and x64 static libs On Sunday, December 5, 2010, Hicham Mouline hic...@mouline.org 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. Well I'd like to have other FindBoost users opinions. In terms of niceness (I believe there is no equivalent to Linux Standard Base which says where files should be on windows), I am flipping between: 1. c:\Program Files\boost\lib for 64bit libs and c:\Program Files (x86)\boost\lib for 32bit libs. I don't know where to put the headers then, maybe duplicate them in both directories. Then BOOST_ROOT is kind of irrelevant here. 2. C:\boost and then have lib32 lib64 under those, then BOOST_ROOT is c:\boost and your proposed change would be nice, though this somehow seems a little less standard to me. Shall we hear what other boosters say? Thanks, I would see what the actual boost project has to say about this. BoostPro used to have precompiled binaries that got installed on windows. Where were those installed in the filesystem? Basically Windows is a crap-shoot. Nobody installs boost in the same location on windows and like Phillip said, Windows does not have anything like Linux Standard so your guess is as good as anyone else's. The best you can do is look for BOOST_ROOT and go from there. This is what the Boost project seems to advocate and it would be best if CMake could honor that as much as possible. Just to add to the Here is my setup bandwagon this is how I set things up on my windows X64 system: I have the following directories: C:\Developer\i386\Boost and C:\Developer\x64\Boost. I then have a pair of .bat files that get called each from a matching Command Prompt Shortcut. Each .bat file sets up the visual studio environment for either i386 or x64 and also sets the proper environment variables such as BOOST_ROOT. So when I configure a CMake project for use with Visual Studio for the first time I simply launch the proper Command Prompt (either i386 or x64) and run CMake from there. That way the proper environment is picked up. For completeness here is one of the .bat files: @rem This is the vcvarsamd64.bat file. It is invoked using the argument @rem x64 @SET VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 9.0 @SET VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC @SET FrameworkDir=C:\Windows\Microsoft.NET\Framework64 @SET FrameworkVersion=v2.0.50727 @SET Framework35Version=v3.5 @if %VSINSTALLDIR%== goto error_no_VSINSTALLDIR @if %VCINSTALLDIR%== goto error_no_VCINSTALLDIR @echo Setting environment for using Microsoft Visual Studio 2008 Beta2 x64 tools. @call :GetWindowsSdkDir @if not %WindowsSdkDir% == ( set PATH=%WindowsSdkDir%bin\x64;%WindowsSdkDir%bin\win64\x64;%WindowsSdkDir%bin;%PATH% set INCLUDE=%WindowsSdkDir%include;%INCLUDE% set LIB=%WindowsSdkDir%lib\x64;%LIB% ) @set PATH=%VCINSTALLDIR%\BIN\amd64;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%Framework35Version%\Microsoft .NET Framework 3.5 (Pre-Release Version);%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\VCPackages;%VSINSTALLDIR%\Common7\IDE;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR%\Common7\Tools\bin;%PATH% @set INCLUDE=%VCINSTALLDIR%\ATLMFC\INCLUDE;%VCINSTALLDIR%\INCLUDE;%INCLUDE% @set
Re: [CMake] test property COST not working in cmake 2.8.3?
In the process of attempting to fix this, I learned a lot of stuff about
how COST is handled that I've never encountered in the docs. Am I
missing something?
Here are some notes I made about the behavior of COST in CTest. If
others find them useful, I'd be happy to put them in the Wiki if someone
could nominate an appropriate place.
- Any COST property you set on a test is only a starting point. CTest
calculates an average cost value for a test each time that test is
run. This value is cached in Testing/Temporary/CTestCostData.txt.
- Tests that fail are also stored in
Testing/Temporary/CTestCostData.txt. On the next run, these tests have
their cost set to the maximum to insure that they are run first. I
believe this factors into later averaging, so that tests that fail more
frequently run earlier than tests that faill less frequently.
So, my solution. I've tried to implement Zach's suggested middle
ground.
For non-parallel CTest runs:
- The run failed tests first behavior is disabled to prevent failed
tests from clobbering their given COST property.
- The stored values in CTestCostData.txt are not used.
- As long as std::sort() is stable, the COST for each test should remain
0 and the tests should run in the order encountered in CMakeLists.txt.
For parallel CTest runs, failed tests run first and the moving average
is calculated and used. I think it makes sense that if you ask for tests
to run in parallel, you probably don't care so much about the order
(modulo test dependencies) so it is more reasonable to throw out the
COST data provided by the CMakeLists.txt.
I'm not really a C++ dev so please let me know if I'm way off base.
This patch appears to solve my immediate problem but if it can be
included upstream that is better for everyone.
The patch is against the 2.8.3 release.
I've also included a simple CMakeLists.txt for testing and verifying
behavior. Unpatched ctest 2.8.3 runs the tests in reverse order. Patched
ctest runs them according to COST.
##
### PATCH
##
--- ./Source/CTest/cmCTestMultiProcessHandler.cxx.orig 2010-12-07
15:31:57.091228582 -0800
+++ ./Source/CTest/cmCTestMultiProcessHandler.cxx 2010-12-07
19:59:11.115740666 -0800
@@ -434,9 +434,14 @@
if(index == -1) continue;
this-Properties[index]-PreviousRuns = prev;
- if(this-Properties[index] this-Properties[index]-Cost == 0)
+ // When not running in parallel mode, don't clobber test's cost with
+ // running average.
+ if(this-ParallelLevel 1)
{
-this-Properties[index]-Cost = cost;
+if(this-Properties[index] this-Properties[index]-Cost == 0)
+ {
+ this-Properties[index]-Cost = cost;
+ }
}
}
// Next part of the file is the failed tests
@@ -475,20 +480,23 @@
{
SortedTests.push_back(i-first);
-//If the test failed last time, it should be run first, so max the cost
-if(std::find(this-LastTestsFailed.begin(),
- this-LastTestsFailed.end(),
- this-Properties[i-first]-Name)
- != this-LastTestsFailed.end())
+//If the test failed last time, it should be run first, so max the cost.
+//Only do this for parallel runs; in non-parallel runs, avoid clobbering
+//the test's original cost.
+if(this-ParallelLevel 1)
{
- this-Properties[i-first]-Cost = FLT_MAX;
+ if(std::find(this-LastTestsFailed.begin(),
+ this-LastTestsFailed.end(),
+ this-Properties[i-first]-Name)
+ != this-LastTestsFailed.end())
+{
+this-Properties[i-first]-Cost = FLT_MAX;
+}
}
}
- if(this-ParallelLevel 1)
-{
+
TestComparator comp(this);
std::sort(SortedTests.begin(), SortedTests.end(), comp);
-}
}
//-
##
### TEST CASE
##
cmake_minimum_required(VERSION 2.8)
project(p)
enable_testing()
# Add in reverse order to make sure COST rather than order of add_test()
# commands really controls execution order.
add_test (i_should_run_fifth ${CMAKE_COMMAND} -E echo i should run fifth)
set_tests_properties (i_should_run_fifth PROPERTIES COST -100)
add_test (i_should_run_fourth ${CMAKE_COMMAND} -E echo i should run fourth)
set_tests_properties (i_should_run_fourth PROPERTIES COST -1)
add_test (i_should_run_third ${CMAKE_COMMAND} -E echo i should run third)
set_tests_properties (i_should_run_third PROPERTIES COST 1)
add_test (i_should_run_first ${CMAKE_COMMAND} -E echo i should run first)
set_tests_properties (i_should_run_first PROPERTIES COST 100)
# In serial mode, this test should always run second.
#
# In parallel mode (ctest -jN, N1), this test should run second in a fresh
# binary directory. Otherwise, since it failed previously, it should run first.
add_test
[Cmake-commits] CMake branch, next, updated. v2.8.3-754-g65d4422
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 65d442299fba56e0e05a3b475455cb194e2d917f (commit)
via 88cd4c1e923817f0a38bbc9d14d0bf40a2151897 (commit)
from 049091d2ba07fa049f8feb5ae74cf146f6ed28f5 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65d442299fba56e0e05a3b475455cb194e2d917f
commit 65d442299fba56e0e05a3b475455cb194e2d917f
Merge: 049091d 88cd4c1
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 14:46:51 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Dec 7 14:46:51 2010 -0500
Merge topic 'dev/strict-mode' into next
88cd4c1 Use 'CMake Warning' versus 'warning' for CDash
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=88cd4c1e923817f0a38bbc9d14d0bf40a2151897
commit 88cd4c1e923817f0a38bbc9d14d0bf40a2151897
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 14:17:50 2010 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Dec 7 14:40:21 2010 -0500
Use 'CMake Warning' versus 'warning' for CDash
diff --git a/Source/cmCommandArgumentParserHelper.cxx
b/Source/cmCommandArgumentParserHelper.cxx
index 23101b8..decdaaa 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -138,7 +138,7 @@ char* cmCommandArgumentParserHelper::ExpandVariable(const
char* var)
{
cmOStringStream msg;
msg this-FileName : this-FileLine :
- warning: uninitialized variable \' var \';
+ CMake Warning: uninitialized variable \' var \';
cmSystemTools::Message(msg.str().c_str());
}
}
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index ed435da..016d5fe 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1800,7 +1800,7 @@ void cmMakefile::CheckForUnused(const char* reason, const
char* name) const
{
cmOStringStream msg;
msg path : line :
- warning: ( reason ) unused variable \' name \';
+ CMake Warning: ( reason ) unused variable \' name
\';
cmSystemTools::Message(msg.str().c_str());
}
}
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index d9217ff..8c12ca9 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -4511,7 +4511,7 @@ void cmake::RunCheckForUnusedVariables(const std::string
reason) const
{
if(!it-second)
{
- std::string message = warning: The variable, ' + it-first +
+ std::string message = CMake Warning: The variable, ' + it-first +
', given on the command line, was not used during the + reason +
.;
cmSystemTools::Message(message.c_str());
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index ac36327..4cfbf93 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1099,9 +1099,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--build-project WarnUnusedUnusedViaSet
--build-options --warn-unused-vars)
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaSet PROPERTIES
-PASS_REGULAR_EXPRESSION warning: \\(changing definition\\) unused
variable 'UNUSED_VARIABLE')
+PASS_REGULAR_EXPRESSION CMake Warning: \\(changing definition\\) unused
variable 'UNUSED_VARIABLE')
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaSet PROPERTIES
-FAIL_REGULAR_EXPRESSION warning: \\(unsetting\\) unused variable
'UNUSED_VARIABLE')
+FAIL_REGULAR_EXPRESSION CMake Warning: \\(unsetting\\) unused variable
'UNUSED_VARIABLE')
LIST(APPEND TEST_BUILD_DIRS
${CMake_BINARY_DIR}/Tests/WarnUnusedUnusedViaSet)
ADD_TEST(WarnUnusedUnusedViaUnset ${CMAKE_CTEST_COMMAND}
@@ -1114,9 +1114,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--build-project WarnUnusedUnusedViaUnset
--build-options --warn-unused-vars)
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaUnset PROPERTIES
-PASS_REGULAR_EXPRESSION :7: warning: \\(unsetting\\) unused variable
'UNUSED_VARIABLE')
+PASS_REGULAR_EXPRESSION :7: CMake Warning: \\(unsetting\\) unused
variable 'UNUSED_VARIABLE')
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaUnset PROPERTIES
-FAIL_REGULAR_EXPRESSION :5: warning: \\(unsetting\\) unused variable
'UNUSED_VARIABLE')
+FAIL_REGULAR_EXPRESSION :5: CMake Warning: \\(unsetting\\) unused
variable 'UNUSED_VARIABLE')
LIST(APPEND TEST_BUILD_DIRS
${CMake_BINARY_DIR}/Tests/WarnUnusedUnusedViaUnset)
ADD_TEST(WarnUnusedCliUnused ${CMAKE_CTEST_COMMAND}
@@ -1129,7 +1129,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master
[Cmake-commits] CMake branch, next, updated. v2.8.3-756-gd2edef4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via d2edef4c09d2a68363ccd23080df1d7c56cbeb36 (commit) via e580daec4c6debeae2462ac59fee436524c3dedb (commit) from 65d442299fba56e0e05a3b475455cb194e2d917f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2edef4c09d2a68363ccd23080df1d7c56cbeb36 commit d2edef4c09d2a68363ccd23080df1d7c56cbeb36 Merge: 65d4422 e580dae Author: Brad King brad.k...@kitware.com AuthorDate: Tue Dec 7 15:07:01 2010 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Dec 7 15:07:01 2010 -0500 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-759-gf8719ea
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via f8719ead3fd52e6a97bc873fc1195bf552800ed1 (commit) via 35fd8d3abbbc0fa5de04fd46803bfa625218306d (commit) via 2a214ad8b57716d05d9ae0b5b81682e023714329 (commit) from d2edef4c09d2a68363ccd23080df1d7c56cbeb36 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f8719ead3fd52e6a97bc873fc1195bf552800ed1 commit f8719ead3fd52e6a97bc873fc1195bf552800ed1 Merge: d2edef4 35fd8d3 Author: David Cole david.c...@kitware.com AuthorDate: Tue Dec 7 15:28:20 2010 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Tue Dec 7 15:28:20 2010 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-763-g7a51a21
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 7a51a2131a40aca492ed26b5ffa0686f99dad5ed (commit)
via 4e3bea41ee939a039b53d5963f459c354bcb2b42 (commit)
via 8e8c9e49243674579545d5f27101597604c96f12 (commit)
via 668e005db5d9cece95965e23b8c589bd50a29faa (commit)
from f8719ead3fd52e6a97bc873fc1195bf552800ed1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a51a2131a40aca492ed26b5ffa0686f99dad5ed
commit 7a51a2131a40aca492ed26b5ffa0686f99dad5ed
Merge: f8719ea 4e3bea4
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 16:48:25 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Dec 7 16:48:25 2010 -0500
Merge topic 'dev/strict-mode' into next
4e3bea4 Update expected messages to new format
8e8c9e4 Don't check at destruction for usage
668e005 Use cmake::IssueMessage for warnings
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e3bea41ee939a039b53d5963f459c354bcb2b42
commit 4e3bea41ee939a039b53d5963f459c354bcb2b42
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 16:46:10 2010 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Dec 7 16:46:10 2010 -0500
Update expected messages to new format
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 4cfbf93..b60a610 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1099,9 +1099,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--build-project WarnUnusedUnusedViaSet
--build-options --warn-unused-vars)
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaSet PROPERTIES
-PASS_REGULAR_EXPRESSION CMake Warning: \\(changing definition\\) unused
variable 'UNUSED_VARIABLE')
+PASS_REGULAR_EXPRESSION unused variable \\(changing definition\\)
'UNUSED_VARIABLE')
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaSet PROPERTIES
-FAIL_REGULAR_EXPRESSION CMake Warning: \\(unsetting\\) unused variable
'UNUSED_VARIABLE')
+FAIL_REGULAR_EXPRESSION unused variable \\(unsetting\\)
'UNUSED_VARIABLE')
LIST(APPEND TEST_BUILD_DIRS
${CMake_BINARY_DIR}/Tests/WarnUnusedUnusedViaSet)
ADD_TEST(WarnUnusedUnusedViaUnset ${CMAKE_CTEST_COMMAND}
@@ -1114,9 +1114,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--build-project WarnUnusedUnusedViaUnset
--build-options --warn-unused-vars)
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaUnset PROPERTIES
-PASS_REGULAR_EXPRESSION :7: CMake Warning: \\(unsetting\\) unused
variable 'UNUSED_VARIABLE')
+PASS_REGULAR_EXPRESSION CMake Warning .*:7 \\(set\\):)
SET_TESTS_PROPERTIES(WarnUnusedUnusedViaUnset PROPERTIES
-FAIL_REGULAR_EXPRESSION :5: CMake Warning: \\(unsetting\\) unused
variable 'UNUSED_VARIABLE')
+FAIL_REGULAR_EXPRESSION CMake Warning .*:5 \\(set\\):)
LIST(APPEND TEST_BUILD_DIRS
${CMake_BINARY_DIR}/Tests/WarnUnusedUnusedViaUnset)
ADD_TEST(WarnUnusedCliUnused ${CMAKE_CTEST_COMMAND}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e8c9e49243674579545d5f27101597604c96f12
commit 8e8c9e49243674579545d5f27101597604c96f12
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 16:38:37 2010 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Dec 7 16:38:37 2010 -0500
Don't check at destruction for usage
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index e22ade3..9ccde8f 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -181,9 +181,6 @@ bool cmMakefile::NeedCacheCompatibility(int major, int
minor)
cmMakefile::~cmMakefile()
{
- // Check for unused variables
- this-CheckForUnusedVariables();
-
for(std::vectorcmInstallGenerator*::iterator
i = this-InstallGenerators.begin();
i != this-InstallGenerators.end(); ++i)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=668e005db5d9cece95965e23b8c589bd50a29faa
commit 668e005db5d9cece95965e23b8c589bd50a29faa
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 16:38:25 2010 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Dec 7 16:38:25 2010 -0500
Use cmake::IssueMessage for warnings
diff --git a/Source/cmCommandArgumentParserHelper.cxx
b/Source/cmCommandArgumentParserHelper.cxx
index decdaaa..a781767 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -137,9 +137,14 @@ char* cmCommandArgumentParserHelper::ExpandVariable(const
char* var)
this-Makefile-GetHomeOutputDirectory()))
{
[Cmake-commits] CMake branch, next, updated. v2.8.3-765-g36eb4f9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 36eb4f9fcdac1060fbac68c35900dc2deb2fd6eb (commit)
via 544d0c37742a068fa07b265380315a25af3ae9f3 (commit)
from 7a51a2131a40aca492ed26b5ffa0686f99dad5ed (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=36eb4f9fcdac1060fbac68c35900dc2deb2fd6eb
commit 36eb4f9fcdac1060fbac68c35900dc2deb2fd6eb
Merge: 7a51a21 544d0c3
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 17:03:00 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Dec 7 17:03:00 2010 -0500
Merge topic 'dev/strict-mode' into next
544d0c3 Fix expected output for WarnUninitialized test
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=544d0c37742a068fa07b265380315a25af3ae9f3
commit 544d0c37742a068fa07b265380315a25af3ae9f3
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Tue Dec 7 17:00:41 2010 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Dec 7 17:00:41 2010 -0500
Fix expected output for WarnUninitialized test
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index b60a610..c421e69 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1157,7 +1157,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--build-project WarnUninitialized
--build-options --warn-uninitialized)
SET_TESTS_PROPERTIES(WarnUninitialized PROPERTIES
-PASS_REGULAR_EXPRESSION CMake Warning: uninitialized variable
'USED_VARIABLE')
+PASS_REGULAR_EXPRESSION uninitialized variable 'USED_VARIABLE')
LIST(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/WarnUninitialized)
# Make sure CTest can handle a test with no newline in output.
---
Summary of changes:
Tests/CMakeLists.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.3-163-g02a8ea2
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 02a8ea2d5b0b41858be8a9e28d41e06af744fd0b (commit) from 35fd8d3abbbc0fa5de04fd46803bfa625218306d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02a8ea2d5b0b41858be8a9e28d41e06af744fd0b commit 02a8ea2d5b0b41858be8a9e28d41e06af744fd0b Author: KWSys Robot kwro...@kitware.com AuthorDate: Wed Dec 8 00:01:05 2010 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Wed Dec 8 00:10:03 2010 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 3bf5201..b27f07b 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 12) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 07) +SET(KWSYS_DATE_STAMP_DAY 08) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
