[Cmake-commits] CMake branch, master, updated. v3.14.4-1101-g63f149f

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  63f149f5989ea4adfa522cec63a954b5059c223c (commit)
  from  e32f8393388d28de7d713f35d076a33060368ec3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63f149f5989ea4adfa522cec63a954b5059c223c
commit 63f149f5989ea4adfa522cec63a954b5059c223c
Author: Kitware Robot 
AuthorDate: Sun May 26 00:01:04 2019 -0400
Commit: Kitware Robot 
CommitDate: Sun May 26 00:01:04 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 17632c7..9325305 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 14)
-set(CMake_VERSION_PATCH 20190525)
+set(CMake_VERSION_PATCH 20190526)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [cmake-developers] Is email notification of a failed CMake dashboard possible?

[Craig Scott]

Notifications for builds are controlled through CDash. You can adjust your
CDash notifications to suit your preferences. Go to CDash, click on "My
CDash". You should see a list of "My Projects" and "Public Projects".
Subscribe to a project and it will appear under your "My Projects" area if
it isn't there already. For each subscribed project, you should see an icon
next to it under the Actions column which allows you to edit your
subscription and from there you can control what you receive email
notifications for. I'm not sure if there is a way to limit your
notifications to just certain sites though. You may need to ask on the
CDash mailing list for help with that.


On Sun, May 26, 2019 at 7:54 AM Alan W. Irwin 
wrote:

> With a lot of initial configuration help from Brad King, I have been
> automatically submitting a Nightly dashboard for CMake (including the
> PLplot contract test) for some time now (see the "merlin" results at
>  and
> ).  On extremely rare
> occasions there is a failure in either of my CMake or KWSYS
> dashboards.  Is it possible for me to set up e-mail notification of
> such failures (and successes at first to make sure notification
> works), and if so, how?
>
> 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.org); 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
> __
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
>


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] Is email notification of a failed CMake dashboard possible?

[Alan W. Irwin]

With a lot of initial configuration help from Brad King, I have been
automatically submitting a Nightly dashboard for CMake (including the
PLplot contract test) for some time now (see the "merlin" results at
 and
).  On extremely rare
occasions there is a failure in either of my CMake or KWSYS
dashboards.  Is it possible for me to set up e-mail notification of
such failures (and successes at first to make sure notification
works), and if so, how?

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.org); 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
__
--

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] Dependency cycle - why?

[Bill Somerville]

Hi Eric,

thanks for the comprehensive reply to my query. My follow up comments in 
line below.


On 25/05/2019 15:47, Eric Noulard wrote:
Le sam. 25 mai 2019 à 13:51, Bill Somerville > a écrit :


Hi Robert,

thanks for that, the target name change does seem to help but I am
still unable to achieve my goal. Here is a simplified example that
demonstrates the problem:

cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
project (demo LANGUAGES NONE)
add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch 
prog${CMAKE_EXECUTABLE_SUFFIX})
add_executable (prog IMPORTED)
add_dependencies (prog prog_target)
set_target_properties (prog PROPERTIES IMPORTED_LOCATION 
${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
install (TARGETS prog RUNTIME DESTINATION bin)

which gives the following error at CMake configuration:

CMake Error at CMakeLists.txt:7 (install):
   install TARGETS given target "prog" which does not exist.


-- Configuring incomplete, errors occurred!

So the target that 'add_executable(name IMPORTED)' creates is not
a real executable target. I can change its properties but the
'install(TARGETS ...)' command thinks it does not exist. Note that
a executable target is a very simple demonstration and I
understand that I can use 'install(PROGRAM ...)' just about as
easily, but when it comes to a shared library it gets a lot more
complex when using, exporting, and instlling it, and it seems that
IMPORTED targets fall well short of useful when they are actually
produced by the current CMake project.

I can understand that an IMPORTED target is perhaps not meant to
be installable


Robert will give his advice on that but I bet IMPORTED target were 
never meant to be drop-in *replacement* of genuine target.


They were meant to ease *reference to* object/lib:executable that are 
outside the build of the project.
e.g the doc says: 
https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
"An IMPORTED library target references a library file located outside 
the project"


Nmelly a target that is "already installed somewhere" and that you 
want to reference in your CMake build.
That is fine but I don't see why there is a problem with making IMPORTED 
targets better CMake citizens, it should be down to the CMake script 
author as to whether they take advantage of that. What is there now is a 
lie and the add_*(target ... IMPORTED ...) commands are not doing what 
they should IMHO.


but if so then your statement that "The goal that you have is
fully supported by CMake" seems to be incorrect. To reiterate, I
am trying to use foreign tools to make binary targets and wish to
have CMake treat them *as if* they were created by supported
languages like C, ++, or Fortran. Am I still missing something?


My opinion is that IMPORTED target are not designed (as of today) for 
that purpose.

Agreed.


When you want to do what you seem to want you need to either:
1) add a "new LANGUAGE" (you seem to be willing to add golang)
    see: 
https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
    and may be: https://github.com/aadidenko/golang-cmake-example (or 
fork of this)
I am not sure that adding a new CMake supported language is right for 
Go. For the Go ecosystem the Go build tools do the right thing and CMake 
is largely unnecessary. Particularly the Go build system deals with 
dependencies internally so I don't see how it could be added to CMake 
without using the lower level Go tools and having to list many source 
dependencies that the high level Go build system deals with without 
fuss. Note that I am dealing with cgo which allows Go language static or 
shared libraries to interoperate with other languages via a C API. This 
is where CMake needs to join in because a project using cgo is likely to 
build tests, tools, and libraries in languages that CMake does support. 
As far as I can see the Go build system support is weak in providing a 
"package" from, for example, a cgo shared library, it just builds the 
shared object and header files and stops there.


2) define a set of custom macros that mimic genuine target behaviour.
    may be see: https://github.com/cpconduce/go_cmake
This is exactly where I started but it only covers tools written in Go 
and uses install(PROGRAMS ...) to install them. It uses 
add_custom_command() which means all source dependencies must be 
specified for reliable rebuilds, which is effectively discarding the 
dependency management of the Go build system. It would be very fragile 
in a large project and doesn't address the cgo capabilities to create 
libraries. My queries here are exactly because I am trying to extend 
this approach to tools and libraries that play well in the CMake 
ecosystem, without sacrificing the advantages of the Go build 

Re: [CMake] Dependency cycle - why?

[Eric Noulard via CMake]

Le sam. 25 mai 2019 à 13:51, Bill Somerville  a
écrit :

> Hi Robert,
>
> thanks for that, the target name change does seem to help but I am still
> unable to achieve my goal. Here is a simplified example that demonstrates
> the problem:
>
> cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
> project (demo LANGUAGES NONE)
> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch 
> prog${CMAKE_EXECUTABLE_SUFFIX})
> add_executable (prog IMPORTED)
> add_dependencies (prog prog_target)
> set_target_properties (prog PROPERTIES IMPORTED_LOCATION 
> ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
> install (TARGETS prog RUNTIME DESTINATION bin)
>
> which gives the following error at CMake configuration:
>
> CMake Error at CMakeLists.txt:7 (install):
>   install TARGETS given target "prog" which does not exist.
>
>
> -- Configuring incomplete, errors occurred!
>
> So the target that 'add_executable(name IMPORTED)' creates is not a real
> executable target. I can change its properties but the 'install(TARGETS
> ...)' command thinks it does not exist. Note that a executable target is a
> very simple demonstration and I understand that I can use 'install(PROGRAM
> ...)' just about as easily, but when it comes to a shared library it gets a
> lot more complex when using, exporting, and instlling it, and it seems that
> IMPORTED targets fall well short of useful when they are actually produced
> by the current CMake project.
>
> I can understand that an IMPORTED target is perhaps not meant to be
> installable
>

Robert will give his advice on that but I bet IMPORTED target were never
meant to be drop-in *replacement* of genuine target.

They were meant to ease *reference to* object/lib:executable that are
outside the build of the project.
e.g the doc says:
https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
"An IMPORTED library target references a library file located outside the
project"

Nmelly a target that is "already installed somewhere" and that you want to
reference in your CMake build.


> but if so then your statement that "The goal that you have is fully
> supported by CMake" seems to be incorrect. To reiterate, I am trying to use
> foreign tools to make binary targets and wish to have CMake treat them *as
> if* they were created by supported languages like C, ++, or Fortran. Am I
> still missing something?
>

My opinion is that IMPORTED target are not designed (as of today) for that
purpose.

When you want to do what you seem to want you need to either:
1) add a "new LANGUAGE" (you seem to be willing to add golang)
see:
https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
and may be: https://github.com/aadidenko/golang-cmake-example (or fork
of this)

2) define a set of custom macros that mimic genuine target behaviour.
may be see: https://github.com/cpconduce/go_cmake

If you want to have a look at existing similar example shippped with CMake,
have a look at UseJava.cmake module (
https://cmake.org/cmake/help/latest/module/UseJava.html)
You'll see that you have
add_jar, which is similar to add_executable and create a custom target
and
install_jar which is similar to install on genuine target but plays with
target properties and install(FILES...) in order to mimic that.
see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake

I'm not developing with golang but AFAIK go has a builtin "build system" so
bringing go as a language in CMake may not be the best option,
but again I am no Go expert.

The only reference of that kind of thing I found in the CMake mailing list
is oldish:
https://cmake.org/pipermail/cmake-developers/2011-August/013715.html

May be adding the support for "install" command for IMPORTED target is
doable but this seems to be a feature request to be discussed on developer
mailing list;
Regards,
Eric


> Regards
> Bill Somerville.
>
> On 24/05/2019 20:23, Robert Maynard wrote:
>
> Hi,
>
> The goal that you have is fully supported by CMake. You have just run
> into a bug in CMake, and you should report this 
> tohttps://gitlab.kitware.com/cmake/cmake/issues .
> Basically at a very high level the name out the add_executable target
> `callback_generator` is the same as the internal name that CMake is
> using for the add_custom_command. This than causes some logic in CMake
> (cmTargetTraceDependencies) to incorrectly build another link between
> the add_custom_command and your add_executable.
>
> The easiest way to solve this issue is name the add_executable target
> to have a different name than the output of your custom command minus
> file extension. So maybe something like  `callback_generator_exec`
>
> On Fri, May 24, 2019 at 2:02 PM Bill Somerville  
>  wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file 

Re: [CMake] Dependency cycle - why?

[Bill Somerville]

Hi Robert,

thanks for that, the target name change does seem to help but I am still 
unable to achieve my goal. Here is a simplified example that 
demonstrates the problem:


cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
project (demo LANGUAGES NONE)
add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch 
prog${CMAKE_EXECUTABLE_SUFFIX})
add_executable (prog IMPORTED)
add_dependencies (prog prog_target)
set_target_properties (prog PROPERTIES IMPORTED_LOCATION 
${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
install (TARGETS prog RUNTIME DESTINATION bin)

which gives the following error at CMake configuration:

CMake Error at CMakeLists.txt:7 (install):
  install TARGETS given target "prog" which does not exist.


-- Configuring incomplete, errors occurred!

So the target that 'add_executable(name IMPORTED)' creates is not a real 
executable target. I can change its properties but the 'install(TARGETS 
...)' command thinks it does not exist. Note that a executable target is 
a very simple demonstration and I understand that I can use 
'install(PROGRAM ...)' just about as easily, but when it comes to a 
shared library it gets a lot more complex when using, exporting, and 
instlling it, and it seems that IMPORTED targets fall well short of 
useful when they are actually produced by the current CMake project.


I can understand that an IMPORTED target is perhaps not meant to be 
installable but if so then your statement that "The goal that you have 
is fully supported by CMake" seems to be incorrect. To reiterate, I am 
trying to use foreign tools to make binary targets and wish to have 
CMake treat them *as if* they were created by supported languages like 
C, ++, or Fortran. Am I still missing something?


Regards
Bill Somerville.

On 24/05/2019 20:23, Robert Maynard wrote:

Hi,

The goal that you have is fully supported by CMake. You have just run
into a bug in CMake, and you should report this to
https://gitlab.kitware.com/cmake/cmake/issues .
Basically at a very high level the name out the add_executable target
`callback_generator` is the same as the internal name that CMake is
using for the add_custom_command. This than causes some logic in CMake
(cmTargetTraceDependencies) to incorrectly build another link between
the add_custom_command and your add_executable.

The easiest way to solve this issue is name the add_executable target
to have a different name than the output of your custom command minus
file extension. So maybe something like  `callback_generator_exec`

On Fri, May 24, 2019 at 2:02 PM Bill Somerville  wrote:

On 13/05/2019 12:03, Bill Somerville wrote:

Hi folks,

I am struggling to understand what the problem is with this:

find_program (GO go)
set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
file (MAKE_DIRECTORY ${GOPATH})

set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
set (build_command ${GO} build)
set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
add_custom_command (OUTPUT ${output}
   COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} 
CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} 
${sources}
   DEPENDS ${sources}
   VERBATIM)
add_custom_target (callback_generator_target DEPENDS 
${CMAKE_CURRENT_BINARY_DIR}/${output})
add_executable (callback_generator IMPORTED)
set_target_properties (callback_generator
   PROPERTIES
   IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
   )
add_dependencies (callback_generator callback_generator_target)

add_custom_target (server ALL DEPENDS callback_generator)

which gives this error:


cmake --version

cmake --version
cmake version 3.14.3


cmake -G "MinGW Makefiles" ..\..

cmake -G "MinGW Makefiles" ..\..
-- Configuring done
CMake Error: The inter-target dependency graph contains the following strongly 
connected component (cycle):
   "callback_generator_target" of type UTILITY
 depends on "callback_generator_target" (strong)
The component contains at least one cycle consisting of strong dependencies 
(created by add_dependencies) that cannot be broken.

The set_target_properties () call seems to be part of the problem but I don't 
understand why.

Regards
Bill Somerville.

Hi again,

answering my own post since no one has replied. Clearly my question was too 
specific. Let me try again with a more general question. I have tools that can 
generate executables (programs, static libraries, and shared libraries, 
including DLL import libraries on MS Windows). These tools are not directly 
supported by CMake but they are both needed within a project that uses them and 
installs them as the project artefacts. How do I integrate, for example a 
shared library, into a CMake project as if it were produced by a supported 
toolchain like C or C++? The library is produced by an add_custom_target() 
command (not add_custom_command() since the underlying tools do their own 
dependency checking so it is right to run the target commands every build). I 
need to have a