Re: [cmake-developers] Add a new SYSTEM_ONLY mode for CMAKE_FIND_ROOT_PATH
On 08/19/2014 05:43 PM, Chuck Atkins wrote: The new hybrid mode allows the default search location to be re-rooted and any user specified paths to be untouched. This looks useful. However, the current implementation appears to change the order in which each kind of path is generated. The order is very important and cannot be changed. Instead you'll have to refactor the path generation to store a boolean with each value that indicates whether it is to be re-rooted or not. Or, re-arrange the generation to construct separate lists of paths from each source first, and then combine them while re-rooting some. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add a new SYSTEM_ONLY mode for CMAKE_FIND_ROOT_PATH
I was trying to avoid the code duplication but I definitely see your point. I'll refactor. - Chuck On Wed, Aug 20, 2014 at 8:55 AM, Brad King brad.k...@kitware.com wrote: On 08/19/2014 05:43 PM, Chuck Atkins wrote: The new hybrid mode allows the default search location to be re-rooted and any user specified paths to be untouched. This looks useful. However, the current implementation appears to change the order in which each kind of path is generated. The order is very important and cannot be changed. Instead you'll have to refactor the path generation to store a boolean with each value that indicates whether it is to be re-rooted or not. Or, re-arrange the generation to construct separate lists of paths from each source first, and then combine them while re-rooting some. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add a new SYSTEM_ONLY mode for CMAKE_FIND_ROOT_PATH
The branch has been updated on the stage to retain search path order. - Chuck On Wed, Aug 20, 2014 at 9:10 AM, Chuck Atkins chuck.atk...@kitware.com wrote: I was trying to avoid the code duplication but I definitely see your point. I'll refactor. - Chuck On Wed, Aug 20, 2014 at 8:55 AM, Brad King brad.k...@kitware.com wrote: On 08/19/2014 05:43 PM, Chuck Atkins wrote: The new hybrid mode allows the default search location to be re-rooted and any user specified paths to be untouched. This looks useful. However, the current implementation appears to change the order in which each kind of path is generated. The order is very important and cannot be changed. Instead you'll have to refactor the path generation to store a boolean with each value that indicates whether it is to be re-rooted or not. Or, re-arrange the generation to construct separate lists of paths from each source first, and then combine them while re-rooting some. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Collecting libraries for NSIS installer
On Tue, Aug 19, 2014 at 11:40 AM, Hendrik Sattler p...@hendrik-sattler.de wrote: On 19. August 2014 16:36:14 MESZ, David Cole via CMake cmake@cmake.org wrote: Definitely getting warmer! It looks like that GetPrerequistes only works on an existing target so I'm thinking I would have to set this up as a super cmake project after the main project is already built? Right, or as a script that runs at install time. It requires an executable file to analyze, so it can come up with the required DLLs. Actually I wonder why this is needed? If all libraries are linked will full path or via imported targets (those that do it right on windows), why do the binaries have to be checked Yes, the more I look at this the more I realize it's not going to work. The script method is going to install the required libraries, in my case on win32 no one is going to run make install it's instead going to be make package. I guess what I need is a way to translate the import libraries into the runtime dll paths. The .a is easy enough to handle in regex, but in most cases the import library is in /usr/lib and the runtime library is in /usr/bin. Is there a property I can interrogate to get there? Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Collecting libraries for NSIS installer
Yes, the more I look at this the more I realize it's not going to work. The script method is going to install the required libraries, in my case on win32 no one is going to run make install it's instead going to be make package. But make package typically runs make install under the hood... So if you get it to work with make install it should just work with make package. D -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] organizing export link libraries
Hi all, a general question: I have a dependency chain of libraries A - B - C - ... - Z and all of those libraries are built with CMake, using CMake's export functionality [1] to let the next in the chain know about its the dependencies. If all of the libraries are built statically and A needs some symbols from a third-party library A1, this information needs to travel to Z. Right now, in the export file I'm writing out the link line as set(a_EXTRA_LIBS -lhdf5 -lhdf5_hl -ldl -lm -lz -lcurl) and then in B set(b_EXTRA_LIBS some other libs -lhdf5 -lhdf5_hl -ldl -lm -lz -lcurl) and so on. Is that the preferred way to handle this in CMake? Any other recommendations? Cheers, Nico [1] http://www.cmake.org/cmake/help/v3.0/module/CMakePackageConfigHelpers.html -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Variable shadowing between scope, cache and command line argument
On Wednesday, July 30, 2014 14:59:46 Ghyslain Leclerc wrote: Hello, First post here. Sorry if its too long. Simply trying to be as clear as I can be. I am trying to make sense of the various ways to set a variable and how one can shadow the other. Long story short, I am trying to get the following behaviour for a variable in a script: 1 - check if MYVAR exists 1.1 - If it does, test its validity and set a second variable named MYVAR_VALID to TRUE or FALSE 2 - if MYVAR does not exist or if MYVAR_VALID is FALSE, inspect system for information and set MYVAR (with FORCE in the cache) and MYVAR_VALID (not in cache, but does not seem to make a difference). Hope this is written clearly enough to be understood. Sorry, english is not my first language. Anyhow, I get the following behaviour easily except in one case, which is the reason for my question. These are the cases I have tested : - Start with empty cache and call ccmake. Then, MYVAR does not exist. My script inspects the system, sets the value, sets MYVAR_VALID to TRUE and stops. On successive runs, the variable is defined and valid, so the system is not inspected again. Everything is fine. - Start with empty cache. Run it once, but can’t find a valid entry (or find a wrong one somehow, but that’s practically impossible since the code in my script to inspect the system and to test the variable are basically the same. I digress, sorry). Set MYVAR_VALID to FALSE. User can set the value to a valid one and on next run, the script will set MYVAR_VALID to TRUE and then, we are back to variable defined and valid. Everything is fine. - Start with non-empty cache because ccmake (or cmake) is called with -DMYVAR:PATH=/Users/“, for instance. If the value set on command line is fine, then MYVAR_VALID will be set to TRUE on the first run and no system inspection is necessary. The value is now set and valid. Everything is fine. Now, for my problem : - Start with non-empty cache because ccmake (or cmake) is called with -DMYVAR:PATH=/Users/“, for instance. But this time, the value is not a valid one. Then, the variable is defined but not valid. So on the first run, the script will inspect the system. If it can find a valid value, I would like my script to override the variable with the valid one. Then, set to valid and so on and so forth... I have not been able to do this. I can find the correct value, I can set the new value, but it is not used. I mean by that that I have inspected the CMakeCache.txt file and when I call ccmake, the cache contains the value set on the command line. Then, I launch my cmake script and output the values of MYVAR and MYVAR_VALID and they are respectively the one of the command line and FALSE. Then, I find the correct value for MYVAR and try and set it. When I inspect the cache, it seems the value has effectively been overwritten. You are using set(... FORCE), right ? But when I try to output the new variables, it seems to remain stuck at the value provided on the command line. I have tried using unset( MYVAR ) in scope, How do you mean that ? IIRC -DVAR=value sets the cache variable. Not sure, it seems -D maybe also sets the non-cache variable ? Then uset() should have worked. Can you post a small example to reproduce it ? Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Collecting libraries for NSIS installer
Ok, that being the case I tried it out. There's two things I'm doing
differently than the only example[1] I found:
1. Using install(CODE...) instead of install(SCRIPT...), shouldn't work any
differently, right?
2. The example is from 2009 and uses:
GET_TARGET_PROPERTY(MY_BINARY_LOCATION my_binary LOCATION)
Which I get a policy warning about.
I tried using $TARGET_FILE:freedv inside of get_but apparently I'm not
getting how that's supposed to be used.
Here's the whole code block:
if(WIN32)
install(CODE
INCLUDE(GetPrerequisites)
GET_PREREQUISITES($TARGET_FILE:freedv DEPENDENCIES 1 1 \\ \\)
message(\Checking for dependencies in $TARGET_FILE:fredv\)
message(\Dependencies: ${DEPENDENCIES}\)
FOREACH(DEPENDENCY ${DEPENDENCIES})
GET_FILENAME_COMPONENT(DEPENDENCY_NAME \${DEPENDENCY}\ NAME)
GET_FILENAME_COMPONENT(DEPENDENCY_ACTUAL \${DEPENDENCY}\ REALPATH)
message(\DEPENDENCY_NAME: ${DEPENDENCY_NAME}\)
message(\DEPENDENCY_ACTUAL: ${DEPENDENCY_ACTUAL}\)
FILE(INSTALL
DESTINATION bin
TYPE EXECUTABLE
RENAME \${DEPENDENCY_NAME}\
FILES \${DEPENDENCY_ACTUAL}\
)
ENDFOREACH()
)
endif(WIN32)
--- end ---
Ideas?
Thanks,
Richard
[1] http://www.cmake.org/pipermail/cmake/2009-June/029975.html
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
On Tuesday, August 12, 2014 09:06:13 Brad King wrote: ... FYI, the only intended use case for setting a policy to OLD is to quiet warnings in a maintenance branch of an existing release. Some day support for OLD behavior of some policies may be dropped, so all project development moving forward should set the policy to NEW. Fixing a warning may make the project require the newer cmake version. E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0, which generates a warning, a developer using cmake 3.0.0 may see the warning and fix it, but by that he may have broken the build for the required 2.8.10 and actually now 3.0.0 is required. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Collecting libraries for NSIS installer
Ok, short answer to #1, no you can't use install(CODE because all your cmake variables we be evaluated now instead of later. Same problem though when I use install(SCRIPT... Run CPack packaging tool... CPack: Create package using NSIS CPack: Install projects CPack: - Run preinstall target for: FreeDV CPack: - Install project: FreeDV warning: target '$TARGET_FILE:freedv' is not absolute... warning: target '$TARGET_FILE:freedv' does not exist... C:/msys32/mingw32/bin/objdump.exe: '$TARGET_FILE:freedv': No such file Dependencies: Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.0.1-4983-gf13f913
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 f13f913f7cbde7616e2a2fc2209e087967ecba58 (commit)
via f1e9fa3cb6e2ac3f1cd94946a2a71e60950406f8 (commit)
via 22a89b7ab59e4e44c06788578b22905c8753cdb7 (commit)
from 5f774ccb6860d8e48a0e44813c7348c9806ba324 (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=f13f913f7cbde7616e2a2fc2209e087967ecba58
commit f13f913f7cbde7616e2a2fc2209e087967ecba58
Merge: 5f774cc f1e9fa3
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Aug 20 10:04:50 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 20 10:04:50 2014 -0400
Merge topic 'vs-windows-apps' into next
f1e9fa3c VS: Place missing artifacts in per-target intermediate directory
22a89b7a VS: Generate default AppxManifest in a per-target directory
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f1e9fa3cb6e2ac3f1cd94946a2a71e60950406f8
commit f1e9fa3cb6e2ac3f1cd94946a2a71e60950406f8
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Aug 20 09:12:07 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Aug 20 09:57:09 2014 -0400
VS: Place missing artifacts in per-target intermediate directory
Also revise missing file generation code to simplify layout and
encode characters for XML correctly.
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index 0a538d0..a1dd7ab 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -161,6 +161,9 @@ cmVisualStudio10TargetGenerator(cmTarget* target,
this-MSTools = true;
this-BuildFileStream = 0;
this-IsMissingFiles = false;
+ this-DefaultArtifactDir =
+this-Makefile-GetStartOutputDirectory() + std::string(/) +
+this-LocalGenerator-GetTargetDirectory(*this-Target);
}
cmVisualStudio10TargetGenerator::~cmVisualStudio10TargetGenerator()
@@ -2327,9 +2330,12 @@ void
cmVisualStudio10TargetGenerator::WriteWinRTPackageCertificateKeyFile()
this-GlobalGenerator-GetSystemVersion() == 8.0))
{
// Move the manifest to a project directory to avoid clashes
+ std::string artifactDir =
+this-LocalGenerator-GetTargetDirectory(*this-Target);
+ this-ConvertToWindowsSlash(artifactDir);
this-WriteString(PropertyGroup\n, 1);
this-WriteString(AppxPackageArtifactsDir, 2);
- (*this-BuildFileStream) this-Target-GetName()
+ (*this-BuildFileStream) cmVS10EscapeXML(artifactDir)
\\/AppxPackageArtifactsDir\n;
this-WriteString(ProjectPriFullPath
$(TargetDir)resources.pri/ProjectPriFullPath, 2);
@@ -2338,11 +2344,9 @@ void
cmVisualStudio10TargetGenerator::WriteWinRTPackageCertificateKeyFile()
// aren't targeting WP8.0, add a default certificate
if(pfxFile.empty())
{
-std::string baseFolder = this-Makefile-GetStartOutputDirectory() +
- std::string(/) + this-Target-GetName();
std::string templateFolder = cmSystemTools::GetCMakeRoot() +
/Templates/Windows;
-pfxFile = baseFolder + /Windows_TemporaryKey.pfx;
+pfxFile = this-DefaultArtifactDir + /Windows_TemporaryKey.pfx;
cmSystemTools::CopyAFile(templateFolder + /Windows_TemporaryKey.pfx,
pfxFile, false);
this-ConvertToWindowsSlash(pfxFile);
@@ -2518,8 +2522,6 @@ void cmVisualStudio10TargetGenerator::WriteMissingFiles()
void cmVisualStudio10TargetGenerator::WriteMissingFilesWP80()
{
- std::string baseFolder = this-Makefile-GetStartOutputDirectory() +
- std::string(/) + this-Target-GetName();
std::string templateFolder = cmSystemTools::GetCMakeRoot() +
/Templates/Windows;
@@ -2528,248 +2530,250 @@ void
cmVisualStudio10TargetGenerator::WriteMissingFilesWP80()
// folders
std::string manifestFile = this-Makefile-GetStartOutputDirectory() +
std::string(/WMAppManifest.xml);
+ std::string artifactDir =
+this-LocalGenerator-GetTargetDirectory(*this-Target);
+ this-ConvertToWindowsSlash(artifactDir);
+ std::string artifactDirXML = cmVS10EscapeXML(artifactDir);
+ std::string targetNameXML = cmVS10EscapeXML(this-Target-GetName());
cmGeneratedFileStream fout(manifestFile.c_str());
fout.SetCopyIfDifferent(true);
- fout ?xml version=\1.0\ encoding=\utf-8\?\n
- Deployment xmlns=
- \http://schemas.microsoft.com/windowsphone/2012/deployment\;
-
[Cmake-commits] CMake branch, next, updated. v3.0.1-4985-gbc419fa
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 bc419fa05ee44b12ace8db8dd1eab1615eaf82d4 (commit)
via ce40a377935cd05e50230d844f2fe579ef5dfb41 (commit)
from f13f913f7cbde7616e2a2fc2209e087967ecba58 (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=bc419fa05ee44b12ace8db8dd1eab1615eaf82d4
commit bc419fa05ee44b12ace8db8dd1eab1615eaf82d4
Merge: f13f913 ce40a37
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Aug 20 10:19:28 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 20 10:19:28 2014 -0400
Merge topic 'vs-masm' into next
ce40a377 VS: Skip MASM test on MSVC 13.0
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ce40a377935cd05e50230d844f2fe579ef5dfb41
commit ce40a377935cd05e50230d844f2fe579ef5dfb41
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Aug 20 10:19:00 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Aug 20 10:19:00 2014 -0400
VS: Skip MASM test on MSVC 13.0
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 48e1c82..f237f21 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1679,7 +1679,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
list(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/MFC)
endif()
- if(MSVC AND NOT MSVC_VERSION LESS 1300
+ if(MSVC AND NOT MSVC_VERSION LESS 1310
AND NOT CMAKE_GENERATOR MATCHES Visual Studio [6789]( |$))
ADD_TEST_MACRO(VSMASM VSMASM)
endif()
---
Summary of changes:
Tests/CMakeLists.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.1-4987-g6e35477
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 6e354771a8f8a7ec95e878eb658a56800b6c8639 (commit)
via df3b007d7f904f8de5877f3e05b629239af7220a (commit)
from bc419fa05ee44b12ace8db8dd1eab1615eaf82d4 (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=6e354771a8f8a7ec95e878eb658a56800b6c8639
commit 6e354771a8f8a7ec95e878eb658a56800b6c8639
Merge: bc419fa df3b007
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Aug 20 10:20:49 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 20 10:20:49 2014 -0400
Merge topic 'vs-masm' into next
df3b007d VS: Add test for MASM support
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df3b007d7f904f8de5877f3e05b629239af7220a
commit df3b007d7f904f8de5877f3e05b629239af7220a
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Aug 7 14:53:57 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Aug 20 10:19:49 2014 -0400
VS: Add test for MASM support
It is now expected to work with VS = 10 and MSVC = 13.1.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index ca7fcdc..f237f21 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1679,6 +1679,11 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
list(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/MFC)
endif()
+ if(MSVC AND NOT MSVC_VERSION LESS 1310
+ AND NOT CMAKE_GENERATOR MATCHES Visual Studio [6789]( |$))
+ADD_TEST_MACRO(VSMASM VSMASM)
+ endif()
+
if(${CMAKE_GENERATOR} MATCHES Visual Studio)
if(NOT MSVC60)
ADD_TEST_MACRO(SBCS SBCS)
diff --git a/Tests/VSMASM/CMakeLists.txt b/Tests/VSMASM/CMakeLists.txt
new file mode 100644
index 000..f2570a3
--- /dev/null
+++ b/Tests/VSMASM/CMakeLists.txt
@@ -0,0 +1,10 @@
+cmake_minimum_required(VERSION 2.8.12)
+project(VSMASM C ASM_MASM)
+if(CMAKE_SIZEOF_VOID_P EQUAL 8)
+ add_definitions(-DTESTx64)
+else()
+ add_definitions(-DTESTi386)
+ set(CMAKE_ASM_MASM_FLAGS ${CMAKE_ASM_MASM_FLAGS} /safeseh)
+endif()
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)
+add_executable(VSMASM main.c foo.asm)
diff --git a/Tests/VSMASM/foo.asm b/Tests/VSMASM/foo.asm
new file mode 100644
index 000..51cb969
--- /dev/null
+++ b/Tests/VSMASM/foo.asm
@@ -0,0 +1,7 @@
+ifndef TESTx64
+.386
+.model flat, c
+endif
+.code
+include foo-proc.asm
+end
diff --git a/Tests/VSMASM/include/foo-proc.asm
b/Tests/VSMASM/include/foo-proc.asm
new file mode 100644
index 000..e8ba5dc
--- /dev/null
+++ b/Tests/VSMASM/include/foo-proc.asm
@@ -0,0 +1,4 @@
+foo proc public
+ mov eax,0
+ ret
+foo endp
diff --git a/Tests/VSMASM/main.c b/Tests/VSMASM/main.c
new file mode 100644
index 000..570ba16
--- /dev/null
+++ b/Tests/VSMASM/main.c
@@ -0,0 +1,2 @@
+extern int foo(void);
+int main(void) { return foo(); }
---
Summary of changes:
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.1-1735-g16afcca
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 16afccac0542cff1ee440eaa77512ba35223ea78 (commit) via 914db028da1fc488df202a0c8705d1d5a8c258d1 (commit) from c570be01a4a9d2235560feaaddd7cdad955c0d69 (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=16afccac0542cff1ee440eaa77512ba35223ea78 commit 16afccac0542cff1ee440eaa77512ba35223ea78 Merge: c570be0 914db02 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Aug 20 10:25:51 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Aug 20 10:25:51 2014 -0400 Merge topic 'check-flag-for-intel' 914db028 Check*CompilerFlag: Add another pattern for Intel (#15096) --- Summary of changes: Modules/CMakeCheckCompilerFlagCommonPatterns.cmake |1 + 1 file changed, 1 insertion(+) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.1-4990-gd963457
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 d963457e4425185f3235c950538bd4056959889c (commit) via 16afccac0542cff1ee440eaa77512ba35223ea78 (commit) via c570be01a4a9d2235560feaaddd7cdad955c0d69 (commit) from 6e354771a8f8a7ec95e878eb658a56800b6c8639 (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=d963457e4425185f3235c950538bd4056959889c commit d963457e4425185f3235c950538bd4056959889c Merge: 6e35477 16afcca Author: Brad King brad.k...@kitware.com AuthorDate: Wed Aug 20 10:27:30 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Aug 20 10:27:30 2014 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.1-1736-g4517d6b
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 4517d6b7572e4f0656759c9b361326a8604c92a9 (commit) from 16afccac0542cff1ee440eaa77512ba35223ea78 (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=4517d6b7572e4f0656759c9b361326a8604c92a9 commit 4517d6b7572e4f0656759c9b361326a8604c92a9 Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Aug 21 00:01:07 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Aug 21 00:01:07 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7345b1b..70bd0f8 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 0) -set(CMake_VERSION_PATCH 20140820) +set(CMake_VERSION_PATCH 20140821) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
