[cmake-developers] [CMake 0012496]: Compiler tests ignore variables from command line when using toolchain file
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12496
==
Reported By:Markus Klinik
Assigned To:
==
Project:CMake
Issue ID: 12496
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-10-06 03:50 EDT
Last Modified: 2011-10-06 03:50 EDT
==
Summary:Compiler tests ignore variables from command line
when using toolchain file
Description:
Have a toolchain file that sets cache variables. On the
command line, override the default values using the -D option. The overrides
are ignored by the configure-time compiler tests, but the overrides go to the
generated makefiles.
Example:
--- toolchain.cmake
set(ANDROID_NDK_ROOT /home/nosuchuser/android-ndk-r6b CACHE PATH Android NDK
root)
message(ANDROID_NDK_ROOT is: ${ANDROID_NDK_ROOT})
--- end of toolchain.cmake
--- CMakeLists.txt
project(foobar)
--- end of CMakeLists.txt
run cmake with the following command:
$ cmake -DANDROID_NDK_ROOT=/home/mkl/android-ndk
-DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
and observe that ANDROID_NDK_ROOT takes on the default value for the compiler
tests:
ANDROID_NDK_ROOT is: /home/mkl/android-ndk
ANDROID_NDK_ROOT is: /home/mkl/android-ndk
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
==
Issue History
Date ModifiedUsername FieldChange
==
2011-10-06 03:50 Markus Klinik 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
[cmake-developers] [CMake 0012499]: VS 2010 custom rules with no output need to not have a command line
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12499 == Reported By:James Bigler Assigned To: == Project:CMake Issue ID: 12499 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-10-06 12:48 EDT Last Modified: 2011-10-06 12:48 EDT == Summary:VS 2010 custom rules with no output need to not have a command line Description: I've noticed with some of my projects that the ZERO_CHECK project always runs. I think I narrowed it down to the fact that the rule for ZERO_CHECK.rule has a command line. The custom build machinery in VS 2010 seems to think that because the Output file, which in this case is non-existent and designed to be that way, needs to be built. D:\WIN7X64\BUGS\CMAKE-EXTRA-BUILD\BUILD-64-VS10\CMAKEFILES\ZERO_CHECK does not exist; source compilation required. (TaskId:14) CMakeFiles\ZERO_CHECK.rule will be compiled. (TaskId:14) If I remove the script from the command line that seems to do nothing, then the build behaves the way that it should. setlocal :cmEnd endlocal call :cmErrorLevel %errorlevel% goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd (TaskId:14) Steps to Reproduce: I've attached a simple CMake project. 1. Configure it and build twice. The second build will always build the ZERO_CHECK project. 2. Open the Property Pages for ZERO_CHECK.rule and remove the contents of the Command Line entry. 3. Delete the files in build/x64/Debug/ZERO_CHECK/* This is needed to update the custom target files found in this directory that are used by MSbuild to determine dependencies. 4. Build twice. The second build will not rebuild the ZERO_CHECK project. Editing the CMakeLists.txt file will cause a rebuild as expected (though it will overwrite your local changes to the project files). == Issue History Date ModifiedUsername FieldChange == 2011-10-06 12:48 James Bigler New Issue 2011-10-06 12:48 James Bigler File Added: cmake-extra-build.7z == -- 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] Strange VS output file field
On Wed, Oct 5, 2011 at 3:45 PM, James Bigler jamesbig...@gmail.com wrote: On Fri, Aug 19, 2011 at 10:41 AM, David Cole david.c...@kitware.comwrote: On Thu, Aug 18, 2011 at 4:56 PM, David Cole david.c...@kitware.com wrote: On Thu, Aug 18, 2011 at 1:30 PM, David Cole david.c...@kitware.com wrote: On Tue, Aug 9, 2011 at 6:19 PM, James Bigler jamesbig...@gmail.com wrote: I recently switched to 2.8.5 and noticed something strange. I have several files that build into a Debug|Release agnostic place. If I build it in one then switch to the other the files don't regenerate, because the build rule has been satisfied. With CMake 2.8.5 and VS 2010 I noticed something strange. It wanted to build the files in both debug and release. I then looked at the vsproj files and I noticed this: Outputs Condition='$(Configuration)|$(Platform)'=='RelWithDebInfo|Win32'C:\code\build-32-vs10-c40\lib\myfile_build.txt;%(Outputs)/Outputs %(Outputs)??? Why is that in there. If I manually remove $(Outputs) then it stops rebuilding my files. James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers The %(Attribute) notation means inherit the value from the same element in my parent. So for a file's attribute, it typically inherits the value from the same named attribute in the project. In this case, I'm not entirely sure why it's there, but it's been there right from the very first commit adding the VS 10 generator to CMake: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7491f529 I can't think of the reason why it might be needed off the top of my head, so ... I'll try to remove it and see if all the tests pass. If they do, I suppose it should be ok to remove it. Does anybody else reading this thread have any other information? Thanks, David I constructed a custom build command that runs a batch file and outputs a text file solely via the VS10 IDE... and there was no %(Outputs) in the vcxproj file. So I think it's safe to remove this. I'll push a change that does that. Thanks for the report, David This bug is quite possibly a report of the same thing, although, as noted in the bug, I could not reproduce the problem: http://public.kitware.com/Bug/view.php?id=12302 Drat! This doesn't actually seem to help. I'll see if I can create a smaller test program that illustrates the issue. Does anyone know of a way to figure out why VS wants to build something similar to a make -d? It would be really helpful to understand what is causing VS to rebuild stuff. James I've been buried in this for the past day and I think I might know what is going on. Unfortunately there doesn't appear to be an elegant solution to this other than perhaps filing a bug with Microsoft. From my experimentation, it appears that custom build rules require being registered in the custombuild.command.1.tlog file that is put into the %(Intermediate Directory) location of the project. Since this location is generally different for Debug and Release builds, each configuration needs to run *all* the custom build rules at least once to populate this file. This the output from MSBuild when more detailed logging is enabled. Forcing rebuild of all source files due to missing command tlog D:\win7x64\bugs\cmake-extra-build\VS-2010\cat-file\Release\custombuild.command.1.tlog. (TaskId:14) I'm not sure how to work around this aside from putting all non configuration dependent targets into a special project that has an intermediate directory that isn't %(Configuration) dependent. That doesn't seem like a lot of fun. Why MSBuild can't simply just populate the files without actually running the build commands if the dependencies are met seems like a little bit like a missing feature, however it could be the mechanism to determine dependencies relies on that file being populated. Unfortunately for me where I have *many* non-configuration dependent custom build rules I have to rebuild all the files for each configuration. :( 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
Brad King wrote:
On 10/5/2011 9:47 AM, Stephen Kelly wrote:
Thanks for all of your explanations. It seems that introducing a way to
do this with one command has some support.
So if SOME_FEATURE is true,
target_link_libraries(foo bar SOME_KEYWORD baz)
if (SOME_FEATURE)
target_link_libraries(foo mar SOME_KEYWORD maz)
endif()
would have to result in bar and mar not being part of the link interface,
and baz and maz being part of the link interface.
How do we decide on a keyword there? LINK_INTERFACE_DEPENDENCIES perhaps?
One possible problem with making it a keyword is that the name could
appear in a list of libraries and invisibly transform a
target_link_libraries call.
Do you mean a library or target called LINK_INTERFACE_DEPENDENCIES? Or do
you mean like this:
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
where the variable could be a list containing the term
LINK_INTERFACE_DEPENDENCIES?
What we need is a pair of keywords to switch
between link+interface and
link-only dependencies. We allow the keywords only if one of the two is
the second argument to the command after the target name. For example,
they can be called LINK_INTERFACE for link+interface and LINK_DEPENDS
for link-only:
target_link_libraries(foo LINK_INTERFACE bar LINK_DEPENDS baz)
if(SOME_FEATURE)
target_link_libraries(foo LINK_INTERFACE mar LINK_DEPENDS maz)
endif()
Is this also succeptable to the same
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
effect?
Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE?
Perhaps LINK AND LINK_ONLY?
I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which
are most clear to me. We can change it once we have an implementation to
talk about.
All the best,
Steve.
--
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
Stephen Kelly wrote: Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE? Perhaps LINK AND LINK_ONLY? I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which are most clear to me. We can change it once we have an implementation to talk about. Well that didn't take long. I pushed a target-link-libraries-interfaces branch to stage. In the branch: target_link_libraries(foo LINK_PRIVATE qtxml LINK_PUBLIC qtcore qtnetwork ) and target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork LINK_PRIVATE qtxml ) are equivalent to: target_link_libraries(foo qtcore qtnetwork qtxml ) target_link_libraries(foo LINK_INTERFACE_LIBRARIES qtcore qtnetwork ) both mean: * foo will link against qtxml, qtcore and qtnetwork * qtcore and qtnetwork will be in the LINK_INTERFACE_LIBRARIES ... target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to target_link_libraries(foo qtcore qtnetwork ) * foo will link against qtcore and qtnetwork ... target_link_libraries(foo LINK_PRIVATE qtcore ) is equivalent to: target_link_libraries(foo qtcore ) target_link_libraries(foo TARGET_LINK_LIBRARIES ) * foo will link against qtcore * qtcore will not be in the LINK_INTERFACE_LIBRARIES ... target_link_libraries(foo LINK_PRIVATE qtxml ) target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to: target_link_libraries(foo qtcore qtxml qtnetwork ) target_link_libraries(foo TARGET_LINK_LIBRARIES qtcore qtnetwork ) * foo will link against qtxml, qtcore and qtnetwork * qtcore and qtnetwork will be in the LINK_INTERFACE_LIBRARIES What do you think? Thanks, Steve. -- 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
Stephen Kelly wrote: target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to target_link_libraries(foo qtcore qtnetwork ) * foo will link against qtcore and qtnetwork I should have also noted that both qtcore and qtnetwork will also be in the LINK_INTERFACE_LIBRARIES. -- 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] Include source files on a per-configuration basis
On 10/06/2011 07:04 AM, Michael Wild wrote:
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?
)
###
Yes, this would work, too, but if neither b.cpp nor c.cpp should be
compiled if the current configuration is neither DEBUG nor RELEASE,
the b_or_c.cpp file would be effectively empty, and adding an object
file compiled from an empty source file to a binary is not 100 % the
same as dropping the object file completely - at least with gcc and
even with -Os. However, it's a quite negligible effect, but linking
against an empty static library or building a reconfigured project
means *exactly* the same as if b.cpp
[CMake] Custom install target
Hello, I would like to create a custom install target: install-update The things done by this target are: - change CMAKE_INSTALL_PREFIX to a specific directory: CMAKE_BINARY_PREFIX/PROJECT_NAME-REVISION_NUMBER - run make install I don't know how to launch a defined target from within cmake. Is there any simple solution to do that ? Best regards, YC -- 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] modifying the PATH during NSIS intallation
Hi all, I recently discovered the (very) useful CPack program from CMake. I would like to build an NSIS installer that, when launched, will, as well as installing my package, will also modify the PATH with the directory where my executables have been installed. Is that something (if so, how) that fall in the scope of CPACK_INSTALL_COMMANDS ? thanks a lot Eric -- 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
[CMake] Still problems with add_custom_command
Hi,
in my CMake project I have the need for a custom command that should be
processed in case a file is touched...that is the file the custom
command depends on. I already use the add_custom_command and
add_custom_target CMake instructions in my project, but always for
CMakeLists.txt files in subfolders where a static library will be build.
I think I have a real simple requirement, but I don't get it work up to now.
In my main project I have a subfolder with an own CMakeLists.txt file,
this subfolder is added to the main project by instruction
add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/subfolder ).
Within the CMakeLists.txt in the subfolder I want to call a custom
command, so I added the following lines:
message( My Tool started by custom command / target )
add_custom_command( OUTPUT Out.txt
COMMAND tool.exe ${ToolConfig}
DEPENDS ${ToolConfig} )
add_custom_target( TOOL_CFG_OUT
DEPENDS Out.txt )
In my main project I added the custom target as dependency in the way:
add_dependencies( ${PROJECT_NAME} TOOL_CFG_OUT )
If I start the CMake process generating the Makefile I see the output of
my message My Tool started by custom command / target, but the custom
command is never called.
I would like to have a build configuration that every time the dependend
file which is declared in the variable ${ToolConfig} is touched, the
command tool.exe is started.
What am I doing wrong? Do you have a sample for me how to start a custom
command every time a file is touched. I don't get it work.
Thanks in advance,
Martin...
--
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] Version 2.8.6 Issues with Cmake-Gui and CTest
I was previously using 2.8.0. With 2.8.6 (from zipped binaries for win32-x86) I immediately noticed a couple oddities: My Wacom mouse can't seem to activate any controls on Cmake-Gui. It still works fine with 2.8.0. When the new version of CTest runs, my firewall reports it is trying to connect to the internet. Any info on these issues? Regards, Sheri -- 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
Hi Bill, Here are some timing, I made for ITK to compare ninja vs make (made last month). See results below The difference is not much, especially when you realized that none of the data have been downloaded, and I am not sure that at the end we get the same binary tree... Encouraging matter of fact, it worked on ITK... my 2 cts, Arnaud Starting from scratch $ time make -j12 real18m20.479s user205m51.536s sys8m21.319s $ time ninja -j12 real18m1.246s user205m23.438s sys7m26.392 adding one extra space in itk::Image $ time make -j12 real15m8.004s user166m45.025s sys6m13.991s $ time ninja -j12 real14m54.776s user166m41.377s sys5m31.129s -- 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 10/6/2011 12:07 PM, Arnaud Gelas wrote: Hi Bill, Here are some timing, I made for ITK to compare ninja vs make (made last month). See results below The difference is not much, especially when you realized that none of the data have been downloaded, and I am not sure that at the end we get the same binary tree... Encouraging matter of fact, it worked on ITK... my 2 cts, Arnaud What happens if you just do a build where nothing builds? -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] Version 2.8.6 Issues with Cmake-Gui and CTest
On 10/6/2011 11:50 AM, Sheri wrote: I was previously using 2.8.0. With 2.8.6 (from zipped binaries for win32-x86) I immediately noticed a couple oddities: My Wacom mouse can't seem to activate any controls on Cmake-Gui. It still works fine with 2.8.0. Do other mice work? I can't see how there could be a mouse specific HW issue in cmake-gui, it is just a Qt app. Might be the version of Qt we are using When the new version of CTest runs, my firewall reports it is trying to connect to the internet. What ctest command are you running? -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
[CMake] STREQUAL not functioning?
According to the CMake documentation, the `STREQUAL` comparison is allowed to take either a VARIABLE or a STRING as either parameter. So, in this example below, the message does NOT print, which is broken: set( FUBARTEST OK ) if( FUBARTEST STREQUAL OK ) message( It Worked ) endif() Any reason why this isn't working as documented? - 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] STREQUAL not functioning?
2011/10/6 Robert Dailey rcdai...@gmail.com: According to the CMake documentation, the `STREQUAL` comparison is allowed to take either a VARIABLE or a STRING as either parameter. So, in this example below, the message does NOT print, which is broken: set( FUBARTEST OK ) if( FUBARTEST STREQUAL OK ) message( It Worked ) endif() Any reason why this isn't working as documented? Don't know but it works just fine for on Linux + CMake 2.8.6 which cmake version are you using? Could you try running cmake --trace --debug-output -P fubartest.cmake and tell us waht's printed out? -- 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] STREQUAL not functioning?
Well there you go, deleting the cache reconfiguring fixed it. That was
weird.
Thanks for the help!
-
Robert Dailey
On Thu, Oct 6, 2011 at 1:50 PM, Robert Dailey rcdai...@gmail.com wrote:
Ok interesting, it is working for me too. I guess my reproducible use case
was invalid.
(BTW, I'm running through cmake-gui on Windows 7 x64 using CMake version
2.8.5)
My use case was a simplified version of the real code. FUBARTEST is
actually a cache variable defined by the root CMakeLists.txt file. In my
real test case, my STREQUAL statement is failing to execute the conditional
code when I do this:
if( NEMO_TARGET STREQUAL NSPR )
However if I do this, it works:
if( ${NEMO_TARGET} STREQUAL NSPR )
I don't know why both would behave differently. Just to rule out the cache
variable being the issue, I tried this (I attempted to make the SET() call
override the originally defined cache variable. I did not actually remove
the variable from cache):
set( NEMO_TARGET NSPR )
if( NEMO_TARGET STREQUAL NSPR )
Of course, this statement did not result in the enclosed message() being
executed.
I have tried creating a small test case to reproduce this issue but so far
I have been unsuccessful. I'll try clearing my cache to rule out any issues
there. In the meantime if you have any suspicions or have run into this
before, please give me some ideas on how to solve this :)
Thanks.
-
Robert Dailey
On Thu, Oct 6, 2011 at 1:31 PM, Eric Noulard eric.noul...@gmail.comwrote:
2011/10/6 Robert Dailey rcdai...@gmail.com:
According to the CMake documentation, the `STREQUAL` comparison is
allowed
to take either a VARIABLE or a STRING as either parameter. So, in this
example below, the message does NOT print, which is broken:
set( FUBARTEST OK )
if( FUBARTEST STREQUAL OK )
message( It Worked )
endif()
Any reason why this isn't working as documented?
Don't know but it works just fine for on Linux + CMake 2.8.6
which cmake version are you using?
Could you try running
cmake --trace --debug-output -P fubartest.cmake
and tell us waht's printed out?
--
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] Version 2.8.6 Issues with Cmake-Gui and CTest
On 06.10.11 20:21:33, Andreas Pakulat wrote: On 06.10.11 12:30:09, Bill Hoffman wrote: On 10/6/2011 11:50 AM, Sheri wrote: I was previously using 2.8.0. With 2.8.6 (from zipped binaries for win32-x86) I immediately noticed a couple oddities: My Wacom mouse can't seem to activate any controls on Cmake-Gui. It still works fine with 2.8.0. Do other mice work? I can't see how there could be a mouse specific HW issue in cmake-gui, it is just a Qt app. Might be the version of Qt we are using There's recently been a Wacom-related thread on qt-interest, but IIRC that was about a tablet device. Thats the qt-interest list from Nokia: http://lists.qt.nokia.com/mailman/listinfo/qt-interest Andreas -- 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
OK, so I think this project is way too small for this test. There is some fixed overhead in the process here, and we are seeing it. We are talking about .5 seconds difference to check a whole build system. If you want to do tests like this, you need a much bigger project. I am sure that CMake will not be 50% slower for a larger project where we are not comparing .5 seconds to 1.1 seconds or .1 seconds. I don't know a bigger project which supports qmake and cmake, but I tried VTK: Time to check when nothing to build: ninja(ms) make(ms) -j1 ~2503600 -j2 ~2502100 -j4 ~2501700 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] FindQt4
On Friday, September 30, 2011 03:54:26 pm MM wrote:
hi,
I generated a msvc10 solution with cmake 2.8.5.
I use the following in the project's CMakeLists.txt
FIND_PACKAGE(Qt4 4.5.3 COMPONENTS QtCore QtGui QtOpenGL REQUIRED)
IF(QT4_FOUND)
INCLUDE(${QT_USE_FILE})
TARGET_LINK_LIBRARIES(nhui ${QT_LIBRARIES})
ELSE()
MESSAGE(FATAL_ERROR Qt=4.5.3 not found)
ENDIF()
opening the solution in vs2010 and linking against qwtplot3d required
adding these 2 libs on winxp32bit
OpenGL32.Lib et GlU32.Lib
I would have thought QtOpenGL4.lib required these above 2 libs and so
FindQt4 would have added them automatically?
QtOpenGL4.dll needs those libraries, but that doesn't necessarily mean users
of that library need to link with opengl32.lib and glu32.lib also.
If your code needs to link with opengl32.lib, then you can use
find_package(OpenGL) and target_link_libraries().
--
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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 06.10.2011 21:14, Peter Kümmel wrote: OK, so I think this project is way too small for this test. There is some fixed overhead in the process here, and we are seeing it. We are talking about .5 seconds difference to check a whole build system. If you want to do tests like this, you need a much bigger project. I am sure that CMake will not be 50% slower for a larger project where we are not comparing .5 seconds to 1.1 seconds or .1 seconds. I don't know a bigger project which supports qmake and cmake, Another idea is to down-cock the system: My system runs in a VirtualBox, and I simply don't allow 100% CPU usage: KST: qmake cmake ninja -j1 14s 45s 3s -j2 14s 27s 3s VTK: qmake cmake ninja -j1 130s8s -j4 30s 8s 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
[CMake] Target-specific include directories?
I'm using cmake (through the GUI) on Windows (version 2.8.5).
Currently I have a define_project() function that all 100 or so
sub-directories use to define its project. This function calls
add_executable(), sets target properties, and everything necessary to set it
up properly to build in Visual Studio. Each project is also able to pass in
a list of include directories that other targets shall use if they specify
that target as a dependency. So for example:
if I have two targets, A and B, and A depends on B, if B specified C:\foo
as its source include directory, then target A will have an additional
include directory of C:\foo to get to B's source code.
Right now I'm implementing this functionality using an internal cache
variable. Each target defines a ${target}_SOURCEDIR cache variable. So I
would have a B_SOURCEDIR variable with C:\foo in it, and target A would
use this variable to add include directories to itself.
The problem with this approach is that it requires projects to be processed
by CMake in the order of their dependency. I would like to make the project
definition order (the order I call define_project()) to not matter, so I was
wondering if there was a built-in functionality for this kind of behavior or
if there is a different implementation I could use. Can anyone help me out?
Thanks in advance.
-
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] Version 2.8.6 Issues with Cmake-Gui and CTest
On 10/6/2011 12:30 PM, Bill Hoffman wrote: On 10/6/2011 11:50 AM, Sheri wrote: I was previously using 2.8.0. With 2.8.6 (from zipped binaries for win32-x86) I immediately noticed a couple oddities: My Wacom mouse can't seem to activate any controls on Cmake-Gui. It still works fine with 2.8.0. Do other mice work? I can't see how there could be a mouse specific HW issue in cmake-gui, it is just a Qt app. Might be the version of Qt we are using yes, a wired Logitech mouse works. But my normal mouse is currently the Wacom one. It is apparently an ongoing qt bug since 2010. https://bugreports.qt.nokia.com//browse/QTBUG-6127 My earlier Cmake version 2.8.0 was from 2009. I don't suppose I could copy the old cmake-gui.exe into the new folder? When the new version of CTest runs, my firewall reports it is trying to connect to the internet. What ctest command are you running? e.g., make test Things are getting worse. My project won't configure properly to build on MSVC8. I recently coded some testing changes for PCRE's CmakeLists.txt file, which included raising the minimum version policy to 2.8.0. Everything works configuring, building and testing in Msys (2.8.0 and 2.8.6) but not for MSVC8. The only reason I was trying the latest version is that if my changes are published it will necessitate users updating CMake; so I just thought I should test it with the latest release. With 2.8.6, when I first open cmake-gui, select the PCRE source folder, enter a new build folder name, and click Configure it gives a bunch of Failed to open and Permission denied, errors e.g.: --- CMake Error at C:/cmake/share/cmake-2.8/Modules/CheckFunctionExists.cmake:47 (TRY_COMPILE): Failed to open C:/pcre-8.20/pcre-8.20-RC2/VC_NewConfig286_2/CMakeFiles/CMakeTmp/CMakeLists.txt Permission denied Call Stack (most recent call first): CMakeLists.txt:86 (CHECK_FUNCTION_EXISTS) --- After that if I choose my options, then Configure again, it says its checking long long and other types. Seems ok. But if I then Generate and try to build in native compiler MSVC8, during the build I get a compile errors, e.g.: ..\pcrecpp.cc(828) : fatal error C1189: #error : parse_longlong_radix: cannot convert input to a long-long I don't believe this has anything to do with my changes, but I will try configuring using unmodified CmakeLists.txt file in 2.8.6 and see if the project builds as it did in 2.8.0 and a variety of earlier cmake versions. My system is slow, so it is painful to need to keep rebuilding. Regards, Sheri -- 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] STREQUAL not functioning?
On 10/06/2011 08:51 PM, Robert Dailey wrote:
Well there you go, deleting the cache reconfiguring fixed it. That was
weird.
Thanks for the help!
FYI, the attached CMakeLists.txt examines a variable's value in 5 cases:
NONEXIST: No value in current scope or in cache.
SCOPEONLY: Value in current scope, no value in cache.
CACHEONLY: No value in current scope, value in cache.
BOTHEQUAL: The same value in current scope and cache.
BOTHUNEQUAL: Different values in current scope and cache.
The findings are:
NOT STREQUAL, NONEXIST[SCOPE]=, NONEXIST[CACHE]=
STREQUAL, SCOPEONLY[SCOPE]=xyz, SCOPEONLY[CACHE]=
STREQUAL, CACHEONLY[SCOPE]=xyz, CACHEONLY[CACHE]=xyz
STREQUAL, BOTHEQUAL[SCOPE]=xyz, BOTHEQUAL[CACHE]=xyz
STREQUAL, BOTHUNEQUAL[SCOPE]=xyz, BOTHUNEQUAL[CACHE]=abc
AFAICS, this is exactly what one would expect, i.e. STREQUAL refers to
the variable's value in the current scope and uses the cached value as
fallback - in CACHEONLY - if the variable has no current-scope value.
This is with CMake 2.8.6; do you gain different results?
Regards,
Michael
On Thu, Oct 6, 2011 at 1:50 PM, Robert Dailey rcdai...@gmail.com wrote:
Ok interesting, it is working for me too. I guess my reproducible use case
was invalid.
(BTW, I'm running through cmake-gui on Windows 7 x64 using CMake version
2.8.5)
My use case was a simplified version of the real code. FUBARTEST is
actually a cache variable defined by the root CMakeLists.txt file. In my
real test case, my STREQUAL statement is failing to execute the conditional
code when I do this:
if( NEMO_TARGET STREQUAL NSPR )
However if I do this, it works:
if( ${NEMO_TARGET} STREQUAL NSPR )
I don't know why both would behave differently. Just to rule out the cache
variable being the issue, I tried this (I attempted to make the SET() call
override the originally defined cache variable. I did not actually remove
the variable from cache):
set( NEMO_TARGET NSPR )
if( NEMO_TARGET STREQUAL NSPR )
Of course, this statement did not result in the enclosed message() being
executed.
I have tried creating a small test case to reproduce this issue but so far
I have been unsuccessful. I'll try clearing my cache to rule out any issues
there. In the meantime if you have any suspicions or have run into this
before, please give me some ideas on how to solve this :)
Thanks.
-
Robert Dailey
On Thu, Oct 6, 2011 at 1:31 PM, Eric Noulard eric.noul...@gmail.comwrote:
2011/10/6 Robert Dailey rcdai...@gmail.com:
According to the CMake documentation, the `STREQUAL` comparison is
allowed
to take either a VARIABLE or a STRING as either parameter. So, in this
example below, the message does NOT print, which is broken:
set( FUBARTEST OK )
if( FUBARTEST STREQUAL OK )
message( It Worked )
endif()
Any reason why this isn't working as documented?
Don't know but it works just fine for on Linux + CMake 2.8.6
which cmake version are you using?
Could you try running
cmake --trace --debug-output -P fubartest.cmake
and tell us waht's printed out?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STREQUAL NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
UNSET(NONEXIST)
UNSET(NONEXIST CACHE)
IF(NONEXIST STREQUAL xyz)
MESSAGE(STREQUAL, NONEXIST[SCOPE]=${NONEXIST},
NONEXIST[CACHE]=$CACHE{NONEXIST})
ELSE()
MESSAGE(NOT STREQUAL, NONEXIST[SCOPE]=${NONEXIST},
NONEXIST[CACHE]=$CACHE{NONEXIST})
ENDIF()
SET(SCOPEONLY xyz)
UNSET(SCOPEONLY CACHE)
IF(SCOPEONLY STREQUAL xyz)
MESSAGE(STREQUAL, SCOPEONLY[SCOPE]=${SCOPEONLY},
SCOPEONLY[CACHE]=$CACHE{SCOPEONLY})
ELSE()
MESSAGE(NOT STREQUAL, SCOPEONLY[SCOPE]=${SCOPEONLY},
SCOPEONLY[CACHE]=$CACHE{SCOPEONLY})
ENDIF()
SET(CACHEONLY xyz CACHE STRING FORCE)
SET(CACHEONLY pqr) # In order to check if UNSET(CACHEONLY) really...
UNSET(CACHEONLY) # ...unsets CACHEONLY only in the current scope.
IF(CACHEONLY STREQUAL xyz)
MESSAGE(STREQUAL, CACHEONLY[SCOPE]=${CACHEONLY},
CACHEONLY[CACHE]=$CACHE{CACHEONLY})
ELSE()
MESSAGE(NOT STREQUAL, CACHEONLY[SCOPE]=${CACHEONLY},
CACHEONLY[CACHE]=$CACHE{CACHEONLY})
ENDIF()
SET(BOTHEQUAL xyz CACHE STRING FORCE)
SET(BOTHEQUAL xyz) # Actually unnecessary.
IF(BOTHEQUAL STREQUAL xyz)
MESSAGE(STREQUAL, BOTHEQUAL[SCOPE]=${BOTHEQUAL},
BOTHEQUAL[CACHE]=$CACHE{BOTHEQUAL})
ELSE()
MESSAGE(NOT STREQUAL, BOTHEQUAL[SCOPE]=${BOTHEQUAL},
BOTHEQUAL[CACHE]=$CACHE{BOTHEQUAL})
ENDIF()
SET(BOTHUNEQUAL abc CACHE STRING FORCE)
SET(BOTHUNEQUAL xyz)
IF(BOTHUNEQUAL STREQUAL xyz)
MESSAGE(STREQUAL, BOTHUNEQUAL[SCOPE]=${BOTHUNEQUAL},
BOTHUNEQUAL[CACHE]=$CACHE{BOTHUNEQUAL})
ELSE()
MESSAGE(NOT STREQUAL, BOTHUNEQUAL[SCOPE]=${BOTHUNEQUAL},
BOTHUNEQUAL[CACHE]=$CACHE{BOTHUNEQUAL})
ENDIF()
--
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
Re: [CMake] Version 2.8.6 Issues with Cmake-Gui and CTest
On 10/6/2011 5:35 PM, Sheri wrote: On 10/6/2011 12:30 PM, Bill Hoffman wrote: On 10/6/2011 11:50 AM, Sheri wrote: I was previously using 2.8.0. With 2.8.6 (from zipped binaries for win32-x86) I immediately noticed a couple oddities: My Wacom mouse can't seem to activate any controls on Cmake-Gui. It still works fine with 2.8.0. Do other mice work? I can't see how there could be a mouse specific HW issue in cmake-gui, it is just a Qt app. Might be the version of Qt we are using yes, a wired Logitech mouse works. But my normal mouse is currently the Wacom one. It is apparently an ongoing qt bug since 2010. https://bugreports.qt.nokia.com//browse/QTBUG-6127 My earlier Cmake version 2.8.0 was from 2009. I don't suppose I could copy the old cmake-gui.exe into the new folder? When the new version of CTest runs, my firewall reports it is trying to connect to the internet. What ctest command are you running? e.g., make test Things are getting worse. snip Rebooted and was able to properly configure in 2.8.6's cmake-gui and build in MSVC8. Not sure what was previously awry. Regards, Sheri -- 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] CDT generator - CDT 8.0.1 [Visual Studio compiler support]
Hi, Using CMake 2.8.4, I see Eclipse CDT4 generator support for NMake With the recent release of CDT 8.X, there is Visual Studio compiler as a new/separate toolchain. Are there plans to support that as a generator? Regards -- Nicholas Yue Graphics - RenderMan, Visualization, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue -- 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] Still problems with add_custom_command
On 10/06/2011 05:40 PM, Martin Kupke wrote:
Hi,
in my CMake project I have the need for a custom command that should be
processed in case a file is touched...that is the file the custom
command depends on. I already use the add_custom_command and
add_custom_target CMake instructions in my project, but always for
CMakeLists.txt files in subfolders where a static library will be build.
I think I have a real simple requirement, but I don't get it work up to now.
In my main project I have a subfolder with an own CMakeLists.txt file,
this subfolder is added to the main project by instruction
add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/subfolder ).
Within the CMakeLists.txt in the subfolder I want to call a custom
command, so I added the following lines:
message( My Tool started by custom command / target )
Use the COMMENT clause of ADD_CUSTOM_COMMAND() instead; in this
way, you will see when the custom command is actually executed.
add_custom_command( OUTPUT Out.txt
COMMAND tool.exe ${ToolConfig}
DEPENDS ${ToolConfig} )
add_custom_target( TOOL_CFG_OUT
DEPENDS Out.txt )
In my main project I added the custom target as dependency in the way:
add_dependencies( ${PROJECT_NAME} TOOL_CFG_OUT )
If I start the CMake process generating the Makefile I see the output of
my message My Tool started by custom command / target, but the custom
command is never called.
I would like to have a build configuration that every time the dependend
file which is declared in the variable ${ToolConfig} is touched, the
command tool.exe is started.
What am I doing wrong? Do you have a sample for me how to start a custom
command every time a file is touched. I don't get it work.
Thanks in advance,
Martin...
Indeed, custom commands in subdirectories with results used in higher
directories provide some pitfalls. At first, the following exemplary
CMakeList.txt files model the situation you outlined and do work:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMCOMMAND C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_SUBDIRECTORY(subdir)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
SET_SOURCE_FILES_PROPERTIES(
${CMAKE_BINARY_DIR}/subdir/f.c PROPERTIES GENERATED TRUE)
ADD_EXECUTABLE(main main.c ${CMAKE_BINARY_DIR}/subdir/f.c)
ADD_DEPENDENCIES(main f)
# subdir/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c.in void f(void){}\n)
ADD_CUSTOM_COMMAND(
OUTPUT f.c
COMMAND ${CMAKE_COMMAND} -E copy f.c.in f.c
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/f.c.in
COMMENT Generating f.c)
ADD_CUSTOM_TARGET(f DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/f.c)
AFAICS, the crux is the DEPENDS clause of ADD_CUSTOM_COMMAND():
Followed by a relative path, it refers to CMAKE_CURRENT_BINARY_DIR,
but the custom command is attached to the custom target f, and this
is built in CMAKE_BINARY_DIR without having its prerequisites adapted.
Look into subdir/CMakeFiles/f.dir/build.make; the dependency line of
interest is subdir/f.c: subdir/f.c.in which is perfect in CMAKE_
BINARY_DIR. Change the DEPENDS clause to DEPENDS f.c.in, and the
dependency line becomes subdir/f.c: ../subdir/f.c.in, i.e. Make's
target (f.c) is relative to CMAKE_BINARY_DIR, but the prerequisite
(f.c.in) is relative to CMAKE_CURRENT_BINARY_DIR, or CMAKE_BINARY_
DIR/subdir. Of course, this can't work and might even be considered
as a CMake bug, but the interpretation of the DEPENDS clause w.r.t.
relative paths isn't documented - as opposed to the OUTPUT clause -
so you should always use full paths here when in doubt.
There's another somewhat subtle pitfall revealed by the above-noted
example: During the inital configuration, ADD_EXECUTABLE() searches
${CMAKE_BINARY_DIR}/subdir/f.c, doesn't find it because it doesn't
exist yet, but stumbles over the f.c.in template - and is content
since .in is a valid suffix. However, an .in file is useless
for a C project on *nix, and so it's ignored. This results in the
quite funny situation that f.c is regenerated each time f.c.in is
touched - as you desired - but it's not compiled and, thus, not
incorporated in the main target's executable. That's the reason
for explicitly setting the GENERATED property on f.c what's not
necessary for the OUTPUT files of a custom command in the same
CMakeLists.txt. Change f.c.in's suffix to .template, e.g., and
you will see that the GENERATED property is actually necessary
as the property imposed automatically by ADD_CUSTOM_COMMAND()
is valid in the respective CMakeLists.txt file only; see the
documentation of SET_SOURCE_FILES_PROPERTIES().
'hope that helps. If not, please boil down your problem to a
minimal but self-contained example which demonstrates the
issue and can be posted here for further investigation.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
[CMake] Issue w/ myproj-targets-buildtype.cmake not being generated.
Hello,
I have code like the following in my CMakeLists.txt file to make it
simpler to import code from a library.
install(TARGETS ${PROJECT_NAME} DESTINATION
${CMAKE_CURRENT_SOURCE_DIR}/../lib/${BUILD_TYPE_GNU_ONLY} EXPORT
${PROJECT_NAME}-targets)
install(EXPORT ${PROJECT_NAME}-targets DESTINATION
${CMAKE_CURRENT_SOURCE_DIR}/../lib/${BUILD_TYPE_GNU_ONLY})
The problem I have, is that for one project, it creates the files:
myproja-targets.cmake
myproja-targets-buildtype.cmake
However, the same lines of code in a different project only produces
myprojb-targets.cmake
And when myprojc tries to use myprojb via:
include(${CMAKE_CURRENT_SOURCE_DIR}/../myprojb/lib/${BUILD_TYPE_GNU_ONLY}/myprojb-targets.cmake)
It fails, however the same line above modified for myproja succeeds
As a note, the lib files for myproja and myprojb are both created and
installed as expected.
During writing this, I discovered a minor discrepancy in the install
outputs, the one that succeeds, has this:
-- Install configuration: build type
However, the one that fails has:
-- Install configuration:
The interesting thing to me is that I did not specify the build type in
a different way, both CMakeLists.txt include a file that sets
CMAKE_BUILD_TYPE automatically if not specified on the cmd line.
Any suggestions?
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] Custom install target
On 10/06/2011 08:23 AM, ycollette.nos...@free.fr wrote:
Hello,
I would like to create a custom install target: install-update
The things done by this target are:
- change CMAKE_INSTALL_PREFIX to a specific directory:
CMAKE_BINARY_PREFIX/PROJECT_NAME-REVISION_NUMBER
- run make install
I don't know how to launch a defined target from within cmake. Is there any
simple solution to do that ?
Best regards,
YC
Look at the attached exemplary CMakeLists.txt file. However, note that
- changing the CMAKE_INSTALL_PREFIX means invalidating the build tree,
so the whole project is built anew when install-update is triggered,
- triggering install-update means rebuilding *and* installing, so you
possibly need root privileges for this to succeed; building as root
is inadvisable, so you should perhaps limit yourself to a target
build-update without the install step and run make install
in the end as usual.
'hope that helps.
Regards,
Michael
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INSTALLUPDATE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_BINARY_PREFIX /dev/shm CACHE STRING )
SET(REVISION_NUMBER 0 CACHE STRING )
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
INSTALL(TARGETS main DESTINATION bin)
ADD_CUSTOM_TARGET(install-update
COMMAND ${CMAKE_COMMAND}
-DCMAKE_INSTALL_PREFIX=${CMAKE_BINARY_PREFIX}/${PROJECT_NAME}-${REVISION_NUMBER}
${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target install
--config $CONFIGURATION)
--
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] Issue w/ myproj-targets-buildtype.cmake not being generated.
On 10/6/2011 7:04 PM, Raindog wrote:
Hello,
I have code like the following in my CMakeLists.txt file to make it
simpler to import code from a library.
install(TARGETS ${PROJECT_NAME} DESTINATION
${CMAKE_CURRENT_SOURCE_DIR}/../lib/${BUILD_TYPE_GNU_ONLY} EXPORT
${PROJECT_NAME}-targets)
install(EXPORT ${PROJECT_NAME}-targets DESTINATION
${CMAKE_CURRENT_SOURCE_DIR}/../lib/${BUILD_TYPE_GNU_ONLY})
The problem I have, is that for one project, it creates the files:
myproja-targets.cmake
myproja-targets-buildtype.cmake
However, the same lines of code in a different project only produces
myprojb-targets.cmake
And when myprojc tries to use myprojb via:
include(${CMAKE_CURRENT_SOURCE_DIR}/../myprojb/lib/${BUILD_TYPE_GNU_ONLY}/myprojb-targets.cmake)
It fails, however the same line above modified for myproja succeeds
As a note, the lib files for myproja and myprojb are both created and
installed as expected.
During writing this, I discovered a minor discrepancy in the install
outputs, the one that succeeds, has this:
-- Install configuration: build type
However, the one that fails has:
-- Install configuration:
The interesting thing to me is that I did not specify the build type
in a different way, both CMakeLists.txt include a file that sets
CMAKE_BUILD_TYPE automatically if not specified on the cmd line.
Any suggestions?
Thanks
--
I've made a discovery that if I set the CMAKE_BUILD_TYPE from the
command line when calling cmake, everything works for both projects,
however, myproja still does not require any specification from the
command line, while the 2nd project does. Any suggestions?
--
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] Issue w/ myproj-targets-buildtype.cmake not being generated.
On 10/6/2011 7:56 PM, Raindog wrote:
On 10/6/2011 7:04 PM, Raindog wrote:
Hello,
I have code like the following in my CMakeLists.txt file to make it
simpler to import code from a library.
install(TARGETS ${PROJECT_NAME} DESTINATION
${CMAKE_CURRENT_SOURCE_DIR}/../lib/${BUILD_TYPE_GNU_ONLY} EXPORT
${PROJECT_NAME}-targets)
install(EXPORT ${PROJECT_NAME}-targets DESTINATION
${CMAKE_CURRENT_SOURCE_DIR}/../lib/${BUILD_TYPE_GNU_ONLY})
The problem I have, is that for one project, it creates the files:
myproja-targets.cmake
myproja-targets-buildtype.cmake
However, the same lines of code in a different project only produces
myprojb-targets.cmake
And when myprojc tries to use myprojb via:
include(${CMAKE_CURRENT_SOURCE_DIR}/../myprojb/lib/${BUILD_TYPE_GNU_ONLY}/myprojb-targets.cmake)
It fails, however the same line above modified for myproja succeeds
As a note, the lib files for myproja and myprojb are both created and
installed as expected.
During writing this, I discovered a minor discrepancy in the install
outputs, the one that succeeds, has this:
-- Install configuration: build type
However, the one that fails has:
-- Install configuration:
The interesting thing to me is that I did not specify the build type
in a different way, both CMakeLists.txt include a file that sets
CMAKE_BUILD_TYPE automatically if not specified on the cmd line.
Any suggestions?
Thanks
--
I've made a discovery that if I set the CMAKE_BUILD_TYPE from the
command line when calling cmake, everything works for both projects,
however, myproja still does not require any specification from the
command line, while the 2nd project does. Any suggestions?
Problem solved:
I had the myproja CMakeLists.txt in the same directory as the source:
root/proja/CMakeLists.txt # sets the build type through an included file
For myprojb however it was like this:
root/projb/CMakeLists.txt
root/projb/src/CMakeLists.txt = set the build type here
By the time the 2nd CMakeLists.txt was cracked open, the CMake glue code
had already determined the build type was
--
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
