[cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3
dear CMake developers, We have observed a changed and surprising behavior in CMake 3.3.0-rc3 with Fortran module dependency scanning and preprocessing compared to earlier CMake versions (for instance 3.2.3). I have checked open bugs and email list archives but could not find this mentioned. To give an example the following Fortran source fails to compile: program example #ifdef SOMEDEF use mymodule #endif call hello() end program with: main.F90:3:7: use mymodule 1 Fatal Error: Can't open module file ‘mymodule.mod’ for reading at (1): No such file or directory It seems that Fortran dependencies are scanned prior to pre-processing. This seems different compared to 3.2.3 (and earlier versions). Not sure this is a bug or a feature. All relevant files (CMakeLists.txt, main.F90, mymodule.F90) for a complete minimal example are attached. I can also submit this directly to http://www.cmake.org/Bug/ in case this is not a feature. Thank you and best wishes, radovan cmake_minimum_required(VERSION 2.8 FATAL_ERROR) project(example) enable_language(Fortran) add_definitions(-DSOMEDEF) add_executable(example.x main.F90 mymodule.F90) #ifdef SOMEDEF module mymodule contains subroutine hello() print *, 'hello' end subroutine end module #else subroutine empty() end subroutine #endif program example #ifdef SOMEDEF use mymodule #endif call hello() end program -- 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] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3
On 07/02/2015 04:14 AM, Radovan Bast wrote: We have observed a changed and surprising behavior in CMake 3.3.0-rc3 with Fortran module dependency scanning and preprocessing compared to earlier CMake versions (for instance 3.2.3). I don't recall any changes related to this since 3.2. I also cannot reproduce the problem with the example you provided. It seems that Fortran dependencies are scanned prior to pre-processing. CMake does its own approximate preprocessing for dependency scanning. This hasn't changed in a long time. Can you please provide a more complete example to reproduce this? Or, if you can consistently reproduce it locally please try bisecting our Git history between 3.2 and 3.3 to see if you can find the commit that introduced the problem. 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] CMake adds -qalias=noansi by XLC
On 07/01/2015 12:14 PM, Todd Gamblin wrote: - Is there some reason CMake adds the -qalias=noansi arg for XLC? It was added here: Add initial XL C compiler flags for safer builds http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1729238 but I don't recall why it was included among the other defaults and the commit message doesn't say anything about it :( - Could it be removed in future versions for consistency with other compilers' C++ settings? Yes, we can try dropping it: XL: Drop -qalias=noansi from default C flags http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a33fb493 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
What is the difference between the intended uses of those existing options and the intended uses of the new options, given that -Wno-dev is mostly useful for third parties to silence policy warnings? Working on this issue, I did find the different variables/options a bit confusing. dev and deprecated both change the effect of message modes, pretty much doing the same thing but slightly different (for example there is -Wdev and -Wno-dev, but not -Werror=dev or -Wno-error=dev). Would it be worth refactoring the -W dev options to be in line with the -W deprecated options? If the new options are merged to master should -Wdev and -Wno-dev also be changed to affect CMAKE_WARN_DEPRECATED? That would be sensible behaviour to me, shall I modify cmake::Configure to do this? Cheers, Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
Sorry, I've added in the missing method to cmake.cxx, which updates the
WarningLevel map according to the boolean provided. cmake-gui compiles
without errors again.
I could add support for the new options to the GUI, in which case I
would probably also go back to the changes I made to cmake.cxx and make
the code related to WarningLevel a bit more generic and replace
instances of dev and deprecated with constants to make the changes a
bit more maintainable.
Cheers,
Michael
On 25/06/2015 15:50, Brad King wrote:
On 06/24/2015 05:30 PM, Michael Scott wrote:
Thanks for the comments, here is the previous patch, with the suggested
amendments.
Thanks.
This hunk:
- void SetSuppressDevWarnings(bool v)
-{
- this-SuppressDevWarnings = v;
- this-DoSuppressDevWarnings = true;
-}
causes the cmake-gui Qt dialog to fail to compile:
$ git grep SetSuppressDevWarnings
Source/QtDialog/QCMake.cxx:
this-CMakeInstance-SetSuppressDevWarnings(this-SuppressDevWarnings);
Sorry I didn't notice that last time.
Please enable the BUILD_QtDialog option at CMake build time to
build this part and make sure it compiles after the changes.
It would be nice to also provide settings in cmake-gui for
these deprecation levels (as there is for -Wdev), but I won't
make that a requirement for acceptance of the patch.
Thanks,
-Brad
From c19b143756a9ecf800ac42a37dd2d4bac64d7025 Mon Sep 17 00:00:00 2001
From: Michael Scott michael.scott...@gmail.com
Date: Sat, 13 Jun 2015 18:34:31 +0100
Subject: [PATCH] Refactored the -Wdev and -Wno-dev to use a generic -W parser,
which follows the GCC pattern. Included support for setting
CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED via the deprecated warning.
Added tests for new options and updated cmake documentation and release notes
to list new options.
---
Help/manual/OPTIONS_BUILD.txt | 24
Help/release/dev/cmake-Wdeprecated.rst | 9 ++
Help/variable/CMAKE_ERROR_DEPRECATED.rst | 4 +
Help/variable/CMAKE_WARN_DEPRECATED.rst| 4 +
Source/cmake.cxx | 127 ++---
Source/cmake.h | 24 ++--
Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 37 ++
Tests/RunCMake/CommandLine/W_bad-arg1-result.txt | 1 +
Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt | 2 +
Tests/RunCMake/CommandLine/W_bad-arg2-result.txt | 1 +
Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt | 2 +
Tests/RunCMake/CommandLine/W_bad-arg3-result.txt | 1 +
Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt | 2 +
Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt | 4 +
Tests/RunCMake/CommandLine/Wdeprecated.cmake | 1 +
.../CommandLine/Werror_deprecated-result.txt | 1 +
.../CommandLine/Werror_deprecated-stderr.txt | 4 +
Tests/RunCMake/CommandLine/Werror_deprecated.cmake | 1 +
Tests/RunCMake/CommandLine/Wno-deprecated.cmake| 1 +
.../CommandLine/Wno-error_deprecated.cmake | 1 +
20 files changed, 223 insertions(+), 28 deletions(-)
create mode 100644 Help/release/dev/cmake-Wdeprecated.rst
create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-result.txt
create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt
create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-result.txt
create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt
create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt
create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt
create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt
create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated.cmake
create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-result.txt
create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt
create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated.cmake
create mode 100644 Tests/RunCMake/CommandLine/Wno-deprecated.cmake
create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake
diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt
index 4207db4..5366cae 100644
--- a/Help/manual/OPTIONS_BUILD.txt
+++ b/Help/manual/OPTIONS_BUILD.txt
@@ -84,3 +84,27 @@
Enable warnings that are meant for the author of the CMakeLists.txt
files.
+
+``-Wdeprecated``
+ Enable deprecated macro and function warnings.
+
+ Enable warnings for usage of deprecated macros and functions, that are meant
+ for the author of the CMakeLists.txt files.
+
+``-Wno-deprecated``
+ Suppress deprecated macro and function warnings.
+
+ Suppress warnings for usage of deprecated macros and functions, that are
meant
+ for the author of the CMakeLists.txt files.
+
+``-Werror=deprecated``
+ Make deprecated macro and function warnings errors.
+
+ Make warnings for usage of deprecated macros and functions, that are meant
+ for the author of the CMakeLists.txt files, errors.
+
[cmake-developers] Feature Request: Modify CXX_STANDARD behavior for Xcode Generator: Starting Tips?
Salutations. I right now use CXX_STANDARD and CXX_STANDARD_LIBRARY for some test projects since I want to utilize smart pointers. As I am on a Mac, my preferred IDE is Xcode (sometimes called XCode), so I generate Xcode targets by default. I've noticed, however, that whenever I use CXX_STANDARD and its companions, it places the -std=gnu++11 (or equivalent) calls in the OTHER_CPLUSPLUSFLAGS attribute instead of the CLANG_CXX_LANGUAGE_STANDARD attribute. Here's my current knowledge of this code base to see what currently happens and what needs to be done. - The source file Source/cmGlobalXCodeGenerator.cxx is what generates the Xcode file. - Lines 2272 to 2277 (assuming master branch) are where the OTHER_CPLUSPLUSFLAGS are written. - The flags are coming from either one of cflags[*li] or defFlags. defFlags is filled in via GetDefineFlags() within Source/cmMakefile.h, whereas cflags is filled in with the contents of gflags. - Doing a grep for `gnu++11` gives me either .rst files or .cmake files, but no .h or .cxx files. I guess I'm still a little confused as to where I need to modify the Xcode generator. My questions are thus the following: - Is there a proper source location where the standard is defined? - Which variable does it get set to: cflags or defFlags? - Is there a clean way to remove the std flag and place it in a more Apple friendly location, or would I have to do so? Sincerely, Jason Felds -- 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] Adding Swift support to CMake
On 6/29/15, Brad King brad.k...@kitware.com wrote: On 06/25/2015 09:24 AM, Eric Wing wrote: I pushed up a couple of repos for everybody to try. Thanks. From that I was able to make some progress with getting CMakeDetermineSwiftCompiler to work. I've made two tweaks to CMakeDetermineCompilerId to make it easier to use from a new CMakeDetermineSwiftCompiler module: CMakeDetermineCompilerId: Simplify src reference in IDE projects http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8306108f CMakeDetermineCompilerId: Use per-language regex to match Xcode compiler tool http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6452291c Once these changes test cleanly on nightly builds I will look at the rest of the changes for basic Swift + Xcode. -Brad Thank you Brad. When you are ready, let me know how I can help next. Thanks, Eric -- 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] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3
dear Brad, thanks for testing it on your side and also for the suggestions! I can consistently reproduce it locally on 3 different machines (Ubuntu 14.04 and Arch derivative; gfortran 4.8.4 and 5.1.0). I have Git bisected the history and this is the commit that broke this example on my machines: https://github.com/Kitware/CMake/commit/0b945ea9a6a38d1b3ee27cc32afb4268bd571600 Can you see something possibly related in there? thank you best wishes, radovan On Thu, Jul 2, 2015 at 3:30 PM Brad King brad.k...@kitware.com wrote: On 07/02/2015 04:14 AM, Radovan Bast wrote: We have observed a changed and surprising behavior in CMake 3.3.0-rc3 with Fortran module dependency scanning and preprocessing compared to earlier CMake versions (for instance 3.2.3). I don't recall any changes related to this since 3.2. I also cannot reproduce the problem with the example you provided. It seems that Fortran dependencies are scanned prior to pre-processing. CMake does its own approximate preprocessing for dependency scanning. This hasn't changed in a long time. Can you please provide a more complete example to reproduce this? Or, if you can consistently reproduce it locally please try bisecting our Git history between 3.2 and 3.3 to see if you can find the commit that introduced the problem. 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
