[Cmake-commits] CMake branch, master, updated. v3.12.0-rc2-110-gdc70284

2018-06-30 Thread Kitware Robot 
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  dc70284c811a3183295371903d965658a9d2f8e0 (commit)
  from  ed95fe5c7a923a204ad41ba0b7f2b1748ec7e99c (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=dc70284c811a3183295371903d965658a9d2f8e0
commit dc70284c811a3183295371903d965658a9d2f8e0
Author: Kitware Robot 
AuthorDate: Sun Jul 1 00:01:23 2018 -0400
Commit: Kitware Robot 
CommitDate: Sun Jul 1 00:01:23 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 3af5446..bc7569a 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 12)
-set(CMake_VERSION_PATCH 20180630)
+set(CMake_VERSION_PATCH 20180701)
 #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

[CMake] Changes to cmake_minimum_required() for 3.12

2018-06-30 Thread Craig Scott 
(Subject changed to be specific to this discussion)

On Sat, Jun 30, 2018 at 3:13 PM, Hendrik Sattler 
wrote:

> It would actually make even more sense to rename cmake_minimum_required()
> to cmake_version_required() with the new syntax or something similar. Users
> of the old function cannot use the new syntax in older cmake versions and
> the old name does not actually fit the new functionality.
>

Actually older versions can use the new syntax and this is indeed the
specific reason why the new syntax is the way it is. Older CMake versions
will see the extra dots as being version component separators and will end
up effectively ignoring the max part. The nett result is that older
versions will continue to treat the min version as the policy setting just
like they have been to date. Newer versions of CMake will be able to take
advantage of the extra information provided by the max part to allow newer
policies to be enforced.

Regarding the renaming, a very similar discussion took place in the merge
request itself, so I'll refer you to there for details:

https://gitlab.kitware.com/cmake/cmake/merge_requests/1864#note_389157




>
> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" <
> ir...@beluga.phys.uvic.ca>:
> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
> >[...]
> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
> >>  commands now accept a version range using the form
> >>  "[...]". The "" version is required but policies are
> >>  set based on the "" version.  This allows projects to specify a
> >>  range of versions for which they have been updated and avoid
> >>  explicit policy settings.
> >[...]
> >
> >I suggest the following change to the above description:
> >
> >but policies are set based on the "" version.
> >
> >==>
> >
> >but policies are set based on the minimum of the running CMake and
> >"" versions.
> >
> >I prefer the latter because it immediately answers the question implied
> >by the former, i.e.,
> >what happens if the running version is less than max?
>

Seems reasonable. I've created a MR with a slight tweak to your wording for
this here .

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

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

Re: [cmake-developers] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

2018-06-30 Thread Patrick Stotko 
It seems that CMake does not find PkgConfig::GooCanvas because it is 
imported but not globally imported, i.e. it is maybe a visibility problem.
For reference, the relaxation of this limitation 
(https://gitlab.kitware.com/cmake/cmake/merge_requests/2040) is covered 
by this additional check for the LHS target:


https://gitlab.kitware.com/cmake/cmake/blob/c9349cc1b94a08b4f5ed86a397e72ceed50847dd/Source/cmTargetLinkLibrariesCommand.cxx#L383

Maybe a corresponding check for locally imported RHS targets is missing 
here:


https://gitlab.kitware.com/cmake/cmake/blob/c9349cc1b94a08b4f5ed86a397e72ceed50847dd/Source/cmTargetLinkLibrariesCommand.cxx#L396

Best regards,
Patrick Stotko


Am 30.06.2018 um 21:15 schrieb Rolf Eike Beer:

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

I played a bit around with that as I hope it would simplify some things in
OSM2go, but it looks there are still some limitations:

in main:

add_library(osm2go_lib ...)

add_subdirectory(sub)

in sub:

pkg_search_module(GooCanvas REQUIRED IMPORTED_TARGET goocanvas)
target_sources(osm2go_lib PRIVATE
src/platforms/gtk/canvas_goocanvas.cpp
)
target_link_libraries(osm2go_lib PRIVATE PkgConfig::GooCanvas)

Breaks:

CMake Error at CMakeLists.txt:43 (add_library):
   Target "osm2go_lib" links to target "PkgConfig::GooCanvas" but the target
   was not found.  Perhaps a find_package() call is missing for an IMPORTED
   target, or an ALIAS target is missing?

Is this intended to work?

There is an easy workaround, but it feels nasty:

add_library(osm2go_x_lib INTERFACE)
target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas)
target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib)




-- 

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-developers] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

2018-06-30 Thread Rolf Eike Beer 
> There is an easy workaround, but it feels nasty:
> 
> add_library(osm2go_x_lib INTERFACE)
> target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas)
> target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib)

This also seems to be not "stackable", i.e. an additional interface library in 
sub/sub can neither be linked into osm2go_lib nor osm2go_x_lib.

signature.asc
Description: This is a digitally signed message part.
-- 

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-developers] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

2018-06-30 Thread Rolf Eike Beer 
> * The "target_link_libraries()" command may now be called to modify
>   targets created outside the current directory.

I played a bit around with that as I hope it would simplify some things in 
OSM2go, but it looks there are still some limitations:

in main:

add_library(osm2go_lib ...)

add_subdirectory(sub)

in sub:

pkg_search_module(GooCanvas REQUIRED IMPORTED_TARGET goocanvas)
target_sources(osm2go_lib PRIVATE
src/platforms/gtk/canvas_goocanvas.cpp
)
target_link_libraries(osm2go_lib PRIVATE PkgConfig::GooCanvas)

Breaks:

CMake Error at CMakeLists.txt:43 (add_library):
  Target "osm2go_lib" links to target "PkgConfig::GooCanvas" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

Is this intended to work?

There is an easy workaround, but it feels nasty:

add_library(osm2go_x_lib INTERFACE)
target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas)
target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib)


signature.asc
Description: This is a digitally signed message part.
-- 

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] How to specify library dir for imported interface?

2018-06-30 Thread Francis Giraldeau 
Build fails at link time, because a static library imported using
pkg-config is not in the standard path:

[ 74%] Linking CXX executable valhalla_add_predicted_traffic
/usr/bin/c++   ... -lprime_server ...

Usually, cmake uses the absolute path to the static library, but instead,
pkg-config provides the library name and the library dir separately. Here
is the imported target:

add_library(libprime_server INTERFACE IMPORTED)
pkg_check_modules(libprime_server REQUIRED libprime_server>=0.6.3)
set_target_properties(libprime_server PROPERTIES
INTERFACE_LINK_LIBRARIES "${libprime_server_LIBRARIES}"
INTERFACE_INCLUDE_DIRECTORIES "${libprime_server_INCLUDE_DIRS}")

The library dir is defined in the CMakeCache.txt (both in the LDFLAGS in
LIBRARY_DIRS):

libprime_server_LDFLAGS:INTERNAL=-L/home/francis/local/lib;-lprime_server
libprime_server_LIBRARY_DIRS:INTERNAL=/home/francis/local/lib

However, it seems no property exists to actually specify the library dir of
imported target, nor the linker flags to pass when using the imported
target.

What would be the best way to specify the library dir for an imported
library?

Thanks!

Francis Giraldeau
-- 
Francis Giraldeau
-- 

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