Re: [CMake] FindZLIB doesn't work for PGI compiler

[Chuck Atkins]

Hi Sanu,
We test pgi pretty heavily so it should work okay.  Can you show the output
failure you get when trying to configure?

- Chuck

On Tue, Jul 23, 2019, 1:21 AM 李 三乎  wrote:

> Dear CMake Community,
>
> I’m here to report an error occurred when using PGI compiler. The readme
> for CMake asks me to ask question first in the mailing list, and here I am.
>
> I’ve installed zlib1g-dev to my system, but CMake cannot find the zlib
> library for me. Then I tested it on a singularity ubuntu image ( similar to
> docker image ), with the following settings:
>
> Ubuntu 19.04 amd64
> PGI compiler community edition 19.04
> CMake 3.14
>
> CMakeLists.txt
> ```
> project( none C CXX)
> find_package( ZLIB REQUIRED )
> ```
>
> If I use gcc or clang, it would create the makefile successfully, but when
> I use PGI compiler (pgcc, pgc++), it would report not able to find zlib. I
> think there might be some problem with the FindZLIB.cmake file but I
> couldn’t find out where is the problem.
>
> Also, when using CLion configured with PGI compiler, there would be a lot
> of error messages ( although we can still build the project ), the error
> messages are really annoying. I feel it’s because the support for PGI
> compiler is still not perfect yet. Really wish CMake would like to add more
> support for this compiler.
>
> Thank you very much for reading. Have a great day!
>
> —
> Sanhu Li
>
> via Newton Mail
> 
> --
>
> 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
>
-- 

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] General question about variable scope.

[Chuck Atkins]

So, a couple things:

string(TOUPPER ${lib} lib_upper)
>   set(WITH_LIB_${lib_upper}_EXAMPLES "")
>
> This needs to be outside the foreach loop.  It's getting reset to empty on
every iteration rather than accumulating results

list(APPEND ${WITH_LIB_${lib_upper}_EXAMPLES} ${CMAKE_MATCH_1})
>
> Don't de-reference the first argument, just use the variable name itself,
i.e.:
list(APPEND WITH_LIB_${lib_upper}_EXAMPLES ${CMAKE_MATCH_1})

This is also well suited to a function, which are generally preferred over
macros as it will avoid polluting the current variable scope with temporary
variables:

function(bsBuildLibExamples lib)
  string(TOUPPER ${lib} lib_upper)
  set(all_lib_examples)
  get_cmake_property(all_vars VARIABLES)
  foreach(var IN LISTS all_vars)
if(var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
  list(APPEND all_lib_examples ${CMAKE_MATCH_1})
endif()
  endforeach()
  set(WITH_LIB_${lib_upper}_EXAMPLES "${all_lib_examples}" PARENT_SCOPE)
endmacro()

- Chuck
-- 

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] CMake with two C++ compilers

[Chuck Atkins via CMake]

Hi John,
Two different compilers in the same project for the same language is messy,
but in your case it's directly supproted as a special case for cuda using
the CMAKE_CUDA_HOST_COMPILER CMake variable or the CUDAHOSTCXX environment
variable.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Wed, May 8, 2019 at 7:27 AM JR Cary  wrote:

> Is there a standard way to deal with 2 C++ compilers?  Getting both
> there versions, etc.?
>
> I need one compiler for compiling ordinary C++ code and a different
> one to use as the host compiler for CUDA.
>
> Thx..John Cary
> --
>
> 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
>
-- 

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] Basic question how to find -lm include and lib dir with find_package or otherwise

[Chuck Atkins via CMake]

Usually you don't need to use the full path to libm, and it's only needed
sometimes depending on your compiler and toolchain.  I typically use
something like the following to deal with both the implicit and explicit
scenarios:

include(CheckCSourceCompiles)
set(LIBM_TEST_SOURCE "#include\nfloat f; int main(){sqrt(f);return
0;}")
check_c_source_compiles("${LIBM_TEST_SOURCE}" HAVE_MATH)
if(HAVE_MATH)
  set(LIBM_LIBRARIES)
else()
  set(CMAKE_REQUIRED_LIBRARIES m)
  check_c_source_compiles("${LIBM_TEST_SOURCE}" HAVE_LIBM_MATH)
  unset(CMAKE_REQUIRED_LIBRARIES)
  if(NOT HAVE_LIBM_MATH)
message(FATAL_ERROR "Unable to use C math library functions")
  endif()
  set(LIBM_LIBRARIES m)
endif()

target_link_libraries(fooTarget PRIVATE ${LIBM_LIBRARIES})

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.



On Fri, Mar 15, 2019 at 7:46 AM frodak17  wrote:

>
>
> On Thu, Mar 14, 2019 at 8:53 PM workbe...@gmx.at  wrote:
>
>> Hi everyone,
>>
>> i'm searching for a way to find the right include dir so that -lm can be
>> found, the is not find_package for this, is /usr/lib and /usr/include a
>> default because he find it without me adding any include or lib path for
>> the build.
>>
>>
>>
> It seems strange that you need to do this.  In my experience 'm' is just
> the math portion of the 'c' library.  Depending on which host and toolset
> you are using there can be multiple version of the 'm' library depending on
> target architecture and other options used.  The linker should just use the
> correct 'm' library just as it uses the correct 'c' library.  It could be
> in /usr/lib depending on how the compiler was packaged for your host.
> --
>
> 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
>
-- 

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] cmake cannot find source file (new to cmake)

[Chuck Atkins via CMake]

>
> When I ran "cmake .." in bin, cmake complained that it could not find
> source file src1.h in add_executable. What is wrong here?
>

Hi Lei,
Alex hit several of these points, but to wrap it up together:

A couple of things...

   - There's no need for a CMakeLists.txt in a directory if it's not
   actually going to do anything.  i.e. if you're not adding targets or
   executing any other CMake code then just traversing the directories doesn't
   serve any particular purpose.
   - The list of source files that a target uses to build don't have to
   necessarily be full paths, they can be absolute or relative paths, but the
   relative paths need to be relative to where the target is created, i.e. the
   add_executable(...) call.  So in your case, the target is "exec" in the
   "src" folder so all paths to source files, if relative paths and not
   absolute paths, need to be relative to the src directory.
   - include_directories is the older style CMake and will apply to all
   targets created after it.  Use target_include_directories instead for the
   more modern target-centric approach of having commands only apply to the
   appropriate target instead of globally.
   - Rather than use a list of sources, you can also use the target_sources
   command to programmatically add source files to a target based on necessary
   logic.  The same restriction applies though that the sources added need to
   be relative to the target location or an absolute path.
   - The preferred project layout for CMake is to really have out-of-source
   builds.  So instead having bin as a sub-directory of your project, just
   eliminate that level entirely.  You can certainly create your structure
   however you want but that's the suggested and preferred way of organising.

Combining these things, you could have nested CMakeLists.txt in which the
subdirectories are explicitly adding the sources:

   - Top Level:
   - CMakeLists.txt
  cmake_minimum_required(VERSION 3.8)
  project(proj)

  add_executable(exec)

  add_subdirectory(common)
  add_subdirectory(dir1)
  - common/
 - src1.h
 - CMakeLists.txt
 target_include_directories(exec PRIVATE
 ${CMAKE_CURRENT_SOURCE_DIR})
 target_sources(exec PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src1.h)
  - dir1/
 - src1.c
 - src2.c
 - CMakeLists.txt
 target_sources(exec PRIVATE
   ${CMAKE_CURRENT_SOURCE_DIR}/src1.c
   ${CMAKE_CURRENT_SOURCE_DIR}/src2.c
 )

Or a much simpler single file where no nested CMakeLists.txt are needed
since they wouldn't be doing anything:

   - Top Level:
   - CMakeLists.txt
  cmake_minimum_required(VERSION 3.8)
  project(proj)

  add_executable(exec
common/src1.h
dir1/src1.c dir1/src2.c
  )
  target_include_directories(exec common)

  - common/
 - src1.h
  - dir1/
 - src1.c
 - src2.c

Both are valid, the first is overkill for this simple example but
illustrates a way of doing things that can be helpful with much more
complex projects.  Either way, you also have a build directory completely
detached and outside your source tree instead of a sub-directory.

 - Chuck
-- 

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] CopyOfCMakeCache.txt

[Chuck Atkins]

Hi Frank,
What version of CMake are you running (cmake --version) and what is are you
running on?  Is this on the Windows Subsystem for Linux?  Older CMake
versions had similar trouble there that was resolved with more recent
releases.

- Chuck

On Thu, Oct 18, 2018, 17:04 Jean-Christophe Fillion-Robin 
wrote:

> Hi Frank,
>
> Out of curiosity, did you explicitly pass CMAKE_SYSTEM_NAME variable when
> configuring your project ?
>
> Jc
>
> On Wed, Oct 17, 2018 at 6:38 PM Frank Tocci  wrote:
>
>> Hello,
>>
>> I was using the CMake GUI when I came across the following message:
>>
>> System is unknown to cmake, create:
>> Platform/Ubuntu to use this system, please send your config file to
>> cm...@www.cmake.org so it can be added to cmake
>>
>> Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please send
>> that file to cm...@www.cmake.org.
>>
>> Performing Test HAVE_POLL_FINE
>>
>> System is unknown to cmake, create:
>> Platform/Ubuntu to use this system, please send your config file to
>> cm...@www.cmake.org so it can be added to cmake
>>
>> Performing Test HAVE_POLL_FINE - Failed
>>
>> Configuring done
>>
>> Generating done
>>
>>
>> CopyOfCMakeCache.txt is attached.
>>
>>
>> Thank you,
>>
>> Frank
>> --
>>
>> 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
>>
> --
>
> 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
>
-- 

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] Building arguments to target_comple_definitions()

[Chuck Atkins]

Hi Rob,

How would one set a variable containing multiple definitions to be passed
> to target_compile_definitions()  ?
>

The example you gave works (adjusting for typos, PIC, and adding visibility
specifier):
...
set(COMMON_DEFINITIONS SOME_DEFINE_1 SOME_DEFINE_2 SOME_DEFINE_3)
...
target_compile_definitions(CHUNK1 PRIVATE ${COMMON_DEFINITIONS}
CHUNK1_STUFF CHUNK_NAME=\"One\")
target_compile_definitions(CHUNK2 PRIVATE ${COMMON_DEFINITIONS}
CHUNK2_STUFF CHUNK_NAME=\"Two\")
target_compile_definitions(FooBar PRIVATE ${COMMON_DEFINITIONS})
...
results in the following:
...
/usr/bin/c++  -DCHUNK1_STUFF -DCHUNK_NAME=\"One\" -DSOME_DEFINE_1
-DSOME_DEFINE_2 -DSOME_DEFINE_3  -fPIC   -o
CMakeFiles/CHUNK1.dir/chunk_one.cpp.o -c
/home/chuck/Code/tmp/source/chunk_one.cpp
...
/usr/bin/c++  -DCHUNK2_STUFF -DCHUNK_NAME=\"Two\" -DSOME_DEFINE_1
-DSOME_DEFINE_2 -DSOME_DEFINE_3  -fPIC   -o
CMakeFiles/CHUNK2.dir/chunk_two.cpp.o -c
/home/chuck/Code/tmp/source/chunk_two.cpp
...
/usr/bin/c++  -DFooBar_EXPORTS -DSOME_DEFINE_1 -DSOME_DEFINE_2
-DSOME_DEFINE_3  -fPIC   -o CMakeFiles/FooBar.dir/foobar.cpp.o -c
/home/chuck/Code/tmp/source/foobar.cpp
...

Here you can see the common definitions make it to all targets.

- Chuck
-- 

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] Building arguments to target_comple_definitions()

[Chuck Atkins]

> So in CMake parlance, what type is the last argument to
> target_compile_definitions?  Is it a list, string or something else?
>

It's a series of VISIBILITY_SPECIFIER DEF1 DEF2 ... DEFN, so the visibility
specifier followed by a list of definitions, optionally followed by another
visibility specifier and list of definitions, etc.

add_library(Foo OBJECT Foo.cxx)
target_compile_definitions(Foo
  PUBLIC
COMMON_DEF_1 COMMON_DEF_2
  PRIVATE
FOO_SPECIFIC_DEF=42
)

will translate to something like:

c++ -DCOMMON_DEF_1 -DCOMMON_DEF_2 -DFOO_SPECIFIC_DEF=4 -o Foo.cxx.o -c
Foo.cxx

- Chuck


>
> *From: *Chuck Atkins 
> *Date: *Thursday, October 11, 2018 at 2:55 PM
> *To: *Rob Boehne 
> *Cc: *CMake Mail List 
> *Subject: *Re: [CMake] Building arguments to target_comple_definitions()
>
>
>
> So, are you suggesting that I make a “dummy” target and fill it with the
> common options in compile_definitions() and include_directories() (et. al.)
>
> Then make my OBJECT libraries (and the shared library) depend on the
> “dummy” target?
>
>
>
> If that’s not the suggestion, I’m afraid I don’t see how I can use this to
> set the common flags
>
>
>
> That's certainly one way you can solve the problem, i.e. making an
> interface library with the common defs, and a good idea at that, but that's
> not what I was referring to.  I was simply tying to explain that the error
> your getting trying to pass arguments to target_compile_options is because
> you're missing the visibility argument.
>
>
>
> - Chuck
>
-- 

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] Building arguments to target_comple_definitions()

[Chuck Atkins]

>
> So, are you suggesting that I make a “dummy” target and fill it with the
> common options in compile_definitions() and include_directories() (et. al.)
>
> Then make my OBJECT libraries (and the shared library) depend on the
> “dummy” target?
>

>
> If that’s not the suggestion, I’m afraid I don’t see how I can use this to
> set the common flags
>

That's certainly one way you can solve the problem, i.e. making an
interface library with the common defs, and a good idea at that, but that's
not what I was referring to.  I was simply tying to explain that the error
your getting trying to pass arguments to target_compile_options is because
you're missing the visibility argument.

- Chuck

>
-- 

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] Putting the git commit hash in a cmake variable

[Chuck Atkins]

> COMMAND "${GIT_EXECUTABLE}" describe --always HEAD
>

git describe is nice way to do it since you can get a monotonic-ish
increasing version number


>
> string(REGEX REPLACE "^.*-(.*)-g.*$" "\\1" MYAPP_VERSION_MICRO
> "${MYAPP_VERSION}")
> ...
> set(MYAPP_VERSION_MICRO "0")
>

Only tangentially related, CMake commands and functions that deal with
version information refer to the 4th component as _TWEAK.

- Chuck
-- 

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] Building arguments to target_comple_definitions()

[Chuck Atkins]

Hi Rob,


> target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS}  CHUNK1_STUFF
> CHUNK_NAME=\”One\” )
>
> target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS}  CHUNK2_STUFF
> CHUNK_NAME=\”Two\”)
>
> target_compile_definitions( FooBar ${COMMON_DEFINITIONS}  )
>

This is what I was referring to.  Adding visibility to
target_compile_definitions:

target_compile_definitions(CHUNK1 PRIVATE ${COMMON_DEFINITIONS}
CHUNK1_STUFF CHUNK_NAME=\"One\")
target_compile_definitions(CHUNK2 PRIVATE ${COMMON_DEFINITIONS}
CHUNK2_STUFF CHUNK_NAME=\"Two\")
target_compile_definitions(FooBar PRIVATE ${COMMON_DEFINITIONS})

All of the target_ commands take the format target_foo(target_name
USAGE_VISIBILY bar1 bar2 bar3 ...).  target_link_libraries is the exception
with everythign being PUBLIC by default but only because it pre-dates all
the other target commands.

- Chuck
-- 

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] FindMPI.cmake in 3.11.4

[Chuck Atkins]

Hi Burlen

Of course I read the documentation.
>

I certainly didn't mean for that to come off as an "rtfm", so my appologies
if it did, that wasn't my intent.



> why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get changed from
> cache variables to not chached variables? that seems to be the cause of the
> issue.
>

There was a completere-write of FindMPI from scratch to address a wide
range of issues with it.  In general many of the "old" behaviors were in
opposition to other established "best practices" so it was re-written with
many of these in mind.  As such, much of the old behavior w.r.t. variable
names may not have been preserved in an attemnt to bring the behavior more
inline with recommended current CMake practices.  So in some scenarios it
should be considdered a breaking change.


Alas after trying various settings described there in, nothing worked. my
> settings are ignored and erased.
>


>   Now how does one override the detection and tell it what to use in the
> new module?
>

There's several different scenarios to try to detect MPI and I believe they
happen in this order:

   1. Using the mpicc compiler wrapper as your "regular compiler"
  - libraries and includes should remain empty as nothing needs to be
  added for MPI to work
  - This is the case when using the CrayPE wrappers
   2. Locating mpicc in your path and interrogating it
  - Determined the set of includes and libraries to be added to the
  regular compiler to make MPI work
  - This is the typical behavior that get's used in *most* mpi
  environments.
   3. Falling back to manually searching for headers and libraries

Can you describe your environment and scenario more specifically so I can
try to reproduce it?

Thanks
- Chuck
-- 

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] FindMPI.cmake in 3.11.4

[Chuck Atkins]

Hi Burlen,
_LIBRARIES and _INCLUDE_DIRS are non-cached output variables.  The new
functionality should be documented as to how to guide the current FindMPI:
https://cmake.org/cmake/help/v3.12/module/FindMPI.html#variables-for-locating-mpi
.  That being said, is it incorrectl6y detecting or determine the MPI
installation?  If that's the case then we should probably fix that issue
instead.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183


On Thu, Sep 13, 2018 at 4:46 PM Burlen Loring 
wrote:

> Hi,
>
> I'm trying to transition from cmake 3.8.2 to cmake 3.11.4. There are a
> number of changes the way FindMPI.cmake behaves in 3.11 that are making
> this difficult.
>
> In 3.11 how do I override the settings? For instance I want to set
> MPI_C_LIBRARIES, MPI_C_INCLUDE_DIRS? In 3.8 all I had to do was set
> those variables myself, before find_package(MPI), and my setting were
> used. in 3.11 find_package(MPI) ignores, and wipes out my settings, and
> then fails.
>
> Isn't it a defacto standard of cmake to be able to override find modules
> by setting the libraries and include dirs before the module runs?
>
> Burlen
>
>
> --
>
> 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
>
-- 

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] Shared libraries

[Chuck Atkins]

Hi Tony,

I expect what your seeing is likely the result of how MaraiaDBhas
specifically implemented their CMake build.  The only builtin CMake
variable to control this is BUILD_SHARED_LIBS, which when set to "ON"
changes the behavior of add_library(foo) to be add_library(foo SHARED),
instead of the default add_library(foo STATIC).  The other
BUILD_STATIC_LIBS and DISABLE_SHARED are variables are not builtin to CMake
and are part of however they have chosen to implement their build.

CMake builds are typically designed to produce a single configuration, i.e.
shared release or static debug, etc.  Often, however, because to have the
flexibility to do otherwise. projects will try to instead implement a build
that produces several configurations in a single pass.  It seems this is
what MariaDB has done and as such the variables to control it will be
unique and specific to that project and how they've decided to implement it.

------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, Aug 9, 2018 at 12:23 PM REIX, Tony  wrote:

> Hi,
>
>
> On AIX, when building MongoC 1.11, cmake 3.11.4 generates lib*.so files
> and lib*.a files which contain .o files.
>
> On AIX, we should get libraries lib*.a containing the lib*.so file.
>
> I've tried to use:
>
> -DBUILD_SHARED_LIBS=ON  \
> -DBUILD_STATIC_LIBS=OFF \
> -DCMAKE_C_CREATE_SHARED_LIBRARY=ON  \
> -DCMAKE_CXX_CREATE_SHARED_LIBRARY=ON
> and I see that, for MariaDB, someone has tried with:
>
> -DDISABLE_SHARED=OFF
>
>
> None seems to work.
>
>
> Which CMake variable should I use for asking CMAKE to generate shared
> libraries rather than static ones: lib*.a file containing .so files rather
> than .o files.
>
>
> Thanks
>
>
> Cordialement,
>
> Tony Reix
>
> tony.r...@atos.net
>
> ATOS / Bull SAS
> ATOS Expert
> IBM Coop Architect & Technical Leader
> Office : +33 (0) 4 76 29 72 67
> 1 rue de Provence - 38432 Échirolles - France
> www.atos.net
> <https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.=http%3a%2f%2fwww.atos.net%2f>
> --
>
> 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
>
-- 

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] Is there a way to obtain the current compiler standard flag?

[Chuck Atkins]

Hi Chris.

Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable.  For
example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)

project(foo CXX)

foreach(std IN ITEMS 98 11 14 17)
  message("C++${std} std flags: ${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
  message("C++${std} ext flags:
${CMAKE_CXX${std}_EXTENSION_COMPILE_OPTION}")
endforeach()

Wll generate for GCC on Linux:
-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -std=c++98
C++98 ext flags: -std=gnu++98
C++11 std flags: -std=c++11
C++11 ext flags: -std=gnu++11
C++14 std flags: -std=c++14
C++14 ext flags: -std=gnu++14
C++17 std flags: -std=c++1z
C++17 ext flags: -std=gnu++1z
-- Configuring done

PGI on Linux:
-- The CXX compiler identification is PGI 18.4.0
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++ --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -A
C++98 ext flags: --gnu_extensions
C++11 std flags: --c++11;-A
C++11 ext flags: --c++11;--gnu_extensions
C++14 std flags: --c++14;-A
C++14 ext flags: --c++14;--gnu_extensions
C++17 std flags: --c++17;-A
C++17 ext flags: --c++17;--gnu_extensions
-- Configuring done


And for IBM XL on AIX:
-- The CXX compiler identification is XL 13.1.3
-- Check for working CXX compiler: /usr/bin/xlC
-- Check for working CXX compiler: /usr/bin/xlC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -qlanglvl=strict98
C++98 ext flags: -qlanglvl=extended
C++11 std flags: -qlanglvl=extended0x
C++11 ext flags: -qlanglvl=extended0x
C++14 std flags:
C++14 ext flags:
C++17 std flags:
C++17 ext flags:
-- Configuring done
-- Generating done

- Chuck
-- 

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] failure to build Cmake to / against non-standard directory under Linux

[Chuck Atkins]

CMAKE_PREFIX_PATH just adds a set of search paths.  To instead have it
shift it's entire search infrastructure, you can use the
CMAKE_FIND_ROOT_PATH CMake variable and a few associated with it, which
will cause the entire set of search heuristics to be re-rooted in the
specified path.  First run the bootstrap step:

mkdir build
cd build
../bootstrap

Then use the bootstrapped CMake with the find root path settings:

./Bootstrap.mk/cmake \
  -DCMAKE_FIND_ROOT_PATH=/home/tools \
  -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \
  -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \
  -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY \
  -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=ONLY \
  -DCMAKE_USE_SYSTEM_LIBRARIES=ON \
  -DCMAKE_INSTALL_PREFIX=/home/tools \
  ..

make -j8

make install


- Chuck
-- 

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] how to detect architecture ?

[Chuck Atkins]

Hi Franck,

I'd suggest going a little more robust by using both
CMAKE_SHARED_LIBRARY_PREFIX and CMAKE_SHARED_LIBRARY_SUFFIX to generate a
function at configure time to resolve the correct filename.

For example, util.h.in:

#ifndef _UTIL_H_
#define _UTIL_H_

#include 

static inline
void get_library_filename(char* filename, const char* libname)
{
  sprintf(filename, "@CMAKE_SHARED_LIBRARY_PREFIX@
%s@CMAKE_SHARED_LIBRARY_SUFFIX@", libname);
}

#endif /* _UTIL_H_ */


Then your CMakeLists.txt:

configure_file(
  ${CMAKE_CURRENT_SOURCE_DIR}/util.h.in
  ${CMAKE_CURRENT_BINARY_DIR}/util.h
  @ONLY
)
add_executable(foo main.c ${CMAKE_CURRENT_BINARY_DIR}/util.h)
target_include_directories(foo PRIVATE ${CMAKE_CURRENT_BINARY_DIR})

And finally main.c:

#include 
#include 

int main(int argc, char **argv)
{
  char filename[256];

  get_library_filename(filename, "foo");

  printf("Library foo uses file %s\n", filename);

  return 0;
}

This will give you "libfoo.so" on Linux, "libfoo.dylib" on Apple, and "
foo.dll" on Windows.


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Jan 9, 2018 at 10:04 AM, Franck Houssen <franck.hous...@inria.fr>
wrote:

> Thanks !
>
> - Mail original -
> > De: "Konstantin Tokarev" <annu...@yandex.ru>
> > À: "Franck Houssen" <franck.hous...@inria.fr>, "CMake Mail List" <
> cmake@cmake.org>
> > Envoyé: Mardi 9 Janvier 2018 16:00:55
> > Objet: Re: [CMake] how to detect architecture ?
> >
> >
> >
> > 09.01.2018, 17:58, "Franck Houssen" <franck.hous...@inria.fr>:
> > > Is there a way to detect architecture ?
> > >
> > > Seems there is nothing simple since these old threads :
> > > https://stackoverflow.com/questions/11944060/how-to-
> detect-target-architecture-using-cmake/12024211#12024211
> > > https://stackoverflow.com/questions/16796629/cmake-
> create-architecture-aware-makefile
> > >
> > > Is there a solution now ?
> > >
> > > My need is quite simple: I have an executable who needs dlopen. To
> test it,
> > > I planned to write a bash script that would have done "./exe
> > > /path/to/lib.so" on linux (debian, ...) OR "./exe /path/to/lib.dylib"
> on
> > > osx. To replace correctly so/dylib in the bash script I need to know
> the
> > > architecture. Any idea how to do this ?
> >
> > ${CMAKE_SHARED_LIBRARY_SUFFIX}
> >
>
> Oh man ! Didn't know this one : exactly what I was looking for
>
> > > Franck
> > > ,--
> > >
> > > 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
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> --
>
> 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
>
-- 

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] Bootstrap fails to detect C++11 compiler on AIX 7.1/XL C 13.1.3 toolset

[Chuck Atkins]

Hi Nathan,
I am able to reproduce this error on our Dashboard machine; it should be
working and clearly it's not at the moment.

I will investigate...

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.

On Tue, Dec 19, 2017 at 11:48 AM, Nathan Strong <gblues+cm...@gmail.com>
wrote:

> I am having difficulty building CMake on AIX 7.1 using IBM XL C 13.1.3,
> which seems to be the newest version as of April 2017.
>
> The bootstrap script fails with the following error:
>
> -
> CMake 3.10.1, Copyright 2000-2017 Kitware, Inc. and Contributors
> Found XL toolchain
> C compiler on this system is: xlc
> -
> Error when bootstrapping CMake:
> Cannot find a C++ compiler supporting C++11 on this system.
> Please specify one using environment variable CXX.
> See cmake_bootstrap.log for compilers attempted.
> -
> Log of errors: src/cmake-3.10.1/Bootstrap.cmk/cmake_bootstrap.log
> -
>
> Given that AIX is explicitly listed as a supported platform, and I am
> using the latest version of the IBM AIX compiler, I find this error dubious.
>
> Below is a the contents of the cmake_bootstrap.log, where we can see that
> it does try to use the appropriate -q flag to enable the compiler's
> supported C++11 features.
>
> Is XL C simply unsupported?
>
> --- paste below ---
> Checking for XL toolchain
> Try: xlc
> Line: xlc  cmake_bootstrap_18350136_test.c -o
> cmake_bootstrap_18350136_test
> --  file   ---
> int main() { return 0; }
> --
> Test succeeded
> Try: xlC
> Line: xlC  cmake_bootstrap_18350136_test.cpp -o
> cmake_bootstrap_18350136_test
> --  file   ---
> int main() { return 0; }
> --
> Test succeeded
> Checking whether 'xlc  ' works.
> Try: xlc
> Line: xlc   cmake_bootstrap_18350136_test.c -o
> cmake_bootstrap_18350136_test
> --  file   ---
>
> #ifdef __cplusplus
> # error "The CMAKE_C_COMPILER is set to a C++ compiler"
> #endif
>
> #if defined(__sun) && __STDC_VERSION__ < 199901L
> #error "On Solaris we need C99."
> #endif
>
> #include 
>
> int main(int argc, char* argv[])
> {
>   printf("%d%c", (argv != 0), (char)0x0a);
>   return argc - 1;
> }
>
> --
> 1
> Test succeeded
> Checking whether 'xlC  ' works.
> Try: xlC
> Line: xlC   cmake_bootstrap_18350136_test.cxx -o
> cmake_bootstrap_18350136_test
> --  file   ---
>
> #include 
> #include 
> #include 
>
> #if __cplusplus < 201103L
> #error "Compiler is not in a mode aware of C++11."
> #endif
>
> #if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
> #error "SunPro <= 5.13 mode not supported due to bug in move semantics."
> #endif
>
> class Class
> {
> public:
>   int Get() const { return this->Member; }
> private:
>   int Member = 1;
> };
> int main()
> {
>   auto const c = std::unique_ptr(new Class);
>   std::cout << c->Get() << std::endl;
>   return 0;
> }
>
> --
> "/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
> #error directive: To use the unordered map library, macro __IBMCPP_TR1__
> must be defined
> by user to non zero integer value..
> "cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
> directive: "Compiler is not in a mode aware of C++11.".
> Test failed to compile
> Checking whether 'xlC  ' works.
> Try: xlC
> Line: xlC   cmake_bootstrap_18350136_test.cxx -o
> cmake_bootstrap_18350136_test
> --  file   ---
>
> #include 
> #include 
> #include 
>
> #if __cplusplus < 201103L
> #error "Compiler is not in a mode aware of C++11."
> #endif
>
> #if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
> #error "SunPro <= 5.13 mode not supported due to bug in move semantics."
> #endif
>
> class Class
> {
> public:
>   int Get() const { return this->Member; }
> private:
>   int Member = 1;
> };
> int main()
> {
>   auto const c = std::unique_ptr(new Class);
>   std::cout << c->Get() << std::endl;
>   return 0;
> }
>
> --
> "/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
>

Re: [CMake] Failed to build C++ source with CMakeLists.txt

[Chuck Atkins]

Hi Jupiter,


Compiling the C compiler identification source file "CMakeCCompilerId.c"
> failed.
> Compiler: /usr/local/gcc/4.9.1/bin/gcc
> Build flags: /usr/local/cppcms/1.1.0/include
>

It looks like you have an errant "/usr/local/cppcms/1.1.0/include" set in
your CFLAGS environment variable, or otherwise specified as a default
argument to the compiler, which is obviously not a valid flag.

- Chuck
-- 

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] CPack Multicore Usage

[Chuck Atkins]

>
> cause cpack does not "rebuild" the software again, it uses the compiled
> software and just starts the "install" into its _CPack_Packages
> subdirectories
>

Just running `cpack` does not.  However, CMake does generate a "package"
make target that is tied into your dependencies, so if instead of running
`make -jN; cpack` you could also run 'make -jN package' which will run the
build, since it's a dependency of the package target.

- Chuck
-- 

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] CPack Multicore Usage

[Chuck Atkins]

> > In calls to cpack only one core is used if Makefiles are used. Is there
> any option to enable multicore?
>

It depends on what your trying to achieve.  Typically the bottleneck for
CPack is in the compression step of the resulting tar (or rpm, etc.).  In
that case, CMake is limited by the libarchive, libz, libbz2, liblzma, etc.
implementations it's linked to, which are typically single threaded.  It's
really no different than taking an install tree and running "tar -czf
foo.tgz /path/t/foo-prefix".  So in that sense, even if you can
parallelizes the "temporary" install step where it collects the files to
packages, actually generating and compressing the package, which is the
costly part, will likely remain a single process.
-- 

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] OBJECT libraries and working around lake of target_link_libraries

[Chuck Atkins]

Hi David,


> Supporting OBJECT libraries in
> target_link_libraries calls was mentioned mentioned right back here
> https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but
> sadly seems still to be on the back burner.
>

It's not on the back burner!  There has been progress on desiging the rest
of the implementation to make OBJECT libraries "first class citizens" and
I  can't give you actual dates I do believe you can probably expect it some
time this year.


>
> Not being
> able to use target_link_libraries with thier transitive nature made this
> very painful, many days of work.


I actually just recently went through the exercise of creating a workaround
for this in one of my projects so I can certainly understand the gaping
hole that is currently present.  The workaround I ended up with was to
create three seperate libraries: one for the objects, one for the usage
requirements, and then a third that combines them.

add_library(foo_objects OBJECT foo_src1.cxx foo_src2.cxx ...)

add_library(foo_interface INTERFACE)
target_link_libraries(foo_interface INTERFACE FooDepend1 FooDepend2 ...)
target_include_directories(foo_interface INTERFACE
  $
  $)

add_library(foo INTERFACE)
target_sources(foo INTERFACE $)
target_link_libraries(foo INTERFACE foo_interface)

The interface sources property on "foo" will populate the object files into
whatever uses "foo" in its target_link_libraries and then the usage
requirements in foo_interface will populate transitively.  The only problem
with this approach, and the reason for creating three separate libraries
instead of just adding the objects to the sources on foo_interface, is that
INTERFACE_SOURCES will continue to get propagated transitively potentially
causing duplicate symbols upstream, so it's really only appropriate for
private linking so you want to link publically then add the objects
manually and pass the interface publically.  This essentially means you
need to use it like this:

// Use foo privately, so just put "foo" in TLL and it just works
add_library(bar1 bar1_src1.cxx bar1_src2.cxx)
target_link_libraries(bar1 PRIVATE foo)

// Use foo publicly so we need to separately grab the objects and
// their usage requirements.
add_library(bar2
  bar2_src1.cxx bar2_src2.cxx
  $)
target_link_libraries(bar2 PUBLIC foo_interface)

This is effectively what the current plan is for the upstream
implementation, just all rolled into one; i.e. the objects get added to
whatever is explicitly linking with target_link_libraries, but all
transitive linkage only uses the interface usage requirements.  Plans, of
course, may change but that's what it's looking like right now, we just
need to find the time and funding to implement it.

- Chuck
-- 

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] Unable to build cmoka project using cmake

[Chuck Atkins]

Hi Rajesh, so you're saying it works with 3.8.2 but not with 3.9.x?  Can
you try with the recent release candidate, 3.9.0-RC5?  It would be helpful
to know the output from what you see on the version that works vs the one
that doesn't since it sounds like a possible regression.

Thanks.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Fri, Jun 30, 2017 at 1:17 PM, Rajesh Kumar <thisiz...@gmail.com> wrote:

> Tried with cmake 3.8.2 version. Able to compile CMOCKA.
>
> Regards
> Rajesh
>
> On Wed, Jun 21, 2017, 3:10 PM Rajesh Kumar <thisiz...@gmail.com> wrote:
>
>> Hi Al,
>>
>> I am unable to build cmocka project using Cmake. The below are the errors
>> which I'm facing.
>>
>> "The C compiler identification is unknown"
>> "System is unknown to cmake, create: to use this system, please send your
>> config file to cm...@www.cmake.org so it can be added to cmake"
>>
>> Please suggest.
>>
>> Regards
>> Rajesh
>>
>
> --
>
> 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
>
-- 

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-developers] how does target_compile_features() test the c++11 conformance?

[Chuck Atkins]

Hi Claus,

how does target_compile_features() test the c++11 conformance?
>

It doesn't.  The language features supported by different compilers and
thier various versions is basically a manually constructed whitelist since
testing for them at configure time is far too costly.  You can see the
details for msvc here in the internal compiler detection logic in the CMake
distribution: Modules/Compiler/MSVC-CXX-FeatureTests.cmake


 target_compile_features(${targetname} PRIVATE cxx_std_11) # OK
>
> But wenn I use this most features are missing:
>
> target_compile_features(${targetname} PRIVATE
>cxx_contextual_conversions  # OK
> ...

   #FIXME: missing features at MS VS12 2013:
> ...
>cxx_aggregate_default_initializers

...
>  )
>

The cxx_std_11 compile feature is a meta-feature.  Basically it tells CMake
to Use the compiler in C++11 mode if possible, and then the cmpiler will do
what it can.  This is effectively adding the -std=c++11 flag to gcc or
-std=c++1y for cxx_std_14.  The compiler may not support all the features
but CMake knows that it can at least support *some* so it will try to use
what it can.  MSVC is a bit of an oddball with compilers since you cant
actually control the language level (maybe with 2017 you can), i.e. you
can't explicitly instruct msvc to build in C++98 mode only.

The individual language features wre initially put in place due to the
half-broken C++11 implementations that thend to be available in many
compilers (as you're finding out).  However, over time as it's used more
that level of granularity is less and less useful.  Hence the addition of
the meta-features for language levels.  Several compilers that have
reecently added language standard support in CMake (IBM XL, Cray, PGI) are
now just using the meta-feature as the maintenace burdon for maintaining
the feature tables is too great with respect to the reward.

Hope that helps clarify the state of things.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Unable to build cmoka project using cmake

[Chuck Atkins]

Hi Rajesh,
 We would need more information to be useful:

   - What version of CMake are you using?
   - What compiler and version are you using?
   - What OS and version are you using?
   - Do you have separate source and build directories?
   - How are you running cmake?


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Wed, Jun 21, 2017 at 5:47 AM, Rajesh Kumar <thisiz...@gmail.com> wrote:

> Hi All,
>
> I am unable to build cmocka project using Cmake. The below are the errors
> which I'm facing.
>
> "The C compiler identification is unknown"
> "System is unknown to cmake, create: to use this system, please send your
> config file to cm...@www.cmake.org so it can be added to cmake"
>
> Please suggest.
>
> Regards
> Rajesh
>
> --
>
> 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
>
-- 

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] setting rpath-link

[Chuck Atkins]

Hi Petros,
This doesn't really answer your question but it may solve your problem a
different way.  I've fought this very same boost problem many times in the
past.  In my case it was needing to link against Matlab dev libraries,
which in turn pulled their own private copy of boost in.  I tried a similar
approach of rpath-link but it wasn't feasible since it had to work on
Windows as well.  The best way to address it, I found, was to use the bcp
tool that comes with boost to generate a copy of the boost source tree with
a different namespace.  So I created my own private boost in the kwboost::
namespace instead of boost:: with libraries kwboost_filesystem.so, etc.
That way I could guarantee that the version I used was exactly the version
I created and would in turn also not create the same problem for anybody
else when they linked to me.

- Chuck <(518)%20881-1183>

On Fri, Jun 16, 2017 at 10:50 AM, Mamales, Petros via CMake  wrote:

> Hi,
>
> I am in a situation where I have to use 2 versions of the boost library
> (c++), one “explicitly” and one indirectly (through a package that comes as
> a shared lib).
>
> The external package is to be considered as a black box.
>
> Playing around on the web (as I am rather new to it), I came across the
> very nice article:
>
> http://www.kaizou.org/2015/01/linux-libraries/
>
> which in the last section recommends the usage of
> –rpath-link=/path/to/old/boost
>
> How can I specify this in CMake (preferably in 3.5.2 , as this s the
> currently used version in the company I work for)?
>
> TIA,
>
> Petros
>
>
>
> PS: Issues of how this would propagate at installation phase, although
> very important, are not pressing right now, as manual workarounds can be
> employed, or another question later may be made ;-)
>
>
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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] Different flags for compiling and linking with Fortran

[Chuck Atkins]

Hi Xavier,

CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
>
...

> -- The C compiler identification is Clang 3.8.0
> -- The CXX compiler identification is Clang 3.8.0
> ...
>
-- The Fortran compiler identification is XL
>

What version of CMake are you using?  Give that the C and C++ compilers are
detected as Clang then I suspect it's rather old.  They should also be
detected as XL like the Fortran compiler.  Do you get the same XL Fortran
errors using a new version of CMake?

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

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] Emacs cmake-mode indentation flaw

[Chuck Atkins]

Hi Frank,
It's really a matter of personal style.  There's a multitude of different
ways that people format multi-line function calls so no one way is right or
wrong.  For instance:

foo(
  bar1
  bar2)

foo(
  bar1
  bar2
  )

foo(
  bar1
  bar2
)

foo(bar1
bar2)

foo(bar1
bar2
)

foo(bar1
bar2
)

All of which have their justifications.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Fri, Jun 2, 2017 at 1:57 AM, Frank Roland <theldo...@hotmail.com> wrote:

> There is probably a faulty indentation implemented in cmake-mode for emacs
> regarding closing parens.
>
> If you have the following source code:
>
> foo(
>bar
> )
>
>
> I indents the closing parenwould expect it to be indented like this:
>
> foo(
>bar
>)
>
>
> I would expect the single closing paren to be not indendet.
>
>
> Can anybody confirm that this is an issue worth reporting?
>
>
> I could also create a pull request for a fix if there is interest in doing
> so.
>
>
>
> --
>
> 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
>
-- 

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-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Chuck Atkins]

>
> Hi Chuck (off list):
>

Hi Alan (on list)



> but the one above I completely missed.

...

> with the hint above I should be able to figure out
> all those remaining issues on my own


Excellent!  Glad to hear it.  Inconsistent path quoting is a common pitfal
when writing portable CMake code.  It bites all of us at one point or
another, even Brad sometimes.  Glad I could help.



> Or even better, don't blow away the current module path, jsut append to
>>> the front:
>>> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
>>>
>>
> What is the use case you had in mind for not blowing away
> CMAKE_MODULE_PATH?  Does CMake itself sometimes set CMAKE_MODULE_PATH
> so blowing away this variable by setting it in the top-level
> CMakeLists.txt file (something that is done in all the CMake-based
> build systems I have helped to implement) could cause problems?


The typical use case is when your package is being used as a third party
library by somebody else.  There are many different ways that could be done
but for small dependencies, a typical approach is to just place the code in
a subdirectory and add it to an existing build with add_subdirectory.  In
this case, the calling project has set up the environment in a particular
way and your forcibly throwing it away.  There's other use cases for it but
it's typically good practice to make yourself work within an existing
environment rather than ignore the environment and create your own unless
you have a specific reason (other than I don't know what they're going to
do)


I wouldn't want to allow such freedom to users of software packages I am
> associated with since it implies a significant increase (more things
> that could possibly go wrong) in the support burden for each such
> project.


It's certainly up to you since it's your code but if you're distributing
source then somebody will just change it anyway if that's their use case.
Using the insert instead of set allows both uses cases; i.e. as a
standalone library or a third party library included by a larger CMake
project, so why limit it.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Chuck Atkins]

In addition to that in the Main CMakeLists.txt, make a similar change in
CMakeTestAdaCompiler.cmake.  Replace:
set(CMAKE_MODULE_PATH ${CMAKE_Ada_MODULES})
with:
list(INSERT CMAKE_MODULE_PATH 0 \"${CMAKE_Ada_MODULES}\")

The additional quoting here is because it's inside a file(WRITE ...)
command.  With both of those changes, I get:

source: ~/tmp/test_ada source
binary: ~/tmp/test_ada build
output:

[chuck.atkins@hal9000 test_ada build]$ cmake ../test_ada\ source
-- The C compiler identification is GNU 6.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_Ada_COMPILER_ID = GNU
-- Check for working /usr/bin/gnatmake compiler:
-- Check for working /usr/bin/gnatmake compiler:  -- works
-- CMAKE_Ada_COMPILER = /usr/bin/gnatgcc
-- GNAT_MAJOR_VERSION = 6
-- GNAT_VERSION = 6.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/
khq.kitware.com/chuck.atkins/tmp/test_ada build
[chuck.atkins@hal9000 test_ada build]$




------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, May 25, 2017 at 12:00 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:

> Hi Alan,
>
> You're missing quotes so when CMake expands CMAKE_SOURCE_DIR then the
> space in the filename is interpreted as a list separator, no different than:
> set(my_list foo bar)
> What you want instead is:
> set(my_list "foo bar")
>
> Change:
> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
> To:
> set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")
>
> Or even better, don't blow away the current module path, jut append to the
> front:
> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
>
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Mon, May 22, 2017 at 3:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
> wrote:
>
>> So my guess is the measures that have been used so that a blank in the
>>> fullpath name works fine for CMake language support files that are
>>> installed by CMake have not been extended to the case where
>>> CMAKE_MODULE_PATH must be used to find the language support files.
>>>
>>
>> I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
>> to find the find modules we have implemented. That use case works
>> without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
>> So such a blank only appears to be an issue when CMAKE_MODULE_PATH
>> is used to find language support files.
>>
>> Alan
>>
>> __
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> 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
>> __
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Chuck Atkins]

Hi Alan,

You're missing quotes so when CMake expands CMAKE_SOURCE_DIR then the space
in the filename is interpreted as a list separator, no different than:
set(my_list foo bar)
What you want instead is:
set(my_list "foo bar")

Change:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
To:
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")

Or even better, don't blow away the current module path, jut append to the
front:
list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Mon, May 22, 2017 at 3:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:

> So my guess is the measures that have been used so that a blank in the
>> fullpath name works fine for CMake language support files that are
>> installed by CMake have not been extended to the case where
>> CMAKE_MODULE_PATH must be used to find the language support files.
>>
>
> I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
> to find the find modules we have implemented. That use case works
> without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
> So such a blank only appears to be an issue when CMAKE_MODULE_PATH
> is used to find language support files.
>
> Alan
>
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> 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
> __
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Proposed Feature: automatic search prefixes for find modules

[Chuck Atkins]

Brad and I discussed this a few years ago but nothing really came of it.
Working through several find modules today, I saw many common patterns for
this and realized it should be pretty easy to implement, so here it is:

Allow the variables ENV{PackageName_ROOT} and PackageName_ROOT to be used
as initial search prefixes for al find_{file,path,library,program} commands
executed from within a find module.

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

Specifying the search prefix is a very common pattern, especially when the
utility is not setup in your path, and prevents the need to explicitly set
the location of all the various headers and libraries for a module when you
can just specify a prefix to use.

Thoughts? Good Idea?  Bad idea?  Good, but do it differently?  Undecided?

Thanks
- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMAKE_SIZEOF_VOID_P question

[Chuck Atkins]

Hi Thomas,

According to the documentation CMAKE_SIZEOF_VOID_P it is determined by
> running the compiler. However it seems that it is not using pertinent flags
> from the configuration, in particular CMAKE_C_FLAGS and CMAKE_CXX_FLAGS.
>

It is but the results from type size checking get saved in cache variables
so when run a second time, even though specifying extra CMAKE_CXX_FLAGS,
the CMAKE_SIZEOF_VOID_P variable already exists in cache so it's not
checked again.  If you clear your build directory before each invocation of
CMake then you should see it switch between 4 and 8 as expected.

------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

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-developers] Some info about AIX needed

[Chuck Atkins]

Hi Gregor,
Please try to keep these sort of conversations on the dev list to ensure
that others can benefit from or contribute to the discussion as well.

I just checked on the AIX 7.2 dashboard machine.  Here's the output from
all possible uname switches described in the manpage:
uname -a
AIX power8-aix 2 7 00FA74164C00

uname -x
AIX power8-aix 4201911884 2 7 00FA74164C00

uname -F
8B646080

uname -f
8B646083

uname -l
4201911884

uname -L
3 p3-power8-aix

uname -m
00FA74164C00

uname -M
IBM,8284-22A

uname -n
power8-aix

uname -p
powerpc

uname -r
2

uname -s
AIX

uname -u
IBM,02217416W

uname -v
7

uname -W
0

Attached is the cmake --system-information output from that same machine
using the CMake nightly build build with the IBM XL compiler 13.1.3:
[atkins3@power8-aix My_Tests]$ ./CMake_IBM-13.1.3/CMake-build/bin/cmake
--version
cmake version 3.8.20170327-gc4c307

CMake suite maintained and supported by Kitware (kitware.com/cmake).
[atkins3@power8-aix My_Tests]$

- Chuck


On Tue, Mar 28, 2017 at 4:32 PM, Gregor Jasny  wrote:

> On 3/28/17 10:08 PM, Gregor Jasny wrote:
> > Could you please run the following on you AIX box?
> >
> > uname -s ; uname -v ; uname -r
>
> Maybe also
>
> cmake --system-information aix.txt and attach the output.
>
> Thanks,
> Gregor
>
Avoid ctest truncation of output: CTEST_FULL_OUTPUT

=== MAIN VARIABLES

CMAKE_STATIC_LIBRARY_PREFIX == "lib"
CMAKE_STATIC_LIBRARY_SUFFIX == ".a"
CMAKE_SHARED_LIBRARY_PREFIX == "lib"
CMAKE_SHARED_LIBRARY_SUFFIX == ".so"
CMAKE_SHARED_MODULE_PREFIX == "lib"
CMAKE_SHARED_MODULE_SUFFIX == ".so"


CMAKE_DL_LIBS == "-lld"
CMAKE_LIBRARY_PATH_FLAG == "-L"
CMAKE_LINK_LIBRARY_FLAG == "-l"
CMAKE_SKIP_RPATH == "NO"
CMAKE_SYSTEM_INFO_FILE == "Platform/AIX"
CMAKE_SYSTEM_NAME == "AIX"
CMAKE_SYSTEM == "AIX-2"
CMAKE_CXX_COMPILER == "/usr/bin/c++"
CMAKE_C_COMPILER == "/usr/bin/gcc"
CMAKE_COMPILER_IS_GNUCC == "1"
CMAKE_COMPILER_IS_GNUCXX == "1"

// C shared library flag
CMAKE_SHARED_LIBRARY_C_FLAGS == "-fPIC"
CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_LIBRARY_LINK_FLAGS == ""
CMAKE_SHARED_LIBRARY_RUNTIME_FLAG == ""
CMAKE_SHARED_LIBRARY_RUNTIME_FLAG_SEP == ""
CMAKE_SHARED_LIBRARY_LINK_STATIC_C_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_C_FLAGS == ""

// C shared module flags
CMAKE_SHARED_MODULE_C_FLAGS  == "-fPIC"
CMAKE_SHARED_MODULE_CREATE_C_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_MODULE_LINK_STATIC_C_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_DYNAMIC_C_FLAGS == ""

// C exe flags
CMAKE_EXE_LINK_STATIC_C_FLAGS == ""
CMAKE_EXE_LINK_DYNAMIC_C_FLAGS == ""

// CXX shared library flags
CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_LIBRARY_CXX_FLAGS == "-fPIC"
CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS == "-Wl,-bexpall"
CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG == "-Wl,-blibpath:"
CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG_SEP == ":"
CMAKE_SHARED_LIBRARY_LINK_STATIC_CXX_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_CXX_FLAGS == ""

// CXX shared module flags
CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_MODULE_CXX_FLAGS == "-fPIC"
CMAKE_SHARED_MODULE_LINK_STATIC_CXX_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_DYNAMIC_CXX_FLAGS == ""

// CXX exe flags
CMAKE_EXE_LINK_STATIC_CXX_FLAGS == ""
CMAKE_EXE_LINK_DYNAMIC_CXX_FLAGS == ""

CMAKE_USER_MAKE_RULES_OVERRIDE == ""
CMAKE_VERBOSE_MAKEFILE == "FALSE"
CMAKE_BUILD_TYPE == ""
CMAKE_CXX_FLAGS == ""
CMAKE_CXX_FLAGS_DEBUG == "-g"
CMAKE_CXX_FLAGS_MINSIZEREL == "-Os -DNDEBUG"
CMAKE_CXX_FLAGS_RELEASE == "-O3 -DNDEBUG"
CMAKE_CXX_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG"

CMAKE_C_FLAGS == ""
CMAKE_C_FLAGS_DEBUG == "-g"
CMAKE_C_FLAGS_MINSIZEREL == "-Os -DNDEBUG"
CMAKE_C_FLAGS_RELEASE == "-O3 -DNDEBUG"
CMAKE_C_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG"

// build rules
CMAKE_CXX_CREATE_SHARED_LIBRARY == " 
   
  -o 
  "
CMAKE_CXX_CREATE_SHARED_MODULE == " 
   
  -o 
  "
CMAKE_C_CREATE_SHARED_LIBRARY == " 
   
  -o  
 "
CMAKE_C_CREATE_SHARED_MODULE == " 
   
  -o  
 "
CMAKE_CXX_CREATE_STATIC_LIBRARY == ""
CMAKE_C_CREATE_STATIC_LIBRARY == ""
CMAKE_CXX_COMPILE_OBJECT == " 
-o  -c "
CMAKE_C_COMPILE_OBJECT == "-o 
   -c "
CMAKE_C_LINK_EXECUTABLE == "   
   -o  "
CMAKE_CXX_LINK_EXECUTABLE == "   
-o  "

=
=== VARIABLES
=
CMAKE_AR "/usr/bin/ar"
CMAKE_AR "/usr/bin/ar"
CMAKE_BASE_NAME "g++"
CMAKE_BINARY_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation"
CMAKE_BUILD_TOOL "/usr/bin/gmake"
CMAKE_BUILD_TYPE ""
CMAKE_C11_COMPILE_FEATURES "c_std_11;c_static_assert"
CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu11"
CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c11"
CMAKE_C90_COMPILE_FEATURES "c_std_90;c_function_prototypes"
CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90"

Re: [CMake] Link to local glibc

[Chuck Atkins]

>
> I'll try and see if I can compile a gcc 4.9.3 chain on the CentOS 5
> machine (I need C++11).
>
I'd suggest using the devtollset repo from
https://people.centos.org/tru/devtools/devtools.repo


> The docker container looks interesting but I haven't used it yet: does it
> need some specific install on the target machine? I don't have any install
> rights on the Cento 5.11 machine
>

I think you misunderstand.  I meant to use a docker container on your
Ubuntu machine running CentOS 5 as a development environment.  That way you
can use your Ubuntu workstation to build in a CentOS 5 environment.

- Chuck
-- 

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] Link to local glibc

[Chuck Atkins]

If you're using a newer Ubuntu environment, I'd suggest using a CentOS 5
docker container.   Either that or the VM.

- Chuck

On Tue, Mar 7, 2017 at 1:53 PM, Marcel Loose  wrote:

> Hi Michele,
>
> This could become a painful exercise. You basically have two options:
> 1) Treat it as a cross-compilation project, or
> 2) Create a virtual machine running CentOS 5.8 and do the build there.
> If I were you, I would go for the second option.
>
> Cheers,
> Marcel.
>
> Op 07-03-17 om 17:56 schreef Michele Portolan:
> > Hello,
> >
> > I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my
> > program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried
> > compiling with "-static" to have static linking, but when I try to
> > execute I get "ERROR: Kernel too old!"
> >
> > I therefore locally compiled a glibc with support for kernel 2.6.18 ...
> > but how can I have Cmake use it instead of the system one?
> >
> > Thanks,
> >
> >
> > Michele
> >
>
>
>
> --
>
> 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
>
-- 

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-developers] error install FAST with cmake

[Chuck Atkins]

Hi Soumaia,

It looks like your issues are not related to CMake but to the FAST project
it'self.  I see you're already in contact with the user community on their
mailing lists,
https://lists.gforge.inria.fr/pipermail/nossi-tddft-users/2017-February/06.html.
Please continue to work through the issue with the FAST project's
developers there as these are not issues with CMake.

- Chuck

On Thu, Feb 23, 2017 at 4:11 PM, Soumaia Djaadi via cmake-developers <
cmake-developers@cmake.org> wrote:

> Hi all
> I want install FAST code with some software (siesta-4.0, cmake-3.7, intel
> fortran parallel studio 2017, gsl-2.2) but i have this problem when run
> make command :
> 
> ..
>   Scanning dependencies of target myfit
> [ 73%] Building CXX object src/CMakeFiles/myfit.dir/LorentzFit.cpp.o
> /home/ilaf/Desktop/FAST-1-1/src/LorentzFit.cpp(219): error: class
> "gsl_multifit_fdfsolver" has no member "J"
> gsl_multifit_covar (s->J, 0.0, covar);
>^
>
> compilation aborted for /home/ilaf/Desktop/FAST-1-1/src/LorentzFit.cpp
> (code 2)
> src/CMakeFiles/myfit.dir/build.make:62: recipe for target
> 'src/CMakeFiles/myfit.dir/LorentzFit.cpp.o' failed
> make[2]: *** [src/CMakeFiles/myfit.dir/LorentzFit.cpp.o] Error 2
> CMakeFiles/Makefile2:1053: recipe for target
> 'src/CMakeFiles/myfit.dir/all' failed
> make[1]: *** [src/CMakeFiles/myfit.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> ..
> how can solve this problem ?can any one help me ?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] how to use cmake3.7 for building fast code infedora 24

[Chuck Atkins]

Hi Soumaia,
Please keep conversations on the mailing list so others can benefit from it
as well.  Also, I've moved this over to the CMake Users list at
cmake@cmake.org as it's a more appropriate place for this than that
developers list.


can you help me please how can i do this setup ?
>

All you should need to do is source the setup script as I described here:

source /opt/intel/bin/compilervars.sh intel64
>

That should place the compilers in the search path for your current shell.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

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-developers] how to use cmake3.7 for building fast code in fedora 24

[Chuck Atkins]

Hi Soumaia,
The compilers are not yet in your search path so CMake can't find them.
You need to setup the intel compiler's environment first with: source
/opt/intel/bin/compilervars.sh intel64 , then CMake should be able to find
your compiler.



--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, Feb 16, 2017 at 5:42 AM, Soumaia Djaadi via cmake-developers <
cmake-developers@cmake.org> wrote:

> I want to install FAST (Fast Absorption Simulation by TDDFT) code but I
> faced some problems. I use for this  Cmake 3.7 and siesta-4.0, and the
> Intel 17.X compilers, my system is linux fedora 24. FAST code is freely
> available at https://gforge.inria.fr/frs/?group_id=1179
> This is the problem:
> [ilaf@localhost Desktop]tar xzf FAST−1−1.tar.gz
> [ilaf@localhostDesktop] cd FAST-1-1/
> [ilaf@localhost FAST-1-1]mkdir build
> [ilaf@localhostFAST−1−1]cd build/
> [ilaf@localhost build]$ CC=icc FC=ifort CXX=icpc cmake -
> DSIESTA_XC_DIR=/home/ilaf/Desktop/siesta-4.0/Obj/SiestaXC ../ CMake Error
> at /usr/local/share/cmake- 3.7/Modules/CMakeDetermineCCompiler.cmake:48
> (message): Could not find compiler set in environment variable CC:
> icc. Call Stack (most recent call first): CMakeLists.txt:47 (PROJECT)
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error:
> CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete,
> errors occurred! See also "/home/ilaf/Desktop/FAST-1-1/
> build/CMakeFiles/CMakeOutput.log". [ilaf@localhost build]$
> Can any one help me ?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

[Chuck Atkins]

Hi YC,


> cmake version on fedora 25: 3.6.2
>

Fedora is specifically patching CMake in the RPM spec file to reduce the
gcc flag from O3 to O2 so it's the distributuion's packaging making that
change, not CMake itself.  If you download and build the source from
cmake.org then you'll get O3 as default for gcc release builds.

That being said, I do think we should revisit the use of O3 by default
given the safety issues surounding it.

- Chuck
-- 

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] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

[Chuck Atkins]

Hi Adrian,

I'd suggest taking the issue up with the package maintainer.  The upstream
source for CMake 3.7.2 configures, builds, and passes all tests on EL7 so
the problem seems to lie in how the RPM SPEC file is driving the build.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.

On Thu, Feb 16, 2017 at 3:32 AM, Adrian Sevcenco <adrian.sevce...@cern.ch>
wrote:

> On 02/15/2017 09:04 PM, Chuck Atkins wrote:
>
>> Hi Adrian,
>>
> Hi! and thank you for looking into this problem!
>
>
> So, would this imply that cmake is not supported on EL7 because gcc
>> does not support cxx11 ?
>>
>>
>> That's not really what's happening.  CMake is testing the C compiler to
>> determine whether or not it supports C11 features and the C++ compiler
>> to see if it supports C++11.  The error messages are expected in many of
>> the test cases.  Here it's jsut checking to see if what it knows about
>> the features supported by the specific version of GCC line up correctly
>> with reality.  i.e. CMake thinks that gcc 4.8.2 supports certain
>> features so it tests them to make sure.  So it's not saying that CMake
>> isn't supported, just that the 1 specific test failed for some reason.
>>
>
>
>>
>>
>> So, does anyone have any idea what is the latest 3.x version that
>> can be built on centos 7?
>>
>>
>> All that being said, I wasn't able to reproduce the error with the
>> current 3.7.2 release:
>>
>> [chuck.atkins@deepthought v3.7.2]$ lsb_release -d
>> Description:CentOS Linux release 7.3.1611 (Core)
>> [chuck.atkins@deepthought v3.7.2]$ gcc --version
>> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>> ...
>> [chuck.atkins@deepthought v3.7.2]$ ../../source/v3.7.2/bootstrap
>> --parallel=28
>> ...
>> CMake has bootstrapped.  Now run gmake.
>> [chuck.atkins@deepthought v3.7.2]$ make -j28
>> ...
>> 100%] Built target ctest
>> [chuck.atkins@deepthought v3.7.2]$ ./bin/ctest -j 28
>> ...
>> 100% tests passed, 0 tests failed out of 431
>>
>> Label Time Summary:
>> Label1=   0.51 sec (1 test)
>> Label2=   0.51 sec (1 test)
>>
>> Total Test time (real) = 247.03 sec
>> [chuck.atkins@deepthought v3.7.2]$
>>
>> What specific versionof EL7 are you running and which version of GCC?
>>
> the standard ones :
> lsb_release -d
> Description:CentOS Linux release 7.3.1611 (Core)
>
> gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>
> i try to create cmake rpm based on the spec of
> cmake-3.6.2-6.fc25.src.rpm
> from which i removed most of the patches (i just want an rpm for centos 7)
> and used source of 3.7.2
>
> Thank you!!
> Adrian
>
>
>
>
>
>
>
-- 

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] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

[Chuck Atkins]

Hi Adrian,

So, would this imply that cmake is not supported on EL7 because gcc does
> not support cxx11 ?
>

That's not really what's happening.  CMake is testing the C compiler to
determine whether or not it supports C11 features and the C++ compiler to
see if it supports C++11.  The error messages are expected in many of the
test cases.  Here it's jsut checking to see if what it knows about the
features supported by the specific version of GCC line up correctly with
reality.  i.e. CMake thinks that gcc 4.8.2 supports certain features so it
tests them to make sure.  So it's not saying that CMake isn't supported,
just that the 1 specific test failed for some reason.



> So, does anyone have any idea what is the latest 3.x version that can be
> built on centos 7?
>

All that being said, I wasn't able to reproduce the error with the current
3.7.2 release:

[chuck.atkins@deepthought v3.7.2]$ lsb_release -d
Description:CentOS Linux release 7.3.1611 (Core)
[chuck.atkins@deepthought v3.7.2]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
...
[chuck.atkins@deepthought v3.7.2]$ ../../source/v3.7.2/bootstrap
--parallel=28
...
CMake has bootstrapped.  Now run gmake.
[chuck.atkins@deepthought v3.7.2]$ make -j28
...
100%] Built target ctest
[chuck.atkins@deepthought v3.7.2]$ ./bin/ctest -j 28
...
100% tests passed, 0 tests failed out of 431

Label Time Summary:
Label1=   0.51 sec (1 test)
Label2=   0.51 sec (1 test)

Total Test time (real) = 247.03 sec
[chuck.atkins@deepthought v3.7.2]$

What specific versionof EL7 are you running and which version of GCC?

------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

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] Forcing linking compatability to old libc / libstdc++ (Linux)

[Chuck Atkins]

FWIW, we've moved to CentOS 6 for the binaries we package and distribute
for ParaView.  It's about the oldest widely deployed Linux distro that's
still actively supported (EL5 is EOL'd and most deployments have long since
moved to 6 or 7).  it's binaries are compatible with virtually all current
Linux distros.  It also has newer compilers available (gcc 5.3 through the
devtoolset-4 package) that can build C++11 binaries compatible with the
older systems.

- Chuck

On Fri, Feb 3, 2017 at 3:46 PM, Alexander Neundorf 
wrote:

> On 2017 M02 2, Thu 20:07:29 CET you wrote:
> > Hi Gonzalo,
> >
> > Using the dockcross/manylinux-x64 docker image should allow to build you
> > project out-of-the-box.
> > It is based on Centos5, include recent gcc, CMake, Git, etc ...
> >
> > See https://github.com/dockcross/dockcross
> >
> > In a nutshell,
> >
> > # Pull image
> > docker pull dockcross/manylinux-x64
> >
> > # Generate helper script
> > docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> > chmod +x ./dockcross-manylinux-x64
> > mv ./dockcross-manylinux-x64 ~/bin/
> >
> > # Build your project
> > cd /path/to/src
> > dockcross cmake -Bbuild -H. -GNinja
> >
> >
> > The directory build will then contain the build tree of your project
> > compiled using gcc provided by the Centos5 image and link against an old
> > glibc.
>
> when docker starts, you are usually root in the container, and if then
> something is built, the files belong to root, and not the user as which
> you are
> logged in.
> How do you handle that ?
> I just found a hackish way (a shell script which sets up a user with the
> same
> numerical ID) to have the same user ID in the container as on the host
> system.
> Is there a better way ?
>
> Alex
>
> --
>
> 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
>
-- 

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] OBJECT libraries and INTERFACE_SOURCES

[Chuck Atkins]

Hi Giovanni,
Does it work if you add lib1 as a private dependency of lib2?  i.e.:
target_link_libraries(lib2 PRIVATE lib1)

Also, it shouldn't matter but what about in your original example if you
use the full path to the source file instead while still keeping the public
link dependency?  i.e.:
add_library(lib1-obj OBJECT $(CMAKE_CURRENT_SOURCE_DIR}/lib1.cpp).

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Fri, Dec 9, 2016 at 5:26 AM, Giovanni Funchal <g...@cloudnc.co.uk> wrote:

> Hi,
>
> Apologies, the problem wasn't properly minimised because I had some
> trouble wrapping my head around it. Here's two complete examples which I
> hope can explain the problem better this time.
>
> 1) This works:
>
> [CMakeLists.txt]
> cmake_minimum_required(VERSION 3.6)
> project(Test)
> add_library(lib1-obj OBJECT lib1.cpp)
> add_library(lib1 INTERFACE)
> set_target_properties(lib1 PROPERTIES INTERFACE_SOURCES
> $)
> add_library(lib2 lib2.cpp)
> target_link_libraries(lib2 lib1)
> add_executable(main main.cpp)
> target_link_libraries(main lib2)
>
> 2) But this does not:
>
> [CMakeLists.txt]
> cmake_minimum_required(VERSION 3.6)
> project(Test)
> add_library(lib1-obj OBJECT lib1.cpp)
> add_library(lib1 INTERFACE)
> set_target_properties(lib1 PROPERTIES INTERFACE_SOURCES
> $)
> add_library(lib2 lib2.cpp)
> target_link_libraries(lib2 lib1)
> add_subdirectory(main)
>
> [main/CMakeLists.txt]
> add_executable(main main.cpp)
> target_link_libraries(main lib2)
>
> With the second example, I get an error "cannot find source file
> lib1.cpp.o tried extensions...".
>
> Thanks,
> -- Giovanni
>
>
> On Thu, Dec 8, 2016 at 9:56 PM, Stephen Kelly <steve...@gmail.com> wrote:
>
>> Giovanni Funchal wrote:
>>
>> > Hi,
>> >
>> > The help page [1] mentions that:
>> >
>> >> Although object libraries may not be named directly in calls to the
>> >> target_link_libraries() command, they can be “linked” indirectly by
>> >> using an Interface Library whose INTERFACE_SOURCES target property
>> >> is set to name $.
>> >
>> > However, I was unable to get this to work. Doing this:
>> >
>> > add_library(lib-obj OBJECT test.cpp)
>> > add_library(lib INTERFACE)
>> > add_dependencies(lib lib-obj)
>> > set_target_properties(lib PROPERTIES INTERFACE_SOURCES
>> > $)
>> >
>> > And then trying to specify lib in link_libraries of an executable yields
>> > an error message "Cannot find source file: ... Tried extensions:... ".
>> >
>> > Am I doing something wrong?
>>
>> This works for me:
>>
>> cmake_minimum_required(VERSION 3.3)
>>
>> project(testit CXX)
>>
>> add_library(lib-obj OBJECT foo.cpp)
>> add_library(lib-iface INTERFACE)
>> set_target_properties(lib-iface PROPERTIES
>>   INTERFACE_SOURCES $
>> )
>> add_executable(main foo-user.cpp)
>> target_link_libraries(main lib-iface)
>>
>>
>> Thanks,
>>
>> Steve.
>>
>>
>> --
>>
>> 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
>
>
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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-developers] Building CMake system libraries

[Chuck Atkins]

Shouldn't we  be able to accomplish the same same thing with just the
CMAKE_USE_SYSTEM_FOO
variable as a cache entry?  I ran into this when trying to build CMake
master and I want to use all system libraries but librhash.  Given the
current implementation, there's a number of configurations that cause no
way to actually set this with the user-facing option.  Typically I'd do
-DCMAKE_USE_SYSTEM_LIBRARIES=ON -DCMAKE_USE_SYSTEM_LIBRHASH=OFF but the
user-facing option has no meaning because internally the
CMAKE_USE_SYSTEM_LIBRARY_RHASH
variable, initialized by
CMAKE_USE_SYSTEM_LIBRARIES force overrides anything I try to set for it.

--
Chuck Atkins


On Wed, Dec 7, 2016 at 10:33 AM, Brad King <brad.k...@kitware.com> wrote:

> On 12/07/2016 10:02 AM, Chuck Atkins wrote:
> > I'm trying to understand why there's both CMAKE_USE_SYSTEM_LIBRARY_FOO
> > and CMAKE_USE_SYSTEM_FOO when it seems that the user-facing option
> > CMAKE_USE_SYSTEM_FOO isn't usually settable.
>
> This is for interaction with the bootstrap script.  Options to that
> come in as cache entries that set the default for the user-facing
> options IIRC.
>
> -Brad
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Duplicating a shared library and replacing target link libraries

[Chuck Atkins]

>
> The library linking against "originalLibraryForward" has to be
> compiled from the original sources too. Actually performing the

linking step should be sufficient. Is there a way to accomplish that?
>

Object libraries are what you need here.  See
https://cmake.org/cmake/help/v3.7/manual/cmake-buildsystem.7.html#object-libraries
.  Essentially you'll do something like this:

add_library(fooObj OBJECT ${foo_Common_Sources})
add_library(foo $ ${foo_RealOnly_Sources})
add_library(fooMock $ ${foo_MockOnly_Sources})


The function does not work when the library passed to
> AddMockedLibrary() uses target_link_libraries() with IMPORTED targets
> from, e. g. calls to find_package(). In order to make creating the
> _MOCK-Library work I have to duplicate the original call to
> find_package() before calling AddMockedLibrary(). Is there a way to
> automate this as well?
>

You might be able to go down the route of creating an INTERFACE library
with all of the common properties necessary for both the actual and mock
libraries.  You could then add the interface lib as a public dependency
with target_link_libraries(foo PUBLIC fooInterface) and
target_link_libraries(fooMock PUBLIC fooInterface).  It's a bit convoluted
but I think it could work well here for you.

- Chuck
-- 

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

[Chuck Atkins]

> why does it not interrogate the MPI wrapper if set as FC or CC?
>

CC, CXX, and FC env vars are just used to initialize the
CMAKE_{C,CXX,Fortran}_COMPILER variables wihch CMake will then use as the
"regular" compilers for a given language.  If those regular compilers
already work with MPI then there's no need to retrieve the underlying
settings that it uses.



> Would there be any harm in attempting to pull out the
> {LIBRARIES,INCLUD_DIRS} etc.?
>

They should be empty.  People often think of the variables as "this is
where MPI things are" which is not really what they mean.  What they are
saying is "these are the extra things to add when useing MPI".  So if your
primary compiler is an MPI wrapper then there's no extra includes or
libraries to add.

- Chuck
-- 

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

[Chuck Atkins]

>
> As far as enhancements to FindMPI go, It might be worthwhile to check if
> FC, CC,CXX match any obvious MPI wrappers, and then set MPI__compiler
> and select the MPI version from there: If the user set the compiler
> explicitly to an MPI wrapper, that's likely the MPI they intend to use
> If I find some time maybe I'll work up a pull request for this.
>

It's actualy already there since this is the default and preferred behavior
in Cray systems.  As a fallback if MPI can't be found, then it tests the
regular compilers.  If successful,  it will not interrogate them and
MPI_FOUND wll be true but the MPI__{LIBRARIES,INCLUDE_DIRS} variables
will be empty.  Instead it will explicitly set
MPI__COMPILER_NO_INTERROGATE=/path/to/mpi{cc,c++,f90}.  Look around
line 600 (try_reguilar_compiler and interrogate_mpi_compiler)

I think the logic is a bit backwards on this and if you were to make a
change, I'd suggest it be there and re-order a few things such that if MPI
things haven't been already explicitly set then the *first* thing to do
(rather than last) is test the regular compilers, then if those don't work,
search for and interrogate the MPI wrappers.

- Chuck
-- 

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

[Chuck Atkins]

Hi Zaak,

Sorry for the first mail being so abrupt, I didn't mean to hit "send" so
soon.



> I took a look at the FindMPI CMake module, and it seems as though you can
> set MPI_HOME to a list of directories to search.
>

That's also another way of doing it, which would probably be easier than
what I iniitially suggested; the former has just become my own habbit since
MPI_HOME isn't always set.  MPI_HOME is used as a hint to search for
mpiexec.  If mpiexec is found, it then uses it's location as a basis for
locating the compiler wrappers.

That being said, if using MPI through an environment module (as is the
typical use case) then FindMPI should "just work" as the wrappers generally
end up in the path when the appropriate MPI module is loaded.  If you need
to point to an entirely external MPI not part of your environment at all
though, then using the MPI_HOME env var or MPI__COMPILER CMake vars
is the way to do it.



> Would KitWare accept a pull request or a patch that expands the
> documentation of FindMPI
>

Of course :-).  Expanding the "Usage" section in FindMPI to include using
the MPI_HOME environment variable would be a good place for that.



> and/or adds some clearer additional features to the call signature (like
> HINTS and PATHS)?
>

Could you clarify what you mean by this?  To which call signature?


- Chuck
-- 

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

[Chuck Atkins]

Hi Zaak,

When using CMake, it's generally best to use the actual compiler rather
than any compiler wrappers (with Cray being the exception).  Given that,
set the CC, CXX, and FC environment variables to the actual compilers you
want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables the
MPI wrappers.  FindMPI will then interrogate the MPI wrappers to extract
the appropriate include and link options.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:

> Pass the following CMake options at configure time:
>
> -DMPI_C_COMPILER=/path/to/mpicc
> -DMPI_CXX_COMPILER=/path/to/mpiCC
> -DMPI_Fortran_COMPILER=/path/to/mpif90
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman <zbeek...@gmail.com> wrote:
>
>> Hi,
>>
>> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
>> etc. OR also be able to pass a compiler and use FindMPI to add link,
>> compile and include flags. I'm encountering an issue when my MPI
>> implementation is not on my PATH, I want CMake to be able to look in an
>> additional location (our build script can download and build MPICH and by
>> default installs it in user space) and also resolve where mpif90 is coming
>> from and look there too.
>>
>> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
>> specify additional locations to search?
>>
>> Using `find_package` with HINTS and PATHS means that it doesn't use
>> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
>> a cache variable set early, so it's not having an effect.
>>
>> It would be great if FindMPI used the realpath of mpif90 etc when passed
>> as $FC.
>>
>> TIA
>>
>> --
>>
>> 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
>>
>
>
-- 

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

[Chuck Atkins]

Pass the following CMake options at configure time:

-DMPI_C_COMPILER=/path/to/mpicc
-DMPI_CXX_COMPILER=/path/to/mpiCC
-DMPI_Fortran_COMPILER=/path/to/mpif90

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman <zbeek...@gmail.com> wrote:

> Hi,
>
> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
> etc. OR also be able to pass a compiler and use FindMPI to add link,
> compile and include flags. I'm encountering an issue when my MPI
> implementation is not on my PATH, I want CMake to be able to look in an
> additional location (our build script can download and build MPICH and by
> default installs it in user space) and also resolve where mpif90 is coming
> from and look there too.
>
> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
> specify additional locations to search?
>
> Using `find_package` with HINTS and PATHS means that it doesn't use
> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
> a cache variable set early, so it's not having an effect.
>
> It would be great if FindMPI used the realpath of mpif90 etc when passed
> as $FC.
>
> TIA
>
> --
>
> 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
>
-- 

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] Building CMake without Curl

[Chuck Atkins]

It looks like you're using an existing configuration already set to use
system installed libraries.  Try from a clean source tree and an
out-of-source (the recommend way to do all cmake things) build directory.
Using the 3.6.2 tarball, I get:

$ tar -xvf cmake-3.6.2.tar.gz
... lots of tar output ...
$ mkdir cmake-3.6.2-build
$ cd cmake-3.6.2-build
$ ../cmake-3.6.2/bootstrap --prefix=../cmake-3.6.2-install
-
CMake 3.6.2, Copyright 2000-2016 Kitware, Inc.
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: gmake
g++ is GNU compiler
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
-
... lots of compile output ...
loading initial cache file /home/khq.kitware.com/chuck.
atkins/Code/CMake/source/cmake-3.6.2-build/Bootstrap.
cmk/InitialCacheFlags.cmake
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
... lots of cmake output ...
-
CMake has bootstrapped.  Now run gmake.
$


At this point, if you run "make help" then you'll get a list of available
targets.  In there, amongst others, you will see cmzlib, cmcurl, cmbzip2,
cmliblzma, cmlibarchive, cmexpat, and cmjsoncpp.  These are CMake's
internal copies of the dependencies.  When bootstrap is run with
--system-libs then system versions of those dependencies will be used
instead and the previously mentioned cm targets will not exist in
the make help output.



------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, Nov 3, 2016 at 10:47 AM, Jayesh Badwaik <pub...@jayeshbadwaik.in>
wrote:

> > CMake includes internal versions of all the dependencies it needs to
> > build.  You have the option of using an external system-supplied version
> > but it's certainly not required.  Without OpenSSL you'll just have a
> cmake
> > that can't use https, certainly not the end of the world.  The default
> > configuration of the ./bootstrap command should be using internal
> versions
> > of all of CMake's dependencies.  Is that causing problems for you?
>
> Yes. The bootstrap command runs successfully, but after that it advises me
> to
> run gmake, which fails. I've attached the errors of the bootstrap command
> and
> the gmake command in this mail.
>
> --
> Cheers
> Jayesh Badwaik
> https://www.jayeshbadwaik.in
>
-- 

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] Building CMake without Curl

[Chuck Atkins]

Hi Jayesh,

CMake includes internal versions of all the dependencies it needs to
build.  You have the option of using an external system-supplied version
but it's certainly not required.  Without OpenSSL you'll just have a cmake
that can't use https, certainly not the end of the world.  The default
configuration of the ./bootstrap command should be using internal versions
of all of CMake's dependencies.  Is that causing problems for you?


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Wed, Nov 2, 2016 at 1:08 PM, Jayesh Badwaik <pub...@jayeshbadwaik.in>
wrote:

> Hi,
>
> Is there a way to build CMake without curl? I am currently in an
> environment
> where I have no openssl-dev packages nor libcurl-dev packages. So, if I
> want
> to build CMake, I will need to build openssl-dev myself which I do not
> want to
> do.
>
> I can ask my sysadmin for the packages, but I was wondering if there is
> another method. A follow up question would be, if this is not possible,
> why is
> libcurl essential to Cmake?
>
>
> --
> Cheers
> Jayesh Badwaik
> https://www.jayeshbadwaik.in
> --
>
> 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
>
-- 

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] [SOLVED] RE: Crosscompilation woes

[Chuck Atkins]

In VTK and ParaView we use a manual two-step build.  The first pass
configures a host build of the cross-compile utilities and the second pass
configures a target build with a toolchain file, which requires you tell it
where the host tools are.  So the build process looks like this:

mkdir build_host
cd build_host
cmake -DBUILD_CROSSTOOLS=ON /path/to/source
make
cd ..
mkdir build_target
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/tolchain.cmake
-DFOO_CROSSTOOLS_DIR=/path/to/build_host
make

You should be able to adapt this to a superbuild scenario with two external
projects and it seems like that's exactly what you've done.  Just
confirming that yes that's a sane approach and that's how we do it to.


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Mon, Oct 10, 2016 at 9:56 AM, Robert Bielik <robert.bie...@dirac.com>
wrote:

> For reference: I went with Brads suggestion: https://gitlab.kitware.com/
> cmake/cmake/issues/16356
>
>
>
> which seems to be working fine.
>
>
>
> Regards
>
> /R
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Robert
> Bielik
> *Sent:* den 10 oktober 2016 14:00
> *To:* Craig Scott <craig.sc...@crascit.com>
>
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> I am using a toolchain file! The CC and CXX environment variables are set
> by CMake (I assume, because I haven’t touched them).
>
>
>
> I’ll disect the link to see what I’ve missed.
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.sc...@crascit.com
> <craig.sc...@crascit.com>]
> *Sent:* den 10 oktober 2016 13:56
> *To:* Robert Bielik <robert.bie...@dirac.com>
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Don't use environment variables to set the ARM compilers in your
> situation, use a toolchain file to specify them instead. Your CMake
> experience will generally be smoother if you specify cross-compile details
> via toolchain files. If you are following the method in the stackoverflow
> link I mentioned last time, the host part of the build will then pick up
> the host compilers and the ARM part of the build will use the compilers
> from the toolchain file.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <robert.bie...@dirac.com>
> wrote:
>
> I’m trying to do this, but since I setup a cross compiling env. by setting
> C++ compiler, these settings get used when I run execute_process to setup
> the host build !! Thus I get the ARM version of the build tools anyway! :(
>
>
>
> It seems that when execute_process is executed, the CC and CXX environment
> variables are set, which makes cmake use those when generating the
> makefiles.
>
>
>
> Ideas are most welcome!
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.sc...@crascit.com]
> *Sent:* den 10 oktober 2016 10:47
> *To:* Robert Bielik <robert.bie...@dirac.com>
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Here's one possible solution (not perfect, but has been working in
> production for us for a while now for a similar scenario to what you
> describe):
>
>
>
> http://stackoverflow.com/q/36084785/1938798
>
>
>
> An alternative is a superbuild arrangement which would require a top level
> project to drive two sub-builds brought in via ExternalProject
> <https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one
> for the host and the other for arm. This is both better and worse,
> depending on your point of view, so you may need to do some
> research/experimenting to see which is a better fit for your situation.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <robert.bie...@dirac.com>
> wrote:
>
> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> 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.or

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-158-gf90c7ba

[Chuck Atkins]

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, next has been updated
   via  f90c7ba54f1a9a61e930292207d3387df40b2dad (commit)
   via  495f92446a6e663be39a742721bb18e7fb1d9c14 (commit)
   via  d1c1db6360cacdcce9fc48c51fb7809f2711e62b (commit)
  from  c8a45332313cac5acc6661f8bcf4993d1fb81b49 (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=f90c7ba54f1a9a61e930292207d3387df40b2dad
commit f90c7ba54f1a9a61e930292207d3387df40b2dad
Merge: c8a4533 495f924
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Oct 6 15:45:56 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 15:45:56 2016 -0400

Merge topic 'check-libuv-minimum-version' into next

495f9244 Set minimum version for LibUV to 1.0.0
d1c1db63 Use find_package for JsonCpp and LibUV instead of include


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=495f92446a6e663be39a742721bb18e7fb1d9c14
commit 495f92446a6e663be39a742721bb18e7fb1d9c14
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Wed Oct 5 10:20:28 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Wed Oct 5 10:20:28 2016 -0400

Set minimum version for LibUV to 1.0.0

Older versions of libuv did not have the uv_loop_close API.  It first
showed up in unstable releases ~ v0.11.20 but was not available in
a stable release until v1.0

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bafca23..b4a577c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -491,7 +491,7 @@ int main(void) { return 0; }
   if(CMAKE_USE_LIBUV)
 if(CMAKE_USE_SYSTEM_LIBUV)
   if(NOT CMAKE_VERSION VERSION_LESS 3.0)
-find_package(LibUV)
+find_package(LibUV 1.0.0)
   else()
 message(FATAL_ERROR "CMAKE_USE_SYSTEM_LIBUV requires CMake >= 3.0")
   endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1c1db6360cacdcce9fc48c51fb7809f2711e62b
commit d1c1db6360cacdcce9fc48c51fb7809f2711e62b
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Wed Oct 5 10:19:55 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Wed Oct 5 10:19:55 2016 -0400

Use find_package for JsonCpp and LibUV instead of include

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 309e224..bafca23 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -10,6 +10,10 @@ if(POLICY CMP0053)
 endif()
 project(CMake)
 
+# Make sure we can find internal find_package modules only used for
+# building CMake and not for shipping externally
+list(INSERT CMAKE_MODULE_PATH 0 ${CMake_SOURCE_DIR}/Source/Modules)
+
 if(CMAKE_BOOTSTRAP)
   # Running from bootstrap script.  Set local variable and remove from cache.
   set(CMAKE_BOOTSTRAP 1)
@@ -441,7 +445,7 @@ macro (CMAKE_BUILD_UTILITIES)
   # Build jsoncpp library.
   if(CMAKE_USE_SYSTEM_JSONCPP)
 if(NOT CMAKE_VERSION VERSION_LESS 3.0)
-  include(${CMake_SOURCE_DIR}/Source/Modules/FindJsonCpp.cmake)
+  find_package(JsonCpp)
 else()
   message(FATAL_ERROR "CMAKE_USE_SYSTEM_JSONCPP requires CMake >= 3.0")
 endif()
@@ -487,7 +491,7 @@ int main(void) { return 0; }
   if(CMAKE_USE_LIBUV)
 if(CMAKE_USE_SYSTEM_LIBUV)
   if(NOT CMAKE_VERSION VERSION_LESS 3.0)
-include(${CMake_SOURCE_DIR}/Source/Modules/FindLibUV.cmake)
+find_package(LibUV)
   else()
 message(FATAL_ERROR "CMAKE_USE_SYSTEM_LIBUV requires CMake >= 3.0")
   endif()

---

Summary of changes:
 CMakeLists.txt |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Correct way to use ARMCC (Files in Modules/Compiler/ARMCC*)

[Chuck Atkins]

>
> 1. Toolchain needs to be in a separate file
>

Yes, that is certainly best practice and makes the rest of the
cross-compiling infrastructure just work better.



> 2.  That file needs to be called before the project line of your
> CMakeLists.txt
>

You actually shouldn't be "calling" it at all.  You specify it with cmake
-DCMAKE_TOOLCHAIN_FILE=/path/to/MyARMStuff.cmake ...[other cmake options]
/path/to/source.  CMake then explicitly processes the toolchain file in a
few different places but handles when to do this internally.  Basically you
write your CMakeLists.txt without worrying much about cross-compiling and
you specify the toolcain file to let CMake deal with the cross-compile
aspect.
-- 

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-developers] Security in CMake

[Chuck Atkins]

Hi Egor,
Is this intended to run on Linux?  If so, I think you're FAR better off
leveraging an existing security framework like SELinux, since it's actually
designed from the ground up to enforce these types of controls.  You could
define a label that you place on the executables run by the package manager
and then enforce whatever restrictions and controls you feel are
appropriate. This will let you do things like block network access got the
specific CMake executable used by the package system.  It allows the CMake
scripts to leverage all the available language and command features but
deny, ant a system level, actions you deem unsafe or harmful.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
<%28518%29%20881-1183>

On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin <egor.pu...@gmail.com> wrote:

> > What is the attack you want to stop? What are bad scripts and commands
> in this context?
>
> I wrote them in the first message. For example,
> - any cmake commands that use COMMAND keyword (execute_process(COMMAND
> ...), add_custom_{command|target}(...) etc. This will deny any user
> scripts, programs (wget, curl, rm, ...).
> - download commands (CMake's builtin curl) - they can fill the drives
> with trash.
>
> > CMake runs lots of commands all the time. Most can be changed by a user,
> many are changed by the generator based on environment and whatnot. Any of
> these may be bad commands -- based on configuration.
>
> Yes, and it should deny only stuff above in small CMakeLists.txt part
> that will be protected with some other commands or policies.
>
> > But if CMake gets a secure mode for your generator and if that is merged
> upstream, then I need to know about that when reading or writing
> CMakeLists.txt.
>
> For the moment I'm just asking about possibility of implementation of
> these features. Any decision will go from CMake guys, not from me. So,
> you shouldn't ask me about it. :)
>
> > Generated code is safe only as long as you very tightly control the
> environment CMake runs in.
>
> I don't care what is around, what is in user env. This is his
> responsibility. I'm just worrying for my parts of CMake stuff.
>
> On 21 August 2016 at 20:43, Tobias Hunger <tobias.hun...@gmail.com> wrote:
> > Hi Egor,
> >
> > Am 21.08.2016 12:34 schrieb "Egor Pugin" <egor.pu...@gmail.com>:
> >>
> >> > What are the attack scenarios you want to defend against? What should
> >> > not be possible in your system that currently is in CMake?
> >>
> >> At least downloading or executing bad scripts and commands.
> >
> > What is the attack you want to stop? What are bad scripts and commands in
> > this context?
> >
> > CMake runs lots of commands all the time. Most can be changed by a user,
> > many are changed by the generator based on environment and whatnot. Any
> of
> > these may be bad commands -- based on configuration.
> >
> > Downloading can be done using internal commands or by running e.g. wget
> or
> > curl, both of which are pretty widely available on developer machines.
> >
> >> > That forces me to keep more state in my head when reading
> CMakeLists.txt
> >> > files.
> >>
> >> CMake files are generated in my system. That's what I mean when I said
> >> 'based on CMake'.
> >
> > Sure. But if CMake gets a secure mode for your generator and if that is
> > merged upstream, then I need to know about that when reading or writing
> > CMakeLists.txt.
> >
> >> It's like compiler compiler like yacc, bison, lex, flex. They are
> >> producing output not for human readers, but for computer parsers.
> >> And that's why generated code is safe and insertions from users are not.
> >
> > Generated code is safe only as long as you very tightly control the
> > environment CMake runs in.
> >
> >> Also in the most cases there's no any insertions at all, so it's rare
> >> case.
> >
> > I'm sure you know what you are doing:)
> >
> > Best regards,
> > Tobias
>
>
>
> --
> Egor Pugin
> --
>
> 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

Re: [CMake] latest cmake 3.6.1 building in AIX can not find symbol `.w32attrset`

[Chuck Atkins]

Hi Zeson,
We do have a nightly build on AIX with both GCC and IBM XL.  It does build
correctly using curses instead ncurses, as you mention, but the machine we
use doesn't have ncurses on it, only curses, so it doesn't have this
problem of accidentally finding the wrong curses library. When configuring
your build, try adding -DCURSES_NCURSES_LIBRARY=IGNORE to prevent
FindCurses from picking the wrong one.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.

On Fri, Aug 19, 2016 at 5:14 AM, Zeson Wu <westion...@gmail.com> wrote:

> /usr/bin/g++-Wl,-bnoipath -Wl,-brtl CMakeFiles/ccmake.dir/CursesDi
>> alog/cmCursesOptionsWidget.cxx.o 
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesBoolWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesCacheEntryComposite.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesDummyWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesFilePathWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesForm.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesLabelWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesLongMessageForm.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesMainForm.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesPathWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesStringWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o  -o ../bin/ccmake
>> -Wl,-bexpall libCMakeLib.a CursesDialog/form/libcmForm.a kwsys/libcmsys.a
>> ../Utilities/cmexpat/libcmexpat.a 
>> ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a
>> ../Utilities/cmliblzma/libcmliblzma.a ../Utilities/cmbzip2/libcmbzip2.a
>> ../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/lib/libcmcurl.a
>> ../Utilities/cmzlib/libcmzlib.a -lld ../Utilities/cmjsoncpp/libcmjsoncpp.a
>> */usr/lib/libncurses.a* /opt/freeware/lib/gcc/powerpc-
>> ibm-aix7.1.0.0/4.9.2/libgcc_eh.a /opt/freeware/lib/gcc/powerpc-
>> ibm-aix7.1.0.0/4.9.2/libgcc_eh.a -Wl,-blibpath:/opt/freeware/li
>> b/gcc/powerpc-ibm-aix7.1.0.0/4.9.2:/opt/freeware/lib:/usr/lib:/lib
>> ld: 0711-317 ERROR: Undefined symbol: .w32attrset
>> ld: 0711-317 ERROR: Undefined symbol: .w32insch
>> ld: 0711-317 ERROR: Undefined symbol: .w32addch
>> ld: 0711-317 ERROR: Undefined symbol: .w32attron
>> ld: 0711-317 ERROR: Undefined symbol: .w32attroff
>> ld: 0711-317 ERROR: Undefined symbol: .initscr32
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
>> information.
>> collect2: error: ld returned 8 exit status
>>
>>
> In AIX, it links with */usr/lib/libncurses.a* library which does not have
> such symbol. It should be */usr/lib/libcurses.a*. In AIX, it uses 
> */usr/include/curses.h
> *and can not find ncurses.h in /usr/include. It must be something wrong
> with* Modules/FindCurses.cmake*.
>
> --
> Zeson
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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-commits] CMake branch, next, updated. v3.6.1-1176-gc9477b6

[Chuck Atkins]

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, next has been updated
   via  c9477b66889974bf27c435ef951435a557bfd1b7 (commit)
   via  55e72872796d6649b17edf4dbca2d2641274c5c4 (commit)
  from  d8a2506da003e45b84c1f8e09960b60037be7434 (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=c9477b66889974bf27c435ef951435a557bfd1b7
commit c9477b66889974bf27c435ef951435a557bfd1b7
Merge: d8a2506 55e7287
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 9 08:01:14 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Aug 9 08:01:14 2016 -0400

Merge topic 'add-extra-boolean-comparisons' into next

55e72872 Add additional <= and >= comparison operators


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=55e72872796d6649b17edf4dbca2d2641274c5c4
commit 55e72872796d6649b17edf4dbca2d2641274c5c4
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 14:11:46 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Tue Aug 9 08:00:25 2016 -0400

Add additional <= and >= comparison operators

This adds the LESS_EQUAL, GREATER_EQUAL, and associated STR and VERSION
equivalents to use the combined <= and >= functionality.

diff --git a/Help/command/if.rst b/Help/command/if.rst
index 56e618c..0941029 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -30,10 +30,12 @@ else and endif clause is optional.  Long expressions can be 
used and
 there is a traditional order of precedence.  Parenthetical expressions
 are evaluated first followed by unary tests such as ``EXISTS``,
 ``COMMAND``, and ``DEFINED``.  Then any binary tests such as
-``EQUAL``, ``LESS``, ``GREATER``, ``STRLESS``, ``STRGREATER``,
-``STREQUAL``, and ``MATCHES`` will be evaluated.  Then boolean ``NOT``
-operators and finally boolean ``AND`` and then ``OR`` operators will
-be evaluated.
+``EQUAL``, ``LESS``, ``LESS_EQUAL, ``GREATER``, ``GREATER_EQUAL``,
+``STREQUAL``, ``STRLESS``, ``STRLESS_EQUAL``, ``STRGREATER``,
+``STRGREATER_EQUAL``, ``VERSION_EQUAL``, ``VERSION_LESS``,
+``VERSION_LESS_EQUAL``, ``VERSION_GREATER``, ``VERSION_GREATER_EQUAL``,
+and ``MATCHES`` will be evaluated.  Then boolean ``NOT`` operators and
+finally boolean ``AND`` and then ``OR`` operators will be evaluated.
 
 Possible expressions are:
 
@@ -115,6 +117,14 @@ Possible expressions are:
  True if the given string or variable's value is a valid number and equal
  to that on the right.
 
+``if(<variable|string> LESS_EQUAL <variable|string>)``
+ True if the given string or variable's value is a valid number and less
+ than or equal to that on the right.
+
+``if(<variable|string> GREATER_EQUAL <variable|string>)``
+ True if the given string or variable's value is a valid number and greater
+ than or equal to that on the right.
+
 ``if(<variable|string> STRLESS <variable|string>)``
  True if the given string or variable's value is lexicographically less
  than the string or variable on the right.
@@ -127,15 +137,31 @@ Possible expressions are:
  True if the given string or variable's value is lexicographically equal
  to the string or variable on the right.
 
+``if(<variable|string> STRLESS_EQUAL <variable|string>)``
+ True if the given string or variable's value is lexicographically less
+ than or equal to the string or variable on the right.
+
+``if(<variable|string> STRGREATER_EQUAL <variable|string>)``
+ True if the given string or variable's value is lexicographically greater
+ than or equal to the string or variable on the right.
+
 ``if(<variable|string> VERSION_LESS <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``).
 
+``if(<variable|string> VERSION_GREATER <variable|string>)``
+ Component-wise integer version number comparison (version format is
+ ``major[.minor[.patch[.tweak]]]``).
+
 ``if(<variable|string> VERSION_EQUAL <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``).
 
-``if(<variable|string> VERSION_GREATER <variable|string>)``
+``if(<variable|string> VERSION_LESS_EQUAL <variable|string>)``
+ Component-wise integer version number comparison (version format is
+ ``major[.minor[.patch[.tweak]]]``).
+
+``if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.

[Cmake-commits] CMake branch, next, updated. v3.6.1-1174-gd8a2506

[Chuck Atkins]

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, next has been updated
   via  d8a2506da003e45b84c1f8e09960b60037be7434 (commit)
   via  970eaed46afef12f003b51bdb51f5abf62214b19 (commit)
  from  d20a9735cddbdceda3ee3122711feaab7cb74818 (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=d8a2506da003e45b84c1f8e09960b60037be7434
commit d8a2506da003e45b84c1f8e09960b60037be7434
Merge: d20a973 970eaed
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 9 08:00:11 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Aug 9 08:00:11 2016 -0400

Merge topic 'add-extra-boolean-comparisons' into next

970eaed4 Fix documentation warning


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=970eaed46afef12f003b51bdb51f5abf62214b19
commit 970eaed46afef12f003b51bdb51f5abf62214b19
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 9 07:59:28 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Tue Aug 9 07:59:28 2016 -0400

Fix documentation warning

diff --git a/Help/release/dev/add-extra-boolean-comparisons.rst 
b/Help/release/dev/add-extra-boolean-comparisons.rst
index 6a1db01..a69b212 100644
--- a/Help/release/dev/add-extra-boolean-comparisons.rst
+++ b/Help/release/dev/add-extra-boolean-comparisons.rst
@@ -1,5 +1,5 @@
 add-extra-boolean-comparisons
 -
 
-* Add LESS_EQUAL, GREATER_EQUAL, and thier associated STR and VERSION_
+* Add LESS_EQUAL, GREATER_EQUAL, and thier associated STR and VERSION
   equivalents to use the combined <= and >= functionality.

---

Summary of changes:
 Help/release/dev/add-extra-boolean-comparisons.rst |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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1159-ge52f140

[Chuck Atkins]

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, next has been updated
   via  e52f1401237c7aa646ca6ecbe7f1eb78b018607f (commit)
   via  37507ffb11c441380ce6d6635b3992e09937f090 (commit)
  from  20b89cd9be9f35c547e4cebc1fbbda251cad954b (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=e52f1401237c7aa646ca6ecbe7f1eb78b018607f
commit e52f1401237c7aa646ca6ecbe7f1eb78b018607f
Merge: 20b89cd 37507ff
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 11:03:11 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Aug 8 11:03:11 2016 -0400

Merge topic 'add-extra-boolean-comparisons' into next

37507ffb Add additional <= and >= comparison operators


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=37507ffb11c441380ce6d6635b3992e09937f090
commit 37507ffb11c441380ce6d6635b3992e09937f090
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 14:11:46 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Mon Aug 8 11:02:27 2016 -0400

Add additional <= and >= comparison operators

This adds the LESS_EQUAL, GREATER_EQUAL, and associated STR and VERSION_
equivalents to use the combined <= and >= functionality.

diff --git a/Help/command/if.rst b/Help/command/if.rst
index 56e618c..0941029 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -30,10 +30,12 @@ else and endif clause is optional.  Long expressions can be 
used and
 there is a traditional order of precedence.  Parenthetical expressions
 are evaluated first followed by unary tests such as ``EXISTS``,
 ``COMMAND``, and ``DEFINED``.  Then any binary tests such as
-``EQUAL``, ``LESS``, ``GREATER``, ``STRLESS``, ``STRGREATER``,
-``STREQUAL``, and ``MATCHES`` will be evaluated.  Then boolean ``NOT``
-operators and finally boolean ``AND`` and then ``OR`` operators will
-be evaluated.
+``EQUAL``, ``LESS``, ``LESS_EQUAL, ``GREATER``, ``GREATER_EQUAL``,
+``STREQUAL``, ``STRLESS``, ``STRLESS_EQUAL``, ``STRGREATER``,
+``STRGREATER_EQUAL``, ``VERSION_EQUAL``, ``VERSION_LESS``,
+``VERSION_LESS_EQUAL``, ``VERSION_GREATER``, ``VERSION_GREATER_EQUAL``,
+and ``MATCHES`` will be evaluated.  Then boolean ``NOT`` operators and
+finally boolean ``AND`` and then ``OR`` operators will be evaluated.
 
 Possible expressions are:
 
@@ -115,6 +117,14 @@ Possible expressions are:
  True if the given string or variable's value is a valid number and equal
  to that on the right.
 
+``if(<variable|string> LESS_EQUAL <variable|string>)``
+ True if the given string or variable's value is a valid number and less
+ than or equal to that on the right.
+
+``if(<variable|string> GREATER_EQUAL <variable|string>)``
+ True if the given string or variable's value is a valid number and greater
+ than or equal to that on the right.
+
 ``if(<variable|string> STRLESS <variable|string>)``
  True if the given string or variable's value is lexicographically less
  than the string or variable on the right.
@@ -127,15 +137,31 @@ Possible expressions are:
  True if the given string or variable's value is lexicographically equal
  to the string or variable on the right.
 
+``if(<variable|string> STRLESS_EQUAL <variable|string>)``
+ True if the given string or variable's value is lexicographically less
+ than or equal to the string or variable on the right.
+
+``if(<variable|string> STRGREATER_EQUAL <variable|string>)``
+ True if the given string or variable's value is lexicographically greater
+ than or equal to the string or variable on the right.
+
 ``if(<variable|string> VERSION_LESS <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``).
 
+``if(<variable|string> VERSION_GREATER <variable|string>)``
+ Component-wise integer version number comparison (version format is
+ ``major[.minor[.patch[.tweak]]]``).
+
 ``if(<variable|string> VERSION_EQUAL <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``).
 
-``if(<variable|string> VERSION_GREATER <variable|string>)``
+``if(<variable|string> VERSION_LESS_EQUAL <variable|string>)``
+ Component-wise integer version number comparison (version format is
+ ``major[.minor[.patch[.tweak]]]``).
+
+``if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``maj

[Cmake-commits] CMake branch, next, updated. v3.6.1-1157-g20b89cd

[Chuck Atkins]

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, next has been updated
   via  20b89cd9be9f35c547e4cebc1fbbda251cad954b (commit)
   via  dd46b956f2feabbf8041dd8cedf086dca5b54622 (commit)
  from  717ece197f2931fe9d633b0fe1074aa3416eed0c (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=20b89cd9be9f35c547e4cebc1fbbda251cad954b
commit 20b89cd9be9f35c547e4cebc1fbbda251cad954b
Merge: 717ece1 dd46b95
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 11:02:14 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Aug 8 11:02:14 2016 -0400

Merge topic 'add-extra-boolean-comparisons' into next

dd46b956 Fix Sphinx warnings


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd46b956f2feabbf8041dd8cedf086dca5b54622
commit dd46b956f2feabbf8041dd8cedf086dca5b54622
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 11:01:20 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Mon Aug 8 11:01:20 2016 -0400

Fix Sphinx warnings

diff --git a/Help/release/dev/add-extra-boolean-comparisons.rst 
b/Help/release/dev/add-extra-boolean-comparisons.rst
index d47f0af..6a1db01 100644
--- a/Help/release/dev/add-extra-boolean-comparisons.rst
+++ b/Help/release/dev/add-extra-boolean-comparisons.rst
@@ -1,5 +1,5 @@
 add-extra-boolean-comparisons
---
+-
 
 * Add LESS_EQUAL, GREATER_EQUAL, and thier associated STR and VERSION_
   equivalents to use the combined <= and >= functionality.

---

Summary of changes:
 Help/release/dev/add-extra-boolean-comparisons.rst |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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1155-g717ece1

[Chuck Atkins]

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, next has been updated
   via  717ece197f2931fe9d633b0fe1074aa3416eed0c (commit)
   via  8872cd142ba7ad8e3eb36f06e92bda35475a9e90 (commit)
  from  4a5e3beb82eca0e2a1358c3eddfe41939ebdcdb8 (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=717ece197f2931fe9d633b0fe1074aa3416eed0c
commit 717ece197f2931fe9d633b0fe1074aa3416eed0c
Merge: 4a5e3be 8872cd1
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 10:48:00 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Aug 8 10:48:00 2016 -0400

Merge topic 'add-extra-boolean-comparisons' into next

8872cd14 Add additional <= and >= comparison operators


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8872cd142ba7ad8e3eb36f06e92bda35475a9e90
commit 8872cd142ba7ad8e3eb36f06e92bda35475a9e90
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 14:11:46 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Fri Aug 5 16:05:20 2016 -0400

Add additional <= and >= comparison operators

This adds the LESS_EQUAL, GREATER_EQUAL, and associated STR and VERSION_
equivalents to use the combined <= and >= functionality.

diff --git a/Help/command/if.rst b/Help/command/if.rst
index 56e618c..0941029 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -30,10 +30,12 @@ else and endif clause is optional.  Long expressions can be 
used and
 there is a traditional order of precedence.  Parenthetical expressions
 are evaluated first followed by unary tests such as ``EXISTS``,
 ``COMMAND``, and ``DEFINED``.  Then any binary tests such as
-``EQUAL``, ``LESS``, ``GREATER``, ``STRLESS``, ``STRGREATER``,
-``STREQUAL``, and ``MATCHES`` will be evaluated.  Then boolean ``NOT``
-operators and finally boolean ``AND`` and then ``OR`` operators will
-be evaluated.
+``EQUAL``, ``LESS``, ``LESS_EQUAL, ``GREATER``, ``GREATER_EQUAL``,
+``STREQUAL``, ``STRLESS``, ``STRLESS_EQUAL``, ``STRGREATER``,
+``STRGREATER_EQUAL``, ``VERSION_EQUAL``, ``VERSION_LESS``,
+``VERSION_LESS_EQUAL``, ``VERSION_GREATER``, ``VERSION_GREATER_EQUAL``,
+and ``MATCHES`` will be evaluated.  Then boolean ``NOT`` operators and
+finally boolean ``AND`` and then ``OR`` operators will be evaluated.
 
 Possible expressions are:
 
@@ -115,6 +117,14 @@ Possible expressions are:
  True if the given string or variable's value is a valid number and equal
  to that on the right.
 
+``if(<variable|string> LESS_EQUAL <variable|string>)``
+ True if the given string or variable's value is a valid number and less
+ than or equal to that on the right.
+
+``if(<variable|string> GREATER_EQUAL <variable|string>)``
+ True if the given string or variable's value is a valid number and greater
+ than or equal to that on the right.
+
 ``if(<variable|string> STRLESS <variable|string>)``
  True if the given string or variable's value is lexicographically less
  than the string or variable on the right.
@@ -127,15 +137,31 @@ Possible expressions are:
  True if the given string or variable's value is lexicographically equal
  to the string or variable on the right.
 
+``if(<variable|string> STRLESS_EQUAL <variable|string>)``
+ True if the given string or variable's value is lexicographically less
+ than or equal to the string or variable on the right.
+
+``if(<variable|string> STRGREATER_EQUAL <variable|string>)``
+ True if the given string or variable's value is lexicographically greater
+ than or equal to the string or variable on the right.
+
 ``if(<variable|string> VERSION_LESS <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``).
 
+``if(<variable|string> VERSION_GREATER <variable|string>)``
+ Component-wise integer version number comparison (version format is
+ ``major[.minor[.patch[.tweak]]]``).
+
 ``if(<variable|string> VERSION_EQUAL <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``).
 
-``if(<variable|string> VERSION_GREATER <variable|string>)``
+``if(<variable|string> VERSION_LESS_EQUAL <variable|string>)``
+ Component-wise integer version number comparison (version format is
+ ``major[.minor[.patch[.tweak]]]``).
+
+``if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``maj

[Cmake-commits] CMake branch, next, updated. v3.6.1-1128-g05c29d6

[Chuck Atkins]

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, next has been updated
   via  05c29d64b440766b28622db87d5ab91069ec2af7 (commit)
   via  e52302d6cbee72c9d680affcf1f253bfa61f1891 (commit)
  from  f4cc3c36d7a704951d87abfd3031182871aa0d41 (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=05c29d64b440766b28622db87d5ab91069ec2af7
commit 05c29d64b440766b28622db87d5ab91069ec2af7
Merge: f4cc3c3 e52302d
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 09:02:49 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Aug 5 09:02:49 2016 -0400

Merge topic 'update-cle-version-info' into next

e52302d6 CrayLinuxEnvironment: Add alternative methods to get version info


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e52302d6cbee72c9d680affcf1f253bfa61f1891
commit e52302d6cbee72c9d680affcf1f253bfa61f1891
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Aug 4 14:46:10 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Fri Aug 5 09:01:43 2016 -0400

CrayLinuxEnvironment: Add alternative methods to get version info

Closes: #16229

diff --git a/Modules/Compiler/CrayPrgEnv.cmake 
b/Modules/Compiler/CrayPrgEnv.cmake
index fa39b00..9f8befd 100644
--- a/Modules/Compiler/CrayPrgEnv.cmake
+++ b/Modules/Compiler/CrayPrgEnv.cmake
@@ -56,6 +56,8 @@ macro(__CrayPrgEnv_setup lang test_src compiler_cmd link_cmd)
 message(STATUS "Cray Programming Environment $ENV{CRAYPE_VERSION} ${lang}")
   elseif(DEFINED ENV{ASYNCPE_VERSION})
 message(STATUS "Cray XT Programming Environment $ENV{ASYNCPE_VERSION} 
${lang}")
+  else()
+message(STATUS "Cray Programming Environment (unknown version) ${lang}")
   endif()
 
   # Flags for the Cray wrappers
diff --git a/Modules/Platform/CrayLinuxEnvironment.cmake 
b/Modules/Platform/CrayLinuxEnvironment.cmake
index 97771a2..a1a3d3f 100644
--- a/Modules/Platform/CrayLinuxEnvironment.cmake
+++ b/Modules/Platform/CrayLinuxEnvironment.cmake
@@ -8,14 +8,22 @@ if(DEFINED ENV{CRAYOS_VERSION})
   set(CMAKE_SYSTEM_VERSION "$ENV{CRAYOS_VERSION}")
 elseif(DEFINED ENV{XTOS_VERSION})
   set(CMAKE_SYSTEM_VERSION "$ENV{XTOS_VERSION}")
-else()
-  message(FATAL_ERROR "Neither the CRAYOS_VERSION or XTOS_VERSION environment 
variables are defined.  This platform file should be used inside the Cray Linux 
Environment for targeting compute nodes (NIDs)")
+elseif(EXISTS /etc/opt/cray/release/cle-release)
+  file(STRINGS /etc/opt/cray/release/cle-release release REGEX "^RELEASE=.*")
+  string(REGEX REPLACE "^RELEASE=(.*)$" "\\1" CMAKE_SYSTEM_VERSION 
"${release}")
+  unset(release)
+elseif(EXISTS /etc/opt/cray/release/clerelease)
+  file(READ /etc/opt/cray/release/clerelease CMAKE_SYSTEM_VERSION)
 endif()
 
 # Guard against multiple messages
 if(NOT __CrayLinuxEnvironment_message)
-  set(__CrayLinuxEnvironment_message 1)
-  message(STATUS "Cray Linux Environment ${CMAKE_SYSTEM_VERSION}")
+  set(__CrayLinuxEnvironment_message 1 CACHE INTERNAL "")
+  if(NOT CMAKE_SYSTEM_VERSION)
+message(STATUS "CrayLinuxEnvironment: Unable to determine CLE version.  
This platform file should only be used from inside the Cray Linux Environment 
for targeting compute nodes (NIDs).")
+  else()
+message(STATUS "Cray Linux Environment ${CMAKE_SYSTEM_VERSION}")
+  endif()
 endif()
 
 # All cray systems are x86 CPUs and have been for quite some time

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.1-1126-gf4cc3c3

[Chuck Atkins]

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, next has been updated
   via  f4cc3c36d7a704951d87abfd3031182871aa0d41 (commit)
   via  7e29fda9fc6f0081825d1961249d3e572f460b9f (commit)
  from  721ea794cd31ba2c2e96d35eb7b15d97db5c4642 (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=f4cc3c36d7a704951d87abfd3031182871aa0d41
commit f4cc3c36d7a704951d87abfd3031182871aa0d41
Merge: 721ea79 7e29fda
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 09:00:54 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Aug 5 09:00:54 2016 -0400

Merge topic 'update-cle-version-info' into next

7e29fda9 Closes: #16229


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e29fda9fc6f0081825d1961249d3e572f460b9f
commit 7e29fda9fc6f0081825d1961249d3e572f460b9f
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 08:58:27 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Fri Aug 5 08:59:55 2016 -0400

Closes: #16229

diff --git a/Modules/Compiler/CrayPrgEnv.cmake 
b/Modules/Compiler/CrayPrgEnv.cmake
index fa39b00..9f8befd 100644
--- a/Modules/Compiler/CrayPrgEnv.cmake
+++ b/Modules/Compiler/CrayPrgEnv.cmake
@@ -56,6 +56,8 @@ macro(__CrayPrgEnv_setup lang test_src compiler_cmd link_cmd)
 message(STATUS "Cray Programming Environment $ENV{CRAYPE_VERSION} ${lang}")
   elseif(DEFINED ENV{ASYNCPE_VERSION})
 message(STATUS "Cray XT Programming Environment $ENV{ASYNCPE_VERSION} 
${lang}")
+  else()
+message(STATUS "Cray Programming Environment (unknown version) ${lang}")
   endif()
 
   # Flags for the Cray wrappers
diff --git a/Modules/Platform/CrayLinuxEnvironment.cmake 
b/Modules/Platform/CrayLinuxEnvironment.cmake
index 301eb85..a1a3d3f 100644
--- a/Modules/Platform/CrayLinuxEnvironment.cmake
+++ b/Modules/Platform/CrayLinuxEnvironment.cmake
@@ -18,7 +18,7 @@ endif()
 
 # Guard against multiple messages
 if(NOT __CrayLinuxEnvironment_message)
-  set(__CrayLinuxEnvironment_message 1 CACHE BOOL "" FORCE)
+  set(__CrayLinuxEnvironment_message 1 CACHE INTERNAL "")
   if(NOT CMAKE_SYSTEM_VERSION)
 message(STATUS "CrayLinuxEnvironment: Unable to determine CLE version.  
This platform file should only be used from inside the Cray Linux Environment 
for targeting compute nodes (NIDs).")
   else()

---

Summary of changes:
 Modules/Compiler/CrayPrgEnv.cmake   |2 ++
 Modules/Platform/CrayLinuxEnvironment.cmake |2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.1-1117-gf6773d2

[Chuck Atkins]

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, next has been updated
   via  f6773d23c4ca2cf59726734aba131f2be36307f0 (commit)
   via  388147085e26ec8e8589640f2492cccfe14f3f8b (commit)
  from  a67e5b8ce377c119914fa8e0983defbbd3daf146 (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=f6773d23c4ca2cf59726734aba131f2be36307f0
commit f6773d23c4ca2cf59726734aba131f2be36307f0
Merge: a67e5b8 3881470
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Aug 4 15:26:52 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Aug 4 15:26:52 2016 -0400

Merge topic 'update-cle-version-info' into next

38814708 CrayLinuxEnvironment: Add alternative methods to retrive version 
info


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=388147085e26ec8e8589640f2492cccfe14f3f8b
commit 388147085e26ec8e8589640f2492cccfe14f3f8b
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Aug 4 14:46:10 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Thu Aug 4 13:20:37 2016 -0600

CrayLinuxEnvironment: Add alternative methods to retrive version info

diff --git a/Modules/Platform/CrayLinuxEnvironment.cmake 
b/Modules/Platform/CrayLinuxEnvironment.cmake
index 97771a2..301eb85 100644
--- a/Modules/Platform/CrayLinuxEnvironment.cmake
+++ b/Modules/Platform/CrayLinuxEnvironment.cmake
@@ -8,14 +8,22 @@ if(DEFINED ENV{CRAYOS_VERSION})
   set(CMAKE_SYSTEM_VERSION "$ENV{CRAYOS_VERSION}")
 elseif(DEFINED ENV{XTOS_VERSION})
   set(CMAKE_SYSTEM_VERSION "$ENV{XTOS_VERSION}")
-else()
-  message(FATAL_ERROR "Neither the CRAYOS_VERSION or XTOS_VERSION environment 
variables are defined.  This platform file should be used inside the Cray Linux 
Environment for targeting compute nodes (NIDs)")
+elseif(EXISTS /etc/opt/cray/release/cle-release)
+  file(STRINGS /etc/opt/cray/release/cle-release release REGEX "^RELEASE=.*")
+  string(REGEX REPLACE "^RELEASE=(.*)$" "\\1" CMAKE_SYSTEM_VERSION 
"${release}")
+  unset(release)
+elseif(EXISTS /etc/opt/cray/release/clerelease)
+  file(READ /etc/opt/cray/release/clerelease CMAKE_SYSTEM_VERSION)
 endif()
 
 # Guard against multiple messages
 if(NOT __CrayLinuxEnvironment_message)
-  set(__CrayLinuxEnvironment_message 1)
-  message(STATUS "Cray Linux Environment ${CMAKE_SYSTEM_VERSION}")
+  set(__CrayLinuxEnvironment_message 1 CACHE BOOL "" FORCE)
+  if(NOT CMAKE_SYSTEM_VERSION)
+message(STATUS "CrayLinuxEnvironment: Unable to determine CLE version.  
This platform file should only be used from inside the Cray Linux Environment 
for targeting compute nodes (NIDs).")
+  else()
+message(STATUS "Cray Linux Environment ${CMAKE_SYSTEM_VERSION}")
+  endif()
 endif()
 
 # All cray systems are x86 CPUs and have been for quite some time

---

Summary of changes:
 Modules/Platform/CrayLinuxEnvironment.cmake |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.1-1044-gdc1dbed

[Chuck Atkins]

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, next has been updated
   via  dc1dbedc733126da4ed0fff03cefab71b0692d22 (commit)
   via  8eb0b56c2ace0f005cba436268337f509e06033f (commit)
  from  e6bfb7d0d6a053aeb105a2480687519095b35b70 (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=dc1dbedc733126da4ed0fff03cefab71b0692d22
commit dc1dbedc733126da4ed0fff03cefab71b0692d22
Merge: e6bfb7d 8eb0b56
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 2 10:42:08 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Aug 2 10:42:08 2016 -0400

Merge topic 'fix-findhdf5-definitions' into next

8eb0b56c FindHDF5: Make sure compile definition vars keep the -D flag


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8eb0b56c2ace0f005cba436268337f509e06033f
commit 8eb0b56c2ace0f005cba436268337f509e06033f
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 2 10:34:51 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Tue Aug 2 10:34:51 2016 -0400

FindHDF5: Make sure compile definition vars keep the -D flag

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 50e1892..a898386 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -332,7 +332,7 @@ macro( _HDF5_parse_compile_line
 set( RE " -D([^ ]*)")
 string( REGEX MATCHALL "${RE}" definition_flags "${${compile_line_var}}" )
 foreach( DEF IN LISTS definition_flags )
-string( REGEX REPLACE "${RE}" "\\1" DEF "${DEF}" )
+string( STRIP "${DEF}" DEF )
 list( APPEND ${definitions} ${DEF} )
 endforeach()
 

---

Summary of changes:
 Modules/FindHDF5.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] FindLibXml2.cmake: rename "LIBXML2_DEFINITIONS"

[Chuck Atkins]

Hi Yaron,


I think it should b renamed to "LIBXML2_COMPILE_FLAGS".
>

Xxx_DEFINITIONS is one of the standard variable names for a given
FindXxx.cmake find module, see
https://cmake.org/cmake/help/v3.6/manual/cmake-developer.7.html#standard-variable-names
.



> If u wish, I can submit a patch.
>

Thank you for the enthusiasm!   If you would like to improve on the
FindLibXML2 module, which really hasn't been touched in several years aside
from formatting changes, rather than mess with the varible names I would
instead suggest you look at creating an imported target for what get's
found.  That would certainly help bring the find module up to more modern
CMake conventions and would be greatly appreciated!

- Chuck
-- 

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] custom build

[Chuck Atkins]

Hi Lev,

However, the target builds only if I explicitly say 'make foo_sqlite'. So
> far
> so good. Is there any way I can make it build if I just say 'make'?
>

See the add_custom_target documentation for the ALL option,
https://cmake.org/cmake/help/v3.6/command/add_custom_target.html


And, there are more then one sqlite database to build, how can I make the
> rule to be generic? Can I say *.sql, *.sqlite?
>

The problem with using wild cards is that they won't be sensitive to make
detecting file changes.  For example, if you add a new file then CMake
won't automatically re-run because the *.sql statement hasn't changed.  You
should also be able to replace the separate custom_target and
custom_command with a single custom_target:

add_custom_target(foo ALL sqlite3 -init foo.sql foo.sqlite)

You could also wrap the call in a macro for convience:

macro(add_sqlite_target name)
  add_custom_target(${name} ALL sqlite3 -init
${CMAKE_CURRENT_SOURCE_DIR}/${name}.sql
${CMAKE_CURRENT_BINARY_DIR}/${name}.sqlite BYPRODUCTS
${CMAKE_CURRENT_BINARY_DIR}/${name}.sqlite SOURCES ${name}.sql)
endmacro()

add_sqlite_target(fooA)
add_sqlite_target(fooB)
add_sqlite_target(fooC)
add_sqlite_target(fooD)

Note the addition of BYPRODUCTS and SOURCES.  This adds additional
dependency information if you decided to either a) make other targets that
consume the database or b) have other targets that produce the source code.

- Chuck
-- 

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-commits] CMake branch, next, updated. v3.6.1-993-ga135841

[Chuck Atkins]

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, next has been updated
   via  a135841da3110538f92f9aa51923e51157f31f1b (commit)
   via  412f76c6b8a713a158396f385bc0521cd3d39f7c (commit)
  from  67849b913481d1e686742d8e543d0dc97495553e (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=a135841da3110538f92f9aa51923e51157f31f1b
commit a135841da3110538f92f9aa51923e51157f31f1b
Merge: 67849b9 412f76c
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Jul 28 12:10:57 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Jul 28 12:10:57 2016 -0400

Merge topic 'add-findszip' into next

412f76c6 FindSZIP: Add a new find module to locate the SZIP library.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=412f76c6b8a713a158396f385bc0521cd3d39f7c
commit 412f76c6b8a713a158396f385bc0521cd3d39f7c
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jul 25 13:07:02 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Thu Jul 28 12:10:30 2016 -0400

FindSZIP: Add a new find module to locate the SZIP library.

diff --git a/Modules/FindSZIP.cmake b/Modules/FindSZIP.cmake
new file mode 100644
index 000..db0a3c7
--- /dev/null
+++ b/Modules/FindSZIP.cmake
@@ -0,0 +1,128 @@
+#.rst:
+# FindSZIP
+# -
+#
+# Find SZIP, a compression library developed by HDF5.
+#
+# Once done this will define
+#
+# ::
+#   SZIP_FOUND - System has SZIP
+#   SZIP_INCLUDE_DIRS - The SZIP include directories to use
+#   SZIP_LIBRARIES - Link these to use SZIP
+#   SZIP_VERSION - The version of SZIP found
+# ::
+#
+# The following imported target is also created:
+#
+# ::
+# SZIP::SZIP
+# ::
+#
+# The following variable can be set to guide the search for SZIP libraries and
+# includes:
+#   SZIP_ROOT_DIR -
+# Search order preference is SZIP_ROOT_DIR followed by ENV{SZIP_INSTALL}.
+# If SZIP_ROOT_DIR is specified then it is searched exclusively, ignoring
+# default search paths.
+
+#=
+# Copyright 2006-2016 Kitware, Inc.
+#
+# Distributed under the OSI-approved BSD License (the "License");
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+#  License text for the above reference.)
+
+function(_SZIP_get_version)
+  set(scratch_dir ${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/szip)
+  set(test_file ${scratch_dir}/cmake_szip_version.c)
+  file(WRITE ${test_file}
+"#include \n"
+"#include \n"
+"int main(void) {\n"
+"  char const* info_ver = \"INFO\" \":\" SZLIB_VERSION;\n"
+"  return 0;\n"
+"}")
+  try_compile(szip_version_test ${scratch_dir} ${test_file}
+CMAKE_FLAGS -DINCLUDE_DIRECTORIES=${SZIP_INCLUDE_DIR}
+COPY_FILE ${scratch_dir}/cmake_szip_version)
+  if(szip_version_test)
+file(STRINGS ${scratch_dir}/cmake_szip_version INFO_VER
+  REGEX "^INFO:([0-9]+(\\.[0-9]+(\\.[0-9]+)?)?)$")
+string(REGEX MATCH "^INFO:([0-9]+(\\.[0-9]+(\\.[0-9]+)?)?)$"
+  INFO_VER "${INFO_VER}")
+set(SZIP_VERSION ${CMAKE_MATCH_1} PARENT_SCOPE)
+  endif()
+endfunction()
+
+# If the root dir is explicitly specified, then ONLY look there
+message("SZIP_ROOT_DIR: ${SZIP_ROOT_DIR}")
+message("ENV{SZIP_INSTALL}: $ENV{SZIP_INSTALL}")
+if(SZIP_ROOT_DIR)
+  set(SZIP_SEARCH_OPTS PATHS ${SZIP_ROOT_DIR} NO_DEFAULT_PATH)
+elseif(NOT ("$ENV{SZIP_INSTALL}" STREQUAL ""))
+  message("DEBUG: ENV{SZIP_INSTALL}")
+  set(SZIP_SEARCH_OPTS HINTS ENV SZIP_INSTALL)
+endif()
+
+# Find the main header
+find_path(SZIP_INCLUDE_DIR NAMES szlib.h
+  ${SZIP_SEARCH_OPTS} PATH_SUFFIXES include include/szip Include Include/szip)
+mark_as_advanced(SZIP_INCLUDE_DIR)
+
+# Find the release library
+set(SZIP_LIBRARY_RELEASE_NAMES sz szip)
+if(WIN32)
+  list(APPEND SZIP_LIBRARY_RELEASE_NAMES libsz libszip)
+endif()
+find_library(SZIP_LIBRARY_RELEASE NAMES ${SZIP_LIBRARY_RELEASE_NAMES}
+  ${SZIP_SEARCH_OPTS} PATH_SUFFIXES lib Lib)
+
+# Find the debug library
+set(SZIP_LIBRARY_DEBUG_NAMES sz_d szip_d)
+if(WIN32)
+  list(APPEND SZIP_LIBARY_DEBUG_NAMES libsz_d libs

[Cmake-commits] CMake branch, next, updated. v3.6.1-991-g67849b9

[Chuck Atkins]

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, next has been updated
   via  67849b913481d1e686742d8e543d0dc97495553e (commit)
   via  fe54ce57545ae1292a94b28405c4fa65e19f5748 (commit)
  from  10aeccbfbd4d34050a470f59757a81cd553f0eb2 (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=67849b913481d1e686742d8e543d0dc97495553e
commit 67849b913481d1e686742d8e543d0dc97495553e
Merge: 10aeccb fe54ce5
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Jul 28 12:10:11 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Jul 28 12:10:11 2016 -0400

Merge topic 'add-findszip' into next

fe54ce57 FindSZIP: Better logic for handling ROOT_DIR search path


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe54ce57545ae1292a94b28405c4fa65e19f5748
commit fe54ce57545ae1292a94b28405c4fa65e19f5748
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Jul 28 12:06:32 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Thu Jul 28 12:06:32 2016 -0400

FindSZIP: Better logic for handling ROOT_DIR search path

diff --git a/Modules/FindSZIP.cmake b/Modules/FindSZIP.cmake
index 872907d..db0a3c7 100644
--- a/Modules/FindSZIP.cmake
+++ b/Modules/FindSZIP.cmake
@@ -62,22 +62,19 @@ function(_SZIP_get_version)
 endfunction()
 
 # If the root dir is explicitly specified, then ONLY look there
+message("SZIP_ROOT_DIR: ${SZIP_ROOT_DIR}")
+message("ENV{SZIP_INSTALL}: $ENV{SZIP_INSTALL}")
 if(SZIP_ROOT_DIR)
-  set(SZIP_SEARCH_OPTS NO_DEFAULT_PATH)
-else()
-  # Otherwise initialize from an environment variable
-  set(SZIP_ROOT_DIR $ENV{SZIP_INSTALL})
-endif()
-
-# If we do have a root dir, use it as a hint
-if(SZIP_ROOT_DIR)
-  set(SZIP_SEARCH_PATHS HINTS ${SZIP_ROOT_DIR})
+  set(SZIP_SEARCH_OPTS PATHS ${SZIP_ROOT_DIR} NO_DEFAULT_PATH)
+elseif(NOT ("$ENV{SZIP_INSTALL}" STREQUAL ""))
+  message("DEBUG: ENV{SZIP_INSTALL}")
+  set(SZIP_SEARCH_OPTS HINTS ENV SZIP_INSTALL)
 endif()
 
 # Find the main header
 find_path(SZIP_INCLUDE_DIR NAMES szlib.h
-  ${SZIP_SEARCH_PATHS} ${SZIP_SEARCH_OPTS}
-  PATH_SUFFIXES include include/szip Include Include/szip)
+  ${SZIP_SEARCH_OPTS} PATH_SUFFIXES include include/szip Include Include/szip)
+mark_as_advanced(SZIP_INCLUDE_DIR)
 
 # Find the release library
 set(SZIP_LIBRARY_RELEASE_NAMES sz szip)
@@ -85,8 +82,7 @@ if(WIN32)
   list(APPEND SZIP_LIBRARY_RELEASE_NAMES libsz libszip)
 endif()
 find_library(SZIP_LIBRARY_RELEASE NAMES ${SZIP_LIBRARY_RELEASE_NAMES}
-  ${SZIP_SEARCH_PATHS} ${SZIP_SEARCH_OPTS}
-  PATH_SUFFIXES lib Lib)
+  ${SZIP_SEARCH_OPTS} PATH_SUFFIXES lib Lib)
 
 # Find the debug library
 set(SZIP_LIBRARY_DEBUG_NAMES sz_d szip_d)
@@ -94,13 +90,12 @@ if(WIN32)
   list(APPEND SZIP_LIBARY_DEBUG_NAMES libsz_d libszip_d)
 endif()
 find_library(SZIP_LIBRARY_DEBUG NAMES ${SZIP_LIBRARY_DEBUG_NAMES}
-  ${SZIP_SEARCH_PATHS} ${SZIP_SEARCH_OPTS}
-  PATH_SUFFIXES lib Lib)
+  ${SZIP_SEARCH_OPTS} PATH_SUFFIXES lib Lib)
 
 include(SelectLibraryConfigurations)
 select_library_configurations(SZIP)
 
-if(SZIP_INCLUDE_DIR AND SZIP_LIBRARY)
+if(SZIP_INCLUDE_DIR)
   _SZIP_get_version()
 endif()
 

---

Summary of changes:
 Modules/FindSZIP.cmake |   27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.1-984-ge752540

[Chuck Atkins]

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, next has been updated
   via  e752540b9f56d82cc5527c681c3883df66730c48 (commit)
   via  9e301f70e0f665aed783977a239d2712775a0aa0 (commit)
   via  3d57541d6d4fa094db0ceede2972d27d0a0a0246 (commit)
   via  ffc7c24b2e91ce47718237e6cc90a21358833426 (commit)
   via  d615d20a63ce4fae5ada3881f4d154bfc4385fd7 (commit)
  from  858f96eab547ea0970bc087d6d0b77c26f4a377a (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=e752540b9f56d82cc5527c681c3883df66730c48
commit e752540b9f56d82cc5527c681c3883df66730c48
Merge: 858f96e 9e301f7
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Wed Jul 27 10:32:59 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Jul 27 10:32:59 2016 -0400

Merge topic 'add-findszip' into next

9e301f70 FindSZIP: Add a new find module to locate the SZIP library.
3d57541d CMake Nightly Date Stamp
ffc7c24b CMake Nightly Date Stamp
d615d20a CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e301f70e0f665aed783977a239d2712775a0aa0
commit 9e301f70e0f665aed783977a239d2712775a0aa0
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jul 25 13:07:02 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Wed Jul 27 10:23:44 2016 -0400

FindSZIP: Add a new find module to locate the SZIP library.

diff --git a/Modules/FindSZIP.cmake b/Modules/FindSZIP.cmake
new file mode 100644
index 000..872907d
--- /dev/null
+++ b/Modules/FindSZIP.cmake
@@ -0,0 +1,133 @@
+#.rst:
+# FindSZIP
+# -
+#
+# Find SZIP, a compression library developed by HDF5.
+#
+# Once done this will define
+#
+# ::
+#   SZIP_FOUND - System has SZIP
+#   SZIP_INCLUDE_DIRS - The SZIP include directories to use
+#   SZIP_LIBRARIES - Link these to use SZIP
+#   SZIP_VERSION - The version of SZIP found
+# ::
+#
+# The following imported target is also created:
+#
+# ::
+# SZIP::SZIP
+# ::
+#
+# The following variable can be set to guide the search for SZIP libraries and
+# includes:
+#   SZIP_ROOT_DIR -
+# Search order preference is SZIP_ROOT_DIR followed by ENV{SZIP_INSTALL}.
+# If SZIP_ROOT_DIR is specified then it is searched exclusively, ignoring
+# default search paths.
+
+#=
+# Copyright 2006-2016 Kitware, Inc.
+#
+# Distributed under the OSI-approved BSD License (the "License");
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+#  License text for the above reference.)
+
+function(_SZIP_get_version)
+  set(scratch_dir ${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/szip)
+  set(test_file ${scratch_dir}/cmake_szip_version.c)
+  file(WRITE ${test_file}
+"#include \n"
+"#include \n"
+"int main(void) {\n"
+"  char const* info_ver = \"INFO\" \":\" SZLIB_VERSION;\n"
+"  return 0;\n"
+"}")
+  try_compile(szip_version_test ${scratch_dir} ${test_file}
+CMAKE_FLAGS -DINCLUDE_DIRECTORIES=${SZIP_INCLUDE_DIR}
+COPY_FILE ${scratch_dir}/cmake_szip_version)
+  if(szip_version_test)
+file(STRINGS ${scratch_dir}/cmake_szip_version INFO_VER
+  REGEX "^INFO:([0-9]+(\\.[0-9]+(\\.[0-9]+)?)?)$")
+string(REGEX MATCH "^INFO:([0-9]+(\\.[0-9]+(\\.[0-9]+)?)?)$"
+  INFO_VER "${INFO_VER}")
+set(SZIP_VERSION ${CMAKE_MATCH_1} PARENT_SCOPE)
+  endif()
+endfunction()
+
+# If the root dir is explicitly specified, then ONLY look there
+if(SZIP_ROOT_DIR)
+  set(SZIP_SEARCH_OPTS NO_DEFAULT_PATH)
+else()
+  # Otherwise initialize from an environment variable
+  set(SZIP_ROOT_DIR $ENV{SZIP_INSTALL})
+endif()
+
+# If we do have a root dir, use it as a hint
+if(SZIP_ROOT_DIR)
+  set(SZIP_SEARCH_PATHS HINTS ${SZIP_ROOT_DIR})
+endif()
+
+# Find the main header
+find_path(SZIP_INCLUDE_DIR NAMES szlib.h
+  ${SZIP_SEARCH_PATHS} ${SZIP_SEARCH_OPTS}
+  PATH_SUFFIXES include include/szip Include Include/szip)
+
+# Find the release library
+set(SZIP_LIBRARY_RELEASE_NAMES sz szip)
+if(WIN32)
+  list(APPEND SZIP_LIBRARY_RELEASE_NAMES libsz libszip)
+endif()
+find_library(SZIP_

Re: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade

[Chuck Atkins]

Hi Brennan,

We also just got the Homebrew cmake formula updated to explicitly include
the patch.  See https://github.com/Homebrew/homebrew-core/pull/2968

- Chuck

On Wed, Jul 13, 2016 at 11:10 PM, Breannan Smith 
wrote:

> Rad, I can verify that the issue is resolved in the git repo if anyone
> else is running into the bug. Thanks!
>
> On Tue, Jul 12, 2016 at 5:12 AM, Robert Maynard
>  wrote:
> > Hi Breannan,
> >
> > You can track the status of the fix at
> > https://gitlab.kitware.com/cmake/cmake/merge_requests/34
> >
> > On Mon, Jul 11, 2016 at 8:52 AM, Robert Maynard
> >  wrote:
> >> Hi Breannan,
> >>
> >> I am able to reproduce this and will start digging into why this is
> occurring.
> >>
> >> On Sun, Jul 10, 2016 at 6:34 PM, Breannan Smith <
> smithbrean...@gmail.com> wrote:
> >>> After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on
> OS X.
> >>>
> >>> With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the
> >>> following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in
> >>> this list:
> >>>
> >>>
> /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib
> >>>
> >>> With 3.6.0, the same find_package command gives the following
> >>> HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present:
> >>>
> >>>
> /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib
> >>>
> >>> The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same
> >>> under 3.6.0. Interestingly, the FindHDF5.cmake module does not report
> >>> a failure under 3.6.0 even though it fails to locate the HDF5 library.
> >>>
> >>> I did not see any changes to FindHDF5.cmake listed under the 3.6
> >>> release notes [1], but diffing the module files there were extensive
> >>> edits made.
> >>>
> >>> Has anyone else run into this issue or found a fix? Thank you!
> >>>
> >>> [1] https://cmake.org/cmake/help/v3.6/release/3.6.html
> >>> --
> >>>
> >>> 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
> --
>
> 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
>
-- 

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] Does Makefile generated by CMake support make -jN?

[Chuck Atkins]

>
> Thanks for your analysis for me Andrew. I can't use "-j" options, i think
> the

reason is the project i dealed with is not parallel. Thus when i use "make
> -jN", it couldn't work correctly every time. Obviously it caused by the
> Makefile generated by CMake, so i wonder if there are some CMake options to
> use CPU effectively.


This usually means missing dependencies the CMakeLists.txt files.  Because
of this you get unpredictable results when compiling in parallel.  Check
your dependencies on targets, link lines, and source files and make sure
they are all correct and not missing anything.



> Because i found when i use already exist Makefile, just
> use "make", it used about 480% CPU.


The Makefile is probably explicitly adding a fixed number of -j options.
CMake will not do this and instead rely on the user to call make with their
desired appropriate level of parallelism.



> And when i use CMake generated Makefile, it just uesd about 96% CPU. The
> "hardware acceleration" i said means how to
> CPU more effectively in CMake.
>

-jN is as good as it gets for make.  That being said, you can always try a
different generator, like Ninja, which tends to have quite a bit better
build times in parallel.

First things first though, you need to get your dependency problem squared
away.  That's the underlying cause of why your parallel builds with -j are
unpredictable.
-- 

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-commits] CMake branch, next, updated. v3.6.0-788-gf405373

[Chuck Atkins]

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, next has been updated
   via  f4053736f27e15046f0f130d8559414c3bee0c9d (commit)
   via  d5e4516ec279318d3c639cda2f20149f0a588220 (commit)
   via  4ece8bdd0fa36d8e69dabf8c620f9e5017e8 (commit)
   via  87c1cd9c517bb57a537ba1f75548e6c20966553d (commit)
  from  0d7f858b7a6e8f1d0e49fadce08b57ea56eab062 (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=f4053736f27e15046f0f130d8559414c3bee0c9d
commit f4053736f27e15046f0f130d8559414c3bee0c9d
Merge: 0d7f858 d5e4516
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Jul 12 15:55:06 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jul 12 15:55:06 2016 -0400

Merge topic 'fix-misc-hdf5-issues' into next

d5e4516e FindHDF5: Cleanup inconsistent use of HDF5_ROOT
4ece8bdd FindHDF5: Properly fail when required components are not found.
87c1cd9c FindHDF5: Fix h5cc arg parsing to work with homebrew on Mac


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5e4516ec279318d3c639cda2f20149f0a588220
commit d5e4516ec279318d3c639cda2f20149f0a588220
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Jul 12 15:32:10 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Tue Jul 12 15:32:10 2016 -0400

FindHDF5: Cleanup inconsistent use of HDF5_ROOT

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index a81ba13..50e1892 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -378,6 +378,10 @@ macro( _HDF5_parse_compile_line
 endforeach()
 endmacro()
 
+if(NOT HDF5_ROOT)
+set(HDF5_ROOT $ENV{HDF5_ROOT})
+endif()
+
 # Try to find HDF5 using an installed hdf5-config.cmake
 if(NOT HDF5_FOUND AND NOT HDF5_ROOT)
 find_package(HDF5 QUIET NO_MODULE)
@@ -478,7 +482,6 @@ if(NOT HDF5_FOUND AND NOT HDF5_ROOT)
   # search options with the wrapper
   find_program(HDF5_${__lang}_COMPILER_EXECUTABLE
 NAMES ${HDF5_${__lang}_COMPILER_NAMES} NAMES_PER_DIR
-HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 ${__lang} Wrapper compiler.  Used only to detect HDF5 
compile flags."
   )
@@ -590,10 +593,14 @@ elseif(NOT HDF5_FOUND AND NOT _HDF5_NEED_TO_SEARCH)
   endif()
 endif()
 
+if(HDF5_ROOT)
+set(SEARCH_OPTS NO_DEFAULT_PATH)
+endif()
 find_program( HDF5_DIFF_EXECUTABLE
 NAMES h5diff
-HINTS ENV HDF5_ROOT
+HINTS ${HDF5_ROOT}
 PATH_SUFFIXES bin Bin
+${SEARCH_OPTS}
 DOC "HDF5 file differencing tool." )
 mark_as_advanced( HDF5_DIFF_EXECUTABLE )
 
@@ -608,9 +615,6 @@ if( NOT HDF5_FOUND )
 set(HDF5_Fortran_LIBRARY_NAMEShdf5_fortran   ${HDF5_C_LIBRARY_NAMES})
 set(HDF5_Fortran_HL_LIBRARY_NAMES hdf5_hl_fortran 
${HDF5_C_HL_LIBRARY_NAMES} ${HDF5_Fortran_LIBRARY_NAMES})
 
-if(HDF5_ROOT)
-set(SEARCH_OPTS NO_DEFAULT_PATH)
-endif()
 foreach(__lang IN LISTS HDF5_LANGUAGE_BINDINGS)
 # find the HDF5 include directories
 if(LANGUAGE STREQUAL "Fortran")
@@ -622,7 +626,7 @@ if( NOT HDF5_FOUND )
 endif()
 
 find_path(HDF5_${__lang}_INCLUDE_DIR ${HDF5_INCLUDE_FILENAME}
-HINTS ${HDF5_ROOT} ENV HDF5_ROOT
+HINTS ${HDF5_ROOT}
 PATHS $ENV{HOME}/.local/include
 PATH_SUFFIXES include Include
 ${SEARCH_OPTS}
@@ -648,12 +652,12 @@ if( NOT HDF5_FOUND )
 endif()
 find_library(HDF5_${LIB}_LIBRARY_DEBUG
 NAMES ${THIS_LIBRARY_SEARCH_DEBUG}
-HINTS ${HDF5_ROOT} ENV HDF5_ROOT PATH_SUFFIXES lib Lib
+HINTS ${HDF5_ROOT} PATH_SUFFIXES lib Lib
 ${SEARCH_OPTS}
 )
 find_library( HDF5_${LIB}_LIBRARY_RELEASE
 NAMES ${THIS_LIBRARY_SEARCH_RELEASE}
-HINTS ${HDF5_ROOT} ENV HDF5_ROOT PATH_SUFFIXES lib Lib
+HINTS ${HDF5_ROOT} PATH_SUFFIXES lib Lib
 ${SEARCH_OPTS}
 )
 select_library_configurations( HDF5_${LIB} )
@@ -685,12 +689,12 @@ if( NOT HDF5_FOUND )
 endif()
 find_library(HDF5_${LIB}_LIBRARY_DEBUG
 NAMES ${THIS_LIBRARY_SEARCH_DEBUG}
-HINTS ${HDF5_ROOT} ENV HDF5_ROOT PATH_SUFFIXES lib Lib
+HINTS ${HDF5_ROOT} PATH_SUFFIXES lib Lib
 ${SEARCH_OPTS}
 )
 find_library( HDF5_${LIB}_LIBRARY_RELEASE
 NAMES ${THIS_LIBRARY_SEARCH_RELEASE}
-  

[Cmake-commits] CMake branch, next, updated. v3.6.0-773-g230ad0d

[Chuck Atkins]

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, next has been updated
   via  230ad0d96f390c5e4b300f4cb3103e341556f542 (commit)
   via  7f3c28a4acfee737db0079a98a76eafc5f3af7e2 (commit)
  from  cfdb1592487c71e046d4f08d63d828d54b712e94 (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=230ad0d96f390c5e4b300f4cb3103e341556f542
commit 230ad0d96f390c5e4b300f4cb3103e341556f542
Merge: cfdb159 7f3c28a
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jul 11 12:06:04 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Jul 11 12:06:04 2016 -0400

Merge topic 'fix-hdf5-homebrew' into next

7f3c28a4 FindHDF5: Fix h5cc arg parsing to work with homebrew on Mac


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f3c28a4acfee737db0079a98a76eafc5f3af7e2
commit 7f3c28a4acfee737db0079a98a76eafc5f3af7e2
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jul 11 11:26:24 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Mon Jul 11 12:01:36 2016 -0400

FindHDF5: Fix h5cc arg parsing to work with homebrew on Mac

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index b074f63..f644a17 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -267,8 +267,20 @@ endfunction()
 # return_value argument, the text output is stored to the output variable.
 macro( _HDF5_invoke_compiler language output return_value version)
 set(${version})
+if(HDF5_USE_STATIC_LIBRARIES)
+   set(_ltargs -noshlib)
+ else()
+   set(_ltargs -shlib)
+endif()
+if(language STREQUAL "C")
+set(_sourcefile test_hdf5.c)
+elseif(language STREQUAL "CXX")
+set(_sourcefile test_hdf5.cxx)
+elseif(language STREQUAL "Fortran")
+set(_sourcefile test_hdf5.f90)
+endif()
 exec_program( ${HDF5_${language}_COMPILER_EXECUTABLE}
-ARGS -show
+ARGS -show ${_ltargs} ${_sourcefile}
 OUTPUT_VARIABLE ${output}
 RETURN_VALUE ${return_value}
 )
@@ -321,7 +333,6 @@ macro( _HDF5_parse_compile_line
 string( REGEX MATCHALL "-L([^\" ]+|\"[^\"]+\")" library_path_flags
 "${${compile_line_var}}"
 )
-
 foreach( LPATH ${library_path_flags} )
 string( REGEX REPLACE "^-L" "" LPATH ${LPATH} )
 string( REPLACE "//" "/" LPATH ${LPATH} )
@@ -331,17 +342,32 @@ macro( _HDF5_parse_compile_line
 # now search for the library names specified in the compile line (match 
-l...)
 # match only -l's preceded by a space or comma
 # this is to exclude directory names like xxx-linux/
-string( REGEX MATCHALL "[, ]-l([^\", ]+)" library_name_flags
+string( REGEX MATCHALL "[, ]+-l([^\", ]+)" library_name_flags
 "${${compile_line_var}}" )
-# strip the -l from all of the library flags and add to the search list
 foreach( LIB ${library_name_flags} )
-string( REGEX REPLACE "^[, ]-l" "" LIB ${LIB} )
-if(LIB MATCHES ".*_hl")
+string( REGEX REPLACE "^[, ]+-l" "" LIB ${LIB} )
+if(LIB MATCHES ".*hl")
 list(APPEND ${libraries_hl} ${LIB})
 else()
 list(APPEND ${libraries} ${LIB})
 endif()
 endforeach()
+
+# now search for full library paths with no flags
+string( REGEX MATCHALL "[, ][^\-]([^\", ]+)" library_name_noflags
+"${${compile_line_var}}" )
+foreach( LIB ${library_name_noflags})
+string( REGEX REPLACE "^[, ]+" "" LIB ${LIB} )
+get_filename_component(LIB_DIR ${LIB} DIRECTORY)
+get_filename_component(LIB_NAME ${LIB} NAME_WE)
+string( REGEX REPLACE "^lib" "" LIB_NAME ${LIB_NAME} )
+list( APPEND ${library_paths} ${LIB_DIR} )
+if(LIB_NAME MATCHES ".*hl")
+list(APPEND ${libraries_hl} ${LIB_NAME})
+else()
+list(APPEND ${libraries} ${LIB_NAME})
+endif()
+endforeach()
 endmacro()
 
 # Try to find HDF5 using an installed hdf5-config.cmake
@@ -459,6 +485,14 @@ if(NOT HDF5_FOUND AND NOT HDF5_ROOT)
 HDF5_${__lang}_HL_LIBRARY_NAMES
   )
   set(HDF5_${__lang}_LIBRARIES)
+
+  set(_HDF5_CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES})
+  if(HDF5_USE_STATIC_LIBRARIES)
+set(CMAKE_FIND_LIBRARY_SUFFIXES ${

Re: [cmake-developers] Possibly an obscure bug

[Chuck Atkins]

This isn't a bug but more of a weird side effect of having your executable
named the same as an include file and adding the destination directory for
the executable in the include path.  The same thing would happen if your
executable was named foo and you had "#include ".  By setting
CMAKE_INCLUDE_CURRENT_DIR to on then CMake is adding
-I/path/to/source/blink and -I/path/to/build/blink to the compile line.
The default destination for the list executable also happens to be
/path/to/build/blink.  The second time around, the list executable from the
first run is in the include path, thus #include  picks up the
executable instead of the C++ header.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Finding libxml2 when building llvm/clang

[Chuck Atkins]

You could try to force libxml to be ignored by CMake so it will think it
wasn't found and use the fallback configuration:

cmake ... -DLIBXML2_LIBRARIES=IGNORE ...

- Chuck

On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:

> Building llvm/clang from source involves using CMake. I am building
> llvm/clang from source on Windows using CMake 3.5.2. I am not a clang
> developer, just a clang user. Similarly I just use CMake rather than
> understand or write CMakeLists.txt files.
>
> I reported a problem to clang where building a 32-bit version of clang
> succeeds but building a 64-bit version of clang fails with xml link errors.
> I have A 32-bit libxml2 binary in my path from gnuwin32, but not a 64-bit
> binary of libxml2 in my path.
>
> I was told by clang developers that one of the tools which clang builds
> uses xml and libxml2 if it is available, otherwise uses some other
> technology for the tool. The suggestion was that the problem I am
> encountering is that of CMake; that CMake does not recognize that the
> libxml2 which I have is the 32-bit version and instead thinks that it is
> the 64-bit version and therefore attempts erroneously to use it in the
> 64-bit build of clang.
>
> Does anybody know what might be happening here ? I do not create the
> CMakeLists.txt files used by llvm/clang so I do not know how the use of
> libxml2 can be optionally specified in them.
>
> --
>
> 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
>
-- 

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-commits] CMake branch, next, updated. v3.6.0-rc2-306-g6efb921

[Chuck Atkins]

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, next has been updated
   via  6efb9214e46763a2a731938e3948fc8751f51167 (commit)
   via  90d114ed8c724ca49fa02444dd59d06fd9806f3b (commit)
  from  68b0ed4e365c77d1eb2109b17fa11d358f1a575b (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=6efb9214e46763a2a731938e3948fc8751f51167
commit 6efb9214e46763a2a731938e3948fc8751f51167
Merge: 68b0ed4 90d114e
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Jun 14 09:56:45 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jun 14 09:56:45 2016 -0400

Merge topic 'findcuda-use-correct-runtime-for-required' into next

90d114ed FindCUDA: Use the correct runtime in REQUIRED_VARS check


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90d114ed8c724ca49fa02444dd59d06fd9806f3b
commit 90d114ed8c724ca49fa02444dd59d06fd9806f3b
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jun 13 09:39:15 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Tue Jun 14 09:55:35 2016 -0400

FindCUDA: Use the correct runtime in REQUIRED_VARS check

When enabling the CUDA static runtime, the current module always uses
the shared runtime in the REQUIRED_VARS check.  This change should
select the correct runtime to be checked for as required based on the
CUDA_USE_STATIC_CUDA_RUNTIME option.

Fixes #16096

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 86f89d8..81fc7a8 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -787,8 +787,10 @@ endif()
 if(CUDA_cudart_static_LIBRARY)
   # Set whether to use the static cuda runtime.
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" ON)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_cudart_static_LIBRARY)
 else()
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" OFF)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_CUDART_LIBRARY)
 endif()
 
 if(CUDA_USE_STATIC_CUDA_RUNTIME)
@@ -1003,7 +1005,7 @@ find_package_handle_standard_args(CUDA
 CUDA_TOOLKIT_ROOT_DIR
 CUDA_NVCC_EXECUTABLE
 CUDA_INCLUDE_DIRS
-CUDA_CUDART_LIBRARY
+${CUDA_CUDART_LIBRARY_VAR}
   VERSION_VAR
 CUDA_VERSION
   )

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Provide configuration settings for users

[Chuck Atkins]

Hi Cedric,

It sounds like creating a package config file is exactly what you need.
When installed, a user will be able to consume your project with
"find_package(Foo)".  That will locate and read the package config file
which will create an imported target Foo::Foo.  This imported target will
cary with it all of the necessary link dependency information.

See https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html for more
details.

- Chuck

On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet 
wrote:

>
> Hello,
>
> is there a native way to provide configuration settings for the users of a
> software?
>
> For example, I develop a software which depends on several 3rd party
> libraries which are automatically downloaded and installed with the
> ExternalProject module.
> My CMake configuration scripts are written so as to handle these 3rd party
> libraries.
> During installation of the software, header files and libraries are copied
> to the destination directory but (of course) without their 3rd party
> dependencies.
>
> Therefore, if a user wants to use my software, he has to handle these 3rd
> party libraries during compilation and linking steps.
> Depending on the skills of the user, it may be difficult to achieve it.
>
> I would like to know if there exists a native way of providing sufficient
> configuration information so that users do not have to handle these
> libraries.
> For the moment, I provide a CMakeLists template but I wonder if it's the
> best possible solution.
>
> Best regards,
>
> Cédric Doucet
>
> --
>
> 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
>
-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-279-gfba0b6b

[Chuck Atkins]

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, next has been updated
   via  fba0b6b15f0528bf88da45b3fdaca304552bd255 (commit)
   via  25aa576db0294187a20f478ad83aa101d7d57801 (commit)
  from  1e493167950e427062417500f225862904c145dc (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=fba0b6b15f0528bf88da45b3fdaca304552bd255
commit fba0b6b15f0528bf88da45b3fdaca304552bd255
Merge: 1e49316 25aa576
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jun 13 10:21:41 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Jun 13 10:21:41 2016 -0400

Merge topic 'findcuda-use-correct-runtime-for-required' into next

25aa576d FindCUDA: Use the correct runtime in REQUIRED_VARS check


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25aa576db0294187a20f478ad83aa101d7d57801
commit 25aa576db0294187a20f478ad83aa101d7d57801
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jun 13 09:39:15 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Mon Jun 13 10:21:13 2016 -0400

FindCUDA: Use the correct runtime in REQUIRED_VARS check

When enabling the CUDA static runtime, the current module always uses
the shared truntime in the REQUIRED_VARS check.  This change should
select the correct runtime to be checked for as required based on the
CUDA_USE_STATIC_CUDA_RUNTIME option.

Fixes #16096

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 86f89d8..81fc7a8 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -787,8 +787,10 @@ endif()
 if(CUDA_cudart_static_LIBRARY)
   # Set whether to use the static cuda runtime.
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" ON)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_cudart_static_LIBRARY)
 else()
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" OFF)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_CUDART_LIBRARY)
 endif()
 
 if(CUDA_USE_STATIC_CUDA_RUNTIME)
@@ -1003,7 +1005,7 @@ find_package_handle_standard_args(CUDA
 CUDA_TOOLKIT_ROOT_DIR
 CUDA_NVCC_EXECUTABLE
 CUDA_INCLUDE_DIRS
-CUDA_CUDART_LIBRARY
+${CUDA_CUDART_LIBRARY_VAR}
   VERSION_VAR
 CUDA_VERSION
   )

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-267-g0d3c95e

[Chuck Atkins]

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, next has been updated
   via  0d3c95e99e875c846381c472e6e1f066d42eb019 (commit)
   via  5537355afc62328bd3c8dce879862887190e9821 (commit)
   via  06ee543c00971cd6d52a41da146fdbc9317fd5f7 (commit)
  from  63bc1a824aa06ec90bde12603d6bfaa612a80462 (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=0d3c95e99e875c846381c472e6e1f066d42eb019
commit 0d3c95e99e875c846381c472e6e1f066d42eb019
Merge: 63bc1a8 5537355
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jun 13 09:56:36 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Jun 13 09:56:36 2016 -0400

Merge topic 'findcuda-use-correct-runtime-for-required' into next

5537355a FindCUDA: Use the correct runtime in REQUIRED_VARS check
06ee543c CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5537355afc62328bd3c8dce879862887190e9821
commit 5537355afc62328bd3c8dce879862887190e9821
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jun 13 09:39:15 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Mon Jun 13 09:44:04 2016 -0400

FindCUDA: Use the correct runtime in REQUIRED_VARS check

When enabling the CUDA static runtime, the current module always uses
the shared truntime in the REQUIRED_VARS check.  This change should
select the correct runtime to be checked for as required based on the
CUDA_USE_STATIC_CUDA_RUNTIME option.

Fixes Issue #16096

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 86f89d8..81fc7a8 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -787,8 +787,10 @@ endif()
 if(CUDA_cudart_static_LIBRARY)
   # Set whether to use the static cuda runtime.
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" ON)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_cudart_static_LIBRARY)
 else()
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" OFF)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_CUDART_LIBRARY)
 endif()
 
 if(CUDA_USE_STATIC_CUDA_RUNTIME)
@@ -1003,7 +1005,7 @@ find_package_handle_standard_args(CUDA
 CUDA_TOOLKIT_ROOT_DIR
 CUDA_NVCC_EXECUTABLE
 CUDA_INCLUDE_DIRS
-CUDA_CUDART_LIBRARY
+${CUDA_CUDART_LIBRARY_VAR}
   VERSION_VAR
 CUDA_VERSION
   )

---

Summary of changes:
 Modules/FindCUDA.cmake|4 +++-
 Source/CMakeVersion.cmake |2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] How do you handle recursive dependencies in CMake

[Chuck Atkins]

If the projects are each providing their own Config.cmake file then you
probably will want to use those instead of Find modules.  Instead of using
the Foo_Bar_LIBRARIES variable though, try using the actual imported
targets from the config files.  Those should have the appropriate
dependency information. If you're not sure what they are you should be able
to dig through the provided Config.cmake and Targets.cmake files for FooBar
and see which targets are created bu "add_library(FooBar::Foo ...
IMPORTED)".

- Chuck

On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars <s.ba...@rug.nl> wrote:

> In my case all projects provide their own FooBarConfig.cmake, but not a
> FindFooBar.cmake. For this reason I wanted to use those, because I thought
> it saves me the effort of writing a lot of FindFooBar.cmake files, and it
> also seemed like the right way to do it, because it provides things like
> FooBar_LIBRARIES, which is what I need. The reason I said that I create my
> own FooBarConfig.cmake, is because I want to use CMake properly in my own
> project, so I also want to provide a FoorBarConfig.cmake file for my users.
> So even if the projects I use don't do everything properly, I still want to
> do it properly myself. The problem in this case is that I'm not sure what
> the proper way is. If the FoorBarConfig.cmake file is not enough to handle
> the dependencies I encounter, should I provide a FindFooBar.cmake file or
> something, instead of just the FooBarConfig.cmake? And meanwhile also write
> a FindFooBar.cmake file for all my dependencies?
>
> Another reason why this seems odd to me, is because if N different
> projects use FooBar, then also possibly N different versions of
> FindFooBar.cmake are created by all the different projects (I have actually
> already seen this a lot). That is the case, because the FindFooBar.cmake
> file is not provided by the FooBar project, unlike the FooBarConfig.cmake.
>
> Cheers,
> Sven
>
>
> On 06/08/2016 03:11 PM, Chuck Atkins wrote:
>
> The FooBarConfig.cmake is something that should be generated by FooBar's
> build.   The reason you don't get absolute paths for the "libraries" from a
> package config file is that they're not actually libraries but imported
> targets.  The imported target let's you treat "foo" as though it were a
> library built by your project.  It then has the appropriate target
> properties set on it ti define the full path to it's library, etc.  That
> being said, if you're manually creating the FooBarConfig.cmake that's not
> really the right approach.  If the FooBar buil;d doesn't actually generate
> it's own FooBarConfig.cmake file then you'll want to create you're own
> FindFooBar.cmake.  A bare bones find module that creates an imported target
> would look something like this:
>
> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>   find_path(FooBar_INCLUDE_DIR FooBar.h)
>   find_library(FooBar_LIBRARY FooBar)
>
>   include(FindPackageHandleStandardArgs)
>   find_package_handle_standard_args(FooBar
> FOUND_VAR FooBar_FOUND
> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY
>   )
> endif()
>
> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>   add_library(FooBar::FooBar UNKNOWN IMPORTED)
>   set_target_properties(FooBar::FooBar PROPERTIES
> IMPORTED_LOCATION ${FooBar_LIBRARY}
> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR}
>   )
> endif()
>
> Then in your project you can use:
>
> find_package(FooBar)
> add_library(MyLib supercoolfiles.cxx)
> target_libkLibraries(MyLib FooBar::FooBar)
>
> Where this starts to get really helpful in your situation is if you have
> an imported target for A, B, and C, then you can create the appropriate
> dependencies.  Say, for example, you have a FindA.cmake that follows the
> pattern above and generates an A::A target.  Then in your FindB.cmake you
> can have:
>
> if(NOT B_FOUND AND NOT TARGET B::B)
>   find_path(B_INCLUDE_DIR B.h)
>   find_library(B_LIBRARY B)
>
>   include(FindPackageHandleStandardArgs)
>   find_package_handle_standard_args(B
> FOUND_VAR B_FOUND
> REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY
>   )
>
>
>
>
> *  find_package(A QUIET)   if(A_FOUND) set(B_Extra_Deps A::A)
> endif()*
> endif()
>
> if(B_FOUND AND NOT TARGET B::B)
>   add_library(B::B UNKNOWN IMPORTED)
>   set_target_properties(B::B PROPERTIES
> IMPORTED_LOCATION ${B_LIBRARY}
> INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR}
>   )
>
>
>
>
> *  if(B_Extra_Deps) set_target_properties(B::B PROPERTIES
> INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} )   endif()*
> endif()
>
> and similarly for FindC.cmake.  Since A::A, B::B, and C::C are actual
> proper CMake targe

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

[Chuck Atkins]

I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for
uname -m so I assume it works correctly on EL7 as well.  Testead via an IBM
machine hosted at the OSU Open Source Lab that we can access and use for
testing.

- Chuck

On Wed, Jun 8, 2016 at 10:33 AM, M Kelly  wrote:

> Domen Vrankar  writes:
>
> >
> > > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by
> cmake
> > > --system-information) uses the same "uname -m"
> > > see Modules/CMakeDetermineSystem.cmake.
> > >
> > > So there is something odd to have one right and the other wrong...
> >
> > In that case it's quite possible that CPACK_RPM_PACKAGE_ARCHITECTURE
> > is already set to x86_64 somewhere in cmake list which overrides the
> > default.
> >
> > Regards,
> > Domen
>
> Hi,
>
> I do think somewhere we are forcing CPACK_RPM_PACKAGE_ARCHITECTURE to
> x86_64
> I will find that and fix.
>
> thanks,
> mark
>
>
> --
>
> 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
>
-- 

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] How do you handle recursive dependencies in CMake

[Chuck Atkins]

The FooBarConfig.cmake is something that should be generated by FooBar's
build.   The reason you don't get absolute paths for the "libraries" from a
package config file is that they're not actually libraries but imported
targets.  The imported target let's you treat "foo" as though it were a
library built by your project.  It then has the appropriate target
properties set on it ti define the full path to it's library, etc.  That
being said, if you're manually creating the FooBarConfig.cmake that's not
really the right approach.  If the FooBar buil;d doesn't actually generate
it's own FooBarConfig.cmake file then you'll want to create you're own
FindFooBar.cmake.  A bare bones find module that creates an imported target
would look something like this:

if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar)
  find_path(FooBar_INCLUDE_DIR FooBar.h)
  find_library(FooBar_LIBRARY FooBar)

  include(FindPackageHandleStandardArgs)
  find_package_handle_standard_args(FooBar
FOUND_VAR FooBar_FOUND
REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY
  )
endif()

if(FooBar_FOUND AND NOT TARGET FooBar::FooBar)
  add_library(FooBar::FooBar UNKNOWN IMPORTED)
  set_target_properties(FooBar::FooBar PROPERTIES
IMPORTED_LOCATION ${FooBar_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR}
  )
endif()

Then in your project you can use:

find_package(FooBar)
add_library(MyLib supercoolfiles.cxx)
target_libkLibraries(MyLib FooBar::FooBar)

Where this starts to get really helpful in your situation is if you have an
imported target for A, B, and C, then you can create the appropriate
dependencies.  Say, for example, you have a FindA.cmake that follows the
pattern above and generates an A::A target.  Then in your FindB.cmake you
can have:

if(NOT B_FOUND AND NOT TARGET B::B)
  find_path(B_INCLUDE_DIR B.h)
  find_library(B_LIBRARY B)

  include(FindPackageHandleStandardArgs)
  find_package_handle_standard_args(B
FOUND_VAR B_FOUND
REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY
  )




*  find_package(A QUIET)  if(A_FOUND)set(B_Extra_Deps A::A)  endif()*
endif()

if(B_FOUND AND NOT TARGET B::B)
  add_library(B::B UNKNOWN IMPORTED)
  set_target_properties(B::B PROPERTIES
IMPORTED_LOCATION ${B_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR}
  )




*  if(B_Extra_Deps)set_target_properties(B::B PROPERTIES
INTERFACE_LINK_LIBRARIES ${B_Extra_Deps})  endif()*
endif()

and similarly for FindC.cmake.  Since A::A, B::B, and C::C are actual
proper CMake targets and not just library files then they carry with them
associated target dependency information.  In CMake vernacular we refer
this as "target usage requirements" since the target caries with it all the
necessary information for something to actually use it, whether that's just
extra link libraries or also extra include directories and compile
definitions needed.  The Package::Target naming convention is the idea that
each package has it's own namespace where you may define multiple targets.
-- 

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] add_custom_command, POST_BUILD

[Chuck Atkins]

Could you just make the tests run in the post-build of the test?

add_library(Foo Foo.cxx)

add_executable(FooTest FooTest.cxx)
target_link_libraries(FooTest Foo)

add_custom_command(TARGET FooTest POST_BUILD
  COMMAND $ $
)

That way the the test is run as part of it's build.


- Chuck

On Wed, Jun 1, 2016 at 11:46 AM, Vladimir Chebotarev <
vladimir.chebota...@gmail.com> wrote:

> Hi there.
>
> At the moment one can add a command executing after a build of a target
> using:
> add_custom_command(... POST_BUILD...)
>
> However if the command have a dependencies which build after the target,
> there is practically no way to specify it.
>
> Simple case: we have a library and tests for it. E.g. I want them to run
> in POST_BUILD of a library. But, tests already depends on the library so I
> can't make them built before it.
>
> There are few possible solutions to that:
> 1) add possibility to set dependencies for add_custom_command in
> POST_BUILD mode;
> 2) add possibility to populate list of targets if we have specified ones
> in list.
>
> Or maybe correct me if I miss something.
>
> Kind regards, Vladimir.
>
> --
>
> 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
>
-- 

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] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Chuck Atkins]

Interesting.  It seems CMake is having trouble identifying GCC in 6.1.1.
Do you have a 5.x compiler available?  If so does it work with that?  That
would help narrow it down to a gcc6 issue vs something about how Manjaro
packages compilers.

- Chuck

On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma <eschni...@openmailbox.org>
wrote:

> The standard choice is c++
>
>
>
> [eschnigma@manjaro ~]$ c++ --version
> c++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> But I've tried enforcing g++ as such:
>
>
>
> -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
> -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++
>
>
>
> And that has the same results.
>
>
>
> Version:
>
>
>
> [eschnigma@manjaro ~]$ g++ --version
> g++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote:
>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>
>
> This is definitely the reason for no debug symbols.  If the compiler is
> unknown then CMake won't know the right flags to pass to generate debug
> info.  The more important question though is why the compiler can't be
> identified.  What compiler is being used?  Can check with /usr/bin/c++
> --version ?
>
>
>
-- 

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] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Chuck Atkins]

>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>

This is definitely the reason for no debug symbols.  If the compiler is
unknown then CMake won't know the right flags to pass to generate debug
info.  The more important question though is why the compiler can't be
identified.  What compiler is being used?  Can check with /usr/bin/c++
--version ?
-- 

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] How to hundle gcc link options(like whole-archive, --allow-multiple-definition) in CMake？

[Chuck Atkins]

Hi Chao,

You want to let CMake to as much of the work for you as possible.  You're
still trying to explicitly pass the path to the library file to
target_link_libraries.  If you look at the line:

target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a
--no-whole-archive")

there's no CMake target name so CMake can't know about the dependency.
However, if you use the target name instead:

top_dir/CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(foo)
add_subdirectory(sub_dir2)
add_subdirectory(sub_dir1)

top_dir/sub_dir1/CMakeLists.txt
add_library(L1 1.c)

top_dit/sub_dir2/CMakeLists.txt
add_executable(exe1 main.c)
target_link_libraries(exe1 "-Wl,--whole-archive" *L1*
"-Wl,--no-whole-archive")

Notice how in the target_link_libraries line for exe1, the link options are
separate instead of 1 big string combining them all and the actual CMake
target name, L1, is used instead of the output file libL1.a.  You can see
the resulting output is what you want:

$ make VERBOSE=1
...
[100%] Linking C executable exe1
...
/usr/bin/cc CMakeFiles/exe1.dir/main.c.o  -o exe1 -rdynamic
*-Wl,--whole-archive
../sub_dir1/libL1.a -Wl,--no-whole-archive*

Generally speaking, always use target names in a CMakeLists.txt instead of
the actual output file.  There are a few situations where you may need the
actual file name but they are uncommon and even then you would do it
through target properties and generator expressions rather than hard code
the library file name.

- Chuck

On Mon, May 30, 2016 at 8:35 AM, Chaos Zhang  wrote:

> Hi, all,
>
> Thanks for taking your time to review my email. I have a demo project and
> it's structure like as below:
>
> top_dir
> CMakeLists.txt
> sub_dir1
> CMakeLists.txt
> sub_dir2
> CMakeLists.txt
>
> top_dir/sub_dir1/CMakeLists.txt used to build `lib1` by using
> `add_library(lib1 ...)`,
> top_dir/sub_dir2/CMakeLists.txt used to build `exe1` with linking lib1 by
> `target_link_library(exe1 lib1)`.
> And the content of top_dir/CMakeLists.txt is as below:
>
> add_subdirectory(sub_dir2)
> add_subdirectory(sub_dir1)
>
> Normally, when build target exe1, cmake will check dependency so `lib1`
> will
> be built before building exe1. The problem is I am transfering an existed
> makefile project into CMake, and there are many gcc link options, like
> "whole-archive ... no-whole-archive, allow-mutiple-definition", if use like
> `target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a
> --no-whole-archive")`(The form like this, and this may not work, it just a
> e.g.), cmake seem don't built `lib1` any more. Is there any way i can use
> target_link_library like `target_link_library(exe1 "-Wl, --whole-archive
> ../sub_dir1/liblib1.a")` and cmake link dependency checking still work, or
> other way i can transfer these gcc link options into cmake?
>
> Thanks a lot,
> Chao
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-hundle-gcc-link-options-like-whole-archive-allow-multiple-definition-in-CMake-tp7593563.html
> Sent from the CMake mailing list archive at Nabble.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:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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-commits] CMake branch, next, updated. v3.5.2-1533-geec9b0f

[Chuck Atkins]

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, next has been updated
   via  eec9b0f91dac9ac4dc938c624b44ac55b69b3c1c (commit)
   via  b63eb05e2a0d750c08e78e915993da53e165a350 (commit)
  from  43d02bf54b86076ffa4ad0bb30b087a51c0b860e (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=eec9b0f91dac9ac4dc938c624b44ac55b69b3c1c
commit eec9b0f91dac9ac4dc938c624b44ac55b69b3c1c
Merge: 43d02bf b63eb05
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue May 24 10:42:28 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue May 24 10:42:28 2016 -0400

Merge topic 'find-cuda-generate' into next

b63eb05e CUDA: Use file(GENERATE) for cuda cmake scripts


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b63eb05e2a0d750c08e78e915993da53e165a350
commit b63eb05e2a0d750c08e78e915993da53e165a350
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue May 24 09:15:34 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Tue May 24 10:41:07 2016 -0400

CUDA: Use file(GENERATE) for cuda cmake scripts

Instead of just configure_file, by folloing it with a file(GENERATE) the
resulting cmake scripts used by the FindCUDA for wrapping nvcc calls can
now support generator expressions in the CUDA_NVCC_FLAGS variable

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 0718116..2979f0f 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -1395,7 +1395,8 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
   set(cmake_dependency_file 
"${cuda_compile_intermediate_directory}/${generated_file_basename}.depend")
   set(NVCC_generated_dependency_file 
"${cuda_compile_intermediate_directory}/${generated_file_basename}.NVCC-depend")
   set(generated_cubin_file 
"${generated_file_path}/${generated_file_basename}.cubin.txt")
-  set(custom_target_script 
"${cuda_compile_intermediate_directory}/${generated_file_basename}.cmake")
+  set(custom_target_script_pregen 
"${cuda_compile_intermediate_directory}/${generated_file_basename}.cmake.pre-gen")
+  set(custom_target_script 
"${cuda_compile_intermediate_directory}/${generated_file_basename}$<$<BOOL:$>:.$>.cmake")
 
   # Setup properties for obj files:
   if( NOT cuda_compile_to_external_module )
@@ -1436,7 +1437,11 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
   endif()
 
   # Configure the build script
-  configure_file("${CUDA_run_nvcc}" "${custom_target_script}" @ONLY)
+  configure_file("${CUDA_run_nvcc}" "${custom_target_script_pregen}" @ONLY)
+  file(GENERATE
+OUTPUT "${custom_target_script}"
+INPUT "${custom_target_script_pregen}"
+)
 
   # So if a user specifies the same cuda file as input more than once, you
   # can have bad things happen with dependencies.  Here we check an option

---

Summary of changes:
 Modules/FindCUDA.cmake |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly

[Chuck Atkins]

If you know the full path to the library then I'd suggest using it as
/path/to/foo/libfoo.a (or .so if it's shared) instead of -L/path/to/foo
-lfoo.  CMake will adjust the flags to -L and -l if needed but the
preference is always to use the full library path.

- Chuck

On Mon, May 23, 2016 at 2:23 AM, Chaos Zhang <zcsd2...@gmail.com> wrote:

> Thanks a lot! `set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY}
> -Wl,--no-whole-archive")` worked when the content of ${FOO_LIBRARY} look
> like `-Ldir -llib`, if just use lib name as the content of ${FOO_LIBRARY},
> error while occur.
>
> Chuck Atkins wrote
> >> -rpath
> >
> >
> >  RPATHs are automatically added by CMake to executables so they can use
> > libraries from the build tree.
> >
> >
> >
> >> -whole-archive
> >>
> >
> > whole-archive is definitely trickier since you shouldn't be applying it
> to
> > the entire executable but instead wrapping individual libraries with it.
> > Conveniently, you can pass link options directly with
> > target_link_libraries.  So you could have:
> >
> > # Just an example, find_library calls should really be isolated to
> > separate
> > find modules
> > find_library(FOO_LIBRARY foo)
> > set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY}
> > -Wl,--no-whole-archive")
> >
> > add_executable(hello main.c)
> > target_link_libraries(hello ${FOO_LIBRARY})
> >
> >
> >>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
> >>
> >
> > CMAKE_EXE_LINKER_FLAGS should work for other more general cases that
> > aren't
> > tied to specific libraries.  The problem with your example is likely not
> > using an absolute path for -L since the compilation is actually taking
> > place in a nested work directory somewhere.
> >
> > --
> >
> > 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
>
>
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593518.html
> Sent from the CMake mailing list archive at Nabble.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:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly

[Chuck Atkins]

> -rpath


 RPATHs are automatically added by CMake to executables so they can use
libraries from the build tree.



> -whole-archive
>

whole-archive is definitely trickier since you shouldn't be applying it to
the entire executable but instead wrapping individual libraries with it.
Conveniently, you can pass link options directly with
target_link_libraries.  So you could have:

# Just an example, find_library calls should really be isolated to separate
find modules
find_library(FOO_LIBRARY foo)
set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} -Wl,--no-whole-archive")

add_executable(hello main.c)
target_link_libraries(hello ${FOO_LIBRARY})


>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
>

CMAKE_EXE_LINKER_FLAGS should work for other more general cases that aren't
tied to specific libraries.  The problem with your example is likely not
using an absolute path for -L since the compilation is actually taking
place in a nested work directory somewhere.
-- 

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] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly

[Chuck Atkins]

Is there a reason to not use target_link_libraries here? For the purposes
of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS.  What
are you actually trying to accomplish? Because there is almost certainly a
better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS.

- Chuck

On Fri, May 20, 2016 at 4:28 AM, Chaos Zhang  wrote:

> Hi, all,
>
> I try to use some gcc link option and libs(except libs link by
> target_link_libraries(...)), i researched and try to use
> 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below:
> in dir, there are 5 files:
>
> -hello.h
> -hello.c
> -main.c
> -hello.o
> -libhello.a
>
> hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained
> hello.o. And other 3 files content:
> 1.In hello.h:
>
> void hello();
>
> 2.In hello.c:
>
> #include
> void hello()
> {
> printf("hello\n");
> }
>
> 3.In main.c:
>
> #include "hello.h"
> void main()
> {
>hello();
> }
>
> When i used gcc -o main main.c libhello.a, the exe file: main generated,
> and
> it work well.
> Then i write a CMakeLists.txt, the content as below:
>
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
> add_executable(main main.c)
>
> When i cmake this project, an error occurred: main.c:undefined
> reference to 'hello'.
>
> Since i wil add a complicated link option and would not conflict with  libs
> link by target_link_libraries(...), i should figure out how to use
> 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some
> advices? :-)
>
> Thanks,
> Chao
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html
> Sent from the CMake mailing list archive at Nabble.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:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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] Error if CMAKE_SYSTEM_NAME is placed wrongly

[Chuck Atkins]

> when I place set(CMAKE_SYSTEM_NAME Generic) after cmake_minimum_required()
> and project() and set(VERSION_MAYOR/MINOR),
>

CMAKE_SYSTEM_NAME really shouldn't be in a CMakeLists.txt file at all.  It
should instead be in a stand alone toolchain file defining your various
cross-compiling requirements and then passed to cmake with
-DCMAKE_TOOLCHAIN_FILE=/path/to/Toolchain.cmake.  CMake has certain rules
for when the toolchain file get's loaded very early on and processed to
make sure that the subsequent processing of the CMakeLists.txt is done with
the appropriate platform and compiler information set.

- Chuck
-- 

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] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each?

[Chuck Atkins]

Hi TCW,

A typical approach for this is in the top level CMakeLists.txt to have:

include(CompilerFlags)

And then you can isolate the detection and specialization logic in a
separate CompilerFlags.cmake:

if(CMAKE_COMPILER_IS_GNUC)
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options")
elseif(CMAKE_C_COMPILER_ID MATCHES "Intel")
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options")
elseif(CMAKE_C_COMPILER_ID MATCHES "PGI)
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options")
elseif(MSVC)
  if(MSVC_VERSION GREATER_THAN 1700)
...
  elseif(...)
...
  endif()
endif()

And then similarly for C++.


- Chuck

On Tue, May 17, 2016 at 1:49 AM, TCW via CMake  wrote:

> Hello all,
>
> On linux, what's the correct way to support building with several
> different C compilers, each with some extra compiler-specifc flags for
> Debug and Release modes?  (Eventually I'll need to add Visual Studio on
> Windows too. )
>
> For now, I'm following what's mentioned in the cmake FAQ and using
> CXX=/blah cmake, etc.
>
> (From:
> https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F)
>
> But this is getting quite cumbersome as I'm experimenting with different
> flags for each compiler, and I'd rather avoid polluting my fairly clean
> CMakeLists file with a bunch of if/else branches to set flags.
>
> In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option,
> but this seems designed for embedded cross-compile scenarios.  (Is that
> right?)
>
> (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html)
>
> Basically, I'd like to succinctly choose among a set of (slightly)
> customized compiler choices.
>
> For modern cmake usage what is the correct method?  Can anybody point me
> to a well done example for a simple case like this?
>
> Thank you!
> tcw
>
> --
>
> 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
>
-- 

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-developers] [PATCH] cmFileCommand: sort list of files from glob command

[Chuck Atkins]

>
> I'd like to express my concerns about the proposed change. CMake strongly
> discourages using `file(GLOB)` to find source files, since file additions
> then do not automatically trigger a buildsystem regeneration.
>

I second this.  The intent of the patch is to address an issue that is only
present when using a practice explicitly not recommended in CMake
documentation:

https://cmake.org/cmake/help/v3.5/command/file.html
Note: We do not recommend using GLOB to collect a list of source files from
your source tree. If no CMakeLists.txt file changes when a source is added
or removed then the generated build system cannot know when to ask CMake to
regenerate.
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1359-g969ac90

[Chuck Atkins]

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, next has been updated
   via  969ac90d3805db87e32929de3305d1af5470aba6 (commit)
   via  fdfb0c064929786fa1d09670cc4569b22c7c22ca (commit)
  from  af395dc4c1196c6665c66ca690d656589c5d873a (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=969ac90d3805db87e32929de3305d1af5470aba6
commit 969ac90d3805db87e32929de3305d1af5470aba6
Merge: af395dc fdfb0c0
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu May 12 13:56:30 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu May 12 13:56:30 2016 -0400

Merge topic 'fix-hdf5-component-search' into next

fdfb0c06 HDF5: Rework component searching to correctly find HL for all 
bindings


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fdfb0c064929786fa1d09670cc4569b22c7c22ca
commit fdfb0c064929786fa1d09670cc4569b22c7c22ca
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu May 12 11:36:41 2016 -0400
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Thu May 12 13:54:58 2016 -0400

HDF5: Rework component searching to correctly find HL for all bindings

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 17a2aeb..f589977 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -46,24 +46,47 @@
 #
 # ::
 #
+#   HDF5_FOUND - true if HDF5 was found on the system
+#   HDF5_VERSION - HDF5 version in format Major.Minor.Release
 #   HDF5_INCLUDE_DIRS - Location of the hdf5 includes
 #   HDF5_INCLUDE_DIR - Location of the hdf5 includes (deprecated)
 #   HDF5_DEFINITIONS - Required compiler definitions for HDF5
-#   HDF5_C_LIBRARIES - Required libraries for the HDF5 C bindings.
+#   HDF5_LIBRARIES - Required libraries for all requested bindings
+#   HDF5_HL_LIBRARIES - Required libraries for the HDF5 high level API for all
+#   bindings, if the HL component is enabled
+#
+# Available components are: C CXX Fortran and HL.  For each enabled language
+# binding, a corresponding HDF5_${LANG}_LIBRARIES variable will be defined.
+# If the HL component is enabled, then an HDF5_${LANG}_HL_LIBRARIES will
+# also be defined.  With all components enabled, the following variables will 
be defined:
+#
+# ::
+#
+#   HDF5_C_LIBRARIES - Required libraries for the HDF5 C bindings
 #   HDF5_CXX_LIBRARIES - Required libraries for the HDF5 C++ bindings
 #   HDF5_Fortran_LIBRARIES - Required libraries for the HDF5 Fortran bindings
-#   HDF5_HL_LIBRARIES - Required libraries for the HDF5 high level API
+#   HDF5_C_HL_LIBRARIES - Required libraries for the high level C bindings
+#   HDF5_CXX_HL_LIBRARIES - Required libraries for the high level C++ bindings
 #   HDF5_Fortran_HL_LIBRARIES - Required libraries for the high level Fortran
 #   bindings.
-#   HDF5_LIBRARIES - Required libraries for all requested bindings
-#   HDF5_FOUND - true if HDF5 was found on the system
-#   HDF5_VERSION - HDF5 version in format Major.Minor.Release
-#   HDF5_LIBRARY_DIRS - the full set of library directories
+#
 #   HDF5_IS_PARALLEL - Whether or not HDF5 was found with parallel IO support
 #   HDF5_C_COMPILER_EXECUTABLE - the path to the HDF5 C wrapper compiler
 #   HDF5_CXX_COMPILER_EXECUTABLE - the path to the HDF5 C++ wrapper compiler
 #   HDF5_Fortran_COMPILER_EXECUTABLE - the path to the HDF5 Fortran wrapper 
compiler
+#   HDF5_C_COMPILER_EXECUTABLE_NO_INTERROGATE - path to the primary C compiler
+#   which is also the HDF5 wrapper
+#   HDF5_CXX_COMPILER_EXECUTABLE_NO_INTERROGATE - path to the primary C++
+# compiler which is also
+# the HDF5 wrapper
+#   HDF5_Fortran_COMPILER_EXECUTABLE_NO_INTERROGATE - path to the primary
+# Fortran compiler which
+# is also the HDF5 wrapper
 #   HDF5_DIFF_EXECUTABLE - the path to the HDF5 dataset comparison tool
+#
+# The following variable can be set to guide the search for HDF5 libraries and 
includes:
+#
+# HDF5_ROOT
 
 #=
 # Copyright 2015 Axel Huebl, Helmholtz-Zentrum Dresden - Rossendorf
@@ -85,28 +108,43 @@ 
include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 
 # List of the valid HDF5 components
-set( HDF5_VALID_COMPONENTS
-C
-CXX
-Fortr

Re: [CMake] [cmake-developers] [PATCH] FindBoost does not detect absence of header file

[Chuck Atkins]

I guess it doesn't really matter but for the libraries that don't have a
single include header, should you be using these instead:

   - container/container_fwd.hpp
   - exception/all.hpp
   - filesystem.hpp
   - math_fwd.hpp (instead of math/quaternion.hpp)
   - system/config.hpp
   - type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of specific
headers.

- Chuck

On Wed, May 11, 2016 at 10:38 AM,  wrote:

> On 2016-04-12 11:22, Joachim Wuttke wrote:
>
>> FindBoost does not detect absence of header files.
>>
>> To be specific: Run the following under cmake version 3.5.1:
>>
>> set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
>> set(Boost_USE_STATIC_LIBS OFF)
>> set(Boost_USE_MULTITHREADED ON)
>> set(Boost_USE_STATIC_RUNTIME OFF)
>> add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
>> #add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
>> auto-linked libraries
>> if(WIN32)
>> set(boost_libraries_required date_time chrono program_options zlib
>> bzip2 iostreams system filesystem regex thread)
>> else()
>> set(boost_libraries_required date_time chrono program_options
>> iostreams system filesystem regex thread)
>> endif()
>> find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} REQUIRED)
>> message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
>> message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
>> message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")
>>
>> It will pass, even if files like /usr/include/boost/date_time.hpp  are
>> removed
>> from the system.
>>
>
> Attached is a patch to add this extra checking.
>
> For each library component, there is a corresponding header which has been
> present in all versions of boost to date which provide the library; the
> list used to validate this is also attached.  I have also validated that
> each component works with find_package for Boost 1.58 and 1.60.
>
> If your system contains both the libraries and headers, then FindBoost
> will behave exactly as before.  But if you have the libraries without the
> headers, FindBoost will now fail, rather than passing and then having the
> build subsequently fail when it tries to use the nonexistent headers.  So
> it's essentially adding an additional header check per component, which
> will identify situations where the user has an incomplete Boost
> installation e.g. no all the -dev packages are installed.
>
> I can merge this into next for testing, but if anyone wanted to have an
> initial play with it to verify that it's still functional and that the
> approach is sound, I can wait off for now.
>
>
> Regards,
> Roger
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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-developers] [PATCH] FindBoost does not detect absence of header file

[Chuck Atkins]

I guess it doesn't really matter but for the libraries that don't have a
single include header, should you be using these instead:

   - container/container_fwd.hpp
   - exception/all.hpp
   - filesystem.hpp
   - math_fwd.hpp (instead of math/quaternion.hpp)
   - system/config.hpp
   - type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of specific
headers.

- Chuck

On Wed, May 11, 2016 at 10:38 AM,  wrote:

> On 2016-04-12 11:22, Joachim Wuttke wrote:
>
>> FindBoost does not detect absence of header files.
>>
>> To be specific: Run the following under cmake version 3.5.1:
>>
>> set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
>> set(Boost_USE_STATIC_LIBS OFF)
>> set(Boost_USE_MULTITHREADED ON)
>> set(Boost_USE_STATIC_RUNTIME OFF)
>> add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
>> #add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
>> auto-linked libraries
>> if(WIN32)
>> set(boost_libraries_required date_time chrono program_options zlib
>> bzip2 iostreams system filesystem regex thread)
>> else()
>> set(boost_libraries_required date_time chrono program_options
>> iostreams system filesystem regex thread)
>> endif()
>> find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} REQUIRED)
>> message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
>> message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
>> message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")
>>
>> It will pass, even if files like /usr/include/boost/date_time.hpp  are
>> removed
>> from the system.
>>
>
> Attached is a patch to add this extra checking.
>
> For each library component, there is a corresponding header which has been
> present in all versions of boost to date which provide the library; the
> list used to validate this is also attached.  I have also validated that
> each component works with find_package for Boost 1.58 and 1.60.
>
> If your system contains both the libraries and headers, then FindBoost
> will behave exactly as before.  But if you have the libraries without the
> headers, FindBoost will now fail, rather than passing and then having the
> build subsequently fail when it tries to use the nonexistent headers.  So
> it's essentially adding an additional header check per component, which
> will identify situations where the user has an incomplete Boost
> installation e.g. no all the -dev packages are installed.
>
> I can merge this into next for testing, but if anyone wanted to have an
> initial play with it to verify that it's still functional and that the
> approach is sound, I can wait off for now.
>
>
> Regards,
> Roger
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1297-gd1ea20a

[Chuck Atkins]

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, next has been updated
   via  d1ea20a5782ac72f5d4616360d73e51cf3958dd2 (commit)
   via  00405af0f17efd550a99de605867a86e746b5004 (commit)
  from  943d8b478ce9d313420f219544ea7600f6cd60ae (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=d1ea20a5782ac72f5d4616360d73e51cf3958dd2
commit d1ea20a5782ac72f5d4616360d73e51cf3958dd2
Merge: 943d8b4 00405af
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon May 9 10:21:59 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon May 9 10:21:59 2016 -0400

Merge topic 'fix-hdf5-for-compiler-wrapers' into next

00405af0 HDF5: Refactor the use of compiler wrappers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00405af0f17efd550a99de605867a86e746b5004
commit 00405af0f17efd550a99de605867a86e746b5004
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Apr 4 15:09:00 2016 -0600
Commit: Chuck Atkins <chuck.atk...@kitware.com>
CommitDate: Mon May 9 10:20:39 2016 -0400

HDF5: Refactor the use of compiler wrappers

 * Make work with HDF5 compiler wrappers as the primary compiler (Cray)
 * Accept options used by compiler wrappers instead of just seeding
   search parameters
 * Only search for libraries if the first 2 fail

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 9f6e666..a129671 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -120,54 +120,137 @@ else()
   set(HDF5_Fortran_COMPILER_NAMES h5fc h5pfc)
 endif()
 
-# try to find the HDF5 wrapper compilers
-find_program( HDF5_C_COMPILER_EXECUTABLE
-NAMES ${HDF5_C_COMPILER_NAMES} NAMES_PER_DIR
-HINTS ENV HDF5_ROOT
-PATH_SUFFIXES bin Bin
-DOC "HDF5 Wrapper compiler.  Used only to detect HDF5 compile flags." )
-mark_as_advanced( HDF5_C_COMPILER_EXECUTABLE )
-
-find_program( HDF5_CXX_COMPILER_EXECUTABLE
-NAMES ${HDF5_CXX_COMPILER_NAMES} NAMES_PER_DIR
-HINTS ENV HDF5_ROOT
-PATH_SUFFIXES bin Bin
-DOC "HDF5 C++ Wrapper compiler.  Used only to detect HDF5 compile flags." )
-mark_as_advanced( HDF5_CXX_COMPILER_EXECUTABLE )
-
-find_program( HDF5_Fortran_COMPILER_EXECUTABLE
-NAMES ${HDF5_Fortran_COMPILER_NAMES} NAMES_PER_DIR
-HINTS ENV HDF5_ROOT
-PATH_SUFFIXES bin Bin
-DOC "HDF5 Fortran Wrapper compiler.  Used only to detect HDF5 compile 
flags." )
-mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
+# We may have picked up some duplicates in various lists during the above
+# process for the language bindings (both the C and C++ bindings depend on
+# libz for example).  Remove the duplicates. It appears that the default
+# CMake behavior is to remove duplicates from the end of a list. However,
+# for link lines, this is incorrect since unresolved symbols are searched
+# for down the link line. Therefore, we reverse the list, remove the
+# duplicates, and then reverse it again to get the duplicates removed from
+# the beginning.
+macro(_HDF5_remove_duplicates_from_beginning _list_name)
+  if(${_list_name})
+list(REVERSE ${_list_name})
+list(REMOVE_DUPLICATES ${_list_name})
+list(REVERSE ${_list_name})
+  endif()
+endmacro()
 
-unset(HDF5_C_COMPILER_NAMES)
-unset(HDF5_CXX_COMPILER_NAMES)
-unset(HDF5_Fortran_COMPILER_NAMES)
 
-find_program( HDF5_DIFF_EXECUTABLE
-NAMES h5diff
-HINTS ENV HDF5_ROOT
-PATH_SUFFIXES bin Bin
-DOC "HDF5 file differencing tool." )
-mark_as_advanced( HDF5_DIFF_EXECUTABLE )
+# Test first if the current compilers automatically wrap HDF5
+
+function(_HDF5_test_regular_compiler_C success version)
+  set(scratch_directory
+${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/hdf5)
+  if(NOT ${success} OR
+ NOT EXISTS ${scratch_directory}/compiler_has_h5_c)
+set(test_file ${scratch_directory}/cmake_hdf5_test.c)
+file(WRITE ${test_file}
+  "#include \n"
+  "#include \n"
+  "int main(void) {\n"
+  "  char const* info_ver = \"INFO\" \":\" H5_VERSION;\n"
+  "  hid_t fid;\n"
+  "  fid = H5Fcreate(\"foo.h5\",H5F_ACC_TRUNC,H5P_DEFAULT,H5P_DEFAULT);\n"
+  "  return 0;\n"
+  "}")
+try_compile(${success} ${scratch_directory} ${test_file}
+  COPY_FILE ${scratch_directory}/compiler_has_h5_c
+)
+  endif()
+  if(${success})
+file(STRINGS ${scratch_directory}/compiler_has_h5_c INFO_VER
+  REGEX "^INFO:([0-9]+\\.[0-9]+\\.[0-9]+)(-patch([0-9]+))?&quo