[cmake-developers] [PATCH] libarchive: fix typo in CheckFileOffsetBits.cmake
From 42997294f5b50194881f50f0aaf75704986d80e6 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer e...@sf-mail.de
Date: Wed, 5 Oct 2011 10:09:07 +0200
Needs to go upstream, too.
---
.../build/cmake/CheckFileOffsetBits.cmake |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Utilities/cmlibarchive/build/cmake/CheckFileOffsetBits.cmake
b/Utilities/cmlibarchive/build/cmake/CheckFileOffsetBits.cmake
index 5f4e053..472b80d 100644
--- a/Utilities/cmlibarchive/build/cmake/CheckFileOffsetBits.cmake
+++ b/Utilities/cmlibarchive/build/cmake/CheckFileOffsetBits.cmake
@@ -18,7 +18,7 @@
MACRO (CHECK_FILE_OFFSET_BITS)
IF(NOT DEFINED _FILE_OFFSET_BITS)
-MESSAGE(STATUS Cheking _FILE_OFFSET_BITS for large files)
+MESSAGE(STATUS Checking _FILE_OFFSET_BITS for large files)
TRY_COMPILE(__WITHOUT_FILE_OFFSET_BITS_64
${CMAKE_BINARY_DIR}
${libarchive_SOURCE_DIR}/build/cmake/CheckFileOffsetBits.c
@@ -32,10 +32,10 @@ MACRO (CHECK_FILE_OFFSET_BITS)
IF(NOT __WITHOUT_FILE_OFFSET_BITS_64 AND __WITH_FILE_OFFSET_BITS_64)
SET(_FILE_OFFSET_BITS 64 CACHE INTERNAL _FILE_OFFSET_BITS macro needed
for large files)
- MESSAGE(STATUS Cheking _FILE_OFFSET_BITS for large files - needed)
+ MESSAGE(STATUS Checking _FILE_OFFSET_BITS for large files - needed)
ELSE(NOT __WITHOUT_FILE_OFFSET_BITS_64 AND __WITH_FILE_OFFSET_BITS_64)
SET(_FILE_OFFSET_BITS CACHE INTERNAL _FILE_OFFSET_BITS macro needed
for large files)
- MESSAGE(STATUS Cheking _FILE_OFFSET_BITS for large files - not needed)
+ MESSAGE(STATUS Checking _FILE_OFFSET_BITS for large files - not needed)
ENDIF(NOT __WITHOUT_FILE_OFFSET_BITS_64 AND __WITH_FILE_OFFSET_BITS_64)
ENDIF(NOT DEFINED _FILE_OFFSET_BITS)
--
1.7.6.4
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] libarchive: fix typo in CheckFileOffsetBits.cmake
On 10/5/2011 4:24 AM, Rolf Eike Beer wrote: From 42997294f5b50194881f50f0aaf75704986d80e6 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beere...@sf-mail.de Date: Wed, 5 Oct 2011 10:09:07 +0200 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41719b75 Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
On 10/4/2011 10:22 PM, Stephen Kelly wrote:
1) Change the meaning of LINK_INTERFACE_LIBRARIES in
set_target_properties(foo LINK_INTERFACE_LIBRARIES bar)
Do you mean target_link_libraries, rather than set_target_properties?
The latter is a very general command and will not be taught special
behavior for certain properties. I'm assuming you mean
target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)
set_target_properties(foo baz LINK_INTERFACE_LIBRARIES bar)
target_link_libraries(foo baz LINK_INTERFACE_LIBRARIES bar)
mean 'foo links against baz, but doesn't expose symbols from it; foo links
against bar, and does export symbols from it'.
Currently this is actually a command mode, not a keyword. It only works
with LINK_INTERFACE_LIBRARIES as the second argument. Therefore the second
example is actually not valid right now. The only ambiguity in this behavior
change would be in the first example. However in the future the latter example
may mean link to baz and put bar in the interface but do not link to it.
I'm not excited about adding another policy that affects linking behavior.
CMP0003 was a major disruption that caused a lot of confusion, but it was
worthwhile because it enabled proper generation of link behavior in cases
that were previously not even possible. The proposed policy will affect
every single call to target_link_libraries that uses the interface mode.
Since we support repeated libraries on the link line we cannot even try
to avoid warning by detecting cases that the interface duplicates part
of the real link dependencies. Every project that currently uses the
feature will need to be changed to avoid duplication. Any project that
wants the new behavior will have to explicitly set the policy to NEW.
Someone coming back and reading the code later will have no idea from
the local context whether the call means interface-only or depend+interface
because the meaning depends on a policy setting made elsewhere.
Side Note:
When thinking about examples for this it is important to remember that
there can be multiple calls to target_link_libraries spread out all over
for the same target. This is often used for cases of optional features with
optional dependencies.
2) Introduce another variable for doing the same thing as above.
s/variable/keyword argument to target_link_libraries/
The meaning of the target property LINK_INTERFACE_LIBRARIES will not change.
It must match the meaning of IMPORTED_LINK_INTERFACE_LIBRARIES in the case of
IMPORTED targets when the interface is the only thing to specify. It also can
vary on a per-configuration basis, as in LINK_INTERFACE_LIBRARIES_CONFIG.
The only question is whether the target_link_libraries command can be modified
to change when it adds a link dependency and/or appends to the link interface.
As David notes, this might be confusing without looking up docs
...but not as confusing as having to look around the rest of the project
source tree for a policy setting to know the meaning. David was asking that
the new option be well-named to avoid confusing it with the current option.
behaviour of LINK_INTERFACE_LIBRARIES (do not actually link to the things
listed there) doesn't have a use-case
I'm reserving this use case for a future type of (virtual) target that does
not actually have a library file but can specify a link interface on other
real libraries. Besides, the meaning of the LINK_INTERFACE_LIBRARIES target
property should not change as noted above.
3) Introduce a variable for doing the opposite of what
s/variable/keyword argument to target_link_libraries/
LINK_INTERFACE_LIBRARIES does. That is, the equivalent of the above would be
set_target_properties(foo bat LINK_DEPENDENT_LIBRARIES baz)
target_link_libraries(foo bat LINK_DEPENDENT_LIBRARIES baz)
This may have confusing interaction with the LINK_INTERFACE_LIBRARIES keyword
argument. In the above example the presence of LINK_DEPENDENT_LIBRARIES for
baz would have to imply LINK_INTERFACE_LIBRARIES for bat. Then a later
target_link_libraries(foo other libs with no keyword)
call would suddenly add only link dependencies and not the interface even
though the LINK_INTERFACE_LIBRARIES keyword never appears in any call.
My preference is (1).
We need to use (2) with a well-chosen name.
Does anyone know the reason for the current behaviour?
Only a command with link_libraries in its name should add link dependencies.
Setting the LINK_INTERFACE_LIBRARIES property should not add new link rules
for the target on which it is set.
Originally the link interface could be set only by the property. Then when
people kept using ${FOO_LIBRARIES} in the property it caused confusion because
those variables often contain debug and optimized keyword arguments that
are meaningful only to the target_link_libraries command. Then we added the
option to that command to set the property by taking the keywords into account.
This was all new enough at the time
[cmake-developers] [CMake 0012495]: FIND_PACKAGE does not search lib64 for VTK
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12495 == Reported By:Scott K Logan Assigned To: == Project:CMake Issue ID: 12495 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-10-06 00:33 EDT Last Modified: 2011-10-06 00:33 EDT == Summary:FIND_PACKAGE does not search lib64 for VTK Description: When suing FindVTK.cmake, the FIND_PACKAGE command does not search /usr/lib64 for vtk-5.6, thus resulting in an error. Steps to Reproduce: 1. create a cmake file containing only find_package (VTK REQUIRED) 2. run cmake -P testfile.cmake == Issue History Date ModifiedUsername FieldChange == 2011-10-06 00:33 Scott K Logan New 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Sharing objects between executables - solved
thanks for your help Alexander Michael.
Eric
Michael Hertling a écrit :
On 10/04/2011 10:42 AM, pellegrini wrote:
Hi all,
I would need your advise about the strategy to adopt when two
executables share common object files.
Sharing object files among different targets might mean asking for
trouble - possibly quite subtle trouble - since different targets'
object files may need to be compiled with different sets of flags,
defines etc.; in particular, think of -fPIC w.r.t. object files
destined for a static library as well as for a shared one.
Here is the context. I have a project that consists in a program (e.g.
console_prog) that was historically a console program
on top of which a GUI (gui_prog) was built. The gui_prog calling
directly the console program via an input file generated by the GUI.
As the gui by itself does not mean anything without its console partner,
I built a CMakeLists.tx file that contains two add_executables:
- add_executable(console_prog console_prog.f90 module1.f90
module2.f90 module3.f90 ...)
- add_executable(gui_prog gui_prog.f90 module1.f90 module2.f90)
My problem is that gui_prog uses some routines included in the source
files of the console program (e.g. module1.f90 module2.f90).
I would like to avoid a double build of module1.f90, module2.f90
I see two possibilities:
- building a static libraries out of the common files and linking it
to both console_prog and gui_prog executables
Unless you have very good reasons to not do so, this is definitely what
you should aim at. Besides, that's the basic idea of object libraries.
- using the set_source_files_properties command on the objects files
generated by pfind build with GENERATED option set to true.
Which approach do you think suit the best to my purpose ? If this is the
second one: is there an easy way to get/specify the list of the
object files generated during the pfind build ?
You might use a RULE_LAUNCH_COMPILE target property for this purpose:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LOF C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main1 main.c)
SET_TARGET_PROPERTIES(main1 PROPERTIES RULE_LAUNCH_COMPILE sh
${CMAKE_SOURCE_DIR}/lof.sh OBJECT ${CMAKE_BINARY_DIR}/\$\$(basename
SOURCE).o)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/main.c.o PROPERTIES
GENERATED TRUE)
ADD_EXECUTABLE(main2 ${CMAKE_BINARY_DIR}/main.c.o)
SET_TARGET_PROPERTIES(main2 PROPERTIES LINKER_LANGUAGE C)
# lof.sh:
ln -s $1 $2; shift 2; exec $@
However, this approach is limited to Makefile generators and makes use
of platform-specific tools like basename, so it's usually inadvisable.
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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.6 available for download
When I install the .sh version over an existing 2.8.4 release and use CodeBlocks - Unix Makefiles QtCreator only shows the CMakeLists.txt, nothing more. Seems the CodeBlocks - Unix Makefiles generator is broken in 2.8.6. The entry Option virtualFolders=.. looks quite different between the two generated .cbp files. Peter -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- 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] static build broken ?
On 10/04/11 09:32, Alan Hourihane wrote: On 10/03/11 09:46, Alan wrote: Hi all, I'm trying to build cmake 2.8.5, but the system I'm building on doesn't have a dynamic libraries, so static only. When cmake comes to link I get this (with debug from make) It turns out that CMake is not honouring the configuration from pkgconfig, otherwise it could have found the dependencies and linked them in. What's the best way to make FindCURL.cmake and FindLibArchive.cmake use pkgconfig ? Hi folks, Any pointers in making this change as I'm finding other packages that have these problems with regard to the lack of usage of pkgconfig to manage link time dependencies. Thanks, Alan. -- 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] Cross Compilation problem
Hello all,
I have been struggling with this problem for 2 days and I cannot really find
a solution.
I have a c++ application that I want to cross compile under Fedora 15 to
use it with Windows.
The packages that my app depends on are already pre-compiled in :
/usr/i686-mingw32./
I am using CMake. It compiles okay and I generate the .exe file without
problems.
When I try to run it under Windows it complains :
The program cant start because boost_filesystem-gcc45-mt-1_46_1.dll
ins missing...
I have boost 1.47 installed in the windows machine but the libraries have a
different suffix (...vc-xx-mt...)
When I cross compile I do it statically ( I am attaching my
toolchain-mingw32 file )
My question is, why is the exe program looking for the boost dll with
exactly the same name as it has in the linux
machine where the cross compiled exe has been built from??
In my fedora mingw32 lib folder the boost libraries look like this :
libboost_filesystem-gcc45-mt-1_46_1.dll·a
Is there any way to tell cmake to disregard those suffixes while running in
Windows?
Is there any way to tell cmake to copy the boost libraries needed for my
application into a local folder that will be included
inside the the windows installer??
Also while cross compiling I had gotten this error :
In file included
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/detail/hash_float.hpp:17,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/hash.hpp:15,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash.hpp:6,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered/unordered_set.hpp:17,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered_set.hpp:16,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimatorHelper.h:33,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimator.cpp:28:
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: declaration does not declare anything
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: declaration does not declare anything
It seemed boost defines a typedf in cstdint that is already defined in
somewhere else, I would guess it is because the windows flag is
activated
even though it is compiling under linux. I fixed it checking it the
definition has been made already but this is not a proper solution.
Is it maybe that definition in my code or another cross compiled library?
Tool chain file :
SET(CMAKE_SYSTEM_NAME Windows)
# specify the cross compiler
find_file(MINGWV NAMES i586-mingw32msvc-gcc i586-mingw32msvc-g++ PATHS
/usr/bin
/usr/local/bin)
if(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i686-pc-mingw32-)
SET(Boost_COMPILER -gcc45)
else(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i586-mingw32msvc-)
SET(Boost_COMPILER -mgw)
endif(NOT MINGWV)
# set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} -mwindows
-mthreads -static-libgcc)
# set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_DEBUG} -mwindows -mthreads
-static-libgcc)
# SET(CMAKE_SHARED_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
# SET(CMAKE_MODULE_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
set(CMAKE_C_COMPILER${MINGW_PREFIX}gcc)
set(CMAKE_CXX_COMPILER ${MINGW_PREFIX}g++)
set(CMAKE_RC_COMPILER ${MINGW_PREFIX}windres)
# set(CMAKE_AR ${MINGW_PREFIX}ar)
set(CMAKE_RANLIB${MINGW_PREFIX}ranlib)
set(CMAKE_LINKER${MINGW_PREFIX}ld)
set(CMAKE_STRIP ${MINGW_PREFIX}strip)
set(CMAKE_EXECUTABLE_SUFFIX .exe)
# Boost Configuration
SET(Boost_USE_STATIC_LIBS ON)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH
/usr/i686-pc-mingw32;/usr/i586-mingw32msvc;/usr/i686-pc-mingw32/sys-root/mingw;/usr/i586-mingw32msvc/sys-root/mingw;
/home/USERNAME/i586-mingw32msvc;/home/USERNAME/i686-pc-mingw32;${CMAKE_PREFIX_PATH};
${PROJECT_SOURCE_DIR}/../libs;${PROJECT_SOURCE_DIR}/libs;${PROJECT_SOURCE_DIR}/../../libs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Thank you so much
Jose
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages
[CMake] Cross Compilation problem
Hello all,
I have been struggling with this problem for 2 days and I cannot really find
a solution.
I have a c++ application that I want to cross compile under Fedora 15 to
use it with Windows.
The packages that my app depends on are already pre-compiled in :
/usr/i686-mingw32./
I am using CMake. It compiles okay and I generate the .exe file without
problems.
When I try to run it under Windows it complains :
The program cant start because boost_filesystem-gcc45-mt-1_
46_1.dll ins missing...
I have boost 1.47 installed in the windows machine but the libraries have a
different suffix (...vc-xx-mt...)
When I cross compile I do it statically ( I am attaching my
toolchain-mingw32 file )
My question is, why is the exe program looking for the boost dll with
exactly the same name as it has in the linux
machine where the cross compiled exe has been built from??
In my fedora mingw32 lib folder the boost libraries look like this :
libboost_filesystem-gcc45-mt-1_46_1.dll·a
Is there any way to tell cmake to disregard those suffixes while running in
Windows?
Is there any way to tell cmake to copy the boost libraries needed for my
application into a local folder that will be included
inside the the windows installer??
Also while cross compiling I had gotten this error :
In file included
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/detail/hash_float.hpp:17,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/hash.hpp:15,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash.hpp:6,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered/unordered_set.hpp:17,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered_set.hpp:16,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimatorHelper.h:33,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimator.cpp:28:
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: declaration does not declare anything
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: declaration does not declare anything
It seemed boost defines a typedf in cstdint that is already defined in
somewhere else, I would guess it is because the windows flag is
activated
even though it is compiling under linux. I fixed it checking it the
definition has been made already but this is not a proper solution.
Is it maybe that definition in my code or another cross compiled library?
Tool chain file :
SET(CMAKE_SYSTEM_NAME Windows)
# specify the cross compiler
find_file(MINGWV NAMES i586-mingw32msvc-gcc i586-mingw32msvc-g++ PATHS
/usr/bin
/usr/local/bin)
if(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i686-pc-mingw32-)
SET(Boost_COMPILER -gcc45)
else(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i586-mingw32msvc-)
SET(Boost_COMPILER -mgw)
endif(NOT MINGWV)
# set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} -mwindows
-mthreads -static-libgcc)
# set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_DEBUG} -mwindows -mthreads
-static-libgcc)
# SET(CMAKE_SHARED_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
# SET(CMAKE_MODULE_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
set(CMAKE_C_COMPILER${MINGW_PREFIX}gcc)
set(CMAKE_CXX_COMPILER ${MINGW_PREFIX}g++)
set(CMAKE_RC_COMPILER ${MINGW_PREFIX}windres)
# set(CMAKE_AR ${MINGW_PREFIX}ar)
set(CMAKE_RANLIB${MINGW_PREFIX}ranlib)
set(CMAKE_LINKER${MINGW_PREFIX}ld)
set(CMAKE_STRIP ${MINGW_PREFIX}strip)
set(CMAKE_EXECUTABLE_SUFFIX .exe)
# Boost Configuration
SET(Boost_USE_STATIC_LIBS ON)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH
/usr/i686-pc-mingw32;/usr/i586-mingw32msvc;/usr/i686-pc-mingw32/sys-root/mingw;/usr/i586-mingw32msvc/sys-root/mingw;
/home/USERNAME/i586-mingw32msvc;/home/USERNAME/i686-pc-mingw32;${CMAKE_PREFIX_PATH};
${PROJECT_SOURCE_DIR}/../libs;${PROJECT_SOURCE_DIR}/libs;${PROJECT_SOURCE_DIR}/../../libs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Thank you so much
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic
Re: [CMake] add_custom_command and $...
On Oct 4, 2011, at 6:56 PM, Michael Hertling wrote: On 10/04/2011 09:20 PM, Jaime Frey wrote: Hi. I'm having some trouble with the add_custom_command() function in cmake 2.8.3. I'm using it to run a POST_BUILD command on a target. The docs say I can use $TARGET_FILE:tgt in the arguments to COMMAND to get the filename of the generated target file. But no substitution occurs and $TARGET_FILE:tgt gets plopped into the generated makefiles, where make happily replaces $ with one of the dependencies and the build fails. Bug 9465 (http://public.kitware.com/Bug/view.php?id=9465) suggests that $... in add_custom_command() hasn't been implemented, but the ticket is 2 years old now. I don't see any mention of this in the Changelog for versions after 2.8.3. Am I missing something, or are the docs in error? AFAIK, generator expressions for custom commands have been introduced in 2.8.4. A possible error - rather an omission - in the documentation is that they also work for custom targets which isn't mentioned at all. Thanks. I see the entry in the Changelog now. I guess I didn't pick the right search term when I looked at it before. Might I suggest adding a note to bug 9465 that the custom commands now support generator expressions (bug 11209), for any future searchers who run across it? ++---+ | Jaime Frey | I used to be a heavy gambler. | | jf...@cs.wisc.edu| But now I just make mental bets. | || That's how I lost my mind.| ++---+ -- 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] add_custom_command and $...
On Wed, Oct 5, 2011 at 10:09 AM, Jaime Frey jf...@cs.wisc.edu wrote: On Oct 4, 2011, at 6:56 PM, Michael Hertling wrote: On 10/04/2011 09:20 PM, Jaime Frey wrote: Hi. I'm having some trouble with the add_custom_command() function in cmake 2.8.3. I'm using it to run a POST_BUILD command on a target. The docs say I can use $TARGET_FILE:tgt in the arguments to COMMAND to get the filename of the generated target file. But no substitution occurs and $TARGET_FILE:tgt gets plopped into the generated makefiles, where make happily replaces $ with one of the dependencies and the build fails. Bug 9465 (http://public.kitware.com/Bug/view.php?id=9465) suggests that $... in add_custom_command() hasn't been implemented, but the ticket is 2 years old now. I don't see any mention of this in the Changelog for versions after 2.8.3. Am I missing something, or are the docs in error? AFAIK, generator expressions for custom commands have been introduced in 2.8.4. A possible error - rather an omission - in the documentation is that they also work for custom targets which isn't mentioned at all. Thanks. I see the entry in the Changelog now. I guess I didn't pick the right search term when I looked at it before. Might I suggest adding a note to bug 9465 that the custom commands now support generator expressions (bug 11209), for any future searchers who run across it? ++---+ | Jaime Frey | I used to be a heavy gambler. | | jf...@cs.wisc.edu | But now I just make mental bets. | | | That's how I lost my mind. | ++---+ -- 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 Like this? http://public.kitware.com/Bug/view.php?id=9465#c27525 :-) David -- 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] disable global package caching mechanims?
Hi, is there a way to disable the global caching mechanism of cmake? I mean the caching where cmake stores where a certain software package can be /was found once successfully built. I have a closed standalone build (suitable for e.g. a buildserver and automatic testing) and want to make sure that it is using *exactly* what it is building itself in that makefile run. Debugging the makefiles, i have some problems because everytime something goes wrong, the machine finds the required libraries somewhere else (as they are present at several locations and cmake apparently cached that). That behaviour completly defeats the purpose of having a monolithic build with a testable software release. Is there a switch of some kind? Regards, Thomas -- 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.6 available for download
On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel syntheti...@gmx.net wrote: When I install the .sh version over an existing 2.8.4 release and use CodeBlocks - Unix Makefiles QtCreator only shows the CMakeLists.txt, nothing more. Seems the CodeBlocks - Unix Makefiles generator is broken in 2.8.6. The entry Option virtualFolders=.. looks quite different between the two generated .cbp files. I just tried this with CMake compiled from master, on a fresh ParaView build tree (hadn't made one in a while) using, cmake -G CodeBlocks - Unix Makefiles ~/ssd/src/ParaView I was able to open the resulting build directory in Qt Creator 2.3.1 and see all of the source files etc. I can dig a little deeper if you let me know what version of Qt Creator you are using, a project you see the issue with etc. I could also give the installer a try if the problem persists (I normally just build from source and current CMake master is 2.8.6). Marcus -- 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] disable global package caching mechanims?
On Wed 05 Oct 2011 04:22:27 PM CEST, Thomas Wolf wrote: Hi, is there a way to disable the global caching mechanism of cmake? I mean the caching where cmake stores where a certain software package can be /was found once successfully built. I have a closed standalone build (suitable for e.g. a buildserver and automatic testing) and want to make sure that it is using *exactly* what it is building itself in that makefile run. Debugging the makefiles, i have some problems because everytime something goes wrong, the machine finds the required libraries somewhere else (as they are present at several locations and cmake apparently cached that). That behaviour completly defeats the purpose of having a monolithic build with a testable software release. Is there a switch of some kind? Regards, Thomas CMake only caches this kind of information in the CMakeCache.txt file in the build tree. You might want to take a look at the -C option of CMake. Alternatively, you can also try to play around with the CMAKE_SYSTEM_PREFIX and CMAKE_SYSTEM_*_PATH variables as documented the man-page. 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] Wiki: version compatibility matrix
On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, On Saturday 04 December 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). now cmake 2.8.5 has been released, could you please if you find the time update that page ? It's really useful :-) Alex ___ 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 Same request over again, but now for the hot-off-the-presses CMake 2.8.6 official release. Can you / do you have the time to update the wiki for 2.8.6? Thanks! David -- 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
On Wed, Oct 5, 2011 at 10:51 AM, David Cole david.c...@kitware.com wrote: On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, On Saturday 04 December 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). now cmake 2.8.5 has been released, could you please if you find the time update that page ? It's really useful :-) Alex ___ 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 Same request over again, but now for the hot-off-the-presses CMake 2.8.6 official release. Can you / do you have the time to update the wiki for 2.8.6? Thanks! David And similarly, Alex, for the help text wiki page at http://www.cmake.org/Wiki/CMake_Released_Versions 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] CMake 2.8.6 available for download
On Wednesday, October 05, 2011 08:29:00 am Marcus D. Hanwell wrote: On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel syntheti...@gmx.net wrote: When I install the .sh version over an existing 2.8.4 release and use CodeBlocks - Unix Makefiles QtCreator only shows the CMakeLists.txt, nothing more. Seems the CodeBlocks - Unix Makefiles generator is broken in 2.8.6. The entry Option virtualFolders=.. looks quite different between the two generated .cbp files. I just tried this with CMake compiled from master, on a fresh ParaView build tree (hadn't made one in a while) using, cmake -G CodeBlocks - Unix Makefiles ~/ssd/src/ParaView I was able to open the resulting build directory in Qt Creator 2.3.1 and see all of the source files etc. I can dig a little deeper if you let me know what version of Qt Creator you are using, a project you see the issue with etc. I could also give the installer a try if the problem persists (I normally just build from source and current CMake master is 2.8.6). So I see that one of my projects has this problem. I've narrowed it down to this commit: http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 If I remove the code that commit adds, from the current HEAD, then my problem goes away. When checking the XML, it complained about a few lines that looked like this: Add option=-DMY_DIR=/path/to/file / So it appears that code doesn't handle preprocessor defines with quoting. Peter, is that your problem also? Can you edit your .cbp to remove lines like that? Or copy it to a file with a .xml extension then open it in a program that can check the xml (e.g. firefox). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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] CMake 2.8.6 available for download
On 10/5/2011 11:17 AM, Clinton Stimpson wrote: Peter, is that your problem also? Can you edit your .cbp to remove lines like that? Or copy it to a file with a .xml extension then open it in a program that can check the xml (e.g. firefox). So, what can we do to get people to try the RC's? This issue was in RC 1 which went out on 8/26. Patch by Campbell Barton: puts definitions into C::B project file This is really frustrating for the CMake team. We really need the help of the users to make sure we have most of the big issues worked out with the releases. This issue has been around for over a month in the RC releases and no one notices. Then less than 24 hours after the official release we get the bug report... :( -Bill -- 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] disable global package caching mechanims?
CMake only caches this kind of information in the CMakeCache.txt file
in the build tree. You might want to take a look at the -C option of
CMake. Alternatively, you can also try to play around with the
CMAKE_SYSTEM_PREFIX and CMAKE_SYSTEM_*_PATH variables as documented the
man-page.
Michael
Hi,
So, what about step 5 in the findpackage docs..
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
---
5. Search project build trees recently configured in a CMake GUI. This
can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the
case when a user is building multiple dependent projects one after another.
---
Can i disable this alltogether? On some of my subprojects that do a
find_package i have no incluence. And given the fact that some of the
provided find_package scripts are suboptimal, i really don't want to
find any stuff lying around.
Again: Can this be disabled?
(like passing DNO_CMAKE_BUILDS_PATH to cmake?)
Reason: if I configured something wrong, like ${package}_DIR or the
HINT, I want the build to fail, and not to silently continue with some
other binaries.
There are several builds running, doing similar stuff. It can happen
that one build creates a library, that by accident may be found in
another build task.
Regards,
Thomas
--
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
Hi, I'll probably get to it in the next 1-3 weeks... Cheers, Johannes On 10/05/2011 at 16:51, David Cole david.c...@kitware.com wrote: On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, On Saturday 04 December 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). now cmake 2.8.5 has been released, could you please if you find the time update that page ? It's really useful :-) Alex ___ 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 Same request over again, but now for the hot-off-the-presses CMake 2.8.6 official release. Can you / do you have the time to update the wiki for 2.8.6? Thanks! David -- 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.6 available for download
On Wednesday 05 October 2011, Clinton Stimpson wrote: On Wednesday, October 05, 2011 08:29:00 am Marcus D. Hanwell wrote: On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel syntheti...@gmx.net wrote: When I install the .sh version over an existing 2.8.4 release and use CodeBlocks - Unix Makefiles QtCreator only shows the CMakeLists.txt, nothing more. Seems the CodeBlocks - Unix Makefiles generator is broken in 2.8.6. The entry Option virtualFolders=.. looks quite different between the two generated .cbp files. I just tried this with CMake compiled from master, on a fresh ParaView build tree (hadn't made one in a while) using, cmake -G CodeBlocks - Unix Makefiles ~/ssd/src/ParaView I was able to open the resulting build directory in Qt Creator 2.3.1 and see all of the source files etc. I can dig a little deeper if you let me know what version of Qt Creator you are using, a project you see the issue with etc. I could also give the installer a try if the problem persists (I normally just build from source and current CMake master is 2.8.6). So I see that one of my projects has this problem. I've narrowed it down to this commit: http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 If I remove the code that commit adds, from the current HEAD, then my problem goes away. When checking the XML, it complained about a few lines that looked like this: Add option=-DMY_DIR=/path/to/file / So it appears that code doesn't handle preprocessor defines with quoting. Can you please create a ticket in the bugtracker and attach such a bad project file ? Thanks Alex -- 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.6 available for download
On Wednesday, October 05, 2011 09:53:53 am Alexander Neundorf wrote: On Wednesday 05 October 2011, Clinton Stimpson wrote: On Wednesday, October 05, 2011 08:29:00 am Marcus D. Hanwell wrote: On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel syntheti...@gmx.net wrote: When I install the .sh version over an existing 2.8.4 release and use CodeBlocks - Unix Makefiles QtCreator only shows the CMakeLists.txt, nothing more. Seems the CodeBlocks - Unix Makefiles generator is broken in 2.8.6. The entry Option virtualFolders=.. looks quite different between the two generated .cbp files. I just tried this with CMake compiled from master, on a fresh ParaView build tree (hadn't made one in a while) using, cmake -G CodeBlocks - Unix Makefiles ~/ssd/src/ParaView I was able to open the resulting build directory in Qt Creator 2.3.1 and see all of the source files etc. I can dig a little deeper if you let me know what version of Qt Creator you are using, a project you see the issue with etc. I could also give the installer a try if the problem persists (I normally just build from source and current CMake master is 2.8.6). So I see that one of my projects has this problem. I've narrowed it down to this commit: http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 If I remove the code that commit adds, from the current HEAD, then my problem goes away. When checking the XML, it complained about a few lines that looked like this: Add option=-DMY_DIR=/path/to/file / So it appears that code doesn't handle preprocessor defines with quoting. Can you please create a ticket in the bugtracker and attach such a bad project file ? Thanks Alex Oh, do you still want this in the bug tracker? It was a simple fix. http://cmake.org/gitweb?p=cmake.git;a=commit;h=240d39 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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] CMake 2.8.6 available for download
Hmm. Part of the problem might be the generators most of the folks who follow CMake closely tend to use - I'm a command line + vim linux weenie myself, so I'm only going to be testing a subset of the generators. I imagine others are Windows only, etc. One idea that comes to mind might be to put up a table when the RC process starts - one column per generator, and the rows listing various open source projects using CMake that are known to work with various generators. If it's expected in advance that a particular project won't build, just black out that cell so people know not to try, but otherwise people could fill in the matrix with RC1 or RC4 as they test particular generators and projects and they succeed. That would give folks a place to check what has and has not been looked at - Urk! nobody's tried the Eclipse generator yet for this RC or It's been 3 RC bumps since anybody checked Visual Studio 8. And if particular generators go untested for a while, the call could be put out on the email lists - somebody please try generator X with project Y before release Would that help? Cheers, CY On Wed, Oct 5, 2011 at 11:36 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On 10/5/2011 11:17 AM, Clinton Stimpson wrote: Peter, is that your problem also? Can you edit your .cbp to remove lines like that? Or copy it to a file with a .xml extension then open it in a program that can check the xml (e.g. firefox). So, what can we do to get people to try the RC's? This issue was in RC 1 which went out on 8/26. Patch by Campbell Barton: puts definitions into C::B project file This is really frustrating for the CMake team. We really need the help of the users to make sure we have most of the big issues worked out with the releases. This issue has been around for over a month in the RC releases and no one notices. Then less than 24 hours after the official release we get the bug report... :( -Bill -- 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] add_custom_command and $...
On Oct 5, 2011, at 9:18 AM, David Cole wrote: On Wed, Oct 5, 2011 at 10:09 AM, Jaime Frey jf...@cs.wisc.edu wrote: Thanks. I see the entry in the Changelog now. I guess I didn't pick the right search term when I looked at it before. Might I suggest adding a note to bug 9465 that the custom commands now support generator expressions (bug 11209), for any future searchers who run across it? Like this? http://public.kitware.com/Bug/view.php?id=9465#c27525 Great. Once we upgrade past 2.8.3, I'll be looking to use those generator expressions. -- Jaime -- 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.6 available for download
So I see that one of my projects has this problem. I've narrowed it down to this commit: http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 Great! This was fast. If I remove the code that commit adds, from the current HEAD, then my problem goes away. When checking the XML, it complained about a few lines that looked like this: Add option=-DMY_DIR=/path/to/file / So it appears that code doesn't handle preprocessor defines with quoting. Peter, is that your problem also? Yes, same here: Add option=-DOP_PATH= / Can you edit your .cbp to remove lines like that? Or copy it to a file with a .xml extension then open it in a program that can check the xml (e.g. firefox). Replacing above line with Add option=-DOP_PATH / fixes the problem. Peter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- 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] Removing C-style comments from fortran include file?
On 10/03/2011 07:39 PM, John R. Cary wrote:
I am using the cmakedefine mechanism for a fortran include file.
If the variable is not defined, rather than
/* #undef HAVE_PLASMASTATE */
I need
! #undef HAVE_PLASMASTATE
Are there existing solutions?
You might postprocess the already configured file:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FORTRANIZE NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FUNCTION(FORTRANIZE file)
UNSET(result)
FILE(STRINGS ${file} lines)
FOREACH(i IN LISTS lines)
STRING(REGEX REPLACE ^/\\* (#undef .*) \\*/$ ! \\1 i ${i})
SET(result ${result}${i}\n)
ENDFOREACH()
FILE(WRITE ${file} ${result})
ENDFUNCTION()
FILE(WRITE ${CMAKE_BINARY_DIR}/file.f.in
#cmakedefine VAR1\n#cmakedefine VAR2
/* #undef DONTTOUCH */ \n)
SET(VAR1 1)
SET(VAR2 0)
CONFIGURE_FILE(${CMAKE_BINARY_DIR}/file.f.in ${CMAKE_BINARY_DIR}/file.f)
FORTRANIZE(${CMAKE_BINARY_DIR}/file.f)
However, this is possibly not totally bullet-proof when a line
/* #undef ... */
appears intentionally and shouldn't be touched. Since CONFIGURE_FILE()
throws away the rest of a #cmakedefine line if the variable evaluates
to 0, i.e. #cmakedefine VAR /* TAG */ becomes /* #undef VAR */,
the lines to be postprocessed can't be specially tagged. Instead,
the intentional lines could be silently tagged with a trailing
whitespace like in the above-noted example.
'hope that helps.
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
Re: [CMake] CMake 2.8.6 available for download
Am Mittwoch, 5. Oktober 2011, 18:38:35 schrieb Peter Kuemmel: So I see that one of my projects has this problem. I've narrowed it down to this commit: http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 Great! This was fast. If I remove the code that commit adds, from the current HEAD, then my problem goes away. When checking the XML, it complained about a few lines that looked like this: Add option=-DMY_DIR=/path/to/file / So it appears that code doesn't handle preprocessor defines with quoting. Peter, is that your problem also? Yes, same here: Add option=-DOP_PATH= / Can you edit your .cbp to remove lines like that? Or copy it to a file with a .xml extension then open it in a program that can check the xml (e.g. firefox). Replacing above line with Add option=-DOP_PATH / fixes the problem. The thing the patch does would be Add option=-DOP_PATH=quot;quot; / Eike signature.asc Description: This is a digitally signed message part. -- 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
On Wednesday 05 October 2011, David Cole wrote: On Wed, Oct 5, 2011 at 10:51 AM, David Cole david.c...@kitware.com wrote: On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, On Saturday 04 December 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). now cmake 2.8.5 has been released, could you please if you find the time update that page ? It's really useful :-) Alex ___ 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 Same request over again, but now for the hot-off-the-presses CMake 2.8.6 official release. Can you / do you have the time to update the wiki for 2.8.6? Thanks! David And similarly, Alex, for the help text wiki page at http://www.cmake.org/Wiki/CMake_Released_Versions Done (it was already on my TODO for today). Alex -- 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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j10.5-0.8 1.6-1.9 0.11-0.14 -j20.6-0.8 1.3-1.4 0.11-0.13 -j40.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case Peter -- 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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Wednesday 05 October 2011, Peter Kümmel wrote: And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j10.5-0.8 1.6-1.9 0.11-0.14 -j20.6-0.8 1.3-1.4 0.11-0.13 -j40.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case and: - qmake makefiles don't have complete dependencies Seriously, if cmakes Makefiles are slower, I am very sure this is because they have complete dependencies. Alex -- 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] Curious build output
What is this extra chatty output from? I never remember seeing it in VS
2008, but I see it in VS 2010.
-- Build started: Project: copy_scripts, Configuration: Release x64
--
1Build started 10/5/2011 12:38:07 PM.
1InitializeBuildStatus:
1 Creating x64\Release\copy_scripts\copy_scripts.unsuccessfulbuild
because AlwaysCreate was specified.
1FinalizeBuildStatus:
1 Deleting file x64\Release\copy_scripts\copy_scripts.unsuccessfulbuild.
1 Touching x64\Release\copy_scripts\copy_scripts.lastbuildstate.
1
1Build succeeded.
3-- Build started: Project: ALL_BUILD, Configuration: Release x64
--
3Build started 10/5/2011 12:38:08 PM.
3InitializeBuildStatus:
3 Creating x64\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild because
AlwaysCreate was specified.
3CustomBuild:
3 Build all projects
3FinalizeBuildStatus:
3 Deleting file x64\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild.
3 Touching x64\Release\ALL_BUILD\ALL_BUILD.lastbuildstate.
3
3Build succeeded.
I'm using VS 2010 and CMake 2.8.6 (2.8.5 also did this).
When I click build solution it always seems to run this, as if VS thinks
that the dependencies aren't met and decides to build it.
Hmm... I wonder if this is related to the bug where we removed the
%(Outputs) from the Outputs field.
C:/code/rtsdk/rtmain/build-64-vs10-c40/tests/Regression/scripts/CMakeFiles/copy_scripts.rule;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\correctness.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\performance.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\run_tests.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\test_cases.rb;%(AdditionalInputs)
I removed the $(AdditionalInputs), and that didn't seem to make a
difference.
One thing that is curious is that I have this for the Outputs field, but
that doesn't exist anywhere:
C:\code\rtsdk\rtmain\build-64-vs10-c40\tests\Regression\scripts\CMakeFiles\copy_scripts
How is it that we have a build rule that says it generates a particular
output, but the output isn't generated by the rule.
This is what I used to create this target:
foreach( script ${scripts} )
set( src ${CMAKE_CURRENT_SOURCE_DIR}/${script} )
set( dest ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${script} )
list( APPEND dest_files ${dest} )
add_custom_command(
OUTPUT ${dest}
COMMAND ${CMAKE_COMMAND} -E copy ${src} ${dest}
MAIN_DEPENDENCY ${src}
COMMENT Copying ${src} to ${dest}
VERBATIM
)
endforeach()
add_custom_target( copy_scripts
ALL
DEPENDS ${dest_files}
)
Note that I have the same problem with the ALL_BUILD target.
James
--
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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 05.10.2011 20:38, Alexander Neundorf wrote: On Wednesday 05 October 2011, Peter Kümmel wrote: And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j10.5-0.8 1.6-1.9 0.11-0.14 -j20.6-0.8 1.3-1.4 0.11-0.13 -j40.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case and: - qmake makefiles don't have complete dependencies OK, qmake Makefiles are not complete. Seriously, if cmakes Makefiles are slower, I am very sure this is because they have complete dependencies. Is there a way to run cmake's Makefiles in the (faster) qmake-mode ? Peter Alex -- 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 change the Start in directory for Windows Start menu shortcuts
On Tue, Oct 4, 2011 at 6:37 PM, Ben Medina ben.med...@gmail.com wrote: Hello all, We're using NSIS via CPack for our Windows installer. One thing we'd like to change is the Start in directory for Windows Start menu shortcuts. Currently, it appears to default to the installation directory, but that's not very useful: users aren't going to be saving files underneath C:\Program Files\MyApp. Is it possible to change the start in directory? Thanks, 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 You could customize the NSIS template to write your own NSIS CreateShortCut calls. There's more info on customizing the NSIS template in the mailing list archive. If you have trouble finding it, let me know, and I'll dig up a pointer. The docs for CreateShortCut are here: http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.3.4 The docs say $OUTDIR is used for the working directory. You can change it by using SetOutPath before creating the Shortcut. I'm assuming that's what the working directory will be for the shortcut. (If I'm reading the docs correctly...) Of course, if I were going to do such a thing, I'd also save/restore the value of $OUTDIR across the CreateShortCut operations because I have no idea what else in NSIS depends on that value in a hidden way like this... Or. you could simply write your app to ignore the start in directory, and present things like file open and save dialogs pointing to the user's home directory to start with, like most document based apps do. HTH, David -- 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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 05.10.2011 21:45, Bill Hoffman wrote: I just tried this on a machine here. svn co svn://anonsvn.kde.org/home/kde/branches/work/kst/portto4/kst CMake build: make -j8 real3m19.131s user16m31.866s sys 3m25.289s Qmake build: real2m55.761s user15m15.585s sys 1m58.203s mp/../viewitem.h:92: warning: unused parameter 'f' tmp/../viewitem.h:92: warning: unused parameter 'c' rm -f libkst2app.so.1.0.0 libkst2app.so libkst2app.so.1 libkst2app.so.1.0 linking ../../build/lib/libkst2app.so.1.0.0 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[1]: *** [../../build/lib/libkst2app.so.1.0.0] Error 1 make[1]: Leaving directory `/home/hoffman/kst-qmake/src/libkstapp' make: *** [sub-src-libkstapp-make_default-ordered] Error 2 So, for me the qmake build had a total failure after almost taking as long to build. So, CMake wins because the qmake build never actually finishes... :) BTW, This is an 8 core machine. What are you building on to get .5 minute builds? Something is odd here... 4 real cores and hyper threading with Ubuntu 11.10 and GCC 4.6: 1m15.467s But the build times aren't that interesting. The .5 you mentioned where .5 seconds which it takes to run make on an already build project: $ time make [ 19%] Built target kst2core [ 33%] Built target kst2math [ 43%] Built target kst2widgets [ 90%] Built target kst2app [ 90%] Built target kst2_filters_differentiation [ 92%] Built target kst2_datasource_ascii [ 92%] Built target kst2_datasource_qimagesource [ 93%] Built target kst2_datasource_sampledatasource [ 93%] Built target kst2_dataobject_bin [ 94%] Built target kst2_dataobject_linefit [ 95%] Built target kst2_dataobject_chop [ 96%] Built target kst2_dataobject_phase [ 96%] Built target kst2_dataobject_lockin [ 97%] Built target kst2_dataobject_statistics [ 97%] Built target kst2_dataobject_shift [ 97%] Built target kst2_dataobject_syncbin [ 98%] Built target kst2_dataobject_differentiation [ 98%] Built target kst2_dataobject_crossspectrum [ 98%] Built target kst2_dataobject_effectivebandwidth [ 99%] Built target kst2_dataobject_genericfilter [ 99%] Built target kst2_filters_cumulativesum [100%] Built target kst2_filters_despike [100%] Built target kst2 real0m1.772s user0m1.116s sys 0m0.372s $ How is this called 'clean run'? I hope this measures best the pure make-system speed. Peter -Bill -- 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
[CMake] Include source files on a per-configuration basis
In my particular CMake project, I have three CPP files: a.cpp b.cpp c.cpp I want 'a.cpp' to be compiled in all configurations (release debug).br I only want 'b.cpp' to be compiled in DEBUG configuration.br I only want 'c.cpp' to be compiled in RELEASE configuration. How can I do this? I need something similar to the `debug` and `optimized` keywords that are accepted by the `target_link_libraries()` CMake operation. - Robert Dailey -- 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] Include source files on a per-configuration basis
On 10/05/2011 10:47 PM, Robert Dailey wrote:
In my particular CMake project, I have three CPP files:
a.cpp
b.cpp
c.cpp
I want 'a.cpp' to be compiled in all configurations (release debug).br
I only want 'b.cpp' to be compiled in DEBUG configuration.br
I only want 'c.cpp' to be compiled in RELEASE configuration.
How can I do this? I need something similar to the `debug` and `optimized`
keywords that are accepted by the `target_link_libraries()` CMake operation.
If it's okay that b.cpp and c.cpp are compiled in all configurations but
incorporated in the final binaries only in the DEBUG or in the RELEASE
configuration, respectively, you might do the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDEMPTY C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Add library for DEBUG:
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
ADD_LIBRARY(b STATIC b.c)
# Add library for RELEASE:
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
ADD_LIBRARY(c STATIC c.c)
# Add empty static library:
FILE(WRITE ${CMAKE_BINARY_DIR}/empty.c )
ADD_LIBRARY(empty STATIC empty.c)
# Reimport empty static library:
EXPORT(TARGETS empty NAMESPACE imported FILE importedempty.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importedempty.cmake)
# Impose IMPORTED_LINK_INTERFACE_LIBRARIES_{DEBUG,RELEASE} properties:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
STRING(TOUPPER ${i} i)
IF(i STREQUAL DEBUG)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} b)
ELSEIF(i STREQUAL RELEASE)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} c)
ENDIF()
ENDFOREACH()
# Specify required dependencies:
ADD_DEPENDENCIES(importedempty empty b c)
# Add final binary:
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
ADD_EXECUTABLE(a a.c)
TARGET_LINK_LIBRARIES(a importedempty)
Adventurous, but somewhat clean; see [1] for an explanation, and be
especially careful with a file named libc.a on *nix systems. ;-)
If you really need to avoid the compilation of b.cpp or c.cpp in
certain configurations, you might try the following approach:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RECONF C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
STRING(TOUPPER ${CONF} CONF)
IF(CONF STREQUAL DEBUG)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c b.c)
ELSEIF(CONF STREQUAL RELEASE)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c c.c)
ELSE()
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c)
ENDIF()
ADD_CUSTOM_TARGET(a ALL
COMMAND ${CMAKE_COMMAND}
-DCONF=$CONFIGURATION
${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target a0)
Effectively, when target a is built, the project reconfigures itself
with the current configuration passed in via CONF and with a helper
target a0 which is made up from the configuration-specific sources;
finally, this target a0 is built with the current configuration.
This can be seen working on *nix with Makefiles, but there might
be issues with other generators and IDEs.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34680.html
--
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] Curious build output
It's because VS2010 uses msbuild to build C++ projects. You can modify
verbosity level in settings menu: Tools Options Projects and Solutions
Build and Run MSBuild project build output verbosity
On Wed, Oct 5, 2011 at 10:49 PM, James Bigler jamesbig...@gmail.com wrote:
What is this extra chatty output from? I never remember seeing it in VS
2008, but I see it in VS 2010.
-- Build started: Project: copy_scripts, Configuration: Release x64
--
1Build started 10/5/2011 12:38:07 PM.
1InitializeBuildStatus:
1 Creating x64\Release\copy_scripts\copy_scripts.unsuccessfulbuild
because AlwaysCreate was specified.
1FinalizeBuildStatus:
1 Deleting file
x64\Release\copy_scripts\copy_scripts.unsuccessfulbuild.
1 Touching x64\Release\copy_scripts\copy_scripts.lastbuildstate.
1
1Build succeeded.
3-- Build started: Project: ALL_BUILD, Configuration: Release x64
--
3Build started 10/5/2011 12:38:08 PM.
3InitializeBuildStatus:
3 Creating x64\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild because
AlwaysCreate was specified.
3CustomBuild:
3 Build all projects
3FinalizeBuildStatus:
3 Deleting file x64\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild.
3 Touching x64\Release\ALL_BUILD\ALL_BUILD.lastbuildstate.
3
3Build succeeded.
I'm using VS 2010 and CMake 2.8.6 (2.8.5 also did this).
When I click build solution it always seems to run this, as if VS thinks
that the dependencies aren't met and decides to build it.
Hmm... I wonder if this is related to the bug where we removed the
%(Outputs) from the Outputs field.
C:/code/rtsdk/rtmain/build-64-vs10-c40/tests/Regression/scripts/CMakeFiles/copy_scripts.rule;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\correctness.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\performance.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\run_tests.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\test_cases.rb;%(AdditionalInputs)
I removed the $(AdditionalInputs), and that didn't seem to make a
difference.
One thing that is curious is that I have this for the Outputs field, but
that doesn't exist anywhere:
C:\code\rtsdk\rtmain\build-64-vs10-c40\tests\Regression\scripts\CMakeFiles\copy_scripts
How is it that we have a build rule that says it generates a particular
output, but the output isn't generated by the rule.
This is what I used to create this target:
foreach( script ${scripts} )
set( src ${CMAKE_CURRENT_SOURCE_DIR}/${script} )
set( dest ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${script} )
list( APPEND dest_files ${dest} )
add_custom_command(
OUTPUT ${dest}
COMMAND ${CMAKE_COMMAND} -E copy ${src} ${dest}
MAIN_DEPENDENCY ${src}
COMMENT Copying ${src} to ${dest}
VERBATIM
)
endforeach()
add_custom_target( copy_scripts
ALL
DEPENDS ${dest_files}
)
Note that I have the same problem with the ALL_BUILD target.
James
--
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] Fwd: Help regarding dependency..I guess..
On 10/02/2011 06:41 PM, gaurav chetal wrote:
Frndzz..
I am attaching an archive file herewith!!!..In it the .h file of project A
is not able to link to the .h file of project B when linking the library
of A as well as B with the executable..This is just an outline of what i
want to execute in my project.
I am a beginner to CMake so very much confused sir..Plzz help!!!
A/CMakeLists.txt: You don't have a target named A, so saying
target_link_libraries(A B) makes no sense; probably, you meant
target_link_libraries(utilities B) as the utilities library is
built from ProA.C that includes prob.h - probably ProB.h - via
ProA.h. File names are usually case-sensitive. Furthermore, as
main.C includes ProA.h, you probably need target_link_libraries(
t utilities). Always specify merely immediate dependencies with
target_link_libraries() and let CMake find out the mediate ones.
Moreover, in order to make target_link_libraries(utilities B) do what
you probably want, the targets B and utilities must be defined within
the same project, so you need a top-level CMakeLists.txt file next to
the directories A and B, reading roughly
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(AB CXX)
ADD_SUBDIRECTORY(A)
ADD_SUBDIRECTORY(B)
and you build the overall project from that CMakeLists.txt. In this
way, you could also use CMAKE_SOURCE_DIR in include_directories():
include_directories(${CMAKE_SOURCE_DIR}/A ${CMAKE_SOURCE_DIR}/B)
A/main.C: Where is the function toLowerCase() defined? AFAIK, it's not
in the C++ standard library, so it is not surprising that you get an
undefined reference during the link stage, and what's the object x?
Finally, never say using namespace std; in a *header* file.
'hope that helps.
Regards,
Michael
On Fri, Sep 30, 2011 at 7:25 PM, Eric Noulard eric.noul...@gmail.comwrote:
2011/9/30 gaurav chetal chetal.gau...@gmail.com:
Respected sir!!!..
Actually i have made the static libraries..But the problems which m
gettin
is that the program of the CMakeLists.txt is first of all nt able to pick
up
the libraries (with TARGET_LINK_LIBRARY) and second thing those libraries
are of the header files (.h)..The header files also it is nt picking up
as a
result of that!!!
May be you can send us an archive of your sample project
which exhibit the issue, I suspect that the problem may not be with CMake.
Do you manage to compile your project by hand using hand-wriiten
command lines?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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] disable global package caching mechanims?
On Wed 05 Oct 2011 05:48:12 PM CEST, Thomas Wolf wrote:
CMake only caches this kind of information in the CMakeCache.txt file
in the build tree. You might want to take a look at the -C option of
CMake. Alternatively, you can also try to play around with the
CMAKE_SYSTEM_PREFIX and CMAKE_SYSTEM_*_PATH variables as documented the
man-page.
Michael
Hi,
So, what about step 5 in the findpackage docs..
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
---
5. Search project build trees recently configured in a CMake GUI. This
can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for
the case when a user is building multiple dependent projects one after
another.
---
Can i disable this alltogether? On some of my subprojects that do a
find_package i have no incluence. And given the fact that some of the
provided find_package scripts are suboptimal, i really don't want to
find any stuff lying around.
Again: Can this be disabled?
(like passing DNO_CMAKE_BUILDS_PATH to cmake?)
Reason: if I configured something wrong, like ${package}_DIR or the
HINT, I want the build to fail, and not to silently continue with some
other binaries.
There are several builds running, doing similar stuff. It can happen
that one build creates a library, that by accident may be found in
another build task.
Regards,
Thomas
Ahh, now I understand. Sorry for that. No, I don't think you can do
that (might be worthwhile to file a bug report on this). There are two
ways:
- After each build, remove the caches. On *NIX machines I think this
would be ~/.cmake/packages and ~/.config/Kitware/CMakeSetup.conf. On
Windows that stuff is stored in the registry:
HKEY_CURRENT_USER\Software\Kitware\CMake\Packages,
HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages and
HKEY_CURRENT_USER\Software\Kitware\CMakeSetup\Settings\StartPath;WhereBuild.
- After each build (re)move the build tree.
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] Include source files on a per-configuration basis
On Thu 06 Oct 2011 05:17:00 AM CEST, Michael Hertling wrote:
On 10/05/2011 10:47 PM, Robert Dailey wrote:
In my particular CMake project, I have three CPP files:
a.cpp
b.cpp
c.cpp
I want 'a.cpp' to be compiled in all configurations (release debug).br
I only want 'b.cpp' to be compiled in DEBUG configuration.br
I only want 'c.cpp' to be compiled in RELEASE configuration.
How can I do this? I need something similar to the `debug` and `optimized`
keywords that are accepted by the `target_link_libraries()` CMake operation.
If it's okay that b.cpp and c.cpp are compiled in all configurations but
incorporated in the final binaries only in the DEBUG or in the RELEASE
configuration, respectively, you might do the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDEMPTY C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Add library for DEBUG:
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
ADD_LIBRARY(b STATIC b.c)
# Add library for RELEASE:
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
ADD_LIBRARY(c STATIC c.c)
# Add empty static library:
FILE(WRITE ${CMAKE_BINARY_DIR}/empty.c )
ADD_LIBRARY(empty STATIC empty.c)
# Reimport empty static library:
EXPORT(TARGETS empty NAMESPACE imported FILE importedempty.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importedempty.cmake)
# Impose IMPORTED_LINK_INTERFACE_LIBRARIES_{DEBUG,RELEASE} properties:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
STRING(TOUPPER ${i} i)
IF(i STREQUAL DEBUG)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} b)
ELSEIF(i STREQUAL RELEASE)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} c)
ENDIF()
ENDFOREACH()
# Specify required dependencies:
ADD_DEPENDENCIES(importedempty empty b c)
# Add final binary:
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
ADD_EXECUTABLE(a a.c)
TARGET_LINK_LIBRARIES(a importedempty)
Adventurous, but somewhat clean; see [1] for an explanation, and be
especially careful with a file named libc.a on *nix systems. ;-)
If you really need to avoid the compilation of b.cpp or c.cpp in
certain configurations, you might try the following approach:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RECONF C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
STRING(TOUPPER ${CONF} CONF)
IF(CONF STREQUAL DEBUG)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c b.c)
ELSEIF(CONF STREQUAL RELEASE)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c c.c)
ELSE()
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c)
ENDIF()
ADD_CUSTOM_TARGET(a ALL
COMMAND ${CMAKE_COMMAND}
-DCONF=$CONFIGURATION
${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target a0)
Effectively, when target a is built, the project reconfigures itself
with the current configuration passed in via CONF and with a helper
target a0 which is made up from the configuration-specific sources;
finally, this target a0 is built with the current configuration.
This can be seen working on *nix with Makefiles, but there might
be issues with other generators and IDEs.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34680.html
I think it would be much easier to have a wrapper file, say b_or_c.cpp
which #include's b.cpp or c.cpp at compile time depending on the current
configuration. E.g. like this:
///
#if defined USE_B_CPP
# include b.cpp
#elseif defined USE_C_CPP
# include c.cpp
#else // what should happen otherwise?
# error Either USE_B_CPP or USE_C_CPP must be defined!
#endif
///
And then in your CMakeLists.txt you do:
###
set_source_files_properties(b_or_c.cpp PROPERTIES
COMPILE_DEFINITIONS_DEBUG USE_B_CPP
COMPILE_DEFINITIONS_RELEASE USE_C_CPP
# what should happen in a default build?
# Or RELWITHDEBINFO and MINSIZEREL?
)
###
HTH
Michael W.
--
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-commits] CMake branch, next, updated. v2.8.6-1501-gc56fdde
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 c56fdde415b2ee90d19634fa4d3393a34f47bbf1 (commit) via ab97790c33c74127b4698e1c858ab6a3ce966b40 (commit) from 8ed8a361a33a351047850834ef1d665e59c008d5 (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=c56fdde415b2ee90d19634fa4d3393a34f47bbf1 commit c56fdde415b2ee90d19634fa4d3393a34f47bbf1 Merge: 8ed8a36 ab97790 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Oct 5 09:28:12 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Oct 5 09:28:12 2011 -0400 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.6-1505-g021cece
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 021cece31b7fc461940fe605252a4958ded66ac5 (commit)
via 67ae66aa918ba62ebb2010f01c98574ddc1cf2d5 (commit)
from 1ee556b5d5e66faff366b2aad8fdff142204dc8b (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=021cece31b7fc461940fe605252a4958ded66ac5
commit 021cece31b7fc461940fe605252a4958ded66ac5
Merge: 1ee556b 67ae66a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Oct 5 09:52:38 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Oct 5 09:52:38 2011 -0400
Merge topic 'cmake-link-interface-libraries' into next
67ae66a Export symbols from the test libraries.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67ae66aa918ba62ebb2010f01c98574ddc1cf2d5
commit 67ae66aa918ba62ebb2010f01c98574ddc1cf2d5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Oct 5 15:51:46 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Oct 5 15:51:46 2011 +0200
Export symbols from the test libraries.
Hopefully fix continuous builds.
diff --git a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
index 8a06cf0..b7bb42f 100644
--- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
+++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
@@ -51,6 +51,10 @@ macro(_do_build CLEAR_LINK_INTERFACE_LIBRARIES
SPECIFY_LINK_INTERFACE_LIBRARIES)
add_library(libB SHARED classB.cpp)\n
add_library(libC SHARED classC.cpp)\n
+generate_export_header(libA)\n
+generate_export_header(libB)\n
+generate_export_header(libC)\n
+
add_executable(exec
\${CMAKE_CURRENT_BINARY_DIR}/test${COUNT}/main.cpp\)\n
)
diff --git a/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt
b/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt
index a9332e9..22e6b29 100644
--- a/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt
+++ b/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt
@@ -3,6 +3,7 @@ cmake_minimum_required(VERSION 2.8)
project(src)
include(CheckCXXCompilerFlag)
+include(GenerateExportHeader)
check_cxx_compiler_flag(-Wl,--no-undefined HAS_NO_UNDEFINED)
diff --git a/Tests/CMakeCommands/target_link_libraries/src/classA.h
b/Tests/CMakeCommands/target_link_libraries/src/classA.h
index d485489..0a83f88 100644
--- a/Tests/CMakeCommands/target_link_libraries/src/classA.h
+++ b/Tests/CMakeCommands/target_link_libraries/src/classA.h
@@ -2,7 +2,9 @@
#ifndef CLASS_A_H
#define CLASS_A_H
-class classA
+#include liba_export.h
+
+class LIBA_EXPORT classA
{
public:
classA();
diff --git a/Tests/CMakeCommands/target_link_libraries/src/classB.h
b/Tests/CMakeCommands/target_link_libraries/src/classB.h
index 7c2ad47..81e83fe 100644
--- a/Tests/CMakeCommands/target_link_libraries/src/classB.h
+++ b/Tests/CMakeCommands/target_link_libraries/src/classB.h
@@ -2,9 +2,11 @@
#ifndef CLASS_B_H
#define CLASS_B_H
+#include libb_export.h
+
class classA;
-class classB
+class LIBB_EXPORT classB
{
public:
classB();
diff --git a/Tests/CMakeCommands/target_link_libraries/src/classC.h
b/Tests/CMakeCommands/target_link_libraries/src/classC.h
index 5d8a931..8dc929e 100644
--- a/Tests/CMakeCommands/target_link_libraries/src/classC.h
+++ b/Tests/CMakeCommands/target_link_libraries/src/classC.h
@@ -2,9 +2,11 @@
#ifndef CLASS_C_H
#define CLASS_C_H
+#include libc_export.h
+
class classA;
-class classC
+class LIBC_EXPORT classC
{
public:
classC();
---
Summary of changes:
.../target_link_libraries/CMakeLists.txt |4
.../target_link_libraries/src/CMakeLists.txt |1 +
.../target_link_libraries/src/classA.h |4 +++-
.../target_link_libraries/src/classB.h |4 +++-
.../target_link_libraries/src/classC.h |4 +++-
5 files changed, 14 insertions(+), 3 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.6-1510-gb4da0da
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 b4da0da63e02a50091b8b2a8048502257fa86a58 (commit) via 4f37d5c7d9505848a4e2cddee0c29ee354f0c14a (commit) from 9e7a7f82b132f70005f42df3c7f58dbdab116799 (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=b4da0da63e02a50091b8b2a8048502257fa86a58 commit b4da0da63e02a50091b8b2a8048502257fa86a58 Merge: 9e7a7f8 4f37d5c Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Oct 5 11:16:12 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Oct 5 11:16:12 2011 -0400 Merge topic 'cmake-link-interface-libraries' into next 4f37d5c Explicitly exclude apple from use of this linker flag. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f37d5c7d9505848a4e2cddee0c29ee354f0c14a commit 4f37d5c7d9505848a4e2cddee0c29ee354f0c14a Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Oct 5 17:14:57 2011 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Oct 5 17:14:57 2011 +0200 Explicitly exclude apple from use of this linker flag. The check for this flag seems to pass on Apple, and then fail later. diff --git a/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt b/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt index 22e6b29..5411226 100644 --- a/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt +++ b/Tests/CMakeCommands/target_link_libraries/src/CMakeLists.txt @@ -7,7 +7,7 @@ include(GenerateExportHeader) check_cxx_compiler_flag(-Wl,--no-undefined HAS_NO_UNDEFINED) -if (HAS_NO_UNDEFINED) +if (HAS_NO_UNDEFINED AND NOT APPLE) set(CMAKE_SHARED_LINKER_FLAGS -Wl,--no-undefined) endif() --- Summary of changes: .../target_link_libraries/src/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, next, updated. v2.8.6-1512-gef78b39
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 ef78b3971ef2d0502f4bd9a6083a9ca3883ff25c (commit) via 279e66e5a9f27a326fa8397093af2ca107fc6e7e (commit) from b4da0da63e02a50091b8b2a8048502257fa86a58 (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=ef78b3971ef2d0502f4bd9a6083a9ca3883ff25c commit ef78b3971ef2d0502f4bd9a6083a9ca3883ff25c Merge: b4da0da 279e66e Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Oct 5 12:01:34 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Oct 5 12:01:34 2011 -0400 Merge topic 'cmake-link-interface-libraries' into next 279e66e Don't test for failure on APPLE. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=279e66e5a9f27a326fa8397093af2ca107fc6e7e commit 279e66e5a9f27a326fa8397093af2ca107fc6e7e Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Oct 5 18:00:24 2011 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Oct 5 18:00:53 2011 +0200 Don't test for failure on APPLE. This fails for a reason I do not know because I'm not familiar with Apple. diff --git a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt index 94029bf..41224d0 100644 --- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt +++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt @@ -163,20 +163,24 @@ expect_pass(False False # However, if we do clear it and don't explicitly link the executable to it, it fails, # whether we specify the link_interface_libraries properly or not. -if (NOT WIN32) - # ... but not on windows apparently - expect_fail(True False -classB classC - LIBS -libC -) -endif() +if (NOT APPLE) + # Apparently this doesn't work on APPLE either. + # http://www.cdash.org/CDash/testDetails.php?test=117927753build=1596834 + if (NOT WIN32) +# This does not work on windows apparently +expect_fail(True False + classB classC +LIBS + libC + ) + endif() -expect_fail(True True -classB classC - LIBS -libC -) + expect_fail(True True + classB classC +LIBS + libC + ) +endif() # Then we can still link the executable to libA directly of course to pass expect_pass(True False --- Summary of changes: .../target_link_libraries/CMakeLists.txt | 30 +++ 1 files changed, 17 insertions(+), 13 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.6-1514-g1d53d38
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 1d53d38d503513d39eb5003abbedb1ce82e6fe7c (commit)
via 240d39a6a4f72fe0e45fc1a1403e0b578d36a142 (commit)
from ef78b3971ef2d0502f4bd9a6083a9ca3883ff25c (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=1d53d38d503513d39eb5003abbedb1ce82e6fe7c
commit 1d53d38d503513d39eb5003abbedb1ce82e6fe7c
Merge: ef78b39 240d39a
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Oct 5 12:03:38 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Oct 5 12:03:38 2011 -0400
Merge topic 'CodeBlocks-quoting' into next
240d39a Fix XML safety issue with adding preprocessor defines in CodeBlocks
project.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=240d39a6a4f72fe0e45fc1a1403e0b578d36a142
commit 240d39a6a4f72fe0e45fc1a1403e0b578d36a142
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Oct 5 10:02:32 2011 -0600
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Wed Oct 5 10:02:32 2011 -0600
Fix XML safety issue with adding preprocessor defines in CodeBlocks project.
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx
b/Source/cmExtraCodeBlocksGenerator.cxx
index 7db91c7..9a0b1ea 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -19,6 +19,7 @@
#include cmGeneratedFileStream.h
#include cmTarget.h
#include cmSystemTools.h
+#include cmXMLSafe.h
#include cmsys/SystemTools.hxx
@@ -585,7 +586,8 @@ void
cmExtraCodeBlocksGenerator::AppendTarget(cmGeneratedFileStream fout,
for(std::vectorstd::string::const_iterator di = defs.begin();
di != defs.end(); ++di)
{
-fout Add option=\-D di-c_str() \ /\n;
+cmXMLSafe safedef(di-c_str());
+fout Add option=\-D safedef.str() \ /\n;
}
}
---
Summary of changes:
Source/cmExtraCodeBlocksGenerator.cxx |4 +++-
1 files changed, 3 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.6-3-g61c69d3
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 61c69d3fbbdb0390eb8f27e39a30a21d43ab4169 (commit) from ab97790c33c74127b4698e1c858ab6a3ce966b40 (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=61c69d3fbbdb0390eb8f27e39a30a21d43ab4169 commit 61c69d3fbbdb0390eb8f27e39a30a21d43ab4169 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Oct 6 00:01:21 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Oct 6 00:05:17 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index d1ffc3a..86cdb39 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 10) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 05) +SET(KWSYS_DATE_STAMP_DAY 06) --- 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
