[cmake-developers] [CMake 0015444]: include_directories is case insensitive usually, but is case sensitive in files inside subfolders
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15444
==
Reported By:alean79
Assigned To:
==
Project:CMake
Issue ID: 15444
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-03-13 13:40 EDT
Last Modified: 2015-03-13 13:40 EDT
==
Summary:include_directories is case insensitive usually, but
is case sensitive in files inside subfolders
Description:
I have a project that was developed in Windows environment, so the #include
sentences was developed in case insensitive way (there are a LOT of differences
between the name of the .hpp included, and the real name of the .hpp file).
I imported that project in a Linux environment, and configured cmake with the
following clause:
include_directories(
SYSTEM ${PROJECT_SOURCE_DIR}/inc)
Inside the inc folder there are .hpp files, but there are subfolders with
aditional .hpp files. In my code, the .hpp files that are in the inc folder
are recognized correctly, beside the case problems. But the files in the
subfolders are NOT recognized if there are case differences.
Example:
${PROJECT_SOURCE_DIR}
|
|-- inc
|
|-- vpp = subfolder
||
||-- vpp.hpp = header file
|
|-- flags.hpp = header file
If I include the second header file with the following sentence, the file is
recognized correctly:
#include flags.hpp
But, if I include the first header file with the following sentence, the file is
NOT found:
#include vpp/vpp.hpp
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-13 13:40 alean79New Issue
2015-03-13 13:40 alean79File Added: CMakeLists.txt
==
--
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
[cmake-developers] [CMake 0015445]: Interface in Russian Language
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15445 == Reported By:abductor Assigned To: == Project:CMake Issue ID: 15445 Category: CMake Reproducibility:N/A Severity: major Priority: low Status: new == Date Submitted: 2015-03-13 14:07 EDT Last Modified: 2015-03-13 14:07 EDT == Summary:Interface in Russian Language Description: I use CMake 2.8.10.2. And I will use 3.2.1 on next week. Cool, what file name in path maybe in Russian language in 3.2.1. I wont help to translate interface and message in russian language. == Issue History Date ModifiedUsername FieldChange == 2015-03-13 14:07 abductor New Issue == -- 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
[cmake-developers] [CMake 0015446]: In verbose mode, display env vars that were explicitly set for each test
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15446 == Reported By:Zach Mullen Assigned To: == Project:CMake Issue ID: 15446 Category: CTest Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-03-13 17:29 EDT Last Modified: 2015-03-13 17:29 EDT == Summary:In verbose mode, display env vars that were explicitly set for each test Description: We use set_property with the ENVIRONMENT property for many of our tests to control their runtime behavior. When running in verbose mode we see the full command line that is executed, but not the environment variables that were explicitly set for the test invocation. It would be nice to include those. == Issue History Date ModifiedUsername FieldChange == 2015-03-13 17:29 Zach MullenNew Issue == -- 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] Generating buildsystem metadata from CMake
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.
The aim is to generate a structured file containing metadata relating the
buildsystem.
To help with completing the design of this feature, I've written
documentation (documentation driven design), and a unit test
containing a CMakeLists.txt file which exercises many modern CMake
features in the generate-metadata branch in my clone.
Mostly the design I propose can be read in the documentation I wrote. I'm
interested in any feedback.
https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt
http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html
I expect to require a few iterations to figure out what the metadata files
should contain in the end. Note that there are already some differences
between my design and Aleix's implementation, such as that my design
proposes one metadata file per config. There are also some things
missing like location, because it is not yet clear to me whether build
or install locations are needed etc.
The content of the metadata file is determined by the build properties, and
is necessarily similar to the compile-related content created when
generating the actual buildsystem. It additionally contains information
about the output locations of build artifacts and information relating to
the cmake description itself.
Goals include:
* Make it possible for IDEs to access the compile-related information for
autocompletion and code navigation etc purposes.
* Remove the need for IDEs to parse generated Makefiles or Ninja files to
access compile-related information. The structure of those files is not
'stable', while the content of the metadata file is stable.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081
* Remove the need for users to create a new build directory and new build
in order to use or switch IDEs. QtCreator requires that
the C::B 'extra generator is used as it parses compile information from
that. Other 'extra generators' such as for eclipse, sublime, kate etc
also require fresh/new build directories, although the actual buildsystem
they create is identical (assuming using all Makefile based or
all Ninja based 'extra generators')
* Make it possible to write a plugin for the editors/IDEs such as sublime
which consumes the metadata file and invokes the build using whatever
buildsystem the user already has a build directory for, instead of
writing an 'extra generator' and maintaining it in the cmake repo.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004
* Make it possible for editors/IDEs to allow specifying the configuration
at build-time, where the IDE has that feature, and where a multi-config
generator is available. That is, QtCreator provides user-interface for
choosing debug/release config to build. Currently it can't offer that
when using cmake, because it only allows the use of Makefile or Ninja
generators, in order to make use of the C::B file. QtCreator should be
able to use the Xcode or Visual Studio generators, generate the metadata
file(s), and invoke `cmake --build . --config ${CONFIG}` as
appropriate. Eclipse, Sublime and other editors have similar abilities
to invoke config-specific builds after generation.
* Provide a list of 'build targets', which can be listed and invoked in
IDE/editor user interface. Build targets for all linked binaries
and utilties are provided. The tooling is expected to perform filtering
on the target types to show only executables and utilities for
execution, for example.
* Provide a list of source files per target per type of source file, eg
object sources, header files, generated files, files excluded from the
active configuration/platform/compiler, non-compiled files.
* Make it more easy for an IDE to support actions such as 'remove file
from the project', which requires removing it from the CMakeLists.txt
at the appropriate place, and 'add new file/class to target', which
involves adding code to the CMakeLists.txt file at the appropriate
place. Most likely the easiest way to do the latter is using the
target_sources() command, and to support the former, the location of
the declaration of the target, and all target_sources() calls would
need to be recorded. Even that is not enough because of transitive
consumption of
[cmake-developers] [CMake 0015442]: Test 124 fails, space before colon in check_file_match_expected_relocation_path
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15442 == Reported By:Daniel TISCHER Assigned To: == Project:CMake Issue ID: 15442 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-13 03:18 EDT Last Modified: 2015-03-13 03:18 EDT == Summary:Test 124 fails, space before colon in check_file_match_expected_relocation_path Description: The following tests FAILED: 124 - CPackComponentsForAll-RPM-IgnoreGroup (Failed) 124: error: 124: '/home/quickbuild/workspace/root/packages/cmake/BUILD/cmake-3.2.1/build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm' 124: rpm package relocation path does not match expected value - regex 124: 'Relocations : /usr/foo/bar /usr/foo/bar/include'; RPM output: 'Name : 124: mylib-headers Relocations: /usr/foo/bar /usr/foo/bar/include [root@jawas ~]# rpm -qpi /home/quickbuild/workspace/root/packages/cmake/BUILD/cmake-3.2.1/build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm Name: mylib-headersRelocations: /usr/foo/bar /usr/foo/bar/include Version : 1.0.2 Vendor: CMake.org Release : 1 Build Date: Thu 12 Mar 2015 09:36:37 PM CET -- there is no space between Relocations and colon : Steps to Reproduce: run tests Additional Information: RunCPackVerifyResult.cmake lines 167, 174, 180, 186 set(check_file_match_expected_relocation_path Relocations : --^ [root@jawas ~]# rpm --version RPM version 4.8.0 == Issue History Date ModifiedUsername FieldChange == 2015-03-13 03:18 Daniel TISCHER New Issue == -- 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
[cmake-developers] RFC: Helper macros for writing Find modules
For the extra-cmake-modules package, I wrote some macros to help with writing component-based Find modules, which are non-trivial to get right. The documentation for them can be found here: http://api.kde.org/ecm/module/ECMFindModuleHelpers.html I've found them incredibly useful in writing classic Find modules, where you just want to find a bunch of libraries and their associated headers, but you also need to account for the dependencies between those libraries. The interface is a little unusual: you have to set up some information- providing variables before calling the macros to describe the information for each component. As an example, see http://quickgit.kde.org/?p=extra-cmake-modules.gita=blobh=c5a56c1635d03acdaf5ccd780b9a358d6f6655fdhb=4f81d1a92e4ccc2ce7b33d2860397a526b1a4d2ff=find-modules%2FFindWayland.cmake (which I would also submit for inclusion to CMake if this is accepted). Would this be something that might be included in CMake? I have some ideas about how to extend it to be able to account for debug vs release libraries as well (roughly following a simplified version of the pattern of the FindQt4 module). 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-developers
[cmake-developers] [CMake 0015443]: Unable to use target_compile_features with MinGW-w64
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15443
==
Reported By:David Demelier
Assigned To:
==
Project:CMake
Issue ID: 15443
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2015-03-13 04:42 EDT
Last Modified: 2015-03-13 04:42 EDT
==
Summary:Unable to use target_compile_features with MinGW-w64
Description:
The following CMakeLists.txt generates an error on MinGW-w64:
cmake_minimum_required(VERSION 3.2)
project(test)
add_executable(main main.cpp)
target_compile_features(
main
PRIVATE
cxx_constexpr
)
This is the error:
CMake Error at CMakeLists.txt:6 (target_compile_features):
target_compile_features no known features for CXX compiler
GNU
version 4.9.2.
Steps to Reproduce:
1. Try to use target_compile_features with MinGW-w64
Additional Information:
It seems that Modules/Compiler/GNU-CXX.cmake has useless UNIX conditionals:
Changing lines 47 and 50 to the following fix the problem:
set(_result 0)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.8)
_get_gcc_features(${CMAKE_CXX14_STANDARD_COMPILE_OPTION}
CMAKE_CXX14_COMPILE_FEATURES)
endif()
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.4)
if (_result EQUAL 0)
_get_gcc_features(${CMAKE_CXX11_STANDARD_COMPILE_OPTION}
CMAKE_CXX11_COMPILE_FEATURES)
endif()
if (_result EQUAL 0)
_get_gcc_features(${CMAKE_CXX98_STANDARD_COMPILE_OPTION}
CMAKE_CXX98_COMPILE_FEATURES)
endif()
endif()
Please note that MinGW-w64 fully supports C++11 and C++14.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-13 04:42 David Demelier New Issue
==
--
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] Generating buildsystem metadata from CMake
On 03/11/2015 11:10 AM, Stephen Kelly wrote: I'm starting to gather requirements and make sure the feature is well designed to satisfy the needs we're already aware of, and fits with the features CMake currently has. Source file groups (as in defined by source_group()) and target folders (as in the FOLDER target property) may be of interest to IDEs to layout target and source file hierarchies. Nils -- 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] RFC: CMake precompiled header support and custom compiler based implementation
On Wed, Mar 4, 2015 at 8:53 PM, Brad King brad.k...@kitware.com wrote: On 03/03/2015 07:43 AM, Adam Strzelecki wrote: On 03/01/2015 08:02 PM, Ben Boeckel wrote: On 02/28/2015 11:59 AM, Adam Strzelecki wrote: target_precompiled_header(target path/to/precompiled_header.h) target_precompiled_header(target path/to/precompiled_header.h SHARED other_target_to_share_precompiled_header_with) Could we rename this? Currently target_* functions are all related to usage requirements and these are not usage requirements. Honestly I don't understand your request. What would be then the name that better represents what the function does. Currently the target_* commands are: target_compile_definitions target_compile_features target_compile_options target_include_directories target_link_libraries target_sources They all have the general signature target_command(target [options] [SCOPE items...]...) where SCOPE is INTERFACE, PUBLIC, or PRIVATE and affects whether the settings apply to sources in the target itself and/or its dependents. The proposed target_precompiled_header signature does not fit into this layout. Either a different command name is needed or one needs to define the command signature and semantics to fit the above layout. Do PCHs fit into usage requirements in any way? That would be nice, right? I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch Expect it to be incomplet and incorrekt. It certainly needs a couple of iterations, but the direction should be clear: add_library(foo foo.c) target_include_directories(foo PUBLIC include) target_precompile_headers(foo PUBLIC foo.h) add_library(bar INTERFACE) target_include_directories(bar INTERFACE include) target_precompile_headers(bar INTERFACE bar.h) add_executable(foobar foobar.c) target_link_libraries(foobar foo bar) There is a new command called target_precompile_headers. This name is chosen carefully. * It says precompile headers, not precompiled header. This command is used to set a list of headers to precompile. It is not used to specify a single prebuilt file. * It has a target_ prefix, and the expectations about usage requirements should be satisfied. Things to keep in mind: * We probably want to precompile headers based on configuration. * For generators that support it (Makefile + Ninja), we want to precompile headers based on the compile language. * We probably want to enable/disable the use of PCH globally, on a per-target-level, and on a per-source-level. In meantime https://github.com/nanoant/CMakePCHCompiler is just an implementation that emulates desired behavior using many tricks. But I don't want this to be a part of CMake, but instead I want this to be handled natively adding some extra variables: Good. That means we are on the same page. I was a little confused when I first saw your approach. :-) cheers, Daniel -- 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] Generating buildsystem metadata from CMake
On 03/11/2015 11:10 AM, Stephen Kelly wrote: Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 The discussion in that thread is causing people confusion (eg regarding an obsolete approach to config and CMAKE_BUILD_TYPE). Please discontinue the discussion there. My branch is the way forward. I extended my branch to contain not only test and documentation but also an implementation and a generated file from my computer, so that you can read it/try it and give feedback. Obviously the branch needs to be broken up into multiple commits, but that something to do when this is not a prototype anymore. We are still in a design discussion. I pushed the implementation only because I know you guys won't discuss the design of the feature on its own and you want to have an implementation asap. However, this is still a design discussion, and all of the questions in my previous mail are still valid. Thanks, Steve. -- 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] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
These sounds like easy changes, but I probably won't be able to update and test
it until the middle of next week.
Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Thursday, March 12, 2015 2:18 PM
To: Geoffrey Viola
Cc: cmake-developers@cmake.org
Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 03/11/2015 01:39 PM, Geoffrey Viola wrote:
Attached is a patch with the recommended changes
Thanks! The basic toolchain initialization is pretty close.
Here are more comments.
In Modules/Platform/GHS-MULTI-Initialize.cmake:
+#Setup consistent compiler executables
+find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT})
+find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT})
This should not be needed at all. The CMAKE_GENERATOR_* variables are just
hints to the compiler detection logic. Since this generator hard-codes the
compiler setting in C++ the logic that uses these variables is never executed
anyway.
+string(REGEX MATCH (comp_)([0-9]+) CMAKE_SYSTEM_VERSION
+${CMAKE_MAKE_PROGRAM}) string(REPLACE comp_
+CMAKE_SYSTEM_VERSION ${CMAKE_SYSTEM_VERSION})
EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has
code to find the comp root.
+mark_as_advanced(CMAKE_MAKE_PROGRAM)
This should not be needed.
+include(Platform/WindowsPaths)
This should move to Modules/Platform/GHS-MULTI.cmake
In EnableLanguage:
+ mf-AddDefinition(CMAKE_MAKE_PROGRAM,
+std::string(ghsCompRootStart +
+ gbuild.exe).c_str());
The VS and Xcode generators no longer put this in the cache.
Take a look at how the Xcode generator now does this with
cmGlobalXCodeGenerator::FindMakeProgram
cmGlobalXCodeGenerator::GetXcodeBuildCommand
cmGlobalXCodeGenerator::FindXcodeBuildCommand
and its call to SelectMakeProgram in GenerateBuildCommand:
this-SelectMakeProgram(makeProgram, this-GetXcodeBuildCommand())
Together this all allows the generator to compute the proper build tool without
exposing any settings to the user.
+ mf-AddDefinition(CMAKE_C_COMPILER_ID, GhsMultiArmC);
[snip]
+ mf-AddDefinition(CMAKE_CXX_COMPILER_ID, GhsMultiArmCXX);
Instead of GhsMultiArm* these should be just GHS, to be consistent with
Modules/Compiler/GHS-DetermineCompiler.cmake.
-
Please also look at modifying the Help/ directory to document the new
generator. You'll need at least to create/update:
Help/manual/cmake-generators.7.rst
Help/generator/Green Hills MULTI.rst
Help/variable/CMAKE_MAKE_PROGRAM.rst
where the change to the last one depends on the above updates.
Thanks,
-Brad
This message contains confidential information and is intended only for the
recipient. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately if you
have received this e-mail by mistake and delete this e-mail from your system.
Finally, the recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
--
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
