[Cmake-commits] CMake branch, master, updated. v3.9.0-rc5-246-gfc58819

[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  fc58819150a126d87bf17ad812bb6f62f28ae42b (commit)
  from  e09252f5d220965b07069fc00edf8658fc8198f1 (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=fc58819150a126d87bf17ad812bb6f62f28ae42b
commit fc58819150a126d87bf17ad812bb6f62f28ae42b
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Mon Jul 10 00:01:09 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Jul 10 00:01:09 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index a4f9ed9..2d86e33 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 9)
-set(CMake_VERSION_PATCH 20170709)
+set(CMake_VERSION_PATCH 20170710)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Tell cmake use /usr/include/db.h, not /usr/local/include/db.h

[Larry Hynes]

Michael Ellery  wrote:

>> On Jul 9, 2017, at 4:16 AM, Larry Hynes  wrote:
>> 
>> Hi
>> 
>> I'm building nvi2[0], on (Mac OS X Yosemite (10.10.5)), which uses
>> cmake.
>> 
>> nvi2 depends on a reasonably sane BSD environment, which would
>> include Berkeley DB V1 which is found at /usr/include/db.h.
>> 
>> I also have installed BDB V4, which lives at /usr/local/include/db.h,
>> for use by other programs.
>> 
>> The only way I can get nvi2 to build, is to uninstall BDB V4, in
>> which case cmake picks up V1 and all is well. Otherwise cmake
>> resolutely picks up V4 and the build fails.
>> 
>> I'm trying to figure out if it is possible to tell cmake to use the
>> V1 that is at /usr/include/db.h.
>> 
>> I've tried various invocations of find_path and find_library in
>> CMakeLists.txt, with and without appeals to default paths and such
>> like, to no avail. I've tried any variation of -DCMAKE_XXXFLAGS I
>> can think of, in CMakeLists.txt and on the command line, to no
>> avail. (When using find_XXX, cmake tells me they're found, but still
>> uses DB4. In the case of passing flags, cmake tells me that it
>> is ignoring them.)
>> 
>> Now, at day's end, this is not A Big Deal; I uninstall BDB4, build
>> nvi2, reinstall BDB4. But one would imagine that there is some
>> (simple) way to instruct cmake to use X over Y when building Z?
>> 
>> [0] https://github.com/lichray/nvi2
>> 
> system include order path is implementation defined, but it sounds
> to me like your compiler (clang) is behaving in a fairly normal way
> - that is, it checks /usr/local/include before /usr/include, which
> allows you to have newer versions of libs in local. This has nothing
> to do with CMake - this is standard compiler behavior. So, now it
> sounds like you want to change that default behavior for this target.
> If you can figure out the right set of flags to pass to clang to get
> it to find the right header, then it’s possible to convince CMake to
> pass those flags using something like target_compile_options().
>
> The CMake find_path and find_library functions don’t do anything
> magical…they just simplify the process of searching various locations
> on your filesystem for the specified files, and conveniently
> find_library knows about library file naming convention. When those
> functions are used, they just end-up setting some variables to tell
> you what it found and where, but they don’t do anything special with
> compiler flags. It’s up to you to take the results (variables) of
> those functions and pass them along to your compiler/toolchain as you
> see fit.
>
> So that’s the challenge here - figure out how to convince your
> compiler to ignore /usr/local/include, at least of this one
> dependency. If you have other things in /usr/local/include that you
> depend on, then this might be very tricky. It looks like the -include
> option to clang might allow you to specify a full path to a file to
> include before preprocessing, but that might also require that you
> remove all #include  from your sources - I don’t know if that’s
> feasible.

Thanks Mike - you gave me an idea here, and it works. Turns out
 is only included from one file - common/common.h - and
changing it to '#include "/usr/include/db.h"' does the trick. Yes,
it's a little hacky and amateurish and will probably anger the Gods,
but it takes less time than the uninstall / reinstall dance, so
we'll call it a victory.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Tell cmake use /usr/include/db.h, not /usr/local/include/db.h

[Michael Ellery]

> On Jul 9, 2017, at 4:16 AM, Larry Hynes  wrote:
> 
> Hi
> 
> I'm building nvi2[0], on (Mac OS X Yosemite (10.10.5)), which uses
> cmake.
> 
> nvi2 depends on a reasonably sane BSD environment, which would
> include Berkeley DB V1 which is found at /usr/include/db.h.
> 
> I also have installed BDB V4, which lives at /usr/local/include/db.h,
> for use by other programs.
> 
> The only way I can get nvi2 to build, is to uninstall BDB V4, in
> which case cmake picks up V1 and all is well. Otherwise cmake
> resolutely picks up V4 and the build fails.
> 
> I'm trying to figure out if it is possible to tell cmake to use the
> V1 that is at /usr/include/db.h.
> 
> I've tried various invocations of find_path and find_library in
> CMakeLists.txt, with and without appeals to default paths and such
> like, to no avail. I've tried any variation of -DCMAKE_XXXFLAGS I
> can think of, in CMakeLists.txt and on the command line, to no
> avail. (When using find_XXX, cmake tells me they're found, but still
> uses DB4. In the case of passing flags, cmake tells me that it
> is ignoring them.)
> 
> Now, at day's end, this is not A Big Deal; I uninstall BDB4, build
> nvi2, reinstall BDB4. But one would imagine that there is some
> (simple) way to instruct cmake to use X over Y when building Z?
> 
> [0] https://github.com/lichray/nvi2
> 

system include order path is implementation defined, but it sounds to me like 
your compiler (clang) is behaving in a fairly normal way - that is, it checks 
/usr/local/include before /usr/include, which allows you to have newer versions 
of libs in local. This has nothing to do with CMake - this is standard compiler 
behavior.  So, now it sounds like you want to change that default behavior for 
this target. If you can figure out the right set of flags to pass to clang to 
get it to find the right header, then it’s possible to convince CMake to pass 
those flags using something like target_compile_options(). 

The CMake find_path and find_library functions don’t do anything magical…they 
just simplify the process of searching various locations on your filesystem for 
the specified files, and conveniently find_library knows about library file 
naming convention. When those functions are used, they just end-up setting some 
variables to tell you what it found and where, but they don’t do anything 
special with compiler flags. It’s up to you to take the results (variables) of 
those functions and pass them along to your compiler/toolchain as you see fit.

So that’s the challenge here - figure out how to convince your compiler to 
ignore /usr/local/include, at least of this one dependency. If you have other 
things in /usr/local/include that you depend on, then this might be very 
tricky.  It looks like the -include option to clang might allow you to specify 
a full path to a file to include before preprocessing, but that might also 
require that you remove all #include  from your sources - I don’t know if 
that’s feasible.

If it were up to me, I’d probably choose to not install the newer lib to 
/usr/local because fighting the compiler regarding system include paths is not 
fun. If/when I needed the newer version, I’d put it in some non-system path 
(like /opt) and then tell the compiler to treat that alternate path with top 
precedence if/when I need to use the newer version. That’s just my 2 cents.

-Mike

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Tell cmake use /usr/include/db.h, not /usr/local/include/db.h

[Larry Hynes]

Hi

I'm building nvi2[0], on (Mac OS X Yosemite (10.10.5)), which uses
cmake.

nvi2 depends on a reasonably sane BSD environment, which would
include Berkeley DB V1 which is found at /usr/include/db.h.

I also have installed BDB V4, which lives at /usr/local/include/db.h,
for use by other programs.

The only way I can get nvi2 to build, is to uninstall BDB V4, in
which case cmake picks up V1 and all is well. Otherwise cmake
resolutely picks up V4 and the build fails.

I'm trying to figure out if it is possible to tell cmake to use the
V1 that is at /usr/include/db.h.

I've tried various invocations of find_path and find_library in
CMakeLists.txt, with and without appeals to default paths and such
like, to no avail. I've tried any variation of -DCMAKE_XXXFLAGS I
can think of, in CMakeLists.txt and on the command line, to no
avail. (When using find_XXX, cmake tells me they're found, but still
uses DB4. In the case of passing flags, cmake tells me that it
is ignoring them.)

Now, at day's end, this is not A Big Deal; I uninstall BDB4, build
nvi2, reinstall BDB4. But one would imagine that there is some
(simple) way to instruct cmake to use X over Y when building Z?

[0] https://github.com/lichray/nvi2

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Help on first cmake project

[Florian Lindner]

Am 07.07.2017 um 16:47 schrieb J Decker:
> 
> 
> On Thu, Jul 6, 2017 at 11:45 PM, Florian Lindner  > wrote:
> 
> Hello,
> 
> coming from scons I want to take a look into cmake...
> 
> My CMakeList.txt looks like:
> 
> 
> cmake_minimum_required (VERSION 3.0)
> project (ASTE)
> 
> add_executable(readMesh readMesh.cpp)
> 
> find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build/last)
> target_link_libraries(readMesh ${precice})
> set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} 
> $ENV{PRECICE_ROOT}/build/last)
> 
> 
> find_package(Boost 1.60.0
>   COMPONENTS program_options filesystem
>   REQUIRED)
> target_link_libraries(readMesh ${Boost_LIBRARIES})
> 
> find_package(MPI REQUIRED)
> target_link_libraries(readMesh ${MPI_LIBRARIES})
> set(COMPILE_FLAGS  ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
> set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS})
> 
> 
> and does it job, i.e. the target builds. precice is out own, 
> independently build library.
> 
> However, I have several questions:
> 
> * Can I make target_link_libraries add a library for all defined targets? 
> At the moment, there is only one, but in the
> projekt there are multiple, very similiar targets built.
> 
> No; each target needs to have target_link_libaries.  You can build a list of 
> libs to add like set( common_deps
> ${Boost_LIBRARIES} ${MPI_LIBRARIES} ) ; or appending to a variable like you 
> did with COMPILE_FLAGS.

Ok, that would be nice feature I think.

> * Can I make find_library to treat the library as required, as with 
> find_package?
> 
>  
> can add if( -NOTFOUND ) message( ERROR "xxx not found" )

Ok. I am a bit surprised, that there is no REQUIRED flag, just like it is with 
the similar find_package.

> can wrap that in a macro for simplification...
> 
> macro( my_find_library var )
>   find_library( ${var} ${ARGN} )
>   if( ${var}-NOTFOUND )
> message( FATAL_ERROR "${ARG2} was not found" )
>   endif()
> endmacro()

find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build/last)
if( precice-NOTFOUND )
  message(FATAL_ERROR "preCICE was not found")
endif()

but the missing library is not caught and the subsequent call to 
target_link_libraries fails.

Using if(NOT precice) instead made it working.

> (assumes that you're using the single name version, and not multiple names 
> using NAME command in find_library)
> 
> 
> * Can I reused the value of find_library's PATH setting? Especially if 
> there are multiple PATHs, wouldn't it be nice to
> have a precice-LIBPATH that contains the path, where the library was 
> found? So I can add this to CMAKE_LIBRARY_PATH? Or
> is there another function that does all that?
> 
> Yes, these become available for all sub projects also.  INCLUDE_DIRECTORIES() 
> and LINK_DIRECTORIES() will also get
> inherited by child projects.

Not sure if I got that, but we'll see...

Best,
Florian



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake