[cmake-developers] [ANNOUNCE] CMake 3.10.0-rc1 is now ready for testing

2017-10-05 Thread Robert Maynard 
I am proud to announce the first CMake 3.10 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.10

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.10/release/3.10.html

Some of the more significant changes in CMake 3.10 are:

* The flang Fortran compiler is now supported, with compiler id
  "Flang".

* Support for the MSVC ARM64 architecture was added. Visual Studio
  2017 Update 4 and above offer an ARM64 toolchain.

* The "include_guard()" command was introduced to allow guarding
  CMake scripts from being included more than once. The command
  supports "DIRECTORY" and "GLOBAL" options to adjust the
  corresponding include guard scope. If no options given, include
  guard is similar to basic variable-based check.

* "FindMPI" received a major overhaul. It now features language specific
  components, better Fortran support, and support for statically linked
  MPI implementations.

* A "FindOpenACC" module was added to detect compiler support for
  OpenACC.  Currently only supports PGI, GNU and Cray compilers.

* The "FindOpenGL" module underwent numerous improvements. It has gained
  support for GLVND and EGL on Linux. It now has import targets that
  separate the OpenGL library and OpenGL contexts.

* The "GoogleTest" module gained a new command
  "gtest_discover_tests()" implementing dynamic (build-time) test
  discovery.

* When using "AUTOMOC" or "AUTOUIC", source files that are
  "GENERATED" will be processed as well. They were ignored by
  "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071".

* A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest
  script variable were added to specify a list of labels that should
  be treated as subprojects by CDash. To use this value in both the
  CTest module and the ctest command line Dashboard Client mode (e.g.
  "ctest -S") set it in the "CTestConfig.cmake" config file.

* CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)",
  configured by the "CPackFreeBSD" module.

* The CPack "DEB" generator, configured by the "CPackDeb" module,
  was enabled on Windows.  While not fully featured (due to the lack
  of external UNIX tools) this will allow building basic cross-
  platform Debian packages.

* The "cmake(1)" "-E" mode gained support for "sha1sum",
  "sha224sum", "sha256sum", "sha384sum", and "sha512sum".

* The "file(GENERATE)" command now interprets relative paths given
  to its "OUTPUT" and "INPUT" arguments with respect to the caller's
  current binary and source directories, respectively. See policy
  "CMP0070".

CMake 3.10 Release Notes


Changes made since CMake 3.9 include the following.


New Features



Platforms
-

* The flang Fortran compiler is now supported, with compiler id
  "Flang".

* A new minimal platform file for "Midipix" was added.

* Support for the MSVC ARM64 architecture was added. Visual Studio
  2017 Update 4 and above offer an ARM64 toolchain.

* Support for the IAR ARM Compiler was improved.


Generators
--

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools like ccache along with the compiler for the
  "CUDA" language ("C" and "CXX" were supported previously).  See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* The "CodeBlocks" extra generator learned to optionally exclude
  files from outside the project root directory from the generated
  project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable.


Commands


* The "cmake_host_system_information()" command learned more keys to
  get information about the processor capabilities and the host OS
  version.

* The "configure_file()" command learned to support indented "#
  cmakedefine" and "#  cmakedefine01". Spaces and/or tabs between the
  "#" character and the "cmakedefine"/"cmakedefine01" words are now
  understood and preserved in the output.

* The "execute_process()" command gained a "RESULTS_VARIABLE" option
  to collect a list of results from all children in a pipeline of
  processes when multiple "COMMAND" arguments are given.

* The "include_guard()" command was introduced to allow guarding
  CMake scripts from being included more than once. The command
  supports "DIRECTORY" and "GLOBAL" options to adjust the
  corresponding include guard scope. If no options given, include
  guard is similar to basic variable-based check.

* The "string()" command learned a new "PREPEND" subcommand.

* The "string(TIMESTAMP)" command now supports "%A" for full weekday
  name and "%B" for full month name.


Variables
-

* A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels
  for all tests in a directory.


Properties
--

* A "_CPPCHECK" target property and supporting
  "CMAKE__CPPCHECK" variable were introduced to tell the
  Makefile Generators and the "Ninja"

Re: [cmake-developers] CMake 3.10 feature freeze on 2017-10-02

2017-10-05 Thread Brad King 
On 10/02/2017 11:48 AM, Brad King wrote:
> I'll announce when post-3.10 development is open.

I've branched 'release' for 3.10.  The repository is now open for
post-3.10 development.  Please rebase open merge requests on 'master'
before staging or merging.

> Meanwhile the following types of changes are still welcome:
> 
> * Documentation updates
> * Regression fixes
> * Dashboard fixes
> * Fixes for bugs in features new to 3.10 or 3.9

These types of changes may still be accepted to 'release' during
the 3.10 release candidate cycle.  The 3.10 release is now closed
to new features and general bug fixes.

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] Extending XCode scheme generation support

2017-10-05 Thread Steven Velez 
Thanks for the followup Gregor.

One thing that concerns me about the property-centric approach is that
I can't think of a way to use properties for generating a custom
scheme that builds the ALL_BUILD target.  I would assume this would
run into the same issues and limitations that I have seen in google
searches with trying to control the the folder for the ALL_BUILD
target with the FOLDER target property (even though this would be a
Visual Studio concern).  It seems that is addressed now with the
*_TARGETS_FOLDER global properties, so maybe an analog can be
established?

Regarding sequencing changes, do you mean to come up with a set of
smaller logical changes/MRs so that this isn't all dumped at once?  If
so, I think we could implement XCODE_SCHEME_NAME and a single
additional property without generator support, then add generator
support, then add the balance of the properties one-by-one.  Would
that make sense?

I have to get more familiar with CMake's testing methodologies to have
any comment on that portion.

If two targets specify the same schema name, then overwrite/accept
latest with a warning?

Regarding ios builds or perhaps having multiple build devices (I have
seen some hand-made projects with 64-bit and 32-bit desktop clients
selectable), then I will also have to get back to you on that.  I was
thinking the property definitions were generic enough to handle any
needs... and I assumed that devices were handles with additional
scheme files, but I realize that was a bad assumption.

Will try to have that thought out soon.

Thanks,
Steven

On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny  wrote:
> Hello Steven,
>
> On 9/22/17 3:36 AM, Steven Velez wrote:
>> # Property-Centric
>> In this proposal, the generation of the scheme files is customized primarily 
>> by
>> a user setting additional, specialized properties on a given target, which 
>> then
>> affect the generation of the scheme files associated with that target.
> thank you for working an the scheme proposal. I also believe that the
> property-centric approach is better suited and easier to implement than
> the file-centrix one.
>
> Next steps would be to sequence the necessary changes and define test
> cases. I could imagine that adding generator-expression support would be
> much harder to implement that other things.
>
> Things that also should be considered are:
> * differences between macOS and iOS when generating a scheme
> * what should happen if two targets specify the same schema name
>
> Thanks,
> Gregor
-- 

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] CMP0071

2017-10-05 Thread Sebastian Holtermann 
> I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence
> CMP0071 warnings. 

It's an unfortunate situation.

In many cases (qt < 5.10) it might work to just let AUTOUIC probe
the (moc/uic/rcc) GENERATED files as well by setting
`cmake_policy(SET CMP0071 NEW)`

-- 

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] CMP0071

2017-10-05 Thread Sebastian Holtermann 
On Mittwoch, 4. Oktober 2017 20:01:50 CEST clin...@elemtech.com wrote:
> - On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org 
wrote:
> >> I updated and I'm getting this:
> >> 
> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
> >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED
> >> files.
> >> Run "cmake --help-policy CMP0071" for policy details. Use the
> >> cmake_policy
> >> command to set the policy and suppress this warning.
> >> 
> >> AUTOMOC: Ignoring GENERATED header file(s):
> >> 
> >> "/path/to/ui_SomeFile.h"
> >> "/path/to/qrc_AnotherFile.cpp"
> >> 
> >> 
> >> Those ui_* and qrc_* files do not require processing by moc.
> >> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
> >> 
> >> I did an experiment and replaced qt5_wrap_ui() with autouic, and the
> >> warning went away for those ui_* files.
> >> 
> >> Is there a way to not print out that policy warning on ui_* and qrc_*
> >> files
> >> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file
> >> types
> >> for which I'm getting that warning.
> > 
> > You can set the source file property SKIP_AUTOMOC on the GENERATED files.
> > See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
> > See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html
> > 
> > For example like this
> > ```
> > set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
> > set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
> > ```
> 
> I'm probably pushing things here, but why not.
> I'm experimenting with setting AUTOMOC/AUTOUIC/AUTORCC on, and also using
> the qt5_* macros.
> 
> I see the rcc processing only looks at *.qrc files, but the uic processing
> looks at files with any extension.  Why not limit that to just *.ui files? 
> I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence
> CMP0071 warnings.  Its obvious to me that a .cpp or .h file is not an xml
> file as expected by uic.
> 
> I can understand having to set SKIP_AUTOMOC on files with various file
> extensions.
> 
> I bring this up here in case something needs to change on the CMake side.

Despite it's name might imply that, AUTOUIC doesn't care about .ui files in the 
target sources. It never did.

AUTOUIC probes the same files as AUTOMOC, that is .h(xx/pp) and .c(xx/pp) 
files. 
In these files it searches for '#include "ui_.h"' strings and derives the 
.ui file names from that (for uic processing).

I don't think that this can (or should) be changed. It's a reasonable behavior 
and a number of projects rely on it. It just is not what people might expect 
at a first glance.





-- 

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