From robert.maynard at kitware.com  Wed Oct  3 10:54:23 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 3 Oct 2018 10:54:23 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.12.3 available for download
Message-ID: <CAFzjYVop-JN4nekx1QLjYrBtzyAR7DZgd5RbgqzOJkE--HV_xQ@mail.gmail.com>

We are pleased to announce that CMake 3.12.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.12.3 since 3.12.2:

Brad King (8):
      CTest: Fix --test-load regression
      FindMPI: Restore MPI_<LANG>_COMPILE_FLAGS as a command-line string
      FindDoxygen: Ensure policy settings allow use of IN_LIST
      libarchive: Backport fix for build with LibreSSL 2.7
      libuv: do not require PATH_MAX to be defined
      VS: Fix CSharp flag selection when linking to a static C++ library
      CSharp: Fix regression in VS project type selection
      CMake 3.12.3

Kyle Edwards (1):
      CTest: Fix regression in ctest_start()

Marc Chevrier (1):
      Help: TESTS property: clarify usage.

From robert.maynard at kitware.com  Tue Oct  9 12:07:38 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 9 Oct 2018 12:07:38 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
Message-ID: <CAFzjYVrNBLs_7Y691GU0YCnhG=5L4kuPCUQ3km+zve4M1XXbdw@mail.gmail.com>

I am proud to announce the first CMake 3.13 release candidate.
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.13 are:

* The Visual Studio Generators for VS 2010 and above learned to
  support the "INTERPROCEDURAL_OPTIMIZATION" target property and
  supporting "CheckIPOSupported" module.

* The "Green Hills MULTI" generator has been updated to include
  support for platform, architecture, and toolset selection.

* The "cmake" command gained the "-S <source_dir>" command line
  option to specify the location of the source directory. This option
  can be used independently of "-B".

* The "cmake" command gained the "-B <build_dir>" command line
  option to specify the location of the build directory. This option
  can be used independently of "-S".

* The "cmake" "-E create_symlink" command can now be used on
  Windows.

* The "target_link_directories()" command was created to specify
  link directories for targets and their dependents.

* The "target_link_options()" command was created to specify link
  options for targets and their dependents.

* The "target_link_libraries()" command may now be called to modify
  targets created outside the current directory. See policy "CMP0079".

* The "install(TARGETS)" command learned to install targets created
  outside the current directory.

* The "install(CODE)" and "install(SCRIPT)" commands learned to
  support generator expressions.

* A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to
  set the debugging command line arguments with Visual Studio
  Generators for VS 2010 and above.

* A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the
  debugging environment with Visual Studio Generators for VS 2010 and
  above.

* The "option()" command now honors an existing normal variable of
  the same name and does nothing instead of possibly creating a cache
  entry (or setting its type) and removing the normal variable. See
  policy "CMP0077".

* The "target_sources()" command now interprets relative source file
  paths as relative to the current source directory.  This simplifies
  incrementally building up a target's sources from subdirectories.
  The "CMP0076" policy was added to provide backward compatibility
  with the old behavior where required.


CMake 3.13 Release Notes
************************

Changes made since CMake 3.12 include the following.


New Features
============


Generators
----------

* The Visual Studio Generators for VS 2010 and above learned to
  support the "INTERPROCEDURAL_OPTIMIZATION" target property and
  supporting "CheckIPOSupported" module.

* The "Xcode" generator learned to configure more Xcode Scheme
  fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable.

* The "Green Hills MULTI" generator has been updated:

  * Added support for architecture selection through
    "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86".

  * Added support for toolset selection through
    "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510",
    "comp_201722_beta".

  * Added support for platform selection through
    "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone",
    etc.

  * No longer checks that "arm" based compilers are installed but
    ensures that the correct "gbuild.exe" exists.

  * No longer hard-codes ARM files, BSP, toolset, or OS locations.


Command-Line
------------

* The "cmake(1)" command gained the "-S <source_dir>" command line
  option to specify the location of the source directory. This option
  can be used independently of "-B".

* The "cmake(1)" command gained the "-B <build_dir>" command line
  option to specify the location of the build directory. This option
  can be used independently of "-S".

* The "cmake(1)" "-E create_symlink" command can now be used on
  Windows.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned to support generator expressions in "WORKING_DIRECTORY"
  options.

* The "add_link_options()" command was created to add link options
  in the current directory.

* The "install(CODE)" and "install(SCRIPT)" commands learned to
  support generator expressions.

* The "install(TARGETS)" command learned to install targets created
  outside the current directory.

* The "link_directories()" command gained options to control
  insertion position.

* The "list(SORT)" command gained options to control the comparison
  operation used to order the entries.

* The "math()" command gained options for hexadecimal.

* The "target_link_directories()" command was created to specify
  link directories for targets and their dependents.

* The "target_link_options()" command was created to specify link
  options for targets and their dependents.

* The "target_link_libraries()" command may now be called to modify
  targets created outside the current directory. See policy "CMP0079".


Variables
---------

* A "CMAKE_AUTOGEN_VERBOSE" variable was added to optionally
  increase the verbosity of "AUTOMOC", "AUTOUIC" and "AUTORCC" from
  within CMake project code.

* A "CMAKE_VS_GLOBALS" variable was added to initialize
  "VS_GLOBAL_<variable>" target properties on targets as they are
  created.


Properties
----------

* The "DEPLOYMENT_ADDITIONAL_FILES" target property was added to
  tell the "Visual Studio 9 2008" generator to specify additional
  files for deployment to WinCE devices for remote debugging.

* The "INTERFACE_LINK_DEPENDS" target property was created to
  specify transitive link dependencies on files.

* The "LINK_DEPENDS" target property learned to support "generator
  expressions".

* "LINK_DIRECTORIES" and "INTERFACE_LINK_DIRECTORIES" target
  properties were added to collect link directories for a target and
  its dependents.  Use the "target_link_directories()" command to set
  them.

* "LINK_OPTIONS" and "INTERFACE_LINK_OPTIONS" target properties were
  added to collect link options for a target and its dependents.  Use
  the "target_link_options()" command to set them.

* A "LINK_OPTIONS" directory property was added to collect link
  options for targets created under the current directory. Use the
  "add_link_options()" command to set it.

* A "STATIC_LIBRARY_OPTIONS" target property was created to specify
  archiver options to use when creating static libraries.

* A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to
  set the debugging command line arguments with Visual Studio
  Generators for VS 2010 and above.

* A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the
  debugging environment with Visual Studio Generators for VS 2010 and
  above.

* The "VS_DEBUGGER_COMMAND" and "VS_DEBUGGER_WORKING_DIRECTORY"
  target properties now support generator expressions.


Modules
-------

* The "FindCURL" module learned to find debug and release variants
  separately.

* The "FindMatlab" module gained new components "ENGINE_LIBRARY" and
  "DATAARRAY_LIBRARY" to request finding the Matlab C++ Engine and
  DataArray libraries respectively.

* The "FindMatlab" module now explicitly exports mexFunction in
  Visual Studio.

* The "FindMatlab" module gained a new "MCC_COMPILER" component to
  request finding the Matlab Compiler add-on.

* The "FindPkgConfig" module gained an option to create imported
  targets in global scope.

* The "FindPkgConfig" module gained support for "<" and ">"
  operators for version checks in addition to the already supported
  operators ">=", "<=", and "=".

* Modules "FindPython3", "FindPython2" and "FindPython" gain
  capability to control order of resource lookup on macOS (Framework)
  and Windows (Registry).

* The "FindSubversion" module "Subversion_WC_INFO" command gained an
  "IGNORE_SVN_FAILURE" option to suppress failures, e.g. when the
  source tree is not under Subversion control.

* The "UseSWIG" module learned to manage target property
  "INCLUDE_DIRECTORIES" for "SWIG" compilation.


CTest
-----

* "ctest(1)" gained a "--progress" option to enable a live test
  progress summary when output goes to a terminal.


CPack
-----

* The "CPack Deb Generator" learned to split debug symbols into a
  corresponding .ddeb package when "CPACK_DEBIAN_DEBUGINFO_PACKAGE" is
  set.

* The "CPack Deb Generator" learned to honor the "SOURCE_DATE_EPOCH"
  environment variable when packaging files.  This is useful for
  generating reproducible packages.

* CPack gained a new "CPack External Generator" which is used to
  export the CPack metadata in a format that other software can
  understand. The intention of this generator is to allow external
  packaging software to take advantage of CPack's features when it may
  not be possible to use CPack for the entire packaging process.


Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies
  "CMP0055" through "CMP0063" ("CMP0054" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.


Other Changes
=============

* The "option()" command now honors an existing normal variable of
  the same name and does nothing instead of possibly creating a cache
  entry (or setting its type) and removing the normal variable. See
  policy "CMP0077".

* The Makefile Generators learned to remove custom command and
  custom target byproducts during "make clean".

* The "target_sources()" command now interprets relative source file
  paths as relative to the current source directory.  This simplifies
  incrementally building up a target's sources from subdirectories.
  The "CMP0076" policy was added to provide backward compatibility
  with the old behavior where required.

* The "BundleUtilities" module may no longer be included at
  configure time. This was always a bug anyway. See policy "CMP0080".

* The "UseSWIG" module has changed strategy for target naming. See
  policy "CMP0078".

* The "LINK_DIRECTORIES" target property now expects absolute paths.
  See policy "CMP0081".

* The CPack generators have been moved into their own separate
  section in the documentation, rather than having the documentation
  in their internal implementation modules. These internal
  implementation modules are also no longer available to scripts that
  may have been incorrectly including them, because they should never
  have been available in the first place.

From eike at sf-mail.de  Tue Oct  9 14:00:15 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 09 Oct 2018 20:00:15 +0200
Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for
 testing
In-Reply-To: <CAFzjYVrNBLs_7Y691GU0YCnhG=5L4kuPCUQ3km+zve4M1XXbdw@mail.gmail.com>
References: <CAFzjYVrNBLs_7Y691GU0YCnhG=5L4kuPCUQ3km+zve4M1XXbdw@mail.gmail.com>
Message-ID: <43977294.SK0xnDjAYC@daneel.sf-tec.de>

Robert Maynard wrote:
> I am proud to announce the first CMake 3.13 release candidate.
>   https://cmake.org/download/
> 
> Documentation is available at:
>   https://cmake.org/cmake/help/v3.13
> 
> Release notes appear below and are also published at
>   https://cmake.org/cmake/help/v3.13/release/3.13.html
> 
> Some of the more significant changes in CMake 3.13 are:

[?]

Seems like you missed one part of the announcement mail ;)

Policies
======
 
* An explicit deprecation diagnostic was added for policies
  "CMP0055" through "CMP0063" ("CMP0054" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* CMP0076: The ``target_sources()`` command converts relative paths to
  absolute.

* CMP0077: ``option()`` honors normal variables.

* CMP0078: ``UseSWIG`` generates now standard target names.

* CMP0079: ``target_link_libraries()`` allows use with targets in other
  directories.

* CMP0080: ``BundleUtilities`` cannot be included at configure time.

* CMP0081: Relative paths not allowed in ``LINK_DIRECTORIES`` target property.

HTH,

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181009/83bc61b7/attachment.sig>

From brad.king at kitware.com  Tue Oct  9 14:17:36 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 9 Oct 2018 14:17:36 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for
 testing
In-Reply-To: <43977294.SK0xnDjAYC@daneel.sf-tec.de>
References: <CAFzjYVrNBLs_7Y691GU0YCnhG=5L4kuPCUQ3km+zve4M1XXbdw@mail.gmail.com>
 <43977294.SK0xnDjAYC@daneel.sf-tec.de>
Message-ID: <090444a1-19b0-597e-7e16-9bc30f77cd88@kitware.com>

On 10/09/2018 02:00 PM, Rolf Eike Beer wrote:
> Seems like you missed one part of the announcement mail ;)
> 
> Policies
> ======

The announcement comes from the release notes, and all policies
are mentioned there in relevant bullets.  We've never called them
out separately in such notes.  One can always see the list here:

   https://cmake.org/cmake/help/v3.13/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-13

separated by version.

-Brad

From gblikas at gmail.com  Fri Oct 12 17:01:09 2018
From: gblikas at gmail.com (George Blikas)
Date: Fri, 12 Oct 2018 14:01:09 -0700
Subject: [cmake-developers] Current Projects
Message-ID: <CAHbc-jL4uYCaXYRF+KDnfb6yA-ioqD6cnf=45Kn6HWi55V-YXw@mail.gmail.com>

I was looking to be a more serious contributor to CMake. Is there a list of
feature requests, or a simple enough project that I could get started on?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181012/316ade25/attachment.html>

From kyle.edwards at kitware.com  Fri Oct 12 17:37:04 2018
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 12 Oct 2018 17:37:04 -0400
Subject: [cmake-developers] Current Projects
In-Reply-To: <CAHbc-jL4uYCaXYRF+KDnfb6yA-ioqD6cnf=45Kn6HWi55V-YXw@mail.gmail.com>
References: <CAHbc-jL4uYCaXYRF+KDnfb6yA-ioqD6cnf=45Kn6HWi55V-YXw@mail.gmail.com>
Message-ID: <1539380224.5597.70.camel@kitware.com>

On Fri, 2018-10-12 at 14:01 -0700, George Blikas wrote:
> I was looking to be a more serious contributor to CMake. Is there a
> list of feature requests, or a simple enough project that I could get
> started on?
Hello George,
Thank you for your interest in contributing to CMake! We're always
happy to have new developers.
If you're looking to implement feature requests or fix bugs, I'd start
with the official CMake issue tracker on our GitLab server:?https://git
lab.kitware.com/cmake/cmake/issues?Pick something that looks
interesting and take a crack at it! We are very responsive to merge
requests.
In addition, if there's a feature or behavior tweak you want to see for
your own personal use, you could try implementing it yourself.
If you have an exotic hardware/software platform that we don't
currently support, you could try porting it to that architecture and
setting up your machine as a nightly testing machine.
Thanks again,
Kyle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181012/6179e7a2/attachment.html>

From whisperity at gmail.com  Mon Oct 15 13:43:07 2018
From: whisperity at gmail.com (Whisperity)
Date: Mon, 15 Oct 2018 19:43:07 +0200
Subject: [cmake-developers] Experiments in CMake support for Clang (header &
 standard) modules
Message-ID: <CAL3FZmVS==wpx2PYJDpwdOiOQNqCDf4vtZ81gqrLVsT3JD-f=Q@mail.gmail.com>

Dear List,

(Unfortunately, I can't reply to the previous threads because I just
got to know and subscribed to this list.)

I have (from what it seems, also) created an implementation for C++
Modules TS support (in Clang specifically) for CMake. This is part of
an ongoing research project of mine (and a few of my colleagues) into
the knick and knacks of modular C++ compilation (where "modular" here
is a more abstract term) as we are all harassed by long compilation
times...

The patch is available here:
http://gitlab.kitware.com/cmake/cmake/merge_requests/2482

This talk will specifically be about "Modules TS", *NOT* the "header
modules", or as Richard Smith put it, "C++98 Modules", or the "module
map" thing. (Clang's current documentation really doesn't go into any
detail about the "Modules TS" version sadly...)

(From this point now on, please "s/standard/standard proposal/g" if I
miss it somewhere.)

The idea behind the patch was to introduce a new CMake command
(add_cxx_module) that handles compiling a source file (the module's
input file in the standard) into the necessary module binaries (in
Clang, a PCM - PreCompiled Module), by making sure these compilations
do the necessary parameter setting to the compiler to make a module.
This was introduced through some new variables in CMake's "Compiler
Knowledge" files.

The second change was with "target_link_libraries()" which allowed
specifying a module in the linker list, as modules don't only need the
interface to make sure the semantic analysis can run correctly, but
also the implementation details to generate code in an "end-binary".
(Library or executable or whatever.) This was more like a necessary
frog to swallow as unfortunately, CMake when checking the actual
dependencies (include statements) of a source file, even though I made
it match onto "import" statements too, when an import statement is
read (such as "import foo;") I can't "call back" to CMake's global
generator to find the target named "foo", and if so, set it up as a
dependency (just like how header dependencies easily work without
explicit specification of them). So to make sure dependencies can be
mapped (so changing a module CPP will recompile the PCM and also
relink the end binaries), the user needs to explicitly specify them...
this is admittedly a bad thing, I was thinking of eventually figuring
out maybe a generator expression that can be added to a target through
a command which helps this, but so far what I can see is that the
/child/ CMake instance has no way to know about the global state of
things.

I agree that this thing with listing up all modules needed in
"target_link_libraries()" is the most convoluted part.

The better option would be somehow making sure we can do more (reading
and writing of global state) when an "import" statement is
encountered. In this way, we could automatically at the time of
depchecking a source file:
 - figure out what sort of modules are needed from the list of imports
 - find these modules (somehow? maybe through some logic like the
local folder, parent folder, system folder, maybe a list of modules
added -as modules- (kinda like add_cxx_module() in the knowledge
base), where they are compiled from
 - create their compilation (in a way that the current CXX_COMPILER
does it - hence why I added the extra configuration options saying
"Okay Clang does it this way" and then making room for "But GCC/MSVC
does it the other way")
   - (Sidenote: the fact that GCC wants a callback mechanism which if
I understand it correctly would -want to call the build system- is
really not a good idea I think, because that would introduce coupling
from the compiler back to the build wrangler... maintaining the
knowledge about particular compilers in CMake is already a burden, now
doing a backwards thing in each and every compiler will just turn it
into a big mess of dependency hell.)
   - Of course the whole thing isn't that much clear on Clang's side
anyways. There is a concurrent discussion on the Clang Developers list
(see my post: http://clang-developers.42468.n3.nabble.com/Modules-TS-Work-tt4062259.html#a4062511
and the thread available from here...).
 - add these compilations into the current build, and add their making
as a dependency to build the particular object which imports them, add
them as a linkage dependency (if the compiler, and Clang does, require
such), etc.

This latter step is the cornerstone which requires a particular local
generator to be able to see the global generator -truly globally- (as
current calling FindTarget() on a valid and defined module *even in my
patch!* in depcheck time will result in a nullptr...), and maybe
introduce a "temporarily built things" or "build staging area" kind of
thing where these generated PCMs can be added where they will be read
as valid targets, where they are generated and as files used from, but
which is not -explicitly- mentioned in the original CMakeLists.txt in
any way.

I have yet to try the implementation (and module system as a whole) on
large projects. It is currently in the making on a smaller and a
larger project for research purposes on complexity, memory usage, etc.
I hope the results will be valuable for the whole community.

The whole naming thing is wonky as CMake already has something called
"module library" which is yet another thing, and CMake "Modules" are
just a bunch of CMake files, ...

Regards,
Whisperity.

From eike at sf-mail.de  Wed Oct 17 04:47:15 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Wed, 17 Oct 2018 10:47:15 +0200
Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for
 testing
In-Reply-To: <090444a1-19b0-597e-7e16-9bc30f77cd88@kitware.com>
References: <CAFzjYVrNBLs_7Y691GU0YCnhG=5L4kuPCUQ3km+zve4M1XXbdw@mail.gmail.com>
 <43977294.SK0xnDjAYC@daneel.sf-tec.de>
 <090444a1-19b0-597e-7e16-9bc30f77cd88@kitware.com>
Message-ID: <3495855b17f0e481486cd75791ea87f3@sf-mail.de>

Am 2018-10-09 20:17, schrieb Brad King:
> On 10/09/2018 02:00 PM, Rolf Eike Beer wrote:
>> Seems like you missed one part of the announcement mail ;)
>> 
>> Policies
>> ======
> 
> The announcement comes from the release notes, and all policies
> are mentioned there in relevant bullets.  We've never called them
> out separately in such notes.  One can always see the list here:
> 
> 
> https://cmake.org/cmake/help/v3.13/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-13
> 
> separated by version.

The idea was that someone like me would look on the announcement and say 
"hey, these 2 policies should be set to new even in my code supporting 
old CMake versions because it makes sense to us".

Eike

From cristian.adam at gmail.com  Wed Oct 17 08:58:02 2018
From: cristian.adam at gmail.com (Cristian Adam)
Date: Wed, 17 Oct 2018 14:58:02 +0200
Subject: [cmake-developers] CMake Server and the "Language Server Protocol"
 support [Qt Creator 4.8 / Visual Studio Code]
Message-ID: <CA+u+m-JrXj8iGxJ6526Xnimsu9aU9bcbYAsSkhhf=1e-SOVZ0A@mail.gmail.com>

Hi,

With the announcement of Qt Creator 4.8 Beta
<http://blog.qt.io/blog/2018/10/11/qt-creator-4-8-beta-released/>  we can
see that it supports Microsoft's Language Server Protocol
<https://microsoft.github.io/language-server-protocol/>.

How far is CMake from having such support in server mode?

Stephen Kelly had this in his January 2016's CMake Daemon client
demonstration <https://www.youtube.com/watch?v=BPgXuvPAl-8>. Having watched
that video I feel the urge of compiling his code and having that tool today.

Having that level of integration makes everything else feel like editing in
Notepad.

If such support would be available in Qt Creator, and Visual Studio Code
etc., people wouldn't rant
<https://dorinlazar.ro/cough-short-cough-history-build-systems/> that much
about CMake's language or documentation.

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181017/2c9b38a1/attachment.html>

From mingw.android at gmail.com  Thu Oct 18 11:48:28 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Thu, 18 Oct 2018 16:48:28 +0100
Subject: [cmake-developers] Generalized verbose option for cmake --build.
Message-ID: <CAOYw7dtC0TjdUPFchsKYn5fhnb5AhQ66+k703Pd7aWOA48sxJA@mail.gmail.com>

Hi CMake developers,

Why do I need to know the necessary verbose flag to make each back-end
that cmake --build calls emit more information? If forces my build
script to switch on the platform in a really ugly way for something
I'd consider a very important feature (you already hardcode various
things to enable cmake --build to work, so why not this as well?)
Something like cmake --build --verbose would be good.


Best regards,

Ray.

From brad.king at kitware.com  Thu Oct 18 11:53:32 2018
From: brad.king at kitware.com (Brad King)
Date: Thu, 18 Oct 2018 11:53:32 -0400
Subject: [cmake-developers] Generalized verbose option for cmake --build.
In-Reply-To: <CAOYw7dtC0TjdUPFchsKYn5fhnb5AhQ66+k703Pd7aWOA48sxJA@mail.gmail.com>
References: <CAOYw7dtC0TjdUPFchsKYn5fhnb5AhQ66+k703Pd7aWOA48sxJA@mail.gmail.com>
Message-ID: <5de86ed9-74f4-7524-2e35-832bf37b309d@kitware.com>

On 10/18/2018 11:48 AM, Ray Donnelly wrote:
> Why do I need to know the necessary verbose flag to make each back-end
> that cmake --build calls emit more information? If forces my build
> script to switch on the platform in a really ugly way for something
> I'd consider a very important feature (you already hardcode various
> things to enable cmake --build to work, so why not this as well?)
> Something like cmake --build --verbose would be good.

There is work on that here:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2129

but it has stalled.

-Brad

From eike at sf-mail.de  Thu Oct 18 12:21:51 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Thu, 18 Oct 2018 18:21:51 +0200
Subject: [cmake-developers] Generalized verbose option for cmake --build.
In-Reply-To: <CAOYw7dtC0TjdUPFchsKYn5fhnb5AhQ66+k703Pd7aWOA48sxJA@mail.gmail.com>
References: <CAOYw7dtC0TjdUPFchsKYn5fhnb5AhQ66+k703Pd7aWOA48sxJA@mail.gmail.com>
Message-ID: <3814333.fKoG2J8dXN@daneel.sf-tec.de>

Am Donnerstag, 18. Oktober 2018, 17:48:28 CEST schrieb Ray Donnelly:
> Hi CMake developers,
> 
> Why do I need to know the necessary verbose flag to make each back-end
> that cmake --build calls emit more information? If forces my build
> script to switch on the platform in a really ugly way for something
> I'd consider a very important feature (you already hardcode various
> things to enable cmake --build to work, so why not this as well?)
> Something like cmake --build --verbose would be good.

I had the same problem with our automated builds, and I solved this by simply 
passing

        -D CMAKE_VERBOSE_MAKEFILE=On

to the CMake run.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181018/b0a5d300/attachment.sig>

From jrmadsen at lbl.gov  Thu Oct 18 23:22:02 2018
From: jrmadsen at lbl.gov (Jonathan R. Madsen)
Date: Thu, 18 Oct 2018 20:22:02 -0700
Subject: [cmake-developers] Python bindings for CTest
Message-ID: <3B2EEAFD-6CAF-4CC3-891D-C77F8C0BEBC8@lbl.gov>

Hi,

I have created some Python bindings for CTest. The goal was to create an easy way for Python projects that I work with to be able to wrap their Python compilation log (if there was one), dynamically generate CTests and/or wrap their existing testing commands, do any additional testing analysis (in Python), etc. and then submit the logs, notes, plots, etc. to CDash without requiring them to overhaul any of their existing build or testing systems. 

Is there any interest in this development?

Jonathan

From brad.king at kitware.com  Fri Oct 19 09:19:28 2018
From: brad.king at kitware.com (Brad King)
Date: Fri, 19 Oct 2018 09:19:28 -0400
Subject: [cmake-developers] Python bindings for CTest
In-Reply-To: <3B2EEAFD-6CAF-4CC3-891D-C77F8C0BEBC8@lbl.gov>
References: <3B2EEAFD-6CAF-4CC3-891D-C77F8C0BEBC8@lbl.gov>
Message-ID: <40a12d9c-a6b7-50fb-f820-0488db8f0089@kitware.com>

On 10/18/2018 11:22 PM, Jonathan R. Madsen wrote:
> I have created some Python bindings for CTest. The goal was to
> create an easy way for Python projects that I work with to be able
> to wrap their Python compilation log (if there was one), dynamically
> generate CTests and/or wrap their existing testing commands, do any
> additional testing analysis (in Python), etc. and then submit the
> logs, notes, plots, etc. to CDash without requiring them to overhaul
> any of their existing build or testing systems. 
> 
> Is there any interest in this development?

Neat.  Have you published these anywhere?

Does this make modifications to CTest itself, or is this all
going through CTestTestfile.cmake generation?  I don't think we
can have "ctest" itself link to python libraries.

Thanks,
-Brad

From jrmadsen at lbl.gov  Fri Oct 19 11:16:44 2018
From: jrmadsen at lbl.gov (Jonathan R. Madsen)
Date: Fri, 19 Oct 2018 08:16:44 -0700
Subject: [cmake-developers] Python bindings for CTest
In-Reply-To: <40a12d9c-a6b7-50fb-f820-0488db8f0089@kitware.com>
References: <3B2EEAFD-6CAF-4CC3-891D-C77F8C0BEBC8@lbl.gov>
 <40a12d9c-a6b7-50fb-f820-0488db8f0089@kitware.com>
Message-ID: <9EE5F822-58CC-4982-B228-AE1D4E2B0CBE@lbl.gov>

Inline below.

--
Jonathan

> On Oct 19, 2018, at 6:19 AM, Brad King <brad.king at kitware.com> wrote:
> 
>> On 10/18/2018 11:22 PM, Jonathan R. Madsen wrote:
>> I have created some Python bindings for CTest. The goal was to
>> create an easy way for Python projects that I work with to be able
>> to wrap their Python compilation log (if there was one), dynamically
>> generate CTests and/or wrap their existing testing commands, do any
>> additional testing analysis (in Python), etc. and then submit the
>> logs, notes, plots, etc. to CDash without requiring them to overhaul
>> any of their existing build or testing systems. 
>> 
>> Is there any interest in this development?
> 
> Neat.  Have you published these anywhere?
> 
Yes it is currently available at https://github.com/jrmadsen/pyctest.
The 'conda-fixes' branch is what I've been working on most recently but I hasn't diverged much outside of the examples. This is a good example of how the driver works:

https://github.com/jrmadsen/pyctest/blob/conda-fixes/examples/TomoPy/pyctest_tomopy.py

> Does this make modifications to CTest itself,

It does not modify CTestLib or CMakeLib in any substantial way. I had to reimplement some classes to bypass some expectations -- such as the expections for actual files -- but when that was required I prefixed the new/alternative implementation with "py" (e.g. cmConfigureFileCommand became pycmConfigureFileCommand).

> or is this all
> going through CTestTestfile.cmake generation?  

I'm not 100% sure what you are asking here. For the most part, I let y'all's library do all the work. For example, the Python version of cmTest (pycmTest) uses cmPropertyMap and the Python version of cmTestGenerator (pycmTestGenerator) inherits from cmScriptGenerator. I believe this to be a far less error-prone method than just creating a Python package that "knows the syntax" and writes files for CMake/CTest.

> I don't think we
> can have "ctest" itself link to python libraries.
> 


Nothing on the CMake side has any dependencies on python libraries as a result of this. I just include header files and link to y'all's library like one does with any other API. 

> Thanks,
> -Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181019/010196b3/attachment.html>

From brad.king at kitware.com  Fri Oct 19 12:33:34 2018
From: brad.king at kitware.com (Brad King)
Date: Fri, 19 Oct 2018 12:33:34 -0400
Subject: [cmake-developers] Python bindings for CTest
In-Reply-To: <9EE5F822-58CC-4982-B228-AE1D4E2B0CBE@lbl.gov>
References: <3B2EEAFD-6CAF-4CC3-891D-C77F8C0BEBC8@lbl.gov>
 <40a12d9c-a6b7-50fb-f820-0488db8f0089@kitware.com>
 <9EE5F822-58CC-4982-B228-AE1D4E2B0CBE@lbl.gov>
Message-ID: <33c522ee-a94e-f62e-c774-c1dac91c7fc1@kitware.com>

On 10/19/2018 11:16 AM, Jonathan R. Madsen wrote:
> I just include header files and link to y'all's library like one
> does with any other API.?

As a matter of policy we do not offer any stable API, SDK, headers,
or libraries to be linked for exposing CMake internals.  Any external
package that tries to do this must take responsibility for updating
as we make internal changes.

The syntax of CTestTestfile.cmake files is much more stable.

If your goal is to submit to CDash, one could generate the .xml
files directly from python and not need CTest at all.

-Brad

From ben.boeckel at kitware.com  Fri Oct 19 15:19:05 2018
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 19 Oct 2018 15:19:05 -0400
Subject: [cmake-developers] Python bindings for CTest
In-Reply-To: <33c522ee-a94e-f62e-c774-c1dac91c7fc1@kitware.com>
References: <3B2EEAFD-6CAF-4CC3-891D-C77F8C0BEBC8@lbl.gov>
 <40a12d9c-a6b7-50fb-f820-0488db8f0089@kitware.com>
 <9EE5F822-58CC-4982-B228-AE1D4E2B0CBE@lbl.gov>
 <33c522ee-a94e-f62e-c774-c1dac91c7fc1@kitware.com>
Message-ID: <20181019191905.GA13409@rotor.localdomain>

On Fri, Oct 19, 2018 at 12:33:34 -0400, Brad King wrote:
> If your goal is to submit to CDash, one could generate the .xml
> files directly from python and not need CTest at all.

There is some code in Spack which does this already (though it is very
Spack-specific, it might provide some help):

    https://github.com/spack/spack/blob/1e1ea54bada54ae783198823c7f8fe0430ac41cb/lib/spack/spack/reporters/cdash.py
    https://github.com/spack/spack/tree/e5a68327608d6a5e6c0709237517238e0de96c27/share/spack/templates/reports/cdash

--Ben

From gurenchan at gmail.com  Mon Oct 22 19:45:22 2018
From: gurenchan at gmail.com (blubee blubeeme)
Date: Tue, 23 Oct 2018 07:45:22 +0800
Subject: [cmake-developers] cmake checkfortran fails
Message-ID: <CALM2mEkWExizXvt1GZKpOqGJpJm3cJ_FW=a+=VBKntsQ-R4jng@mail.gmail.com>

There's a newly open sourced fortran compiler flang:
https://github.com/flang-compiler/flang

The CMakeTestFortranCompiler.cmake erroneously says that the compiler
doesn't work.

-- The Fortran compiler identification is Flang 99.99.1
-- Check for working Fortran compiler: /usr/local/bin/flang
-- Check for working Fortran compiler: /usr/local/bin/flang  -- broken
CMake Error at
/usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:45 (message):
  The Fortran compiler

    "/usr/local/bin/flang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir:
/wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/local/bin/ninja" "cmTC_3bdf7"
    [1/4] Building Fortran preprocessed
CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f
    FAILED: CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f
CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f.ddi
    /usr/local/bin/flang -cpp    -E testFortranCompiler.f -o
CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f &&
/usr/local/bin/cmake -E cmake_ninja_depends
--tdi=CMakeFiles/cmTC_3bdf7.dir/FortranDependInfo.json
--pp=CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f
--dep=CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f.d
--obj=CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f.o
--ddi=CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f.ddi
    # 1 "testFortranCompiler.f"
    # 2 "testFortranCompiler.f"
            PROGRAM TESTFortran
            PRINT *, 'Hello'
            END

    CMake Error: -E cmake_ninja_depends failed to open
CMakeFiles/cmTC_3bdf7.dir/testFortranCompiler.f-pp.f
    ninja: build stopped: subcommand failed.

the fortran compiler does work if you remove the -E flag from the the
compilation command.

Is this an issue something that can get some attention?

Best,
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181023/5d7c6da2/attachment.html>

From Alan.W.Irwin1234 at gmail.com  Tue Oct 23 14:58:51 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Tue, 23 Oct 2018 11:58:51 -0700 (PDT)
Subject: [cmake-developers] kernel log segfault warning messages when
 building/testing CMake
Message-ID: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>

My "merlin" computer automatically builds and tests (including the
PLplot contract test) CMake each day at 4:32 Pacific time, and I have
noticed for some time now that those successful "merlin" tests (clean for the
CMake dashboard, but with 8 compile warnings but no errors for the
KWSys dashboard that is also generated by the CMake test) are always
accompanied by segfault warnings in the kernel log file for my Debian
Buster system.  At least some of those segfaults seem to
be associated with the KWSys part of this test.  Here are those log
warnings for today (taken from /var/log/messages):

======================
Oct 23 04:32:47 merlin kernel: [145023.933476] cmsysTestProces[5466]: segfault at 4 ip 000055d23f362e3b sp 00007ffda48d1940
  error 6 in cmsysTestProcess[55d23f362000+6000]
Oct 23 04:32:47 merlin kernel: [145023.933483] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 f
f ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00

Oct 23 04:32:47 merlin kernel: [145023.935919] cmsysTestProces[5472]: segfault at 4 ip 000055b7f515be3b sp 00007ffd46054c90
  error 6 in cmsysTestProcess[55b7f515b000+6000]
Oct 23 04:32:47 merlin kernel: [145023.935928] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 f
f ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00

Oct 23 04:33:48 merlin kernel: [145084.853316] Crash[6355]: segfault at 0 ip 000055f36cfd8135 sp 00007ffcc0d2d0f0 error 6 i
n Crash[55f36cfd8000+1000]
Oct 23 04:33:48 merlin kernel: [145084.853321] Code: 2f 00 00 01 5d c3 0f 1f 80 00 00 00 00 c3 0f 1f 80 00 00 00 00 e9 7b f
f ff ff 55 48 89 e5 48 c7 45 f8 00 00 00 00 48 8b 45 f8 <c7> 00 01 00 00 00 b8 00 00 00 00 5d c3 66 2e 0f 1f 84 00 00 00 00

Oct 23 04:34:33 merlin kernel: [145130.287867] kwsysTestProces[2964]: segfault at 4 ip 0000557e9dadce3b sp 00007fff85d3cce0 error 6 in kwsysTestProcess[557e9dadc000+6000]
Oct 23 04:34:33 merlin kernel: [145130.287875] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 ff ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00 
Oct 23 04:34:35 merlin kernel: [145131.727495] kwsysTestProces[4382]: segfault at 4 ip 000055ccd8790e3b sp 00007ffc422fea20 error 6 in kwsysTestProcess[55ccd8790000+6000]
Oct 23 04:34:35 merlin kernel: [145131.727499] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 ff ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00 
Oct 23 04:35:12 merlin kernel: [145169.367275] kwsysTestProces[4838]: segfault at 4 ip 0000563d98a43e3b sp 00007ffce04a4ab0 error 6 in kwsysTestProcess[563d98a43000+6000]
Oct 23 04:35:12 merlin kernel: [145169.367279] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 ff ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00 
Oct 23 04:41:17 merlin kernel: [145533.853387] kwsysTestProces[17736]: segfault at 4 ip 000056237dea3e3b sp 00007ffc5cd97cf0 error 6 in kwsysTestProcess[56237dea3000+6000]
Oct 23 04:41:17 merlin kernel: [145533.853394] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 ff ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00 
Oct 23 04:41:17 merlin kernel: [145533.855467] kwsysTestProces[17742]: segfault at 4 ip 000055ae9d89ce3b sp 00007fff23ff8b30 error 6 in kwsysTestProcess[55ae9d89c000+6000]
Oct 23 04:41:17 merlin kernel: [145533.855473] Code: 00 48 8d 3d 6f 56 00 00 e8 12 f5 ff ff 48 8b 3d db 83 00 00 e8 76 f4 ff ff 48 8b 3d ef 83 00 00 e8 6a f4 ff ff ba 2e 00 00 00 <c7> 04 25 04 00 00 00 00 00 00 00 48 8b 0d b3 83 00 00 be 01 00 00

======================

I don't notice any other platform on KWSys dashboard that also has the
8 build warnings, but it is likely my fairly recent gcc compiler
(Debian Buster ccache and gcc/g++ 8.2.0) is more sensitive to
problematic code in KWSys than prior versions of the gcc compiler
suite.

Anyhow, I suggest cleaning up the 8 build warnings for the KWSys
code to see if those are the source of some/all of these
segfaults.  And if no CMake developer here has access to Debian Buster, I
would be glad to run preliminary tests of any of your proposed KWSys code
changes to make sure the compile warnings are gone.

I have attached a compressed version of the my_dashboard.cmake script
that created a while ago (with lots of advice from Brad) to configure
this CMake test in case there is anything problematic in there.  For
example, I notice

set(ENV{CXXFLAGS} "-O3 -DNDEBUG")
set(ENV{CFLAGS} "-O3 -DNDEBUG")

in there in case that makes a difference with regard to the above KWSys compile warnings
that seem to appear just for my platform.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From eike at sf-mail.de  Tue Oct 23 15:20:43 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 23 Oct 2018 21:20:43 +0200
Subject: [cmake-developers] kernel log segfault warning messages when
 building/testing CMake
In-Reply-To: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>
References: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>
Message-ID: <1688048.LsWmZLGmg9@daneel.sf-tec.de>

Am Dienstag, 23. Oktober 2018, 20:58:51 CEST schrieb Alan W. Irwin:
> My "merlin" computer automatically builds and tests (including the
> PLplot contract test) CMake each day at 4:32 Pacific time, and I have
> noticed for some time now that those successful "merlin" tests (clean for
> the CMake dashboard, but with 8 compile warnings but no errors for the
> KWSys dashboard that is also generated by the CMake test) are always
> accompanied by segfault warnings in the kernel log file for my Debian
> Buster system.  At least some of those segfaults seem to
> be associated with the KWSys part of this test.  Here are those log
> warnings for today (taken from /var/log/messages):

I get those daily, here from my sparc:

[1540252.631482] kwsysTestProces[44830]: segfault at 4 ip 0000000000011c68 
(rpc 0000000000011c28) sp 00000000ffd7b670 error 1 in 
kwsysTestProcess[10000+e000]
[1540255.178055] kwsysTestProces[45441]: segfault at 4 ip 0000000000011c68 
(rpc 0000000000011c28) sp 00000000ff933670 error 1 in 
kwsysTestProcess[10000+e000]
[1541099.090339] kwsysTestProces[65043]: segfault at 4 ip 0000000000011c68 
(rpc 0000000000011c28) sp 00000000ffad96b0 error 1 in 
kwsysTestProcess[10000+e000]
[1541099.096219] kwsysTestProces[65049]: segfault at 4 ip 0000000000011c68 
(rpc 0000000000011c28) sp 00000000ff95f6b0 error 1 in 
kwsysTestProcess[10000+e000]

This is intentional, there are test binaries that segfault to test if that is 
properly detected by the signal handler/debug/ctest/whatever code.

> I don't notice any other platform on KWSys dashboard that also has the
> 8 build warnings, but it is likely my fairly recent gcc compiler
> (Debian Buster ccache and gcc/g++ 8.2.0) is more sensitive to
> problematic code in KWSys than prior versions of the gcc compiler
> suite.

I run gcc 8.2 on castor, but I don't know why this does not trigger these 
warnings.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181023/913cf8c4/attachment.sig>

From Alan.W.Irwin1234 at gmail.com  Tue Oct 23 18:37:09 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Tue, 23 Oct 2018 15:37:09 -0700 (PDT)
Subject: [cmake-developers] KWSys build warnings on the "merlin" platform
In-Reply-To: <1688048.LsWmZLGmg9@daneel.sf-tec.de>
References: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>
 <1688048.LsWmZLGmg9@daneel.sf-tec.de>
Message-ID: <nycvar.QRO.7.76.1810231500090.1506@zreyva.zlyna.ubzr>

On 2018-10-23 21:20+0200 Rolf Eike Beer wrote:

[...]
> [These segfaults are] intentional, there are test binaries that segfault to test if that is
> properly detected by the signal handler/debug/ctest/whatever code.

OK, and thanks for that info.

I have therefore changed the subject line appropriately.

>> I don't notice any other platform on KWSys dashboard that also has the
>> 8 build warnings, but it is likely my fairly recent gcc compiler
>> (Debian Buster ccache and gcc/g++ 8.2.0) is more sensitive to
>> problematic code in KWSys than prior versions of the gcc compiler
>> suite.
>
> I run gcc 8.2 on castor, but I don't know why this does not trigger these
> warnings.

It's possible it is the gcc/g++ flags I am using, but in any case
someone knowledgeable should look at those build warnings which
repeatedly show up on the "merlin" report for the the KWSys dashboard
to see if there is anything obvious that can be done to deal with the
source code issues that gcc/g++ has discovered for my Debian Buster
platform.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From Alan.W.Irwin1234 at gmail.com  Tue Oct 23 19:28:23 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Tue, 23 Oct 2018 16:28:23 -0700 (PDT)
Subject: [cmake-developers] KWSys build warnings on the "merlin" platform
In-Reply-To: <nycvar.QRO.7.76.1810231500090.1506@zreyva.zlyna.ubzr>
References: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>
 <1688048.LsWmZLGmg9@daneel.sf-tec.de>
 <nycvar.QRO.7.76.1810231500090.1506@zreyva.zlyna.ubzr>
Message-ID: <nycvar.QRO.7.76.1810231626560.1506@zreyva.zlyna.ubzr>

The promised attachment concerning how my CMake test is configured.


__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my_dashboard.cmake.gz
Type: application/x-gtar-compressed
Size: 1539 bytes
Desc: 
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181023/3d4bb651/attachment.tgz>

From brad.king at kitware.com  Wed Oct 24 07:42:33 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 24 Oct 2018 07:42:33 -0400
Subject: [cmake-developers] cmake checkfortran fails with Flang
In-Reply-To: <CALM2mEkWExizXvt1GZKpOqGJpJm3cJ_FW=a+=VBKntsQ-R4jng@mail.gmail.com>
References: <CALM2mEkWExizXvt1GZKpOqGJpJm3cJ_FW=a+=VBKntsQ-R4jng@mail.gmail.com>
Message-ID: <08ce211f-269a-f878-af9a-c52c3e3aba8e@kitware.com>

On 10/22/2018 07:45 PM, blubee blubeeme wrote:
> There's a newly open sourced fortran compiler flang:?https://github.com/flang-compiler/flang
> 
> ? ? /usr/local/bin/flang -cpp? ? -E testFortranCompiler.f ...
> 
> the fortran compiler does work if you remove the -E flag from the the compilation command.
> 
> Is this an issue something that can get some attention?

It's trying to pass both -cpp and -E to get preprocessing.

Please open an issue tracker entry for this.

Thanks,
-Brad

From brad.king at kitware.com  Wed Oct 24 09:05:52 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 24 Oct 2018 09:05:52 -0400
Subject: [cmake-developers] KWSys build warnings on the "merlin" platform
In-Reply-To: <nycvar.QRO.7.76.1810231500090.1506@zreyva.zlyna.ubzr>
References: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>
 <1688048.LsWmZLGmg9@daneel.sf-tec.de>
 <nycvar.QRO.7.76.1810231500090.1506@zreyva.zlyna.ubzr>
Message-ID: <284370e6-0a41-b8ae-94f0-841d1b13e327@kitware.com>

On 10/23/2018 06:37 PM, Alan W. Irwin wrote:
> look at those build warnings which
> repeatedly show up on the "merlin" report for the the KWSys dashboard

The warnings come from code generated by CMake.  You're driving the
builds with CMake 3.7 which still generated code on which gcc 8 warns.
CMake 3.11 has the fix.  If you drive with that or higher instead then
the warnings should go away.

-Brad

From gurenchan at gmail.com  Wed Oct 24 10:15:31 2018
From: gurenchan at gmail.com (blubee blubeeme)
Date: Wed, 24 Oct 2018 22:15:31 +0800
Subject: [cmake-developers] cmake checkfortran fails with Flang
In-Reply-To: <08ce211f-269a-f878-af9a-c52c3e3aba8e@kitware.com>
References: <CALM2mEkWExizXvt1GZKpOqGJpJm3cJ_FW=a+=VBKntsQ-R4jng@mail.gmail.com>
 <08ce211f-269a-f878-af9a-c52c3e3aba8e@kitware.com>
Message-ID: <CALM2mE=2oHHJp-haa7nrnAhD16_dY3RnOTu+96RTPJ1ceUgzXw@mail.gmail.com>

On Wed, Oct 24, 2018 at 7:42 PM Brad King <brad.king at kitware.com> wrote:

> On 10/22/2018 07:45 PM, blubee blubeeme wrote:
> > There's a newly open sourced fortran compiler flang:
> https://github.com/flang-compiler/flang
> >
> >     /usr/local/bin/flang -cpp    -E testFortranCompiler.f ...
> >
> > the fortran compiler does work if you remove the -E flag from the the
> compilation command.
> >
> > Is this an issue something that can get some attention?
>
> It's trying to pass both -cpp and -E to get preprocessing.
>
> Please open an issue tracker entry for this.
>
> Thanks,
> -Brad
>
Thank you, issue created:
https://gitlab.kitware.com/cmake/cmake/issues/18497
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181024/356e1ccc/attachment.html>

From Alan.W.Irwin1234 at gmail.com  Wed Oct 24 16:03:37 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Wed, 24 Oct 2018 13:03:37 -0700 (PDT)
Subject: [cmake-developers] KWSys build warnings on the "merlin" platform
In-Reply-To: <284370e6-0a41-b8ae-94f0-841d1b13e327@kitware.com>
References: <nycvar.QRO.7.76.1810231110350.1506@zreyva.zlyna.ubzr>
 <1688048.LsWmZLGmg9@daneel.sf-tec.de>
 <nycvar.QRO.7.76.1810231500090.1506@zreyva.zlyna.ubzr>
 <284370e6-0a41-b8ae-94f0-841d1b13e327@kitware.com>
Message-ID: <nycvar.QRO.7.76.1810241244410.1506@zreyva.zlyna.ubzr>

On 2018-10-24 09:05-0400 Brad King wrote:

> On 10/23/2018 06:37 PM, Alan W. Irwin wrote:
>> look at those build warnings which
>> repeatedly show up on the "merlin" report for the the KWSys dashboard
>
> The warnings come from code generated by CMake.  You're driving the
> builds with CMake 3.7 which still generated code on which gcc 8 warns.
> CMake 3.11 has the fix.  If you drive with that or higher instead then
> the warnings should go away.

OK. The issue was I keep ctest-3.7.2 (and cmake-3.7.2) first on my PATH because I
want to make sure to test those versions for the PLplot case (since that is the
PLplot minimum version of CMake for now although I plan within a year or so to
bump that to 3.12.3 or higher once most Linux distributions provide that version).

To fix this issue, I left my PATH the same but I now use the explicit
system version of ctest (3.12.3 on Debian Buster) to launch the
script, and the script automatically figures out inside to use the
compatible version of cmake to launch other parts of the test rather
than cmake-3.7.2 from my PATH).  And as you predicted the warnings go
away (see the most recent merlin results on the dashboard).  So thanks
very much for your key help in getting this issue figured out.

I seem to have been the only one currently who has tried to use a
ctest version less than 3.11 to drive testing, but nevertheless, you
may still want to document that the minimum ctest version to drive
testing should be 3.11 to avoid others running into this issue in the
future.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From robert.maynard at kitware.com  Thu Oct 25 11:05:23 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 25 Oct 2018 11:05:23 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc2 is ready for testing
Message-ID: <CAFzjYVqssO3qDjV=PxtWZMgXL3dQy6pLwKrU560UQfppyVBJ+w@mail.gmail.com>

I am proud to announce the second CMake 3.13 release candidate.
  https://cmake.org/download/

The first 3.13.0 release candidates included a change to allow
generator expressions in "install(CODE)" and "install(SCRIPT)".
This has been reverted in rc2 due to breaking backwards
compatibility. See issue 18435.

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

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

Some of the more significant changes in CMake 3.13 are:

* The Visual Studio Generators for VS 2010 and above learned to
  support the "INTERPROCEDURAL_OPTIMIZATION" target property and
  supporting "CheckIPOSupported" module.

* The "Green Hills MULTI" generator has been updated to include
  support for platform, architecture, and toolset selection.

* The "cmake" command gained the "-S <source_dir>" command line
  option to specify the location of the source directory. This option
  can be used independently of "-B".

* The "cmake" command gained the "-B <build_dir>" command line
  option to specify the location of the build directory. This option
  can be used independently of "-S".

* The "cmake" "-E create_symlink" command can now be used on
  Windows.

* The "target_link_directories()" command was created to specify
  link directories for targets and their dependents.

* The "target_link_options()" command was created to specify link
  options for targets and their dependents.

* The "target_link_libraries()" command may now be called to modify
  targets created outside the current directory. See policy "CMP0079".

* The "install(TARGETS)" command learned to install targets created
  outside the current directory.

* A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to
  set the debugging command line arguments with Visual Studio
  Generators for VS 2010 and above.

* A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the
  debugging environment with Visual Studio Generators for VS 2010 and
  above.

* The "option()" command now honors an existing normal variable of
  the same name and does nothing instead of possibly creating a cache
  entry (or setting its type) and removing the normal variable. See
  policy "CMP0077".

* The "target_sources()" command now interprets relative source file
  paths as relative to the current source directory.  This simplifies
  incrementally building up a target's sources from subdirectories.
  The "CMP0076" policy was added to provide backward compatibility
  with the old behavior where required.


CMake 3.13 Release Notes
************************

Changes made since CMake 3.12 include the following.


New Features
============


Generators
----------

* The Visual Studio Generators for VS 2010 and above learned to
  support the "INTERPROCEDURAL_OPTIMIZATION" target property and
  supporting "CheckIPOSupported" module.

* The "Xcode" generator learned to configure more Xcode Scheme
  fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable.

* The "Green Hills MULTI" generator has been updated:

  * Added support for architecture selection through
    "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86".

  * Added support for toolset selection through
    "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510",
    "comp_201722_beta".

  * Added support for platform selection through
    "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone",
    etc.

  * No longer checks that "arm" based compilers are installed but
    ensures that the correct "gbuild.exe" exists.

  * No longer hard-codes ARM files, BSP, toolset, or OS locations.


Command-Line
------------

* The "cmake(1)" command gained the "-S <source_dir>" command line
  option to specify the location of the source directory. This option
  can be used independently of "-B".

* The "cmake(1)" command gained the "-B <build_dir>" command line
  option to specify the location of the build directory. This option
  can be used independently of "-S".

* The "cmake(1)" "-E create_symlink" command can now be used on
  Windows.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned to support generator expressions in "WORKING_DIRECTORY"
  options.

* The "add_link_options()" command was created to add link options
  in the current directory.

* The "install(TARGETS)" command learned to install targets created
  outside the current directory.

* The "link_directories()" command gained options to control
  insertion position.

* The "list(SORT)" command gained options to control the comparison
  operation used to order the entries.

* The "math()" command gained options for hexadecimal.

* The "target_link_directories()" command was created to specify
  link directories for targets and their dependents.

* The "target_link_options()" command was created to specify link
  options for targets and their dependents.

* The "target_link_libraries()" command may now be called to modify
  targets created outside the current directory. See policy "CMP0079".


Variables
---------

* A "CMAKE_AUTOGEN_VERBOSE" variable was added to optionally
  increase the verbosity of "AUTOMOC", "AUTOUIC" and "AUTORCC" from
  within CMake project code.

* A "CMAKE_VS_GLOBALS" variable was added to initialize
  "VS_GLOBAL_<variable>" target properties on targets as they are
  created.


Properties
----------

* The "DEPLOYMENT_ADDITIONAL_FILES" target property was added to
  tell the "Visual Studio 9 2008" generator to specify additional
  files for deployment to WinCE devices for remote debugging.

* The "INTERFACE_LINK_DEPENDS" target property was created to
  specify transitive link dependencies on files.

* The "LINK_DEPENDS" target property learned to support "generator
  expressions".

* "LINK_DIRECTORIES" and "INTERFACE_LINK_DIRECTORIES" target
  properties were added to collect link directories for a target and
  its dependents.  Use the "target_link_directories()" command to set
  them.

* "LINK_OPTIONS" and "INTERFACE_LINK_OPTIONS" target properties were
  added to collect link options for a target and its dependents.  Use
  the "target_link_options()" command to set them.

* A "LINK_OPTIONS" directory property was added to collect link
  options for targets created under the current directory. Use the
  "add_link_options()" command to set it.

* A "STATIC_LIBRARY_OPTIONS" target property was created to specify
  archiver options to use when creating static libraries.

* A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to
  set the debugging command line arguments with Visual Studio
  Generators for VS 2010 and above.

* A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the
  debugging environment with Visual Studio Generators for VS 2010 and
  above.

* The "VS_DEBUGGER_COMMAND" and "VS_DEBUGGER_WORKING_DIRECTORY"
  target properties now support generator expressions.


Modules
-------

* The "FindCURL" module learned to find debug and release variants
  separately.

* The "FindMatlab" module gained new components "ENGINE_LIBRARY" and
  "DATAARRAY_LIBRARY" to request finding the Matlab C++ Engine and
  DataArray libraries respectively.

* The "FindMatlab" module now explicitly exports mexFunction in
  Visual Studio.

* The "FindMatlab" module gained a new "MCC_COMPILER" component to
  request finding the Matlab Compiler add-on.

* The "FindPkgConfig" module gained an option to create imported
  targets in global scope.

* The "FindPkgConfig" module gained support for "<" and ">"
  operators for version checks in addition to the already supported
  operators ">=", "<=", and "=".

* Modules "FindPython3", "FindPython2" and "FindPython" gain
  capability to control order of resource lookup on macOS (Framework)
  and Windows (Registry).

* The "FindSubversion" module "Subversion_WC_INFO" command gained an
  "IGNORE_SVN_FAILURE" option to suppress failures, e.g. when the
  source tree is not under Subversion control.

* The "UseSWIG" module learned to manage target property
  "INCLUDE_DIRECTORIES" for "SWIG" compilation.


CTest
-----

* "ctest(1)" gained a "--progress" option to enable a live test
  progress summary when output goes to a terminal.


CPack
-----

* The "CPack Deb Generator" learned to split debug symbols into a
  corresponding .ddeb package when "CPACK_DEBIAN_DEBUGINFO_PACKAGE" is
  set.

* The "CPack Deb Generator" learned to honor the "SOURCE_DATE_EPOCH"
  environment variable when packaging files.  This is useful for
  generating reproducible packages.

* CPack gained a new "CPack External Generator" which is used to
  export the CPack metadata in a format that other software can
  understand. The intention of this generator is to allow external
  packaging software to take advantage of CPack's features when it may
  not be possible to use CPack for the entire packaging process.


Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies
  "CMP0055" through "CMP0063" ("CMP0054" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.


Other Changes
=============

* The precompiled binaries provided on "cmake.org" now include
  qthelp- format documentation.

* The "option()" command now honors an existing normal variable of
  the same name and does nothing instead of possibly creating a cache
  entry (or setting its type) and removing the normal variable. See
  policy "CMP0077".

* The Makefile Generators learned to remove custom command and
  custom target byproducts during "make clean".

* The "target_sources()" command now interprets relative source file
  paths as relative to the current source directory.  This simplifies
  incrementally building up a target's sources from subdirectories.
  The "CMP0076" policy was added to provide backward compatibility
  with the old behavior where required.

* The "BundleUtilities" module may no longer be included at
  configure time. This was always a bug anyway. See policy "CMP0080".

* The "UseSWIG" module has changed strategy for target naming. See
  policy "CMP0078".

* The "LINK_DIRECTORIES" target property now expects absolute paths.
  See policy "CMP0081".

* The CPack generators have been moved into their own separate
  section in the documentation, rather than having the documentation
  in their internal implementation modules. These internal
  implementation modules are also no longer available to scripts that
  may have been incorrectly including them, because they should never
  have been available in the first place.

----------------------------------------------------------------------------
Changes made since CMake 3.13.0-rc1:

Ben Boeckel (1):
      CMP0053: document that `$` is a valid literal variable character

Brad King (17):
      Tests: Fix Cuda test project names
      VS: Drop workaround for CUDA compiler PDB location on CUDA 9.2+
      VS: Add workaround for CUDA compiler PDB location with space
      install: Revert CODE,SCRIPT support for generator expressions
      cmake-server: Revert "Support codemodel filegroups for INTERFACE_SOURCES"
      Utilities/Release: Add qthelp docs to binary archives
      Help: Clarify command-line encoding of target_link_libraries items
      curl: Update script to get curl 7.61.1
      curl: Backport to work with CMake 3.1 again
      curl: Update build within CMake to account for 7.61 changes
      curl: add missing type sizes for 'long long' and '__int64'
      VS: Fix crash on CSharp sources in a custom target
      VS: Fix CSharp support for win32res: and win32icon: flags
      cmake: Distinguish '-E tar' warnings from errors copying data
      Tests: Add missing BUILD_TESTING conditions
      cmake-gui: Fix "Open Project" for VS IDE with space in path
      CMake 3.13.0-rc2

Craig Scott (1):
      FindPkgConfig: Document support for > and < operators

Curl Upstream (1):
      curl 2018-09-04 (432eb5f5)

James Clarke (1):
      GNUInstallDirs: Don't use BSD info and man paths on GNU/kFreeBSD

KWSys Upstream (1):
      KWSys 2018-10-19 (c2f29d2e)

Kyle Edwards (3):
      Help: Convert DeployQt4 to block-style comment
      DeployQt4: Convert to 2-space indentation
      DeployQt4: Do not include BundleUtilities at configure time

Marc Chevrier (1):
      FindPython*: Add missing registry paths

Mario Bielert (1):
      FindBoost: Search for -mt variant of release libs

Mateusz ?oskot (1):
      FindBoost: Add support for upcoming Boost 1.69

Robert Maynard (3):
      Help: document CMAKE_DEBUG_TARGET_PROPERTIES support for LINK properties
      CUDA: Filter out host link flags during device linking
      CUDA: Add test for device linking when host linking uses threads

Rolf Eike Beer (1):
      FindThreads: Pass -pthread to CUDA compiler through -Xcompiler

vim-cmake-syntax upstream (2):
      vim-cmake-syntax 2018-10-10 (ac1957fb)
      vim-cmake-syntax 2018-10-18 (64ff4bd7)

From craig.scott at crascit.com  Sun Oct 28 02:30:13 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Sun, 28 Oct 2018 17:30:13 +1100
Subject: [cmake-developers] PIE flags on various platforms
Message-ID: <CA+dygYm7S7HpG_RBSn9KFvyhkUf7YQpzuPcHhPXHV4AMYkfsRw@mail.gmail.com>

I'm currently reviewing a merge request
<https://gitlab.kitware.com/cmake/cmake/merge_requests/2465> that addresses
problems with creating PIE executables. Is anyone here sufficiently
familiar with Fuchsia, FreeBSD or NetBSD to be able to check whether the
right flags are being used there (look at the relevant
Modules/Platform/*.cmake file)? If there are other platform-specific issues
which may need to be considered for these, I'm interested in hearing about
those too (for the BSDs in particular, there seems to have been quite a bit
of activity in this area a couple of years ago).

Regards

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181028/e7b86459/attachment.html>