Re: [cmake-developers] [update]: CPack IFW generator
Hello dear developers, and of course Brad! 11.08.2014, 18:38, Brad King brad.k...@kitware.com: After some fixes for nightly testing this is now in 'master'... Thank you that my small contribution is now available for the rest :-) FYI, if you were to start a new branch and base your changes off the upstream version instead of merging it then I would not have to keep squashing away your history as much. Something like this: git checkout-b cpack-ifw-updates 2fdd5d88 Thanks for the hints. The branch with the changes: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cpack-ifw-updates Update for the last week in one commit: http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=5ee02291d0c4dde21a4ecb513dd69cbb0157ddf6 I hope that soon these changes will be accepted. Regards, Konstantin Podsvirov -- 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] [update]: CPack IFW generator
On 08/12/2014 02:57 PM, Konstantin Podsvirov wrote: Update for the last week in one commit: http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=5ee02291d0c4dde21a4ecb513dd69cbb0157ddf6 Thanks. I revised the commit slightly to not un-do some of my earlier cleanups (we can't use that temporary option pointer without warnings on several compilers about assignment in 'if'): CPackIFW: Revise this generator http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6496b60 Please base further work by starting a branch from e6496b60, or from 'master' once it is merged there. As I accept each change I may revise it slightly, so then you should rebase further work on the upstream version each time. 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] [PATCH] New module: FindIce.cmake
On Mon, Aug 11, 2014 at 11:07:57AM -0400, Brad King wrote:
On 08/08/2014 08:56 AM, Roger Leigh wrote:
On Thu, Aug 07, 2014 at 06:49:28PM +0100, Roger Leigh wrote:
Hi,
I've written a module for finding the details of a ZeroC ICE installation,
attached, which I thought might be of interest to a wider audience and be
suitable for direct inclusion into cmake. I've attached the patch for
this.
The docs should be correct, but I'm not yet totally familiar with the cmake
docs build, so it might possibly need some minor tweaking.
I have added a few portability and documentation fixes. Updated copy
attached.
Thanks for working on this. The patch looks pretty complete.
Is it possible to convince ZeroC ICE to provide a CMake
Package Configuration File as documented here:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html
I will certainly ask them if they will consider it.
? That would be much more maintainable and allows for much more
powerful CMake interfaces to be used. It is the CMake equivalent
of a pkg-config .pc file, but is much more powerful.
Otherwise we can consider the module here, but we ask that you
commit to regular maintenance as the upstream changes.
I'm currently working on this for my job, and so will be keeping this
up to date. I just thought it would benefit being upstream so that
others can benefit from it. I'll also make the upstream aware of it.
They release fairly infrequently, so I don't expect updates generally
more than once or twice a year, if that.
While a configuration file would be ideal for new releases, the
proposed find script will cater for their most recent releases
to date, and as such will support all current Linux, Mac and
Windows users.
As for the module itself, there are a few problems:
I hope that the new patch (attached) addresses these problems. I
hope this is more acceptable, and I'll be happy to make any additional
changes.
1. The legal notice block is not of the proper format and
fails the CMake.ModuleNotices test.
This should be fixed.
2. The module provides singular names like comp_LIBRARY as its
output. Please read
http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#find-modules
for conventions on variable naming. The find_* command
cached result variables should not overlap with the output
variables from the module.
I read through the conventions and fixed things to work as best as
I understood things. I also switched to supporting COMPONENTS
and OPTIONAL_COMPONENTS for all the separate libraries.
3. There is a lot of hard-coded version-specific information
that will require constant maintenance and new releases
of CMake as the upstream versions change. This is not
maintainable, and is one reason the package configuration
file approach linked above is much preferred to a Find
module. Are there Windows Registry entries available
that specify the install location?
I have reworked this so that it loops through all the variants
which are compatible with the generator in use, plus fallbacks.
The disadvantage is that this now means that on Windows you
won't get an outright failure if the visual studio version
mismatches with the detected libraries whereas the previous
approach hardcoded all that knowledge. That said, it's a
whole lot more flexible and maintainable this way and so is an
acceptable tradeoff.
Regarding the Windows Registry, I've taken a look and it looks
like there might be some usable keys from the installer which
could be used, but I'll need to do further digging with all
the different versions to see what's most usable here.
4. Rather than repeatedly testing CMAKE_SIZEOF_VOID_P,
save the /x64 suffix in a ${_x64} variable.
Also fixed now.
If you had any further comments on the attached revision, I'll
be happy to make any further changes as needed, and as noted
above I'll also look at the registry stuff.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
From e9c1ce9a8df62904e69ac687b6e0ed4f4aa769f8 Mon Sep 17 00:00:00 2001
From: Roger Leigh r.le...@dundee.ac.uk
Date: Thu, 7 Aug 2014 18:37:36 +0100
Subject: [PATCH] FindIce: New module to find ZeroC Ice
- autodetects Ice on all major platforms
- allows building with all supported Visual Studio versions on Windows
- autodetects the slice path on most platforms
- separately detects the Ice programs, headers, slice files and
libraries so that any Ice configuration or installation errors can
be accurately reported, making diagnosis of Ice problems simpler
---
Help/manual/cmake-modules.7.rst | 1 +
Help/module/FindIce.rst | 1 +
Modules/FindIce.cmake | 461
3 files changed,
Re: [cmake-developers] [PATCH] New module: FindIce.cmake
On Tue, Aug 12, 2014 at 09:08:57PM +0100, Roger Leigh wrote: On Mon, Aug 11, 2014 at 11:07:57AM -0400, Brad King wrote: On 08/08/2014 08:56 AM, Roger Leigh wrote: On Thu, Aug 07, 2014 at 06:49:28PM +0100, Roger Leigh wrote: 3. There is a lot of hard-coded version-specific information that will require constant maintenance and new releases of CMake as the upstream versions change. This is not maintainable, and is one reason the package configuration file approach linked above is much preferred to a Find module. Are there Windows Registry entries available that specify the install location? I have reworked this so that it loops through all the variants which are compatible with the generator in use, plus fallbacks. The disadvantage is that this now means that on Windows you won't get an outright failure if the visual studio version mismatches with the detected libraries whereas the previous approach hardcoded all that knowledge. That said, it's a whole lot more flexible and maintainable this way and so is an acceptable tradeoff. Regarding the Windows Registry, I've taken a look and it looks like there might be some usable keys from the installer which could be used, but I'll need to do further digging with all the different versions to see what's most usable here. This turned out to be fairly simple at least for Ice versions 3.4.0 - 3.5.1, which all have the same naming convention. Earlier versions have odd naming conventions and are in Wow6432Node so I've not included them (they are obsolete in any case, and ICE_HOME can be set to use them). I've attached an updated copy which now includes using the registry. Happy to make any further improvements if needed. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From 3464e856d09de090a17ca7d8ce3e35b3caff4746 Mon Sep 17 00:00:00 2001 From: Roger Leigh r.le...@dundee.ac.uk Date: Thu, 7 Aug 2014 18:37:36 +0100 Subject: [PATCH] FindIce: New module to find ZeroC Ice - autodetects Ice on all major platforms - allows building with all supported Visual Studio versions on Windows - autodetects the slice path on most platforms - separately detects the Ice programs, headers, slice files and libraries so that any Ice configuration or installation errors can be accurately reported, making diagnosis of Ice problems simpler --- Help/manual/cmake-modules.7.rst | 1 + Help/module/FindIce.rst | 1 + Modules/FindIce.cmake | 443 3 files changed, 445 insertions(+) create mode 100644 Help/module/FindIce.rst create mode 100644 Modules/FindIce.cmake diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst index 91fffe9..737057c 100644 --- a/Help/manual/cmake-modules.7.rst +++ b/Help/manual/cmake-modules.7.rst @@ -114,6 +114,7 @@ All Modules /module/FindHg /module/FindHSPELL /module/FindHTMLHelp + /module/FindIce /module/FindIcotool /module/FindImageMagick /module/FindITK diff --git a/Help/module/FindIce.rst b/Help/module/FindIce.rst new file mode 100644 index 000..3af9405 --- /dev/null +++ b/Help/module/FindIce.rst @@ -0,0 +1 @@ +.. cmake-module:: ../../Modules/FindIce.cmake diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake new file mode 100644 index 000..2930e2d --- /dev/null +++ b/Modules/FindIce.cmake @@ -0,0 +1,443 @@ +#.rst: +# FindIce +# --- +# +# Find the ZeroC Internet Communication Engine (ICE) programs, +# libraries and datafiles. +# +# Use this module by invoking find_package with the form:: +# +# find_package(Ice +# [version] [EXACT] # Minimum or EXACT version e.g. 3.5.1 +# [REQUIRED] # Fail with error if Ice is not found +# [COMPONENTS libs...]) # Ice libraries by their name +# +# Components can include any of: Freeze Glacier2 Ice IceBox IceDB +# IceGrid IcePatch IceSSL IceStorm IceUtil IceXML Slice. +# +# This module reports information about the Ice installation in +# several variables. General variables:: +# +# Ice_VERSION - Ice release version +# Ice_FOUND - true if the main programs and libraries were found +# ICE_LIBRARIES - component libraries to be linked +# Ice_BINARY_DIR - the directory containing the Ice programs +# Ice_INCLUDE_DIR - the directory containing the Ice headers +# Ice_SLICE_DIR - the directory containing the Ice slice interface definitions +# Ice_LIBRARY_DIR - the directory containing the Ice libraries +# +# Ice programs are reported in:: +# +# Ice_SLICE2CPP_EXECUTABLE - path to slice2cpp executable +# Ice_SLICE2CS_EXECUTABLE - path to slice2cs executable +# Ice_SLICE2FREEZEJ_EXECUTABLE - path to slice2freezej executable +# Ice_SLICE2FREEZE_EXECUTABLE - path to slice2freeze executable +#
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
On 11/08/14 18:47, Brad King wrote: On 08/09/2014 09:46 AM, Marcel Loose wrote: CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and immediately deprecated the LINK_INTERFACE_LIBRARIES keyword, triggering policy warnings CMP0022 and CMP0023. What is the proper way to get rid of these policy warnings, while at the same time staying backward compatible with older CMake versions? From the documentation of CMP0022: Warning-free future-compatible code which works with CMake 2.8.9 onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries(). Actually it should say 2.8.7, not 2.8.9. CMP0023 docs mention 2.8.7. -Brad Hi, Another problem I faced with policy CMP0022 is that I was unable to really silence it. Setting the policy to OLD doesn't really work (at least not in my case), maybe because the cmake_policy() command is scoped(?). I have a macro that contains the now deprecated use of LINK_INTERFACE_LIBRARIES, so I thought I could simply wrap that statement inside the following code block: if (POLICY CMP0022) cmake_policy(PUSH) cmake_policy(SET CMP0022 OLD) endif() target_link_libraries (... LINK_INTERFACE_LIBRARIES ...) if (POLICY CMP0022) cmake_policy(POP) endif() But that doesn't seem to work. I still get the policy warnings for CMP0022. Also setting the policy to OLD once at top-level doesn't seem to work; probably due to policy scoping. I played a bit with NO_POLICY_SCOPE to different include() and find_package() statements, but to no avail. Regards, Marcel Loose. attachment: loose.vcf-- 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 11/08/14 18:47, Brad King wrote: On 08/09/2014 09:46 AM, Marcel Loose wrote: CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and immediately deprecated the LINK_INTERFACE_LIBRARIES keyword, triggering policy warnings CMP0022 and CMP0023. What is the proper way to get rid of these policy warnings, while at the same time staying backward compatible with older CMake versions? From the documentation of CMP0022: Warning-free future-compatible code which works with CMake 2.8.9 onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries(). Actually it should say 2.8.7, not 2.8.9. CMP0023 docs mention 2.8.7. -Brad Hmm, That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read the following in the docs on target_link_libraries The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the link dependencies and the link interface in one command. This signature is for compatibility only. Prefer the PUBLIC or PRIVATE keywords instead. ... for compatibility only didn't give me the feeling that this is the way to go, which is underscored by the next sentence: Prefer the ... On a side note. Even using the new PRIVATE and PUBLIC keywords I am unable to exactly specify which libraries are needed for linking. Without breaking builds with static libraries, I am forced to specify too many library dependencies. Maybe I'm doing something wrong, but my setup is quite complicated. Fortunately, modern version of ld will get rid of unused libraries anyway, so it's not really that much of an issue for me. Regards, Marcel Loose. attachment: loose.vcf-- 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] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake
From
http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html :
If COMMAND specifies an executable target (created by ADD_EXECUTABLE)
it will automatically be replaced by the location of the executable
created at build time. Additionally a target-level dependency will be
added so that the executable target will be built before any target
using this custom command. However this does NOT add a file-level
dependency that would cause the custom command to re-run whenever the
executable is recompiled.
So... if TestVersion.exe is created as a result of an
add_executable(TestVersion ... call, then you should be able to use
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD
COMMAND TestVersion \$(VersionPath)\
COMMENT Check if $(VersionPath) has version information...)
If you must pass the full path to TestVersion as an argument to a batch
file, you should be able to use
$TARGET_FILE:TestVersion
(again, assuming TestVersion is the name of your add_executable target)
By the way, the error message 'TestVer\TestVersion.exe' is not
recognized ... is probably happening because the working directory is
not set correctly relative to the name TestVer\TestVersion.exe - a
simple pushd/popd combination to the correct directory in the batch
file may solve this.
HTH,
David
--
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 really change CMake linker
Unless it is overridden somewhere else along the way, the following is
used to create the link command line for a C++ executable:
(found in Modules/CMakeCXXInformation.cmake)
if(NOT CMAKE_CXX_LINK_EXECUTABLE)
set(CMAKE_CXX_LINK_EXECUTABLE
CMAKE_CXX_COMPILER FLAGS CMAKE_CXX_LINK_FLAGS
LINK_FLAGS OBJECTS -o TARGET LINK_LIBRARIES)
endif()
As you can see, by default, the C++ compiler is used as a front end to
link C++ executables...
Similarly for other types of targets, there are
CMAKE_CXX_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_MODULE. And
for other languages, there are CMAKE_${LANG}_CREATE_... variables too.
In order to use the linker you want, you would have to define a custom
CMAKE_CXX_LINK_EXECUTABLE that uses CMAKE_LINKER in its definition
of the linker command line.
HTH,
David C.
--
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 08/12/2014 03:59 AM, Marcel Loose wrote: Another problem I faced with policy CMP0022 is that I was unable to really silence it. Setting the policy to OLD doesn't really work (at least not in my case), maybe because the cmake_policy() command is scoped(?). For CMP0022 and CMP0023 the policy setting is recorded on each target when it is created by and add_library command. That affects all target_link_libraries calls that give the library as the first argument. setting the policy to OLD once at top-level doesn't seem to work Any call to cmake_minimum_required(VERSION) will unset policies introduced in versions larger than that named. 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. -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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
On 08/12/2014 03:48 AM, Marcel Loose wrote: That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read the following in the docs on target_link_libraries The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the link dependencies and the link interface in one command. This signature is for compatibility only. Prefer the PUBLIC or PRIVATE keywords instead. ... for compatibility only didn't give me the feeling that this is the way to go, which is underscored by the next sentence: Prefer the ... If your project requires CMake 2.8.12 or higher then it is preferred to use PUBLIC/PRIVATE. For compatibility with earlier CMake versions you can still use LINK_PUBLIC/LINK_PRIVATE. On a side note. Even using the new PRIVATE and PUBLIC keywords I am unable to exactly specify which libraries are needed for linking. Can you provide a concrete example of this trouble? -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
Re: [CMake] how to really change CMake linker
Hi David,
Thanks very much for your reply! That was extremely helpful, and will let
several packages document a functional workflow for the future.
On Tue, Aug 12, 2014 at 5:38 AM, David Cole dlrd...@aol.com wrote:
Unless it is overridden somewhere else along the way, the following is
used to create the link command line for a C++ executable:
(found in Modules/CMakeCXXInformation.cmake)
if(NOT CMAKE_CXX_LINK_EXECUTABLE)
set(CMAKE_CXX_LINK_EXECUTABLE
CMAKE_CXX_COMPILER FLAGS CMAKE_CXX_LINK_FLAGS
LINK_FLAGS OBJECTS -o TARGET LINK_LIBRARIES)
endif()
As you can see, by default, the C++ compiler is used as a front end to
link C++ executables...
Similarly for other types of targets, there are
CMAKE_CXX_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_MODULE. And
for other languages, there are CMAKE_${LANG}_CREATE_... variables too.
Ah, that explains one source of confusion. I read CMAKE_CXX_LINK_EXECUTABLE
with LINK as an adjective - specify the executable that does linking -
whereas the above use of CREATE makes clear that the sense of LINK is
intended to be as a verb - specify how to create an executable. The docs
did say that this variable specifies a rule, now that I know what to look
for. :-(
In order to use the linker you want, you would have to define a custom
CMAKE_CXX_LINK_EXECUTABLE that uses CMAKE_LINKER in its definition
of the linker command line.
Right. It's easy to assume that this would be the default behaviour for
constructing linking command lines. It's probably too late to consider a
change, but I hope the original reasoning works well somewhere! :-)
Mark
HTH,
David C.
--
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] Possible bug in environment variable expansion?
That's a good thought, but unfortunately it didn't pan out. I tried both styles, and I even tried explicitly mixing styles like this: BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 Or this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 And those worked fine. From: lucas.pet...@engilitycorp.com [mailto:lucas.pet...@engilitycorp.com] Sent: Monday, August 11, 2014 11:03 PM To: Chris Volpe ARA/SED; cmake@cmake.org Subject: RE: Possible bug in environment variable expansion? Could it be something as simple as UNIX (slash /) vs Windows (backslash \) in the directory expression? When this environment variable is expanded BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0, it looks like it is converting the %BOOST_ROOT% in UNIX style and then the \lib-msvc-12.0 is Windows. This mixture of styles may be causing a no such directory system error. I know on Windows systems I need to be consistent with directory styles or it fails. Lucas Pettey, PhD HPCMP PETTT EQM CTA Lead ERDC-DSRC OnSite Vicksburg, MS 512-297-9833 Mobile (preferred) 601-634-2980 Office lucas.pet...@engilitycorp.commailto:lucas.pet...@engilitycorp.com From: CMake [cmake-boun...@cmake.org] on behalf of Chris Volpe ARA/SED [cvo...@ara.com] Sent: Monday, August 11, 2014 6:25 PM To: cmake@cmake.org Subject: [CMake] Possible bug in environment variable expansion? I am trying to build an Open Source project called PCL which uses Boost, and CMake's ability to find the Boost libraries seems dependent on whether the BOOST_LIBRARYDIR contains a literal path string, or whether it contains a string that incorporates the expansion of BOOST_ROOT. Here are the details: Boost is installed from a pre-built installer in the folder C:\local\boost_1_55_0. This folder contains, among other things, a subfolder called boost, which contains the headers, and a subfolder called lib64-msvc-12.0, which contains 64-bit libraries built with MS Visual Studio 2013. Ordinarily, CMake would like that folder to be called simply lib, but that's not what the installer created, so I'm trying to override the default with environment variables. I have the following three environment variables defined, all of which are of type Expandable string: BOOST_ROOT=C:\local\boost_1_55_0 BOOST_INCLUDEDIR=%BOOST_ROOT% BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 With these settings, CMake reports an error during the configuration process, as follows: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message): Unable to find the requested Boost libraries. Boost version: 1.55.0 Boost include path: C:/local/boost_1_55_0 Could not find the following Boost libraries: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams boost_chrono No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): cmake/pcl_find_boost.cmake:38 (find_package) CMakeLists.txt:230 (include) But if change the definition of BOOST_LIBRARYDIR by replacing %BOOST_ROOT% with the value assigned to BOOST_ROOT, resulting in this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0 the configuration succeeds. The only difference seems to be whether the C:\local\boost_1_55_0 part of the path is specified explicitly, or obtained implicitly with %BOOST_ROOT%. It would surprise me if this behavior were by design. Does anyone have an explanation for this? Thanks, Chris Christopher R. Volpe, Ph.D. Senior Scientist, Remote Sensing Decision Analytics [Description: Description: Description: cid:image003.png@01CE888B.0167BAD0] NATIONAL SECURITY | INFRASTRUCTURE | ENERGY ENVIRONMENT | HEALTH SOLUTIONS Applied Research Associates, Inc. 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 Find Us Online www.ara.comhttp://www.ara.com Facebook: Applied Research Associateshttps://www.facebook.com/#!/AppliedResearchAssociates LinkedIn: Company Pagehttp://www.linkedin.com/company/8853?trk=tyah LinkedIn Grouphttp://www.linkedin.com/groups/ARA-Employees-Group-4854334?trk=myg_ugrp_ovr Twitter: ARA Newshttps://twitter.com/ARA_News_Events YouTube: Applied Research Associateshttp://www.youtube.com/user/AppliedResearch1?feature=mhee -- 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:
[CMake] Windows RC files with Ninja
Greetings, I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC files. Looks like a simple problem but I would be baffled if I'm the first to experience this so I expect I have some kind of configuration issue. Here is the offending snippet in the rules.ninja file: rule RC_COMPILER depfile = $DEP_FILE deps = gcc command = RC $in $DEP_FILE $out c:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in description = Building RC object $out If I put the path to cmcldeps.exe in the empty quotes on the command line, it works as expected. Does anyone else have this problem? Frank This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system. In order to safeguard its employee data as well as sensitive patient, customer, business, legal and other information, the company uses all lawful means, under all applicable law, to access, monitor, preserve, collect and review all communications between employees and all other users only when, and to the extent necessary, to fulfill investigatory and other important business and legal responsibilities. By responding to this communication, or initiating additional co mmunication with the company, you consent to such lawful monitoring, to the extent such consent is required and valid in your local area. -- 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] Possible bug in environment variable expansion?
As it turns out, something weirder is going on, and it's not cmake's fault, so
I won't look for a solution here, but I'll describe the problem in case
anyone's interested. *Windows* is not expanding those environment variables.
First, I hacked up the installed version of FindBoost.cmake to spit out some
debugging information, with the following, circa line 860:
message(DEBUG _ENV_BOOST_LIBRARYDIR has value ${_ENV_BOOST_LIBRARYDIR})
and then I ran configure in debug mode, which gave me the following from my
extra hacked debugging output:
DEBUG_ENV_BOOST_LIBRARYDIR has value %BOOST_ROOT%/lib64-msvc-12.0
So, when cmake asked the OS for the BOOST_LIBRARYDIR environment variable, the
OS gave it the string without expanding BOOST_ROOT. I have verified this OS
behavior by opening up a command window and using the set command: It's not
getting expanded. I've verified (with RapidEE) that the environment variables
in question are of type expandable string, not string.
While playing with the variables in RapidEE (a wonderful tool, BTW), I noticed
two other strange things. First, I do have a couple of env vars that do have
other env var references in them, and they *do* get expanded in cmd.exe.
Second, my PATH env var used to have embedded env vars for various things, but
somewhere along the way they all got replaced in the PATH *definition* with
their expanded versions, so now everything in my path is now hard coded, so
to speak. Ugh.
So, basically, something is messed up in my system.
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Volpe ARA/SED
Sent: Tuesday, August 12, 2014 12:44 PM
To: lucas.pet...@engilitycorp.com; cmake@cmake.org
Subject: Re: [CMake] Possible bug in environment variable expansion?
That's a good thought, but unfortunately it didn't pan out. I tried both
styles, and I even tried explicitly mixing styles like this:
BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0
Or this:
BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0
And those worked fine.
From: lucas.pet...@engilitycorp.com [mailto:lucas.pet...@engilitycorp.com]
Sent: Monday, August 11, 2014 11:03 PM
To: Chris Volpe ARA/SED; cmake@cmake.org
Subject: RE: Possible bug in environment variable expansion?
Could it be something as simple as UNIX (slash /) vs Windows (backslash \) in
the directory expression?
When this environment variable is expanded
BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0, it looks like it is converting
the %BOOST_ROOT% in UNIX style and then the \lib-msvc-12.0 is Windows. This
mixture of styles may be causing a no such directory system error. I know on
Windows systems I need to be consistent with directory styles or it fails.
Lucas Pettey, PhD
HPCMP PETTT EQM CTA Lead
ERDC-DSRC OnSite
Vicksburg, MS
512-297-9833 Mobile (preferred)
601-634-2980 Office
lucas.pet...@engilitycorp.commailto:lucas.pet...@engilitycorp.com
From: CMake [cmake-boun...@cmake.org] on behalf of Chris Volpe ARA/SED
[cvo...@ara.com]
Sent: Monday, August 11, 2014 6:25 PM
To: cmake@cmake.org
Subject: [CMake] Possible bug in environment variable expansion?
I am trying to build an Open Source project called PCL which uses Boost, and
CMake's ability to find the Boost libraries seems dependent on whether the
BOOST_LIBRARYDIR contains a literal path string, or whether it contains a
string that incorporates the expansion of BOOST_ROOT. Here are the details:
Boost is installed from a pre-built installer in the folder
C:\local\boost_1_55_0. This folder contains, among other things, a subfolder
called boost, which contains the headers, and a subfolder called
lib64-msvc-12.0, which contains 64-bit libraries built with MS Visual Studio
2013. Ordinarily, CMake would like that folder to be called simply lib, but
that's not what the installer created, so I'm trying to override the default
with environment variables. I have the following three environment variables
defined, all of which are of type Expandable string:
BOOST_ROOT=C:\local\boost_1_55_0
BOOST_INCLUDEDIR=%BOOST_ROOT%
BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0
With these settings, CMake reports an error during the configuration process,
as follows:
CMake Error at C:/Program Files
(x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message):
Unable to find the requested Boost libraries.
Boost version: 1.55.0
Boost include path: C:/local/boost_1_55_0
Could not find the following Boost libraries:
boost_system
boost_filesystem
boost_thread
boost_date_time
boost_iostreams
boost_chrono
No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.
Call Stack (most recent call first):
cmake/pcl_find_boost.cmake:38 (find_package)
CMakeLists.txt:230 (include)
But if change the definition of BOOST_LIBRARYDIR by replacing %BOOST_ROOT%
with the value assigned to BOOST_ROOT, resulting in this:
Re: [CMake] Possible bug in environment variable expansion?
On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote: That’s a good thought, but unfortunately it didn’t pan out. I tried both styles, and I even tried explicitly mixing styles like this: BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 Or this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 Try setting Boost_DEBUG=1 in your CMake run, and then it should show you where it is searching and the problem may become more obvious. -Bill -- 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] Possible bug in environment variable expansion?
Thanks, Bill. As it turns out, the problem appears to be a bug in Windows. Through experimentation, I have determined a truth about environment variables that I have yet to be able to find spelled out anywhere: If the type of an environment variable does not *need* to be Expandable String, then it *mustn't* be Expandable String. Environment variable expansion (including nested multiple levels) works only when all the variables that reference others are of type Expandable String, and the ones that don't are of type String. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Tuesday, August 12, 2014 3:50 PM To: cmake@cmake.org Subject: Re: [CMake] Possible bug in environment variable expansion? On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote: That's a good thought, but unfortunately it didn't pan out. I tried both styles, and I even tried explicitly mixing styles like this: BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 Or this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 Try setting Boost_DEBUG=1 in your CMake run, and then it should show you where it is searching and the problem may become more obvious. -Bill -- 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 -- 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] Possible bug in environment variable expansion?
I only define:
BOOST_ROOT=C:\local\boost_1_56_0
BOOST_LIBRARYDIR=C:\local\boost_1_56_0\lib64-msvc-12.0
and this works Ok.
This will not work:
BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0
If you go to a command prompt and type set you will see that %BOOST_ROOT%
is not expanded.
So this is a Windows issue, not a CMake issue.
The only clue I have is that Microsoft expands these variables in order and
since BOOST_ROOT is ordered after BOOST_LIBRARYDIR the expansion does not
happen.
Regards
Andrew
On Wed, Aug 13, 2014 at 5:37 AM, cmake-requ...@cmake.org wrote:
Send CMake mailing list submissions to
cmake@cmake.org
To subscribe or unsubscribe via the World Wide Web, visit
http://public.kitware.com/mailman/listinfo/cmake
or, via email, send a message with subject or body 'help' to
cmake-requ...@cmake.org
You can reach the person managing the list at
cmake-ow...@cmake.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of CMake digest...
Today's Topics:
1. Windows RC files with Ninja (Miller, Frank)
2. Re: Possible bug in environment variable expansion?
(Chris Volpe ARA/SED)
-- Forwarded message --
From: Miller, Frank fmil...@sjm.com
To: CMake MailingList cmake@cmake.org
Cc:
Date: Tue, 12 Aug 2014 16:44:03 +
Subject: [CMake] Windows RC files with Ninja
Greetings,
I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with
RC files. Looks like a simple problem but I would be baffled if I'm the
first to experience this so I expect I have some kind of configuration
issue. Here is the offending snippet in the rules.ninja file:
rule RC_COMPILER
depfile = $DEP_FILE
deps = gcc
command = RC $in $DEP_FILE $out c:/Program Files
(x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe
c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in
description = Building RC object $out
If I put the path to cmcldeps.exe in the empty quotes on the command
line, it works as expected.
Does anyone else have this problem?
Frank
This communication, including any attachments, may contain information
that is proprietary, privileged, confidential or legally exempt from
disclosure. If you are not a named addressee, you are hereby notified that
you are not authorized to read, print, retain a copy of or disseminate any
portion of this communication without the consent of the sender and that
doing so may be unlawful. If you have received this communication in error,
please immediately notify the sender via return e-mail and delete it from
your system. In order to safeguard its employee data as well as sensitive
patient, customer, business, legal and other information, the company uses
all lawful means, under all applicable law, to access, monitor, preserve,
collect and review all communications between employees and all other users
only when, and to the extent necessary, to fulfill investigatory and other
important business and legal responsibilities. By responding to this
communication, or initiating additional communication with the company, you
consent to such lawful monitoring, to the extent such consent is required
and valid in your local area.
-- Forwarded message --
From: Chris Volpe ARA/SED cvo...@ara.com
To: Chris Volpe ARA/SED cvo...@ara.com, lucas.pet...@engilitycorp.com
lucas.pet...@engilitycorp.com, cmake@cmake.org cmake@cmake.org
Cc:
Date: Tue, 12 Aug 2014 19:37:47 +
Subject: Re: [CMake] Possible bug in environment variable expansion?
As it turns out, something weirder is going on, and it’s not cmake’s
fault, so I won’t look for a solution here, but I’ll describe the problem
in case anyone’s interested. **Windows** is not expanding those
environment variables. First, I hacked up the installed version of
FindBoost.cmake to spit out some debugging information, with the following,
circa line 860:
message(DEBUG _ENV_BOOST_LIBRARYDIR has value
${_ENV_BOOST_LIBRARYDIR})
and then I ran configure in debug mode, which gave me the following from
my extra hacked debugging output:
DEBUG_ENV_BOOST_LIBRARYDIR has value %BOOST_ROOT%/lib64-msvc-12.0
So, when cmake asked the OS for the BOOST_LIBRARYDIR environment variable,
the OS gave it the string without expanding BOOST_ROOT. I have verified
this OS behavior by opening up a command window and using the set command:
It’s not getting expanded. I’ve verified (with RapidEE) that the
environment variables in question are of type “expandable string”, not
“string”.
While playing with the variables in RapidEE (a wonderful tool, BTW), I
noticed two other strange things. First, I do have a couple of env vars
that do have other env var references in them, and they **do** get
expanded in cmd.exe. Second, my PATH env var used to have embedded env vars
for various things, but somewhere along the way they all got replaced in
the PATH
[CMake] Removing the original CDash admin
Hi All, Does anyone know how to remove the primary (first) Administrator of a CDash instance? All the other users show up with a 'make normal user' and 'remove user' button but not the original administrator who setup the instance. Thanks Matt -- 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] Removing the original CDash admin
You can always brute force it and go in and remove that user from the database table with MySQL or phpMyAdmin... HTH, David C. -- 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] Removing the original CDash admin
Yeah I was just worried that since CDash seems to be so fond of this user it might react badly to their forced departure. Matt -Original Message- From: David Cole [mailto:dlrd...@aol.com] Sent: Wednesday, 13 August 2014 11:37 AM To: Bolger, Matt (DPS, Clayton); cmake@cmake.org Subject: Re: [CMake] Removing the original CDash admin You can always brute force it and go in and remove that user from the database table with MySQL or phpMyAdmin... HTH, David C. -- 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] Generator expressions for optimized/debug configurations
I just installed CMake 3.0 and I'm trying out the new generator
expressions for the target_compile_definitions() command.
I am doing this:
target_compile_definitions( ${project_name}
PRIVATE ${general_defs}
PRIVATE $$CONFIG:debug:${debug_defs}
PRIVATE $$CONFIG:release:${release_defs}
)
The problem here is that there are many release configurations
provided by CMake by default. I would like a way to target optimized
and unoptimized configurations, regardless of name.
I'm working on a generic CMake framework (written in CMake language)
that hides away some details of using CMake directly for complex
tasks. As such I can't really know from a generic level which
configurations (by name) will exist. Users could add more or less. The
best I can do from the framework level is target optimized or
unoptimized configs.
Any way to do this with 3.0?
Thanks in advance.
--
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] Removing the original CDash admin
I think you should be ok... just make another user admin before you do it, of course. You can always put the user back by brute force, too, if you discover you need it for something. I'm not aware of anything special about the user besides its admin-ness. Good luck, and let us know if you find anything that doesn't work after you remove it. 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-commits] CMake branch, next, updated. v3.0.1-4854-g3ff95a9
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 3ff95a9e0cfc1d0f4a9ecfbd4a0845fd6e04b934 (commit)
via 33d0f64a44f30c5630e80cb265266349cfd11dbb (commit)
from dcd9e9671e260bf7453bde45cf8205d9808640cb (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=3ff95a9e0cfc1d0f4a9ecfbd4a0845fd6e04b934
commit 3ff95a9e0cfc1d0f4a9ecfbd4a0845fd6e04b934
Merge: dcd9e96 33d0f64
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 09:45:14 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 12 09:45:14 2014 -0400
Merge topic 'add-CheckFortranSourceCompiles' into next
33d0f64a Tests/FortranOnly: Print CMakeError.log on HAVE_PRINT failure
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33d0f64a44f30c5630e80cb265266349cfd11dbb
commit 33d0f64a44f30c5630e80cb265266349cfd11dbb
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 09:46:04 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Aug 12 09:46:04 2014 -0400
Tests/FortranOnly: Print CMakeError.log on HAVE_PRINT failure
diff --git a/Tests/FortranOnly/CMakeLists.txt b/Tests/FortranOnly/CMakeLists.txt
index ef151d7..da6a7dd 100644
--- a/Tests/FortranOnly/CMakeLists.txt
+++ b/Tests/FortranOnly/CMakeLists.txt
@@ -44,6 +44,8 @@ add_custom_target(checksayhello ALL
)
add_dependencies(checksayhello sayhello)
+set(err_log ${CMAKE_BINARY_DIR}/CMakeFiles/CMakeError.log)
+file(REMOVE ${err_log})
include(CheckFortranSourceCompiles)
unset(HAVE_PRINT CACHE)
CHECK_Fortran_SOURCE_COMPILES([[
@@ -52,5 +54,10 @@ CHECK_Fortran_SOURCE_COMPILES([[
END
]] HAVE_PRINT)
if(NOT HAVE_PRINT)
- message(SEND_ERROR CHECK_Fortran_SOURCE_COMPILES for HAVE_PRINT failed!)
+ if(EXISTS ${err_log})
+file(READ ${err_log} err)
+ endif()
+ string(REPLACE \n \n err ${err})
+ message(SEND_ERROR CHECK_Fortran_SOURCE_COMPILES for HAVE_PRINT failed:\n
+${err})
endif()
---
Summary of changes:
Tests/FortranOnly/CMakeLists.txt |9 -
1 file changed, 8 insertions(+), 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-1663-ge01cb16
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 e01cb16cdbeac38c1b23e651137efc29116d2c48 (commit) via 0578c283e88c40957c7f43c653dd8c75d8c7782e (commit) from 354c792c9de5759a4484dc157a206e06012e83c6 (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=e01cb16cdbeac38c1b23e651137efc29116d2c48 commit e01cb16cdbeac38c1b23e651137efc29116d2c48 Merge: 354c792 0578c28 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 09:48:32 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Aug 12 09:48:32 2014 -0400 Merge topic 'fujitsu-compiler-id' 0578c283 Add Fujitsu compiler detection --- Summary of changes: Modules/CMakeCompilerIdDetection.cmake |1 + Modules/Compiler/Fujitsu-DetermineCompiler.cmake |2 ++ 2 files changed, 3 insertions(+) create mode 100644 Modules/Compiler/Fujitsu-DetermineCompiler.cmake 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-4858-gf995368
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 f995368714dcc9d9d770b3a3c4f7163abda58027 (commit) via e01cb16cdbeac38c1b23e651137efc29116d2c48 (commit) via 354c792c9de5759a4484dc157a206e06012e83c6 (commit) via 9c103ae80a15b0eccabec8b74812f0f9e9c17123 (commit) from 3ff95a9e0cfc1d0f4a9ecfbd4a0845fd6e04b934 (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=f995368714dcc9d9d770b3a3c4f7163abda58027 commit f995368714dcc9d9d770b3a3c4f7163abda58027 Merge: 3ff95a9 e01cb16 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 09:50:14 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Aug 12 09:50:14 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-1661-g354c792
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 354c792c9de5759a4484dc157a206e06012e83c6 (commit) via 6c32d43ce2d8db87e348b281d9afe981d6ebc15d (commit) via 137a0251aaa643f39d3e804bd9a9c3e8f1519ce0 (commit) via 51c82c3a66f02192df4db5d51d95f7311bc2181f (commit) via fe587db415b1cf728f42c5db55c3acbad7a9a529 (commit) from 9c103ae80a15b0eccabec8b74812f0f9e9c17123 (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=354c792c9de5759a4484dc157a206e06012e83c6 commit 354c792c9de5759a4484dc157a206e06012e83c6 Merge: 9c103ae 6c32d43 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 09:48:30 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Aug 12 09:48:30 2014 -0400 Merge topic 'update-kwsys' 6c32d43c Merge branch 'upstream-kwsys' into update-kwsys 137a0251 KWSys 2014-08-11 (32023afd) 51c82c3a Merge branch 'upstream-kwsys' into update-kwsys fe587db4 KWSys 2014-08-07 (4d526097) --- Summary of changes: Source/kwsys/CPU.h.in |4 ++ Source/kwsys/ProcessUNIX.c |2 + Source/kwsys/SystemTools.cxx | 105 Source/kwsys/SystemTools.hxx.in|9 --- Source/kwsys/testCommandLineArguments1.cxx |2 + Source/kwsys/testProcess.c |2 + Source/kwsys/testSystemTools.cxx | 22 -- 7 files changed, 10 insertions(+), 136 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.0.1-10-g8db3c79
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, release has been updated via 8db3c79f63841e8cabd7e84968da72522f656cb1 (commit) via ef120655fcaedca08f878241efba488ef507 (commit) via d061248791db8cd3c6030c4b29ce780cb8bc84da (commit) from 81a4ca57f858ad8ea7e042f60300aa5322541578 (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 - --- Summary of changes: Source/kwsys/CPU.h.in|4 Utilities/KWIML/ABI.h.in |4 2 files changed, 8 insertions(+) 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-1667-g755891c
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 755891c3d92b684e7884ccb3016e5a1da89bbbde (commit) via 8db3c79f63841e8cabd7e84968da72522f656cb1 (commit) via ef120655fcaedca08f878241efba488ef507 (commit) via d061248791db8cd3c6030c4b29ce780cb8bc84da (commit) from e01cb16cdbeac38c1b23e651137efc29116d2c48 (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 - --- 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, next, updated. v3.0.1-4863-g971b990
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 971b990718b75dd8848e795a07294d8f7594b9a7 (commit) via 755891c3d92b684e7884ccb3016e5a1da89bbbde (commit) via 8db3c79f63841e8cabd7e84968da72522f656cb1 (commit) via ef120655fcaedca08f878241efba488ef507 (commit) via d061248791db8cd3c6030c4b29ce780cb8bc84da (commit) from f995368714dcc9d9d770b3a3c4f7163abda58027 (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=971b990718b75dd8848e795a07294d8f7594b9a7 commit 971b990718b75dd8848e795a07294d8f7594b9a7 Merge: f995368 755891c Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 09:51:08 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Aug 12 09:51:08 2014 -0400 Merge branch 'master' into next --- 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-1680-g7365a9f
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 7365a9fe929c935a194987d3a4a68aff77129a2b (commit)
via 5d3d9a22b28e99894dab2fe4fac0279fb422ace4 (commit)
via 401a00d9f98aff9c2f15315945cd4c392ff36d9f (commit)
via 709cebde66a4251e1a1ed7a90c072f06be691bee (commit)
via 72395ab23eee5ed7ff5a8800632869d6ef66f805 (commit)
via 2074f5813889680d32c784c3dbdb1bf41be1405f (commit)
via c72f0887cee6c3c47f50efb44256476045cf801f (commit)
via 1c94558abb653968de6da2cb4672006f31ca0d14 (commit)
via 592098e2d5a00d396e84d7a5e51ae6c550a21fc6 (commit)
via aa42a78f523f3db5e849663a7c55d949dd25bfb0 (commit)
via b94ddf6cd70e811e4bc3f3c28ef7195bcf2bb0cf (commit)
via d7938bff37bfa05f34b9ad5a46ae3aff54955eea (commit)
via 3abd150ce9df03e24a903dedc952339b58ba79cb (commit)
from 755891c3d92b684e7884ccb3016e5a1da89bbbde (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=7365a9fe929c935a194987d3a4a68aff77129a2b
commit 7365a9fe929c935a194987d3a4a68aff77129a2b
Merge: 755891c 5d3d9a2
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 10:03:03 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 12 10:03:03 2014 -0400
Merge topic 'vs-windows-phone-and-store'
5d3d9a22 Help: Add notes for topic 'vs-windows-phone-and-store'
401a00d9 VS: Set WindowsPhone and WindowsStore min VS version required
709cebde VS: Generate WindowsPhone and WindowsStore application types
72395ab2 VS: Add .sln Deploy mark for WindowsPhone and WindowsStore
binaries
2074f581 MSVC: Add system libs for WindowsPhone and WindowsStore
c72f0887 MSVC: Add default WindowsPhone and WindowsStore compile flags
1c94558a MSVC: Disable incremental linking for WindowsPhone and WindowsStore
592098e2 Define 'WINDOWS_PHONE' and 'WINDOWS_STORE' variables
aa42a78f Add WindowsPhone and WindowsStore platform information modules
b94ddf6c CMakeDetermineCompilerId: Recognize WindowsPhone and WindowsStore
d7938bff VS: Select WindowsPhone and WindowsStore default toolsets
3abd150c VS: Save WindowsPhone and WindowsStore system internally
---
Summary of changes:
Help/manual/cmake-variables.7.rst |2 +
Help/release/dev/vs-windows-phone-and-store.rst| 10 +++
Help/variable/WINDOWS_PHONE.rst|5 ++
Help/variable/WINDOWS_STORE.rst|5 ++
Modules/CMakeDetermineCompilerId.cmake | 12
Modules/CompilerId/VS-10.vcxproj.in|2 +
Modules/Platform/Windows-MSVC.cmake| 18 --
Modules/Platform/Windows.cmake |4 ++
...wsCE-MSVC-C.cmake = WindowsPhone-MSVC-C.cmake} |0
...-MSVC-CXX.cmake = WindowsPhone-MSVC-CXX.cmake} |0
.../{WindowsCE.cmake = WindowsPhone.cmake}|0
...wsCE-MSVC-C.cmake = WindowsStore-MSVC-C.cmake} |0
...-MSVC-CXX.cmake = WindowsStore-MSVC-CXX.cmake} |0
.../{WindowsCE.cmake = WindowsStore.cmake}|0
Source/cmGlobalVisualStudio10Generator.cxx | 38 +++-
Source/cmGlobalVisualStudio10Generator.h | 14 +
Source/cmGlobalVisualStudio11Generator.cxx | 64
Source/cmGlobalVisualStudio11Generator.h |7 +++
Source/cmGlobalVisualStudio12Generator.cxx | 50 +++
Source/cmGlobalVisualStudio12Generator.h |4 ++
Source/cmVisualStudio10TargetGenerator.cxx | 34 +++
Source/cmVisualStudio10TargetGenerator.h |1 +
22 files changed, 265 insertions(+), 5 deletions(-)
create mode 100644 Help/release/dev/vs-windows-phone-and-store.rst
create mode 100644 Help/variable/WINDOWS_PHONE.rst
create mode 100644 Help/variable/WINDOWS_STORE.rst
copy Modules/Platform/{WindowsCE-MSVC-C.cmake = WindowsPhone-MSVC-C.cmake}
(100%)
copy Modules/Platform/{WindowsCE-MSVC-CXX.cmake =
WindowsPhone-MSVC-CXX.cmake} (100%)
copy Modules/Platform/{WindowsCE.cmake = WindowsPhone.cmake} (100%)
copy Modules/Platform/{WindowsCE-MSVC-C.cmake = WindowsStore-MSVC-C.cmake}
(100%)
copy Modules/Platform/{WindowsCE-MSVC-CXX.cmake =
WindowsStore-MSVC-CXX.cmake} (100%)
copy Modules/Platform/{WindowsCE.cmake = WindowsStore.cmake} (100%)
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-4865-g3e510c4
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 3e510c4e348f3d029cf56f3774eec97b609aa544 (commit) via 7365a9fe929c935a194987d3a4a68aff77129a2b (commit) from 971b990718b75dd8848e795a07294d8f7594b9a7 (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=3e510c4e348f3d029cf56f3774eec97b609aa544 commit 3e510c4e348f3d029cf56f3774eec97b609aa544 Merge: 971b990 7365a9f Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 10:04:40 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Aug 12 10:04:40 2014 -0400 Merge branch 'master' into next --- 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, next, updated. v3.0.1-4875-g6b923df
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 6b923df4c355496816aefbe5793d892d4ac907d1 (commit) via 1f8cfc3b5f4bd87216e48c6bf909b59f10b9065e (commit) from 2ba239f0a6fffcb3e165aa3c4dc69893566a071c (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=6b923df4c355496816aefbe5793d892d4ac907d1 commit 6b923df4c355496816aefbe5793d892d4ac907d1 Merge: 2ba239f 1f8cfc3 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 10:18:59 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Aug 12 10:18:59 2014 -0400 Merge branch 'master' into next --- 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, next, updated. v3.0.1-4881-g561267f
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 561267f15216de102807a42e043b9aebe1ea5388 (commit)
via 962d179d46462ac6fb4c1076f33b69bda65dbbb0 (commit)
via 19880cc55d5913c53692b78ca53bbd15360cef50 (commit)
via 34729294e5a5c6e23ba1d41127c5ca6f1832596d (commit)
via a934a846438beb31d664caf7fc93c965aaf3ca50 (commit)
via 9ef7e0863706f629c8e6360ff599003082bca4cf (commit)
from 6b923df4c355496816aefbe5793d892d4ac907d1 (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=561267f15216de102807a42e043b9aebe1ea5388
commit 561267f15216de102807a42e043b9aebe1ea5388
Merge: 6b923df 962d179
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 10:20:51 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 12 10:20:51 2014 -0400
Merge topic 'vs-masm' into next
962d179d VS: Add test for MASM support
19880cc5 VS: Add MASM support to VS 8 and 9 (#8170, #14984)
34729294 VS: Move internal MasmEnabled member up to VS 7 generator
a934a846 VS: Fix ASM_MASM support in VS = 10
9ef7e086 cmLocalVisualStudio7Generator: Rename local 'lang' var
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=962d179d46462ac6fb4c1076f33b69bda65dbbb0
commit 962d179d46462ac6fb4c1076f33b69bda65dbbb0
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Aug 7 14:53:57 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Aug 12 10:06:36 2014 -0400
VS: Add test for MASM support
It is now expected to work with VS = 8 and MSVC = 13.0 for i386.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index ca7fcdc..691e503 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 CMAKE_SIZEOF_VOID_P EQUAL 4
+ AND NOT MSVC60 AND NOT CMAKE_GENERATOR MATCHES Visual Studio [67]( |$))
+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..62e818d
--- /dev/null
+++ b/Tests/VSMASM/CMakeLists.txt
@@ -0,0 +1,6 @@
+cmake_minimum_required(VERSION 2.8.12)
+project(VSMASM C ASM_MASM)
+if(NOT CMAKE_SIZEOF_VOID_P EQUAL 4)
+ message(FATAL_ERROR This test works only with i386 architecture.)
+endif()
+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..2a4519c
--- /dev/null
+++ b/Tests/VSMASM/foo.asm
@@ -0,0 +1,8 @@
+.386
+.model flat, c
+.code
+foo proc public
+ mov eax,0
+ ret
+foo endp
+end
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(); }
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19880cc55d5913c53692b78ca53bbd15360cef50
commit 19880cc55d5913c53692b78ca53bbd15360cef50
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Aug 7 15:20:49 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Aug 12 10:06:36 2014 -0400
VS: Add MASM support to VS 8 and 9 (#8170, #14984)
diff --git a/Source/cmLocalVisualStudio7Generator.cxx
b/Source/cmLocalVisualStudio7Generator.cxx
index 29165f8..d2b2bf7 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -862,6 +862,14 @@ void
cmLocalVisualStudio7Generator::WriteConfiguration(std::ostream fout,
}
}
fout /\n; // end of Tool Name=VCCLCompilerTool
+ if(gg-IsMasmEnabled() !this-FortranProject)
+{
+fout
+ \t\t\tTool\n
+ \t\t\t\tName=\MASM\\n
+ \t\t\t/\n
+ ;
+}
tool = VCCustomBuildTool;
if(this-FortranProject)
{
@@ -1700,6 +1708,7 @@ bool cmLocalVisualStudio7Generator
{
aCompilerTool = VFFortranCompilerTool;
}
+std::string const lang = (*sf)-GetLanguage();
std::string ext = (*sf)-GetExtension();
ext = cmSystemTools::LowerCase(ext);
if(ext == idl)
@@ -1727,6 +1736,11 @@ bool cmLocalVisualStudio7Generator
aCompilerTool = VFCustomBuildTool;
}
}
+if (gg-IsMasmEnabled() !this-FortranProject
+lang == ASM_MASM)
+ {
+ aCompilerTool = MASM;
+ }
[Cmake-commits] CMake branch, next, updated. v3.0.1-4883-gd905333
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 d905333fad73754b594872e67e0e979f31a1b0ab (commit)
via fbf7a9297571b7e26739009d7026fbe21c3ccbc7 (commit)
from 561267f15216de102807a42e043b9aebe1ea5388 (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=d905333fad73754b594872e67e0e979f31a1b0ab
commit d905333fad73754b594872e67e0e979f31a1b0ab
Merge: 561267f fbf7a92
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 13:58:11 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 12 13:58:11 2014 -0400
Merge topic 'makefile-assign-escape-octothorpe' into next
fbf7a929 Makefile: Handle '#' in COMPILE_OPTIONS (#15070)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fbf7a9297571b7e26739009d7026fbe21c3ccbc7
commit fbf7a9297571b7e26739009d7026fbe21c3ccbc7
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 13:26:03 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Aug 12 13:56:21 2014 -0400
Makefile: Handle '#' in COMPILE_OPTIONS (#15070)
Teach the Makefile generators to escape '#' characters on the right hand
side of variable assignments in flags.make. This is needed for flags
like '-Wno-error=#warnings'. Otherwise the make tool treats them as
comments and leaves them out of the _FLAGS variable value.
Add a case to the CompileOptions test covering '#' in a COMPILE_OPTIONS
value, at least on compilers where it is known to be supported.
diff --git a/Source/cmMakefileTargetGenerator.cxx
b/Source/cmMakefileTargetGenerator.cxx
index 758c8e4..7849d12 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -361,9 +361,13 @@ void cmMakefileTargetGenerator::WriteTargetLanguageFlags()
for(std::setstd::string::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
-*this-FlagFileStream *l _FLAGS = this-GetFlags(*l) \n\n;
-*this-FlagFileStream *l _DEFINES = this-GetDefines(*l)
- \n\n;
+std::string flags = this-GetFlags(*l);
+std::string defines = this-GetDefines(*l);
+// Escape comment characters so they do not terminate assignment.
+cmSystemTools::ReplaceString(flags, #, \\#);
+cmSystemTools::ReplaceString(defines, #, \\#);
+*this-FlagFileStream *l _FLAGS = flags \n\n;
+*this-FlagFileStream *l _DEFINES = defines \n\n;
}
}
diff --git a/Tests/CompileOptions/CMakeLists.txt
b/Tests/CompileOptions/CMakeLists.txt
index 9b6c9c2..05a5f82 100644
--- a/Tests/CompileOptions/CMakeLists.txt
+++ b/Tests/CompileOptions/CMakeLists.txt
@@ -22,6 +22,12 @@ set_property(TARGET CompileOptions PROPERTY COMPILE_OPTIONS
${cxx_tests}
)
+if(CMAKE_CXX_COMPILER_ID MATCHES GNU|Clang|Borland)
+ set_property(TARGET CompileOptions APPEND PROPERTY COMPILE_OPTIONS
+-DTEST_OCTOTHORPE=\#\
+)
+endif()
+
target_link_libraries(CompileOptions testlib)
if(CMAKE_CXX_COMPILER_ID MATCHES GNU)
diff --git a/Tests/CompileOptions/main.cpp b/Tests/CompileOptions/main.cpp
index 42f4cca..f3c1355 100644
--- a/Tests/CompileOptions/main.cpp
+++ b/Tests/CompileOptions/main.cpp
@@ -17,6 +17,9 @@
int main()
{
return (strcmp(NEEDS_ESCAPE, E$CAPE) == 0
+#ifdef TEST_OCTOTHORPE
+ strcmp(TEST_OCTOTHORPE, #) == 0
+#endif
strcmp(EXPECTED_C_COMPILER_VERSION, TEST_C_COMPILER_VERSION) == 0
strcmp(EXPECTED_CXX_COMPILER_VERSION, TEST_CXX_COMPILER_VERSION) == 0
TEST_C_COMPILER_VERSION_EQUALITY == 1
---
Summary of changes:
Source/cmMakefileTargetGenerator.cxx | 10 +++---
Tests/CompileOptions/CMakeLists.txt |6 ++
Tests/CompileOptions/main.cpp|3 +++
3 files changed, 16 insertions(+), 3 deletions(-)
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-4885-ge0d54b0
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 e0d54b040c808bc7337e01ade615f01f6497a73b (commit)
via e6496b6023a8f3c471e81b1938580d50b52d3222 (commit)
from d905333fad73754b594872e67e0e979f31a1b0ab (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=e0d54b040c808bc7337e01ade615f01f6497a73b
commit e0d54b040c808bc7337e01ade615f01f6497a73b
Merge: d905333 e6496b6
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 12 15:21:16 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 12 15:21:16 2014 -0400
Merge topic 'cpack-ifw-generator' into next
e6496b60 CPackIFW: Revise this generator
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6496b6023a8f3c471e81b1938580d50b52d3222
commit e6496b6023a8f3c471e81b1938580d50b52d3222
Author: Konstantin Podsvirov konstan...@podsvirov.pro
AuthorDate: Tue Aug 12 22:44:02 2014 +0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Aug 12 15:20:59 2014 -0400
CPackIFW: Revise this generator
CPack IFW generator updates:
- Group now can have script;
- Root package (for monolithic or one package installers) can be
configured from group.
CMake updates:
- Native installation (no Unspecified component).
diff --git a/CMakeCPack.cmake b/CMakeCPack.cmake
index b27cd69..66ec900 100644
--- a/CMakeCPack.cmake
+++ b/CMakeCPack.cmake
@@ -65,16 +65,9 @@ if(EXISTS ${CMAKE_ROOT}/Modules/CPack.cmake)
endif()
endif()
- # default component for IFW
- if(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME)
-set(_CPACK_IFW_COMPONENT_NAME ${CMAKE_INSTALL_DEFAULT_COMPONENT_NAME})
- else()
-set(_CPACK_IFW_COMPONENT_NAME Unspecified)
- endif()
- string(TOUPPER ${_CPACK_IFW_COMPONENT_NAME} _CPACK_IFW_COMPONENT_UNAME)
-
if(${CMAKE_SYSTEM_NAME} MATCHES Windows)
-set(_CPACK_IFW_PACKAGE_ICON set(CPACK_IFW_PACKAGE_ICON
\${CMake_SOURCE_DIR}/Source/QtDialog/CMakeSetup.ico\))
+set(_CPACK_IFW_PACKAGE_ICON
+set(CPACK_IFW_PACKAGE_ICON
\${CMake_SOURCE_DIR}/Source/QtDialog/CMakeSetup.ico\))
if(BUILD_QtDialog)
set(_CPACK_IFW_SHORTCUT_OPTIONAL
${_CPACK_IFW_SHORTCUT_OPTIONAL}component.addOperation(\CreateShortcut\,
\@TargetDir@/bin/cmake-gui.exe\, \@StartMenuDir@/CMake
(cmake-gui).lnk\);\n)
endif()
@@ -87,7 +80,7 @@ if(EXISTS ${CMAKE_ROOT}/Modules/CPack.cmake)
install(FILES ${CMake_SOURCE_DIR}/Source/QtIFW/cmake.org.html
DESTINATION .
)
-set(_CPACK_IFW_COMPONENT_SCRIPT
set(CPACK_IFW_COMPONENT_${_CPACK_IFW_COMPONENT_UNAME}_SCRIPT
\${CMake_BINARY_DIR}/installscript.qs\))
+set(_CPACK_IFW_PACKAGE_SCRIPT set(CPACK_IFW_COMPONENT_GROUP_CMAKE_SCRIPT
\${CMake_BINARY_DIR}/installscript.qs\))
endif()
if(${CMAKE_SYSTEM_NAME} MATCHES Linux)
diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index 5127220..57ed4ca 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -32,22 +32,25 @@ endif()
include(@QT_DIALOG_CPACK_OPTIONS_FILE@ OPTIONAL)
if(CPACK_GENERATOR MATCHES IFW)
- # Version with QtIFW limitations
- set(CPACK_PACKAGE_VERSION @_CPACK_IFW_PACKAGE_VERSION@)
# Installer configuration
set(CPACK_IFW_PACKAGE_TITLE CMake Build Tool)
set(CPACK_IFW_PRODUCT_URL http://www.cmake.org;)
@_CPACK_IFW_PACKAGE_ICON@
- set(CPACK_IFW_PACKAGE_WINDOW_ICON
@CMake_SOURCE_DIR@/Source/QtDialog/CMakeSetup128.png)
- # Enable install default component
- set(CPACK_COMPONENTS_ALL @_CPACK_IFW_COMPONENT_NAME@)
- # Component configuration
- set(CPACK_COMPONENT_@_CPACK_IFW_COMPONENT_UNAME@_DISPLAY_NAME
@CPACK_PACKAGE_NAME@)
- set(CPACK_COMPONENT_@_CPACK_IFW_COMPONENT_UNAME@_DESCRIPTION
@CPACK_PACKAGE_DESCRIPTION_SUMMARY@)
- # IFW component onfiguration
- set(CPACK_IFW_COMPONENT_@_CPACK_IFW_COMPONENT_UNAME@_NAME
@CPACK_PACKAGE_NAME@)
- set(CPACK_IFW_COMPONENT_@_CPACK_IFW_COMPONENT_UNAME@_LICENSES
@CPACK_PACKAGE_NAME@ Copyright @CPACK_RESOURCE_FILE_LICENSE@)
- @_CPACK_IFW_COMPONENT_SCRIPT@
+ set(CPACK_IFW_PACKAGE_WINDOW_ICON
+@CMake_SOURCE_DIR@/Source/QtDialog/CMakeSetup128.png)
+ # Package configuration group
+ set(CPACK_IFW_PACKAGE_GROUP CMake)
+ # Group configuration
+ set(CPACK_COMPONENT_GROUP_CMAKE_DISPLAY_NAME
+@CPACK_PACKAGE_NAME@)
+ set(CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION
+@CPACK_PACKAGE_DESCRIPTION_SUMMARY@)
+ # IFW group configuration
+ set(CPACK_IFW_COMPONENT_GROUP_CMAKE_VERSION
+@_CPACK_IFW_PACKAGE_VERSION@)
+ set(CPACK_IFW_COMPONENT_GROUP_CMAKE_LICENSES
+@CPACK_PACKAGE_NAME@ Copyright @CPACK_RESOURCE_FILE_LICENSE@)
+ @_CPACK_IFW_PACKAGE_SCRIPT@
[Cmake-commits] CMake branch, next, updated. v3.0.1-4887-g3f66f2f
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 3f66f2fbe8f6c27d4bf541fa32c91582f7078174 (commit) via 63fc8dcdb82e91b7218aab959d75f924f6a01bc1 (commit) from e0d54b040c808bc7337e01ade615f01f6497a73b (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=3f66f2fbe8f6c27d4bf541fa32c91582f7078174 commit 3f66f2fbe8f6c27d4bf541fa32c91582f7078174 Merge: e0d54b0 63fc8dc Author: Brad King brad.k...@kitware.com AuthorDate: Tue Aug 12 15:51:08 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Aug 12 15:51:08 2014 -0400 Merge topic 'create_test_sourcelist-msvc-warnings' into next 63fc8dcd create_test_sourcelist: Suppress MSVC warnings in test driver (#15066) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63fc8dcdb82e91b7218aab959d75f924f6a01bc1 commit 63fc8dcdb82e91b7218aab959d75f924f6a01bc1 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Aug 7 09:15:17 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Aug 7 09:17:44 2014 -0400 create_test_sourcelist: Suppress MSVC warnings in test driver (#15066) Suggested-by: Ken Moreland kmo...@sandia.gov diff --git a/Templates/TestDriver.cxx.in b/Templates/TestDriver.cxx.in index 0e0a872..ffa6999 100644 --- a/Templates/TestDriver.cxx.in +++ b/Templates/TestDriver.cxx.in @@ -3,6 +3,10 @@ #include string.h #include stdlib.h +#if defined(_MSC_VER) +# pragma warning(disable:4996) /* deprecation */ +#endif + @CMAKE_TESTDRIVER_EXTRA_INCLUDES@ --- Summary of changes: Templates/TestDriver.cxx.in |4 1 file changed, 4 insertions(+) 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-1685-g5891b36
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 5891b36640aaf95b53441870d95d90d4aaeb1971 (commit) from 1f8cfc3b5f4bd87216e48c6bf909b59f10b9065e (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=5891b36640aaf95b53441870d95d90d4aaeb1971 commit 5891b36640aaf95b53441870d95d90d4aaeb1971 Author: Kitware Robot kwro...@kitware.com AuthorDate: Wed Aug 13 00:01:10 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Wed Aug 13 00:01:10 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index dffdbd1..b9c3034 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 20140812) +set(CMake_VERSION_PATCH 20140813) #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
