Re: [cmake-developers] Topic branches in limbo on the stage?
On Wednesday 08 February 2012, David Cole wrote: The stage is intended only for topics that are imminently going to be merged to 'next'... The following CMake topic branches have been on the stage for quite some time without being merged to 'next': UseEnabledLanguagesForDirectoryInformationFileIncludePath | master=0 next=0 I forgot to delete that one, done. qt4-deploy | master=0 next=0 HandleTargetsInCMakeRequiredLibraries | master=0 next=0 I will continue to work on this one in the next days. CPackNSIS-fixIgnore-INCLUDE_TOPLEVEL | master=0 next=0 qt4-deploy-test | master=0 next=0 findblas-bugs | master=0 next=0 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindImageMagick.cmake backwards compatibility
On Monday 30 January 2012, David Cole wrote: ... From your original post: So when ImageMagick is installed everything behaves as always. But if no ImageMagick is installed behaviour was this: find_package(ImageMagick) - ImageMagick_FOUND = TRUE This is simply clearly incorrect, and is one of those changes that deserves to have its backwards compatibility broken. If I were a client of this module, and I had logic that really depended on ImageMagick being found, then it would be broken already in some other way anyhow. I would rather have ImageMagick_FOUND be set correctly than have it be set incorrectly but the same as the last version of CMake. Same for me. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On 2/9/2012 3:45 PM, Alexander Neundorf wrote: Just to make completely sure: the purpose of this target property is *not* that targets linking against a library with this property set should reuse these include dirs, right ? Correct. It's just to allow the directory-level INCLUDE_DIRECTORIES specification to be target-level. Nevertheless, did you already think about how the interface for such a feature could look like (to make sure it fits with this new target property) ? Maybe something like this ? set_target_properties(... PROPERTIES INCLUDE_DIRECTORIES a/ b/ c/ PUBLIC_BUILD_INCLUDE_DIRECTORIES d/ e/ f/ PUBLIC_INSTALL_INCLUDE_DIRECTORIES g/ h/ i/ ) It would have to be possible to separate between include dirs to be used at build time of the library, and include dirs to be used once the library has been installed (similar to the build and install RPATH) ...just to make sure the syntax for the new INCLUDE_DIRECTORIES property is ok and doesn't make problems later on. I think it could work the same way as linking versus LINK_INTERFACE_LIBRARIES. Anyway, this is not a design goal for the current work and the current work's interface is a natural extension of what is there already. -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] target_include_directories branch in stage
On Thu, Feb 9, 2012 at 3:45 PM, Alexander Neundorf neund...@kde.org wrote: On Monday 30 January 2012, Stephen Kelly wrote: David Cole wrote: On Sun, Jan 29, 2012 at 11:44 AM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: OK... nearly complete now. Please review, then reply and tell me if you object to any of the 7 commits in this topic branch. No objections. They all seem fine. Great, thanks. Steve, I've preserved your authorship for most of these commits, but have significantly re-written some of them. The 3 following 073bc421620e25fef6389b0d8b71cfad8ca79786 (CMake: Eliminate cmMakefile::IncludeDirectories) seem to have been substantially re-written. I'm not sure what is the appropriate way to deal with commits like that, but whatever you choose for the author line is fine. So I guess the question is: if somebody looks up the author at some point in the future and comes asking a question, do you want to be the one they go to, or would you rather have them come to me? ;-) If you want to send them to me, I'll change the author line, but you certainly deserve the credit for getting the ball rolling on this topic. Ok, let's leave it as-is and I'll take responsibility (blame/credit) :) snip - double-check with Alex about the changes in cmake::FindPackage -- Alex? Still pending. Sorry that it took so long, I was really busy the last few weeks. I cloned this repo: git clone https://github.com/dlrdave/CMake.git Both the Eclipse generator and cmake --find-package work fine. Excellent : thanks very much for trying it out. I'll try to get this first draft merged to 'next' tonight or tomorrow. Just to make completely sure: the purpose of this target property is *not* that targets linking against a library with this property set should reuse these include dirs, right ? Nevertheless, did you already think about how the interface for such a feature could look like (to make sure it fits with this new target property) ? Maybe something like this ? set_target_properties(... PROPERTIES INCLUDE_DIRECTORIES a/ b/ c/ PUBLIC_BUILD_INCLUDE_DIRECTORIES d/ e/ f/ PUBLIC_INSTALL_INCLUDE_DIRECTORIES g/ h/ i/ ) It would have to be possible to separate between include dirs to be used at build time of the library, and include dirs to be used once the library has been installed (similar to the build and install RPATH) ...just to make sure the syntax for the new INCLUDE_DIRECTORIES property is ok and doesn't make problems later on. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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 0012953]: Make sure argument passed to CTest are not modified
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12953 == Reported By:Jean-Christophe Fillion-Robin Assigned To: == Project:CMake Issue ID: 12953 Category: CTest Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-02-09 18:38 EST Last Modified: 2012-02-09 18:38 EST == Summary:Make sure argument passed to CTest are not modified Description: In the steps to reproduce, we can read: Reading Script: /home/jchris/Projects/sandbox/foo.cmake,url##http:/cmake.org whereas the following is expected: Reading Script: /home/jchris/Projects/sandbox/foo.cmake,url##http://cmake.org It seems the problem occurs in cmCTestScriptHandler line 186. Calling CollapseFullPath on the string /path/to/ctestscript.cmake,arguments probably causes the arguments to be modified. See http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestScriptHandler.cxx;h=5841b8d42bd3873ccdbeaee25349b103bf89eb18;hb=HEAD#l186 Steps to Reproduce: jchris@karakoram:~/Projects/sandbox $ ctest -S foo.cmake,url##http://cmake.org -VV * Extra verbosity turned on Reading Script: /home/jchris/Projects/sandbox/foo.cmake,url##http:/cmake.org CMake Error: Cannot find file: /home/jchris/Projects/sandbox/foo.cmake == Issue History Date ModifiedUsername FieldChange == 2012-02-09 18:38 Jean-Christophe Fillion-RobinNew 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] How to use CMake with icc via configuration options when needing interprocedural optimization?
On 02/07/2012 02:43 PM, janitor 048 wrote:
Hello,
this is a question I recently asked on stackoverflow (
http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-with-icc-via-configuration-options)
but that has not received any response since then. Maybe this mailing list
is a better place to ask... Here goes
I would like to use the Intel compiler icc (or icpc) with a CMake-based
project (on Linux for what it's worth). I can of course export the CXX
variable when calling cmake, e.g. like
CXX=icpc cmake ../
and this works fine. I would however like to make this choice available via
a custom option. For this I parse custom option, e.g.
cmake -DMY_COMPILER_OPTION=Intel ..
as
IF (MY_COMPILER_OPTION STREQUAL Intel)
MESSAGE(STATUS ** Compiling with Intel settings **)
SET(CMAKE_CXX_COMPILER icpc)
SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w)
SET(CMAKE_CXX_FLAGS_DEBUG -g)
ENDIF ()
and set CMAKE_CXX_COMPILER together with some compiler flags. This also
works, however there is an important but.
I would also like to use the option -ipo (interprocedural optimization) for
my code when compiling with icc plus I need to compile a static library
within the build process. For this to work, I need to use Intel's xiar (and
also xilink I guess).
cmake actually offers a special property for this
set_property(TARGET mytarget PROPERTY INTERPROCEDURAL_OPTIMIZATION 1)
however this only seems to works properly when the compiler has been set
via the environment variable (then xiar is used). When setting the compiler
via CMAKE_CXX_COMPILER this property is ignored.
Is there another way to do this?. Some recommended way? Or at least a
work-around?
If it actually works well when the compiler is specified via the
respective environment variable, you might try the following:
IF (MY_COMPILER_OPTION STREQUAL Intel)
MESSAGE(STATUS ** Compiling with Intel settings **)
SET(ENV{CXX} icpc)
SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w)
SET(CMAKE_CXX_FLAGS_DEBUG -g)
ENDIF ()
However, note that you must do this *before* the language is enabled,
i.e. before the PROJECT() or ENABLE_LANGUAGE() commands. Note further
that this can be done only for the *initial* configuration of a build
tree; afterwards, the compiler can't be changed anymore. In order to
make that approach more robust, you might consider some refinements:
IF (MY_COMPILER_OPTION STREQUAL Intel)
FIND_PROGRAM(ICPC_PROGRAM icpc ...)
IF(ICPC_PROGRAM)
MESSAGE(STATUS ** Compiling with Intel settings **)
IF(ENV{CXX})
MESSAGE(WARNING Overwriting CXX envvar)
ENDIF()
SET(ENV{CXX} ${ICPC_PROGRAM})
SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w)
SET(CMAKE_CXX_FLAGS_DEBUG -g)
ELSE()
MESSAGE(FATAL_ERROR Intel compiler not found)
ENDIF()
ENDIF ()
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] Making a variable a dependency...
On 02/08/2012 11:13 PM, Oliver kfsone Smith wrote:
Michael Hertling said the following on 2/6/2012 6:39 PM:
On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
On Saturday 04 February 2012, Oliver Smith wrote:
My CMakeLists uses the Subversion repository information in a couple of
places (it configures a file revision.h and it uses it for the CPack
package name).
The problem is that this variable is cached and retained until the cache
is rebuilt, instead of being calculated or evaluated per make. So if I
do a build, then do an svn update and pull some changes, it will build a
new executable but it will stamp it with the revision number from when
CMake last regenerated the make files...
Is there a way to mark a variable as volatile or something so that CMake
will always recalculate it and check if it has changed?
Would it be acceptable if cmake would rerun after every build ?
You could enforce that e.g. with a add_custom_command( POST_BUILD ... )
which
could e.g. touch CMakeCache.txt or something.
Better ideas ?
Delay the generation of the revision.h header until build phase
via a custom command; look at the following exemplary project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT dummy revision.h
COMMAND ${CMAKE_COMMAND}
-DBD=${CMAKE_BINARY_DIR}
-DWC=${CMAKE_SOURCE_DIR}
-P ${CMAKE_SOURCE_DIR}/revision.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#includestdio.h
#include \revision.h\
int main(void)
{
printf(\%d\\n\,REVISION); return 0;
}
)
ADD_EXECUTABLE(main main.c revision.h)
# revision.cmake:
FIND_PACKAGE(Subversion)
Subversion_WC_INFO(${WC}@HEAD P)
FILE(WRITE ${BD}/revision.h.in #define REVISION @P_WC_REVISION@\n)
CONFIGURE_FILE(${BD}/revision.h.in ${BD}/revision.h @ONLY)
A make run rebuilds the main target whenever the repository's head
revision has changed - possibly inappropriate for actual usage, just
for demonstration purposes; adapt the revision.cmake script to suit
the needs.
BTW, can anybody confirm that the above-noted example doesn't work
if the order of dummy and revision.h in the custom command is
reversed? AFAICS, revision.h is removed after being generated in
this case, so the subsequent compilation fails.
Unless I'm missing something, that won't work because P_WC_REVISION gets
cached in the CMakeCache.txt -- or does using -P cause it to skip the
caching?
That's exactly the point: CMake scripts launched by cmake -P don't
have access to the cache - refer to the manual - so you can use the
services of FindSubversion.cmake without bothering whether variables
might be stuck in the cache or not. Try the example from my previous
reply and you'll see that P_WC_REVISION doesn't even show up in the
cache at all.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] source_group and Xcode
Hi,
I'm currently developing an app, and it's sources are divided into
subfolders. It seems that when I do:
add_executable(app ${sources} ${headers})
In my Xcode I can see two folders (Source files and Header files)
However, when I group sources in a subfolder with
source_group(folder ${subset_of_sources} ${subset_of_headers})
they're no longer divided into those folders.
I'd like them also to be separated into Source files and Header files
folder.
What should I do?
--
Some information about me: about.me/fran.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please 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] MSBuild and automatic project file regenation
On 01/13/2012 08:02 PM, Michael Hertling wrote:
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I assume
something really changed and there really needs to be a rebuild? What
type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER); return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
Regards,
Michael
Any findings w.r.t. this issue? Can anyone reproduce it? Is it actually
faulty behavior, possibly worth a bug report? If so, can it be fixed in
some way? David Cole mentioned something like that. Although this isn't
really disastrous, it would be quite nice if everything is up-to-date
after a cmake --build . command, as one is used to with Makefiles.
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] MSBuild and automatic project file regenation
I tried this out. The short story is that it works the way he states.
Changing the CMakeLists.txt cause CMake to rerun the ZERO_CHECK but the
executable generates a 0. Running the build again doesn't change
anything. Here is the transcript of the run:
-8-
---
c:\dev2\TestProgs\CMake_Rebuild\b3cmake --version
cmake version 2.8.7
c:\dev2\TestProgs\CMake_Rebuild\b3cat ..\CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER);
return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES COMPILE_DEFINITIONS NUMBER=0)
c:\dev2\TestProgs\CMake_Rebuild\b3cmake -G Visual Studio 9 2008 ..
-- Check for working C compiler using: Visual Studio 9 2008
-- Check for working C compiler using: Visual Studio 9 2008 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/dev2/TestProgs/CMake_Rebuild/b3
c:\dev2\TestProgs\CMake_Rebuild\b3cat ..\CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER);
return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES COMPILE_DEFINITIONS NUMBER=1)
c:\dev2\TestProgs\CMake_Rebuild\b3cmake --build .
Microsoft (R) Visual Studio Version 9.0.30729.1.
Copyright (C) Microsoft Corp. All rights reserved.
1-- Build started: Project: ZERO_CHECK, Configuration: Debug Win32
--
1Checking Build System
1CMake is re-running because
C:/dev2/TestProgs/CMake_Rebuild/b3/CMakeFiles/generate.stamp is
out-of-date.
1 the file 'C:/dev2/TestProgs/CMake_Rebuild/CMakeLists.txt'
1 is newer than
'C:/dev2/TestProgs/CMake_Rebuild/b3/CMakeFiles/generate.stamp.depend'
1 result='-1'
1-- Configuring done
1-- Generating done
1-- Build files have been written to:
C:/dev2/TestProgs/CMake_Rebuild/b3
1Build log was saved at
file://c:\dev2\TestProgs\CMake_Rebuild\b3\ZERO_CHECK.dir\Debug\BuildLog
.htm
1ZERO_CHECK - 0 error(s), 0 warning(s)
2-- Build started: Project: main, Configuration: Debug Win32 --
2Compiling...
2main.c
2Compiling manifest to resources...
2Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
2Copyright (C) Microsoft Corporation. All rights reserved.
2Linking...
2Embedding manifest...
2Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
2Copyright (C) Microsoft Corporation. All rights reserved.
2Build log was saved at
file://c:\dev2\TestProgs\CMake_Rebuild\b3\main.dir\Debug\BuildLog.htm
2main - 0 error(s), 0 warning(s)
== Build: 2 succeeded, 0 failed, 1 up-to-date, 0 skipped
==
c:\dev2\TestProgs\CMake_Rebuild\b3Debug\main.exe
0
c:\dev2\TestProgs\CMake_Rebuild\b3cmake --build .
Microsoft (R) Visual Studio Version 9.0.30729.1.
Copyright (C) Microsoft Corp. All rights reserved.
== Build: 0 succeeded, 0 failed, 3 up-to-date, 0 skipped
==
c:\dev2\TestProgs\CMake_Rebuild\b3Debug\main.exe
0
-8-
---
I tried this first with a 2.8.4 version I had installed on that box
(older dev box here at work that still had vs2008 on it had 2.8.4
installed). Here is its transcript:
-8-
---
c:\dev2\TestProgs\CMake_Rebuild\bcmake --version
cmake version 2.8.4
c:\dev2\TestProgs\CMake_Rebuild\bcat ..\CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER);
return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES COMPILE_DEFINITIONS NUMBER=0)
c:\dev2\TestProgs\CMake_Rebuild\bcmake ..
-- Building for: NMake Makefiles
-- The C compiler identification is MSVC
-- Check for CL compiler version
-- Check for CL compiler version - 1500
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check for working C compiler: c:/Program Files (x86)/Microsoft Visual
Studio 9.0/VC/bin/cl.exe
-- Check for working C compiler: c:/Program Files (x86)/Microsoft Visual
Studio 9.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/dev2/TestProgs/CMake_Rebuild/b
c:\dev2\TestProgs\CMake_Rebuild\bcat ..\CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER);
return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES COMPILE_DEFINITIONS NUMBER=1)
c:\dev2\TestProgs\CMake_Rebuild\bcmake --build .
-- Configuring done
-- Generating done
-- Build
Re: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
Yuri, Your suggestion is close to what I’m looking for. What I need is a easy way to not this as the “Startup Project” , I need to change the property of the INSTALL target itself. By default, the INSTALL target is not in the “all” or if you open the properties on the Solution , you will find the “Build” selection for INSTALL is not selected. I’m trying to avoid changing Cmake’s C++ for this issue, even for an optional setting. It’s not a great practice to try to run INSTALL no matter what but, I’m getting a strong opinion from users that traditionally work under Visual Studio only stating it’s Ok to run INSTALL and just watch over build errors. ++David-Bjornbak; From: Yuri Timenkov [mailto:y...@timenkov.ru] Sent: Wednesday, February 08, 2012 7:27 PM To: BJORNBAK,DAVID (A-Sonoma,ex1) Cc: cmake@cmake.org Subject: Re: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I use a special macro for such purposes, something like this: Sub Install() Dim prj As Project Dim sb As SolutionBuild = DTE.Solution.SolutionBuild Dim prjs As Projects = DTE.Solution.Projects For Each prj In prjs If prj.Name = INSTALL Then sb.BuildProject(sb.ActiveConfiguration.Namehttp://sb.ActiveConfiguration.Name, prj.UniqueName) Exit For End If Next End Sub Good thing is that you can put it on toolbar or bind to hot key and run it separately (while keeping active project you're debugging). On Tue, Feb 7, 2012 at 11:47 PM, david_bjorn...@agilent.commailto:david_bjorn...@agilent.com wrote: Developers on our team have found issues with the difference between “INSTALL” and the default build or “F7” build all under Visual Studio. My question is, there’s a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit “F7” or use the default “Build Solution” functionality to run INSTALL. We’re working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you’re building the entire project. However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or “F7” and the build finishes and they forget to run “INSTALL”.Particularly we, had developers that worked formally on smaller non-Cmake Visual Studio projects and not Linux so, they’re not used to the make all and then make install defacto standard. This request is similar as the following on “Selecting INSTALL target in Visual Studio Configuration by default” but, I wanted to see if anyone had any other suggestions on this topic. http://www.cmake.org/pipermail/cmake/2011-April/044025.html ++David-Bjornbak; -- Powered by www.kitware.comhttp://www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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] MSBuild and automatic project file regenation
I took a look at this, and it is behaving as expected with VS. VS does
NOT have a depend on compile flags. You can change a .vcproj file and
the flags it uses all you want, and VS will NOT rebuild any files
because of that.
So, as far as VS is concerned your source file has not changed and does
not need to rebuild. I modified your example and --build works
perfectly (I change the NUMBER in the CMakeLists.txt and main is rebuilt
with one invocation of cmake --build .)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h
#include main.h
int main(void)
{
printf(\%d\\n\,NUMBER);
return 0;
}
)
include_directories(${CMAKE_BINARY_DIR})
ADD_EXECUTABLE(main main.c)
set(NUMBER 2)
configure_file(main.h.in main.h)
$ cat ../main.h.in
#define NUMBER @NUMBER@
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please 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] PARENT_SCOPE for unset()?
It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? - 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] PARENT_SCOPE for unset()?
On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. 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] PARENT_SCOPE for unset()?
On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf a.neundorf-w...@gmx.netwrote: On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. 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 Does: set(var PARENT_SCOPE) have the intended effect? (If so, you could use that until such time as PARENT_SCOPE is added to unset.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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] PARENT_SCOPE for unset()?
I didn't try that because I thought it would actually treat PARENT_SCOPE as a string and add it to the variable. I did this instead: set( var PARENT_SCOPE ) - Robert Dailey On Thu, Feb 9, 2012 at 1:26 PM, David Cole david.c...@kitware.com wrote: On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. 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 Does: set(var PARENT_SCOPE) have the intended effect? (If so, you could use that until such time as PARENT_SCOPE is added to unset.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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] PARENT_SCOPE for unset()?
On Thu, Feb 9, 2012 at 2:41 PM, Robert Dailey rcdai...@gmail.com wrote: I didn't try that because I thought it would actually treat PARENT_SCOPE as a string and add it to the variable. I did this instead: set( var PARENT_SCOPE ) That leaves it set, with a value of the empty string, in the parent scope. Give the one I sent a try. - Robert Dailey On Thu, Feb 9, 2012 at 1:26 PM, David Cole david.c...@kitware.com wrote: On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. 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 Does: set(var PARENT_SCOPE) have the intended effect? (If so, you could use that until such time as PARENT_SCOPE is added to unset.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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] CMake presentation/tutorial in Toulouse/France (8th February)
2012/1/29 Eric Noulard eric.noul...@gmail.com: Hi All, Just a small advertisement. I will be giving a CMake presentation tutorial in Toulouse/France on February 8th, 2012: http://www.toulibre.org/evenements_a_venir À 20h00 Éric Noulard présentera CMake, outil de compilation et de test multi-plateforme. Presentation will be given in French. This is done and it was nice (at least from my side) The slides (in english) are here: http://noulard.name/CMake/CMake-tutorial-8feb2012.pdf The material I used for making the presentation is available here: http://noulard.name/CMake/CMake-tutorial-8feb2012.tar.bz2 and may be cloned/forked from github as well: https://github.com/TheErk/CMake-tutorial feel free to re-use/improve it. -- 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] CMake presentation/tutorial in Toulouse/France (8thFebruary)
I went through the slides; pretty good introduction-intermediate presentation. I'm forwarding it to all the teams I work with here! Aaron Meadows -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Eric Noulard Sent: Thursday, February 09, 2012 3:26 PM To: CMake ML Subject: Re: [CMake] CMake presentation/tutorial in Toulouse/France (8thFebruary) 2012/1/29 Eric Noulard eric.noul...@gmail.com: Hi All, Just a small advertisement. I will be giving a CMake presentation tutorial in Toulouse/France on February 8th, 2012: http://www.toulibre.org/evenements_a_venir À 20h00 Éric Noulard présentera CMake, outil de compilation et de test multi-plateforme. Presentation will be given in French. This is done and it was nice (at least from my side) The slides (in english) are here: http://noulard.name/CMake/CMake-tutorial-8feb2012.pdf The material I used for making the presentation is available here: http://noulard.name/CMake/CMake-tutorial-8feb2012.tar.bz2 and may be cloned/forked from github as well: https://github.com/TheErk/CMake-tutorial feel free to re-use/improve it. -- 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 This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PARENT_SCOPE for unset()?
That worked, thanks David. I guess CMake goes right-to-left for function parameters? I don't see how else it doesn't think PARENT_SCOPE is a value instead of an option. - Robert Dailey On Thu, Feb 9, 2012 at 1:45 PM, David Cole david.c...@kitware.com wrote: On Thu, Feb 9, 2012 at 2:41 PM, Robert Dailey rcdai...@gmail.com wrote: I didn't try that because I thought it would actually treat PARENT_SCOPE as a string and add it to the variable. I did this instead: set( var PARENT_SCOPE ) That leaves it set, with a value of the empty string, in the parent scope. Give the one I sent a try. - Robert Dailey On Thu, Feb 9, 2012 at 1:26 PM, David Cole david.c...@kitware.comwrote: On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. 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 Does: set(var PARENT_SCOPE) have the intended effect? (If so, you could use that until such time as PARENT_SCOPE is added to unset.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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] PARENT_SCOPE for unset()?
Yes, PARENT_SCOPE must occur as the last argument. Each command has its own code for processing its argument list. See Source/cmSetCommand.cxx for details on this one. Interesting (not quite the right adjective?) side effect: it's difficult to set a variable to the value PARENT_SCOPE because you have to do it indirectly... On Thu, Feb 9, 2012 at 7:12 PM, Robert Dailey rcdai...@gmail.com wrote: That worked, thanks David. I guess CMake goes right-to-left for function parameters? I don't see how else it doesn't think PARENT_SCOPE is a value instead of an option. - Robert Dailey On Thu, Feb 9, 2012 at 1:45 PM, David Cole david.c...@kitware.com wrote: On Thu, Feb 9, 2012 at 2:41 PM, Robert Dailey rcdai...@gmail.com wrote: I didn't try that because I thought it would actually treat PARENT_SCOPE as a string and add it to the variable. I did this instead: set( var PARENT_SCOPE ) That leaves it set, with a value of the empty string, in the parent scope. Give the one I sent a try. - Robert Dailey On Thu, Feb 9, 2012 at 1:26 PM, David Cole david.c...@kitware.comwrote: On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. 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 Does: set(var PARENT_SCOPE) have the intended effect? (If so, you could use that until such time as PARENT_SCOPE is added to unset.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
I dug into CMake’s C++ code and found there’s a generic setting named
EXCLUDE_FROM_ALL that most “targets” use to decide if a project should be under
the default build but, there’s particular target type named “GLOBAL_TARGET”
does use this setting and it’s always excluded from all.
Based on what I’m reading in the CMake’s C++, the safest place to make a
optional change is right at the point where it’s generating Visual Studio
files. The other logic spot in in a function
cmGlobalGenerator::CreateGlobalTarget but, changes here will create a larger
ripple effect on what will most likely go wrong with this type of tinkering.
The following is the spot in the code I have in mind changing and picking up
both an optional setting and the current “target name” being “INSTALL”
Let me know if there’s a better way to allow Visual Studio developers to hit
“F7” and have the “INSTALL” target/vs project run for them. This current C++
will be a private patch for my team but, I prefer if we can have a more public
optional setting for this request.
bool cmGlobalVisualStudio7Generator::IsPartOfDefaultBuild(const char* project,
cmTarget* target)
{
if(target-GetPropertyAsBool(EXCLUDE_FROM_DEFAULT_BUILD))
{
return false;
}
// if it is a utilitiy target then only make it part of the
// default build if another target depends on it
int type = target-GetType();
if (type == cmTarget::GLOBAL_TARGET)
{
return false;
}
if(type == cmTarget::UTILITY)
{
return this-IsDependedOn(project, target);
}
// default is to be part of the build
return true;
}
The return false after type == cmTarget::GLOBAL_TARGET will become
if ( strcmp(target-GetName(),INSTALL) == 0SOME_OPTIONAL_SETTING )
return true;
else
return false;
}
++David-Bjornbak;
From: Yuri Timenkov [mailto:y...@timenkov.ru]
Sent: Wednesday, February 08, 2012 7:27 PM
To: BJORNBAK,DAVID (A-Sonoma,ex1)
Cc: cmake@cmake.org
Subject: Re: [CMake] Under Visual Studio , allow developers to hit F7 to run
the INSTALL target
I use a special macro for such purposes, something like this:
Sub Install()
Dim prj As Project
Dim sb As SolutionBuild = DTE.Solution.SolutionBuild
Dim prjs As Projects = DTE.Solution.Projects
For Each prj In prjs
If prj.Name = INSTALL Then
sb.BuildProject(sb.ActiveConfiguration.Namehttp://sb.ActiveConfiguration.Name,
prj.UniqueName)
Exit For
End If
Next
End Sub
Good thing is that you can put it on toolbar or bind to hot key and run it
separately (while keeping active project you're debugging).
On Tue, Feb 7, 2012 at 11:47 PM,
david_bjorn...@agilent.commailto:david_bjorn...@agilent.com wrote:
Developers on our team have found issues with the difference between “INSTALL”
and the default build or “F7” build all under Visual Studio. My question is,
there’s a reasonable way to configure cmake or Visual Studio to run the INSTALL
target when you hit “F7” or use the default “Build Solution” functionality to
run INSTALL.
We’re working a fairly large project and the default setting of having INSTALL
dependent on ALL or separating out the two targets makes sense when you’re
building the entire project.
However, we allow developers to build sub projects and it makes sense if these
sub project just install quickly into a larger pre-built installation
directory. The confusion currently is, they run ALL_BUILD or “F7” and the
build finishes and they forget to run “INSTALL”.Particularly we, had
developers that worked formally on smaller non-Cmake Visual Studio projects and
not Linux so, they’re not used to the make all and then make install defacto
standard.
This request is similar as the following on “Selecting INSTALL target in Visual
Studio Configuration by default” but, I wanted to see if anyone had any other
suggestions on this topic.
http://www.cmake.org/pipermail/cmake/2011-April/044025.html
++David-Bjornbak;
--
Powered by www.kitware.comhttp://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please 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] Copying Files into build-dir under Visual Studio vs. Codeblocks/Win32 vs. Codeblocks/Linux
Hi,
I'm (still) quite unsure if this isn't an FAQ (or if not maybe should be
one), but I have read through everything I could google-up regarding
this topic and found nothing usable...
I'm writing an x-platform-project which will be compiled using different
compilers and or under different systems... for this project I am
required to move some files from some location (source/data) into the
build-directory. Whileas this works under Linux/Codeblocks/GCC as well
as Windows/Codeblocks/MinGW it doesn't for Visual Studio... Under Visual
Studio the files always are copied to some directory-location directly
above the actual binary-directory.
I've tried using ${CMAKE_CURRENT_BINARY} and it copies the files to the
marked position:
build/--- copies into this directory
build/Debug
build/Release
build/source
After that I tried to do it with GET_TARGET_PROPERTY(... PROPERTY
LOCATION). I then get something like this...
'build/$(Configuration)'
...which of course doesn't solve the problem, too... because the
configuration under Visual Studio is only known after CMake-Generation
of the solution and running the compiler...
So, what is the suggested method of (if you can't avoid it) copying
files from anywhere into the build-directory, which is as compiler
agnostic as possible..?
best regards,
Stefan
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please 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.7-2545-ga80db80
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 a80db8077fe31f2be8692bcf145db0a7d69a9e8b (commit) via 0e70bfb68c6baeb9c4731096902c248915405059 (commit) from 956accd7bebb5af1f967dba032e3103eb84c025e (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=a80db8077fe31f2be8692bcf145db0a7d69a9e8b commit a80db8077fe31f2be8692bcf145db0a7d69a9e8b Merge: 956accd 0e70bfb Author: Rolf Eike Beer e...@sf-mail.de AuthorDate: Thu Feb 9 12:34:21 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 9 12:34:21 2012 -0500 Merge topic 'improve-findopenmp' into next 0e70bfb FindOpenMP: add a default flag for MIPSpro compiler http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e70bfb68c6baeb9c4731096902c248915405059 commit 0e70bfb68c6baeb9c4731096902c248915405059 Author: Rolf Eike Beer e...@sf-mail.de AuthorDate: Thu Feb 9 18:33:38 2012 +0100 Commit: Rolf Eike Beer e...@sf-mail.de CommitDate: Thu Feb 9 18:33:38 2012 +0100 FindOpenMP: add a default flag for MIPSpro compiler diff --git a/Modules/FindOpenMP.cmake b/Modules/FindOpenMP.cmake index cbd002c..9d9fe0d 100644 --- a/Modules/FindOpenMP.cmake +++ b/Modules/FindOpenMP.cmake @@ -64,6 +64,7 @@ function(_OPENMP_FLAG_CANDIDATES LANG) set(OMP_FLAG_SunPro -xopenmp) set(OMP_FLAG_HP +Oopenmp) set(OMP_FLAG_XL -qsmp) + set(OMP_FLAG_MIPSpro -mp) set(OMP_FLAG_PGI -mp) # Move the flag that matches the compiler to the head of the list, --- Summary of changes: Modules/FindOpenMP.cmake |1 + 1 files changed, 1 insertions(+), 0 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.7-2548-g3d606bb
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 3d606bbc5c28a54642cb57e2b2947c0483cf0335 (commit)
via ed14435b232a7e76678716b5a2a6694e7cade66c (commit)
via 16b1a6e4e07b223c7ead20cd40346fc327e90569 (commit)
from a80db8077fe31f2be8692bcf145db0a7d69a9e8b (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=3d606bbc5c28a54642cb57e2b2947c0483cf0335
commit 3d606bbc5c28a54642cb57e2b2947c0483cf0335
Merge: a80db80 ed14435
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 9 14:31:54 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 9 14:31:54 2012 -0500
Merge topic 'curl-CA-bundle' into next
ed14435 Add CURL_CA_BUNDLE option for SSL support (#12946)
16b1a6e KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed14435b232a7e76678716b5a2a6694e7cade66c
commit ed14435b232a7e76678716b5a2a6694e7cade66c
Author: Artur Kedzierski ar...@kedzierski.org
AuthorDate: Thu Feb 9 09:09:54 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Feb 9 09:09:54 2012 -0500
Add CURL_CA_BUNDLE option for SSL support (#12946)
This adds the ability to specify the location of SSL CA bundle at
compile time.
diff --git a/Utilities/cmcurl/CMakeLists.txt b/Utilities/cmcurl/CMakeLists.txt
index 7030b2e..1d50914 100644
--- a/Utilities/cmcurl/CMakeLists.txt
+++ b/Utilities/cmcurl/CMakeLists.txt
@@ -190,6 +190,11 @@ IF(CMAKE_USE_OPENSSL)
CHECK_LIBRARY_EXISTS_CONCAT(crypto CRYPTO_lock HAVE_LIBCRYPTO)
CHECK_LIBRARY_EXISTS_CONCAT(sslSSL_connect HAVE_LIBSSL)
ENDIF(WIN32)
+ SET(CURL_CA_BUNDLE CACHE FILEPATH Path to SSL CA Certificate Bundle)
+ MARK_AS_ADVANCED(CURL_CA_BUNDLE)
+ IF(CURL_CA_BUNDLE)
+ADD_DEFINITIONS(-DCURL_CA_BUNDLE=${CURL_CA_BUNDLE})
+ ENDIF(CURL_CA_BUNDLE)
ENDIF(CMAKE_USE_OPENSSL)
# Check for idn
---
Summary of changes:
Source/kwsys/kwsysDateStamp.cmake |2 +-
Utilities/cmcurl/CMakeLists.txt |5 +
2 files changed, 6 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.7-2550-gd7510a4
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 d7510a4a4f698fdbe1c951c65ce2392e934bb3ff (commit)
via 9fb9416f78a83c59e1260ec1ec0699618be1b95f (commit)
from 3d606bbc5c28a54642cb57e2b2947c0483cf0335 (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=d7510a4a4f698fdbe1c951c65ce2392e934bb3ff
commit d7510a4a4f698fdbe1c951c65ce2392e934bb3ff
Merge: 3d606bb 9fb9416
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Thu Feb 9 20:36:06 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 9 20:36:06 2012 -0500
Merge topic 'change_qmake_path' into next
9fb9416 Use upgraded qt on linux build machine.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9fb9416f78a83c59e1260ec1ec0699618be1b95f
commit 9fb9416f78a83c59e1260ec1ec0699618be1b95f
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Thu Feb 9 20:33:58 2012 -0500
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Thu Feb 9 20:33:58 2012 -0500
Use upgraded qt on linux build machine.
diff --git a/Utilities/Release/magrathea_release.cmake
b/Utilities/Release/magrathea_release.cmake
index 549460e..1b2ae02 100644
--- a/Utilities/Release/magrathea_release.cmake
+++ b/Utilities/Release/magrathea_release.cmake
@@ -10,7 +10,7 @@ CURSES_INCLUDE_PATH:PATH=/usr/i686-gcc-332s/include/ncurses
FORM_LIBRARY:FILEPATH=/usr/i686-gcc-332s/lib/libform.a
CPACK_SYSTEM_NAME:STRING=Linux-i386
BUILD_QtDialog:BOOL:=TRUE
-QT_QMAKE_EXECUTABLE:FILEPATH=/home/kitware/qt-x11-opensource-src-4.3.3-install/bin/qmake
+QT_QMAKE_EXECUTABLE:FILEPATH=/home/kitware/qt-4.43-install/bin/qmake
)
get_filename_component(path ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${path}/release_cmake.cmake)
---
Summary of changes:
Utilities/Release/magrathea_release.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, master, updated. v2.8.7-308-g0fcf69d
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 0fcf69d72f113a989df43973e05c039e4bbd3d33 (commit) from 16b1a6e4e07b223c7ead20cd40346fc327e90569 (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=0fcf69d72f113a989df43973e05c039e4bbd3d33 commit 0fcf69d72f113a989df43973e05c039e4bbd3d33 Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Feb 10 00:05:05 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Fri Feb 10 00:05:05 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 7b31670..13de8a0 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 02) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 09) +SET(KWSYS_DATE_STAMP_DAY 10) --- 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
