From paul at mad-scientist.net  Mon Jan  1 18:12:24 2018
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 01 Jan 2018 18:12:24 -0500
Subject: [CMake] Can I build targets during all but NOT during install?
Message-ID: <1514848344.2717.604.camel@mad-scientist.net>

I have (what I thought was) a common environment where my build creates
both programs to be installed and also test programs etc. that aren't
installed.

What I hoped is for the default build with no targets specified to
build everything ("all"), but if I invoke the build with the "install"
target it builds only the things that are to be installed, not the test
programs.

Unfortunately it doesn't seem like this is possible; at least when I
examine the Makefiles generated by the CMake Unix Makefiles generator,
the install target depends on the preinstall target which depends on
all.  Is this true in general or is there something in my CMake setup
that causes it?

I find this very limiting: it seems clear to me that a default "all"
build might create all sort of other things that aren't installed via
the "install" target... I should be able to build "install" to only
build those things not "all" the things.

Any ideas for this?

From robert.maynard at kitware.com  Tue Jan  2 10:00:22 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 2 Jan 2018 10:00:22 -0500
Subject: [CMake] how to find CUDA libraries under new CUDA framework?
In-Reply-To: <CAO65DGd9=t4MEWWohko4WO2uSJgsRt5NUaBoDV3=ZV2z571dmg@mail.gmail.com>
References: <CAO65DGd9=t4MEWWohko4WO2uSJgsRt5NUaBoDV3=ZV2z571dmg@mail.gmail.com>
Message-ID: <CAFzjYVqMDpgZmDJ0wEfjvxknNYNb4tz8UzbX-K=-wuLm4M1nuw@mail.gmail.com>

I would start by looking at the contents of
CMAKE_CUDA_IMPLICIT_LINK_LIBRARIES and
CMAKE_CUDA_HOST_IMPLICIT_LINK_LIBRARIES

On Sat, Dec 30, 2017 at 12:29 PM, Crni Gorac <cgorac at gmail.com> wrote:
> The FindCUDA.cmake module would put list of CUDA libraries found into
> corresponding CMake variables.  Is there any variable with new
> "project(... LANGUAGES ... CUDA)" framework to do the same (I wasn't
> able to find it)?
>
> Basically, what I want to do is to have an option to install all
> dependencies of my project along with the project deliverables.  Thus
> libcudart_static.a is to be installed too. I can find it using
> find_library(), but am wondering is there a better way.
>
> Thanks.
> --
>
> 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

From franck.houssen at inria.fr  Wed Jan  3 04:08:09 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Wed, 3 Jan 2018 10:08:09 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <1947305018.13130093.1514970089067.JavaMail.zimbra@inria.fr>
Message-ID: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>

Hello, 

How to ask cmake to add a library path (coming from pc file) to rpath ? 

I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not working. Can somebody help ? 

>> more main.cpp 
#include <petsc.h> 

int main(int argc, char ** argv) { 
PetscInitialize(&argc, &argv, NULL, ""); 
PetscFinalize(); 
return 0; 
} 

>> more CMakeLists.txt 
cmake_minimum_required(VERSION 3.7) 
enable_language(CXX) 

find_package(MPI REQUIRED) 
find_package(PkgConfig REQUIRED) # Get pkg_check_modules. 
pkg_check_modules(PETSc REQUIRED PETSc) 

project(main) 
add_executable(main main.cpp) 

target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH}) 
target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES}) 

target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS}) 
foreach(lib ${PETSc_LDFLAGS}) 
target_link_libraries(main PUBLIC ${lib}) 
endforeach(lib) 

foreach(dir ${PETSc_LIBRARY_DIRS}) 
link_directories(main PUBLIC ${dir}) # Not sure: is this needed ? 
endforeach(dir) 
# use, i.e. don't skip the full RPATH for the build tree 
SET(CMAKE_SKIP_BUILD_RPATH FALSE) 
# when building, don't use the install RPATH already 
# (but later on when installing) 
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE) 
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib") 
# add the automatically determined parts of the RPATH 
# which point to directories outside the build tree to the install RPATH 
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) 
# the RPATH to be used when installing, but only if it's not a system directory 
LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir) 
IF("${isSystemDir}" STREQUAL "-1") 
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib") 
ENDIF("${isSystemDir}" STREQUAL "-1") 

include(CTest) 
enable_testing() 
add_test(NAME main COMMAND "mpirun -n 2 ./main" WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}") 

Now, 

>> export PKG_CONFIG_PATH="/path/to/petsc/local/lib/pkgconfig" 
>> cmake ..; make => OK 

But 

>> ldd main 
linux-vdso.so.1 (0x00007ffcf23ca000) 
libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20 (0x00007f68593ea000) 
libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f68590f4000) 
libpetsc.so.3.8 => not found 

and so, make test fails ?!... 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180103/462abf58/attachment.html>

From geogin at gmail.com  Wed Jan  3 13:46:19 2018
From: geogin at gmail.com (Geogin Varghese)
Date: Wed, 3 Jan 2018 19:46:19 +0100
Subject: [CMake] modularizing, specifying dependencies in a project
Message-ID: <CAC4=85+dCcN1zY92ra8_QKx6BR07sYSQ8yPMMEZaeii+tihtsQ@mail.gmail.com>

Hello,

Recently came across these presentations on cmake:

Using Modern CMake Patterns to Enforce a Good Modular Design
(https://www.youtube.com/watch?v=bsXLMQ6WgIk)
Effective CMake
(https://www.youtube.com/watch?v=eC9-iRN2b04)

They encourage using target_* command variants for scripting
CMakeLists.txt.

What would be the recommended way of writing build scripts for a
repository structured as below. The application is compiled from three
modules with a dependency among the modules as in the ascii diagram.

Is it possible to distribute compile info, such that each submodule has
a CMakeLists.txt that describes sources, include and link dependencies needed
to compile that module.

---------------------------------------
.
??? main.cpp
??? ModA
??? ModB
??? ModC

Dependency relation:
--------------------
       +--------+
    +->+main.cpp+<-+
    |  +--------+  |
    |              |
    |              |
    |              |
  +----+        +----+
  |ModA|        |ModB|
  +----+        +----+
    ^              ^
    |              |
    |    +----+    |
    +----+ModC+----+
         +----+

ModA <- ModC: Module A
 depends on Module C
---------------------------------------

My naive effort to do this can be found here:
https://github.com/vargheseg/test

The problem I run into is with describing the dependency relation
between ModA, ModB and ModC.

Details:
.
??? CMakeLists.txt
??? main.cpp
??? ModA
?   ??? a.cpp
?   ??? CMakeLists.txt
??? ModB
?   ??? b.cpp
?   ??? CMakeLists.txt
??? ModC
?   ??? c.cpp
?   ??? CMakeLists.txt

- CMakeLists.txt in the child directories describe compilation
  information for that directory.
- The top level directory includes the CMakeLists.txt from
  subdirectories.
- Cmake buildfile generation fails because the way I set things up; the
  top level CMakeLists.txt ends up including ModC/CMakeLists.txt twice.

---
CMakeLists.txt
---
 cmake_minimum_required(VERSION 3.0)
 project(test_project)

 include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
 include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)

 add_executable(main main.cpp)
 target_link_libraries(main PRIVATE ModA ModB)


---
ModA/CMakeLists.txt
---
 include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
 add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
 target_link_libraries(ModA PRIVATE ModC)


---
ModB/CMakeLists.txt
---
 include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
 add_library(ModB b.cpp)
 target_link_libraries(ModB
         PRIVATE
         ModC)

Is this way of structuring a project a supported use case?

From robert.maynard at kitware.com  Wed Jan  3 14:16:41 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 3 Jan 2018 14:16:41 -0500
Subject: [CMake] modularizing, specifying dependencies in a project
In-Reply-To: <CAC4=85+dCcN1zY92ra8_QKx6BR07sYSQ8yPMMEZaeii+tihtsQ@mail.gmail.com>
References: <CAC4=85+dCcN1zY92ra8_QKx6BR07sYSQ8yPMMEZaeii+tihtsQ@mail.gmail.com>
Message-ID: <CAFzjYVqN7dgi0V+dGd=ntFjbyVVEyRPDdFRGqDdoAhATJFb7uQ@mail.gmail.com>

You will want to use add_subdirectory instead of include in the root
CMakeLists.txt and remove all include statements from ModA and ModB

It total the changes needed to get everything to work are:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index e611a37..b6968c1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,8 +1,9 @@
 cmake_minimum_required(VERSION 3.0)
 project(test_project)

-include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
-include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
+add_subdirectory(ModA)
+add_subdirectory(ModB)
+add_subdirectory(ModC)

 add_executable(main main.cpp)
 target_link_libraries(main
diff --git a/ModA/CMakeLists.txt b/ModA/CMakeLists.txt
index 87128d8..4931be6 100644
--- a/ModA/CMakeLists.txt
+++ b/ModA/CMakeLists.txt
@@ -1,5 +1,4 @@
-include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
-add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
+add_library(ModA a.cpp)
 target_link_libraries(ModA
        PRIVATE
          ModC)
diff --git a/ModB/CMakeLists.txt b/ModB/CMakeLists.txt
index 3a31be9..7f83856 100644
--- a/ModB/CMakeLists.txt
+++ b/ModB/CMakeLists.txt
@@ -1,4 +1,3 @@
-include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)

 add_library(ModB b.cpp)
 target_link_libraries(ModB

On Wed, Jan 3, 2018 at 1:46 PM, Geogin Varghese <geogin at gmail.com> wrote:
> Hello,
>
> Recently came across these presentations on cmake:
>
> Using Modern CMake Patterns to Enforce a Good Modular Design
> (https://www.youtube.com/watch?v=bsXLMQ6WgIk)
> Effective CMake
> (https://www.youtube.com/watch?v=eC9-iRN2b04)
>
> They encourage using target_* command variants for scripting
> CMakeLists.txt.
>
> What would be the recommended way of writing build scripts for a
> repository structured as below. The application is compiled from three
> modules with a dependency among the modules as in the ascii diagram.
>
> Is it possible to distribute compile info, such that each submodule has
> a CMakeLists.txt that describes sources, include and link dependencies needed
> to compile that module.
>
> ---------------------------------------
> .
> ??? main.cpp
> ??? ModA
> ??? ModB
> ??? ModC
>
> Dependency relation:
> --------------------
>        +--------+
>     +->+main.cpp+<-+
>     |  +--------+  |
>     |              |
>     |              |
>     |              |
>   +----+        +----+
>   |ModA|        |ModB|
>   +----+        +----+
>     ^              ^
>     |              |
>     |    +----+    |
>     +----+ModC+----+
>          +----+
>
> ModA <- ModC: Module A
>  depends on Module C
> ---------------------------------------
>
> My naive effort to do this can be found here:
> https://github.com/vargheseg/test
>
> The problem I run into is with describing the dependency relation
> between ModA, ModB and ModC.
>
> Details:
> .
> ??? CMakeLists.txt
> ??? main.cpp
> ??? ModA
> ?   ??? a.cpp
> ?   ??? CMakeLists.txt
> ??? ModB
> ?   ??? b.cpp
> ?   ??? CMakeLists.txt
> ??? ModC
> ?   ??? c.cpp
> ?   ??? CMakeLists.txt
>
> - CMakeLists.txt in the child directories describe compilation
>   information for that directory.
> - The top level directory includes the CMakeLists.txt from
>   subdirectories.
> - Cmake buildfile generation fails because the way I set things up; the
>   top level CMakeLists.txt ends up including ModC/CMakeLists.txt twice.
>
> ---
> CMakeLists.txt
> ---
>  cmake_minimum_required(VERSION 3.0)
>  project(test_project)
>
>  include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
>  include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
>
>  add_executable(main main.cpp)
>  target_link_libraries(main PRIVATE ModA ModB)
>
>
> ---
> ModA/CMakeLists.txt
> ---
>  include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>  add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
>  target_link_libraries(ModA PRIVATE ModC)
>
>
> ---
> ModB/CMakeLists.txt
> ---
>  include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>  add_library(ModB b.cpp)
>  target_link_libraries(ModB
>          PRIVATE
>          ModC)
>
> Is this way of structuring a project a supported use case?
> --
>
> 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

From a.neundorf-work at gmx.net  Wed Jan  3 15:35:02 2018
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Wed, 03 Jan 2018 21:35:02 +0100
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
Message-ID: <3575224.lCVmBBQUTJ@linux-l7nd>

On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> Hello,
> 
> How to ask cmake to add a library path (coming from pc file) to rpath ?
> 
> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
> working. Can somebody help ?
> >> more main.cpp
> 
> #include <petsc.h>
> 
> int main(int argc, char ** argv) {
> PetscInitialize(&argc, &argv, NULL, "");
> PetscFinalize();
> return 0;
> }
> 
> >> more CMakeLists.txt
> 
> cmake_minimum_required(VERSION 3.7)
> enable_language(CXX)
> 
> find_package(MPI REQUIRED)
> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> pkg_check_modules(PETSc REQUIRED PETSc)
> 
> project(main)
> add_executable(main main.cpp)
> 
> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> 
> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> foreach(lib ${PETSc_LDFLAGS})
> target_link_libraries(main PUBLIC ${lib})
> endforeach(lib)

How does each ${lib} look like ?
Is it "-lpetsc" or does it have the full path to the libraries ?
You should use the full path to the libraries, otherwise cmake doesn't know 
where they are and the RPATH computation will not work.

> 
> foreach(dir ${PETSc_LIBRARY_DIRS})
> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> endforeach(dir)

no, link_directories() in general should not be used.

> # use, i.e. don't skip the full RPATH for the build tree
> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> # when building, don't use the install RPATH already
> # (but later on when installing)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

If the automatic computation fails, you could add the petsc lib dir here as 
INSTALL_RPATH

Alex


From Andreas-Naumann at gmx.net  Wed Jan  3 15:41:51 2018
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Wed, 3 Jan 2018 21:41:51 +0100
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <3575224.lCVmBBQUTJ@linux-l7nd>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
Message-ID: <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>

What about using a FindPETSC-Module? Some hints are
     *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
     *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake

Regards,
Andreas

Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
>> Hello,
>>
>> How to ask cmake to add a library path (coming from pc file) to rpath ?
>>
>> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
>> working. Can somebody help ?
>>>> more main.cpp
>> #include <petsc.h>
>>
>> int main(int argc, char ** argv) {
>> PetscInitialize(&argc, &argv, NULL, "");
>> PetscFinalize();
>> return 0;
>> }
>>
>>>> more CMakeLists.txt
>> cmake_minimum_required(VERSION 3.7)
>> enable_language(CXX)
>>
>> find_package(MPI REQUIRED)
>> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
>> pkg_check_modules(PETSc REQUIRED PETSc)
>>
>> project(main)
>> add_executable(main main.cpp)
>>
>> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
>> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>>
>> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
>> foreach(lib ${PETSc_LDFLAGS})
>> target_link_libraries(main PUBLIC ${lib})
>> endforeach(lib)
> How does each ${lib} look like ?
> Is it "-lpetsc" or does it have the full path to the libraries ?
> You should use the full path to the libraries, otherwise cmake doesn't know
> where they are and the RPATH computation will not work.
>
>> foreach(dir ${PETSc_LIBRARY_DIRS})
>> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>> endforeach(dir)
> no, link_directories() in general should not be used.
>
>> # use, i.e. don't skip the full RPATH for the build tree
>> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
>> # when building, don't use the install RPATH already
>> # (but later on when installing)
>> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> If the automatic computation fails, you could add the petsc lib dir here as
> INSTALL_RPATH
>
> Alex
>


From sam.lunt at transmarketgroup.com  Wed Jan  3 16:40:58 2018
From: sam.lunt at transmarketgroup.com (Sam Lunt)
Date: Wed, 3 Jan 2018 15:40:58 -0600
Subject: [CMake] CPack per-component value for
 CPACK_PACKAGING_INSTALL_PREFIX when using RPM generator
Message-ID: <CADjN2kdKd41YAYy=JH=WtAkAFwsLoiXQnZ5Fmzz3nzC80bTopw@mail.gmail.com>

I am trying to set a per-component value for
CPACK_PACKAGING_INSTALL_PREFIX when using the RPM generator, but I
haven't been able to do so.

I would like to be able to:
1. Install using "make install" (or cmake --build ${BUILD_DIR}
--target install) and have CMAKE_INSTALL_PREFIX control the install
location
2. Generate an rpm file for each component such that the rpm is
relocatable (i.e. --prefix and --relocate are supported) and each
component has a different default installation location

The documentation for CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX seems to
indicate that it is the correct way to set a per-component install
prefix, since it says that CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX "May
be used to set per component CPACK_PACKAGING_INSTALL_PREFIX for
relocatable RPM packages." However, I am only able to successfully use
this if I provide an absolute path to the install command, but that
inhibits the use of CMAKE_INSTALL_PREFIX.

Here is a minimal example that illustrates the problem:

## start CMakeLists.txt
cmake_minimum_required(VERSION 3.8)

project(FooBar
    VERSION 0.1.0
)

add_executable(foo foo.cpp)
add_executable(bar bar.cpp)

include(GNUInstallDirs)
install(TARGETS foo
    DESTINATION "${CMAKE_INSTALL_BINDIR}"
    COMPONENT Foo_Comp
)

install(TARGETS bar
    DESTINATION "${CMAKE_INSTALL_BINDIR}"
    COMPONENT Bar_Comp
)

set(CPACK_PACKAGE_VERSION_MAJOR ${FooBar_VERSION_MAJOR})
set(CPACK_PACKAGE_VERSION_MINOR ${FooBar_VERSION_MINOR})
set(CPACK_PACKAGE_VERSION_PATCH ${FooBar_VERSION_PATCH})

set(CPACK_PACKAGE_RELOCATABLE ON)
set(CPACK_PACKAGING_INSTALL_PREFIX "/tmp_dir/foobar")

set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_RPM_FOO_COMP_PACKAGE_PREFIX "/tmp_dir/foo")
set(CPACK_RPM_BAR_COMP_PACKAGE_PREFIX "/tmp_dir/bar")

include(CPack)
## end CMakeLists.txt

When the command "cmake ${SOURCE_DIR} -G "Unix Makefiles" && cmake
--build . && cpack -G RPM", the call to cpack generates the warnings:

CMake Warning (dev) at /usr/share/cmake/CPackRPM.cmake:999 (message):
  CPackRPM:Warning: Path /tmp_dir/foobar/bin/bar is not on one of the
  relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/CPackRPM.cmake:1841
(cpack_rpm_prepare_relocation_paths)
  /usr/share/cmake/Modules/CPackRPM.cmake:2690 (cpack_rpm_generate_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CPackRPM: Will use GENERATED spec file:
/var/tmp/test_pack_prefix/build/_CPack_Packages/Linux/RPM/SPECS/foobar-Bar_Comp.spec
CMake Warning (dev) at /usr/share/cmake/Modules/CPackRPM.cmake:999 (message):
  CPackRPM:Warning: Path /tmp_dir/foobar/bin/foo is not on one of the
  relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/CPackRPM.cmake:1841
(cpack_rpm_prepare_relocation_paths)
  /usr/share/cmake/Modules/CPackRPM.cmake:2690 (cpack_rpm_generate_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CPackRPM: Will use GENERATED spec file:
/var/tmp/test_pack_prefix/build/_CPack_Packages/Linux/RPM/SPECS/foobar-Foo_Comp.spec

The rpm installs the files to CPACK_PACKAGING_INSTALL_PREFIX if I
remove these lines (which prevents a per-component install location):
set(CPACK_RPM_FOO_COMP_PACKAGE_PREFIX "/tmp_dir/foo")
set(CPACK_RPM_BAR_COMP_PACKAGE_PREFIX "/tmp_dir/bar")

I can also prevent the warning by changing the install commands (but
then CMAKE_INSTALL_PREFIX is useless):
install(TARGETS foo
    DESTINATION "/tmp_dir/foo/${CMAKE_INSTALL_BINDIR}"
    COMPONENT Foo_Comp
)

install(TARGETS bar
    DESTINATION "/tmp_dir/bar/${CMAKE_INSTALL_BINDIR}"
    COMPONENT Bar_Comp
)

Is there any way to do what I'm trying to?

From geogin at gmail.com  Wed Jan  3 17:45:25 2018
From: geogin at gmail.com (Geogin Varghese)
Date: Wed, 3 Jan 2018 23:45:25 +0100
Subject: [CMake] modularizing, specifying dependencies in a project
Message-ID: <CAC4=85K-qZ4cKkUmgujKuSSRzUExA9+yQ5W1yrR13aKaD0GG-Q@mail.gmail.com>

This works.

Have pushed changes to the repo here:
https://github.com/vargheseg/test

Thank you

On Wed, Jan 3, 2018 at 8:16 PM, Robert Maynard
<robert.maynard at kitware.com> wrote:
> You will want to use add_subdirectory instead of include in the root
> CMakeLists.txt and remove all include statements from ModA and ModB
>
> It total the changes needed to get everything to work are:
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index e611a37..b6968c1 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -1,8 +1,9 @@
>  cmake_minimum_required(VERSION 3.0)
>  project(test_project)
>
> -include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
> -include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
> +add_subdirectory(ModA)
> +add_subdirectory(ModB)
> +add_subdirectory(ModC)
>
>  add_executable(main main.cpp)
>  target_link_libraries(main
> diff --git a/ModA/CMakeLists.txt b/ModA/CMakeLists.txt
> index 87128d8..4931be6 100644
> --- a/ModA/CMakeLists.txt
> +++ b/ModA/CMakeLists.txt
> @@ -1,5 +1,4 @@
> -include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
> -add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
> +add_library(ModA a.cpp)
>  target_link_libraries(ModA
>         PRIVATE
>           ModC)
> diff --git a/ModB/CMakeLists.txt b/ModB/CMakeLists.txt
> index 3a31be9..7f83856 100644
> --- a/ModB/CMakeLists.txt
> +++ b/ModB/CMakeLists.txt
> @@ -1,4 +1,3 @@
> -include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>
>  add_library(ModB b.cpp)
>  target_link_libraries(ModB
>
> On Wed, Jan 3, 2018 at 1:46 PM, Geogin Varghese <geogin at gmail.com> wrote:
>> Hello,
>>
>> Recently came across these presentations on cmake:
>>
>> Using Modern CMake Patterns to Enforce a Good Modular Design
>> (https://www.youtube.com/watch?v=bsXLMQ6WgIk)
>> Effective CMake
>> (https://www.youtube.com/watch?v=eC9-iRN2b04)
>>
>> They encourage using target_* command variants for scripting
>> CMakeLists.txt.
>>
>> What would be the recommended way of writing build scripts for a
>> repository structured as below. The application is compiled from three
>> modules with a dependency among the modules as in the ascii diagram.
>>
>> Is it possible to distribute compile info, such that each submodule has
>> a CMakeLists.txt that describes sources, include and link dependencies needed
>> to compile that module.
>>
>> ---------------------------------------
>> .
>> ??? main.cpp
>> ??? ModA
>> ??? ModB
>> ??? ModC
>>
>> Dependency relation:
>> --------------------
>>        +--------+
>>     +->+main.cpp+<-+
>>     |  +--------+  |
>>     |              |
>>     |              |
>>     |              |
>>   +----+        +----+
>>   |ModA|        |ModB|
>>   +----+        +----+
>>     ^              ^
>>     |              |
>>     |    +----+    |
>>     +----+ModC+----+
>>          +----+
>>
>> ModA <- ModC: Module A
>>  depends on Module C
>> ---------------------------------------
>>
>> My naive effort to do this can be found here:
>> https://github.com/vargheseg/test
>>
>> The problem I run into is with describing the dependency relation
>> between ModA, ModB and ModC.
>>
>> Details:
>> .
>> ??? CMakeLists.txt
>> ??? main.cpp
>> ??? ModA
>> ?   ??? a.cpp
>> ?   ??? CMakeLists.txt
>> ??? ModB
>> ?   ??? b.cpp
>> ?   ??? CMakeLists.txt
>> ??? ModC
>> ?   ??? c.cpp
>> ?   ??? CMakeLists.txt
>>
>> - CMakeLists.txt in the child directories describe compilation
>>   information for that directory.
>> - The top level directory includes the CMakeLists.txt from
>>   subdirectories.
>> - Cmake buildfile generation fails because the way I set things up; the
>>   top level CMakeLists.txt ends up including ModC/CMakeLists.txt twice.
>>
>> ---
>> CMakeLists.txt
>> ---
>>  cmake_minimum_required(VERSION 3.0)
>>  project(test_project)
>>
>>  include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
>>  include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
>>
>>  add_executable(main main.cpp)
>>  target_link_libraries(main PRIVATE ModA ModB)
>>
>>
>> ---
>> ModA/CMakeLists.txt
>> ---
>>  include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>>  add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
>>  target_link_libraries(ModA PRIVATE ModC)
>>
>>
>> ---
>> ModB/CMakeLists.txt
>> ---
>>  include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>>  add_library(ModB b.cpp)
>>  target_link_libraries(ModB
>>          PRIVATE
>>          ModC)
>>
>> Is this way of structuring a project a supported use case?
>> --
>>
>> 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

From davemilter at gmail.com  Wed Jan  3 21:09:54 2018
From: davemilter at gmail.com (Dave Milter)
Date: Thu, 4 Jan 2018 05:09:54 +0300
Subject: [CMake] coding style for modules
Message-ID: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>

Hello,

If there is some libfoo that I want to use in my project,
and this libfoo has it's own CMakeLists.txt I have 3 options to deal
with such external dependency:

a) Treat it like every other external dependency and write cmake code
  like FindLibFoo.cmake to find libfoo on file system.

b)Include this project as git submodule and use ExternalProject to
invoke `cmake` and `cmake --build`

c)Include this project as git submodule and use add_subdirectory(libfoo)


Variant "c" has advantages that potentially in this case it is
possible to have almost the same compiler flags for libfoo and main
project, which may give the most
robust solution in case of usage visual studio (release/debug/multi
thread/single thread CRT problems), plus it is simplify a lot cross
compilation.

But usually "libfoo" CMakeLists.txt looks like this:

```
cmake_minimum_required(VERSION 3.10)

#configure many things that important for standalone
#project, but not requires for project as part of another project
#for example in case of gcc we add some special flags like -Wall
-Wextra -pedantic and so on

add_library(foo SHARED sources)
```

and part between `cmake_minimum_required` and `add_library` is useless
and sometime prevent cross compilation and usage of the same compiler flags.

So question how should I organize CMakeListst.txt of libfoo help deals with "c"?

Should I move all specific for standalone project code to:

if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
# i am standalone
endif()

or may be I should use some other tricks?

From hintonda at gmail.com  Thu Jan  4 01:48:47 2018
From: hintonda at gmail.com (Don Hinton)
Date: Wed, 3 Jan 2018 22:48:47 -0800
Subject: [CMake] coding style for modules
In-Reply-To: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
References: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
Message-ID: <CAL2T-v6L5EpAjODw8KjhyMv6+gK=v7ZXBKOALSeutXCp=LM9CA@mail.gmail.com>

I normally see it like this:

if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
  project(foo)
# ...
endif()

hth...
don

On Wed, Jan 3, 2018 at 6:09 PM, Dave Milter <davemilter at gmail.com> wrote:

> Hello,
>
> If there is some libfoo that I want to use in my project,
> and this libfoo has it's own CMakeLists.txt I have 3 options to deal
> with such external dependency:
>
> a) Treat it like every other external dependency and write cmake code
>   like FindLibFoo.cmake to find libfoo on file system.
>
> b)Include this project as git submodule and use ExternalProject to
> invoke `cmake` and `cmake --build`
>
> c)Include this project as git submodule and use add_subdirectory(libfoo)
>
>
> Variant "c" has advantages that potentially in this case it is
> possible to have almost the same compiler flags for libfoo and main
> project, which may give the most
> robust solution in case of usage visual studio (release/debug/multi
> thread/single thread CRT problems), plus it is simplify a lot cross
> compilation.
>
> But usually "libfoo" CMakeLists.txt looks like this:
>
> ```
> cmake_minimum_required(VERSION 3.10)
>
> #configure many things that important for standalone
> #project, but not requires for project as part of another project
> #for example in case of gcc we add some special flags like -Wall
> -Wextra -pedantic and so on
>
> add_library(foo SHARED sources)
> ```
>
> and part between `cmake_minimum_required` and `add_library` is useless
> and sometime prevent cross compilation and usage of the same compiler
> flags.
>
> So question how should I organize CMakeListst.txt of libfoo help deals
> with "c"?
>
> Should I move all specific for standalone project code to:
>
> if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
> # i am standalone
> endif()
>
> or may be I should use some other tricks?
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180103/470d10fa/attachment.html>

From irwin at beluga.phys.uvic.ca  Thu Jan  4 02:02:20 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Wed, 3 Jan 2018 23:02:20 -0800 (PST)
Subject: [CMake] coding style for modules
In-Reply-To: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
References: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1801032231330.18536@enira.zlyna.ubzr>

On 2018-01-04 05:09+0300 Dave Milter wrote:

> Hello,
>
> If there is some libfoo that I want to use in my project,
> and this libfoo has it's own CMakeLists.txt I have 3 options to deal
> with such external dependency:
>
> a) Treat it like every other external dependency and write cmake code
>  like FindLibFoo.cmake to find libfoo on file system.
>
> b)Include this project as git submodule and use ExternalProject to
> invoke `cmake` and `cmake --build`
>
> c)Include this project as git submodule and use add_subdirectory(libfoo)

Or

  d) Use a config-file package approach (the preferred modern
  alternative to the find-file package approach used in (a)).  See
  <https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html>
  for details concerning config-file packages. Of course, this option
  assumes that external software's CMake-based build system has been
  developed to the point of creating a config-file package. However, if
  it has a CMake-based build system already that is just lacking such a
  package, it is straightforward to implement such a package (from my
  experience doing that for several different projects and also from
  the above URL).

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
__________________________

From franck.houssen at inria.fr  Thu Jan  4 04:06:26 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 4 Jan 2018 10:06:26 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <3575224.lCVmBBQUTJ@linux-l7nd>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
Message-ID: <485724957.13555203.1515056786197.JavaMail.zimbra@inria.fr>

----- Mail original -----
> De: "Alexander Neundorf" <a.neundorf-work at gmx.net>
> ?: cmake at cmake.org
> Envoy?: Mercredi 3 Janvier 2018 21:35:02
> Objet: Re: [CMake] RPATH for pkg-config
> 
> On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> > Hello,
> > 
> > How to ask cmake to add a library path (coming from pc file) to rpath ?
> > 
> > I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
> > working. Can somebody help ?
> > >> more main.cpp
> > 
> > #include <petsc.h>
> > 
> > int main(int argc, char ** argv) {
> > PetscInitialize(&argc, &argv, NULL, "");
> > PetscFinalize();
> > return 0;
> > }
> > 
> > >> more CMakeLists.txt
> > 
> > cmake_minimum_required(VERSION 3.7)
> > enable_language(CXX)
> > 
> > find_package(MPI REQUIRED)
> > find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> > pkg_check_modules(PETSc REQUIRED PETSc)
> > 
> > project(main)
> > add_executable(main main.cpp)
> > 
> > target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> > target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> > 
> > target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> > foreach(lib ${PETSc_LDFLAGS})
> > target_link_libraries(main PUBLIC ${lib})
> > endforeach(lib)
> 
> How does each ${lib} look like ?
> Is it "-lpetsc" or does it have the full path to the libraries ?

I added 2 message: one for target_link_libraries, one for link_directories.

>> more CMakeLists.txt
...
target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
foreach(lib ${PETSc_LDFLAGS})
  target_link_libraries(main PUBLIC ${lib})
  message("target_link_libraries - lib is ${lib}")
endforeach(lib)

foreach(dir ${PETSc_LIBRARY_DIRS})
  link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
  message("link_directories - dir is ${dir}")
endforeach(dir)

This gives:

>> cmake ..; make
...
target_link_libraries - lib is -L/path/to/petsc/local/lib
target_link_libraries - lib is -lpetsc
link_directories - dir is /path/to/petsc/local/lib

> You should use the full path to the libraries, otherwise cmake doesn't know
> where they are and the RPATH computation will not work.

I expected the same behavior you describe ! That why I added the link_directories (with the associated comment) BEFORE setting CMAKE_SKIP_BUILD_RPATH and others.

> > 
> > foreach(dir ${PETSc_LIBRARY_DIRS})
> > link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> > endforeach(dir)
> 
> no, link_directories() in general should not be used.
> 
> > # use, i.e. don't skip the full RPATH for the build tree
> > SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> > # when building, don't use the install RPATH already
> > # (but later on when installing)
> > SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> > SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> 
> If the automatic computation fails, you could add the petsc lib dir here as
> INSTALL_RPATH
> 

Do you mean that ?

>> more CMakeLists.txt
...
foreach(dir ${PETSc_LIBRARY_DIRS})
  link_directories(main PUBLIC ${dir})
  message("link_directories - dir is ${dir}")
  set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
endforeach(dir)


I've just tried but still not working:

>> cmake ..; make
...
target_link_libraries - lib is -L/home/fghoussen/Documents/INRIA/petsc/local/lib
target_link_libraries - lib is -lpetsc
link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
...
[100%] Built target main
>> ldd main
	linux-vdso.so.1 (0x00007ffebab8a000)
	libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20 (0x00007f36172e3000)
	libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f3616fed000)
	libpetsc.so.3.8 => not found


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

From franck.houssen at inria.fr  Thu Jan  4 04:25:36 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 4 Jan 2018 10:25:36 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
 <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
Message-ID: <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>

My understanding is that you need a local copy of FindPETSc.cmake: if this changes, you don't know it.
That's why I tried to go with the pc file.

----- Mail original -----
> De: "Andreas Naumann" <Andreas-Naumann at gmx.net>
> ?: cmake at cmake.org
> Envoy?: Mercredi 3 Janvier 2018 21:41:51
> Objet: Re: [CMake] RPATH for pkg-config
> 
> What about using a FindPETSC-Module? Some hints are
>      *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
>      *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
> 
> Regards,
> Andreas
> 
> Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> >> Hello,
> >>
> >> How to ask cmake to add a library path (coming from pc file) to rpath ?
> >>
> >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
> >> working. Can somebody help ?
> >>>> more main.cpp
> >> #include <petsc.h>
> >>
> >> int main(int argc, char ** argv) {
> >> PetscInitialize(&argc, &argv, NULL, "");
> >> PetscFinalize();
> >> return 0;
> >> }
> >>
> >>>> more CMakeLists.txt
> >> cmake_minimum_required(VERSION 3.7)
> >> enable_language(CXX)
> >>
> >> find_package(MPI REQUIRED)
> >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> >> pkg_check_modules(PETSc REQUIRED PETSc)
> >>
> >> project(main)
> >> add_executable(main main.cpp)
> >>
> >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> >>
> >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> >> foreach(lib ${PETSc_LDFLAGS})
> >> target_link_libraries(main PUBLIC ${lib})
> >> endforeach(lib)
> > How does each ${lib} look like ?
> > Is it "-lpetsc" or does it have the full path to the libraries ?
> > You should use the full path to the libraries, otherwise cmake doesn't know
> > where they are and the RPATH computation will not work.
> >
> >> foreach(dir ${PETSc_LIBRARY_DIRS})
> >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> >> endforeach(dir)
> > no, link_directories() in general should not be used.
> >
> >> # use, i.e. don't skip the full RPATH for the build tree
> >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> >> # when building, don't use the install RPATH already
> >> # (but later on when installing)
> >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > If the automatic computation fails, you could add the petsc lib dir here as
> > INSTALL_RPATH
> >
> > 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:
> https://cmake.org/mailman/listinfo/cmake
> 

From hintonda at gmail.com  Thu Jan  4 04:43:28 2018
From: hintonda at gmail.com (Don Hinton)
Date: Thu, 04 Jan 2018 09:43:28 +0000
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd> <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
Message-ID: <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>

The cmake rpath settings handle build/install directories more or less
automatically, but you need to add a completely different path.

Try adding the additional path (pretty much every -L you added) to
CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.

Then run cmake with the ?-v? option and look at the link command to verify
rpath was passed correctly.

You can also examine it in a library or executable with ?objdump-x?.

You may want to customize this for your project, but this should get you
started.

hth...
don

On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <franck.houssen at inria.fr>
wrote:

> My understanding is that you need a local copy of FindPETSc.cmake: if this
> changes, you don't know it.
> That's why I tried to go with the pc file.
>
> ----- Mail original -----
> > De: "Andreas Naumann" <Andreas-Naumann at gmx.net>
> > ?: cmake at cmake.org
> > Envoy?: Mercredi 3 Janvier 2018 21:41:51
> > Objet: Re: [CMake] RPATH for pkg-config
> >
> > What about using a FindPETSC-Module? Some hints are
> >      *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
> >      *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
> >
> > Regards,
> > Andreas
> >
> > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> > >> Hello,
> > >>
> > >> How to ask cmake to add a library path (coming from pc file) to rpath
> ?
> > >>
> > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but
> still not
> > >> working. Can somebody help ?
> > >>>> more main.cpp
> > >> #include <petsc.h>
> > >>
> > >> int main(int argc, char ** argv) {
> > >> PetscInitialize(&argc, &argv, NULL, "");
> > >> PetscFinalize();
> > >> return 0;
> > >> }
> > >>
> > >>>> more CMakeLists.txt
> > >> cmake_minimum_required(VERSION 3.7)
> > >> enable_language(CXX)
> > >>
> > >> find_package(MPI REQUIRED)
> > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> > >> pkg_check_modules(PETSc REQUIRED PETSc)
> > >>
> > >> project(main)
> > >> add_executable(main main.cpp)
> > >>
> > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> > >>
> > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> > >> foreach(lib ${PETSc_LDFLAGS})
> > >> target_link_libraries(main PUBLIC ${lib})
> > >> endforeach(lib)
> > > How does each ${lib} look like ?
> > > Is it "-lpetsc" or does it have the full path to the libraries ?
> > > You should use the full path to the libraries, otherwise cmake doesn't
> know
> > > where they are and the RPATH computation will not work.
> > >
> > >> foreach(dir ${PETSc_LIBRARY_DIRS})
> > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> > >> endforeach(dir)
> > > no, link_directories() in general should not be used.
> > >
> > >> # use, i.e. don't skip the full RPATH for the build tree
> > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> > >> # when building, don't use the install RPATH already
> > >> # (but later on when installing)
> > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > > If the automatic computation fails, you could add the petsc lib dir
> here as
> > > INSTALL_RPATH
> > >
> > > 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:
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/7322979e/attachment-0001.html>

From franck.houssen at inria.fr  Thu Jan  4 06:57:29 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 4 Jan 2018 12:57:29 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
 <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
Message-ID: <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>

----- Mail original -----

> De: "Don Hinton" <hintonda at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
> Envoy?: Jeudi 4 Janvier 2018 10:43:28
> Objet: Re: [CMake] RPATH for pkg-config

> The cmake rpath settings handle build/install directories more or less
> automatically, but you need to add a completely different path.

Yes. That's the problem: I need to add a completely different path. 

> Try adding the additional path (pretty much every -L you added) to
> CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.

See does not work 

>> more ../CMakeLists.txt 
... 
foreach(dir ${PETSc_LIBRARY_DIRS}) 
link_directories(main PUBLIC ${dir}) 
message("link_directories - dir is ${dir}") 
set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}") 
endforeach(dir) 
... 
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) 
... 

>> cmake ..; make VERBOSE=1 
... 
target_link_libraries - lib is -L/home/fghoussen/Documents/INRIA/petsc/local/lib 
target_link_libraries - lib is -lpetsc 
link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib 
... 
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o 
/usr/bin/c++ -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/home/fghoussen/Documents/INRIA/petsc/local/include -o CMakeFiles/main.dir/main.cpp.o -c /home/fghoussen/Downloads/cmake/rpath-pkgconfig/main.cpp 
[100%] Linking CXX executable main 
/usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt --verbose=1 
/usr/bin/c++ CMakeFiles/main.dir/main.cpp.o -o main -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc 
make[2]: Leaving directory '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD' 
[100%] Built target main 
make[1]: Leaving directory '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD' 
/usr/bin/cmake -E cmake_progress_start /home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD/CMakeFiles 0 

>> ldd main 
linux-vdso.so.1 (0x00007ffcd876b000) 
libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20 (0x00007f9eaba1f000) 
libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f9eab729000) 
libpetsc.so.3.8 => not found 

> Then run cmake with the ?-v? option and look at the link command to verify
> rpath was passed correctly.

> You can also examine it in a library or executable with ?objdump-x?.

> You may want to customize this for your project, but this should get you
> started.

> hth...
> don

> On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen < franck.houssen at inria.fr >
> wrote:

> > My understanding is that you need a local copy of FindPETSc.cmake: if this
> > changes, you don't know it.
> 
> > That's why I tried to go with the pc file.
> 

> > ----- Mail original -----
> 
> > > De: "Andreas Naumann" < Andreas-Naumann at gmx.net >
> 
> > > ?: cmake at cmake.org
> 
> > > Envoy?: Mercredi 3 Janvier 2018 21:41:51
> 
> > > Objet: Re: [CMake] RPATH for pkg-config
> 
> > >
> 
> > > What about using a FindPETSC-Module? Some hints are
> 
> > > * http://jacobmerson.com/2016/01/17/cmake-petsc2.html
> 
> > > * http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
> 
> > >
> 
> > > Regards,
> 
> > > Andreas
> 
> > >
> 
> > > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> 
> > > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> 
> > > >> Hello,
> 
> > > >>
> 
> > > >> How to ask cmake to add a library path (coming from pc file) to rpath
> > > >> ?
> 
> > > >>
> 
> > > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling , but still
> > > >> not
> 
> > > >> working. Can somebody help ?
> 
> > > >>>> more main.cpp
> 
> > > >> #include <petsc.h>
> 
> > > >>
> 
> > > >> int main(int argc, char ** argv) {
> 
> > > >> PetscInitialize(&argc, &argv, NULL, "");
> 
> > > >> PetscFinalize();
> 
> > > >> return 0;
> 
> > > >> }
> 
> > > >>
> 
> > > >>>> more CMakeLists.txt
> 
> > > >> cmake_minimum_required(VERSION 3.7)
> 
> > > >> enable_language(CXX)
> 
> > > >>
> 
> > > >> find_package(MPI REQUIRED)
> 
> > > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> 
> > > >> pkg_check_modules(PETSc REQUIRED PETSc)
> 
> > > >>
> 
> > > >> project(main)
> 
> > > >> add_executable(main main.cpp)
> 
> > > >>
> 
> > > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> 
> > > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> 
> > > >>
> 
> > > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> 
> > > >> foreach(lib ${PETSc_LDFLAGS})
> 
> > > >> target_link_libraries(main PUBLIC ${lib})
> 
> > > >> endforeach(lib)
> 
> > > > How does each ${lib} look like ?
> 
> > > > Is it "-lpetsc" or does it have the full path to the libraries ?
> 
> > > > You should use the full path to the libraries, otherwise cmake doesn't
> > > > know
> 
> > > > where they are and the RPATH computation will not work.
> 
> > > >
> 
> > > >> foreach(dir ${PETSc_LIBRARY_DIRS})
> 
> > > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> 
> > > >> endforeach(dir)
> 
> > > > no, link_directories() in general should not be used.
> 
> > > >
> 
> > > >> # use, i.e. don't skip the full RPATH for the build tree
> 
> > > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> 
> > > >> # when building, don't use the install RPATH already
> 
> > > >> # (but later on when installing)
> 
> > > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> 
> > > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> 
> > > > If the automatic computation fails, you could add the petsc lib dir
> > > > here
> > > > as
> 
> > > > INSTALL_RPATH
> 
> > > >
> 
> > > > 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:
> 
> > > 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/0f85fdb7/attachment.html>

From hintonda at gmail.com  Thu Jan  4 10:52:53 2018
From: hintonda at gmail.com (Don Hinton)
Date: Thu, 04 Jan 2018 15:52:53 +0000
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd> <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
Message-ID: <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>

On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen <franck.houssen at inria.fr>
wrote:

> ------------------------------
>
> *De: *"Don Hinton" <hintonda at gmail.com>
> *?: *"Franck Houssen" <franck.houssen at inria.fr>
> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
> *Envoy?: *Jeudi 4 Janvier 2018 10:43:28
>
>
> *Objet: *Re: [CMake] RPATH for pkg-config
>
> The cmake rpath settings handle build/install directories more or less
> automatically, but you need to add a completely different path.
>
>
> Yes. That's the problem: I need to add a completely different path.
>
>
> Try adding the additional path (pretty much every -L you added) to
> CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
>
>
> See does not work
>
> >> more ../CMakeLists.txt
> ...
>
> foreach(dir ${PETSc_LIBRARY_DIRS})
>   link_directories(main PUBLIC ${dir})
>   message("link_directories - dir is ${dir}")
>   set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
> endforeach(dir)
>

s/:/;/

You need to use a semicolon instead is a colon as a cmake list separator.


> ...
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> ...
>
> >> cmake ..; make VERBOSE=1
> ...
> target_link_libraries - lib is
> -L/home/fghoussen/Documents/INRIA/petsc/local/lib
> target_link_libraries - lib is -lpetsc
> link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
> ...
> [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
> /usr/bin/c++   -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
> -I/usr/lib/x86_64-linux-gnu/openmpi/include
> -I/home/fghoussen/Documents/INRIA/petsc/local/include   -o
> CMakeFiles/main.dir/main.cpp.o -c
> /home/fghoussen/Downloads/cmake/rpath-pkgconfig/main.cpp
> [100%] Linking CXX executable main
> /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
> --verbose=1
> /usr/bin/c++     CMakeFiles/main.dir/main.cpp.o  -o main
> -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
> -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
> make[2]: Leaving directory
> '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> [100%] Built target main
> make[1]: Leaving directory
> '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> /usr/bin/cmake -E cmake_progress_start
> /home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD/CMakeFiles 0
>
> >> ldd main
>     linux-vdso.so.1 (0x00007ffcd876b000)
>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> (0x00007f9eaba1f000)
>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> (0x00007f9eab729000)
>     libpetsc.so.3.8 => not found
>
>
> Then run cmake with the ?-v? option and look at the link command to verify
> rpath was passed correctly.
>
> You can also examine it in a library or executable with ?objdump-x?.
>
> You may want to customize this for your project, but this should get you
> started.
>
> hth...
> don
>
> On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>> My understanding is that you need a local copy of FindPETSc.cmake: if
>> this changes, you don't know it.
>> That's why I tried to go with the pc file.
>>
>> ----- Mail original -----
>> > De: "Andreas Naumann" <Andreas-Naumann at gmx.net>
>> > ?: cmake at cmake.org
>> > Envoy?: Mercredi 3 Janvier 2018 21:41:51
>> > Objet: Re: [CMake] RPATH for pkg-config
>> >
>> > What about using a FindPETSC-Module? Some hints are
>> >      *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
>> >      *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
>> >
>> > Regards,
>> > Andreas
>> >
>> > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
>> > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
>> > >> Hello,
>> > >>
>> > >> How to ask cmake to add a library path (coming from pc file) to
>> rpath ?
>> > >>
>> > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but
>> still not
>> > >> working. Can somebody help ?
>> > >>>> more main.cpp
>> > >> #include <petsc.h>
>> > >>
>> > >> int main(int argc, char ** argv) {
>> > >> PetscInitialize(&argc, &argv, NULL, "");
>> > >> PetscFinalize();
>> > >> return 0;
>> > >> }
>> > >>
>> > >>>> more CMakeLists.txt
>> > >> cmake_minimum_required(VERSION 3.7)
>> > >> enable_language(CXX)
>> > >>
>> > >> find_package(MPI REQUIRED)
>> > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
>> > >> pkg_check_modules(PETSc REQUIRED PETSc)
>> > >>
>> > >> project(main)
>> > >> add_executable(main main.cpp)
>> > >>
>> > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
>> > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>> > >>
>> > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
>> > >> foreach(lib ${PETSc_LDFLAGS})
>> > >> target_link_libraries(main PUBLIC ${lib})
>> > >> endforeach(lib)
>> > > How does each ${lib} look like ?
>> > > Is it "-lpetsc" or does it have the full path to the libraries ?
>> > > You should use the full path to the libraries, otherwise cmake
>> doesn't know
>> > > where they are and the RPATH computation will not work.
>> > >
>> > >> foreach(dir ${PETSc_LIBRARY_DIRS})
>> > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>> > >> endforeach(dir)
>> > > no, link_directories() in general should not be used.
>> > >
>> > >> # use, i.e. don't skip the full RPATH for the build tree
>> > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
>> > >> # when building, don't use the install RPATH already
>> > >> # (but later on when installing)
>> > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>> > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>> > > If the automatic computation fails, you could add the petsc lib dir
>> here as
>> > > INSTALL_RPATH
>> > >
>> > > 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:
>> > 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/c82f0b89/attachment-0001.html>

From franck.houssen at inria.fr  Thu Jan  4 11:34:22 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 4 Jan 2018 17:34:22 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
 <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
 <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
Message-ID: <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>

nope !... :D 

----- Mail original -----

> De: "Don Hinton" <hintonda at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
> Envoy?: Jeudi 4 Janvier 2018 16:52:53
> Objet: Re: [CMake] RPATH for pkg-config

> On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen < franck.houssen at inria.fr >
> wrote:

> > > De: "Don Hinton" < hintonda at gmail.com >
> > 
> 
> > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > 
> 
> > > Cc: "Andreas Naumann" < Andreas-Naumann at gmx.net >, cmake at cmake.org
> > 
> 
> > > Envoy?: Jeudi 4 Janvier 2018 10:43:28
> > 
> 
> > > Objet: Re: [CMake] RPATH for pkg-config
> > 
> 

> > > The cmake rpath settings handle build/install directories more or less
> > > automatically, but you need to add a completely different path.
> > 
> 

> > Yes. That's the problem: I need to add a completely different path.
> 

> > > Try adding the additional path (pretty much every -L you added) to
> > > CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
> > 
> 

> > See does not work
> 

> > >> more ../CMakeLists.txt
> 
> > ...
> 

> > foreach(dir ${PETSc_LIBRARY_DIRS})
> 
> > link_directories(main PUBLIC ${dir})
> 
> > message("link_directories - dir is ${dir}")
> 
> > set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
> 
> > endforeach(dir)
> 

> s/:/;/

> You need to use a semicolon instead is a colon as a cmake list separator.

I wish it could have worked. Don't understand. 

I added a message 

>> cmake ..; make VERBOSE=1 
... 
target_link_libraries - lib is -L/home/fghoussen/Documents/INRIA/petsc/local/lib 
target_link_libraries - lib is -lpetsc 
link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib 
CMAKE_INSTALL_RPATH: /home/fghoussen/Documents/INRIA/petsc/local/lib;/usr/local/lib;/usr/local/lib; 
... 
>> ldd main 
linux-vdso.so.1 (0x00007ffdec8e8000) 
libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20 (0x00007f429a28a000) 
libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f4299f94000) 
libpetsc.so.3.8 => not found 

> > ...
> 
> > SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> 
> > ...
> 

> > >> cmake ..; make VERBOSE=1
> 
> > ...
> 
> > target_link_libraries - lib is
> > -L/home/fghoussen/Documents/INRIA/petsc/local/lib
> 
> > target_link_libraries - lib is -lpetsc
> 
> > link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
> 
> > ...
> 
> > [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
> 
> > /usr/bin/c++ -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include
> > -I/home/fghoussen/Documents/INRIA/petsc/local/include -o
> > CMakeFiles/main.dir/main.cpp.o -c
> > /home/fghoussen/Downloads/cmake/rpath-pkgconfig/main.cpp
> 
> > [100%] Linking CXX executable main
> 
> > /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
> > --verbose=1
> 
> > /usr/bin/c++ CMakeFiles/main.dir/main.cpp.o -o main
> > -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
> > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
> > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
> > -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
> 
> > make[2]: Leaving directory
> > '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> 
> > [100%] Built target main
> 
> > make[1]: Leaving directory
> > '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> 
> > /usr/bin/cmake -E cmake_progress_start
> > /home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD/CMakeFiles 0
> 

> > >> ldd main
> 
> > linux-vdso.so.1 (0x00007ffcd876b000)
> 
> > libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> > (0x00007f9eaba1f000)
> 
> > libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f9eab729000)
> 
> > libpetsc.so.3.8 => not found
> 

> > > Then run cmake with the ?-v? option and look at the link command to
> > > verify
> > > rpath was passed correctly.
> > 
> 

> > > You can also examine it in a library or executable with ?objdump-x?.
> > 
> 

> > > You may want to customize this for your project, but this should get you
> > > started.
> > 
> 

> > > hth...
> > 
> 
> > > don
> > 
> 

> > > On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen < franck.houssen at inria.fr >
> > > wrote:
> > 
> 

> > > > My understanding is that you need a local copy of FindPETSc.cmake: if
> > > > this
> > > > changes, you don't know it.
> > > 
> > 
> 
> > > > That's why I tried to go with the pc file.
> > > 
> > 
> 

> > > > ----- Mail original -----
> > > 
> > 
> 
> > > > > De: "Andreas Naumann" < Andreas-Naumann at gmx.net >
> > > 
> > 
> 
> > > > > ?: cmake at cmake.org
> > > 
> > 
> 
> > > > > Envoy?: Mercredi 3 Janvier 2018 21:41:51
> > > 
> > 
> 
> > > > > Objet: Re: [CMake] RPATH for pkg-config
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > What about using a FindPETSC-Module? Some hints are
> > > 
> > 
> 
> > > > > * http://jacobmerson.com/2016/01/17/cmake-petsc2.html
> > > 
> > 
> 
> > > > > * http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > Regards,
> > > 
> > 
> 
> > > > > Andreas
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> > > 
> > 
> 
> > > > > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> > > 
> > 
> 
> > > > > >> Hello,
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> How to ask cmake to add a library path (coming from pc file) to
> > > > > >> rpath
> > > > > >> ?
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling , but
> > > > > >> still
> > > > > >> not
> > > 
> > 
> 
> > > > > >> working. Can somebody help ?
> > > 
> > 
> 
> > > > > >>>> more main.cpp
> > > 
> > 
> 
> > > > > >> #include <petsc.h>
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> int main(int argc, char ** argv) {
> > > 
> > 
> 
> > > > > >> PetscInitialize(&argc, &argv, NULL, "");
> > > 
> > 
> 
> > > > > >> PetscFinalize();
> > > 
> > 
> 
> > > > > >> return 0;
> > > 
> > 
> 
> > > > > >> }
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >>>> more CMakeLists.txt
> > > 
> > 
> 
> > > > > >> cmake_minimum_required(VERSION 3.7)
> > > 
> > 
> 
> > > > > >> enable_language(CXX)
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> find_package(MPI REQUIRED)
> > > 
> > 
> 
> > > > > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> > > 
> > 
> 
> > > > > >> pkg_check_modules(PETSc REQUIRED PETSc)
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> project(main)
> > > 
> > 
> 
> > > > > >> add_executable(main main.cpp)
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> > > 
> > 
> 
> > > > > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> > > 
> > 
> 
> > > > > >>
> > > 
> > 
> 
> > > > > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> > > 
> > 
> 
> > > > > >> foreach(lib ${PETSc_LDFLAGS})
> > > 
> > 
> 
> > > > > >> target_link_libraries(main PUBLIC ${lib})
> > > 
> > 
> 
> > > > > >> endforeach(lib)
> > > 
> > 
> 
> > > > > > How does each ${lib} look like ?
> > > 
> > 
> 
> > > > > > Is it "-lpetsc" or does it have the full path to the libraries ?
> > > 
> > 
> 
> > > > > > You should use the full path to the libraries, otherwise cmake
> > > > > > doesn't
> > > > > > know
> > > 
> > 
> 
> > > > > > where they are and the RPATH computation will not work.
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > > >> foreach(dir ${PETSc_LIBRARY_DIRS})
> > > 
> > 
> 
> > > > > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> > > 
> > 
> 
> > > > > >> endforeach(dir)
> > > 
> > 
> 
> > > > > > no, link_directories() in general should not be used.
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > > >> # use, i.e. don't skip the full RPATH for the build tree
> > > 
> > 
> 
> > > > > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> > > 
> > 
> 
> > > > > >> # when building, don't use the install RPATH already
> > > 
> > 
> 
> > > > > >> # (but later on when installing)
> > > 
> > 
> 
> > > > > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> > > 
> > 
> 
> > > > > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > > 
> > 
> 
> > > > > > If the automatic computation fails, you could add the petsc lib dir
> > > > > > here
> > > > > > as
> > > 
> > 
> 
> > > > > > INSTALL_RPATH
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > > > 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:
> > > 
> > 
> 
> > > > > 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
> > > 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/78f7da57/attachment-0001.html>

From hintonda at gmail.com  Thu Jan  4 11:47:19 2018
From: hintonda at gmail.com (Don Hinton)
Date: Thu, 4 Jan 2018 08:47:19 -0800
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd> <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
 <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
 <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>
Message-ID: <CAL2T-v6yXT6iQfRDzd3GwKWFpeJ-AmNZPQAr=f_f213KXPqWsQ@mail.gmail.com>

Are you still doing this at the end?  You are overwriting here, not adding.

IF("${isSystemDir}" STREQUAL "-1")
   SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
ENDIF("${isSystemDir}" STREQUAL "-1")

Also, do not use ':', use ';' instead as a separator.  Or use 'list(APPEND
...), to add to a list.

On Thu, Jan 4, 2018 at 8:34 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> nope !... :D
>
> ------------------------------
>
> *De: *"Don Hinton" <hintonda at gmail.com>
> *?: *"Franck Houssen" <franck.houssen at inria.fr>
> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
> *Envoy?: *Jeudi 4 Janvier 2018 16:52:53
> *Objet: *Re: [CMake] RPATH for pkg-config
>
>
> On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>> ------------------------------
>>
>> *De: *"Don Hinton" <hintonda at gmail.com>
>> *?: *"Franck Houssen" <franck.houssen at inria.fr>
>> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
>> *Envoy?: *Jeudi 4 Janvier 2018 10:43:28
>>
>>
>> *Objet: *Re: [CMake] RPATH for pkg-config
>>
>> The cmake rpath settings handle build/install directories more or less
>> automatically, but you need to add a completely different path.
>>
>>
>> Yes. That's the problem: I need to add a completely different path.
>>
>>
>> Try adding the additional path (pretty much every -L you added) to
>> CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
>>
>>
>> See does not work
>>
>> >> more ../CMakeLists.txt
>> ...
>>
>> foreach(dir ${PETSc_LIBRARY_DIRS})
>>   link_directories(main PUBLIC ${dir})
>>   message("link_directories - dir is ${dir}")
>>   set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
>> endforeach(dir)
>>
>
> s/:/;/
>
>
>> You need to use a semicolon instead is a colon as a cmake list separator.
>
>
>
> I wish it could have worked. Don't understand.
>
> I added a message
>
> >> cmake ..; make VERBOSE=1
> ...
> target_link_libraries - lib is -L/home/fghoussen/Documents/
> INRIA/petsc/local/lib
> target_link_libraries - lib is -lpetsc
> link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
> CMAKE_INSTALL_RPATH: /home/fghoussen/Documents/INRIA/petsc/local/lib;/usr/
> local/lib;/usr/local/lib;
> ...
> >> ldd main
>     linux-vdso.so.1 (0x00007ffdec8e8000)
>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> (0x00007f429a28a000)
>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> (0x00007f4299f94000)
>     libpetsc.so.3.8 => not found
>
>
>
>> ...
>> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
>> ...
>>
>> >> cmake ..; make VERBOSE=1
>> ...
>> target_link_libraries - lib is -L/home/fghoussen/Documents/
>> INRIA/petsc/local/lib
>> target_link_libraries - lib is -lpetsc
>> link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
>> ...
>> [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
>> /usr/bin/c++   -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
>> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/
>> mca/event/libevent2022/libevent -I/usr/lib/x86_64-linux-gnu/
>> openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
>> -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/home/fghoussen/Documents/INRIA/petsc/local/include
>> -o CMakeFiles/main.dir/main.cpp.o -c /home/fghoussen/Downloads/
>> cmake/rpath-pkgconfig/main.cpp
>> [100%] Linking CXX executable main
>> /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
>> --verbose=1
>> /usr/bin/c++     CMakeFiles/main.dir/main.cpp.o  -o main
>> -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
>> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
>> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
>> -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
>> make[2]: Leaving directory '/home/fghoussen/Downloads/
>> cmake/rpath-pkgconfig/BUILD'
>> [100%] Built target main
>> make[1]: Leaving directory '/home/fghoussen/Downloads/
>> cmake/rpath-pkgconfig/BUILD'
>> /usr/bin/cmake -E cmake_progress_start /home/fghoussen/Downloads/
>> cmake/rpath-pkgconfig/BUILD/CMakeFiles 0
>>
>> >> ldd main
>>     linux-vdso.so.1 (0x00007ffcd876b000)
>>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
>> (0x00007f9eaba1f000)
>>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
>> (0x00007f9eab729000)
>>     libpetsc.so.3.8 => not found
>>
>>
>> Then run cmake with the ?-v? option and look at the link command to
>> verify rpath was passed correctly.
>>
>> You can also examine it in a library or executable with ?objdump-x?.
>>
>> You may want to customize this for your project, but this should get you
>> started.
>>
>> hth...
>> don
>>
>> On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <franck.houssen at inria.fr>
>> wrote:
>>
>>> My understanding is that you need a local copy of FindPETSc.cmake: if
>>> this changes, you don't know it.
>>> That's why I tried to go with the pc file.
>>>
>>> ----- Mail original -----
>>> > De: "Andreas Naumann" <Andreas-Naumann at gmx.net>
>>> > ?: cmake at cmake.org
>>> > Envoy?: Mercredi 3 Janvier 2018 21:41:51
>>> > Objet: Re: [CMake] RPATH for pkg-config
>>> >
>>> > What about using a FindPETSC-Module? Some hints are
>>> >      *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
>>> >      *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
>>> >
>>> > Regards,
>>> > Andreas
>>> >
>>> > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
>>> > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
>>> > >> Hello,
>>> > >>
>>> > >> How to ask cmake to add a library path (coming from pc file) to
>>> rpath ?
>>> > >>
>>> > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but
>>> still not
>>> > >> working. Can somebody help ?
>>> > >>>> more main.cpp
>>> > >> #include <petsc.h>
>>> > >>
>>> > >> int main(int argc, char ** argv) {
>>> > >> PetscInitialize(&argc, &argv, NULL, "");
>>> > >> PetscFinalize();
>>> > >> return 0;
>>> > >> }
>>> > >>
>>> > >>>> more CMakeLists.txt
>>> > >> cmake_minimum_required(VERSION 3.7)
>>> > >> enable_language(CXX)
>>> > >>
>>> > >> find_package(MPI REQUIRED)
>>> > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
>>> > >> pkg_check_modules(PETSc REQUIRED PETSc)
>>> > >>
>>> > >> project(main)
>>> > >> add_executable(main main.cpp)
>>> > >>
>>> > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
>>> > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>>> > >>
>>> > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
>>> > >> foreach(lib ${PETSc_LDFLAGS})
>>> > >> target_link_libraries(main PUBLIC ${lib})
>>> > >> endforeach(lib)
>>> > > How does each ${lib} look like ?
>>> > > Is it "-lpetsc" or does it have the full path to the libraries ?
>>> > > You should use the full path to the libraries, otherwise cmake
>>> doesn't know
>>> > > where they are and the RPATH computation will not work.
>>> > >
>>> > >> foreach(dir ${PETSc_LIBRARY_DIRS})
>>> > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>>> > >> endforeach(dir)
>>> > > no, link_directories() in general should not be used.
>>> > >
>>> > >> # use, i.e. don't skip the full RPATH for the build tree
>>> > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
>>> > >> # when building, don't use the install RPATH already
>>> > >> # (but later on when installing)
>>> > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>> > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>>> > > If the automatic computation fails, you could add the petsc lib dir
>>> here as
>>> > > INSTALL_RPATH
>>> > >
>>> > > 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:
>>> > 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/109bd1bf/attachment-0001.html>

From franck.houssen at inria.fr  Thu Jan  4 12:13:18 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 4 Jan 2018 18:13:18 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <CAL2T-v6yXT6iQfRDzd3GwKWFpeJ-AmNZPQAr=f_f213KXPqWsQ@mail.gmail.com>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
 <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
 <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>
 <CAL2T-v6yXT6iQfRDzd3GwKWFpeJ-AmNZPQAr=f_f213KXPqWsQ@mail.gmail.com>
Message-ID: <492856152.13910311.1515085998851.JavaMail.zimbra@inria.fr>

not working with the last cmakelist I have which is: 

>> more ../CMakeLists.txt 
cmake_minimum_required(VERSION 3.7) 
enable_language(CXX) 

find_package(MPI REQUIRED) 
find_package(PkgConfig REQUIRED) # Get pkg_check_modules. 
pkg_check_modules(PETSc REQUIRED PETSc) 

project(main) 
add_executable(main main.cpp) 

target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH}) 
target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES}) 

target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS}) 
foreach(lib ${PETSc_LDFLAGS}) 
target_link_libraries(main PUBLIC ${lib}) 
message("target_link_libraries - lib is ${lib}") 
endforeach(lib) 

# use, i.e. don't skip the full RPATH for the build tree 
SET(CMAKE_SKIP_BUILD_RPATH FALSE) 
# when building, don't use the install RPATH already 
# (but later on when installing) 
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) 
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib;${CMAKE_INSTALL_RPATH}") 
# add the automatically determined parts of the RPATH 
# which point to directories outside the build tree to the install RPATH 
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) 
# the RPATH to be used when installing, but only if it's not a system directory 
LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir) 
IF("${isSystemDir}" STREQUAL "-1") 
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib;${CMAKE_INSTALL_RPATH}") 
ENDIF("${isSystemDir}" STREQUAL "-1") 
foreach(dir ${PETSc_LIBRARY_DIRS}) 
link_directories(main PUBLIC ${dir}) 
message("link_directories - dir is ${dir}") 
set(CMAKE_INSTALL_RPATH "${dir};${CMAKE_INSTALL_RPATH}") 
endforeach(dir) 
message("CMAKE_INSTALL_RPATH: ${CMAKE_INSTALL_RPATH}") 

include(CTest) 
enable_testing() 
add_test(NAME main COMMAND "mpirun -n 2 ./main" WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}") 

----- Mail original -----

> De: "Don Hinton" <hintonda at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "Andreas Naumann" <Andreas-Naumann at gmx.net>, "CMake Mail List"
> <cmake at cmake.org>
> Envoy?: Jeudi 4 Janvier 2018 17:47:19
> Objet: Re: [CMake] RPATH for pkg-config

> Are you still doing this at the end? You are overwriting here, not adding.

> IF("${isSystemDir}" STREQUAL "-1")
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> ENDIF("${isSystemDir}" STREQUAL "-1")

> Also, do not use ':', use ';' instead as a separator. Or use 'list(APPEND
> ...), to add to a list.

> On Thu, Jan 4, 2018 at 8:34 AM, Franck Houssen < franck.houssen at inria.fr >
> wrote:

> > nope !... :D
> 

> > > De: "Don Hinton" < hintonda at gmail.com >
> > 
> 
> > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > 
> 
> > > Cc: "Andreas Naumann" < Andreas-Naumann at gmx.net >, cmake at cmake.org
> > 
> 
> > > Envoy?: Jeudi 4 Janvier 2018 16:52:53
> > 
> 
> > > Objet: Re: [CMake] RPATH for pkg-config
> > 
> 

> > > On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen < franck.houssen at inria.fr >
> > > wrote:
> > 
> 

> > > > > De: "Don Hinton" < hintonda at gmail.com >
> > > > 
> > > 
> > 
> 
> > > > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > > > 
> > > 
> > 
> 
> > > > > Cc: "Andreas Naumann" < Andreas-Naumann at gmx.net >, cmake at cmake.org
> > > > 
> > > 
> > 
> 
> > > > > Envoy?: Jeudi 4 Janvier 2018 10:43:28
> > > > 
> > > 
> > 
> 
> > > > > Objet: Re: [CMake] RPATH for pkg-config
> > > > 
> > > 
> > 
> 

> > > > > The cmake rpath settings handle build/install directories more or
> > > > > less
> > > > > automatically, but you need to add a completely different path.
> > > > 
> > > 
> > 
> 

> > > > Yes. That's the problem: I need to add a completely different path.
> > > 
> > 
> 

> > > > > Try adding the additional path (pretty much every -L you added) to
> > > > > CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
> > > > 
> > > 
> > 
> 

> > > > See does not work
> > > 
> > 
> 

> > > > >> more ../CMakeLists.txt
> > > 
> > 
> 
> > > > ...
> > > 
> > 
> 

> > > > foreach(dir ${PETSc_LIBRARY_DIRS})
> > > 
> > 
> 
> > > > link_directories(main PUBLIC ${dir})
> > > 
> > 
> 
> > > > message("link_directories - dir is ${dir}")
> > > 
> > 
> 
> > > > set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
> > > 
> > 
> 
> > > > endforeach(dir)
> > > 
> > 
> 

> > > s/:/;/
> > 
> 

> > > You need to use a semicolon instead is a colon as a cmake list separator.
> > 
> 

> > I wish it could have worked. Don't understand.
> 

> > I added a message
> 

> > >> cmake ..; make VERBOSE=1
> 
> > ...
> 
> > target_link_libraries - lib is
> > -L/home/fghoussen/Documents/INRIA/petsc/local/lib
> 
> > target_link_libraries - lib is -lpetsc
> 
> > link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
> 
> > CMAKE_INSTALL_RPATH:
> > /home/fghoussen/Documents/INRIA/petsc/local/lib;/usr/local/lib;/usr/local/lib;
> 
> > ...
> 
> > >> ldd main
> 
> > linux-vdso.so.1 (0x00007ffdec8e8000)
> 
> > libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> > (0x00007f429a28a000)
> 
> > libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f4299f94000)
> 
> > libpetsc.so.3.8 => not found
> 

> > > > ...
> > > 
> > 
> 
> > > > SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> > > 
> > 
> 
> > > > ...
> > > 
> > 
> 

> > > > >> cmake ..; make VERBOSE=1
> > > 
> > 
> 
> > > > ...
> > > 
> > 
> 
> > > > target_link_libraries - lib is
> > > > -L/home/fghoussen/Documents/INRIA/petsc/local/lib
> > > 
> > 
> 
> > > > target_link_libraries - lib is -lpetsc
> > > 
> > 
> 
> > > > link_directories - dir is
> > > > /home/fghoussen/Documents/INRIA/petsc/local/lib
> > > 
> > 
> 
> > > > ...
> > > 
> > 
> 
> > > > [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
> > > 
> > 
> 
> > > > /usr/bin/c++ -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
> > > > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent
> > > > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
> > > > -I/usr/lib/x86_64-linux-gnu/openmpi/include
> > > > -I/home/fghoussen/Documents/INRIA/petsc/local/include -o
> > > > CMakeFiles/main.dir/main.cpp.o -c
> > > > /home/fghoussen/Downloads/cmake/rpath-pkgconfig/main.cpp
> > > 
> > 
> 
> > > > [100%] Linking CXX executable main
> > > 
> > 
> 
> > > > /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
> > > > --verbose=1
> > > 
> > 
> 
> > > > /usr/bin/c++ CMakeFiles/main.dir/main.cpp.o -o main
> > > > -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
> > > > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
> > > > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
> > > > -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
> > > 
> > 
> 
> > > > make[2]: Leaving directory
> > > > '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> > > 
> > 
> 
> > > > [100%] Built target main
> > > 
> > 
> 
> > > > make[1]: Leaving directory
> > > > '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> > > 
> > 
> 
> > > > /usr/bin/cmake -E cmake_progress_start
> > > > /home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD/CMakeFiles 0
> > > 
> > 
> 

> > > > >> ldd main
> > > 
> > 
> 
> > > > linux-vdso.so.1 (0x00007ffcd876b000)
> > > 
> > 
> 
> > > > libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> > > > (0x00007f9eaba1f000)
> > > 
> > 
> 
> > > > libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> > > > (0x00007f9eab729000)
> > > 
> > 
> 
> > > > libpetsc.so.3.8 => not found
> > > 
> > 
> 

> > > > > Then run cmake with the ?-v? option and look at the link command to
> > > > > verify
> > > > > rpath was passed correctly.
> > > > 
> > > 
> > 
> 

> > > > > You can also examine it in a library or executable with ?objdump-x?.
> > > > 
> > > 
> > 
> 

> > > > > You may want to customize this for your project, but this should get
> > > > > you
> > > > > started.
> > > > 
> > > 
> > 
> 

> > > > > hth...
> > > > 
> > > 
> > 
> 
> > > > > don
> > > > 
> > > 
> > 
> 

> > > > > On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <
> > > > > franck.houssen at inria.fr
> > > > > >
> > > > > wrote:
> > > > 
> > > 
> > 
> 

> > > > > > My understanding is that you need a local copy of FindPETSc.cmake:
> > > > > > if
> > > > > > this
> > > > > > changes, you don't know it.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > That's why I tried to go with the pc file.
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > ----- Mail original -----
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > De: "Andreas Naumann" < Andreas-Naumann at gmx.net >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > ?: cmake at cmake.org
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Envoy?: Mercredi 3 Janvier 2018 21:41:51
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Objet: Re: [CMake] RPATH for pkg-config
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > What about using a FindPETSC-Module? Some hints are
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > * http://jacobmerson.com/2016/01/17/cmake-petsc2.html
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > * http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Regards,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Andreas
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> Hello,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> How to ask cmake to add a library path (coming from pc file)
> > > > > > > >> to
> > > > > > > >> rpath
> > > > > > > >> ?
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling ,
> > > > > > > >> but
> > > > > > > >> still
> > > > > > > >> not
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> working. Can somebody help ?
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>>> more main.cpp
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> #include <petsc.h>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> int main(int argc, char ** argv) {
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> PetscInitialize(&argc, &argv, NULL, "");
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> PetscFinalize();
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> return 0;
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> }
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>>> more CMakeLists.txt
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> cmake_minimum_required(VERSION 3.7)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> enable_language(CXX)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> find_package(MPI REQUIRED)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> pkg_check_modules(PETSc REQUIRED PETSc)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> project(main)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> add_executable(main main.cpp)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> target_include_directories(main PUBLIC
> > > > > > > >> ${MPI_CXX_INCLUDE_PATH})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >>
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> foreach(lib ${PETSc_LDFLAGS})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> target_link_libraries(main PUBLIC ${lib})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> endforeach(lib)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > How does each ${lib} look like ?
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > Is it "-lpetsc" or does it have the full path to the libraries
> > > > > > > > ?
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > You should use the full path to the libraries, otherwise cmake
> > > > > > > > doesn't
> > > > > > > > know
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > where they are and the RPATH computation will not work.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> foreach(dir ${PETSc_LIBRARY_DIRS})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> link_directories(main PUBLIC ${dir}) # Not sure: is this
> > > > > > > >> needed
> > > > > > > >> ?
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> endforeach(dir)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > no, link_directories() in general should not be used.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> # use, i.e. don't skip the full RPATH for the build tree
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> # when building, don't use the install RPATH already
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> # (but later on when installing)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > If the automatic computation fails, you could add the petsc lib
> > > > > > > > dir
> > > > > > > > here
> > > > > > > > as
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > INSTALL_RPATH
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > 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:
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > 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
> > > > > 
> > > > 
> > > 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/ed1f5e04/attachment-0001.html>

From domen.vrankar at gmail.com  Thu Jan  4 14:51:57 2018
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 4 Jan 2018 20:51:57 +0100
Subject: [CMake] CPack per-component value for
 CPACK_PACKAGING_INSTALL_PREFIX when using RPM generator
In-Reply-To: <CADjN2kdKd41YAYy=JH=WtAkAFwsLoiXQnZ5Fmzz3nzC80bTopw@mail.gmail.com>
References: <CADjN2kdKd41YAYy=JH=WtAkAFwsLoiXQnZ5Fmzz3nzC80bTopw@mail.gmail.com>
Message-ID: <CAKgx6B+JLYa1VL3X9vN37ZR3y9_-9gCVE8NuegRnyuxdSZsPPw@mail.gmail.com>

2018-01-03 22:40 GMT+01:00 Sam Lunt <sam.lunt at transmarketgroup.com>:

> I am trying to set a per-component value for
> CPACK_PACKAGING_INSTALL_PREFIX when using the RPM generator, but I
> haven't been able to do so.
>
> I would like to be able to:
> 1. Install using "make install" (or cmake --build ${BUILD_DIR}
> --target install) and have CMAKE_INSTALL_PREFIX control the install
> location
> 2. Generate an rpm file for each component such that the rpm is
> relocatable (i.e. --prefix and --relocate are supported) and each
> component has a different default installation location
>
> The documentation for CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX seems to
> indicate that it is the correct way to set a per-component install
> prefix, since it says that CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX "May
> be used to set per component CPACK_PACKAGING_INSTALL_PREFIX for
> relocatable RPM packages." However, I am only able to successfully use
> this if I provide an absolute path to the install command, but that
> inhibits the use of CMAKE_INSTALL_PREFIX.
>

How about using CPACK_RPM_RELOCATION_PATHS?
https://cmake.org/cmake/help/v3.10/module/CPackRPM.html#variable:CPACK_RPM_RELOCATION_PATHS

install(DIRECTORY DESTINATION ${CMAKE_INSTALL_LIBDIR}/some_dir COMPONENT
libraries)
set(CPACK_RPM_RELOCATION_PATHS "${CMAKE_INSTALL_INCLUDEDIR}"
  "${CMAKE_INSTALL_LIBDIR}")

You specify all the relocation paths for all components and if one or more
of them are found during package generation that path is written to the
package as a relocation path.
You can also use
https://cmake.org/cmake/help/v3.10/module/CPackRPM.html#variable:CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION
to discard CPACK_PACKAGING_INSTALL_PREFIX as a relocation path.

This feature can also (is prefered to) be used in combination with
GNUInstallDirs module (
https://cmake.org/cmake/help/v3.10/module/GNUInstallDirs.html?highlight=gnuinstalldirs
):

include(GNUInstallDirs)

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/4e53241c/attachment.html>

From hintonda at gmail.com  Thu Jan  4 15:49:05 2018
From: hintonda at gmail.com (Don Hinton)
Date: Thu, 4 Jan 2018 12:49:05 -0800
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <492856152.13910311.1515085998851.JavaMail.zimbra@inria.fr>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
 <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
 <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>
 <CAL2T-v6yXT6iQfRDzd3GwKWFpeJ-AmNZPQAr=f_f213KXPqWsQ@mail.gmail.com>
 <492856152.13910311.1515085998851.JavaMail.zimbra@inria.fr>
Message-ID: <CAL2T-v5J+sfFxH99yYANqw_OGcM1zHNn25e1VbCDN8GJvkNFmg@mail.gmail.com>

This is mostly an ordering problem -- you need to setup everything before
calling add_executable.  Also, I was wrong about using ';' in RPATH
variables.  They should use ':' as in your original since they are used
verbatim.

Here's an example that works:

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.7)
project(main)

enable_language(CXX)
find_package(MPI REQUIRED)

find_package(PkgConfig REQUIRED)
pkg_check_modules(PETSc REQUIRED PETSc)

# RPATH variables must be set, and link_directories called. before calling
add_executable.
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH
"${CMAKE_INSTALL_RPATH}:$ORIGIN/../lib:${PETSc_LIBRARY_DIRS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
-Wl,--enable-new-dtags")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
-Wl,--enable-new-dtags")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-Wl,--enable-new-dtags")
link_directories(${PETSc_LIBRARY_DIRS})

add_executable(main main.cpp)

target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH}
${PETSc_INCLUDE_DIRS})
target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES} ${PETSc_LIBRARIES})

install(TARGETS main RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)

$ make VERBOSE=1
/usr/local/bin/cmake -H/home/dhinton/test -B/home/dhinton/test/build
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start
/home/dhinton/test/build/CMakeFiles
/home/dhinton/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/dhinton/test/build'
make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/depend
make[2]: Entering directory '/home/dhinton/test/build'
cd /home/dhinton/test/build && /usr/local/bin/cmake -E cmake_depends "Unix
Makefiles" /home/dhinton/test /home/dhinton/test /home/dhinton/test/build
/home/dhinton/test/build
/home/dhinton/test/build/CMakeFiles/main.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/home/dhinton/test/build'
make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/build
make[2]: Entering directory '/home/dhinton/test/build'
make[2]: Nothing to be done for 'CMakeFiles/main.dir/build'.
make[2]: Leaving directory '/home/dhinton/test/build'
[100%] Built target main
make[1]: Leaving directory '/home/dhinton/test/build'
/usr/local/bin/cmake -E cmake_progress_start
/home/dhinton/test/build/CMakeFiles 0

$ objdump -x main | grep PATH
  RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib

$ make install
[100%] Built target main
Install the project...
-- Install configuration: ""
-- Installing: /home/dhinton/petsc-test/bin/main

$ objdump -x ~/petsc-test/bin/main | grep PATH
  RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib

hth...
don

On Thu, Jan 4, 2018 at 9:13 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> not working with the last cmakelist I have which is:
>
> >> more ../CMakeLists.txt
> cmake_minimum_required(VERSION 3.7)
> enable_language(CXX)
>
> find_package(MPI REQUIRED)
> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> pkg_check_modules(PETSc REQUIRED PETSc)
>
> project(main)
> add_executable(main main.cpp)
>
> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>
> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> foreach(lib ${PETSc_LDFLAGS})
>   target_link_libraries(main PUBLIC ${lib})
>   message("target_link_libraries - lib is ${lib}")
> endforeach(lib)
>
> # use, i.e. don't skip the full RPATH for the build tree
> SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
> # when building, don't use the install RPATH already
> # (but later on when installing)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib;$
> {CMAKE_INSTALL_RPATH}")
> # add the automatically determined parts of the RPATH
> # which point to directories outside the build tree to the install RPATH
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> # the RPATH to be used when installing, but only if it's not a system
> directory
> LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
> "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
> IF("${isSystemDir}" STREQUAL "-1")
>    SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib;$
> {CMAKE_INSTALL_RPATH}")
> ENDIF("${isSystemDir}" STREQUAL "-1")
> foreach(dir ${PETSc_LIBRARY_DIRS})
>   link_directories(main PUBLIC ${dir})
>   message("link_directories - dir is ${dir}")
>   set(CMAKE_INSTALL_RPATH "${dir};${CMAKE_INSTALL_RPATH}")
> endforeach(dir)
> message("CMAKE_INSTALL_RPATH: ${CMAKE_INSTALL_RPATH}")
>
> include(CTest)
> enable_testing()
> add_test(NAME main COMMAND "mpirun -n 2 ./main" WORKING_DIRECTORY
> "${CMAKE_CURRENT_BINARY_DIR}")
>
> ------------------------------
>
> *De: *"Don Hinton" <hintonda at gmail.com>
> *?: *"Franck Houssen" <franck.houssen at inria.fr>
> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, "CMake Mail List" <
> cmake at cmake.org>
> *Envoy?: *Jeudi 4 Janvier 2018 17:47:19
>
> *Objet: *Re: [CMake] RPATH for pkg-config
>
> Are you still doing this at the end?  You are overwriting here, not adding.
>
> IF("${isSystemDir}" STREQUAL "-1")
>    SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> ENDIF("${isSystemDir}" STREQUAL "-1")
>
> Also, do not use ':', use ';' instead as a separator.  Or use 'list(APPEND
> ...), to add to a list.
>
> On Thu, Jan 4, 2018 at 8:34 AM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>> nope !... :D
>>
>> ------------------------------
>>
>> *De: *"Don Hinton" <hintonda at gmail.com>
>> *?: *"Franck Houssen" <franck.houssen at inria.fr>
>> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
>> *Envoy?: *Jeudi 4 Janvier 2018 16:52:53
>> *Objet: *Re: [CMake] RPATH for pkg-config
>>
>>
>> On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen <franck.houssen at inria.fr>
>> wrote:
>>
>>> ------------------------------
>>>
>>> *De: *"Don Hinton" <hintonda at gmail.com>
>>> *?: *"Franck Houssen" <franck.houssen at inria.fr>
>>> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
>>> *Envoy?: *Jeudi 4 Janvier 2018 10:43:28
>>>
>>>
>>> *Objet: *Re: [CMake] RPATH for pkg-config
>>>
>>> The cmake rpath settings handle build/install directories more or less
>>> automatically, but you need to add a completely different path.
>>>
>>>
>>> Yes. That's the problem: I need to add a completely different path.
>>>
>>>
>>> Try adding the additional path (pretty much every -L you added) to
>>> CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
>>>
>>>
>>> See does not work
>>>
>>> >> more ../CMakeLists.txt
>>> ...
>>>
>>> foreach(dir ${PETSc_LIBRARY_DIRS})
>>>   link_directories(main PUBLIC ${dir})
>>>   message("link_directories - dir is ${dir}")
>>>   set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
>>> endforeach(dir)
>>>
>>
>> s/:/;/
>>
>>
>>> You need to use a semicolon instead is a colon as a cmake list separator.
>>
>>
>>
>> I wish it could have worked. Don't understand.
>>
>> I added a message
>>
>> >> cmake ..; make VERBOSE=1
>> ...
>> target_link_libraries - lib is -L/home/fghoussen/Documents/
>> INRIA/petsc/local/lib
>> target_link_libraries - lib is -lpetsc
>> link_directories - dir is /home/fghoussen/Documents/INRIA/petsc/local/lib
>> CMAKE_INSTALL_RPATH: /home/fghoussen/Documents/
>> INRIA/petsc/local/lib;/usr/local/lib;/usr/local/lib;
>> ...
>> >> ldd main
>>     linux-vdso.so.1 (0x00007ffdec8e8000)
>>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
>> (0x00007f429a28a000)
>>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
>> (0x00007f4299f94000)
>>     libpetsc.so.3.8 => not found
>>
>>
>>
>>> ...
>>> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
>>> ...
>>>
>>> >> cmake ..; make VERBOSE=1
>>> ...
>>> target_link_libraries - lib is -L/home/fghoussen/Documents/
>>> INRIA/petsc/local/lib
>>> target_link_libraries - lib is -lpetsc
>>> link_directories - dir is /home/fghoussen/Documents/
>>> INRIA/petsc/local/lib
>>> ...
>>> [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
>>> /usr/bin/c++   -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
>>> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/
>>> mca/event/libevent2022/libevent -I/usr/lib/x86_64-linux-gnu/
>>> openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
>>> -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/home/fghoussen/Documents/INRIA/petsc/local/include
>>> -o CMakeFiles/main.dir/main.cpp.o -c /home/fghoussen/Downloads/
>>> cmake/rpath-pkgconfig/main.cpp
>>> [100%] Linking CXX executable main
>>> /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
>>> --verbose=1
>>> /usr/bin/c++     CMakeFiles/main.dir/main.cpp.o  -o main
>>> -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
>>> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
>>> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
>>> -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
>>> make[2]: Leaving directory '/home/fghoussen/Downloads/
>>> cmake/rpath-pkgconfig/BUILD'
>>> [100%] Built target main
>>> make[1]: Leaving directory '/home/fghoussen/Downloads/
>>> cmake/rpath-pkgconfig/BUILD'
>>> /usr/bin/cmake -E cmake_progress_start /home/fghoussen/Downloads/
>>> cmake/rpath-pkgconfig/BUILD/CMakeFiles 0
>>>
>>> >> ldd main
>>>     linux-vdso.so.1 (0x00007ffcd876b000)
>>>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
>>> (0x00007f9eaba1f000)
>>>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
>>> (0x00007f9eab729000)
>>>     libpetsc.so.3.8 => not found
>>>
>>>
>>> Then run cmake with the ?-v? option and look at the link command to
>>> verify rpath was passed correctly.
>>>
>>> You can also examine it in a library or executable with ?objdump-x?.
>>>
>>> You may want to customize this for your project, but this should get you
>>> started.
>>>
>>> hth...
>>> don
>>>
>>> On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <franck.houssen at inria.fr>
>>> wrote:
>>>
>>>> My understanding is that you need a local copy of FindPETSc.cmake: if
>>>> this changes, you don't know it.
>>>> That's why I tried to go with the pc file.
>>>>
>>>> ----- Mail original -----
>>>> > De: "Andreas Naumann" <Andreas-Naumann at gmx.net>
>>>> > ?: cmake at cmake.org
>>>> > Envoy?: Mercredi 3 Janvier 2018 21:41:51
>>>> > Objet: Re: [CMake] RPATH for pkg-config
>>>> >
>>>> > What about using a FindPETSC-Module? Some hints are
>>>> >      *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
>>>> >      *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
>>>> >
>>>> > Regards,
>>>> > Andreas
>>>> >
>>>> > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
>>>> > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
>>>> > >> Hello,
>>>> > >>
>>>> > >> How to ask cmake to add a library path (coming from pc file) to
>>>> rpath ?
>>>> > >>
>>>> > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but
>>>> still not
>>>> > >> working. Can somebody help ?
>>>> > >>>> more main.cpp
>>>> > >> #include <petsc.h>
>>>> > >>
>>>> > >> int main(int argc, char ** argv) {
>>>> > >> PetscInitialize(&argc, &argv, NULL, "");
>>>> > >> PetscFinalize();
>>>> > >> return 0;
>>>> > >> }
>>>> > >>
>>>> > >>>> more CMakeLists.txt
>>>> > >> cmake_minimum_required(VERSION 3.7)
>>>> > >> enable_language(CXX)
>>>> > >>
>>>> > >> find_package(MPI REQUIRED)
>>>> > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
>>>> > >> pkg_check_modules(PETSc REQUIRED PETSc)
>>>> > >>
>>>> > >> project(main)
>>>> > >> add_executable(main main.cpp)
>>>> > >>
>>>> > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
>>>> > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>>>> > >>
>>>> > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
>>>> > >> foreach(lib ${PETSc_LDFLAGS})
>>>> > >> target_link_libraries(main PUBLIC ${lib})
>>>> > >> endforeach(lib)
>>>> > > How does each ${lib} look like ?
>>>> > > Is it "-lpetsc" or does it have the full path to the libraries ?
>>>> > > You should use the full path to the libraries, otherwise cmake
>>>> doesn't know
>>>> > > where they are and the RPATH computation will not work.
>>>> > >
>>>> > >> foreach(dir ${PETSc_LIBRARY_DIRS})
>>>> > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>>>> > >> endforeach(dir)
>>>> > > no, link_directories() in general should not be used.
>>>> > >
>>>> > >> # use, i.e. don't skip the full RPATH for the build tree
>>>> > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
>>>> > >> # when building, don't use the install RPATH already
>>>> > >> # (but later on when installing)
>>>> > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>>> > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>>>> > > If the automatic computation fails, you could add the petsc lib dir
>>>> here as
>>>> > > INSTALL_RPATH
>>>> > >
>>>> > > 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:
>>>> > 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
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/22709c3d/attachment-0001.html>

From hintonda at gmail.com  Thu Jan  4 15:56:55 2018
From: hintonda at gmail.com (Don Hinton)
Date: Thu, 4 Jan 2018 12:56:55 -0800
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <CAL2T-v5J+sfFxH99yYANqw_OGcM1zHNn25e1VbCDN8GJvkNFmg@mail.gmail.com>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <4885895a-50d1-6b78-7f83-f10b9e895dde@gmx.net>
 <464314177.13566448.1515057936634.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
 <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
 <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>
 <CAL2T-v6yXT6iQfRDzd3GwKWFpeJ-AmNZPQAr=f_f213KXPqWsQ@mail.gmail.com>
 <492856152.13910311.1515085998851.JavaMail.zimbra@inria.fr>
 <CAL2T-v5J+sfFxH99yYANqw_OGcM1zHNn25e1VbCDN8GJvkNFmg@mail.gmail.com>
Message-ID: <CAL2T-v6iMA31U2+q4HEmGLTzxM4HCtdpaYjVGaSpDegSjLd8Uw@mail.gmail.com>

Let me send this again for completeness -- left out a couple steps the
first time:

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.7)
project(main)

enable_language(CXX)
find_package(MPI REQUIRED)

find_package(PkgConfig REQUIRED)
pkg_check_modules(PETSc REQUIRED PETSc)

# RPATH variables must be set, and link_directories called. before calling
add_executable.
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH
"${CMAKE_INSTALL_RPATH}:$ORIGIN/../lib:${PETSc_LIBRARY_DIRS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
-Wl,--enable-new-dtags")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
-Wl,--enable-new-dtags")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-Wl,--enable-new-dtags")
link_directories(${PETSc_LIBRARY_DIRS})

add_executable(main main.cpp)

target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH}
${PETSc_INCLUDE_DIRS})
target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES} ${PETSc_LIBRARIES})

install(TARGETS main RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)

$ rm -rf * && cmake -DCMAKE_INSTALL_PREFIX=${HOME}/petsc-test ..
-- The C compiler identification is GNU 5.5.0
-- The CXX compiler identification is GNU 5.5.0
-- 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
-- Check for working CXX compiler: /usr/local/bin/c++
-- Check for working CXX compiler: /usr/local/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found MPI_C:
/usr/lib/libmpi.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libhwloc.so
-- Found MPI_CXX:
/usr/lib/libmpi_cxx.so;/usr/lib/libmpi.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libhwloc.so
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
-- Checking for module 'PETSc'
--   Found PETSc, version 3.8.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dhinton/test/build

$ make VERBOSE=1
/usr/local/bin/cmake -H/home/dhinton/test -B/home/dhinton/test/build
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start
/home/dhinton/test/build/CMakeFiles
/home/dhinton/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/dhinton/test/build'
make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/depend
make[2]: Entering directory '/home/dhinton/test/build'
cd /home/dhinton/test/build && /usr/local/bin/cmake -E cmake_depends "Unix
Makefiles" /home/dhinton/test /home/dhinton/test /home/dhinton/test/build
/home/dhinton/test/build
/home/dhinton/test/build/CMakeFiles/main.dir/DependInfo.cmake --color=
Dependee "/home/dhinton/test/build/CMakeFiles/main.dir/DependInfo.cmake" is
newer than depender
"/home/dhinton/test/build/CMakeFiles/main.dir/depend.internal".
Dependee
"/home/dhinton/test/build/CMakeFiles/CMakeDirectoryInformation.cmake" is
newer than depender
"/home/dhinton/test/build/CMakeFiles/main.dir/depend.internal".
Scanning dependencies of target main
make[2]: Leaving directory '/home/dhinton/test/build'
make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/build
make[2]: Entering directory '/home/dhinton/test/build'
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
/usr/local/bin/c++   -I/usr/lib/openmpi/include
-I/usr/lib/openmpi/include/openmpi -I/home/dhinton/usr/include   -o
CMakeFiles/main.dir/main.cpp.o -c /home/dhinton/test/main.cpp
[100%] Linking CXX executable main
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
--verbose=1
/usr/local/bin/c++     -Wl,--enable-new-dtags
CMakeFiles/main.dir/main.cpp.o  -o main  -L/home/dhinton/usr/lib
-Wl,-rpath,":\$ORIGIN/../lib:/home/dhinton/usr/lib" /usr/lib/libmpi_cxx.so
/usr/lib/libmpi.so /usr/lib/x86_64-linux-gnu/libdl.so
/usr/lib/x86_64-linux-gnu/libhwloc.so -lpetsc
make[2]: Leaving directory '/home/dhinton/test/build'
[100%] Built target main
make[1]: Leaving directory '/home/dhinton/test/build'
/usr/local/bin/cmake -E cmake_progress_start
/home/dhinton/test/build/CMakeFiles 0

$ objdump -x main | grep PATH
  RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib

$ objdump -x main | grep PATH
  RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib
a5459ba277d5:/home/dhinton/test/build $ make install
[100%] Built target main
Install the project...
-- Install configuration: ""
-- Installing: /home/dhinton/petsc-test/bin/main

$ objdump -x ~/petsc-test/bin/main | grep PATH
  RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib


On Thu, Jan 4, 2018 at 12:49 PM, Don Hinton <hintonda at gmail.com> wrote:

> This is mostly an ordering problem -- you need to setup everything before
> calling add_executable.  Also, I was wrong about using ';' in RPATH
> variables.  They should use ':' as in your original since they are used
> verbatim.
>
> Here's an example that works:
>
> $ cat ../CMakeLists.txt
> cmake_minimum_required(VERSION 3.7)
> project(main)
>
> enable_language(CXX)
> find_package(MPI REQUIRED)
>
> find_package(PkgConfig REQUIRED)
> pkg_check_modules(PETSc REQUIRED PETSc)
>
> # RPATH variables must be set, and link_directories called. before calling
> add_executable.
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH}:$
> ORIGIN/../lib:${PETSc_LIBRARY_DIRS}")
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
> -Wl,--enable-new-dtags")
> set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
> -Wl,--enable-new-dtags")
> set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
> -Wl,--enable-new-dtags")
> link_directories(${PETSc_LIBRARY_DIRS})
>
> add_executable(main main.cpp)
>
> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH}
> ${PETSc_INCLUDE_DIRS})
> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES} ${PETSc_LIBRARIES})
>
> install(TARGETS main RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
>
> $ make VERBOSE=1
> /usr/local/bin/cmake -H/home/dhinton/test -B/home/dhinton/test/build
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/local/bin/cmake -E cmake_progress_start /home/dhinton/test/build/CMakeFiles
> /home/dhinton/test/build/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory '/home/dhinton/test/build'
> make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/depend
> make[2]: Entering directory '/home/dhinton/test/build'
> cd /home/dhinton/test/build && /usr/local/bin/cmake -E cmake_depends "Unix
> Makefiles" /home/dhinton/test /home/dhinton/test /home/dhinton/test/build
> /home/dhinton/test/build /home/dhinton/test/build/CMakeFiles/main.dir/DependInfo.cmake
> --color=
> make[2]: Leaving directory '/home/dhinton/test/build'
> make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/build
> make[2]: Entering directory '/home/dhinton/test/build'
> make[2]: Nothing to be done for 'CMakeFiles/main.dir/build'.
> make[2]: Leaving directory '/home/dhinton/test/build'
> [100%] Built target main
> make[1]: Leaving directory '/home/dhinton/test/build'
> /usr/local/bin/cmake -E cmake_progress_start /home/dhinton/test/build/CMakeFiles
> 0
>
> $ objdump -x main | grep PATH
>   RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib
>
> $ make install
> [100%] Built target main
> Install the project...
> -- Install configuration: ""
> -- Installing: /home/dhinton/petsc-test/bin/main
>
> $ objdump -x ~/petsc-test/bin/main | grep PATH
>   RUNPATH              :$ORIGIN/../lib:/home/dhinton/usr/lib
>
> hth...
> don
>
> On Thu, Jan 4, 2018 at 9:13 AM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>> not working with the last cmakelist I have which is:
>>
>> >> more ../CMakeLists.txt
>> cmake_minimum_required(VERSION 3.7)
>> enable_language(CXX)
>>
>> find_package(MPI REQUIRED)
>> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
>> pkg_check_modules(PETSc REQUIRED PETSc)
>>
>> project(main)
>> add_executable(main main.cpp)
>>
>> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
>> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>>
>> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
>> foreach(lib ${PETSc_LDFLAGS})
>>   target_link_libraries(main PUBLIC ${lib})
>>   message("target_link_libraries - lib is ${lib}")
>> endforeach(lib)
>>
>> # use, i.e. don't skip the full RPATH for the build tree
>> SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
>> # when building, don't use the install RPATH already
>> # (but later on when installing)
>> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
>> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib;$
>> {CMAKE_INSTALL_RPATH}")
>> # add the automatically determined parts of the RPATH
>> # which point to directories outside the build tree to the install RPATH
>> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>> # the RPATH to be used when installing, but only if it's not a system
>> directory
>> LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
>> "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
>> IF("${isSystemDir}" STREQUAL "-1")
>>    SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib;$
>> {CMAKE_INSTALL_RPATH}")
>> ENDIF("${isSystemDir}" STREQUAL "-1")
>> foreach(dir ${PETSc_LIBRARY_DIRS})
>>   link_directories(main PUBLIC ${dir})
>>   message("link_directories - dir is ${dir}")
>>   set(CMAKE_INSTALL_RPATH "${dir};${CMAKE_INSTALL_RPATH}")
>> endforeach(dir)
>> message("CMAKE_INSTALL_RPATH: ${CMAKE_INSTALL_RPATH}")
>>
>> include(CTest)
>> enable_testing()
>> add_test(NAME main COMMAND "mpirun -n 2 ./main" WORKING_DIRECTORY
>> "${CMAKE_CURRENT_BINARY_DIR}")
>>
>> ------------------------------
>>
>> *De: *"Don Hinton" <hintonda at gmail.com>
>> *?: *"Franck Houssen" <franck.houssen at inria.fr>
>> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, "CMake Mail List" <
>> cmake at cmake.org>
>> *Envoy?: *Jeudi 4 Janvier 2018 17:47:19
>>
>> *Objet: *Re: [CMake] RPATH for pkg-config
>>
>> Are you still doing this at the end?  You are overwriting here, not
>> adding.
>>
>> IF("${isSystemDir}" STREQUAL "-1")
>>    SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>> ENDIF("${isSystemDir}" STREQUAL "-1")
>>
>> Also, do not use ':', use ';' instead as a separator.  Or use
>> 'list(APPEND ...), to add to a list.
>>
>> On Thu, Jan 4, 2018 at 8:34 AM, Franck Houssen <franck.houssen at inria.fr>
>> wrote:
>>
>>> nope !... :D
>>>
>>> ------------------------------
>>>
>>> *De: *"Don Hinton" <hintonda at gmail.com>
>>> *?: *"Franck Houssen" <franck.houssen at inria.fr>
>>> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
>>> *Envoy?: *Jeudi 4 Janvier 2018 16:52:53
>>> *Objet: *Re: [CMake] RPATH for pkg-config
>>>
>>>
>>> On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen <franck.houssen at inria.fr>
>>> wrote:
>>>
>>>> ------------------------------
>>>>
>>>> *De: *"Don Hinton" <hintonda at gmail.com>
>>>> *?: *"Franck Houssen" <franck.houssen at inria.fr>
>>>> *Cc: *"Andreas Naumann" <Andreas-Naumann at gmx.net>, cmake at cmake.org
>>>> *Envoy?: *Jeudi 4 Janvier 2018 10:43:28
>>>>
>>>>
>>>> *Objet: *Re: [CMake] RPATH for pkg-config
>>>>
>>>> The cmake rpath settings handle build/install directories more or less
>>>> automatically, but you need to add a completely different path.
>>>>
>>>>
>>>> Yes. That's the problem: I need to add a completely different path.
>>>>
>>>>
>>>> Try adding the additional path (pretty much every -L you added) to
>>>> CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
>>>>
>>>>
>>>> See does not work
>>>>
>>>> >> more ../CMakeLists.txt
>>>> ...
>>>>
>>>> foreach(dir ${PETSc_LIBRARY_DIRS})
>>>>   link_directories(main PUBLIC ${dir})
>>>>   message("link_directories - dir is ${dir}")
>>>>   set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
>>>> endforeach(dir)
>>>>
>>>
>>> s/:/;/
>>>
>>>
>>>> You need to use a semicolon instead is a colon as a cmake list
>>> separator.
>>>
>>>
>>>
>>> I wish it could have worked. Don't understand.
>>>
>>> I added a message
>>>
>>> >> cmake ..; make VERBOSE=1
>>> ...
>>> target_link_libraries - lib is -L/home/fghoussen/Documents/IN
>>> RIA/petsc/local/lib
>>> target_link_libraries - lib is -lpetsc
>>> link_directories - dir is /home/fghoussen/Documents/INRI
>>> A/petsc/local/lib
>>> CMAKE_INSTALL_RPATH: /home/fghoussen/Documents/INRI
>>> A/petsc/local/lib;/usr/local/lib;/usr/local/lib;
>>> ...
>>> >> ldd main
>>>     linux-vdso.so.1 (0x00007ffdec8e8000)
>>>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
>>> (0x00007f429a28a000)
>>>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
>>> (0x00007f4299f94000)
>>>     libpetsc.so.3.8 => not found
>>>
>>>
>>>
>>>> ...
>>>> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
>>>> ...
>>>>
>>>> >> cmake ..; make VERBOSE=1
>>>> ...
>>>> target_link_libraries - lib is -L/home/fghoussen/Documents/IN
>>>> RIA/petsc/local/lib
>>>> target_link_libraries - lib is -lpetsc
>>>> link_directories - dir is /home/fghoussen/Documents/INRI
>>>> A/petsc/local/lib
>>>> ...
>>>> [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
>>>> /usr/bin/c++   -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
>>>> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent
>>>> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca
>>>> /event/libevent2022/libevent/include -I/usr/lib/x86_64-linux-gnu/openmpi/include
>>>> -I/home/fghoussen/Documents/INRIA/petsc/local/include   -o
>>>> CMakeFiles/main.dir/main.cpp.o -c /home/fghoussen/Downloads/cmak
>>>> e/rpath-pkgconfig/main.cpp
>>>> [100%] Linking CXX executable main
>>>> /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
>>>> --verbose=1
>>>> /usr/bin/c++     CMakeFiles/main.dir/main.cpp.o  -o main
>>>> -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
>>>> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
>>>> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
>>>> -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
>>>> make[2]: Leaving directory '/home/fghoussen/Downloads/cma
>>>> ke/rpath-pkgconfig/BUILD'
>>>> [100%] Built target main
>>>> make[1]: Leaving directory '/home/fghoussen/Downloads/cma
>>>> ke/rpath-pkgconfig/BUILD'
>>>> /usr/bin/cmake -E cmake_progress_start /home/fghoussen/Downloads/cmak
>>>> e/rpath-pkgconfig/BUILD/CMakeFiles 0
>>>>
>>>> >> ldd main
>>>>     linux-vdso.so.1 (0x00007ffcd876b000)
>>>>     libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
>>>> (0x00007f9eaba1f000)
>>>>     libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
>>>> (0x00007f9eab729000)
>>>>     libpetsc.so.3.8 => not found
>>>>
>>>>
>>>> Then run cmake with the ?-v? option and look at the link command to
>>>> verify rpath was passed correctly.
>>>>
>>>> You can also examine it in a library or executable with ?objdump-x?.
>>>>
>>>> You may want to customize this for your project, but this should get
>>>> you started.
>>>>
>>>> hth...
>>>> don
>>>>
>>>> On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <franck.houssen at inria.fr>
>>>> wrote:
>>>>
>>>>> My understanding is that you need a local copy of FindPETSc.cmake: if
>>>>> this changes, you don't know it.
>>>>> That's why I tried to go with the pc file.
>>>>>
>>>>> ----- Mail original -----
>>>>> > De: "Andreas Naumann" <Andreas-Naumann at gmx.net>
>>>>> > ?: cmake at cmake.org
>>>>> > Envoy?: Mercredi 3 Janvier 2018 21:41:51
>>>>> > Objet: Re: [CMake] RPATH for pkg-config
>>>>> >
>>>>> > What about using a FindPETSC-Module? Some hints are
>>>>> >      *http://jacobmerson.com/2016/01/17/cmake-petsc2.html
>>>>> >      *http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
>>>>> >
>>>>> > Regards,
>>>>> > Andreas
>>>>> >
>>>>> > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
>>>>> > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
>>>>> > >> Hello,
>>>>> > >>
>>>>> > >> How to ask cmake to add a library path (coming from pc file) to
>>>>> rpath ?
>>>>> > >>
>>>>> > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but
>>>>> still not
>>>>> > >> working. Can somebody help ?
>>>>> > >>>> more main.cpp
>>>>> > >> #include <petsc.h>
>>>>> > >>
>>>>> > >> int main(int argc, char ** argv) {
>>>>> > >> PetscInitialize(&argc, &argv, NULL, "");
>>>>> > >> PetscFinalize();
>>>>> > >> return 0;
>>>>> > >> }
>>>>> > >>
>>>>> > >>>> more CMakeLists.txt
>>>>> > >> cmake_minimum_required(VERSION 3.7)
>>>>> > >> enable_language(CXX)
>>>>> > >>
>>>>> > >> find_package(MPI REQUIRED)
>>>>> > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
>>>>> > >> pkg_check_modules(PETSc REQUIRED PETSc)
>>>>> > >>
>>>>> > >> project(main)
>>>>> > >> add_executable(main main.cpp)
>>>>> > >>
>>>>> > >> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
>>>>> > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
>>>>> > >>
>>>>> > >> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
>>>>> > >> foreach(lib ${PETSc_LDFLAGS})
>>>>> > >> target_link_libraries(main PUBLIC ${lib})
>>>>> > >> endforeach(lib)
>>>>> > > How does each ${lib} look like ?
>>>>> > > Is it "-lpetsc" or does it have the full path to the libraries ?
>>>>> > > You should use the full path to the libraries, otherwise cmake
>>>>> doesn't know
>>>>> > > where they are and the RPATH computation will not work.
>>>>> > >
>>>>> > >> foreach(dir ${PETSc_LIBRARY_DIRS})
>>>>> > >> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>>>>> > >> endforeach(dir)
>>>>> > > no, link_directories() in general should not be used.
>>>>> > >
>>>>> > >> # use, i.e. don't skip the full RPATH for the build tree
>>>>> > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
>>>>> > >> # when building, don't use the install RPATH already
>>>>> > >> # (but later on when installing)
>>>>> > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>>>> > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>>>>> > > If the automatic computation fails, you could add the petsc lib
>>>>> dir here as
>>>>> > > INSTALL_RPATH
>>>>> > >
>>>>> > > 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:
>>>>> > 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
>>>>>
>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/d4360245/attachment-0001.html>

From a.neundorf-work at gmx.net  Thu Jan  4 16:04:02 2018
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Thu, 04 Jan 2018 22:04:02 +0100
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <485724957.13555203.1515056786197.JavaMail.zimbra@inria.fr>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
 <485724957.13555203.1515056786197.JavaMail.zimbra@inria.fr>
Message-ID: <10597187.lMEi4cFInX@linux-l7nd>

On 2018 M01 4, Thu 10:06:26 CET Franck Houssen wrote:
...
> ...
> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> foreach(lib ${PETSc_LDFLAGS})
>   target_link_libraries(main PUBLIC ${lib})
>   message("target_link_libraries - lib is ${lib}")
> endforeach(lib)
> 
> foreach(dir ${PETSc_LIBRARY_DIRS})
>   link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>   message("link_directories - dir is ${dir}")
> endforeach(dir)
> 
> This gives:
> >> cmake ..; make
> 
> ...
> target_link_libraries - lib is -L/path/to/petsc/local/lib
> target_link_libraries - lib is -lpetsc
> link_directories - dir is /path/to/petsc/local/lib

yes, so cmake doesn't know that it will link to /path/to/petsc/local/lib/
libpetsc.so .
I usually recommend to use the results from pkgconfig as input to find_library() 
etc. calls, ie. put the directory reported by pkgconfig in the HINTS section of 
find_library(). This should then return the full path to the library, which you 
can then use in target_link_libraries(), and cmake will take care of the 
rpath.

...
> >> ldd main
> 
> 	linux-vdso.so.1 (0x00007ffebab8a000)
> 	libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> (0x00007f36172e3000) libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> (0x00007f3616fed000) libpetsc.so.3.8 => not found


you can also use readelf or objdump to see the RPATH entry in the ELF file 
directly.

Alex


From a.neundorf-work at gmx.net  Thu Jan  4 16:09:28 2018
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Thu, 04 Jan 2018 22:09:28 +0100
Subject: [CMake] coding style for modules
In-Reply-To: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
References: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
Message-ID: <3422174.69viOdHLWS@linux-l7nd>

On 2018 M01 4, Thu 05:09:54 CET Dave Milter wrote:
> Hello,
> 
> If there is some libfoo that I want to use in my project,
> and this libfoo has it's own CMakeLists.txt I have 3 options to deal
> with such external dependency:
> 
> a) Treat it like every other external dependency and write cmake code
>   like FindLibFoo.cmake to find libfoo on file system.

This would be a clean solution if you don't want to build libfoo as part of 
your project.

> b)Include this project as git submodule and use ExternalProject to
> invoke `cmake` and `cmake --build`

This would be a clean solution if you want to build libfoo as part of yur 
project.

> 
> c)Include this project as git submodule and use add_subdirectory(libfoo)

the "parent" project will/can influence the behaviour of libfoo then, I would 
not recommend this.

Or use d) as Alan suggests.

Alex


From sam.lunt at transmarketgroup.com  Thu Jan  4 16:42:10 2018
From: sam.lunt at transmarketgroup.com (Sam Lunt)
Date: Thu, 4 Jan 2018 15:42:10 -0600
Subject: [CMake] CPack per-component value for
 CPACK_PACKAGING_INSTALL_PREFIX when using RPM generator
In-Reply-To: <CAKgx6B+JLYa1VL3X9vN37ZR3y9_-9gCVE8NuegRnyuxdSZsPPw@mail.gmail.com>
References: <CADjN2kdKd41YAYy=JH=WtAkAFwsLoiXQnZ5Fmzz3nzC80bTopw@mail.gmail.com>
 <CAKgx6B+JLYa1VL3X9vN37ZR3y9_-9gCVE8NuegRnyuxdSZsPPw@mail.gmail.com>
Message-ID: <CADjN2kcUSu_H1RoSc_W0i5T9ZBbdHGo5UYwd_CEsg8A76PvAmw@mail.gmail.com>

Hi Domen,

Thanks for the reply, but that doesn't seem to work for me. I modified
my example to add this function call:

list(APPEND CPACK_RPM_RELOCATION_PATHS
    ${CPACK_PACKAGING_INSTALL_PREFIX}
)

that silences the warnings, but it still prepends the
CPACK_PACKAGING_INSTALL_PREFIX when generating the RPM files, while I
want it to prepend CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX.

So if I call "rpm -qlp FooBar-0.1.0-Linux-Bar_Comp.rpm", it outputs:
/tmp_dir/foobar
/tmp_dir/foobar/bin
/tmp_dir/foobar/bin/bar

(CPACK_PACKAGING_INSTALL_PREFIX = /tmp_dir/foobar)

I want it to output:

/tmp_dir/bar
/tmp_dir/bar/bin
/tmp_dir/bar/bin/bar

(CPACK_RPM_BAR_COMP_PACKAGE_PREFIX = /tmp_dir/bar)

It seems like cpack is prepending the CPACK_PACKAGING_INSTALL_PREFIX
to any relative paths before actually calling the CPackRPM.cmake
module, so by the time CPackRPM sees the paths, it is seeing
/tmp_dir/foobar/bin/bar and /tmp_dir/foobar/bin/foo, while I want it
to see /tmp_dir/bar/bin/bar and /tmp_dir/foo/bin/foo. Maybe there is
no way to achieve this currently?

Thanks,
Sam

On Thu, Jan 4, 2018 at 1:51 PM, Domen Vrankar <domen.vrankar at gmail.com> wrote:
> 2018-01-03 22:40 GMT+01:00 Sam Lunt <sam.lunt at transmarketgroup.com>:
>>
>> I am trying to set a per-component value for
>> CPACK_PACKAGING_INSTALL_PREFIX when using the RPM generator, but I
>> haven't been able to do so.
>>
>> I would like to be able to:
>> 1. Install using "make install" (or cmake --build ${BUILD_DIR}
>> --target install) and have CMAKE_INSTALL_PREFIX control the install
>> location
>> 2. Generate an rpm file for each component such that the rpm is
>> relocatable (i.e. --prefix and --relocate are supported) and each
>> component has a different default installation location
>>
>> The documentation for CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX seems to
>> indicate that it is the correct way to set a per-component install
>> prefix, since it says that CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX "May
>> be used to set per component CPACK_PACKAGING_INSTALL_PREFIX for
>> relocatable RPM packages." However, I am only able to successfully use
>> this if I provide an absolute path to the install command, but that
>> inhibits the use of CMAKE_INSTALL_PREFIX.
>
>
> How about using CPACK_RPM_RELOCATION_PATHS?
> https://cmake.org/cmake/help/v3.10/module/CPackRPM.html#variable:CPACK_RPM_RELOCATION_PATHS
>
> install(DIRECTORY DESTINATION ${CMAKE_INSTALL_LIBDIR}/some_dir COMPONENT
> libraries)
> set(CPACK_RPM_RELOCATION_PATHS "${CMAKE_INSTALL_INCLUDEDIR}"
>   "${CMAKE_INSTALL_LIBDIR}")
>
> You specify all the relocation paths for all components and if one or more
> of them are found during package generation that path is written to the
> package as a relocation path.
> You can also use
> https://cmake.org/cmake/help/v3.10/module/CPackRPM.html#variable:CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION
> to discard CPACK_PACKAGING_INSTALL_PREFIX as a relocation path.
>
> This feature can also (is prefered to) be used in combination with
> GNUInstallDirs module
> (https://cmake.org/cmake/help/v3.10/module/GNUInstallDirs.html?highlight=gnuinstalldirs):
>
> include(GNUInstallDirs)
>
> Regards,
> Domen

From craig.scott at crascit.com  Thu Jan  4 17:08:01 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 5 Jan 2018 09:08:01 +1100
Subject: [CMake] coding style for modules
In-Reply-To: <3422174.69viOdHLWS@linux-l7nd>
References: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
 <3422174.69viOdHLWS@linux-l7nd>
Message-ID: <CA+dygYkf+g6gDBhLUHuOvsPg=13W+R7wjGxnwZ5L+-cmWLZ+KQ@mail.gmail.com>

On Fri, Jan 5, 2018 at 8:09 AM, Alexander Neundorf <a.neundorf-work at gmx.net>
wrote:

> On 2018 M01 4, Thu 05:09:54 CET Dave Milter wrote:
> >
> > c)Include this project as git submodule and use add_subdirectory(libfoo)
>
> the "parent" project will/can influence the behaviour of libfoo then, I
> would
> not recommend this.
>

It depends on the situation, sometimes you explicitly want this. An
advantage of this approach is that libfoo will then be built with the same
set of flags as the main build (apart from those flags it modifies itself).
It also plays nicely with IDE projects because they will typically see all
the sources of libfoo as well as the main project. You can also end up
building just the targets from libfoo that you need instead of building
everything as you would if it was external. The new FetchContent
<https://cmake.org/cmake/help/git-master/module/FetchContent.html> module
(on master, not yet in a public release) makes this approach particularly
easy.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180105/ebe6beb8/attachment.html>

From domen.vrankar at gmail.com  Thu Jan  4 17:15:51 2018
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 4 Jan 2018 23:15:51 +0100
Subject: [CMake] CPack per-component value for
 CPACK_PACKAGING_INSTALL_PREFIX when using RPM generator
In-Reply-To: <CADjN2kcUSu_H1RoSc_W0i5T9ZBbdHGo5UYwd_CEsg8A76PvAmw@mail.gmail.com>
References: <CADjN2kdKd41YAYy=JH=WtAkAFwsLoiXQnZ5Fmzz3nzC80bTopw@mail.gmail.com>
 <CAKgx6B+JLYa1VL3X9vN37ZR3y9_-9gCVE8NuegRnyuxdSZsPPw@mail.gmail.com>
 <CADjN2kcUSu_H1RoSc_W0i5T9ZBbdHGo5UYwd_CEsg8A76PvAmw@mail.gmail.com>
Message-ID: <CAKgx6BLBbF2GAzSmNjx2Es4toRQML8tw_GLS_Kk54vtTgYK8UQ@mail.gmail.com>

2018-01-04 22:42 GMT+01:00 Sam Lunt <sam.lunt at transmarketgroup.com>:

> Hi Domen,
>
> Thanks for the reply, but that doesn't seem to work for me. I modified
> my example to add this function call:
>
> list(APPEND CPACK_RPM_RELOCATION_PATHS
>     ${CPACK_PACKAGING_INSTALL_PREFIX}
> )
>

The documentation states that CPACK_PACKAGING_INSTALL_PREFIX is prepended
so the way you are using it not how it is supposed to be used.

With your example above I'd do something like this:

include(GNUInstallDirs)
install(TARGETS foo
    DESTINATION "${CMAKE_INSTALL_BINDIR}"
    COMPONENT Foo_Comp
)

install(TARGETS bar
    DESTINATION "a/b/c"
    COMPONENT Bar_Comp
)

list(APPEND CPACK_RPM_RELOCATION_PATHS
    "${CMAKE_INSTALL_BINDIR}" "a/b/c"
)

set(CPACK_PACKAGING_INSTALL_PREFIX "/")

This will make "/", "/${CMAKE_INSTALL_BINDIR}" and "/a/b/c" relocatable
(and if you want to skip / just set CPACK_PACKAGING_INSTALL_PREFIX).

There was a bug in older versions of CPack that CPACK_PACKAGING_INSTALL_PREFIX
could not be set to / (it was fixed by this commit
https://gitlab.kitware.com/cmake/cmake/merge_requests/583/diffs in CMake
3.9 so you can backport it if you want to as it is a small change to
CPackRPM.cmake file).


>
> that silences the warnings, but it still prepends the
> CPACK_PACKAGING_INSTALL_PREFIX when generating the RPM files, while I
> want it to prepend CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX.
>
> So if I call "rpm -qlp FooBar-0.1.0-Linux-Bar_Comp.rpm", it outputs:
> /tmp_dir/foobar
> /tmp_dir/foobar/bin
> /tmp_dir/foobar/bin/bar
>
> (CPACK_PACKAGING_INSTALL_PREFIX = /tmp_dir/foobar)
>
> I want it to output:
>
> /tmp_dir/bar
> /tmp_dir/bar/bin
> /tmp_dir/bar/bin/bar
>
> (CPACK_RPM_BAR_COMP_PACKAGE_PREFIX = /tmp_dir/bar)
>
> It seems like cpack is prepending the CPACK_PACKAGING_INSTALL_PREFIX
> to any relative paths before actually calling the CPackRPM.cmake
> module, so by the time CPackRPM sees the paths, it is seeing
> /tmp_dir/foobar/bin/bar and /tmp_dir/foobar/bin/foo, while I want it
> to see /tmp_dir/bar/bin/bar and /tmp_dir/foo/bin/foo. Maybe there is
> no way to achieve this currently?
>

What you are trying to achieve seems odd to me particularly since your rpms
will be relocatable so why would you want to create the structure of
/some_dir/bar_dir/bin/repeated_bar_dir instead of /bin/bar or
/tmp_dir/bin/bar with either / for the first case or /tmp_dir for the
second case being relocatable?

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180104/a8f4f0a6/attachment.html>

From franck.houssen at inria.fr  Fri Jan  5 03:14:45 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Fri, 5 Jan 2018 09:14:45 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <CAL2T-v5J+sfFxH99yYANqw_OGcM1zHNn25e1VbCDN8GJvkNFmg@mail.gmail.com>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <CAL2T-v7_rVa6Woa-fmvyhnnF1W=WYvf4PjGW9AHmd8e26Dm9=g@mail.gmail.com>
 <1171032489.13714027.1515067049918.JavaMail.zimbra@inria.fr>
 <CAL2T-v7B+Waq5H7ofqgWoEsrwGNZobFY=pLU03qXmF--dM2UqQ@mail.gmail.com>
 <1443583663.13889496.1515083662415.JavaMail.zimbra@inria.fr>
 <CAL2T-v6yXT6iQfRDzd3GwKWFpeJ-AmNZPQAr=f_f213KXPqWsQ@mail.gmail.com>
 <492856152.13910311.1515085998851.JavaMail.zimbra@inria.fr>
 <CAL2T-v5J+sfFxH99yYANqw_OGcM1zHNn25e1VbCDN8GJvkNFmg@mail.gmail.com>
Message-ID: <797274371.14102112.1515140085890.JavaMail.zimbra@inria.fr>

Working !... At last ! Thanks :D 

I suspected an ordering problem: I already tried to change the position of "setting CMAKE_INSTALL_RPATH" before / after "calling target_link_libraries"... But didn't try to do this BEFORE add_executable ! 

Would be nice to add this in the doc https://cmake.org/Wiki/CMake_RPATH_handling : can somebody do that or should I post that to the dev-mail list ?!... 

Anyway, thanks guys 

Franck 

----- Mail original -----

> De: "Don Hinton" <hintonda at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "Andreas Naumann" <Andreas-Naumann at gmx.net>, "CMake Mail List"
> <cmake at cmake.org>
> Envoy?: Jeudi 4 Janvier 2018 21:49:05
> Objet: Re: [CMake] RPATH for pkg-config

> This is mostly an ordering problem -- you need to setup everything before
> calling add_executable. Also, I was wrong about using ';' in RPATH
> variables. They should use ':' as in your original since they are used
> verbatim.

> Here's an example that works:

> $ cat ../CMakeLists.txt
> cmake_minimum_required(VERSION 3.7)
> project(main)

> enable_language(CXX)
> find_package(MPI REQUIRED)

> find_package(PkgConfig REQUIRED)
> pkg_check_modules(PETSc REQUIRED PETSc)

> # RPATH variables must be set, and link_directories called. before calling
> add_executable.
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH
> "${CMAKE_INSTALL_RPATH}:$ORIGIN/../lib:${PETSc_LIBRARY_DIRS}")
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
> -Wl,--enable-new-dtags")
> set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
> -Wl,--enable-new-dtags")
> set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
> -Wl,--enable-new-dtags")
> link_directories(${PETSc_LIBRARY_DIRS})

> add_executable(main main.cpp)

> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH}
> ${PETSc_INCLUDE_DIRS})
> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES} ${PETSc_LIBRARIES})

> install(TARGETS main RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)

> $ make VERBOSE=1
> /usr/local/bin/cmake -H/home/dhinton/test -B/home/dhinton/test/build
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/local/bin/cmake -E cmake_progress_start
> /home/dhinton/test/build/CMakeFiles
> /home/dhinton/test/build/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory '/home/dhinton/test/build'
> make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/depend
> make[2]: Entering directory '/home/dhinton/test/build'
> cd /home/dhinton/test/build && /usr/local/bin/cmake -E cmake_depends "Unix
> Makefiles" /home/dhinton/test /home/dhinton/test /home/dhinton/test/build
> /home/dhinton/test/build
> /home/dhinton/test/build/CMakeFiles/main.dir/DependInfo.cmake --color=
> make[2]: Leaving directory '/home/dhinton/test/build'
> make -f CMakeFiles/main.dir/build.make CMakeFiles/main.dir/build
> make[2]: Entering directory '/home/dhinton/test/build'
> make[2]: Nothing to be done for 'CMakeFiles/main.dir/build'.
> make[2]: Leaving directory '/home/dhinton/test/build'
> [100%] Built target main
> make[1]: Leaving directory '/home/dhinton/test/build'
> /usr/local/bin/cmake -E cmake_progress_start
> /home/dhinton/test/build/CMakeFiles 0

> $ objdump -x main | grep PATH
> RUNPATH :$ORIGIN/../lib:/home/dhinton/usr/lib

> $ make install
> [100%] Built target main
> Install the project...
> -- Install configuration: ""
> -- Installing: /home/dhinton/petsc-test/bin/main

> $ objdump -x ~/petsc-test/bin/main | grep PATH
> RUNPATH :$ORIGIN/../lib:/home/dhinton/usr/lib

> hth...
> don

> On Thu, Jan 4, 2018 at 9:13 AM, Franck Houssen < franck.houssen at inria.fr >
> wrote:

> > not working with the last cmakelist I have which is:
> 

> > >> more ../CMakeLists.txt
> 
> > cmake_minimum_required(VERSION 3.7)
> 
> > enable_language(CXX)
> 

> > find_package(MPI REQUIRED)
> 
> > find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> 
> > pkg_check_modules(PETSc REQUIRED PETSc)
> 

> > project(main)
> 
> > add_executable(main main.cpp)
> 

> > target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> 
> > target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> 

> > target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> 
> > foreach(lib ${PETSc_LDFLAGS})
> 
> > target_link_libraries(main PUBLIC ${lib})
> 
> > message("target_link_libraries - lib is ${lib}")
> 
> > endforeach(lib)
> 

> > # use, i.e. don't skip the full RPATH for the build tree
> 
> > SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> 
> > # when building, don't use the install RPATH already
> 
> > # (but later on when installing)
> 
> > SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> 
> > SET(CMAKE_INSTALL_RPATH
> > "${CMAKE_INSTALL_PREFIX}/lib;${CMAKE_INSTALL_RPATH}")
> 
> > # add the automatically determined parts of the RPATH
> 
> > # which point to directories outside the build tree to the install RPATH
> 
> > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> 
> > # the RPATH to be used when installing, but only if it's not a system
> > directory
> 
> > LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
> > "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
> 
> > IF("${isSystemDir}" STREQUAL "-1")
> 
> > SET(CMAKE_INSTALL_RPATH
> > "${CMAKE_INSTALL_PREFIX}/lib;${CMAKE_INSTALL_RPATH}")
> 
> > ENDIF("${isSystemDir}" STREQUAL "-1")
> 
> > foreach(dir ${PETSc_LIBRARY_DIRS})
> 
> > link_directories(main PUBLIC ${dir})
> 
> > message("link_directories - dir is ${dir}")
> 
> > set(CMAKE_INSTALL_RPATH "${dir};${CMAKE_INSTALL_RPATH}")
> 
> > endforeach(dir)
> 
> > message("CMAKE_INSTALL_RPATH: ${CMAKE_INSTALL_RPATH}")
> 

> > include(CTest)
> 
> > enable_testing()
> 
> > add_test(NAME main COMMAND "mpirun -n 2 ./main" WORKING_DIRECTORY
> > "${CMAKE_CURRENT_BINARY_DIR}")
> 

> > > De: "Don Hinton" < hintonda at gmail.com >
> > 
> 
> > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > 
> 
> > > Cc: "Andreas Naumann" < Andreas-Naumann at gmx.net >, "CMake Mail List" <
> > > cmake at cmake.org >
> > 
> 
> > > Envoy?: Jeudi 4 Janvier 2018 17:47:19
> > 
> 

> > > Objet: Re: [CMake] RPATH for pkg-config
> > 
> 

> > > Are you still doing this at the end? You are overwriting here, not
> > > adding.
> > 
> 

> > > IF("${isSystemDir}" STREQUAL "-1")
> > 
> 
> > > SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > 
> 
> > > ENDIF("${isSystemDir}" STREQUAL "-1")
> > 
> 

> > > Also, do not use ':', use ';' instead as a separator. Or use 'list(APPEND
> > > ...), to add to a list.
> > 
> 

> > > On Thu, Jan 4, 2018 at 8:34 AM, Franck Houssen < franck.houssen at inria.fr
> > > >
> > > wrote:
> > 
> 

> > > > nope !... :D
> > > 
> > 
> 

> > > > > De: "Don Hinton" < hintonda at gmail.com >
> > > > 
> > > 
> > 
> 
> > > > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > > > 
> > > 
> > 
> 
> > > > > Cc: "Andreas Naumann" < Andreas-Naumann at gmx.net >, cmake at cmake.org
> > > > 
> > > 
> > 
> 
> > > > > Envoy?: Jeudi 4 Janvier 2018 16:52:53
> > > > 
> > > 
> > 
> 
> > > > > Objet: Re: [CMake] RPATH for pkg-config
> > > > 
> > > 
> > 
> 

> > > > > On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen <
> > > > > franck.houssen at inria.fr
> > > > > >
> > > > > wrote:
> > > > 
> > > 
> > 
> 

> > > > > > > De: "Don Hinton" < hintonda at gmail.com >
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Cc: "Andreas Naumann" < Andreas-Naumann at gmx.net >,
> > > > > > > cmake at cmake.org
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Envoy?: Jeudi 4 Janvier 2018 10:43:28
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Objet: Re: [CMake] RPATH for pkg-config
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > The cmake rpath settings handle build/install directories more or
> > > > > > > less
> > > > > > > automatically, but you need to add a completely different path.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > Yes. That's the problem: I need to add a completely different path.
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > Try adding the additional path (pretty much every -L you added)
> > > > > > > to
> > > > > > > CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > See does not work
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > >> more ../CMakeLists.txt
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > ...
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > foreach(dir ${PETSc_LIBRARY_DIRS})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > link_directories(main PUBLIC ${dir})
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > message("link_directories - dir is ${dir}")
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > set(CMAKE_INSTALL_RPATH "${dir}:${CMAKE_INSTALL_RPATH}")
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > endforeach(dir)
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > s/:/;/
> > > > 
> > > 
> > 
> 

> > > > > You need to use a semicolon instead is a colon as a cmake list
> > > > > separator.
> > > > 
> > > 
> > 
> 

> > > > I wish it could have worked. Don't understand.
> > > 
> > 
> 

> > > > I added a message
> > > 
> > 
> 

> > > > >> cmake ..; make VERBOSE=1
> > > 
> > 
> 
> > > > ...
> > > 
> > 
> 
> > > > target_link_libraries - lib is
> > > > -L/home/fghoussen/Documents/INRIA/petsc/local/lib
> > > 
> > 
> 
> > > > target_link_libraries - lib is -lpetsc
> > > 
> > 
> 
> > > > link_directories - dir is
> > > > /home/fghoussen/Documents/INRIA/petsc/local/lib
> > > 
> > 
> 
> > > > CMAKE_INSTALL_RPATH:
> > > > /home/fghoussen/Documents/INRIA/petsc/local/lib;/usr/local/lib;/usr/local/lib;
> > > 
> > 
> 
> > > > ...
> > > 
> > 
> 
> > > > >> ldd main
> > > 
> > 
> 
> > > > linux-vdso.so.1 (0x00007ffdec8e8000)
> > > 
> > 
> 
> > > > libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> > > > (0x00007f429a28a000)
> > > 
> > 
> 
> > > > libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> > > > (0x00007f4299f94000)
> > > 
> > 
> 
> > > > libpetsc.so.3.8 => not found
> > > 
> > 
> 

> > > > > > ...
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > ...
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > >> cmake ..; make VERBOSE=1
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > ...
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > target_link_libraries - lib is
> > > > > > -L/home/fghoussen/Documents/INRIA/petsc/local/lib
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > target_link_libraries - lib is -lpetsc
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > link_directories - dir is
> > > > > > /home/fghoussen/Documents/INRIA/petsc/local/lib
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > ...
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > [ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > /usr/bin/c++ -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
> > > > > > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent
> > > > > > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
> > > > > > -I/usr/lib/x86_64-linux-gnu/openmpi/include
> > > > > > -I/home/fghoussen/Documents/INRIA/petsc/local/include -o
> > > > > > CMakeFiles/main.dir/main.cpp.o -c
> > > > > > /home/fghoussen/Downloads/cmake/rpath-pkgconfig/main.cpp
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > [100%] Linking CXX executable main
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > /usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt
> > > > > > --verbose=1
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > /usr/bin/c++ CMakeFiles/main.dir/main.cpp.o -o main
> > > > > > -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib
> > > > > > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
> > > > > > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
> > > > > > -L/home/fghoussen/Documents/INRIA/petsc/local/lib -lpetsc
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > make[2]: Leaving directory
> > > > > > '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > [100%] Built target main
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > make[1]: Leaving directory
> > > > > > '/home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD'
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > /usr/bin/cmake -E cmake_progress_start
> > > > > > /home/fghoussen/Downloads/cmake/rpath-pkgconfig/BUILD/CMakeFiles 0
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > >> ldd main
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > linux-vdso.so.1 (0x00007ffcd876b000)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> > > > > > (0x00007f9eaba1f000)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> > > > > > (0x00007f9eab729000)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > libpetsc.so.3.8 => not found
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > Then run cmake with the ?-v? option and look at the link command
> > > > > > > to
> > > > > > > verify
> > > > > > > rpath was passed correctly.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > You can also examine it in a library or executable with
> > > > > > > ?objdump-x?.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > You may want to customize this for your project, but this should
> > > > > > > get
> > > > > > > you
> > > > > > > started.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > hth...
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > don
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > On Thu, Jan 4, 2018 at 1:25 AM Franck Houssen <
> > > > > > > franck.houssen at inria.fr
> > > > > > > >
> > > > > > > wrote:
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > > My understanding is that you need a local copy of
> > > > > > > > FindPETSc.cmake:
> > > > > > > > if
> > > > > > > > this
> > > > > > > > changes, you don't know it.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > That's why I tried to go with the pc file.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > > ----- Mail original -----
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > De: "Andreas Naumann" < Andreas-Naumann at gmx.net >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > ?: cmake at cmake.org
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > Envoy?: Mercredi 3 Janvier 2018 21:41:51
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > Objet: Re: [CMake] RPATH for pkg-config
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > What about using a FindPETSC-Module? Some hints are
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > * http://jacobmerson.com/2016/01/17/cmake-petsc2.html
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > * http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > Regards,
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > Andreas
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> Hello,
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> How to ask cmake to add a library path (coming from pc
> > > > > > > > > >> file)
> > > > > > > > > >> to
> > > > > > > > > >> rpath
> > > > > > > > > >> ?
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> I checked this https://cmake.org/Wiki/CMake_RPATH_handling
> > > > > > > > > >> ,
> > > > > > > > > >> but
> > > > > > > > > >> still
> > > > > > > > > >> not
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> working. Can somebody help ?
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>>> more main.cpp
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> #include <petsc.h>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> int main(int argc, char ** argv) {
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> PetscInitialize(&argc, &argv, NULL, "");
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> PetscFinalize();
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> return 0;
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> }
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>>> more CMakeLists.txt
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> cmake_minimum_required(VERSION 3.7)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> enable_language(CXX)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> find_package(MPI REQUIRED)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> pkg_check_modules(PETSc REQUIRED PETSc)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> project(main)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> add_executable(main main.cpp)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> target_include_directories(main PUBLIC
> > > > > > > > > >> ${MPI_CXX_INCLUDE_PATH})
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> target_include_directories(main PUBLIC
> > > > > > > > > >> ${PETSc_INCLUDE_DIRS})
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> foreach(lib ${PETSc_LDFLAGS})
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> target_link_libraries(main PUBLIC ${lib})
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> endforeach(lib)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > How does each ${lib} look like ?
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > Is it "-lpetsc" or does it have the full path to the
> > > > > > > > > > libraries
> > > > > > > > > > ?
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > You should use the full path to the libraries, otherwise
> > > > > > > > > > cmake
> > > > > > > > > > doesn't
> > > > > > > > > > know
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > where they are and the RPATH computation will not work.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> foreach(dir ${PETSc_LIBRARY_DIRS})
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> link_directories(main PUBLIC ${dir}) # Not sure: is this
> > > > > > > > > >> needed
> > > > > > > > > >> ?
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> endforeach(dir)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > no, link_directories() in general should not be used.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> # use, i.e. don't skip the full RPATH for the build tree
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> # when building, don't use the install RPATH already
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> # (but later on when installing)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > If the automatic computation fails, you could add the petsc
> > > > > > > > > > lib
> > > > > > > > > > dir
> > > > > > > > > > here
> > > > > > > > > > as
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > INSTALL_RPATH
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > > 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:
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > > > 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
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180105/fc11993b/attachment-0001.html>

From franck.houssen at inria.fr  Fri Jan  5 03:16:57 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Fri, 5 Jan 2018 09:16:57 +0100 (CET)
Subject: [CMake] RPATH for pkg-config
In-Reply-To: <10597187.lMEi4cFInX@linux-l7nd>
References: <1396609947.13133227.1514970489687.JavaMail.zimbra@inria.fr>
 <3575224.lCVmBBQUTJ@linux-l7nd>
 <485724957.13555203.1515056786197.JavaMail.zimbra@inria.fr>
 <10597187.lMEi4cFInX@linux-l7nd>
Message-ID: <1538432804.14102961.1515140217602.JavaMail.zimbra@inria.fr>



----- Mail original -----
> De: "Alexander Neundorf" <a.neundorf-work at gmx.net>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: cmake at cmake.org
> Envoy?: Jeudi 4 Janvier 2018 22:04:02
> Objet: Re: [CMake] RPATH for pkg-config
> 
> On 2018 M01 4, Thu 10:06:26 CET Franck Houssen wrote:
> ...
> > ...
> > target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> > foreach(lib ${PETSc_LDFLAGS})
> >   target_link_libraries(main PUBLIC ${lib})
> >   message("target_link_libraries - lib is ${lib}")
> > endforeach(lib)
> > 
> > foreach(dir ${PETSc_LIBRARY_DIRS})
> >   link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> >   message("link_directories - dir is ${dir}")
> > endforeach(dir)
> > 
> > This gives:
> > >> cmake ..; make
> > 
> > ...
> > target_link_libraries - lib is -L/path/to/petsc/local/lib
> > target_link_libraries - lib is -lpetsc
> > link_directories - dir is /path/to/petsc/local/lib
> 
> yes, so cmake doesn't know that it will link to /path/to/petsc/local/lib/
> libpetsc.so .
> I usually recommend to use the results from pkgconfig as input to
> find_library()
> etc. calls, ie. put the directory reported by pkgconfig in the HINTS section
> of
> find_library(). This should then return the full path to the library, which
> you
> can then use in target_link_libraries(), and cmake will take care of the
> rpath.

Nice recommendation. I wouldn't have thought to do that. I'll give it a try.

> 
> you can also use readelf or objdump to see the RPATH entry in the ELF file
> directly.
> 
> Alex
> 
> 

From davemilter at gmail.com  Fri Jan  5 10:16:08 2018
From: davemilter at gmail.com (Dave Milter)
Date: Fri, 5 Jan 2018 18:16:08 +0300
Subject: [CMake] coding style for modules
In-Reply-To: <3422174.69viOdHLWS@linux-l7nd>
References: <CAJ2oC5MBwybPLLOdwzvXh5cxQHM1MLY-3Dq+VD86Qg=F7AdwtQ@mail.gmail.com>
 <3422174.69viOdHLWS@linux-l7nd>
Message-ID: <CAJ2oC5N+Y8Wui6PpUQ3GAEhVZP78cH21j6KR2nxEJO-xpvy0Fg@mail.gmail.com>

On Fri, Jan 5, 2018 at 12:09 AM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:>
>> b)Include this project as git submodule and use ExternalProject to
>> invoke `cmake` and `cmake --build`
>
> This would be a clean solution if you want to build libfoo as part of yur
> project.
>

Thank you for answer, but how handle cross compilation in this case?
For example I invoke `cmake
-DCMAKE_TOOLCHAIN_FILE=~/Android/Sdk/ndk-bundle/build/cmake/android.toolchain.cmake`
for master project.
Does `cmake` automatically add proper ` -DCMAKE_TOOLCHAIN_FILE=`
option into `cmake` invocation in ExternalProject?

From saadrustam at gmail.com  Fri Jan  5 11:11:56 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Fri, 05 Jan 2018 16:11:56 +0000
Subject: [CMake] CTest not searching for the correct executable
Message-ID: <CAEM70sM=Fyx4FWiDA-7bnH8oXnYczHn79RN3Qve-z3oLHh+tVA@mail.gmail.com>

Hi,

Suppose I have something like this:

add_executable(MyTest main.cpp)
set_target_properties(MyTest
  PROPERTIES
  DEBUG_POSTFIX _d
  RELEASE_POSTFIX _r
  )
add_test(RunTests MyTest) # where MyTest is the <command>

I expect CMake to recognize that "MyTest" has executables that are named
"MyTest_d" and "MyTest_r" and NOT MyTest. I expect this because in the
CMake documentation the <command> can be an executable target where CMake
then replaces it with the location of the executable.

However, what I get is errors when running "ctest" where it complains that
it cannot find "MyTest" when it should really be searching for "MyTest_d"
and "MyTest_r".

Am I doing something wrong or is this a bug in CMake?

Regards,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180105/73b5566c/attachment.html>

From nilsgladitz at gmail.com  Fri Jan  5 11:16:21 2018
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 5 Jan 2018 17:16:21 +0100
Subject: [CMake] CTest not searching for the correct executable
In-Reply-To: <CAEM70sM=Fyx4FWiDA-7bnH8oXnYczHn79RN3Qve-z3oLHh+tVA@mail.gmail.com>
References: <CAEM70sM=Fyx4FWiDA-7bnH8oXnYczHn79RN3Qve-z3oLHh+tVA@mail.gmail.com>
Message-ID: <07072f57-01e5-a106-5428-ed9a8b5b6530@gmail.com>

On 05.01.2018 17:11, Saad Khattak wrote:
> Hi,
>
> Suppose I have something like this:
>
> add_executable(MyTest main.cpp)
> set_target_properties(MyTest
> ? PROPERTIES
> ? DEBUG_POSTFIX _d
> ? RELEASE_POSTFIX _r
> ? )
> add_test(RunTests MyTest) # where MyTest is the <command>
>
> I expect CMake to recognize that "MyTest" has executables that are 
> named "MyTest_d" and "MyTest_r" and NOT MyTest. I expect this because 
> in the CMake documentation the <command> can be an executable target 
> where CMake then replaces it with the location of the executable.
>
> However, what I get is errors when running "ctest" where it complains 
> that it cannot find "MyTest" when it should really be searching for 
> "MyTest_d" and "MyTest_r".
>
> Am I doing something wrong or is this a bug in CMake?

You are using the old signature (without NAME|COMMAND) for which the 
documentation states [1]:
 ??? "Unlike the above |NAME| signature no transformation is performed 
on the command-line to support target names or generator expressions."

Use the new signature instead e.g.:
 ??? add_test(NAME RunTests COMMAND MyTest)

Nils

[1] https://cmake.org/cmake/help/latest/command/add_test.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180105/fc02440c/attachment.html>

From saadrustam at gmail.com  Fri Jan  5 11:45:58 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Fri, 05 Jan 2018 16:45:58 +0000
Subject: [CMake] CTest not searching for the correct executable
In-Reply-To: <07072f57-01e5-a106-5428-ed9a8b5b6530@gmail.com>
References: <CAEM70sM=Fyx4FWiDA-7bnH8oXnYczHn79RN3Qve-z3oLHh+tVA@mail.gmail.com>
 <07072f57-01e5-a106-5428-ed9a8b5b6530@gmail.com>
Message-ID: <CAEM70sNrPvZUzSr00PY34dTo=VEsRfuaJa79xKighmxz2DUPyw@mail.gmail.com>

That was it, thanks Nils!

For future reference, after adding the test like Nils suggested, calling
"ctest" wouldn't work as it now needs your configuration:

ctest -C Debug

On Fri, Jan 5, 2018 at 11:16 AM Nils Gladitz <nilsgladitz at gmail.com> wrote:

> On 05.01.2018 17:11, Saad Khattak wrote:
>
> Hi,
>
> Suppose I have something like this:
>
> add_executable(MyTest main.cpp)
> set_target_properties(MyTest
>   PROPERTIES
>   DEBUG_POSTFIX _d
>   RELEASE_POSTFIX _r
>   )
> add_test(RunTests MyTest) # where MyTest is the <command>
>
> I expect CMake to recognize that "MyTest" has executables that are named
> "MyTest_d" and "MyTest_r" and NOT MyTest. I expect this because in the
> CMake documentation the <command> can be an executable target where CMake
> then replaces it with the location of the executable.
>
> However, what I get is errors when running "ctest" where it complains that
> it cannot find "MyTest" when it should really be searching for "MyTest_d"
> and "MyTest_r".
>
> Am I doing something wrong or is this a bug in CMake?
>
>
> You are using the old signature (without NAME|COMMAND) for which the
> documentation states [1]:
>     "Unlike the above NAME signature no transformation is performed on
> the command-line to support target names or generator expressions."
>
> Use the new signature instead e.g.:
>     add_test(NAME RunTests COMMAND MyTest)
>
> Nils
>
> [1] https://cmake.org/cmake/help/latest/command/add_test.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180105/c1a7adb9/attachment.html>

From stephen.orso at outlook.com  Fri Jan  5 15:40:59 2018
From: stephen.orso at outlook.com (Stephen Orso)
Date: Fri, 5 Jan 2018 20:40:59 +0000
Subject: [CMake] coding style for modules
In-Reply-To: <mailman.1.1515171602.31562.cmake@cmake.org>
References: <mailman.1.1515171602.31562.cmake@cmake.org>
Message-ID: <MWHPR06MB3583F45728B2BD2B8604C8D5821C0@MWHPR06MB3583.namprd06.prod.outlook.com>


On Fri, 5 Jan 2018 18:16:08 +0300 Dave Milter <davemilter at gmail.com> wrote:
> b)Include this project as git submodule and use ExternalProject to
>>> invoke `cmake` and `cmake --build`
>> This would be a clean solution if you want to build libfoo as part of yur
>> project.
>>
> Thank you for answer, but how handle cross compilation in this case?
> For example I invoke `cmake
> -DCMAKE_TOOLCHAIN_FILE=~/Android/Sdk/ndk-bundle/build/cmake/android.toolchain.cmake`
> for master project.
> Does `cmake` automatically add proper ` -DCMAKE_TOOLCHAIN_FILE=`
> option into `cmake` invocation in ExternalProject?
I haven't gotten to cross compilation yet, but my CMake project uses
externalproject_add for several modules.? I want them built using the
same generator and the same configuration type as the parent (consuming)
project.? Some of the allowed generators for this project are 
multi-configuration,
and some are not.

I use the following CMake code:

<CMake code>

# WINTARGET is needed by the configure-time external package build
# and for the creation of the externalproject_add() target.
if( NOT ${WINTARGET} STREQUAL "" )
 ??? set( __wintarget -DWINTARGET=${WINTARGET} )
endif( )

# If we are configuring using a single-configuration generator,
# the configuration name is needed by the configure-time external
# package build and for the creation of the externalproject_add()
# target.
if( "${CMAKE_CONFIGURATION_TYPES}" STREQUAL "" )
 ??? set( __build_type "-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}" )
endif( )

if( NOT "${CMAKE_GENERATOR_PLATFORM}" STREQUAL "" )
 ??? set(__platform -A ${CMAKE_GENERATOR_PLATFORM} )
endif( )
if( NOT "${CMAKE_GENERATOR_TOOLSET}" STREQUAL "" )
 ??? set(__toolset -T ${CMAKE_GENERATOR_TOOLSET} )
endif( )

# When building a static library using externalproject_add() and
# using Ninja for the build tool, we must include the library name
# in the BUILD BYPRODUCTS option of externalproject_add(). See the
# discussion at https://cmake.org/pipermail/cmake/2015-April/060233.html.
# This issue applies only to SoftFloat-3a at the moment because it
# is the only static library built and used by this project.

# Retrieve the full path name of the static library for the current
# configuration from the imported target.? This is relatively simple
# because Ninja is a single-configuration build tool, so we know
# which configuration should be retrieved from the target at
# configure time.

if( "${CMAKE_GENERATOR}" STREQUAL "Ninja" )
 ??? if( "${pkgid}" MATCHES "^[Ss]3[Ff][Hh]$" )
 ??????? string( TOUPPER "${CMAKE_BUILD_TYPE}" __build_byproducts )
 ??????? get_target_property(
 ??????????????? __build_byproducts
 ??????????????? SoftFloat
 ??????????????? IMPORTED_LOCATION_${__build_byproducts}
 ??????????????? )
 ??????? message( "Build type ${CMAKE_BUILD_TYPE}, Setting 
BUILD_BYPRODUCTS to ${__build_byproducts}" )
 ??? endif( )
endif( )

# externalproject_add() does not expose a git depth option, so we
# must download the entire repository.? Oh well...maybe someday.
# Note that "<INSTALL_DIR>" below is not a typo'd generator
# expression.

externalproject_add( ${pkg}
 ??????? PREFIX??????????? ${__pkg_prefix}
 ??????? SOURCE_DIR??????? ${__pkg_prefix}/pkgsrc
 ??????? BINARY_DIR??????? ${__pkg_prefix}/build
 ??????? INSTALL_DIR?????? ${__pkg_prefix}/install
 ??????? GIT_REPOSITORY??? ${pkgurl}
 ??????? GIT_TAG?????????? ${pkgbranch}
 ??????? CMAKE_GENERATOR?????????? ${CMAKE_GENERATOR}
 ??????? CMAKE_GENERATOR_TOOLSET ${CMAKE_GENERATOR_TOOLSET}
 ??????? CMAKE_GENERATOR_PLATFORM ${CMAKE_GENERATOR_PLATFORM}
 ??????? CMAKE_ARGS
 ??????????????? ${__wintarget}
 ??????????????? ${__build_type}
-D${__CMAKE}INSTALL_PREFIX=<INSTALL_DIR>
 ??????????????? -DCMAKE_REQUIRED_QUIET=TRUE
 ??????? BUILD_BYPRODUCTS? ${__build_byproducts}
 ??????? PATCH_COMMAND???? ""??????? # No patches
 ??????? UPDATE_COMMAND??? ""??????? # No updates
 ??????? INSTALL_COMMAND?? ""??????? # ..and no install.
 ??? )

</CMake code>


I expect it would not be difficult to add the toolchain file in the same 
way.

-- 
Best Regards,
Steve Orso


From franck.houssen at inria.fr  Sat Jan  6 09:34:48 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sat, 6 Jan 2018 15:34:48 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
Message-ID: <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>

Hello, 

I have an executable that needs dlopen. 

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ? 
My understanding is that I need to go: 
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" .. 
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!) 

Did I understand correctly ? Did I miss something ? 

Franck 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180106/f992f055/attachment.html>

From d3ck0r at gmail.com  Sat Jan  6 10:19:33 2018
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 6 Jan 2018 07:19:33 -0800
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
Message-ID: <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>

probably just need target_link_libraries( <target> dl )

On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> Hello,
>
> I have an executable that needs dlopen.
>
> Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!..
> Correct ? If so, why is this ?
> My understanding is that I need to go:
> ~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
> which is, basically, telling to CMake where dl is (although this is the
> job of a build system, no ?!)
>
> Did I understand correctly ? Did I miss something ?
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180106/52bade45/attachment.html>

From rainer.poisel at gmail.com  Sat Jan  6 11:30:53 2018
From: rainer.poisel at gmail.com (Rainer Poisel)
Date: Sat, 6 Jan 2018 17:30:53 +0100
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
Message-ID: <CADpFnzxf-xtnFhN+Lx0mH5ipVANTVPo1o3ktdc1hTW-TbGTQDQ@mail.gmail.com>

Hi,

I would use ${CMAKE_DL_LIBS} in target_link_libraries:

  * https://cmake.org/cmake/help/v3.0/variable/CMAKE_DL_LIBS.html

Regards,
  Rainer


On Jan 6, 2018 16:19, "J Decker" <d3ck0r at gmail.com> wrote:

probably just need target_link_libraries( <target> dl )

On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> Hello,
>
> I have an executable that needs dlopen.
>
> Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!..
> Correct ? If so, why is this ?
> My understanding is that I need to go:
> ~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
> which is, basically, telling to CMake where dl is (although this is the
> job of a build system, no ?!)
>
> Did I understand correctly ? Did I miss something ?
>
> 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/opensou
> rce/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180106/b6a97d4b/attachment-0001.html>

From franck.houssen at inria.fr  Sat Jan  6 11:41:59 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sat, 6 Jan 2018 17:41:59 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
Message-ID: <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>

----- Mail original -----

> De: "J Decker" <d3ck0r at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Samedi 6 Janvier 2018 16:19:33
> Objet: Re: [CMake] CMake: using dlopen

> probably just need target_link_libraries( <target> dl )

But so, who defined the dl target ? 

> On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen < franck.houssen at inria.fr >
> wrote:

> > Hello,
> 

> > I have an executable that needs dlopen.
> 

> > Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!..
> > Correct
> > ? If so, why is this ?
> 
> > My understanding is that I need to go:
> 
> > ~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
> 
> > which is, basically, telling to CMake where dl is (although this is the job
> > of a build system, no ?!)
> 

> > Did I understand correctly ? Did I miss something ?
> 

> > 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180106/d6de61b9/attachment.html>

From franck.houssen at inria.fr  Sat Jan  6 11:42:56 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sat, 6 Jan 2018 17:42:56 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CADpFnzxf-xtnFhN+Lx0mH5ipVANTVPo1o3ktdc1hTW-TbGTQDQ@mail.gmail.com>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <CADpFnzxf-xtnFhN+Lx0mH5ipVANTVPo1o3ktdc1hTW-TbGTQDQ@mail.gmail.com>
Message-ID: <1321946689.14456055.1515256976565.JavaMail.zimbra@inria.fr>

----- Mail original -----

> De: "Rainer Poisel" <rainer.poisel at gmail.com>
> ?: "J Decker" <d3ck0r at gmail.com>
> Cc: "Franck Houssen" <franck.houssen at inria.fr>, cmake at cmake.org
> Envoy?: Samedi 6 Janvier 2018 17:30:53
> Objet: Re: [CMake] CMake: using dlopen

> Hi,

> I would use ${CMAKE_DL_LIBS} in target_link_libraries:

> * https://cmake.org/cmake/help/v3.0/variable/CMAKE_DL_LIBS.html

But here again, who defined ${CMAKE_DL_LIBS}: I don't see it when I run "cmake -LA ." 

> Regards,
> Rainer

> On Jan 6, 2018 16:19, "J Decker" < d3ck0r at gmail.com > wrote:

> > probably just need target_link_libraries( <target> dl )
> 

> > On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen < franck.houssen at inria.fr >
> > wrote:
> 

> > > Hello,
> > 
> 

> > > I have an executable that needs dlopen.
> > 
> 

> > > Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!..
> > > Correct
> > > ? If so, why is this ?
> > 
> 
> > > My understanding is that I need to go:
> > 
> 
> > > ~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
> > 
> 
> > > which is, basically, telling to CMake where dl is (although this is the
> > > job
> > > of a build system, no ?!)
> > 
> 

> > > Did I understand correctly ? Did I miss something ?
> > 
> 

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

> > --
> 

> > 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180106/9fd2ad39/attachment.html>

From d3ck0r at gmail.com  Sat Jan  6 12:01:01 2018
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 6 Jan 2018 09:01:01 -0800
Subject: [CMake] CMake: using dlopen
In-Reply-To: <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
Message-ID: <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>

CMake/shared/modules will define the CMAKE_DL_LIBS  which a very high
percentage of the time will just be library 'dl' .

Pretty much any man page on dlopen defines 'dl'

http://man7.org/linux/man-pages/man3/dlopen.3.html

 Link with *-ldl*.

specifying just the library name adds it as a -L<libname> option to be
searched with standard library functions.

On Sat, Jan 6, 2018 at 8:41 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

>
> ------------------------------
>
> *De: *"J Decker" <d3ck0r at gmail.com>
> *?: *"Franck Houssen" <franck.houssen at inria.fr>
> *Cc: *"CMake Mail List" <cmake at cmake.org>
> *Envoy?: *Samedi 6 Janvier 2018 16:19:33
> *Objet: *Re: [CMake] CMake: using dlopen
>
> probably just need target_link_libraries( <target> dl )
>
>
> But so, who defined the dl target ?
>
>
> On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>> Hello,
>>
>> I have an executable that needs dlopen.
>>
>> Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!..
>> Correct ? If so, why is this ?
>> My understanding is that I need to go:
>> ~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
>> which is, basically, telling to CMake where dl is (although this is the
>> job of a build system, no ?!)
>>
>> Did I understand correctly ? Did I miss something ?
>>
>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180106/d62101b2/attachment.html>

From rleigh at codelibre.net  Sat Jan  6 12:42:11 2018
From: rleigh at codelibre.net (Roger Leigh)
Date: Sat, 6 Jan 2018 17:42:11 +0000
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
 <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
Message-ID: <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>

On 06/01/18 17:01, J Decker wrote:
> CMake/shared/modules will define the CMAKE_DL_LIBS? which a very high 
> percentage of the time will just be library 'dl' .
> 
> Pretty much any man page on dlopen defines 'dl'

On Linux.  On MaxOSX and FreeBSD not at all, where the dl functions are 
in libSystem and libc, respectively.  Using CMAKE_DL_LIBS does the right 
thing on all platforms (though I wish it was an imported target to make 
exports a bit nicer).


Regards,
Roger

From franck.houssen at inria.fr  Sun Jan  7 08:58:21 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sun, 7 Jan 2018 14:58:21 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
 <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
 <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>
Message-ID: <1722987865.14591087.1515333501242.JavaMail.zimbra@inria.fr>

----- Mail original -----
> De: "Roger Leigh" <rleigh at codelibre.net>
> ?: cmake at cmake.org
> Envoy?: Samedi 6 Janvier 2018 18:42:11
> Objet: Re: [CMake] CMake: using dlopen
> 
> On 06/01/18 17:01, J Decker wrote:
> > CMake/shared/modules will define the CMAKE_DL_LIBS? which a very high
> > percentage of the time will just be library 'dl' .

OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's the correct way to see all variables ?

> > 
> > Pretty much any man page on dlopen defines 'dl'
> 
> On Linux.  On MaxOSX and FreeBSD not at all, where the dl functions are
> in libSystem and libc, respectively.  Using CMAKE_DL_LIBS does the right
> thing on all platforms (though I wish it was an imported target to make
> exports a bit nicer).

OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})

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

From annulen at yandex.ru  Sun Jan  7 09:20:08 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sun, 07 Jan 2018 17:20:08 +0300
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1722987865.14591087.1515333501242.JavaMail.zimbra@inria.fr>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
 <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
 <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>
 <1722987865.14591087.1515333501242.JavaMail.zimbra@inria.fr>
Message-ID: <774851515334808@web18g.yandex.ru>



> ----- Mail original -----
> 
>> De: "Roger Leigh" <rleigh at codelibre.net>
>> ?: cmake at cmake.org
>> Envoy?: Samedi 6 Janvier 2018 18:42:11
>> Objet: Re: [CMake] CMake: using dlopen
>>
>> On 06/01/18 17:01, J Decker wrote:
>>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
>>> percentage of the time will just be library 'dl' .
> 
> OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's the correct way to see all variables ?

Because cmake -L shows only cached variables, not all variables

> 
>>>
>>> Pretty much any man page on dlopen defines 'dl'
>>
>> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
>> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the right
>> thing on all platforms (though I wish it was an imported target to make
>> exports a bit nicer).
> 
> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})
> 
>> 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:
>> 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
-- 
Regards,
Konstantin

From franck.houssen at inria.fr  Sun Jan  7 11:36:15 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sun, 7 Jan 2018 17:36:15 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <774851515334808@web18g.yandex.ru>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
 <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
 <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>
 <1722987865.14591087.1515333501242.JavaMail.zimbra@inria.fr>
 <774851515334808@web18g.yandex.ru>
Message-ID: <1954678434.14612124.1515342975434.JavaMail.zimbra@inria.fr>



----- Mail original -----
> De: "Konstantin Tokarev" <annulen at yandex.ru>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: cmake at cmake.org, "Roger Leigh" <rleigh at codelibre.net>
> Envoy?: Dimanche 7 Janvier 2018 15:20:08
> Objet: Re: [CMake] CMake: using dlopen
> 
> 
> 
> > ----- Mail original -----
> > 
> >> De: "Roger Leigh" <rleigh at codelibre.net>
> >> ?: cmake at cmake.org
> >> Envoy?: Samedi 6 Janvier 2018 18:42:11
> >> Objet: Re: [CMake] CMake: using dlopen
> >>
> >> On 06/01/18 17:01, J Decker wrote:
> >>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
> >>> percentage of the time will just be library 'dl' .
> > 
> > OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you
> > run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's
> > the correct way to see all variables ?
> 
> Because cmake -L shows only cached variables, not all variables
> 

How to see all variables ?

> > 
> >>>
> >>> Pretty much any man page on dlopen defines 'dl'
> >>
> >> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
> >> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the right
> >> thing on all platforms (though I wish it was an imported target to make
> >> exports a bit nicer).
> > 
> > OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
> > ${CMAKE_DL_LIBS})
> > 
> >> 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:
> >> 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
> --
> Regards,
> Konstantin
> 

From annulen at yandex.ru  Sun Jan  7 11:50:40 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sun, 07 Jan 2018 19:50:40 +0300
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1954678434.14612124.1515342975434.JavaMail.zimbra@inria.fr>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <1062593271.14443819.1515249288095.JavaMail.zimbra@inria.fr>
 <CAA2GJqX6pbKBBT32FEXt7e7XXBQfRq0NS=OWOpTzDoPph1J7kA@mail.gmail.com>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
 <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
 <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>
 <1722987865.14591087.1515333501242.JavaMail.zimbra@inria.fr>
 <774851515334808@web18g.yandex.ru>
 <1954678434.14612124.1515342975434.JavaMail.zimbra@inria.fr>
Message-ID: <529721515343840@web45g.yandex.ru>



07.01.2018, 19:36, "Franck Houssen" <franck.houssen at inria.fr>:
> ----- Mail original -----
>> ?De: "Konstantin Tokarev" <annulen at yandex.ru>
>> ??: "Franck Houssen" <franck.houssen at inria.fr>
>> ?Cc: cmake at cmake.org, "Roger Leigh" <rleigh at codelibre.net>
>> ?Envoy?: Dimanche 7 Janvier 2018 15:20:08
>> ?Objet: Re: [CMake] CMake: using dlopen
>>
>> ?> ----- Mail original -----
>> ?>
>> ?>> De: "Roger Leigh" <rleigh at codelibre.net>
>> ?>> ?: cmake at cmake.org
>> ?>> Envoy?: Samedi 6 Janvier 2018 18:42:11
>> ?>> Objet: Re: [CMake] CMake: using dlopen
>> ?>>
>> ?>> On 06/01/18 17:01, J Decker wrote:
>> ?>>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
>> ?>>> percentage of the time will just be library 'dl' .
>> ?>
>> ?> OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you
>> ?> run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's
>> ?> the correct way to see all variables ?
>>
>> ?Because cmake -L shows only cached variables, not all variables
>
> How to see all variables ?

See first part of https://stackoverflow.com/a/9328525

>
>> ?>
>> ?>>>
>> ?>>> Pretty much any man page on dlopen defines 'dl'
>> ?>>
>> ?>> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
>> ?>> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the right
>> ?>> thing on all platforms (though I wish it was an imported target to make
>> ?>> exports a bit nicer).
>> ?>
>> ?> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
>> ?> ${CMAKE_DL_LIBS})
>> ?>
>> ?>> 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:
>> ?>> 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
>> ?--
>> ?Regards,
>> ?Konstantin

-- 
Regards,
Konstantin

From rleigh at codelibre.net  Sun Jan  7 12:14:04 2018
From: rleigh at codelibre.net (Roger Leigh)
Date: Sun, 07 Jan 2018 17:14:04 +0000
Subject: [CMake] CMake: using dlopen
Message-ID: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>


-------- Original message --------From: Franck Houssen <franck.houssen at inria.fr> Date: 07/01/2018  13:58  (GMT+00:00) To: Roger Leigh <rleigh at codelibre.net> Cc: cmake at cmake.org Subject: Re: [CMake] CMake: using dlopen 
> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})

Use PRIVATE if it is not used in any headers--it's an internal implementation detail.
Regards,Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180107/8c3479e6/attachment.html>

From franck.houssen at inria.fr  Sun Jan  7 13:10:43 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sun, 7 Jan 2018 19:10:43 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <529721515343840@web45g.yandex.ru>
References: <1187429735.14442593.1515248993533.JavaMail.zimbra@inria.fr>
 <824812737.14455938.1515256919766.JavaMail.zimbra@inria.fr>
 <CAA2GJqVQQGjnUfEYCdYBDSouFMJsrMJwJ0nRvrCTMV8odm5d8w@mail.gmail.com>
 <5591bf0b-6b31-1e52-5497-84696920ff8a@codelibre.net>
 <1722987865.14591087.1515333501242.JavaMail.zimbra@inria.fr>
 <774851515334808@web18g.yandex.ru>
 <1954678434.14612124.1515342975434.JavaMail.zimbra@inria.fr>
 <529721515343840@web45g.yandex.ru>
Message-ID: <1210595751.14632677.1515348643789.JavaMail.zimbra@inria.fr>



----- Mail original -----
> De: "Konstantin Tokarev" <annulen at yandex.ru>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: cmake at cmake.org, "Roger Leigh" <rleigh at codelibre.net>
> Envoy?: Dimanche 7 Janvier 2018 17:50:40
> Objet: Re: [CMake] CMake: using dlopen
> 
> 
> 
> 07.01.2018, 19:36, "Franck Houssen" <franck.houssen at inria.fr>:
> > ----- Mail original -----
> >> ?De: "Konstantin Tokarev" <annulen at yandex.ru>
> >> ??: "Franck Houssen" <franck.houssen at inria.fr>
> >> ?Cc: cmake at cmake.org, "Roger Leigh" <rleigh at codelibre.net>
> >> ?Envoy?: Dimanche 7 Janvier 2018 15:20:08
> >> ?Objet: Re: [CMake] CMake: using dlopen
> >>
> >> ?> ----- Mail original -----
> >> ?>
> >> ?>> De: "Roger Leigh" <rleigh at codelibre.net>
> >> ?>> ?: cmake at cmake.org
> >> ?>> Envoy?: Samedi 6 Janvier 2018 18:42:11
> >> ?>> Objet: Re: [CMake] CMake: using dlopen
> >> ?>>
> >> ?>> On 06/01/18 17:01, J Decker wrote:
> >> ?>>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
> >> ?>>> percentage of the time will just be library 'dl' .
> >> ?>
> >> ?> OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when
> >> ?> you
> >> ?> run "cmake -LA ." and/or when you toggle adanced mode in ccmake ?
> >> ?> What's
> >> ?> the correct way to see all variables ?
> >>
> >> ?Because cmake -L shows only cached variables, not all variables
> >
> > How to see all variables ?
> 
> See first part of https://stackoverflow.com/a/9328525
> 

OK, I see ! Thanks

> >
> >> ?>
> >> ?>>>
> >> ?>>> Pretty much any man page on dlopen defines 'dl'
> >> ?>>
> >> ?>> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
> >> ?>> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the
> >> ?>> right
> >> ?>> thing on all platforms (though I wish it was an imported target to
> >> ?>> make
> >> ?>> exports a bit nicer).
> >> ?>
> >> ?> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
> >> ?> ${CMAKE_DL_LIBS})
> >> ?>
> >> ?>> 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:
> >> ?>> 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
> >> ?--
> >> ?Regards,
> >> ?Konstantin
> 
> --
> Regards,
> Konstantin
> 

From franck.houssen at inria.fr  Sun Jan  7 13:13:30 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sun, 7 Jan 2018 19:13:30 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
Message-ID: <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>

----- Mail original -----

> De: "Roger Leigh" <rleigh at codelibre.net>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: cmake at cmake.org
> Envoy?: Dimanche 7 Janvier 2018 18:14:04
> Objet: Re: [CMake] CMake: using dlopen

> -------- Original message --------
> From: Franck Houssen <franck.houssen at inria.fr>
> Date: 07/01/2018 13:58 (GMT+00:00)
> To: Roger Leigh <rleigh at codelibre.net>
> Cc: cmake at cmake.org
> Subject: Re: [CMake] CMake: using dlopen

> > OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
> > ${CMAKE_DL_LIBS})

> Use PRIVATE if it is not used in any headers--it's an internal implementation
> detail.
Difference between PUBLIC/PRIVATE has never been clear to me (usually I always use PUBLIC). 
main.cpp includes dlfcn.h and uses it: not sure to get what you meant (PRIVATE is for templates ? when a header include headers ?) 

> Regards,
> Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180107/cbb11f12/attachment.html>

From annulen at yandex.ru  Sun Jan  7 17:17:44 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 08 Jan 2018 01:17:44 +0300
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
Message-ID: <1189841515363464@web37o.yandex.ru>



07.01.2018, 21:13, "Franck Houssen" <franck.houssen at inria.fr>:
> ----------------------------------------
>> De: "Roger Leigh" <rleigh at codelibre.net>
>> ?: "Franck Houssen" <franck.houssen at inria.fr>
>> Cc: cmake at cmake.org
>> Envoy?: Dimanche 7 Janvier 2018 18:14:04
>> Objet: Re: [CMake] CMake: using dlopen
>>
>> -------- Original message --------
>> From: Franck Houssen <franck.houssen at inria.fr>
>> Date: 07/01/2018 13:58 (GMT+00:00)
>> To: Roger Leigh <rleigh at codelibre.net>
>> Cc: cmake at cmake.org
>> Subject: Re: [CMake] CMake: using dlopen
>>
>>> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})
>>
>> Use PRIVATE if it is not used in any headers--it's an internal implementation detail.
>
> Difference between PUBLIC/PRIVATE has never been clear to me (usually I always use PUBLIC).
> main.cpp includes dlfcn.h and uses it: not sure to get what you meant (PRIVATE is for templates ? when a header include headers ?)

You should use target_link_libraries(A PUBLIC B) if and only if anything that links with library A must also link with library B (usually because B's types are used in public API of A). If A is not a library, there is no difference.

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


--?
Regards,
Konstantin

From me at pedro-vicente.net  Mon Jan  8 00:35:39 2018
From: me at pedro-vicente.net (Pedro Vicente)
Date: Mon, 8 Jan 2018 00:35:39 -0500
Subject: [CMake] include library dependencies in static lib for Visual Studio
Message-ID: <1UQM7Jkat7.3C3XecyJZaX@desktop-039c73k>

I have a project with a chain of external libraries and some of the 
dependencies depend on each other as options 

meaning 

project uses 

LIB A, 
LIB B

LIB B can use as option LIB C

my project then needs to inquire LIB B to see if LIB C was included (to link 
with LIB C)

I do this like this

message("-- Detecting if HDF5 library ${HDF5_LIBRARY} needs the ZLIB library...")
check_library_exists(${HDF5_LIBRARY} H5Z_DEFLATE "" NEED_ZLIB)

here LIB B = HDF5_LIBRARY
LIB C = the zlib library

this works with no problems in Linux.

However in Visual Studio , this detection only works if I manually set in the 
generated project
the option
"Link Library Dependencies"
to include LIB C (the zlib library)

these lines get added to the generated Visual Studio project

<Lib>
<AdditionalOptions>%(AdditionalOptions) /machine:x64</AdditionalOptions>
<AdditionalDependencies>I:\nco\cmake\zlib\build\Debug\zlibstaticd.lib;I:\nco\cmake\szip\build\bin\Debug\libszip_D.lib</AdditionalDependencies>
</Lib

Is there a way that I can set this in the CMake script?


these comments show the problem


#HDF5 can be optionally linked with the SZIP library (Science Data Lossless 
Compression Program) and ZLIB
#Symbol to detect in ZLIB can be only H5Z_DEFLATE, a structure only defined in 
H5Zdeflate.c if the filter is enabled
#For SZIP the structure can be only H5Z_SZIP, defined in H5Zszip.c if the 
filter is enabled
#check_library_exists() tries to link a temporary program with these symbols
#On MSVC for this detection to work, the HDF5 library MUST HAVE as additional 
dependencies the ZLIB and SZIP libraries,
#which is not a requirement for the library to build successfully

to reproduce the problem, this is the project

https://github.com/nco/nco/tree/master/cmake

on a windows Win64 developer shell

git clone https://github.com/nco/nco
cd cmake
clone.bat
bld.bat

this will git clone and build dependencies, but there will be linking errors 
because the ZLIB (and SZIP) libraries
were not correctly identified as needed

thanks


----------------------
Pedro Vicente
http://www.space-research.org/
http://pedro-vicente.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/8dec259e/attachment.html>

From franck.houssen at inria.fr  Mon Jan  8 04:41:25 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Mon, 8 Jan 2018 10:41:25 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
Message-ID: <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>



----- Mail original -----
> De: "Rainer Poisel" <rainer.poisel at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Envoy?: Dimanche 7 Janvier 2018 19:34:21
> Objet: Re: [CMake] CMake: using dlopen
> 
> Hi,
> 
> On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
> > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > always use PUBLIC).
> > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > (PRIVATE is for templates ? when a header include headers ?)
> 
> you are looking for the "Transitive Dependencies" feature of CMake:

OK, I didn't get that. It's more clear to me now. Thanks !

>   *
>   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
> 
> Generally speaking and from my personal experience, use the
> target_-commands as much as possible because properties are bound to
> targets and their dependencies rather than a file/directory structure.
> 
> So, that means, use target_include_directories(),
> target_compile_options(), target_compile_definitions(),
> target_sources(), ... for your targets. The magic keyword to propagate
> the properties of your targets is target_link_libraries(). Depending
> on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> defined using the other target_-commands, the target_link_libraries()
> command propagates these properties to other targets. E. g.
> 
> add_library(otherlib SHARED
>   foo.c
> )
> 
> target_include_directories(otherlib PRIVATE
>   dirPrivate
> )
> 
> target_include_directories(otherlib PUBLIC
>   dirPublic
> )
> 
> add_library(mylib SHARED
>   bar.c
> )
> 
> target_link_libraries(mylib PRIVATE

Is this a typo ?
For the example to work I would have done: target_link_libraries(mylib PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not PRIVATE one's). Correct ?


>   otherlib
> )
> 
> In this case, mylib will use all PUBLIC or INTERFACE properties of
> otherlib for its build. Thus, dirPublic will be added to the include
> directory search path for the compilation of bar.c of mylib. PRIVATE
> properties will not be propagated. In the above mentioned example,
> dirPrivate will NOT be added to the include directory search path for
> the compilation of bar.c of mylib.
> 

The example is illustrative (transitivity - PRIVATE is not propagated)

> This is a very short summary, but I hope it is of help to you. There
> are other ressources on the Internet. E. g.
>   *
>   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
>   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> 
> Regards,
>   Rainer
> 

From d3ck0r at gmail.com  Mon Jan  8 04:45:46 2018
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 8 Jan 2018 01:45:46 -0800
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
Message-ID: <CAA2GJqUxfJ1QOBqD1ye_KQjKL49y5dA445th1t50Kd_s73veWw@mail.gmail.com>

On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

>
>
> ----- Mail original -----
> > De: "Rainer Poisel" <rainer.poisel at gmail.com>
> > ?: "Franck Houssen" <franck.houssen at inria.fr>
> > Envoy?: Dimanche 7 Janvier 2018 19:34:21
> > Objet: Re: [CMake] CMake: using dlopen
> >
> > Hi,
> >
> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <franck.houssen at inria.fr>
> > wrote:
> > > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > > always use PUBLIC).
> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > > (PRIVATE is for templates ? when a header include headers ?)
> >
> > you are looking for the "Transitive Dependencies" feature of CMake:
>
> OK, I didn't get that. It's more clear to me now. Thanks !
>
> >   *
> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.
> 7.html#transitive-usage-requirements
> >
> > Generally speaking and from my personal experience, use the
> > target_-commands as much as possible because properties are bound to
> > targets and their dependencies rather than a file/directory structure.
> >
> > So, that means, use target_include_directories(),
> > target_compile_options(), target_compile_definitions(),
> > target_sources(), ... for your targets. The magic keyword to propagate
> > the properties of your targets is target_link_libraries(). Depending
> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > defined using the other target_-commands, the target_link_libraries()
> > command propagates these properties to other targets. E. g.
> >
> > add_library(otherlib SHARED
> >   foo.c
> > )
> >
> > target_include_directories(otherlib PRIVATE
> >   dirPrivate
> > )
> >
> > target_include_directories(otherlib PUBLIC
> >   dirPublic
> > )
> >
> > add_library(mylib SHARED
> >   bar.c
> > )
> >
> > target_link_libraries(mylib PRIVATE
>
> Is this a typo ?
> For the example to work I would have done: target_link_libraries(mylib
> PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but
> not PRIVATE one's). Correct ?
>
>
Public is whether it propagates outside of the current target to things
that then require 'mylib'
private keeps it within that target, has nothing to do with what it's
pulling from any linked library.


>
> >   otherlib
> > )
> >
> > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > otherlib for its build. Thus, dirPublic will be added to the include
> > directory search path for the compilation of bar.c of mylib. PRIVATE
> > properties will not be propagated. In the above mentioned example,
> > dirPrivate will NOT be added to the include directory search path for
> > the compilation of bar.c of mylib.
> >
>
> The example is illustrative (transitivity - PRIVATE is not propagated)
>
> > This is a very short summary, but I hope it is of help to you. There
> > are other ressources on the Internet. E. g.
> >   *
> >   https://stackoverflow.com/questions/26037954/cmake-
> target-link-libraries-interface-dependencies
> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> >
> > Regards,
> >   Rainer
> >
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/bd115b35/attachment.html>

From franck.houssen at inria.fr  Mon Jan  8 04:50:32 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Mon, 8 Jan 2018 10:50:32 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
Message-ID: <309180789.14948993.1515405032162.JavaMail.zimbra@inria.fr>

And so, if I have an executable (add_executable), the default thing to do is to use target_link_libraries(mylib PRIVATE ...). Not PUBLIC (as I do). Correct ?

----- Mail original -----
> De: "Franck Houssen" <franck.houssen at inria.fr>
> ?: "Rainer Poisel" <rainer.poisel at gmail.com>
> Cc: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Lundi 8 Janvier 2018 10:41:25
> Objet: Re: [CMake] CMake: using dlopen
> 
> 
> 
> ----- Mail original -----
> > De: "Rainer Poisel" <rainer.poisel at gmail.com>
> > ?: "Franck Houssen" <franck.houssen at inria.fr>
> > Envoy?: Dimanche 7 Janvier 2018 19:34:21
> > Objet: Re: [CMake] CMake: using dlopen
> > 
> > Hi,
> > 
> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <franck.houssen at inria.fr>
> > wrote:
> > > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > > always use PUBLIC).
> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > > (PRIVATE is for templates ? when a header include headers ?)
> > 
> > you are looking for the "Transitive Dependencies" feature of CMake:
> 
> OK, I didn't get that. It's more clear to me now. Thanks !
> 
> >   *
> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
> > 
> > Generally speaking and from my personal experience, use the
> > target_-commands as much as possible because properties are bound to
> > targets and their dependencies rather than a file/directory structure.
> > 
> > So, that means, use target_include_directories(),
> > target_compile_options(), target_compile_definitions(),
> > target_sources(), ... for your targets. The magic keyword to propagate
> > the properties of your targets is target_link_libraries(). Depending
> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > defined using the other target_-commands, the target_link_libraries()
> > command propagates these properties to other targets. E. g.
> > 
> > add_library(otherlib SHARED
> >   foo.c
> > )
> > 
> > target_include_directories(otherlib PRIVATE
> >   dirPrivate
> > )
> > 
> > target_include_directories(otherlib PUBLIC
> >   dirPublic
> > )
> > 
> > add_library(mylib SHARED
> >   bar.c
> > )
> > 
> > target_link_libraries(mylib PRIVATE
> 
> Is this a typo ?
> For the example to work I would have done: target_link_libraries(mylib PUBLIC
> otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not
> PRIVATE one's). Correct ?
> 
> 
> >   otherlib
> > )
> > 
> > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > otherlib for its build. Thus, dirPublic will be added to the include
> > directory search path for the compilation of bar.c of mylib. PRIVATE
> > properties will not be propagated. In the above mentioned example,
> > dirPrivate will NOT be added to the include directory search path for
> > the compilation of bar.c of mylib.
> > 
> 
> The example is illustrative (transitivity - PRIVATE is not propagated)
> 
> > This is a very short summary, but I hope it is of help to you. There
> > are other ressources on the Internet. E. g.
> >   *
> >   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> > 
> > Regards,
> >   Rainer
> > 
> --
> 
> 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
> 

From d3ck0r at gmail.com  Mon Jan  8 04:53:03 2018
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 8 Jan 2018 01:53:03 -0800
Subject: [CMake] CMake: using dlopen
In-Reply-To: <309180789.14948993.1515405032162.JavaMail.zimbra@inria.fr>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
 <309180789.14948993.1515405032162.JavaMail.zimbra@inria.fr>
Message-ID: <CAA2GJqWhmWCSg3OXhGw7mUhb-oBoQATPNJjFq33zZVZ_i2mxmA@mail.gmail.com>

On Mon, Jan 8, 2018 at 1:50 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> And so, if I have an executable (add_executable), the default thing to do
> is to use target_link_libraries(mylib PRIVATE ...). Not PUBLIC (as I do).
> Correct ?
>

Yes, unless you have plugins that then back-ljnk against that executable.
(and that also use the libraries that executable uses... if it just uses
things from that library/executable then private should always be used)


>
> ----- Mail original -----
> > De: "Franck Houssen" <franck.houssen at inria.fr>
> > ?: "Rainer Poisel" <rainer.poisel at gmail.com>
> > Cc: "CMake Mail List" <cmake at cmake.org>
> > Envoy?: Lundi 8 Janvier 2018 10:41:25
> > Objet: Re: [CMake] CMake: using dlopen
> >
> >
> >
> > ----- Mail original -----
> > > De: "Rainer Poisel" <rainer.poisel at gmail.com>
> > > ?: "Franck Houssen" <franck.houssen at inria.fr>
> > > Envoy?: Dimanche 7 Janvier 2018 19:34:21
> > > Objet: Re: [CMake] CMake: using dlopen
> > >
> > > Hi,
> > >
> > > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <
> franck.houssen at inria.fr>
> > > wrote:
> > > > Difference between PUBLIC/PRIVATE has never been clear to me
> (usually I
> > > > always use PUBLIC).
> > > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > > > (PRIVATE is for templates ? when a header include headers ?)
> > >
> > > you are looking for the "Transitive Dependencies" feature of CMake:
> >
> > OK, I didn't get that. It's more clear to me now. Thanks !
> >
> > >   *
> > >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.
> 7.html#transitive-usage-requirements
> > >
> > > Generally speaking and from my personal experience, use the
> > > target_-commands as much as possible because properties are bound to
> > > targets and their dependencies rather than a file/directory structure.
> > >
> > > So, that means, use target_include_directories(),
> > > target_compile_options(), target_compile_definitions(),
> > > target_sources(), ... for your targets. The magic keyword to propagate
> > > the properties of your targets is target_link_libraries(). Depending
> > > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > > defined using the other target_-commands, the target_link_libraries()
> > > command propagates these properties to other targets. E. g.
> > >
> > > add_library(otherlib SHARED
> > >   foo.c
> > > )
> > >
> > > target_include_directories(otherlib PRIVATE
> > >   dirPrivate
> > > )
> > >
> > > target_include_directories(otherlib PUBLIC
> > >   dirPublic
> > > )
> > >
> > > add_library(mylib SHARED
> > >   bar.c
> > > )
> > >
> > > target_link_libraries(mylib PRIVATE
> >
> > Is this a typo ?
> > For the example to work I would have done: target_link_libraries(mylib
> PUBLIC
> > otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not
> > PRIVATE one's). Correct ?
> >
> >
> > >   otherlib
> > > )
> > >
> > > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > > otherlib for its build. Thus, dirPublic will be added to the include
> > > directory search path for the compilation of bar.c of mylib. PRIVATE
> > > properties will not be propagated. In the above mentioned example,
> > > dirPrivate will NOT be added to the include directory search path for
> > > the compilation of bar.c of mylib.
> > >
> >
> > The example is illustrative (transitivity - PRIVATE is not propagated)
> >
> > > This is a very short summary, but I hope it is of help to you. There
> > > are other ressources on the Internet. E. g.
> > >   *
> > >   https://stackoverflow.com/questions/26037954/cmake-
> target-link-libraries-interface-dependencies
> > >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> > >
> > > Regards,
> > >   Rainer
> > >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/6dab3d17/attachment-0001.html>

From eric.noulard at gmail.com  Mon Jan  8 04:53:51 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 8 Jan 2018 10:53:51 +0100
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CAA2GJqUxfJ1QOBqD1ye_KQjKL49y5dA445th1t50Kd_s73veWw@mail.gmail.com>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
 <CAA2GJqUxfJ1QOBqD1ye_KQjKL49y5dA445th1t50Kd_s73veWw@mail.gmail.com>
Message-ID: <CAPASGLrRhv-iTMaEGNc-V+CNtELoW8f_gBO7wFv74XZ2XVCQeg@mail.gmail.com>

Explanations on PRIVATE, PUBLIC, INTERFACE has already been discussed in
those ML threads:
https://cmake.org/pipermail/cmake/2017-April/065340.html
https://cmake.org/pipermail/cmake/2016-May/063400.html

I guess we need some doc update.
I did promess contribution and I didn't do it.
I'll try again.


2018-01-08 10:45 GMT+01:00 J Decker <d3ck0r at gmail.com>:

>
> On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>>
>>
>> ----- Mail original -----
>> > De: "Rainer Poisel" <rainer.poisel at gmail.com>
>> > ?: "Franck Houssen" <franck.houssen at inria.fr>
>> > Envoy?: Dimanche 7 Janvier 2018 19:34:21
>> > Objet: Re: [CMake] CMake: using dlopen
>> >
>> > Hi,
>> >
>> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <franck.houssen at inria.fr
>> >
>> > wrote:
>> > > Difference between PUBLIC/PRIVATE has never been clear to me (usually
>> I
>> > > always use PUBLIC).
>> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
>> > > (PRIVATE is for templates ? when a header include headers ?)
>> >
>> > you are looking for the "Transitive Dependencies" feature of CMake:
>>
>> OK, I didn't get that. It's more clear to me now. Thanks !
>>
>> >   *
>> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.
>> 7.html#transitive-usage-requirements
>> >
>> > Generally speaking and from my personal experience, use the
>> > target_-commands as much as possible because properties are bound to
>> > targets and their dependencies rather than a file/directory structure.
>> >
>> > So, that means, use target_include_directories(),
>> > target_compile_options(), target_compile_definitions(),
>> > target_sources(), ... for your targets. The magic keyword to propagate
>> > the properties of your targets is target_link_libraries(). Depending
>> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
>> > defined using the other target_-commands, the target_link_libraries()
>> > command propagates these properties to other targets. E. g.
>> >
>> > add_library(otherlib SHARED
>> >   foo.c
>> > )
>> >
>> > target_include_directories(otherlib PRIVATE
>> >   dirPrivate
>> > )
>> >
>> > target_include_directories(otherlib PUBLIC
>> >   dirPublic
>> > )
>> >
>> > add_library(mylib SHARED
>> >   bar.c
>> > )
>> >
>> > target_link_libraries(mylib PRIVATE
>>
>> Is this a typo ?
>> For the example to work I would have done: target_link_libraries(mylib
>> PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but
>> not PRIVATE one's). Correct ?
>>
>>
> Public is whether it propagates outside of the current target to things
> that then require 'mylib'
> private keeps it within that target, has nothing to do with what it's
> pulling from any linked library.
>
>
>>
>> >   otherlib
>> > )
>> >
>> > In this case, mylib will use all PUBLIC or INTERFACE properties of
>> > otherlib for its build. Thus, dirPublic will be added to the include
>> > directory search path for the compilation of bar.c of mylib. PRIVATE
>> > properties will not be propagated. In the above mentioned example,
>> > dirPrivate will NOT be added to the include directory search path for
>> > the compilation of bar.c of mylib.
>> >
>>
>> The example is illustrative (transitivity - PRIVATE is not propagated)
>>
>> > This is a very short summary, but I hope it is of help to you. There
>> > are other ressources on the Internet. E. g.
>> >   *
>> >   https://stackoverflow.com/questions/26037954/cmake-target-
>> link-libraries-interface-dependencies
>> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
>> >
>> > Regards,
>> >   Rainer
>> >
>> --
>>
>> 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
>
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/3ee6c723/attachment.html>

From franck.houssen at inria.fr  Mon Jan  8 05:07:33 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Mon, 8 Jan 2018 11:07:33 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CAPASGLrRhv-iTMaEGNc-V+CNtELoW8f_gBO7wFv74XZ2XVCQeg@mail.gmail.com>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
 <CAA2GJqUxfJ1QOBqD1ye_KQjKL49y5dA445th1t50Kd_s73veWw@mail.gmail.com>
 <CAPASGLrRhv-iTMaEGNc-V+CNtELoW8f_gBO7wFv74XZ2XVCQeg@mail.gmail.com>
Message-ID: <1692560912.14988270.1515406053959.JavaMail.zimbra@inria.fr>

I usually read the doc in a step-by-step mode (going from "small things" to "the next") when a (new) need/question shows up. When I can I try to "push" some notions (this is an example of it !). 
The doc is "vast" which is a good thing but not so easy when trying to read/understand all of it (personal opinion). To me, the doc misses simple illustrative examples like Rainer's one (here again, personal opinion). 

----- Mail original -----

> De: "Eric Noulard" <eric.noulard at gmail.com>
> ?: "J Decker" <d3ck0r at gmail.com>
> Cc: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List"
> <cmake at cmake.org>
> Envoy?: Lundi 8 Janvier 2018 10:53:51
> Objet: Re: [CMake] CMake: using dlopen

> Explanations on PRIVATE, PUBLIC, INTERFACE has already been discussed in
> those ML threads:
> https://cmake.org/pipermail/cmake/2017-April/065340.html
> https://cmake.org/pipermail/cmake/2016-May/063400.html

> I guess we need some doc update.
> I did promess contribution and I didn't do it.
> I'll try again.

> 2018-01-08 10:45 GMT+01:00 J Decker < d3ck0r at gmail.com > :

> > On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen < franck.houssen at inria.fr >
> > wrote:
> 

> > > ----- Mail original -----
> > 
> 
> > > > De: "Rainer Poisel" < rainer.poisel at gmail.com >
> > 
> 
> > > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > 
> 
> > > > Envoy?: Dimanche 7 Janvier 2018 19:34:21
> > 
> 
> > > > Objet: Re: [CMake] CMake: using dlopen
> > 
> 
> > > >
> > 
> 
> > > > Hi,
> > 
> 
> > > >
> > 
> 
> > > > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <
> > > > franck.houssen at inria.fr
> > > > >
> > 
> 
> > > > wrote:
> > 
> 
> > > > > Difference between PUBLIC/PRIVATE has never been clear to me (usually
> > > > > I
> > 
> 
> > > > > always use PUBLIC).
> > 
> 
> > > > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > 
> 
> > > > > (PRIVATE is for templates ? when a header include headers ?)
> > 
> 
> > > >
> > 
> 
> > > > you are looking for the "Transitive Dependencies" feature of CMake:
> > 
> 

> > > OK, I didn't get that. It's more clear to me now. Thanks !
> > 
> 

> > > > *
> > 
> 
> > > > https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
> > 
> 
> > > >
> > 
> 
> > > > Generally speaking and from my personal experience, use the
> > 
> 
> > > > target_-commands as much as possible because properties are bound to
> > 
> 
> > > > targets and their dependencies rather than a file/directory structure.
> > 
> 
> > > >
> > 
> 
> > > > So, that means, use target_include_directories(),
> > 
> 
> > > > target_compile_options(), target_compile_definitions(),
> > 
> 
> > > > target_sources(), ... for your targets. The magic keyword to propagate
> > 
> 
> > > > the properties of your targets is target_link_libraries(). Depending
> > 
> 
> > > > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > 
> 
> > > > defined using the other target_-commands, the target_link_libraries()
> > 
> 
> > > > command propagates these properties to other targets. E. g.
> > 
> 
> > > >
> > 
> 
> > > > add_library(otherlib SHARED
> > 
> 
> > > > foo.c
> > 
> 
> > > > )
> > 
> 
> > > >
> > 
> 
> > > > target_include_directories(otherlib PRIVATE
> > 
> 
> > > > dirPrivate
> > 
> 
> > > > )
> > 
> 
> > > >
> > 
> 
> > > > target_include_directories(otherlib PUBLIC
> > 
> 
> > > > dirPublic
> > 
> 
> > > > )
> > 
> 
> > > >
> > 
> 
> > > > add_library(mylib SHARED
> > 
> 
> > > > bar.c
> > 
> 
> > > > )
> > 
> 
> > > >
> > 
> 
> > > > target_link_libraries(mylib PRIVATE
> > 
> 

> > > Is this a typo ?
> > 
> 
> > > For the example to work I would have done: target_link_libraries(mylib
> > > PUBLIC
> > > otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not
> > > PRIVATE one's). Correct ?
> > 
> 

> > Public is whether it propagates outside of the current target to things
> > that
> > then require 'mylib'
> 
> > private keeps it within that target, has nothing to do with what it's
> > pulling
> > from any linked library.
> 

> > > > otherlib
> > 
> 
> > > > )
> > 
> 
> > > >
> > 
> 
> > > > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > 
> 
> > > > otherlib for its build. Thus, dirPublic will be added to the include
> > 
> 
> > > > directory search path for the compilation of bar.c of mylib. PRIVATE
> > 
> 
> > > > properties will not be propagated. In the above mentioned example,
> > 
> 
> > > > dirPrivate will NOT be added to the include directory search path for
> > 
> 
> > > > the compilation of bar.c of mylib.
> > 
> 
> > > >
> > 
> 

> > > The example is illustrative (transitivity - PRIVATE is not propagated)
> > 
> 

> > > > This is a very short summary, but I hope it is of help to you. There
> > 
> 
> > > > are other ressources on the Internet. E. g.
> > 
> 
> > > > *
> > 
> 
> > > > https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
> > 
> 
> > > > * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> > 
> 
> > > >
> > 
> 
> > > > Regards,
> > 
> 
> > > > Rainer
> > 
> 
> > > >
> > 
> 
> > > --
> > 
> 

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

> --
> Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/59ab977f/attachment-0001.html>

From eric.noulard at gmail.com  Mon Jan  8 05:27:29 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 8 Jan 2018 11:27:29 +0100
Subject: [CMake] CMake: using dlopen
In-Reply-To: <1692560912.14988270.1515406053959.JavaMail.zimbra@inria.fr>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
 <CAA2GJqUxfJ1QOBqD1ye_KQjKL49y5dA445th1t50Kd_s73veWw@mail.gmail.com>
 <CAPASGLrRhv-iTMaEGNc-V+CNtELoW8f_gBO7wFv74XZ2XVCQeg@mail.gmail.com>
 <1692560912.14988270.1515406053959.JavaMail.zimbra@inria.fr>
Message-ID: <CAPASGLoz-N793xqfsaBsw=ME_u38E58op9jepAx8+nt2gBD1zw@mail.gmail.com>

Franck,

Yes I understand and I mostly do the same.

However, anyone who already faced similar issue should be able to point you
to the "right" place in the doc.
Since this kind of discussion is popping up again I guess  the doc still
miss some bits.

I think the right place would be "usage requirements" :
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#target-usage-requirements

It could be improved for better understanding the impact of
PUBLIC/PRIVATE/INTERFACE
may be with some examples.


2018-01-08 11:07 GMT+01:00 Franck Houssen <franck.houssen at inria.fr>:

> I usually read the doc in a step-by-step mode (going from "small things"
> to "the next") when a (new) need/question shows up. When I can I try to
> "push" some notions (this is an example of it !).
> The doc is "vast" which is a good thing but not so easy when trying to
> read/understand all of it (personal opinion). To me, the doc misses simple
> illustrative examples like Rainer's one (here again, personal opinion).
>
>
> ------------------------------
>
> *De: *"Eric Noulard" <eric.noulard at gmail.com>
> *?: *"J Decker" <d3ck0r at gmail.com>
> *Cc: *"Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <
> cmake at cmake.org>
> *Envoy?: *Lundi 8 Janvier 2018 10:53:51
>
> *Objet: *Re: [CMake] CMake: using dlopen
>
> Explanations on PRIVATE, PUBLIC, INTERFACE has already been discussed in
> those ML threads:
> https://cmake.org/pipermail/cmake/2017-April/065340.html
> https://cmake.org/pipermail/cmake/2016-May/063400.html
>
> I guess we need some doc update.
> I did promess contribution and I didn't do it.
> I'll try again.
>
>
> 2018-01-08 10:45 GMT+01:00 J Decker <d3ck0r at gmail.com>:
>
>>
>> On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <franck.houssen at inria.fr>
>> wrote:
>>
>>>
>>>
>>> ----- Mail original -----
>>> > De: "Rainer Poisel" <rainer.poisel at gmail.com>
>>> > ?: "Franck Houssen" <franck.houssen at inria.fr>
>>> > Envoy?: Dimanche 7 Janvier 2018 19:34:21
>>> > Objet: Re: [CMake] CMake: using dlopen
>>> >
>>> > Hi,
>>> >
>>> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <
>>> franck.houssen at inria.fr>
>>> > wrote:
>>> > > Difference between PUBLIC/PRIVATE has never been clear to me
>>> (usually I
>>> > > always use PUBLIC).
>>> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
>>> > > (PRIVATE is for templates ? when a header include headers ?)
>>> >
>>> > you are looking for the "Transitive Dependencies" feature of CMake:
>>>
>>> OK, I didn't get that. It's more clear to me now. Thanks !
>>>
>>> >   *
>>> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.
>>> 7.html#transitive-usage-requirements
>>> >
>>> > Generally speaking and from my personal experience, use the
>>> > target_-commands as much as possible because properties are bound to
>>> > targets and their dependencies rather than a file/directory structure.
>>> >
>>> > So, that means, use target_include_directories(),
>>> > target_compile_options(), target_compile_definitions(),
>>> > target_sources(), ... for your targets. The magic keyword to propagate
>>> > the properties of your targets is target_link_libraries(). Depending
>>> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
>>> > defined using the other target_-commands, the target_link_libraries()
>>> > command propagates these properties to other targets. E. g.
>>> >
>>> > add_library(otherlib SHARED
>>> >   foo.c
>>> > )
>>> >
>>> > target_include_directories(otherlib PRIVATE
>>> >   dirPrivate
>>> > )
>>> >
>>> > target_include_directories(otherlib PUBLIC
>>> >   dirPublic
>>> > )
>>> >
>>> > add_library(mylib SHARED
>>> >   bar.c
>>> > )
>>> >
>>> > target_link_libraries(mylib PRIVATE
>>>
>>> Is this a typo ?
>>> For the example to work I would have done: target_link_libraries(mylib
>>> PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but
>>> not PRIVATE one's). Correct ?
>>>
>>>
>> Public is whether it propagates outside of the current target to things
>> that then require 'mylib'
>> private keeps it within that target, has nothing to do with what it's
>> pulling from any linked library.
>>
>>
>>>
>>> >   otherlib
>>> > )
>>> >
>>> > In this case, mylib will use all PUBLIC or INTERFACE properties of
>>> > otherlib for its build. Thus, dirPublic will be added to the include
>>> > directory search path for the compilation of bar.c of mylib. PRIVATE
>>> > properties will not be propagated. In the above mentioned example,
>>> > dirPrivate will NOT be added to the include directory search path for
>>> > the compilation of bar.c of mylib.
>>> >
>>>
>>> The example is illustrative (transitivity - PRIVATE is not propagated)
>>>
>>> > This is a very short summary, but I hope it is of help to you. There
>>> > are other ressources on the Internet. E. g.
>>> >   *
>>> >   https://stackoverflow.com/questions/26037954/cmake-
>>> target-link-libraries-interface-dependencies
>>> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
>>> >
>>> > Regards,
>>> >   Rainer
>>> >
>>> --
>>>
>>> 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
>>
>>
>
>
> --
> Eric
>
>
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/599845e4/attachment.html>

From franck.houssen at inria.fr  Mon Jan  8 05:56:47 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Mon, 8 Jan 2018 11:56:47 +0100 (CET)
Subject: [CMake] CMake: using dlopen
In-Reply-To: <CAPASGLoz-N793xqfsaBsw=ME_u38E58op9jepAx8+nt2gBD1zw@mail.gmail.com>
References: <E1eYEY9-0006Vv-SS@a-painless.mh.aa.net.uk>
 <1389564563.14632929.1515348810623.JavaMail.zimbra@inria.fr>
 <CADpFnzx2-KJD7AFE0D9wb9v32n04+z-G8=TXyEq22XiHkTJM-w@mail.gmail.com>
 <1280736981.14925851.1515404485684.JavaMail.zimbra@inria.fr>
 <CAA2GJqUxfJ1QOBqD1ye_KQjKL49y5dA445th1t50Kd_s73veWw@mail.gmail.com>
 <CAPASGLrRhv-iTMaEGNc-V+CNtELoW8f_gBO7wFv74XZ2XVCQeg@mail.gmail.com>
 <1692560912.14988270.1515406053959.JavaMail.zimbra@inria.fr>
 <CAPASGLoz-N793xqfsaBsw=ME_u38E58op9jepAx8+nt2gBD1zw@mail.gmail.com>
Message-ID: <703384642.15096016.1515409007529.JavaMail.zimbra@inria.fr>

----- Mail original -----

> De: "Eric Noulard" <eric.noulard at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "J Decker" <d3ck0r at gmail.com>, "CMake Mail List" <cmake at cmake.org>
> Envoy?: Lundi 8 Janvier 2018 11:27:29
> Objet: Re: [CMake] CMake: using dlopen

> Franck,

> Yes I understand and I mostly do the same.

> However, anyone who already faced similar issue should be able to point you
> to the "right" place in the doc.

I agree. 

> Since this kind of discussion is popping up again I guess the doc still miss
> some bits.

> I think the right place would be "usage requirements" :
> https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#target-usage-requirements

> It could be improved for better understanding the impact of
> PUBLIC/PRIVATE/INTERFACE
> may be with some examples.

Yes ! 

> 2018-01-08 11:07 GMT+01:00 Franck Houssen < franck.houssen at inria.fr > :

> > I usually read the doc in a step-by-step mode (going from "small things" to
> > "the next") when a (new) need/question shows up. When I can I try to "push"
> > some notions (this is an example of it !).
> 
> > The doc is "vast" which is a good thing but not so easy when trying to
> > read/understand all of it (personal opinion). To me, the doc misses simple
> > illustrative examples like Rainer's one (here again, personal opinion).
> 

> > > De: "Eric Noulard" < eric.noulard at gmail.com >
> > 
> 
> > > ?: "J Decker" < d3ck0r at gmail.com >
> > 
> 
> > > Cc: "Franck Houssen" < franck.houssen at inria.fr >, "CMake Mail List" <
> > > cmake at cmake.org >
> > 
> 
> > > Envoy?: Lundi 8 Janvier 2018 10:53:51
> > 
> 

> > > Objet: Re: [CMake] CMake: using dlopen
> > 
> 

> > > Explanations on PRIVATE, PUBLIC, INTERFACE has already been discussed in
> > > those ML threads:
> > 
> 
> > > https://cmake.org/pipermail/cmake/2017-April/065340.html
> > 
> 
> > > https://cmake.org/pipermail/cmake/2016-May/063400.html
> > 
> 

> > > I guess we need some doc update.
> > 
> 
> > > I did promess contribution and I didn't do it.
> > 
> 
> > > I'll try again.
> > 
> 

> > > 2018-01-08 10:45 GMT+01:00 J Decker < d3ck0r at gmail.com > :
> > 
> 

> > > > On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <
> > > > franck.houssen at inria.fr
> > > > >
> > > > wrote:
> > > 
> > 
> 

> > > > > ----- Mail original -----
> > > > 
> > > 
> > 
> 
> > > > > > De: "Rainer Poisel" < rainer.poisel at gmail.com >
> > > > 
> > > 
> > 
> 
> > > > > > ?: "Franck Houssen" < franck.houssen at inria.fr >
> > > > 
> > > 
> > 
> 
> > > > > > Envoy?: Dimanche 7 Janvier 2018 19:34:21
> > > > 
> > > 
> > 
> 
> > > > > > Objet: Re: [CMake] CMake: using dlopen
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > Hi,
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <
> > > > > > franck.houssen at inria.fr
> > > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > wrote:
> > > > 
> > > 
> > 
> 
> > > > > > > Difference between PUBLIC/PRIVATE has never been clear to me
> > > > > > > (usually
> > > > > > > I
> > > > 
> > > 
> > 
> 
> > > > > > > always use PUBLIC).
> > > > 
> > > 
> > 
> 
> > > > > > > main.cpp includes dlfcn.h and uses it: not sure to get what you
> > > > > > > meant
> > > > 
> > > 
> > 
> 
> > > > > > > (PRIVATE is for templates ? when a header include headers ?)
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > you are looking for the "Transitive Dependencies" feature of CMake:
> > > > 
> > > 
> > 
> 

> > > > > OK, I didn't get that. It's more clear to me now. Thanks !
> > > > 
> > > 
> > 
> 

> > > > > > *
> > > > 
> > > 
> > 
> 
> > > > > > https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > Generally speaking and from my personal experience, use the
> > > > 
> > > 
> > 
> 
> > > > > > target_-commands as much as possible because properties are bound
> > > > > > to
> > > > 
> > > 
> > 
> 
> > > > > > targets and their dependencies rather than a file/directory
> > > > > > structure.
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > So, that means, use target_include_directories(),
> > > > 
> > > 
> > 
> 
> > > > > > target_compile_options(), target_compile_definitions(),
> > > > 
> > > 
> > 
> 
> > > > > > target_sources(), ... for your targets. The magic keyword to
> > > > > > propagate
> > > > 
> > > 
> > 
> 
> > > > > > the properties of your targets is target_link_libraries().
> > > > > > Depending
> > > > 
> > > 
> > 
> 
> > > > > > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > > > 
> > > 
> > 
> 
> > > > > > defined using the other target_-commands, the
> > > > > > target_link_libraries()
> > > > 
> > > 
> > 
> 
> > > > > > command propagates these properties to other targets. E. g.
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > add_library(otherlib SHARED
> > > > 
> > > 
> > 
> 
> > > > > > foo.c
> > > > 
> > > 
> > 
> 
> > > > > > )
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > target_include_directories(otherlib PRIVATE
> > > > 
> > > 
> > 
> 
> > > > > > dirPrivate
> > > > 
> > > 
> > 
> 
> > > > > > )
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > target_include_directories(otherlib PUBLIC
> > > > 
> > > 
> > 
> 
> > > > > > dirPublic
> > > > 
> > > 
> > 
> 
> > > > > > )
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > add_library(mylib SHARED
> > > > 
> > > 
> > 
> 
> > > > > > bar.c
> > > > 
> > > 
> > 
> 
> > > > > > )
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > target_link_libraries(mylib PRIVATE
> > > > 
> > > 
> > 
> 

> > > > > Is this a typo ?
> > > > 
> > > 
> > 
> 
> > > > > For the example to work I would have done:
> > > > > target_link_libraries(mylib
> > > > > PUBLIC
> > > > > otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but
> > > > > not
> > > > > PRIVATE one's). Correct ?
> > > > 
> > > 
> > 
> 

> > > > Public is whether it propagates outside of the current target to things
> > > > that
> > > > then require 'mylib'
> > > 
> > 
> 
> > > > private keeps it within that target, has nothing to do with what it's
> > > > pulling
> > > > from any linked library.
> > > 
> > 
> 

> > > > > > otherlib
> > > > 
> > > 
> > 
> 
> > > > > > )
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > > > 
> > > 
> > 
> 
> > > > > > otherlib for its build. Thus, dirPublic will be added to the
> > > > > > include
> > > > 
> > > 
> > 
> 
> > > > > > directory search path for the compilation of bar.c of mylib.
> > > > > > PRIVATE
> > > > 
> > > 
> > 
> 
> > > > > > properties will not be propagated. In the above mentioned example,
> > > > 
> > > 
> > 
> 
> > > > > > dirPrivate will NOT be added to the include directory search path
> > > > > > for
> > > > 
> > > 
> > 
> 
> > > > > > the compilation of bar.c of mylib.
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 

> > > > > The example is illustrative (transitivity - PRIVATE is not
> > > > > propagated)
> > > > 
> > > 
> > 
> 

> > > > > > This is a very short summary, but I hope it is of help to you.
> > > > > > There
> > > > 
> > > 
> > 
> 
> > > > > > are other ressources on the Internet. E. g.
> > > > 
> > > 
> > 
> 
> > > > > > *
> > > > 
> > > 
> > 
> 
> > > > > > https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
> > > > 
> > > 
> > 
> 
> > > > > > * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > Regards,
> > > > 
> > > 
> > 
> 
> > > > > > Rainer
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > --
> > > > 
> > > 
> > 
> 

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

> > > --
> > 
> 
> > > Eric
> > 
> 

> --
> Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/1886b1f8/attachment-0001.html>

From mojca.miklavec.lists at gmail.com  Mon Jan  8 06:35:33 2018
From: mojca.miklavec.lists at gmail.com (Mojca Miklavec)
Date: Mon, 8 Jan 2018 12:35:33 +0100
Subject: [CMake] CMake support for MYS2
Message-ID: <CALBOmsbU_8Dsa21gAJZtV7DbPHhf6Wb-OCA39tZ1=rTK7knx7w@mail.gmail.com>

Dear CMake developers,

I installed msys2 from http://www.msys2.org/ and (after updating etc)
installed cmake via
    pacman -S cmake
as well as some other packages like "make", the gcc compiler etc.

But "ccmake" complains:


 System is unknown to cmake, create:
 Platform/MINGW32_NT-6.1 to use this system, please send your config file to
 cmake at www.cmake.org so it can be added to cmake

 Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please
send that file to
 cmake at www.cmake.org.


I believe I should additional set the compiler somehow, but I guess I
should be able to cope with that part. I just wanted to report the
failure to identify the platform while fighting with other problems.
(Meson works correctly out of the box.)

CopyOfCMakeCache is in attachment.

Thank you very much,
    Mojca
-------------- next part --------------
# This is the CMakeCache file.
# For build in directory: /c/Users/me/test/test-build
# It was generated by CMake: /usr/bin/cmake.exe
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.

########################
# EXTERNAL cache entries
########################

//Path to a program.
CMAKE_AR:FILEPATH=CMAKE_AR-NOTFOUND

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=CMAKE_CXX_COMPILER-NOTFOUND

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=

//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=

//Flags used by the compiler during release builds with debug info.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=

//Flags used by the linker.
CMAKE_EXE_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Enable/Disable output of compile commands during generation.
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF

//Install path prefix, prepended onto install directories.
CMAKE_INSTALL_PREFIX:PATH=/usr/local

//Path to a program.
CMAKE_LINKER:FILEPATH=CMAKE_LINKER-NOTFOUND

//Path to a program.
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make.exe

//Flags used by the linker during the creation of modules.
CMAKE_MODULE_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Path to a program.
CMAKE_NM:FILEPATH=CMAKE_NM-NOTFOUND

//Path to a program.
CMAKE_OBJCOPY:FILEPATH=CMAKE_OBJCOPY-NOTFOUND

//Path to a program.
CMAKE_OBJDUMP:FILEPATH=CMAKE_OBJDUMP-NOTFOUND

//Value Computed by CMake
CMAKE_PROJECT_NAME:STATIC=CommonLib

//Flags used by the linker during the creation of dll's.
CMAKE_SHARED_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//If set, runtime paths are not added when installing shared libraries,
// but are added when building.
CMAKE_SKIP_INSTALL_RPATH:BOOL=NO

//If set, runtime paths are not added when using shared libraries.
CMAKE_SKIP_RPATH:BOOL=NO

//Flags used by the linker during the creation of static libraries.
CMAKE_STATIC_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Path to a program.
CMAKE_STRIP:FILEPATH=CMAKE_STRIP-NOTFOUND

//If this value is on, makefiles will be generated without the
// .SILENT directive, and all commands will be echoed to the console
// during the make.  This is useful for debugging only. With Visual
// Studio IDE projects all commands are done without /nologo.
CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE

//Value Computed by CMake
CommonLib_BINARY_DIR:STATIC=/c/Users/me/test/test-build

//Value Computed by CMake
CommonLib_SOURCE_DIR:STATIC=/c/Users/me/test/test


########################
# INTERNAL cache entries
########################

//ADVANCED property for variable: CMAKE_AR
CMAKE_AR-ADVANCED:INTERNAL=1
//This is the directory where this CMakeCache.txt was created
CMAKE_CACHEFILE_DIR:INTERNAL=/c/Users/me/test/test-build
//Major version of cmake used to create the current loaded cache
CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3
//Minor version of cmake used to create the current loaded cache
CMAKE_CACHE_MINOR_VERSION:INTERNAL=9
//Patch version of cmake used to create the current loaded cache
CMAKE_CACHE_PATCH_VERSION:INTERNAL=6
//ADVANCED property for variable: CMAKE_COLOR_MAKEFILE
CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1
//Path to CMake executable.
CMAKE_COMMAND:INTERNAL=/usr/bin/cmake.exe
//Path to cpack program executable.
CMAKE_CPACK_COMMAND:INTERNAL=/usr/bin/cpack.exe
//Path to ctest program executable.
CMAKE_CTEST_COMMAND:INTERNAL=/usr/bin/ctest.exe
//ADVANCED property for variable: CMAKE_CXX_COMPILER
CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//Path to cache edit program executable.
CMAKE_EDIT_COMMAND:INTERNAL=/usr/bin/ccmake.exe
//Executable file format
CMAKE_EXECUTABLE_FORMAT:INTERNAL=Unknown
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE
CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXPORT_COMPILE_COMMANDS
CMAKE_EXPORT_COMPILE_COMMANDS-ADVANCED:INTERNAL=1
//Name of external makefile project generator.
CMAKE_EXTRA_GENERATOR:INTERNAL=
//Name of generator.
CMAKE_GENERATOR:INTERNAL=Unix Makefiles
//Name of generator platform.
CMAKE_GENERATOR_PLATFORM:INTERNAL=
//Name of generator toolset.
CMAKE_GENERATOR_TOOLSET:INTERNAL=
//Source directory with the top level CMakeLists.txt file for this
// project
CMAKE_HOME_DIRECTORY:INTERNAL=/c/Users/me/test/test
//ADVANCED property for variable: CMAKE_LINKER
CMAKE_LINKER-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MAKE_PROGRAM
CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG
CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE
CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_NM
CMAKE_NM-ADVANCED:INTERNAL=1
//number of local generators
CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=1
//ADVANCED property for variable: CMAKE_OBJCOPY
CMAKE_OBJCOPY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_OBJDUMP
CMAKE_OBJDUMP-ADVANCED:INTERNAL=1
//Platform information initialized
CMAKE_PLATFORM_INFO_INITIALIZED:INTERNAL=1
//noop for ranlib
CMAKE_RANLIB:INTERNAL=:
//Path to CMake installation.
CMAKE_ROOT:INTERNAL=/usr/share/cmake-3.9.6
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG
CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE
CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_INSTALL_RPATH
CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG
CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE
CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STRIP
CMAKE_STRIP-ADVANCED:INTERNAL=1
//uname command
CMAKE_UNAME:INTERNAL=/usr/bin/uname.exe
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1


From annulen at yandex.ru  Mon Jan  8 11:38:10 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 08 Jan 2018 19:38:10 +0300
Subject: [CMake] CMake support for MYS2
In-Reply-To: <CALBOmsbU_8Dsa21gAJZtV7DbPHhf6Wb-OCA39tZ1=rTK7knx7w@mail.gmail.com>
References: <CALBOmsbU_8Dsa21gAJZtV7DbPHhf6Wb-OCA39tZ1=rTK7knx7w@mail.gmail.com>
Message-ID: <3793661515429490@web30j.yandex.ru>



08.01.2018, 14:35, "Mojca Miklavec" <mojca.miklavec.lists at gmail.com>:
> Dear CMake developers,
>
> I installed msys2 from http://www.msys2.org/ and (after updating etc)
> installed cmake via
> ????pacman -S cmake

You should install mingw-w64-x86_64-cmake (or i686). You've installed
package that targets MSYS environment, not native Windows.

> as well as some other packages like "make", the gcc compiler etc.
>
> But "ccmake" complains:
>
> ?System is unknown to cmake, create:
> ?Platform/MINGW32_NT-6.1 to use this system, please send your config file to
> ?cmake at www.cmake.org so it can be added to cmake
>
> ?Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please
> send that file to
> ?cmake at www.cmake.org.
>
> I believe I should additional set the compiler somehow, but I guess I
> should be able to cope with that part. I just wanted to report the
> failure to identify the platform while fighting with other problems.
> (Meson works correctly out of the box.)
>
> CopyOfCMakeCache is in attachment.
>
> Thank you very much,
> ????Mojca
> ,--
>
> 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

From szymon.zakrent at gmail.com  Mon Jan  8 14:44:48 2018
From: szymon.zakrent at gmail.com (szymon zakrent)
Date: Mon, 8 Jan 2018 20:44:48 +0100
Subject: [CMake] Multiple cross compiling
Message-ID: <4c769558-5df7-078b-1a1f-6372d0e0a00d@gmail.com>

Is there a way to make cmake cross compile automatically for multiple
platforms at the same time without running cmake multiple times with
different toolchains?


From franck.houssen at inria.fr  Tue Jan  9 04:24:21 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Tue, 9 Jan 2018 10:24:21 +0100 (CET)
Subject: [CMake] configure_file: escaping (single) quotes
In-Reply-To: <1849277476.15718122.1515489510587.JavaMail.zimbra@inria.fr>
Message-ID: <550188828.15722032.1515489861444.JavaMail.zimbra@inria.fr>

Hello, 

I need configure_file to produce a bash file containing this line: 
VAR="${VAR// ' # ' /}" 

I tried without success VAR="${VAR// ' # ' /}" and VAR="${VAR// \' # \' /}" with and without ESCAPE_QUOTES in configure_file : always get an error like "Syntax error in cmake code when parsing string". 
Not a bash guru, and, can't get if the problem comes from bash or cmake... Can somebody help on this ? 

Franck 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/6aa65599/attachment.html>

From marc.chevrier at sap.com  Tue Jan  9 04:29:30 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Tue, 9 Jan 2018 09:29:30 +0000
Subject: [CMake] configure_file: escaping (single) quotes
Message-ID: <531906A9-34FD-4157-A539-3BF72479BCBD@sap.com>

The problem comes from CMake evaluating variable VAR (i.e. expression ${VAR?}) and detect wrong syntax.
The solution is to specify option @ONLY to command configure_file to avoid ${} evaluation.


From: CMake <cmake-bounces at cmake.org> on behalf of Franck Houssen <franck.houssen at inria.fr>
Date: Tuesday 9 January 2018 at 10:24
To: CMake Mail List <cmake at cmake.org>
Subject: [CMake] configure_file: escaping (single) quotes

VAR="${VAR//'#'/}"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/16d45a8f/attachment.html>

From d3ck0r at gmail.com  Tue Jan  9 04:29:34 2018
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 9 Jan 2018 01:29:34 -0800
Subject: [CMake] configure_file: escaping (single) quotes
In-Reply-To: <550188828.15722032.1515489861444.JavaMail.zimbra@inria.fr>
References: <1849277476.15718122.1515489510587.JavaMail.zimbra@inria.fr>
 <550188828.15722032.1515489861444.JavaMail.zimbra@inria.fr>
Message-ID: <CAA2GJqXoaK7ay0fmk0YAe01b2nS4P4dnJWjnKcvdOhUXLc0cew@mail.gmail.com>

On Tue, Jan 9, 2018 at 1:24 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> Hello,
>
> I need configure_file to produce a bash file containing this line:
> VAR="${VAR//*'*#*'*/}"
>
>
maybe

VAR="$" "{VAR//*'*#*'*/}"


> I tried without success VAR="${VAR//*'*#*'*/}" and VAR="${VAR//*\'*#*\'*/}"
> with and without ESCAPE_QUOTES in configure_file : always get an error
> like "Syntax error in cmake code when parsing string".
> Not a bash guru, and, can't get if the problem comes from bash or cmake...
> Can somebody help on this ?
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/979c7f1e/attachment.html>

From d3ck0r at gmail.com  Tue Jan  9 04:32:23 2018
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 9 Jan 2018 01:32:23 -0800
Subject: [CMake] configure_file: escaping (single) quotes
In-Reply-To: <CAA2GJqXoaK7ay0fmk0YAe01b2nS4P4dnJWjnKcvdOhUXLc0cew@mail.gmail.com>
References: <1849277476.15718122.1515489510587.JavaMail.zimbra@inria.fr>
 <550188828.15722032.1515489861444.JavaMail.zimbra@inria.fr>
 <CAA2GJqXoaK7ay0fmk0YAe01b2nS4P4dnJWjnKcvdOhUXLc0cew@mail.gmail.com>
Message-ID: <CAA2GJqWguM4NNAvOc=qXH3RSqUCZ4N9rq28fVkF4qUqFek5r5Q@mail.gmail.com>

On Tue, Jan 9, 2018 at 1:29 AM, J Decker <d3ck0r at gmail.com> wrote:

>
>
> On Tue, Jan 9, 2018 at 1:24 AM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
>
>> Hello,
>>
>> I need configure_file to produce a bash file containing this line:
>> VAR="${VAR//*'*#*'*/}"
>>
>>
> maybe
>
> VAR="$" "{VAR//*'*#*'*/}"
>
Oh nevermind I was doing that sort of thing using FILE( APPEND ... )


>
>
>
>> I tried without success VAR="${VAR//*'*#*'*/}" and VAR="${VAR//*\'*#*\'*/}"
>> with and without ESCAPE_QUOTES in configure_file : always get an error
>> like "Syntax error in cmake code when parsing string".
>> Not a bash guru, and, can't get if the problem comes from bash or
>> cmake... Can somebody help on this ?
>>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/53d0abe6/attachment-0001.html>

From franck.houssen at inria.fr  Tue Jan  9 05:23:52 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Tue, 9 Jan 2018 11:23:52 +0100 (CET)
Subject: [CMake] configure_file: escaping (single) quotes
In-Reply-To: <531906A9-34FD-4157-A539-3BF72479BCBD@sap.com>
References: <531906A9-34FD-4157-A539-3BF72479BCBD@sap.com>
Message-ID: <2007619620.15763713.1515493432475.JavaMail.zimbra@inria.fr>

----- Mail original -----


De: "Marc CHEVRIER" <marc.chevrier at sap.com> 
?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <cmake at cmake.org> 
Envoy?: Mardi 9 Janvier 2018 10:29:30 
Objet: Re: [CMake] configure_file: escaping (single) quotes 



The problem comes from CMake evaluating variable VAR (i.e. expression ${VAR?}) and detect wrong syntax. 

The solution is to specify option @ONLY to command configure_file to avoid ${} evaluation. 




The line after VAR is something like: 


VAR="${VAR// ' # ' /}" 

CMD="mpirun -n ${MPIEXEC_PREFLAGS} ${MPIEXEC_NUMPROC_FLAG} ${MPIEXEC_MAX_NUMPROCS} ${MPIEXEC_POSTFLAGS}" 




I need MPIEXEC_ * to be replaced. So, I need to use @ONLY and set all MPIEXEC variables with @ (but not $). Correct ? 


<blockquote>








From: CMake <cmake-bounces at cmake.org> on behalf of Franck Houssen <franck.houssen at inria.fr> 
Date: Tuesday 9 January 2018 at 10:24 
To: CMake Mail List <cmake at cmake.org> 
Subject: [CMake] configure_file: escaping (single) quotes 


VAR="${VAR// ' # ' /}" 

</blockquote>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/a04723e4/attachment.html>

From marc.chevrier at sap.com  Tue Jan  9 05:26:55 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Tue, 9 Jan 2018 10:26:55 +0000
Subject: [CMake] configure_file: escaping (single) quotes
In-Reply-To: <2007619620.15763713.1515493432475.JavaMail.zimbra@inria.fr>
References: <531906A9-34FD-4157-A539-3BF72479BCBD@sap.com>
 <2007619620.15763713.1515493432475.JavaMail.zimbra@inria.fr>
Message-ID: <E6B0DFF0-0663-4CA3-B6F6-F7AE204A6D17@sap.com>

Yes, you have to rewrite your line as:
CMD="mpirun -n @MPIEXEC_PREFLAGS@ @MPIEXEC_NUMPROC_FLAG@ @MPIEXEC_MAX_NUMPROCS@ @MPIEXEC_POSTFLAGS@"


From: Franck Houssen <franck.houssen at inria.fr>
Date: Tuesday 9 January 2018 at 11:23
To: "CHEVRIER, Marc" <marc.chevrier at sap.com>
Cc: CMake Mail List <cmake at cmake.org>
Subject: Re: [CMake] configure_file: escaping (single) quotes

________________________________
De: "Marc CHEVRIER" <marc.chevrier at sap.com>
?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <cmake at cmake.org>
Envoy?: Mardi 9 Janvier 2018 10:29:30
Objet: Re: [CMake] configure_file: escaping (single) quotes

The problem comes from CMake evaluating variable VAR (i.e. expression ${VAR?}) and detect wrong syntax.
The solution is to specify option @ONLY to command configure_file to avoid ${} evaluation.

The line after VAR is something like:

VAR="${VAR//'#'/}"

CMD="mpirun -n ${MPIEXEC_PREFLAGS} ${MPIEXEC_NUMPROC_FLAG} ${MPIEXEC_MAX_NUMPROCS} ${MPIEXEC_POSTFLAGS}"



I need MPIEXEC_* to be replaced. So, I need to use @ONLY and set all MPIEXEC variables with @ (but not $). Correct ?




From: CMake <cmake-bounces at cmake.org> on behalf of Franck Houssen <franck.houssen at inria.fr>
Date: Tuesday 9 January 2018 at 10:24
To: CMake Mail List <cmake at cmake.org>
Subject: [CMake] configure_file: escaping (single) quotes
VAR="${VAR//'#'/}"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/be931d67/attachment.html>

From franck.houssen at inria.fr  Tue Jan  9 05:32:09 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Tue, 9 Jan 2018 11:32:09 +0100 (CET)
Subject: [CMake] configure_file: escaping (single) quotes
In-Reply-To: <E6B0DFF0-0663-4CA3-B6F6-F7AE204A6D17@sap.com>
References: <531906A9-34FD-4157-A539-3BF72479BCBD@sap.com>
 <2007619620.15763713.1515493432475.JavaMail.zimbra@inria.fr>
 <E6B0DFF0-0663-4CA3-B6F6-F7AE204A6D17@sap.com>
Message-ID: <1358700947.15769687.1515493929841.JavaMail.zimbra@inria.fr>

OK. Got it to work ! Thanks 

----- Mail original -----

> De: "Marc CHEVRIER" <marc.chevrier at sap.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Mardi 9 Janvier 2018 11:26:55
> Objet: Re: [CMake] configure_file: escaping (single) quotes

> Yes, you have to rewrite your line as:

> CMD="mpirun -n @ MPIEXEC_PREFLAGS @ @ MPIEXEC_NUMPROC_FLAG @ @
> MPIEXEC_MAX_NUMPROCS @ @ MPIEXEC_POSTFLAGS @ "

> From: Franck Houssen <franck.houssen at inria.fr>
> Date: Tuesday 9 January 2018 at 11:23
> To: "CHEVRIER, Marc" <marc.chevrier at sap.com>
> Cc: CMake Mail List <cmake at cmake.org>
> Subject: Re: [CMake] configure_file: escaping (single) quotes

> ----- Mail original -----

> > De: "Marc CHEVRIER" <marc.chevrier at sap.com>
> 
> > ?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List"
> > <cmake at cmake.org>
> 
> > Envoy?: Mardi 9 Janvier 2018 10:29:30
> 
> > Objet: Re: [CMake] configure_file: escaping (single) quotes
> 

> > The problem comes from CMake evaluating variable VAR (i.e. expression
> > ${VAR?}) and detect wrong syntax.
> 

> > The solution is to specify option @ONLY to command configure_file to avoid
> > ${} evaluation.
> 

> The line after VAR is something like:

> VAR="${VAR// ' # ' /}"

> CMD="mpirun -n ${MPIEXEC_PREFLAGS} ${MPIEXEC_NUMPROC_FLAG}
> ${MPIEXEC_MAX_NUMPROCS} ${MPIEXEC_POSTFLAGS}"

> I need MPIEXEC_* to be replaced. So, I need to use @ONLY and set all MPIEXEC
> variables with @ (but not $). Correct ?

> > From: CMake <cmake-bounces at cmake.org> on behalf of Franck Houssen
> > <franck.houssen at inria.fr>
> 
> > Date: Tuesday 9 January 2018 at 10:24
> 
> > To: CMake Mail List <cmake at cmake.org>
> 
> > Subject: [CMake] configure_file: escaping (single) quotes
> 

> > VAR="${VAR// ' # ' /}"
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/c41568e3/attachment-0001.html>

From cosimo at anthrotype.com  Tue Jan  9 07:01:06 2018
From: cosimo at anthrotype.com (Cosimo Lupo)
Date: Tue, 09 Jan 2018 12:01:06 +0000
Subject: [CMake] how to port to cmake a project using gnulib
Message-ID: <CAPp41Bsm_dUDTLr4MiOgHfHQ-k6TDYjSE6nOMpqWvn7HY0zW5A@mail.gmail.com>

Hello,

I'm new to Cmake.

I would like to port to cmake a project that is currently built with the
Autotools and depends on gnulib, the GNU Portability Library:
https://www.gnu.org/software/gnulib/

(The project in question is https://www.freetype.org/ttfautohint/)

It appears that gnulib itself is very much tied with
autoconf/automake/libtool.

In fact I couldn't find any examples of other CMake based projects that use
gnulib.

Does anyone has any tips or examples on how I could proceed?

Thank you,

Cosimo Lupo


-- 
Cosimo Lupo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/93896be6/attachment.html>

From alfred at huji.fr  Tue Jan  9 07:10:47 2018
From: alfred at huji.fr (Alfred Sawaya)
Date: Tue, 09 Jan 2018 13:10:47 +0100
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <CAPp41Bsm_dUDTLr4MiOgHfHQ-k6TDYjSE6nOMpqWvn7HY0zW5A@mail.gmail.com>
Message-ID: <5a54b149.4c361c0a.bdfd6.59b6@mx.google.com>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/c64923f5/attachment.html>

From cosimo at anthrotype.com  Tue Jan  9 07:17:24 2018
From: cosimo at anthrotype.com (Cosimo Lupo)
Date: Tue, 09 Jan 2018 12:17:24 +0000
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <5a54b149.4c361c0a.bdfd6.59b6@mx.google.com>
References: <CAPp41Bsm_dUDTLr4MiOgHfHQ-k6TDYjSE6nOMpqWvn7HY0zW5A@mail.gmail.com>
 <5a54b149.4c361c0a.bdfd6.59b6@mx.google.com>
Message-ID: <CAPp41Bt5dBO3iNGSJ9O0B8=bY+m2Li8gpXGB1OGBpAE1WrUwWQ@mail.gmail.com>

Thanks.
However, that's not exactly what I was looking for. The gnulib, by design,
is not an external library that you link with, but a collection of modules
that are meant to be copied into one's project.
I would like to build ttfautohint with cmake (and ninja), not just adding
ttfautohint as an external project built with autotools and GNU make.


On Tue, Jan 9, 2018 at 12:10 PM Alfred Sawaya <alfred at huji.fr> wrote:

> Hello,
>
> I have some CMake projects that depend on autotools bases libs.
> I compile them as External project.
>
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
>
> Regards
>
> Cordialement,
>
> Alfred Sawaya
> *De:* cosimo at anthrotype.com
> *Envoy?:* 9 janvier 2018 1:01 PM
> *?:* cmake at cmake.org
> *Objet:* [CMake] how to port to cmake a project using gnulib
>
> Hello,
>
> I'm new to Cmake.
>
> I would like to port to cmake a project that is currently built with the
> Autotools and depends on gnulib, the GNU Portability Library:
> https://www.gnu.org/software/gnulib/
>
> (The project in question is https://www.freetype.org/ttfautohint/)
>
> It appears that gnulib itself is very much tied with
> autoconf/automake/libtool.
>
> In fact I couldn't find any examples of other CMake based projects that
> use gnulib.
>
> Does anyone has any tips or examples on how I could proceed?
>
> Thank you,
>
> Cosimo Lupo
>
>
> --
> Cosimo Lupo
>


-- 
Cosimo Lupo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/c529cefd/attachment.html>

From alfred at huji.fr  Tue Jan  9 07:36:09 2018
From: alfred at huji.fr (Alfred Sawaya)
Date: Tue, 09 Jan 2018 13:36:09 +0100
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <CAPp41Bt5dBO3iNGSJ9O0B8=bY+m2Li8gpXGB1OGBpAE1WrUwWQ@mail.gmail.com>
Message-ID: <5a54b73b.859bdf0a.9b6cf.5845@mx.google.com>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/23d162b7/attachment-0001.html>

From cosimo at anthrotype.com  Tue Jan  9 07:50:38 2018
From: cosimo at anthrotype.com (Cosimo Lupo)
Date: Tue, 09 Jan 2018 12:50:38 +0000
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <5a54b73b.859bdf0a.9b6cf.5845@mx.google.com>
References: <CAPp41Bt5dBO3iNGSJ9O0B8=bY+m2Li8gpXGB1OGBpAE1WrUwWQ@mail.gmail.com>
 <5a54b73b.859bdf0a.9b6cf.5845@mx.google.com>
Message-ID: <CAPp41BsPVqaQ=wNk0aqSQZ3_x3mn1iKT8tEWnF-QUYUaQHyhSA@mail.gmail.com>

Thanks for your help, Alfred.

The problem is that very concept of "external dependency" seems to be at
odds with the way gnulib is supposed to work.

And the docs are clear that "Gnulib assumes that your project uses
Autoconf. When using Gnulib, you will need to have Autoconf among your
build tools."

https://www.gnu.org/software/gnulib/manual/html_node//Initial-import.html#Initial-import

Anyway, let's see if others have any more clues.

Cheers

Cosimo



On Tue, Jan 9, 2018 at 12:36 PM Alfred Sawaya <alfred at huji.fr> wrote:

> Sorry, I did not got this hint.
>
> Well, you might still use gnulib as an external dependency (
> https://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html#POSIX-Substitutes-Library).
> Maybe be it worth considering a better separation if the build tool is
> different.
>
> I need to read more about gnulib to give you a better answer. Maybe
> someone already has a clue on the list.
>
> Regards,
>
> Cordialement,
>
> Alfred Sawaya
> *De:* cosimo at anthrotype.com
> *Envoy?:* 9 janvier 2018 1:17 PM
> *?:* alfred at huji.fr
> *Cc:* cmake at cmake.org
> *Objet:* Re: [CMake] how to port to cmake a project using gnulib
>
> Thanks.
> However, that's not exactly what I was looking for. The gnulib, by design,
> is not an external library that you link with, but a collection of modules
> that are meant to be copied into one's project.
> I would like to build ttfautohint with cmake (and ninja), not just adding
> ttfautohint as an external project built with autotools and GNU make.
>
>
> On Tue, Jan 9, 2018 at 12:10 PM Alfred Sawaya <alfred at huji.fr> wrote:
>
>> Hello,
>>
>> I have some CMake projects that depend on autotools bases libs.
>> I compile them as External project.
>>
>> https://cmake.org/cmake/help/latest/module/ExternalProject.html
>>
>> Regards
>>
>> Cordialement,
>>
>> Alfred Sawaya
>> *De:* cosimo at anthrotype.com
>> *Envoy?:* 9 janvier 2018 1:01 PM
>> *?:* cmake at cmake.org
>> *Objet:* [CMake] how to port to cmake a project using gnulib
>>
>> Hello,
>>
>> I'm new to Cmake.
>>
>> I would like to port to cmake a project that is currently built with the
>> Autotools and depends on gnulib, the GNU Portability Library:
>> https://www.gnu.org/software/gnulib/
>>
>> (The project in question is https://www.freetype.org/ttfautohint/)
>>
>> It appears that gnulib itself is very much tied with
>> autoconf/automake/libtool.
>>
>> In fact I couldn't find any examples of other CMake based projects that
>> use gnulib.
>>
>> Does anyone has any tips or examples on how I could proceed?
>>
>> Thank you,
>>
>> Cosimo Lupo
>>
>>
>> --
>> Cosimo Lupo
>>
>
>
> --
> Cosimo Lupo
>


-- 
Cosimo Lupo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/9d176015/attachment.html>

From cosimo at anthrotype.com  Tue Jan  9 07:55:09 2018
From: cosimo at anthrotype.com (Cosimo Lupo)
Date: Tue, 09 Jan 2018 12:55:09 +0000
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <CAPp41BsPVqaQ=wNk0aqSQZ3_x3mn1iKT8tEWnF-QUYUaQHyhSA@mail.gmail.com>
References: <CAPp41Bt5dBO3iNGSJ9O0B8=bY+m2Li8gpXGB1OGBpAE1WrUwWQ@mail.gmail.com>
 <5a54b73b.859bdf0a.9b6cf.5845@mx.google.com>
 <CAPp41BsPVqaQ=wNk0aqSQZ3_x3mn1iKT8tEWnF-QUYUaQHyhSA@mail.gmail.com>
Message-ID: <CAPp41BuPnNKmSHVdahD-r+t_DExWUpHEZajY+sgiw72kwkSJvg@mail.gmail.com>

This is from the gnulib mailing list in reply to a similar question on how
to use gnulib without autotools:

https://lists.gnu.org/archive/html/bug-gnulib/2010-02/msg00248.html

"Gnulib depends heavily on autoconf and automake.
You could manually extract the portions you think you need
and attempt to use them without the requisite glue, but that is
very error-prone."

:,(


On Tue, Jan 9, 2018 at 12:50 PM Cosimo Lupo <cosimo at anthrotype.com> wrote:

> Thanks for your help, Alfred.
>
> The problem is that very concept of "external dependency" seems to be at
> odds with the way gnulib is supposed to work.
>
> And the docs are clear that "Gnulib assumes that your project uses
> Autoconf. When using Gnulib, you will need to have Autoconf among your
> build tools."
>
>
> https://www.gnu.org/software/gnulib/manual/html_node//Initial-import.html#Initial-import
>
> Anyway, let's see if others have any more clues.
>
> Cheers
>
> Cosimo
>
>
>
> On Tue, Jan 9, 2018 at 12:36 PM Alfred Sawaya <alfred at huji.fr> wrote:
>
>> Sorry, I did not got this hint.
>>
>> Well, you might still use gnulib as an external dependency (
>> https://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html#POSIX-Substitutes-Library).
>> Maybe be it worth considering a better separation if the build tool is
>> different.
>>
>> I need to read more about gnulib to give you a better answer. Maybe
>> someone already has a clue on the list.
>>
>> Regards,
>>
>> Cordialement,
>>
>> Alfred Sawaya
>> *De:* cosimo at anthrotype.com
>> *Envoy?:* 9 janvier 2018 1:17 PM
>> *?:* alfred at huji.fr
>> *Cc:* cmake at cmake.org
>> *Objet:* Re: [CMake] how to port to cmake a project using gnulib
>>
>> Thanks.
>> However, that's not exactly what I was looking for. The gnulib, by
>> design, is not an external library that you link with, but a collection of
>> modules that are meant to be copied into one's project.
>> I would like to build ttfautohint with cmake (and ninja), not just adding
>> ttfautohint as an external project built with autotools and GNU make.
>>
>>
>> On Tue, Jan 9, 2018 at 12:10 PM Alfred Sawaya <alfred at huji.fr> wrote:
>>
>>> Hello,
>>>
>>> I have some CMake projects that depend on autotools bases libs.
>>> I compile them as External project.
>>>
>>> https://cmake.org/cmake/help/latest/module/ExternalProject.html
>>>
>>> Regards
>>>
>>> Cordialement,
>>>
>>> Alfred Sawaya
>>> *De:* cosimo at anthrotype.com
>>> *Envoy?:* 9 janvier 2018 1:01 PM
>>> *?:* cmake at cmake.org
>>> *Objet:* [CMake] how to port to cmake a project using gnulib
>>>
>>> Hello,
>>>
>>> I'm new to Cmake.
>>>
>>> I would like to port to cmake a project that is currently built with the
>>> Autotools and depends on gnulib, the GNU Portability Library:
>>> https://www.gnu.org/software/gnulib/
>>>
>>> (The project in question is https://www.freetype.org/ttfautohint/)
>>>
>>> It appears that gnulib itself is very much tied with
>>> autoconf/automake/libtool.
>>>
>>> In fact I couldn't find any examples of other CMake based projects that
>>> use gnulib.
>>>
>>> Does anyone has any tips or examples on how I could proceed?
>>>
>>> Thank you,
>>>
>>> Cosimo Lupo
>>>
>>>
>>> --
>>> Cosimo Lupo
>>>
>>
>>
>> --
>> Cosimo Lupo
>>
>
>
> --
> Cosimo Lupo
>


-- 
Cosimo Lupo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/cc5d2cd5/attachment-0001.html>

From annulen at yandex.ru  Tue Jan  9 08:01:59 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 09 Jan 2018 16:01:59 +0300
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <CAPp41BuPnNKmSHVdahD-r+t_DExWUpHEZajY+sgiw72kwkSJvg@mail.gmail.com>
References: <CAPp41Bt5dBO3iNGSJ9O0B8=bY+m2Li8gpXGB1OGBpAE1WrUwWQ@mail.gmail.com>
 <5a54b73b.859bdf0a.9b6cf.5845@mx.google.com>
 <CAPp41BsPVqaQ=wNk0aqSQZ3_x3mn1iKT8tEWnF-QUYUaQHyhSA@mail.gmail.com>
 <CAPp41BuPnNKmSHVdahD-r+t_DExWUpHEZajY+sgiw72kwkSJvg@mail.gmail.com>
Message-ID: <2823041515502919@web1o.yandex.ru>

Alfred: Gnulib isn't library in usual sense, AFAIK it's a bunch of source files some of which
may be added to the project if needed

Cosimo: I think you should stay with autotools, otherwsie it might be a can of worms.
Or get rid of gnulib.


09.01.2018, 15:55, "Cosimo Lupo" <cosimo at anthrotype.com>:
> This is from the gnulib mailing list in reply to a similar question on how to use gnulib without autotools:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2010-02/msg00248.html
>
> "Gnulib depends heavily on autoconf and automake.
> You could manually extract the portions you think you need
> and attempt to use them without the requisite glue, but that is
> very error-prone."
>
> :,(
>
> On Tue, Jan 9, 2018 at 12:50 PM Cosimo Lupo <cosimo at anthrotype.com> wrote:
>> Thanks for your help, Alfred.
>>
>> The problem is that very concept of "external dependency" seems to be at odds with the way gnulib is supposed to work.
>>
>> And the docs are clear that "Gnulib assumes that your project uses Autoconf. When using Gnulib, you will need to have Autoconf among your build tools."
>>
>> https://www.gnu.org/software/gnulib/manual/html_node//Initial-import.html#Initial-import
>>
>> Anyway, let's see if others have any more clues.
>>
>> Cheers
>>
>> Cosimo
>>
>> On Tue, Jan 9, 2018 at 12:36 PM Alfred Sawaya <alfred at huji.fr> wrote:
>>> Sorry, I did not got this hint.
>>>
>>> Well, you might?still use gnulib as an external dependency (https://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html#POSIX-Substitutes-Library). Maybe be it worth considering a better separation if the build tool is different.
>>>
>>> I need to read more about gnulib to give you a better answer. Maybe someone already has a clue on the list.
>>>
>>> Regards,
>>>
>>> Cordialement,
>>>
>>> Alfred Sawaya
>>>
>>> De: cosimo at anthrotype.com
>>> Envoy?: 9 janvier 2018 1:17 PM
>>> ?: alfred at huji.fr
>>> Cc: cmake at cmake.org
>>> Objet: Re: [CMake] how to port to cmake a project using gnulib
>>> Thanks.
>>> However, that's not exactly what I was looking for. The gnulib, by design, is not an external library that you link with, but a collection of modules that are meant to be copied into one's project.
>>> I would like to build ttfautohint with cmake (and ninja), not just adding ttfautohint as an external project built with autotools and GNU make.
>>>
>>> On Tue, Jan 9, 2018 at 12:10 PM Alfred Sawaya <alfred at huji.fr> wrote:
>>>> Hello,
>>>>
>>>> I have some CMake projects that depend on autotools bases libs.
>>>> I compile them as External project.
>>>>
>>>> https://cmake.org/cmake/help/latest/module/ExternalProject.html
>>>>
>>>> Regards
>>>>
>>>> Cordialement,
>>>>
>>>> Alfred Sawaya
>>>>
>>>> De: cosimo at anthrotype.com
>>>> Envoy?: 9 janvier 2018 1:01 PM
>>>> ?: cmake at cmake.org
>>>> Objet: [CMake] how to port to cmake a project using gnulib
>>>> Hello,
>>>>
>>>> I'm new to Cmake.
>>>>
>>>> I would like to port to cmake a project that is currently built with the Autotools and depends on gnulib, the GNU Portability Library:?https://www.gnu.org/software/gnulib/
>>>>
>>>> (The project in question is?https://www.freetype.org/ttfautohint/)
>>>>
>>>> It appears that gnulib itself is very much tied with autoconf/automake/libtool.
>>>>
>>>> In fact I couldn't find any examples of other CMake based projects that use gnulib.
>>>>
>>>> Does anyone has any tips or examples on how I could proceed?
>>>>
>>>> Thank you,
>>>>
>>>> Cosimo Lupo
>>>>
>>>> --
>>>> Cosimo Lupo
>>>
>>> --
>>> Cosimo Lupo
>>
>> --
>> Cosimo Lupo
>
> --
> Cosimo Lupo
> ,--
>
> 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

From irwin at beluga.phys.uvic.ca  Tue Jan  9 08:47:46 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Tue, 9 Jan 2018 05:47:46 -0800 (PST)
Subject: [CMake] how to port to cmake a project using gnulib
In-Reply-To: <CAPp41Bsm_dUDTLr4MiOgHfHQ-k6TDYjSE6nOMpqWvn7HY0zW5A@mail.gmail.com>
References: <CAPp41Bsm_dUDTLr4MiOgHfHQ-k6TDYjSE6nOMpqWvn7HY0zW5A@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1801090507200.18536@enira.zlyna.ubzr>

On 2018-01-09 12:01-0000 Cosimo Lupo wrote:

> Hello,
>
> I'm new to Cmake.
>
> I would like to port to cmake a project that is currently built with the
> Autotools and depends on gnulib, the GNU Portability Library:
> https://www.gnu.org/software/gnulib/
>
> (The project in question is https://www.freetype.org/ttfautohint/)
>
> It appears that gnulib itself is very much tied with
> autoconf/automake/libtool.
>
> In fact I couldn't find any examples of other CMake based projects that use
> gnulib.
>
> Does anyone has any tips or examples on how I could proceed?

Hi Cosimo:

I have looked at the subsequent list traffic responding to your
question above, and there
appeared to be a clear need for a description of what gnulib really
is.  That is provided by <https://www.gnu.org/software/gnulib/> which
states that gnulib is the GNU Portability Library that is apparently
designed to aid portability of software to different operating systems.
That description of gnulib further
states (in part):

"Gnulib [...] components are intended to be
shared at the source level, rather than being a library that gets
built, installed, and linked against. Thus, there is no distribution
tarball; the idea is to copy files from Gnulib into your own source
tree."

However, I think because gnulib is all about aiding portability and
CMake already is designed to do that task, you likely won't need
gnulib at all once you implement a CMake-based build system for your
own software.  I base that opinion on the general complete lack of
knowledge (including me before I got curious and read the above
description of gnulib) concerning gnulib here.  However, if it turns
out there is still some small useful component of gnulib C source code
that would be useful for your own project, it is an absolutely simple
matter under CMake to build a mixture of library source code from your
project's source directories and some subset of the source code from
the gnulib source directories.

So my best advice is don't be concerned about gnulib executables or
autotools-related cruft at all.  That is, don't be concerned in the
slightest about gnulib unless there is some specific place in your
source code that calls one of the gnulib routines.  And take care
of that case with CMake as indicated above.

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
__________________________

From franck.houssen at inria.fr  Tue Jan  9 09:57:45 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Tue, 9 Jan 2018 15:57:45 +0100 (CET)
Subject: [CMake] how to detect architecture ?
In-Reply-To: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
Message-ID: <1328068172.15929831.1515509865289.JavaMail.zimbra@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 ? 

Franck 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/77cb8b83/attachment.html>

From annulen at yandex.ru  Tue Jan  9 10:00:55 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 09 Jan 2018 18:00:55 +0300
Subject: [CMake] how to detect architecture ?
In-Reply-To: <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
References: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
 <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
Message-ID: <173831515510055@web29o.yandex.ru>



09.01.2018, 17:58, "Franck Houssen" <franck.houssen at 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}

> 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

From d3ck0r at gmail.com  Tue Jan  9 10:01:21 2018
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 9 Jan 2018 07:01:21 -0800
Subject: [CMake] how to detect architecture ?
In-Reply-To: <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
References: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
 <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
Message-ID: <CAA2GJqUEbkxiO0OJSj0cnTV987fum6FN7AF0txS5B1_j1J353A@mail.gmail.com>

On Tue, Jan 9, 2018 at 6:57 AM, Franck Houssen <franck.houssen at inria.fr>
wrote:

> 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 ?
>
>
https://cmake.org/Wiki/CMake_Useful_Variables
https://cmake.org/Wiki/CMake_Checking_Platform

if( APPLE )
   install( PROGRAMS apple.script.sh DESTINATION script.sh )
elseif( UNIX )
   install( PROGRAMS linux.script.sh DESTINATION script.sh )
endif( )
# not sure what the correct tag in endif should be.

so you can just keep 2 scripts and install approrpiately


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180109/c22825d3/attachment.html>

From franck.houssen at inria.fr  Tue Jan  9 10:04:28 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Tue, 9 Jan 2018 16:04:28 +0100 (CET)
Subject: [CMake] how to detect architecture ?
In-Reply-To: <173831515510055@web29o.yandex.ru>
References: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
 <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
 <173831515510055@web29o.yandex.ru>
Message-ID: <544314714.15938853.1515510268977.JavaMail.zimbra@inria.fr>

Thanks ! 

----- Mail original -----
> De: "Konstantin Tokarev" <annulen at yandex.ru>
> ?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <cmake at 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.houssen at 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
> 

From robert.maynard at kitware.com  Tue Jan  9 10:31:12 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 9 Jan 2018 10:31:12 -0500
Subject: [CMake] Multiple cross compiling
In-Reply-To: <4c769558-5df7-078b-1a1f-6372d0e0a00d@gmail.com>
References: <4c769558-5df7-078b-1a1f-6372d0e0a00d@gmail.com>
Message-ID: <CAFzjYVqLOuwqxKC6nFO4m9AEZGs8rqa6yHDO99XmNbyQ2atxGw@mail.gmail.com>

Currently CMake only supports a single platform / toolchain per build directory.

If you need to build with multiple toolchains you will need to use
some form of a wrapper. Which can either be an external script that
invokes CMake multiple times or a CMake project that uses
ExternalProject (
https://cmake.org/cmake/help/latest/module/ExternalProject.html )


On Mon, Jan 8, 2018 at 2:44 PM, szymon zakrent <szymon.zakrent at gmail.com> wrote:
> Is there a way to make cmake cross compile automatically for multiple
> platforms at the same time without running cmake multiple times with
> different toolchains?
>
> --
>
> 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

From rcarter at esturion.net  Tue Jan  9 17:46:37 2018
From: rcarter at esturion.net (Russell L. Carter)
Date: Tue, 9 Jan 2018 15:46:37 -0700
Subject: [CMake] include_directories converting CMAKE_BINARY_DIR into
 relative path
Message-ID: <341c7bd7-34fc-210d-cf78-010f4cd25928@esturion.net>

Greetings,

I am trying to generate a platform specific file by copying it from
the source tree into a specific directory in the separate
out-of-source build tree.  The file generation works fine.

When I try the following cmake code:

set(target_dir ${CMAKE_BINARY_DIR}/nail/platform)
message("target_dir: ${target_dir}")
include_directories(${target_dir})

where message displays:

target_dir: /home/rcarter/nail/core/build/g++7.Debug/nail/platform

That's what I want and the generated files exist in that directory.

However, I get the following error:

FAILED: nail/CMakeFiles/nail_core.dir/platform/time.cpp.o
/usr/local/bin/g++7  -Dnail_core_EXPORTS -I../../ -Inail/platform -g -O 
-std=c++17 -fno-omit-frame-pointer -fstack-protector -Wall -Wextra 
-fvisibility=hidden -fvisibility-inlines-hidden -fPIC -MD -MT 
nail/CMakeFiles/nail_core.dir/platform/time.cpp.o -MF 
nail/CMakeFiles/nail_core.dir/platform/time.cpp.o.d -o 
nail/CMakeFiles/nail_core.dir/platform/time.cpp.o -c nail/platform/time.cpp
nail/platform/time.cpp:2:10: fatal error: nail/platform/time.hpp: No 
such file or directory

Evidently the include_directories() command is converting the
the supplied absolute path to a relative path (-Inail/platform).

What should I do to get that include directory in the
build tree added correctly to the includes?  I suppose I could
add it manually to the CXX flags?  What's the best cmake
friendly way to handle this?

Thanks,
Russell

From rcarter at esturion.net  Tue Jan  9 19:01:31 2018
From: rcarter at esturion.net (Russell L. Carter)
Date: Tue, 9 Jan 2018 17:01:31 -0700
Subject: [CMake] include_directories converting CMAKE_BINARY_DIR into
 relative path
In-Reply-To: <341c7bd7-34fc-210d-cf78-010f4cd25928@esturion.net>
References: <341c7bd7-34fc-210d-cf78-010f4cd25928@esturion.net>
Message-ID: <92db36d5-6676-158f-d868-144ab59e4e66@esturion.net>

Ah well, I figured out the problem, it was located between my
chair and my keyboard.  Everything works perfectly now.  I sure
do love cmake.

Thanks,
Russell

On 01/09/18 15:46, Russell L. Carter wrote:
> Greetings,
> 
> I am trying to generate a platform specific file by copying it from
> the source tree into a specific directory in the separate
> out-of-source build tree.? The file generation works fine.
> 
> When I try the following cmake code:
> 
> set(target_dir ${CMAKE_BINARY_DIR}/nail/platform)
> message("target_dir: ${target_dir}")
> include_directories(${target_dir})
> 
> where message displays:
> 
> target_dir: /home/rcarter/nail/core/build/g++7.Debug/nail/platform
> 
> That's what I want and the generated files exist in that directory.
> 
> However, I get the following error:
> 
> FAILED: nail/CMakeFiles/nail_core.dir/platform/time.cpp.o
> /usr/local/bin/g++7? -Dnail_core_EXPORTS -I../../ -Inail/platform -g -O 
> -std=c++17 -fno-omit-frame-pointer -fstack-protector -Wall -Wextra 
> -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -MD -MT 
> nail/CMakeFiles/nail_core.dir/platform/time.cpp.o -MF 
> nail/CMakeFiles/nail_core.dir/platform/time.cpp.o.d -o 
> nail/CMakeFiles/nail_core.dir/platform/time.cpp.o -c nail/platform/time.cpp
> nail/platform/time.cpp:2:10: fatal error: nail/platform/time.hpp: No 
> such file or directory
> 
> Evidently the include_directories() command is converting the
> the supplied absolute path to a relative path (-Inail/platform).
> 
> What should I do to get that include directory in the
> build tree added correctly to the includes?? I suppose I could
> add it manually to the CXX flags?? What's the best cmake
> friendly way to handle this?
> 
> Thanks,
> Russell

From mojca.miklavec.lists at gmail.com  Wed Jan 10 03:40:32 2018
From: mojca.miklavec.lists at gmail.com (Mojca Miklavec)
Date: Wed, 10 Jan 2018 09:40:32 +0100
Subject: [CMake] CMake support for MYS2
In-Reply-To: <3793661515429490@web30j.yandex.ru>
References: <CALBOmsbU_8Dsa21gAJZtV7DbPHhf6Wb-OCA39tZ1=rTK7knx7w@mail.gmail.com>
 <3793661515429490@web30j.yandex.ru>
Message-ID: <CALBOmsbiYAiTCvqUcvS=FWNVVb3ngtP5z6=dPhuRRFEe5sCA-Q@mail.gmail.com>

On 8 January 2018 at 17:38, Konstantin Tokarev wrote:
> 08.01.2018, 14:35, "Mojca Miklavec":
>> Dear CMake developers,
>>
>> I installed msys2 from http://www.msys2.org/ and (after updating etc)
>> installed cmake via
>>     pacman -S cmake
>
> You should install mingw-w64-x86_64-cmake (or i686).

Thank you very much. That package is missing ccmake though, so I can
only run cmake directly and even then it strangely(?) defaults to
Visual Studio when I would expect it to go for Unix Makefiles.
(The "ccmake" from /usr/bin/ccmake is not helping in any way either, I
was hoping it would perhaps use mingw-w64-x86_64-cmake.)

I later noticed that there is /mingw64/bin/cmake-gui.exe, but that one
doesn't really work either:

$ cmake-gui
C:/msys/msys64/mingw64/bin/cmake-gui.exe: error while loading shared
libraries: librhash.dll: cannot open shared object file: No such file
or directory

> You've installed
> package that targets MSYS environment, not native Windows.

I still assume that others might run into exactly the same isuse in
the future. Since it's explicitly suggesting to write to the mailing
list, the reports might repeat.
(OK, I don't expect so many people to use the strange unix toolchains
on windows platforms, but still.)

Thank you,
    Mojca

>> as well as some other packages like "make", the gcc compiler etc.
>>
>> But "ccmake" complains:
>>
>>  System is unknown to cmake, create:
>>  Platform/MINGW32_NT-6.1 to use this system, please send your config file to
>>  cmake at www.cmake.org so it can be added to cmake
>>
>>  Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please
>> send that file to
>>  cmake at www.cmake.org.
>>
>> I believe I should additional set the compiler somehow, but I guess I
>> should be able to cope with that part. I just wanted to report the
>> failure to identify the platform while fighting with other problems.
>> (Meson works correctly out of the box.)
>>
>> CopyOfCMakeCache is in attachment.
>>
>> Thank you very much,
>>     Mojca
>
> --
> Regards,
> Konstantin

From franck.houssen at inria.fr  Wed Jan 10 04:47:34 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Wed, 10 Jan 2018 10:47:34 +0100 (CET)
Subject: [CMake] test depending on code compilation
In-Reply-To: <1025569814.16228425.1515575159047.JavaMail.zimbra@inria.fr>
Message-ID: <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>

I need to design a test (= a bash script) such that : 
1) run a dedicated executable for the test (to be compiled) 
2) diff the run output with a reference log file 

The test is created with : add_test(mytest ./mytest.sh). The bash script would look like: 
>> more mytest.sh 
/path/to/mytestexe > out.log 
diff out.log out.ref 

The dedicated executable for the test is created with : add_executable(mytestexe mytestexe.cpp) 

Ideally, I would like mytestexe to be compiled when I type "make test" (before to run the test) but not "make". 

Seems impossible to add a dependencie with : add_dependencies(mytest mytestexe). I googled this and found https://stackoverflow.com/questions/733475/cmake-ctest-make-test-doesnt-build-tests but this was not really clear to me...I added : add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} DEPENDS mytestexe). 

The 2 unexpected problems I have left are: 
1) mytestexe is compiled everytime I type "make" which is a solution but is not really what I am looking for (also compiled when I type "make check" which is expected). 
=> is there a way for make not to compile mytestexe (note I didn't added ALL in add_custom_target so I am not sure to know why make builds mytestexe) 
2) Also the verbosity is broken with check : make test ARGS="-V" is verbose , but, make check ARGS="-V" is not. 
=> how to deal with that ? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180110/4a940b39/attachment.html>

From annulen at yandex.ru  Wed Jan 10 05:56:30 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 10 Jan 2018 13:56:30 +0300
Subject: [CMake] CMake support for MYS2
In-Reply-To: <CALBOmsbiYAiTCvqUcvS=FWNVVb3ngtP5z6=dPhuRRFEe5sCA-Q@mail.gmail.com>
References: <CALBOmsbU_8Dsa21gAJZtV7DbPHhf6Wb-OCA39tZ1=rTK7knx7w@mail.gmail.com>
 <3793661515429490@web30j.yandex.ru>
 <CALBOmsbiYAiTCvqUcvS=FWNVVb3ngtP5z6=dPhuRRFEe5sCA-Q@mail.gmail.com>
Message-ID: <1331515581790@web14j.yandex.ru>



10.01.2018, 11:40, "Mojca Miklavec" <mojca.miklavec.lists at gmail.com>:
> On 8 January 2018 at 17:38, Konstantin Tokarev wrote:
>> ?08.01.2018, 14:35, "Mojca Miklavec":
>>> ?Dear CMake developers,
>>>
>>> ?I installed msys2 from http://www.msys2.org/ and (after updating etc)
>>> ?installed cmake via
>>> ?????pacman -S cmake
>>
>> ?You should install mingw-w64-x86_64-cmake (or i686).
>
> Thank you very much. That package is missing ccmake though

Please report it as a bug. cmake package should provide ccmake, or
there should be a separate package if ncurses dependency is undesirable
in the main package.

>, so I can
> only run cmake directly and even then it strangely(?) defaults to
> Visual Studio when I would expect it to go for Unix Makefiles.

This is behavior of vanilla cmake, so it's reasonable that it is not altered.
You can use msys2 like a generic Windows software repository, not only
for MinGW- or MSYS-based development.

> (The "ccmake" from /usr/bin/ccmake is not helping in any way either, I
> was hoping it would perhaps use mingw-w64-x86_64-cmake.)
>
> I later noticed that there is /mingw64/bin/cmake-gui.exe, but that one
> doesn't really work either:
>
> $ cmake-gui
> C:/msys/msys64/mingw64/bin/cmake-gui.exe: error while loading shared
> libraries: librhash.dll: cannot open shared object file: No such file
> or directory
>
>> ?You've installed
>> ?package that targets MSYS environment, not native Windows.
>
> I still assume that others might run into exactly the same isuse in
> the future. Since it's explicitly suggesting to write to the mailing
> list, the reports might repeat.

This is a packaging problem, so it should be reported to msys2
maintainers first.

in the meanwhile, you can edit CMakeCache.txt file directly, gui tools
don't really add much :)

> (OK, I don't expect so many people to use the strange unix toolchains
> on windows platforms, but still.)
>
> Thank you,
> ????Mojca
>
>>> ?as well as some other packages like "make", the gcc compiler etc.
>>>
>>> ?But "ccmake" complains:
>>>
>>> ??System is unknown to cmake, create:
>>> ??Platform/MINGW32_NT-6.1 to use this system, please send your config file to
>>> ??cmake at www.cmake.org so it can be added to cmake
>>>
>>> ??Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please
>>> ?send that file to
>>> ??cmake at www.cmake.org.
>>>
>>> ?I believe I should additional set the compiler somehow, but I guess I
>>> ?should be able to cope with that part. I just wanted to report the
>>> ?failure to identify the platform while fighting with other problems.
>>> ?(Meson works correctly out of the box.)
>>>
>>> ?CopyOfCMakeCache is in attachment.
>>>
>>> ?Thank you very much,
>>> ?????Mojca
>>
>> ?--
>> ?Regards,
>> ?Konstantin

-- 
Regards,
Konstantin

From franck.houssen at inria.fr  Wed Jan 10 06:22:39 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Wed, 10 Jan 2018 12:22:39 +0100 (CET)
Subject: [CMake] test depending on code compilation
In-Reply-To: <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
References: <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
Message-ID: <771501731.16353395.1515583359071.JavaMail.zimbra@inria.fr>

I tried to reduce the example: 

>> ls 
CMakeLists.txt main.cpp mytest.cpp mytest.sh 

>> more * 
:::::::::::::: 
CMakeLists.txt 
:::::::::::::: 
cmake_minimum_required(VERSION 3.7) 
enable_language(CXX) 

project(main) 
add_executable(main main.cpp) 
add_executable(mytestcpp mytest.cpp) 

include(CTest) 
enable_testing() 
configure_file("${CMAKE_CURRENT_SOURCE_DIR}/mytest.sh" "${CMAKE_CURRENT_BINARY_DIR}/mytest.sh") 
add_test(NAME mytestsh COMMAND ./mytest.sh WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}") 

add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} DEPENDS mytestcpp) 
:::::::::::::: 
main.cpp 
:::::::::::::: 
int main() {return 0;} 
:::::::::::::: 
mytest.cpp 
:::::::::::::: 
int main() {return 0;} 
:::::::::::::: 
mytest.sh 
:::::::::::::: 
#!/bin/bash 
exit 0 

I want make to build only main => KO 
>> make 
[ 50%] Built target main 
[100%] Built target mytestcpp 

I want make check to build mytestcpp and run tests => OK but verbose is KO. 
>> make check ARGS="-V" 
[100%] Built target mytestcpp 
Test project /tmp/BUILD 
Start 1: mytestsh 
1/1 Test #1: mytestsh ......................... Passed 0.00 sec 

I want make test to run test only => OK and verbose is OK. 

----- Mail original -----

> De: "Franck Houssen" <franck.houssen at inria.fr>
> ?: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Mercredi 10 Janvier 2018 10:47:34
> Objet: [CMake] test depending on code compilation

> I need to design a test (= a bash script) such that :
> 1) run a dedicated executable for the test (to be compiled)
> 2) diff the run output with a reference log file

> The test is created with : add_test(mytest ./mytest.sh). The bash script
> would look like:
> >> more mytest.sh
> /path/to/mytestexe > out.log
> diff out.log out.ref

> The dedicated executable for the test is created with :
> add_executable(mytestexe mytestexe.cpp)

> Ideally, I would like mytestexe to be compiled when I type "make test"
> (before to run the test) but not "make".

> Seems impossible to add a dependencie with : add_dependencies(mytest
> mytestexe). I googled this and found
> https://stackoverflow.com/questions/733475/cmake-ctest-make-test-doesnt-build-tests
> but this was not really clear to me...I added : add_custom_target(check
> COMMAND ${CMAKE_CTEST_COMMAND} DEPENDS mytestexe).

> The 2 unexpected problems I have left are:
> 1) mytestexe is compiled everytime I type "make" which is a solution but is
> not really what I am looking for (also compiled when I type "make check"
> which is expected).
> => is there a way for make not to compile mytestexe (note I didn't added ALL
> in add_custom_target so I am not sure to know why make builds mytestexe)
> 2) Also the verbosity is broken with check : make test ARGS="-V" is verbose ,
> but, make check ARGS="-V" is not.
> => how to deal with that ?

> --

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180110/9e45b364/attachment-0001.html>

From mojca.miklavec.lists at gmail.com  Wed Jan 10 07:58:13 2018
From: mojca.miklavec.lists at gmail.com (Mojca Miklavec)
Date: Wed, 10 Jan 2018 13:58:13 +0100
Subject: [CMake] CMake support for MYS2
In-Reply-To: <1331515581790@web14j.yandex.ru>
References: <CALBOmsbU_8Dsa21gAJZtV7DbPHhf6Wb-OCA39tZ1=rTK7knx7w@mail.gmail.com>
 <3793661515429490@web30j.yandex.ru>
 <CALBOmsbiYAiTCvqUcvS=FWNVVb3ngtP5z6=dPhuRRFEe5sCA-Q@mail.gmail.com>
 <1331515581790@web14j.yandex.ru>
Message-ID: <CALBOmsa1bD1yk10dOrYbLKF-qASbFBgnBAUvNJi4SUsxFWCgFQ@mail.gmail.com>

On 10 January 2018 at 11:56, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 10.01.2018, 11:40, "Mojca Miklavec" <mojca.miklavec.lists at gmail.com>:
>> On 8 January 2018 at 17:38, Konstantin Tokarev wrote:
>>>  08.01.2018, 14:35, "Mojca Miklavec":
>>>>  Dear CMake developers,
>>>>
>>>>  I installed msys2 from http://www.msys2.org/ and (after updating etc)
>>>>  installed cmake via
>>>>      pacman -S cmake
>>>
>>>  You should install mingw-w64-x86_64-cmake (or i686).
>>
>> Thank you very much. That package is missing ccmake though
>
> Please report it as a bug. cmake package should provide ccmake, or
> there should be a separate package if ncurses dependency is undesirable
> in the main package.

I can create a bug report, but I would like to clarify with CMake
developers first before I know what exactly to report in the first
place.

I'm pretty sure that this is a side-effect of CMake's own build
figuring out that it's being built on and for Windows, so it probably
skips building ccmake and builds cmake-gui.exe instead.

This all makes perfect sense for distributing the standalone
executable on Windows, but it's less suitable in the context of MSYS2.

>>, so I can
>> only run cmake directly and even then it strangely(?) defaults to
>> Visual Studio when I would expect it to go for Unix Makefiles.
>
> This is behavior of vanilla cmake, so it's reasonable that it is not altered.

I assume it belongs "to the same category" as the lack of ccmake.

I can imagine that it would make sense to offer to ways of building
cmake on Windows: the "standalone" mode without ccmake, with cmake-gui
and defaulting to Visual Studio. And the "command-line" mode with
ccmake and defaulting to "Unix Makefiles". Of course one could build
both ccmake and cmake-gui at the same time if desired.

We often have this problem with a Mac package manager. Many software
builds do "if this is mac, then standard unix tools don't exist, so do
something completely different" and they would create the app bundle,
but skip the rest of command-line friendliness and completely ignore
the fact that those unix tools may exist after all.

> You can use msys2 like a generic Windows software repository, not only
> for MinGW- or MSYS-based development.

I admit that I don't totally understand how exactly it's supposed to
work, but further discussion would be too off-topic for this list, I
assume.

>> (The "ccmake" from /usr/bin/ccmake is not helping in any way either, I
>> was hoping it would perhaps use mingw-w64-x86_64-cmake.)
>>
>> I later noticed that there is /mingw64/bin/cmake-gui.exe, but that one
>> doesn't really work either:
>>
>> $ cmake-gui
>> C:/msys/msys64/mingw64/bin/cmake-gui.exe: error while loading shared
>> libraries: librhash.dll: cannot open shared object file: No such file
>> or directory
>>
>>>  You've installed
>>>  package that targets MSYS environment, not native Windows.
>>
>> I still assume that others might run into exactly the same isuse in
>> the future. Since it's explicitly suggesting to write to the mailing
>> list, the reports might repeat.
>
> This is a packaging problem, so it should be reported to msys2
> maintainers first.

OK.

> in the meanwhile, you can edit CMakeCache.txt file directly, gui tools
> don't really add much :)

Well, I can always use
    cmake -G "..." -Dwhatever ../source
but ccmake is useful to show what configuration options the program is
offering. Editing CMakeCache is a feasible workaround, but I would
like to have a proper fix at the end.

Thanks a lot for all the useful insights.

Mojca

From eric.noulard at gmail.com  Wed Jan 10 08:48:24 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 10 Jan 2018 14:48:24 +0100
Subject: [CMake] Is a there a mean to check that all target are installed?
Message-ID: <CAPASGLqwnAKXLOwfY09WTT0E2-Qheu+4M8CRheWiR-oAw=Sb9w@mail.gmail.com>

Is there a way to programmatically check whether
all (or some) CMake targets are installed?

I want to be able to check that all defined targets of a particular project
(at least libraries or executable) are installed.

I can recursively retrieve all targets using
https://cmake.org/cmake/help/v3.9/prop_dir/BUILDSYSTEM_TARGETS.html
directory property.

But then I want to know if a target has been installed or not by some
install(...) rules.

Is it possible?

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180110/611face4/attachment.html>

From lucas.soltic at orange.fr  Wed Jan 10 18:09:49 2018
From: lucas.soltic at orange.fr (Lucas Soltic)
Date: Thu, 11 Jan 2018 00:09:49 +0100
Subject: [CMake] Creating a relocatable ProjectConfig.cmake when build uses
 absolute paths
Message-ID: <EDC117A0-A274-45C4-8EFF-24346B74EFF9@orange.fr>

Hello,

I'm trying to create a relocatable package configuration file but I'm having a hard time with absolute paths that are used during the build.
Note that I use CMake 3.10.0.

First of all for the include path I'm using this:
target_include_directories(MyStaticTarget PUBLIC
                           $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include>
                           $<INSTALL_INTERFACE:include>)

This does work but according to the doc it should not : https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html?highlight=build_interface#output-expressions <https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html?highlight=build_interface#output-expressions>
The doc of BUILD_INTERFACE says: "Content of ... when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise."
So according to the doc, when compiling the target MyTarget, the include dir I gave should not be used. Which seems consistent with the other uses of INTERFACE wording in CMake language. But it actually behaves like PUBLIC rather than INTERFACE. This is fine to me but inconsistent? :)
When exporting the target, the include dir uses what's given in for INSTALL_INTERFACE so it works fine. No problem on that part.


The second point is about libraries to link when using my project. My project exports a static library that depends on other libraries. These libraries are found (when generating my project through cmake) through calls like find_package(OpenGL). This provides a variable that contains an absolute non-relocatable path.

I've tried doing things like this:
target_link_libraries(MyStaticTarget PRIVATE
                      $<BUILD_INTERFACE:${OpenGL_absolute_path}>
                      $<INSTALL_INTERFACE:${OpenGL_relocatable_link_flag}>)

According to https://cmake.org/pipermail/cmake/2016-May/063400.html <https://cmake.org/pipermail/cmake/2016-May/063400.html>, for static libraries, PRIVATE link dependencies become "PUBLIC", which is ok. And I could see that the link flag for this "private" dependency got exported in the generated config. But the problem is that whatever I put for INSTALL_INTERFACE, it is ignored and not written to the generated cmake config file. The generated CMake config file just takes into account what I put for BUILD_INTERFACE. Contrary to what happened with include directories. And I don't want to use only ${OpenGL_relocatable_link_flag} because MyStaticTarget can be configured to be a dynamic library, in which case the library is really used during link and really want to link against the exact library that's referenced.

How can I have ${OpenGL_relocatable_link_flag} be used in the generated cmake config file?
Any other solution that would make the generated config relocatable is also fine.

Best regards,
Lucas 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180111/e09b1ec6/attachment.html>

From franck.houssen at inria.fr  Thu Jan 11 02:56:04 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 11 Jan 2018 08:56:04 +0100 (CET)
Subject: [CMake] test depending on code compilation
In-Reply-To: <771501731.16353395.1515583359071.JavaMail.zimbra@inria.fr>
References: <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
 <771501731.16353395.1515583359071.JavaMail.zimbra@inria.fr>
Message-ID: <310669044.16739631.1515657364958.JavaMail.zimbra@inria.fr>

OK, so I guess there is no way to do that like with autotools... 

----- Mail original -----

> De: "Franck Houssen" <franck.houssen at inria.fr>
> ?: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Mercredi 10 Janvier 2018 12:22:39
> Objet: Re: [CMake] test depending on code compilation

> I tried to reduce the example:

> >> ls
> CMakeLists.txt main.cpp mytest.cpp mytest.sh

> >> more *
> ::::::::::::::
> CMakeLists.txt
> ::::::::::::::
> cmake_minimum_required(VERSION 3.7)
> enable_language(CXX)

> project(main)
> add_executable(main main.cpp)
> add_executable(mytestcpp mytest.cpp)

> include(CTest)
> enable_testing()
> configure_file("${CMAKE_CURRENT_SOURCE_DIR}/mytest.sh"
> "${CMAKE_CURRENT_BINARY_DIR}/mytest.sh")
> add_test(NAME mytestsh COMMAND ./mytest.sh WORKING_DIRECTORY
> "${CMAKE_CURRENT_BINARY_DIR}")

> add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} DEPENDS mytestcpp)
> ::::::::::::::
> main.cpp
> ::::::::::::::
> int main() {return 0;}
> ::::::::::::::
> mytest.cpp
> ::::::::::::::
> int main() {return 0;}
> ::::::::::::::
> mytest.sh
> ::::::::::::::
> #!/bin/bash
> exit 0

> I want make to build only main => KO
> >> make
> [ 50%] Built target main
> [100%] Built target mytestcpp

> I want make check to build mytestcpp and run tests => OK but verbose is KO.
> >> make check ARGS="-V"
> [100%] Built target mytestcpp
> Test project /tmp/BUILD
> Start 1: mytestsh
> 1/1 Test #1: mytestsh ......................... Passed 0.00 sec

> I want make test to run test only => OK and verbose is OK.

> ----- Mail original -----

> > De: "Franck Houssen" <franck.houssen at inria.fr>
> 
> > ?: "CMake Mail List" <cmake at cmake.org>
> 
> > Envoy?: Mercredi 10 Janvier 2018 10:47:34
> 
> > Objet: [CMake] test depending on code compilation
> 

> > I need to design a test (= a bash script) such that :
> 
> > 1) run a dedicated executable for the test (to be compiled)
> 
> > 2) diff the run output with a reference log file
> 

> > The test is created with : add_test(mytest ./mytest.sh). The bash script
> > would look like:
> 
> > >> more mytest.sh
> 
> > /path/to/mytestexe > out.log
> 
> > diff out.log out.ref
> 

> > The dedicated executable for the test is created with :
> > add_executable(mytestexe mytestexe.cpp)
> 

> > Ideally, I would like mytestexe to be compiled when I type "make test"
> > (before to run the test) but not "make".
> 

> > Seems impossible to add a dependencie with : add_dependencies(mytest
> > mytestexe). I googled this and found
> > https://stackoverflow.com/questions/733475/cmake-ctest-make-test-doesnt-build-tests
> > but this was not really clear to me...I added : add_custom_target(check
> > COMMAND ${CMAKE_CTEST_COMMAND} DEPENDS mytestexe).
> 

> > The 2 unexpected problems I have left are:
> 
> > 1) mytestexe is compiled everytime I type "make" which is a solution but is
> > not really what I am looking for (also compiled when I type "make check"
> > which is expected).
> 
> > => is there a way for make not to compile mytestexe (note I didn't added
> > ALL
> > in add_custom_target so I am not sure to know why make builds mytestexe)
> 
> > 2) Also the verbosity is broken with check : make test ARGS="-V" is verbose
> > ,
> > but, make check ARGS="-V" is not.
> 
> > => how to deal with that ?
> 

> > --
> 

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180111/08a59cd9/attachment.html>

From mario.werner at iaik.tugraz.at  Thu Jan 11 10:27:18 2018
From: mario.werner at iaik.tugraz.at (Mario Werner)
Date: Thu, 11 Jan 2018 16:27:18 +0100
Subject: [CMake] test depending on code compilation
In-Reply-To: <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
References: <1025569814.16228425.1515575159047.JavaMail.zimbra@inria.fr>
 <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
Message-ID: <p37vkq$15l$1@blaine.gmane.org>

On 2018-01-10 10:47, Franck Houssen wrote:
> [snip]
> 
> The 2 unexpected problems I have left are:
> 1) mytestexe is compiled everytime I type "make" which is a solution but
> is not really what I am looking for (also compiled when I type "make
> check" which is expected).
> ??? => is there a way for make not to compile mytestexe (note I didn't
> added ALL in add_custom_target so I am not sure to know why make builds
> mytestexe)

You have to excluded mytestexe from the ALL target if you do not want
that it gets built by default [1]. (e.g., add EXCLUDE_FROM_ALL to
add_executable [2])

> 2) Also the verbosity is broken with check : make test ARGS="-V" is
> verbose , but, make check ARGS="-V" is not.
> ??? => how to deal with that ?
> 
> 

Can't help you there. I usually simply use `make check` to build and run
the full test suite in order to get an overview. Afterwards, I directly
call `ctest` with the desired arguments, for example when triaging a bug.

HTH,
Mario


[1] https://cmake.org/cmake/help/v3.0/prop_tgt/EXCLUDE_FROM_ALL.html
[2]
https://cmake.org/cmake/help/v3.0/command/add_executable.html?highlight=EXCLUDE_FROM_ALL


From franck.houssen at inria.fr  Thu Jan 11 12:03:15 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 11 Jan 2018 18:03:15 +0100 (CET)
Subject: [CMake] test depending on code compilation
In-Reply-To: <p37vkq$15l$1@blaine.gmane.org>
References: <1025569814.16228425.1515575159047.JavaMail.zimbra@inria.fr>
 <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
 <p37vkq$15l$1@blaine.gmane.org>
Message-ID: <2028930020.17183939.1515690195505.JavaMail.zimbra@inria.fr>



----- Mail original -----
> De: "Mario Werner" <mario.werner at iaik.tugraz.at>
> ?: cmake at cmake.org
> Envoy?: Jeudi 11 Janvier 2018 16:27:18
> Objet: Re: [CMake] test depending on code compilation
> 
> On 2018-01-10 10:47, Franck Houssen wrote:
> > [snip]
> > 
> > The 2 unexpected problems I have left are:
> > 1) mytestexe is compiled everytime I type "make" which is a solution but
> > is not really what I am looking for (also compiled when I type "make
> > check" which is expected).
> > ??? => is there a way for make not to compile mytestexe (note I didn't
> > added ALL in add_custom_target so I am not sure to know why make builds
> > mytestexe)
> 
> You have to excluded mytestexe from the ALL target if you do not want
> that it gets built by default [1]. (e.g., add EXCLUDE_FROM_ALL to
> add_executable [2])
> 

OK !

> > 2) Also the verbosity is broken with check : make test ARGS="-V" is
> > verbose , but, make check ARGS="-V" is not.
> > ??? => how to deal with that ?
> > 
> > 
> 
> Can't help you there. I usually simply use `make check` to build and run
> the full test suite in order to get an overview. Afterwards, I directly
> call `ctest` with the desired arguments, for example when triaging a bug.
> 

In travis a make check ARGS="-V" could be convenient to see output of tests while they run (understand what is wrong when if it fails - you can't get files from travis).
Anyway, that not so blocking.

> HTH,
> Mario
> 
> 
> [1] https://cmake.org/cmake/help/v3.0/prop_tgt/EXCLUDE_FROM_ALL.html
> [2]
> https://cmake.org/cmake/help/v3.0/command/add_executable.html?highlight=EXCLUDE_FROM_ALL
> 
> --
> 
> 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
> 

From saadrustam at gmail.com  Thu Jan 11 13:43:45 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Thu, 11 Jan 2018 18:43:45 +0000
Subject: [CMake] Get find_package to choose INSTALLed libraries instead of
 libraries in the build folder
Message-ID: <CAEM70sNiL_kRDPCOx6z5_Uwm3Wqd+kekNBdd6Ve7_XDNEpbWzQ@mail.gmail.com>

Hi,

I would like find_package(MyLib) to link find the libraries found in the
INSTALL folder instead of the build folder.

Currently, when I do a find_package(MyLib) and then
target_link_libraries(target MyLib) the paths all point to MyLib's build
folder and not the folder where MyLib's library/headers were installed.

Thank you,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180111/9a5fd140/attachment.html>

From marc.chevrier at sap.com  Fri Jan 12 02:57:13 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Fri, 12 Jan 2018 07:57:13 +0000
Subject: [CMake] Get find_package to choose INSTALLed libraries instead
 of libraries in the build folder
In-Reply-To: <CAEM70sNiL_kRDPCOx6z5_Uwm3Wqd+kekNBdd6Ve7_XDNEpbWzQ@mail.gmail.com>
References: <CAEM70sNiL_kRDPCOx6z5_Uwm3Wqd+kekNBdd6Ve7_XDNEpbWzQ@mail.gmail.com>
Message-ID: <9EB4C155-F415-4EA4-B5B1-35FD8BA81796@sap.com>

Hi,

During install step, installed libraries and executables are relinked to generate binaries without absolute paths so installed artifacts are independent from your build tree.

During build step, build binaries are used as well as absolute paths so produced binaries can be used during build step (i.e. launching an executable produced) without requirements regarding paths settings (i.e. PATH or LD_LIBRARY_PATH).


From: CMake <cmake-bounces at cmake.org> on behalf of Saad Khattak <saadrustam at gmail.com>
Date: Thursday 11 January 2018 at 19:44
To: Cmake Mailing List <cmake at cmake.org>
Subject: [CMake] Get find_package to choose INSTALLed libraries instead of libraries in the build folder

Hi,

I would like find_package(MyLib) to link find the libraries found in the INSTALL folder instead of the build folder.

Currently, when I do a find_package(MyLib) and then target_link_libraries(target MyLib) the paths all point to MyLib's build folder and not the folder where MyLib's library/headers were installed.

Thank you,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/40499724/attachment.html>

From mario.werner at iaik.tugraz.at  Fri Jan 12 03:38:50 2018
From: mario.werner at iaik.tugraz.at (Mario Werner)
Date: Fri, 12 Jan 2018 09:38:50 +0100
Subject: [CMake] test depending on code compilation
In-Reply-To: <2028930020.17183939.1515690195505.JavaMail.zimbra@inria.fr>
References: <1025569814.16228425.1515575159047.JavaMail.zimbra@inria.fr>
 <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
 <p37vkq$15l$1@blaine.gmane.org>
 <2028930020.17183939.1515690195505.JavaMail.zimbra@inria.fr>
Message-ID: <p39s2u$1dv$1@blaine.gmane.org>

On 2018-01-11 18:03, Franck Houssen wrote:
> 
> 
> ----- Mail original -----
>> De: "Mario Werner" <mario.werner at iaik.tugraz.at>
>> ?: cmake at cmake.org
>> Envoy?: Jeudi 11 Janvier 2018 16:27:18
>> Objet: Re: [CMake] test depending on code compilation
>>
> [snip]
>
>>> 2) Also the verbosity is broken with check : make test ARGS="-V" is
>>> verbose , but, make check ARGS="-V" is not.
>>> ??? => how to deal with that ?
>>>
>>>
>>
>> Can't help you there. I usually simply use `make check` to build and run
>> the full test suite in order to get an overview. Afterwards, I directly
>> call `ctest` with the desired arguments, for example when triaging a bug.
>>
> 
> In travis a make check ARGS="-V" could be convenient to see output of tests while they run (understand what is wrong when if it fails - you can't get files from travis).
> Anyway, that not so blocking.
> 

Right, I usually have two custom targets in my projects to deal with
that in a generic way. Namely, "suite" for building the tests and
"check" for building+running the tests.

Developers can then use "make check" as usual to build and run the tests
without providing any arguments to ctest. On the other hand, the CI
system can build using the "suite" target and execute ctest directly
like in the following example. (Of course developers can do the same if
needed)

```

    - mkdir _build
    - cd _build
    - cmake -DCMAKE_BUILD_TYPE=Release ..
    - cmake --build . --target suite -- -j2
    - ctest -V

```

I use the following helper macro to generate the needed boilerplate
code. Usage is then as simple as calling `add_to_suite` for every target.

```

macro(add_to_suite target)
  # add suite target which is used as meta target for building the tests
  if(NOT TARGET "suite")
    add_custom_target("suite")
  endif()

  # add check command which calls ctest
  # it additionally depends on the suite target to build the test cases
  if(NOT TARGET "check")
    add_custom_target("check" COMMAND ${CMAKE_CTEST_COMMAND}
                              WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
                              COMMENT "Executing test suite.")
    add_dependencies("check" "suite")
  endif()

  add_dependencies("suite" ${target})
endmacro()

# usage example (repeat for any number of tests you have
add_executable(testexe EXCLUDE_FROM_ALL ${test_source_files})
target_link_libraries(testexe ${link_dependencies})
add_to_suite(testexe)

```

Note that, instead of specifying EXCLUDE_FROM_ALL on every
add_executable, I usually have all my tests in one directory and specify
EXCLUDE_FROM_ALL on the add_subdirectory call.


From franck.houssen at inria.fr  Fri Jan 12 04:36:49 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Fri, 12 Jan 2018 10:36:49 +0100 (CET)
Subject: [CMake] test depending on code compilation
In-Reply-To: <p39s2u$1dv$1@blaine.gmane.org>
References: <1025569814.16228425.1515575159047.JavaMail.zimbra@inria.fr>
 <875510869.16262548.1515577654030.JavaMail.zimbra@inria.fr>
 <p37vkq$15l$1@blaine.gmane.org>
 <2028930020.17183939.1515690195505.JavaMail.zimbra@inria.fr>
 <p39s2u$1dv$1@blaine.gmane.org>
Message-ID: <726097320.17502782.1515749809355.JavaMail.zimbra@inria.fr>



----- Mail original -----
> De: "Mario Werner" <mario.werner at iaik.tugraz.at>
> ?: cmake at cmake.org
> Envoy?: Vendredi 12 Janvier 2018 09:38:50
> Objet: Re: [CMake] test depending on code compilation
> 
> On 2018-01-11 18:03, Franck Houssen wrote:
> > 
> > 
> > ----- Mail original -----
> >> De: "Mario Werner" <mario.werner at iaik.tugraz.at>
> >> ?: cmake at cmake.org
> >> Envoy?: Jeudi 11 Janvier 2018 16:27:18
> >> Objet: Re: [CMake] test depending on code compilation
> >>
> > [snip]
> >
> >>> 2) Also the verbosity is broken with check : make test ARGS="-V" is
> >>> verbose , but, make check ARGS="-V" is not.
> >>> ??? => how to deal with that ?
> >>>
> >>>
> >>
> >> Can't help you there. I usually simply use `make check` to build and run
> >> the full test suite in order to get an overview. Afterwards, I directly
> >> call `ctest` with the desired arguments, for example when triaging a bug.
> >>
> > 
> > In travis a make check ARGS="-V" could be convenient to see output of tests
> > while they run (understand what is wrong when if it fails - you can't get
> > files from travis).
> > Anyway, that not so blocking.
> > 
> 
> Right, I usually have two custom targets in my projects to deal with
> that in a generic way. Namely, "suite" for building the tests and
> "check" for building+running the tests.
> 
> Developers can then use "make check" as usual to build and run the tests
> without providing any arguments to ctest. On the other hand, the CI
> system can build using the "suite" target and execute ctest directly
> like in the following example. (Of course developers can do the same if
> needed)
> 
> ```
> 
>     - mkdir _build
>     - cd _build
>     - cmake -DCMAKE_BUILD_TYPE=Release ..
>     - cmake --build . --target suite -- -j2
>     - ctest -V
> 
> ```
> 
> I use the following helper macro to generate the needed boilerplate
> code. Usage is then as simple as calling `add_to_suite` for every target.
> 
> ```
> 
> macro(add_to_suite target)
>   # add suite target which is used as meta target for building the tests
>   if(NOT TARGET "suite")
>     add_custom_target("suite")
>   endif()
> 
>   # add check command which calls ctest
>   # it additionally depends on the suite target to build the test cases
>   if(NOT TARGET "check")
>     add_custom_target("check" COMMAND ${CMAKE_CTEST_COMMAND}
>                               WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
>                               COMMENT "Executing test suite.")
>     add_dependencies("check" "suite")
>   endif()
> 
>   add_dependencies("suite" ${target})
> endmacro()
> 
> # usage example (repeat for any number of tests you have
> add_executable(testexe EXCLUDE_FROM_ALL ${test_source_files})
> target_link_libraries(testexe ${link_dependencies})
> add_to_suite(testexe)
> 

OK, I see. I'll try that way. Thanks

> ```
> 
> Note that, instead of specifying EXCLUDE_FROM_ALL on every
> add_executable, I usually have all my tests in one directory and specify
> EXCLUDE_FROM_ALL on the add_subdirectory call.
> 
> --
> 
> 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
> 

From irwin at beluga.phys.uvic.ca  Fri Jan 12 04:58:09 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 12 Jan 2018 01:58:09 -0800 (PST)
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
Message-ID: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>

I am looking into the practicality of using clusters containing ~5
cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
and test software (since even with ccache I am currently spending a
lot of my time waiting for tests to complete as I develop my
software).  Such clusters would give you ~40 cores which is a lot of
computer power for ~$500 or so.  But, of course, the issue with
clusters is how to use them efficiently?

For one 8-core M3 you would expect

make -j<NNN> target

to scale linearly with NNN up to the saturation limit of roughly NNN=8
(where target depends on ~hundreds of different and mostly independent
tests). But my understanding from recent Google searching is that the
-j option for GNU Make is not MPI-aware, i.e., only works for the
cores for a single computer (node) in a cluster.  So in a cluster you
would have to assign the above task to just one node and simply accept
that you cannot scale NNN up to the total number of cores in that
cluster.

I did find one reference to an effort (called the pmake project at
Lawrence Livermore, see <https://computing.llnl.gov/code/pmake.html>)
to modify GNU make to become MPI-aware so the above command would
roughly scale NNN up to the number of cores in the cluster.  But the
single developer of the project seemed unable to overcome a bug in the
result so that parallel make project was abandoned.

I hope someone here can point me to a make variant (does Ninja
qualify?) that does have the capability of scaling NNN up to the
number of cores in the cluster since that would make clusters with a
large number of cores become extremely useful for the purpose of quick
testing by software developers.

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
__________________________

From nilsgladitz at gmail.com  Fri Jan 12 05:11:15 2018
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 12 Jan 2018 11:11:15 +0100
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
In-Reply-To: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
Message-ID: <CAEbDRx0QLcphCZqi_5ZDmb_V-OB382cQ61q23C=pMgT=OumWEg@mail.gmail.com>

On Fri, Jan 12, 2018 at 10:58 AM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> I am looking into the practicality of using clusters containing ~5
> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
> and test software (since even with ccache I am currently spending a
> lot of my time waiting for tests to complete as I develop my
> software).  Such clusters would give you ~40 cores which is a lot of
> computer power for ~$500 or so.  But, of course, the issue with
> clusters is how to use them efficiently?
>

I don't know anything about MPI but would distributed compilation via icecc
(icecream) [1] or distcc be an option?
Should work with both the Makefile and Ninja generators (replace compilers
with icecc/distcc compiler wrappers).

Nils

[1] https://github.com/icecc/icecream
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/f9c3b2d5/attachment.html>

From eric.noulard at gmail.com  Fri Jan 12 05:14:20 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 12 Jan 2018 11:14:20 +0100
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
In-Reply-To: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
Message-ID: <CAPASGLqPG+eKLF-YPq+_pUe_kqymtn8SbXNctcycXNdwiP-vBg@mail.gmail.com>

2018-01-12 10:58 GMT+01:00 Alan W. Irwin <irwin at beluga.phys.uvic.ca>:

> I am looking into the practicality of using clusters containing ~5
> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
> and test software (since even with ccache I am currently spending a
> lot of my time waiting for tests to complete as I develop my
> software).  Such clusters would give you ~40 cores which is a lot of
> computer power for ~$500 or so.  But, of course, the issue with
> clusters is how to use them efficiently?
>
> For one 8-core M3 you would expect
>
> make -j<NNN> target
>
> to scale linearly with NNN up to the saturation limit of roughly NNN=8
> (where target depends on ~hundreds of different and mostly independent
> tests). But my understanding from recent Google searching is that the
> -j option for GNU Make is not MPI-aware, i.e., only works for the
> cores for a single computer (node) in a cluster.  So in a cluster you
> would have to assign the above task to just one node and simply accept
> that you cannot scale NNN up to the total number of cores in that
> cluster.
>

>
AFAIU what you want is "distributed ctest" not really distributed build
right?
For distributed build you may have a look at distcc (http://distcc.org/)
which seems already used
by CMake-enabled project like ccache is
(
https://stackoverflow.com/questions/32752446/using-compiler-prefix-commands-with-cmake-distcc-ccache/34317588
)

Now I'm not quite sure to understand why you speak of MPI-awareness ?
Are your test including MPI which would mean that some executable are
already eating up more than one core?
Or do you have a big collection of mono-processor tests you want to run on
the cluster?

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/49a275b6/attachment.html>

From eric.noulard at gmail.com  Fri Jan 12 05:26:47 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 12 Jan 2018 11:26:47 +0100
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
In-Reply-To: <CAPASGLqPG+eKLF-YPq+_pUe_kqymtn8SbXNctcycXNdwiP-vBg@mail.gmail.com>
References: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
 <CAPASGLqPG+eKLF-YPq+_pUe_kqymtn8SbXNctcycXNdwiP-vBg@mail.gmail.com>
Message-ID: <CAPASGLo+UAwrLdZZPfCO+TgYVpukB7dh_vmQexwFc1vWrfyYUQ@mail.gmail.com>

2018-01-12 11:14 GMT+01:00 Eric Noulard <eric.noulard at gmail.com>:

>
>
> 2018-01-12 10:58 GMT+01:00 Alan W. Irwin <irwin at beluga.phys.uvic.ca>:
>
>> I am looking into the practicality of using clusters containing ~5
>> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
>> and test software (since even with ccache I am currently spending a
>> lot of my time waiting for tests to complete as I develop my
>> software).  Such clusters would give you ~40 cores which is a lot of
>> computer power for ~$500 or so.  But, of course, the issue with
>> clusters is how to use them efficiently?
>>
>> For one 8-core M3 you would expect
>>
>> make -j<NNN> target
>>
>> to scale linearly with NNN up to the saturation limit of roughly NNN=8
>>
>
A side note on that.
Sometimes you want to control the 'load' more than the "parallelism".
With make (or ninja) you can ask for **load** limitation using:

make -l <N>
and
ninja -l <N>

i.e. if you have 8 core and you want to keep 1 of them "calm" then
make -l 7

is interesting.


>
> AFAIU what you want is "distributed ctest" not really distributed build
> right?
> For distributed build you may have a look at distcc (http://distcc.org/)
> which seems already used
> by CMake-enabled project like ccache is
> (https://stackoverflow.com/questions/32752446/using-
> compiler-prefix-commands-with-cmake-distcc-ccache/34317588)
>
> Now I'm not quite sure to understand why you speak of MPI-awareness ?
> Are your test including MPI which would mean that some executable are
> already eating up more than one core?
> Or do you have a big collection of mono-processor tests you want to run on
> the cluster?
>

Concerning high-level distributed execution on a cluster I would have a
look at something
like OpenPBS: http://www.rguha.net/writing/pub/opbs.html (now apparently
http://pbspro.org/).

Once you have your PBS cluster setup I would say that you would need to
write a small test driver
that would launch the tests on the cluster instead of launching them
locally.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/bcb62f92/attachment.html>

From annulen at yandex.ru  Fri Jan 12 05:34:31 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 12 Jan 2018 13:34:31 +0300
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
In-Reply-To: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
Message-ID: <2703871515753271@web40o.yandex.ru>



12.01.2018, 12:58, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
> I am looking into the practicality of using clusters containing ~5
> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
> and test software (since even with ccache I am currently spending a
> lot of my time waiting for tests to complete as I develop my
> software). Such clusters would give you ~40 cores which is a lot of
> computer power for ~$500 or so. But, of course, the issue with
> clusters is how to use them efficiently?

1. For compilation you often need good single-core performance more
than parallelism, and I doubt that embedded-grade ARMv8 can provide it

I guess exception is compiling projects written in C which don't have huge
source files. Still, overhead of passing data between nodes may be
substanital.

2. You should probably use icecc or distcc, unless you have MPI as a
requirement.

>
> For one 8-core M3 you would expect
>
> make -j<NNN> target
>
> to scale linearly with NNN up to the saturation limit of roughly NNN=8
> (where target depends on ~hundreds of different and mostly independent
> tests). But my understanding from recent Google searching is that the
> -j option for GNU Make is not MPI-aware, i.e., only works for the
> cores for a single computer (node) in a cluster. So in a cluster you
> would have to assign the above task to just one node and simply accept
> that you cannot scale NNN up to the total number of cores in that
> cluster.
>
> I did find one reference to an effort (called the pmake project at
> Lawrence Livermore, see <https://computing.llnl.gov/code/pmake.html>)
> to modify GNU make to become MPI-aware so the above command would
> roughly scale NNN up to the number of cores in the cluster. But the
> single developer of the project seemed unable to overcome a bug in the
> result so that parallel make project was abandoned.
>
> I hope someone here can point me to a make variant (does Ninja
> qualify?) that does have the capability of scaling NNN up to the
> number of cores in the cluster since that would make clusters with a
> large number of cores become extremely useful for the purpose of quick
> testing by software developers.
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

-- 
Regards,
Konstantin

From irwin at beluga.phys.uvic.ca  Fri Jan 12 07:45:50 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 12 Jan 2018 04:45:50 -0800 (PST)
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
In-Reply-To: <CAPASGLqPG+eKLF-YPq+_pUe_kqymtn8SbXNctcycXNdwiP-vBg@mail.gmail.com>
References: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
 <CAPASGLqPG+eKLF-YPq+_pUe_kqymtn8SbXNctcycXNdwiP-vBg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1801120338010.18536@enira.zlyna.ubzr>

On 2018-01-12 11:14+0100 Eric Noulard wrote:

> 2018-01-12 10:58 GMT+01:00 Alan W. Irwin <irwin at beluga.phys.uvic.ca>:
>
>> I am looking into the practicality of using clusters containing ~5
>> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
>> and test software (since even with ccache I am currently spending a
>> lot of my time waiting for tests to complete as I develop my
>> software).  Such clusters would give you ~40 cores which is a lot of
>> computer power for ~$500 or so.  But, of course, the issue with
>> clusters is how to use them efficiently?
>>
>> For one 8-core M3 you would expect
>>
>> make -j<NNN> target
>>
>> to scale linearly with NNN up to the saturation limit of roughly NNN=8
>> (where target depends on ~hundreds of different and mostly independent
>> tests). But my understanding from recent Google searching is that the
>> -j option for GNU Make is not MPI-aware, i.e., only works for the
>> cores for a single computer (node) in a cluster.  So in a cluster you
>> would have to assign the above task to just one node and simply accept
>> that you cannot scale NNN up to the total number of cores in that
>> cluster.
>>
>
>>
> AFAIU what you want is "distributed ctest" not really distributed build
> right?

Not ctest, but actually distributed "build", but with "build" in
quotes because instead of exclusively building software, most of the
targets that are built are configured with
add_custom_command/add_custom_target and actually run tests with
proper dependencies on other test targets as well as targets that
actually build software.  So this testing paradigm makes initial
testing of one particular test much quicker because you don't have to
build the "all" target before the test like is required with ctest.

> For distributed build you may have a look at distcc (http://distcc.org/)
> which seems already used
> by CMake-enabled project like ccache is
> (
> https://stackoverflow.com/questions/32752446/using-compiler-prefix-commands-with-cmake-distcc-ccache/34317588
> )

It looks like distcc could speed up compilations tremendously on a
cluster, but only a minority of my targets are actually builds of
software.  So I need a "distmake".  Just after writing that sentence I
decided I liked that made-up name so on the off-chance someone else
had liked it as well, I did a google search and found the SF distmake project
that apparently does exactly what I need!  Instead of using MPI (Message
Passing Interface) standard to coordinate the targets that are built
between the various nodes, it looks like it uses something a lot
simpler.

> Now I'm not quite sure to understand why you speak of MPI-awareness ?

I thought to coordinate target builds over a cluster, that the make
programme itself would have to have MPI directives inserted into its source
code so the whole build coordination could be handled by MPI.  But it
appears that complexity is not necessary (see distmake, above).

> Are your test including MPI which would mean that some executable are
> already eating up more than one core?

No.

> Or do you have a big collection of mono-processor tests you want to run on
> the cluster?

Yes, but with complete dependencies as explained above.

In sum, it looks like this question now boils down to whether anyone
here has used distmake (or something equivalent to it) on a cluster,
and if so, are there any gotcha's?

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
__________________________

From irwin at beluga.phys.uvic.ca  Fri Jan 12 07:53:07 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 12 Jan 2018 04:53:07 -0800 (PST)
Subject: [CMake] Do any CMake back ends have support for parallel builds
 that efficiently use clusters?
In-Reply-To: <2703871515753271@web40o.yandex.ru>
References: <alpine.DEB.2.11.1801120109150.18536@enira.zlyna.ubzr>
 <2703871515753271@web40o.yandex.ru>
Message-ID: <alpine.DEB.2.11.1801120448290.18536@enira.zlyna.ubzr>

On 2018-01-12 13:34+0300 Konstantin Tokarev wrote:

>
>
> 12.01.2018, 12:58, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
>> I am looking into the practicality of using clusters containing ~5
>> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
>> and test software (since even with ccache I am currently spending a
>> lot of my time waiting for tests to complete as I develop my
>> software). Such clusters would give you ~40 cores which is a lot of
>> computer power for ~$500 or so. But, of course, the issue with
>> clusters is how to use them efficiently?
>
> 1. For compilation you often need good single-core performance more
> than parallelism, and I doubt that embedded-grade ARMv8 can provide it
>
> I guess exception is compiling projects written in C which don't have huge
> source files. Still, overhead of passing data between nodes may be
> substanital.
>
> 2. You should probably use icecc or distcc, unless you have MPI as a
> requirement.

Most of the work is run-time tests (configured with
add_custom_command/target) rather than compilations.  It have just
discovered that it looks like "distmake" or equivalent is what I need
(see the post I just wrote).

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
__________________________

From d3ck0r at gmail.com  Fri Jan 12 08:21:58 2018
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 12 Jan 2018 05:21:58 -0800
Subject: [CMake] Source file property INCLUDE_DIRECTORIES
Message-ID: <CAA2GJqUwqaKhj5LBFd-howwUraqdYQsjYWaEEVhkMjNvoUY5yw@mail.gmail.com>

Why can't I set INCLUDE_DIRECTORIES for a source file?

https://cmake.org/cmake/help/v3.0/manual/cmake-properties.7.html

I can probably use COMPILE_FLAGS ; but how to guarantee that -I is the
proper option for every compiler?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/c0c4f05d/attachment.html>

From marc.chevrier at sap.com  Fri Jan 12 08:26:10 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Fri, 12 Jan 2018 13:26:10 +0000
Subject: [CMake] Source file property INCLUDE_DIRECTORIES
In-Reply-To: <CAA2GJqUwqaKhj5LBFd-howwUraqdYQsjYWaEEVhkMjNvoUY5yw@mail.gmail.com>
References: <CAA2GJqUwqaKhj5LBFd-howwUraqdYQsjYWaEEVhkMjNvoUY5yw@mail.gmail.com>
Message-ID: <C2C26987-D02F-4FEF-A488-74F48FB4F66A@sap.com>

Because this property is not yet supported for source files (see #17507<https://gitlab.kitware.com/cmake/cmake/issues/17507>).
FYI, I worked on this support and the merge request is under process? (see !1596<https://gitlab.kitware.com/cmake/cmake/merge_requests/1596>).


From: CMake <cmake-bounces at cmake.org> on behalf of J Decker <d3ck0r at gmail.com>
Date: Friday 12 January 2018 at 14:22
To: CMake Mail List <cmake at cmake.org>
Subject: [CMake] Source file property INCLUDE_DIRECTORIES

Why can't I set INCLUDE_DIRECTORIES for a source file?

https://cmake.org/cmake/help/v3.0/manual/cmake-properties.7.html

I can probably use COMPILE_FLAGS ; but how to guarantee that -I is the proper option for every compiler?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/545286cc/attachment.html>

From d3ck0r at gmail.com  Fri Jan 12 09:02:57 2018
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 12 Jan 2018 06:02:57 -0800
Subject: [CMake] Source file property INCLUDE_DIRECTORIES
In-Reply-To: <C2C26987-D02F-4FEF-A488-74F48FB4F66A@sap.com>
References: <CAA2GJqUwqaKhj5LBFd-howwUraqdYQsjYWaEEVhkMjNvoUY5yw@mail.gmail.com>
 <C2C26987-D02F-4FEF-A488-74F48FB4F66A@sap.com>
Message-ID: <CAA2GJqXYNLBtwWVFosXUjcbW+eYJjr5utUDugfNos=bS-GmKMA@mail.gmail.com>

On Fri, Jan 12, 2018 at 5:26 AM, CHEVRIER, Marc <marc.chevrier at sap.com>
wrote:

> Because this property is not yet supported for source files (see #17507
> <https://gitlab.kitware.com/cmake/cmake/issues/17507>).
>
> FYI, I worked on this support and the merge request is under process? (see
> !1596 <https://gitlab.kitware.com/cmake/cmake/merge_requests/1596>).
>
>
>

Okay :) Glad someone is on it.

Will also work for set_property( SOURCE ... APPEND PROPERTY
INCLUDE_DIRECTORIES ) ?


>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of J Decker <
> d3ck0r at gmail.com>
> *Date: *Friday 12 January 2018 at 14:22
> *To: *CMake Mail List <cmake at cmake.org>
> *Subject: *[CMake] Source file property INCLUDE_DIRECTORIES
>
>
>
> Why can't I set INCLUDE_DIRECTORIES for a source file?
>
>
>
> https://cmake.org/cmake/help/v3.0/manual/cmake-properties.7.html
>
>
>
> I can probably use COMPILE_FLAGS ; but how to guarantee that -I is the
> proper option for every compiler?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/f3a9b86a/attachment.html>

From marc.chevrier at sap.com  Fri Jan 12 09:06:07 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Fri, 12 Jan 2018 14:06:07 +0000
Subject: [CMake] Source file property INCLUDE_DIRECTORIES
In-Reply-To: <CAA2GJqXYNLBtwWVFosXUjcbW+eYJjr5utUDugfNos=bS-GmKMA@mail.gmail.com>
References: <CAA2GJqUwqaKhj5LBFd-howwUraqdYQsjYWaEEVhkMjNvoUY5yw@mail.gmail.com>
 <C2C26987-D02F-4FEF-A488-74F48FB4F66A@sap.com>
 <CAA2GJqXYNLBtwWVFosXUjcbW+eYJjr5utUDugfNos=bS-GmKMA@mail.gmail.com>
Message-ID: <C825730E-D0F6-414E-A21F-42EB792C3E5B@sap.com>

Sure. APPEND keyword is handled at a high level (i.e. regardless the property evolved).

From: J Decker <d3ck0r at gmail.com>
Date: Friday 12 January 2018 at 15:03
To: "CHEVRIER, Marc" <marc.chevrier at sap.com>
Cc: CMake Mail List <cmake at cmake.org>
Subject: Re: [CMake] Source file property INCLUDE_DIRECTORIES



On Fri, Jan 12, 2018 at 5:26 AM, CHEVRIER, Marc <marc.chevrier at sap.com<mailto:marc.chevrier at sap.com>> wrote:
Because this property is not yet supported for source files (see #17507<https://gitlab.kitware.com/cmake/cmake/issues/17507>).
FYI, I worked on this support and the merge request is under process? (see !1596<https://gitlab.kitware.com/cmake/cmake/merge_requests/1596>).


Okay :) Glad someone is on it.

Will also work for set_property( SOURCE ... APPEND PROPERTY INCLUDE_DIRECTORIES ) ?


From: CMake <cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>> on behalf of J Decker <d3ck0r at gmail.com<mailto:d3ck0r at gmail.com>>
Date: Friday 12 January 2018 at 14:22
To: CMake Mail List <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: [CMake] Source file property INCLUDE_DIRECTORIES

Why can't I set INCLUDE_DIRECTORIES for a source file?

https://cmake.org/cmake/help/v3.0/manual/cmake-properties.7.html

I can probably use COMPILE_FLAGS ; but how to guarantee that -I is the proper option for every compiler?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/f48185e6/attachment-0001.html>

From saadrustam at gmail.com  Fri Jan 12 18:12:08 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Fri, 12 Jan 2018 23:12:08 +0000
Subject: [CMake] Get find_package to choose INSTALLed libraries instead
 of libraries in the build folder
In-Reply-To: <9EB4C155-F415-4EA4-B5B1-35FD8BA81796@sap.com>
References: <CAEM70sNiL_kRDPCOx6z5_Uwm3Wqd+kekNBdd6Ve7_XDNEpbWzQ@mail.gmail.com>
 <9EB4C155-F415-4EA4-B5B1-35FD8BA81796@sap.com>
Message-ID: <CAEM70sPFntTmQTODzadX86aHwvYBMuwctiysOSb24ZAADq6F1Q@mail.gmail.com>

Thank you Marc.

That's interesting, I was not aware that they were relinked. I thought they
were just copied.

I guess I'll have to provide the install directory to pick the libraries
found in the install directory instead of the build directory?

Regards,
Saad

On Fri, Jan 12, 2018 at 2:57 AM CHEVRIER, Marc <marc.chevrier at sap.com>
wrote:

> Hi,
>
>
>
> During install step, installed libraries and executables are relinked to
> generate binaries without absolute paths so installed artifacts are
> independent from your build tree.
>
>
>
> During build step, build binaries are used as well as absolute paths so
> produced binaries can be used during build step (i.e. launching an
> executable produced) without requirements regarding paths settings (i.e.
> PATH or LD_LIBRARY_PATH).
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Saad Khattak <
> saadrustam at gmail.com>
> *Date: *Thursday 11 January 2018 at 19:44
> *To: *Cmake Mailing List <cmake at cmake.org>
> *Subject: *[CMake] Get find_package to choose INSTALLed libraries instead
> of libraries in the build folder
>
>
>
> Hi,
>
>
>
> I would like find_package(MyLib) to link find the libraries found in the
> INSTALL folder instead of the build folder.
>
>
>
> Currently, when I do a find_package(MyLib) and then
> target_link_libraries(target MyLib) the paths all point to MyLib's build
> folder and not the folder where MyLib's library/headers were installed.
>
>
>
> Thank you,
>
> Saad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180112/66d4ea96/attachment.html>

From saadrustam at gmail.com  Fri Jan 12 22:24:27 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Sat, 13 Jan 2018 03:24:27 +0000
Subject: [CMake] Querying CMake variables of external CMake projects
Message-ID: <CAEM70sPoyViaSaZijj2owV-QLnfGUMsbC9=w595-tz2miChwuQ@mail.gmail.com>

Hi,

Say I find LibA using find_package(LibA) and I now have access to LibA_DIR,
which is the build folder of LibA. Is there a way I can query additional
variables, such as LibA's source directory, install directory etc. i.e.
variables that are defined by CMake when LibA was being generated/built by
CMake?

Thanks,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180113/0d4a84f9/attachment.html>

From saadrustam at gmail.com  Fri Jan 12 22:41:00 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Sat, 13 Jan 2018 03:41:00 +0000
Subject: [CMake] Making sure dependent projects are up-to-date
Message-ID: <CAEM70sOHxyZhzVte=+wcUQvRm9tdEhOmjurOF7mpMOHi2K3ytA@mail.gmail.com>

Hi,

Let's say I have several CMake enabled libraries that have their own
respective build directories and have been installed:

LibA
LibB (depends on A)
LibC
LibD (depends on LibC and LibA)

I then create a new executable project ProjExe that depends on LibD. Now, I
am working on LibA, LibB, LibC, LibD and ProjExe simultaneously (e.g.
building up functionality in the libraries that the executable uses, fixing
bugs etc.).

What I would like, is a way to ensure that when ProjExe is built, it first
checks whether LibD is up-to-date (i.e. does it have any out of source
build files?), if not, it builds LibD first. But LibD depends on LibC and
LibA, and then LibD ensures that LibC and LibA are up-to-date before
building itself.

Is something like this possible in CMake? This is  similar to the
'solution' concept in Visual C++ where a 'solution' can have several
projects. ProjExe in the solution can be dependent on external libraries
(like the above) and they are part of the 'solution' and are checked to be
up-to-date before ProjExe is compiled/linked.

Thanks,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180113/60cb2998/attachment.html>

From d3ck0r at gmail.com  Sat Jan 13 10:28:17 2018
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 13 Jan 2018 07:28:17 -0800
Subject: [CMake] Making sure dependent projects are up-to-date
In-Reply-To: <CAEM70sOHxyZhzVte=+wcUQvRm9tdEhOmjurOF7mpMOHi2K3ytA@mail.gmail.com>
References: <CAEM70sOHxyZhzVte=+wcUQvRm9tdEhOmjurOF7mpMOHi2K3ytA@mail.gmail.com>
Message-ID: <CAA2GJqX30TG4C-9PvB4y0HhdT+t2oegPqbUwcoL=VnXcOntV8g@mail.gmail.com>

maybehttps://cmake.org/cmake/help/v3.2/module/ExternalProject.html

BUILD_ALWAYS 1No stamp file, build step always runs

On Fri, Jan 12, 2018 at 7:41 PM, Saad Khattak <saadrustam at gmail.com> wrote:

> Hi,
>
> Let's say I have several CMake enabled libraries that have their own
> respective build directories and have been installed:
>
> LibA
> LibB (depends on A)
> LibC
> LibD (depends on LibC and LibA)
>
> I then create a new executable project ProjExe that depends on LibD. Now,
> I am working on LibA, LibB, LibC, LibD and ProjExe simultaneously (e.g.
> building up functionality in the libraries that the executable uses, fixing
> bugs etc.).
>
> What I would like, is a way to ensure that when ProjExe is built, it first
> checks whether LibD is up-to-date (i.e. does it have any out of source
> build files?), if not, it builds LibD first. But LibD depends on LibC and
> LibA, and then LibD ensures that LibC and LibA are up-to-date before
> building itself.
>
> Is something like this possible in CMake? This is  similar to the
> 'solution' concept in Visual C++ where a 'solution' can have several
> projects. ProjExe in the solution can be dependent on external libraries
> (like the above) and they are part of the 'solution' and are checked to be
> up-to-date before ProjExe is compiled/linked.
>
> Thanks,
> Saad
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180113/3d875c7c/attachment.html>

From annulen at yandex.ru  Sat Jan 13 12:06:25 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sat, 13 Jan 2018 20:06:25 +0300
Subject: [CMake] Querying CMake variables of external CMake projects
In-Reply-To: <CAEM70sPoyViaSaZijj2owV-QLnfGUMsbC9=w595-tz2miChwuQ@mail.gmail.com>
References: <CAEM70sPoyViaSaZijj2owV-QLnfGUMsbC9=w595-tz2miChwuQ@mail.gmail.com>
Message-ID: <6372481515863185@web5o.yandex.ru>



13.01.2018, 06:26, "Saad Khattak" <saadrustam at gmail.com>:
> Hi,
>
> Say I find LibA using find_package(LibA) and I now have access to LibA_DIR, which is the build folder of LibA. Is there a way I can query additional variables, such as LibA's source directory, install directory etc. i.e. variables that are defined by CMake when LibA was being generated/built by CMake?

If  find_package(LibA) provides you target "LibA" (i.e., cmake code under "if (TARGET LibA)"
condition is being executed), you can query various properties from it and expect them to
have sane values. See documentation on cmake properties.

If there is no LibA target, it probably means that find_package(LibA) is implemented via
FindLibA.cmake module, and you can only use variables that it sets (usually documented in
the beginning of module)

>
> Thanks,
> Saad
> ,--
>
> 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

From saadrustam at gmail.com  Sat Jan 13 17:20:34 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Sat, 13 Jan 2018 22:20:34 +0000
Subject: [CMake] Making sure dependent projects are up-to-date
In-Reply-To: <CAA2GJqX30TG4C-9PvB4y0HhdT+t2oegPqbUwcoL=VnXcOntV8g@mail.gmail.com>
References: <CAEM70sOHxyZhzVte=+wcUQvRm9tdEhOmjurOF7mpMOHi2K3ytA@mail.gmail.com>
 <CAA2GJqX30TG4C-9PvB4y0HhdT+t2oegPqbUwcoL=VnXcOntV8g@mail.gmail.com>
Message-ID: <CAEM70sNutpkgSyY=H6yAS6sj0GmrDQsku8mScT0wZeGkSZ3Wmg@mail.gmail.com>

Thanks J.

That requires me to use ExternalProject_Add. However, in my case, I have
all Libraries generated/built independently. Should I just start using
ExternalProject_Add for dependencies? If yes, what is the best way to do
that in conjunction with 'find_package(...)'?

On Sat, Jan 13, 2018 at 10:28 AM J Decker <d3ck0r at gmail.com> wrote:

> maybehttps://cmake.org/cmake/help/v3.2/module/ExternalProject.html
>
> BUILD_ALWAYS 1No stamp file, build step always runs
>
> On Fri, Jan 12, 2018 at 7:41 PM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
>> Hi,
>>
>> Let's say I have several CMake enabled libraries that have their own
>> respective build directories and have been installed:
>>
>> LibA
>> LibB (depends on A)
>> LibC
>> LibD (depends on LibC and LibA)
>>
>> I then create a new executable project ProjExe that depends on LibD. Now,
>> I am working on LibA, LibB, LibC, LibD and ProjExe simultaneously (e.g.
>> building up functionality in the libraries that the executable uses, fixing
>> bugs etc.).
>>
>> What I would like, is a way to ensure that when ProjExe is built, it
>> first checks whether LibD is up-to-date (i.e. does it have any out of
>> source build files?), if not, it builds LibD first. But LibD depends on
>> LibC and LibA, and then LibD ensures that LibC and LibA are up-to-date
>> before building itself.
>>
>> Is something like this possible in CMake? This is  similar to the
>> 'solution' concept in Visual C++ where a 'solution' can have several
>> projects. ProjExe in the solution can be dependent on external libraries
>> (like the above) and they are part of the 'solution' and are checked to be
>> up-to-date before ProjExe is compiled/linked.
>>
>> Thanks,
>> Saad
>>
>> --
>>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180113/7fffee22/attachment.html>

From saadrustam at gmail.com  Sat Jan 13 17:34:18 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Sat, 13 Jan 2018 22:34:18 +0000
Subject: [CMake] Querying CMake variables of external CMake projects
In-Reply-To: <6372481515863185@web5o.yandex.ru>
References: <CAEM70sPoyViaSaZijj2owV-QLnfGUMsbC9=w595-tz2miChwuQ@mail.gmail.com>
 <6372481515863185@web5o.yandex.ru>
Message-ID: <CAEM70sMrTy=j8uJrkZpu=vydQX3JYLkdzpV=i72xMcHEuHZByw@mail.gmail.com>

Thank you Konstantin. get_target_properties(...) works very well.

On Sat, Jan 13, 2018 at 12:06 PM Konstantin Tokarev <annulen at yandex.ru>
wrote:

>
>
> 13.01.2018, 06:26, "Saad Khattak" <saadrustam at gmail.com>:
> > Hi,
> >
> > Say I find LibA using find_package(LibA) and I now have access to
> LibA_DIR, which is the build folder of LibA. Is there a way I can query
> additional variables, such as LibA's source directory, install directory
> etc. i.e. variables that are defined by CMake when LibA was being
> generated/built by CMake?
>
> If  find_package(LibA) provides you target "LibA" (i.e., cmake code under
> "if (TARGET LibA)"
> condition is being executed), you can query various properties from it and
> expect them to
> have sane values. See documentation on cmake properties.
>
> If there is no LibA target, it probably means that find_package(LibA) is
> implemented via
> FindLibA.cmake module, and you can only use variables that it sets
> (usually documented in
> the beginning of module)
>
> >
> > Thanks,
> > Saad
> > ,--
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180113/e657c77a/attachment.html>

From paul at mad-scientist.net  Sat Jan 13 18:15:37 2018
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 13 Jan 2018 18:15:37 -0500
Subject: [CMake] Building cmake: why is openssl linked?
Message-ID: <1515885337.3068.55.camel@mad-scientist.net>

Hi all.

I build CMake myself.  I've noticed that on GNU/Linux by default cmake
will be linked with openssl and require these shared libraries to be
available at runtime.

Why does cmake link with these libraries?  I can't think of a reason it
might need them.  What do I lose in functionality if I force
CMAKE_USE_OPENSSL to OFF during the build?

From jeanmichael.celerier at gmail.com  Sat Jan 13 19:08:36 2018
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Sun, 14 Jan 2018 01:08:36 +0100
Subject: [CMake] Building cmake: why is openssl linked?
In-Reply-To: <1515885337.3068.55.camel@mad-scientist.net>
References: <1515885337.3068.55.camel@mad-scientist.net>
Message-ID: <CAE1uMrUis3tYMAujoSOyOarLnuvQrsFotfVvWE1DMnqwpLKLrg@mail.gmail.com>

https://cmake.org/cmake/help/latest/module/ExternalProject.html

since CMake can download stuff, it needs to support https, hence SSL, hence
OpenSSL

Best,

-------
Jean-Micha?l Celerier
http://www.jcelerier.name

On Sun, Jan 14, 2018 at 12:15 AM, Paul Smith <paul at mad-scientist.net> wrote:

> Hi all.
>
> I build CMake myself.  I've noticed that on GNU/Linux by default cmake
> will be linked with openssl and require these shared libraries to be
> available at runtime.
>
> Why does cmake link with these libraries?  I can't think of a reason it
> might need them.  What do I lose in functionality if I force
> CMAKE_USE_OPENSSL to OFF during the build?
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180114/cc0fd5b6/attachment-0001.html>

From craig.scott at crascit.com  Sun Jan 14 16:29:14 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 15 Jan 2018 08:29:14 +1100
Subject: [CMake] Creating a relocatable ProjectConfig.cmake when build
 uses absolute paths
In-Reply-To: <56F15E8F-9B20-4DAB-B74C-06910F8BD44F@orange.fr>
References: <EDC117A0-A274-45C4-8EFF-24346B74EFF9@orange.fr>
 <CA+dygYn+qbHvZrdLpW2_-ynt23VAd3bL_zUXak0SM9hg96wjOg@mail.gmail.com>
 <56F15E8F-9B20-4DAB-B74C-06910F8BD44F@orange.fr>
Message-ID: <CA+dygYmEMiGzBk7pvnVWxNruwW9V01nPvCc+9T+d6eS9=XL7fg@mail.gmail.com>

(Includes earlier reply from me not sent to the list)


On Fri, Jan 12, 2018 at 9:10 AM, Lucas Soltic <lucas.soltic at orange.fr>
wrote:
>
> On Thu, Jan 11, 2018 at 10:09 AM, Lucas Soltic <lucas.soltic at orange.fr>
> wrote:
>
>> Hello,
>>
>> I'm trying to create a relocatable package configuration file but I'm
>> having a hard time with absolute paths that are used during the build.
>> Note that I use CMake 3.10.0.
>>
>> First of all for the include path I'm using this:
>> target_include_directories(MyStaticTarget PUBLIC
>>                            $<BUILD_INTERFACE:${PROJECT_S
>> OURCE_DIR}/include>
>>                            $<INSTALL_INTERFACE:include>)
>>
>> This does work but according to the doc it should not :
>> https://cmake.org/cmake/help/latest/manual/cmake-generator
>> -expressions.7.html?highlight=build_interface#output-expressions
>> The doc of BUILD_INTERFACE says: "Content of ... when the property is
>> exported using export(), or when the target is *used by another target
>> in the same buildsystem*. Expands to the empty string otherwise."
>>
>
> I'm with you to here.
>
>
>> So according to the doc, when compiling the target MyTarget, the include
>> dir I gave should not be used. Which seems consistent with the other uses
>> of INTERFACE wording in CMake language. But it actually behaves like PUBLIC
>> rather than INTERFACE. This is fine to me but inconsistent? :)
>>
>
> This part is less clear. What is MyTarget? Is it something you link to
> MyStaticTarget? If so, then the include dir *should* be used. In the
> target_include_directories() call above, the content of the generator
> expressions will both be treated as PUBLIC if they expand to something
> non-empty. Don't be confused by the word INTERFACE in the generator
> expressions, it is the PUBLIC before them that is controlling the
> visibility/transitivity of these include paths. Think of BUILD_INTERFACE as
> meaning "only when I'm building with this thing" and INSTALL_INTERFACE as
> "only when this thing is installed (i.e. put this in an export file but
> don't use it in the build I created it in)".
>
>
> Arg I messed up my original e-mail. "MyTarget" is the same as
> "MyStaticTarget". I just didn't rename everywhere?
> I rather have a clear vision about what INTERFACE, PUBLIC and PRIVATE
> keywords mean when used in target_...() commands so I understand that my
> paths will be used both by MyStaticTarget and targets that depend on it.
> It's just that BUILD_INTERFACE's documentation is misleading. Apart from
> that I deduced the same as what you said :)
>
>
> The second point is about libraries to link when using my project. My
>> project exports a *static* library that depends on other libraries.
>> These libraries are found (when generating my project through cmake)
>> through calls like find_package(OpenGL). This provides a variable that
>> contains an absolute non-relocatable path.
>>
>> I've tried doing things like this:
>> target_link_libraries(MyStaticTarget PRIVATE
>>                       $<BUILD_INTERFACE:${OpenGL_absolute_path}>
>>                       $<INSTALL_INTERFACE:${OpenGL_r
>> elocatable_link_flag}>)
>>
>> According to https://cmake.org/pipermail/cmake/2016-May/063400.html, for
>> static libraries, PRIVATE link dependencies become "PUBLIC", which is ok.
>>
>
> They only sort-of become PUBLIC. Only the linking part gets promoted to
> PUBLIC, not things like include paths, compiler defines or compiler options.
>
>
> Indeed. So far so good :)
>
>
>
>
>> And I could see that the link flag for this "private" dependency got
>> exported in the generated config.
>>
>
>
> Short version: I *think* if you use the import libraries that the
> FindOpenGL module provides rather than the variables, you will have more
> success.
>
>
> Long version (this is going to get quite involved, sorry): If your static
> library relies on an external library and you want that external dependency
> to be part of the exported definition of your target, then you'll have to
> do some extra work in how you provide your installed package. If you are
> using install(EXPORT) to produce files that other projects pick up via
> find_package(), then you probably want to be using find_dependency() from
> the CMakeFindDependencyMacro
> <https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html>
> module from inside your package's XXXConfig.cmake file. This will define
> the imported targets that your package's import target should, I believe,
> be expecting to exist and rely on as an interface dependency. Sketching it
> out, it might look something like this (untested, tired brain, so no
> guarantees!):
>
> # Contents of XXXConfig.cmake:
>
> include(CMakeFindDependencyMacro)
> find_dependency(OpenGL)   # Makes sure the OpenGL::GL import target exists
> include(XXXexports)       # The file you are probably already creating now
> for your package
>
> I think the exported target will already have OpenGL::GL in the list of
> interface libraries for the MyStaticTarget import target created by
> XXXexports in the above, but if not it should be easy enough to add that to
> the end of the XXXConfig.cmake sample code (maybe a call to
> target_link_libraries() or set_property(TARGET MyStaticTarget...)).
>
> Back in your original project, the target_link_libraries() call should be
> simplified down to:
>
>
> find_package(OpenGL REQUIRED)
>
> target_link_libraries(MyStaticTarget PRIVATE OpenGL::GL)
>
>
> The MyStaticTarget will then have a link dependency on OpenGL::GL in both
> the build tree and when installed. It's very likely I've made errors in the
> above, but hopefully there's enough there for you to find your way to a
> solution.
>
>
> I like this solution, but I can't use it as is. For 2 reasons: OpenGL was
> one example, but I also have other dependencies that don't provide an
> imported target, and the second reason is that this imported target for
> OpenGL is only available since CMake 3.8 and I must support at least up to
> 3.5.
>
> Also I said "as is" because this makes me think that I could potentially
> define, in my project, an IMPORTED or INTERFACE library for OpenGL that
> would be used in a target_link_libraries() in my project. And in
> <Project>Config.cmake it would allow me to make use of the
> find_dependency() you suggested to create again this target.
>

Indeed. At the point where you call find_package(OpenGL), you could then
test for the existence of the OpenGL::GL library and if it doesn't exist,
you can define it yourself. This should allow you to use the import library
with CMake versions earlier than the one where the OpenGL import library
support was added.




>
> The only downside I can see with this is that the <Project>Config.cmake
> file will need to be kept synchronized with the dependencies that are used
> in various places in my project, instead of having this done automatically
> (and thus always synchronized).
>

Pretty much. I think there have been some discussions in the issue tracker
and/or merge requests over the past year related to how to propagate
dependencies similar to this topic. It's a difficult area with no easy
solution unfortunately.




> But the problem is that whatever I put for INSTALL_INTERFACE, it is
>> ignored and not written to the generated cmake config file. The generated
>> CMake config file just takes into account what I put for BUILD_INTERFACE.
>> Contrary to what happened with include directories.
>>
>
> This sounds strange. Can you provide a simple, complete project that
> reproduces the problem? If so, please open an issue in the bug tracker and
> attach it.
>
>
> I reproduced it with a minimal example, and found out what is causing the
> issue.
> At the beginning of the project, if I put cmake_minimum_required(VERSION
> 2.8.3) (which is what the project I'm working in currently uses) then in
> the generated config, only what's specified in BUILD_INTERFACE generator
> expression is taken into account.
>
> If I change the requirement to version 3.0, the generated config file
> contains what I specified for INSTALL_INTERFACE generator expression.
> I never realized that this command had an effect on CMake policies. At
> least now everything makes sense :)
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180115/cea29e50/attachment.html>

From laasunde at hotmail.com  Mon Jan 15 05:37:31 2018
From: laasunde at hotmail.com (Lars)
Date: Mon, 15 Jan 2018 10:37:31 +0000
Subject: [CMake] CMAke install files using cmake-generator-expression
Message-ID: <HE1PR03MB1338634370247935DB95F6B1CAEB0@HE1PR03MB1338.eurprd03.prod.outlook.com>

Hello,


Using CMake 3.8.1 on Windows 7 SP1.


The following cmake expression will produce an error.

INSTALL(

  FILES

    $<$<CXX_COMPILER_ID:MSVC>${COMP_PATH}/win32/bin/comp.dll>

  DESTINATION "${install_dir}")


"CMake error: Error evaluating generator expression: $<CXX_COMPILER_ID:MSVC>.

$<CXX_COMPILER_ID> may only be used with binary targets. It may not be used with add_custom_command

or add_custom_target."


Tried using "GNU" instead of "MSVC" but did not help.

Tried using "PROGRAMS" instead of "FILES" but did not help.

Replacing $<CXX_COMPILER_ID:MSVC> with $<BOOL:1> works, so it appears cmake-generator-expression work just not using compiler as key.


What does binary target mean in this context?


Why does this fail?


Kind regards,

Lars
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180115/6b4b2221/attachment-0001.html>

From christoph at ruediger.engineering  Mon Jan 15 06:19:37 2018
From: christoph at ruediger.engineering (christoph at ruediger.engineering)
Date: Mon, 15 Jan 2018 11:19:37 +0000
Subject: [CMake] Dual use for single source file
Message-ID: <5D5D5B1D-8161-4366-842F-175B382D53EF@contoso.com>

Hi folks,

we?re using a clang-based tool for co-processing a bunch of our source files. The benefit is, that it understands the compile_commands.json database and hence we do not need to pull out the include paths and the compile definitions by hand. However, CMake does not compile the source file any longer when used as input to a custom command.

Here is the simplest project I could come up with to demonstrate the behavior:

--- snip ---
# CMakeLists.txt
cmake_minimum_required(VERSION 3.1)
project(hello-world)

add_executable(hello main.cxx hello.cxx)

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/reflections.h
  COMMAND echo "// This is a tool which creates type reflections" >reflections.h
  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/hello.cxx
  COMMENT "Generating reflections"
)
--- snip ---

--- snip ---
// main.cxx
void print_hello();

int main() {
  print_hello();
  return 0;
}
--- snip ---

--- snip ---
// hello.cxx
#include <iostream>

void print_hello() {
  std::cout << "Hello world!\n";
}
--- snip ---

What happens is, that CMake does not compile hello.cxx any longer. It only executes the custom command. Consequently, the compile_commands.json database does not contain any information about hello.cxx. Tested on cmake 3.9.1 and 3.10.1.

The reason for this behavior seems to be, that there can be only one kind for each given source file. In cmGeneratorTarget::ComputeKindedSources, there is an explicit check for not adding a source file multiple times to the KindedSources vector. And when checking which kind a source file is of, the first check is for custom commands. CMake says ?Bingo, this is a custom command? and does not check whether it can be of any other kind as well.

Is this a keep-it-simple implementation or is there any deeper knowledge behind this behavior?

And more important: how can I force CMake to compile a source file and process it by a custom command?

Thanks for your help,
Christoph

--
r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180115/9643ce72/attachment.html>

From post at hendrik-sattler.de  Mon Jan 15 08:47:59 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Mon, 15 Jan 2018 14:47:59 +0100
Subject: [CMake] Dual use for single source file
In-Reply-To: <5D5D5B1D-8161-4366-842F-175B382D53EF@contoso.com>
References: <5D5D5B1D-8161-4366-842F-175B382D53EF@contoso.com>
Message-ID: <B51673EA-58E7-4AC7-82BF-2DB02A14E153@hendrik-sattler.de>

Hi,

I also fell into this trap before:
Don't use MAIN_DEPENDENCY but DEPENDS.

HS


Am 15. Januar 2018 12:19:37 MEZ schrieb "christoph at ruediger.engineering" <christoph at ruediger.engineering>:
>Hi folks,
>
>we?re using a clang-based tool for co-processing a bunch of our source
>files. The benefit is, that it understands the compile_commands.json
>database and hence we do not need to pull out the include paths and the
>compile definitions by hand. However, CMake does not compile the source
>file any longer when used as input to a custom command.
>
>Here is the simplest project I could come up with to demonstrate the
>behavior:
>
>--- snip ---
># CMakeLists.txt
>cmake_minimum_required(VERSION 3.1)
>project(hello-world)
>
>add_executable(hello main.cxx hello.cxx)
>
>add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/reflections.h
>COMMAND echo "// This is a tool which creates type reflections"
>>reflections.h
>  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/hello.cxx
>  COMMENT "Generating reflections"
>)
>--- snip ---
>
>--- snip ---
>// main.cxx
>void print_hello();
>
>int main() {
>  print_hello();
>  return 0;
>}
>--- snip ---
>
>--- snip ---
>// hello.cxx
>#include <iostream>
>
>void print_hello() {
>  std::cout << "Hello world!\n";
>}
>--- snip ---
>
>What happens is, that CMake does not compile hello.cxx any longer. It
>only executes the custom command. Consequently, the
>compile_commands.json database does not contain any information about
>hello.cxx. Tested on cmake 3.9.1 and 3.10.1.
>
>The reason for this behavior seems to be, that there can be only one
>kind for each given source file. In
>cmGeneratorTarget::ComputeKindedSources, there is an explicit check for
>not adding a source file multiple times to the KindedSources vector.
>And when checking which kind a source file is of, the first check is
>for custom commands. CMake says ?Bingo, this is a custom command? and
>does not check whether it can be of any other kind as well.
>
>Is this a keep-it-simple implementation or is there any deeper
>knowledge behind this behavior?
>
>And more important: how can I force CMake to compile a source file and
>process it by a custom command?
>
>Thanks for your help,
>Christoph
>
>--
>r?diger.engineering
>Christoph R?diger
>D?sseldorfer Str. 12
>45145 Essen
>Germany
>
>phone: +49 201 458 478 58

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From jsvanbethlehem at gmail.com  Tue Jan 16 05:39:14 2018
From: jsvanbethlehem at gmail.com (Jakob van Bethlehem)
Date: Tue, 16 Jan 2018 11:39:14 +0100
Subject: [CMake] Using CMake to compile non-standard languages
Message-ID: <CAL1KmUDkn5QypjS1uzvLF10HbuBy4AH_PeQUBM=MP_fzPs047A@mail.gmail.com>

Dear all,

Currently I'm trying to make a case to convert the pure makefile-based
build environment at my company into cmake. This is a rather extensive
build environment, which takes care of many things automatically through a
whole set of internally created tools. I still believe we can do better
with CMake, but I need to make a strong case.

The main problem is that we have (very old) code in an obsure languange
called 'Ratfor'. How can I tell CMake how to compile files written in that
language?

Sincerely,
Jakob van Bethlehem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180116/8d4b9f1d/attachment.html>

From annulen at yandex.ru  Tue Jan 16 05:50:25 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 16 Jan 2018 13:50:25 +0300
Subject: [CMake] Using CMake to compile non-standard languages
In-Reply-To: <CAL1KmUDkn5QypjS1uzvLF10HbuBy4AH_PeQUBM=MP_fzPs047A@mail.gmail.com>
References: <CAL1KmUDkn5QypjS1uzvLF10HbuBy4AH_PeQUBM=MP_fzPs047A@mail.gmail.com>
Message-ID: <1377021516099825@web33j.yandex.ru>



16.01.2018, 13:39, "Jakob van Bethlehem" <jsvanbethlehem at gmail.com>:
> Dear all,
>
> Currently I'm trying to make a case to convert the pure makefile-based build environment at my company into cmake. This is a rather extensive build environment, which takes care of many things automatically through a whole set of internally created tools. I still believe we can do better with CMake, but I need to make a strong case.
>
> The main problem is that we have (very old) code in an obsure languange called 'Ratfor'. How can I tell CMake how to compile files written in that language?

1. Create variable with list of source files
2. Iterate through it in cycle and use add_custom_command for each file, defining compilation rule

Note that unlike Make, CMake doesn't have any counterpart of suffix or template user-defined rules, so you have to use cycles.

>
> Sincerely,
> Jakob van Bethlehem
>
> ,--
>
> 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

From christoph at ruediger.engineering  Tue Jan 16 09:15:35 2018
From: christoph at ruediger.engineering (christoph at ruediger.engineering)
Date: Tue, 16 Jan 2018 14:15:35 +0000
Subject: [CMake] Dual use for single source file
In-Reply-To: <B51673EA-58E7-4AC7-82BF-2DB02A14E153@hendrik-sattler.de>
References: <5D5D5B1D-8161-4366-842F-175B382D53EF@contoso.com>
 <B51673EA-58E7-4AC7-82BF-2DB02A14E153@hendrik-sattler.de>
Message-ID: <DCCC4F5D-9D48-486E-B122-2ED3891E6249@ruediger.engineering>

Hi,

this solved the issue here as well.

I added a pull request for a documentation update according to the MAIN_DEPENDENCY: https://gitlab.kitware.com/cmake/cmake/merge_requests/1665

Regards
Christoph

r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58

Von: Hendrik Sattler <post at hendrik-sattler.de>
Datum: Montag, 15. Januar 2018 um 14:47
An: "cmake at cmake.org" <cmake at cmake.org>, "christoph at ruediger.engineering" <christoph at ruediger.engineering>, "cmake at cmake.org" <cmake at cmake.org>
Betreff: Re: [CMake] Dual use for single source file

Hi,

I also fell into this trap before:
Don't use MAIN_DEPENDENCY but DEPENDS.

HS


Am 15. Januar 2018 12:19:37 MEZ schrieb "christoph at ruediger.engineering<mailto:christoph at ruediger.engineering>" <christoph at ruediger.engineering<mailto:christoph at ruediger.engineering>>:
Hi folks,

we?re using a clang-based tool for co-processing a bunch of our source
files. The benefit is, that it understands the compile_commands.json
database and hence we do not need to pull out the include paths and the
compile definitions by hand. However, CMake does not compile the source
file any longer when used as input to a custom command.

Here is the simplest project I could come up with to demonstrate the
behavior:

--- snip ---
# CMakeLists.txt
cmake_minimum_required(VERSION 3.1)
project(hello-world)

add_executable(hello main.cxx hello.cxx)

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/reflections.h
COMMAND echo "// This is a tool which creates type reflections"
reflections.h
  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/hello.cxx
  COMMENT "Generating reflections"
)
--- snip ---

--- snip ---
// main.cxx
void print_hello();

int main() {
  print_hello();
  return 0;
}
--- snip ---

--- snip ---
// hello.cxx
#include <iostream>

void print_hello() {
  std::cout << "Hello world!\n";
}
--- snip ---

What happens is, that CMake does not compile hello.cxx any longer. It
only executes the custom command. Consequently, the
compile_commands.json database does not contain any information about
hello.cxx. Tested on cmake 3.9.1 and 3.10.1.

The reason for this behavior seems to be, that there can be only one
kind for each given source file. In
cmGeneratorTarget::ComputeKindedSources, there is an explicit check for
not adding a source file multiple times to the KindedSources vector.
And when checking which kind a source file is of, the first check is
for custom commands. CMake says ?Bingo, this is a custom command? and
does not check whether it can be of any other kind as well.

Is this a keep-it-simple implementation or is there any deeper
knowledge behind this behavior?

And more important: how can I force CMake to compile a source file and
process it by a custom command?

Thanks for your help,
Christoph

--
r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180116/3c2f5501/attachment-0001.html>

From mohammedrashadkm at gmail.com  Wed Jan 17 11:38:01 2018
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Wed, 17 Jan 2018 17:38:01 +0100
Subject: [CMake] Ubuntu package versioning
In-Reply-To: <CAH8UK3Wtp8UyA34w-Fa1hUkGYcQa5KaNRxroiBnLZFvqDYhCDQ@mail.gmail.com>
References: <CAN3N+znfO5vv=g+HboHUVZU9FgP-o5eck_ibWudJ7T3MaxTNug@mail.gmail.com>
 <alpine.DEB.2.11.1712181907020.18536@enira.zlyna.ubzr>
 <CAH8UK3Wtp8UyA34w-Fa1hUkGYcQa5KaNRxroiBnLZFvqDYhCDQ@mail.gmail.com>
Message-ID: <CANNqv9f1bQYJheQzMpm7gLiFASHn4qdoB2aKEaKjxsz3JvMCKw@mail.gmail.com>

On Tue, Dec 19, 2017 at 4:45 AM, Raymond Wan <rwan.work at gmail.com> wrote:

> Hi Alexander,
>
> On Tue, Dec 19, 2017 at 11:39 AM, Alan W. Irwin
> <irwin at beluga.phys.uvic.ca> wrote:
> > On 2017-12-18 19:14-0500 <Alexander G. Riccio> wrote:
> >
> >> I'm not sure who maintains the Ubuntu cmake package, but I *just*
> >> installed
> >> it, and cmake --version reported 3.5.1... a little bit out of date.
> >
> >
> > If you look at
> > <https://packages.ubuntu.com/search?keywords=cmake&
> searchon=names&suite=all&section=all>
> > the various Ubuntu distribution versions called xenial, zesty, artful,
> and
> > bionic provide respectively CMake versions 3.5.1, 3.7.2, 3.9.1, and
> > 3.9.5.  And similar situations occur for all other Linux distros.
> >
> > So if you upgrade to a later Ubuntu version you will automatically get
> > access to a later CMake version. But such upgrades are non-trivial so a
> > compromise that allows you to delay doing such an upgrade for a while
> > would be to build and use a newer version of CMake yourself.
>
>
> In addition to what Alan said, another alternative to compiling it
> yourself is to install Anaconda into your home directory and then to
> install cmake from that.  For example, you can see here what is
> available to you:  https://anaconda.org/search?q=cmake


This seems too much to me. Seriously, Anaconda for binary package of cmake ?
I have been using cmake's own binary packages for a long time. Never had
once an issue with them?
You get them for those three OSes(Linux, macx, windows)


>
> Ray
> --
>
> 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,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/041fc5f3/attachment.html>

From jdamon at accesio.com  Wed Jan 17 13:05:24 2018
From: jdamon at accesio.com (Jimi Damon)
Date: Wed, 17 Jan 2018 10:05:24 -0800
Subject: [CMake] How can I create a C executable and C++ library from the
 same source
Message-ID: <CA+1aDq6hw9WXY4A1SKQ0qh0STSSyd0UdZZSZFj9hJEf+Hd=7hg@mail.gmail.com>

Hi,

I want to use Gtest for some unit tests on a number of the C functions that
comprise my C executable.  However, Gtest ( And gMock ) are C++ testing
frameworks.

What I would like to have is a project for my exe and then a separate
project for my C++ library and be able to change the source properties to
use the language CXX just before compiling.

The problem I'm having is that CMake uses the CXX compiler for the C files.


Here's what I would like to have

project(cexe)
set(SOURCES foo.c bar.c )
add_executable( cexe  ${SOURCES} )

project(cpplib)
set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX )
add_library( cpplib SHARED ${SOURCES} )



Is there a way to do this ?

Can target_compile_options set the compile type for a given target ?


In the past I've had to copy the .C files to some renamed .CPP equivalent
and then compile off of that.

I'm hoping that enough new functionality has been added to Cmake to allow
separation between compiles.


Thanks,




-- 

Jimi Damon
ACCES I/O Products, Inc. <http://accesio.com/go.cgi?p=/contact/contact.html>
Linux Engineer
JDamon at accesio.com
(858) 550-7320 x3015
[image: ACCES I/O Logo]
10623 Roselle Street San Diego CA 92121-1506 <http://accesio.com/>

-- 
WARNING - This e-mail or its attachments may contain controlled technical 
data or controlled technology within the definition of the International 
Traffic in Arms Regulations (ITAR) or Export Administration Regulations 
(EAR), and are subject to the export control laws of the U.S. Government. 
Transfer of this data or technology by any means to a foreign person, 
whether in the United States or abroad, without an export license or other 
approval from the U.S. Government, is prohibited. The information contained 
in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc. 
Any unauthorized review, use, disclosure or distribution is prohibited 
without express written consent of ACCES I/O Products, Inc. If you are not 
the intended recipient, please contact the sender and destroy all copies of 
the original message and enclosed attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/7e2df7a8/attachment.html>

From mkeeler at tenable.com  Wed Jan 17 13:10:48 2018
From: mkeeler at tenable.com (Matthew Keeler)
Date: Wed, 17 Jan 2018 13:10:48 -0500
Subject: [CMake] How can I create a C executable and C++ library from
 the same source
In-Reply-To: <CA+1aDq6hw9WXY4A1SKQ0qh0STSSyd0UdZZSZFj9hJEf+Hd=7hg@mail.gmail.com>
References: <CA+1aDq6hw9WXY4A1SKQ0qh0STSSyd0UdZZSZFj9hJEf+Hd=7hg@mail.gmail.com>
Message-ID: <CADQNH3X9fU3AqTGkQ-UGcdDjizSZNAJi__isTa6Uwcrk7VWeVA@mail.gmail.com>

Whether what you want exactly is possible I dont know. If you are just
wanting your C++ test library to be able to test your C source then I would
still let them compile as C and just extern ?C? { #include <your header> }.
When it gets linked all together it should be fine. This is how I usually
do testing of my C code with cpputest which is also a C++ library.

-- 
Matt Keeler


On January 17, 2018 at 13:05:36, Jimi Damon (jdamon at accesio.com) wrote:

Hi,

I want to use Gtest for some unit tests on a number of the C functions that
comprise my C executable.  However, Gtest ( And gMock ) are C++ testing
frameworks.

What I would like to have is a project for my exe and then a separate
project for my C++ library and be able to change the source properties to
use the language CXX just before compiling.

The problem I'm having is that CMake uses the CXX compiler for the C files.


Here's what I would like to have

project(cexe)
set(SOURCES foo.c bar.c )
add_executable( cexe  ${SOURCES} )

project(cpplib)
set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX )
add_library( cpplib SHARED ${SOURCES} )



Is there a way to do this ?

Can target_compile_options set the compile type for a given target ?


In the past I've had to copy the .C files to some renamed .CPP equivalent
and then compile off of that.

I'm hoping that enough new functionality has been added to Cmake to allow
separation between compiles.


Thanks,




--

Jimi Damon
ACCES I/O Products, Inc. <http://accesio.com/go.cgi?p=/contact/contact.html>
Linux Engineer
JDamon at accesio.com
(858) 550-7320 x3015
[image: ACCES I/O Logo]
10623 Roselle Street San Diego CA 92121-1506 <http://accesio.com/>


WARNING - This e-mail or its attachments may contain controlled technical
data or controlled technology within the definition of the International
Traffic in Arms Regulations (ITAR) or Export Administration Regulations
(EAR), and are subject to the export control laws of the U.S. Government.
Transfer of this data or technology by any means to a foreign person,
whether in the United States or abroad, without an export license or other
approval from the U.S. Government, is prohibited. The information contained
in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc.
Any unauthorized review, use, disclosure or distribution is prohibited
without express written consent of ACCES I/O Products, Inc. If you are not
the intended recipient, please contact the sender and destroy all copies of
the original message and enclosed attachments. --

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/4c6fbc96/attachment.html>

From d3ck0r at gmail.com  Wed Jan 17 13:29:49 2018
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 17 Jan 2018 10:29:49 -0800
Subject: [CMake] How can I create a C executable and C++ library from
 the same source
In-Reply-To: <CA+1aDq6hw9WXY4A1SKQ0qh0STSSyd0UdZZSZFj9hJEf+Hd=7hg@mail.gmail.com>
References: <CA+1aDq6hw9WXY4A1SKQ0qh0STSSyd0UdZZSZFj9hJEf+Hd=7hg@mail.gmail.com>
Message-ID: <CAA2GJqUt5uGopeqH_E0mp2qSU8Mgvuk0_LPV9eYGODFzioeY2g@mail.gmail.com>

No.
CMake tracks each source file name exactly once.  If you set properties on
it, it will be treated that way always.  Have to make  a copy of the source
to cpp...

copies to cmake_binary_dir/<source name>
plusplus_file_dup is the resulting list
( https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L655 )

(really this is just for headers... src/csrc.h should be
${binary}/src/csrc.h in target too because #include "crsc.h"

FOREACH(SOURCE ${PLUSPLUS_FILES_TO_COPY})
   if( ${SOURCE} MATCHES "${SOURCES_ROOT}(.*)$" )
       set( BASENAME ${CMAKE_MATCH_1} )
       set( plusplus_file_dup ${plusplus_file_dup}
${CMAKE_BINARY_DIR}/${BASENAME} )
       add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${BASENAME}
                           DEPENDS ${SOURCE}
                           COMMAND ${CMAKE_COMMAND} -E copy_if_different
${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}
                           #COMMAND ${CMAKE_COMMAND} -E touch
${CMAKE_BINARY_DIR}/${BASENAME}
                           )
   else()
   endif()
ENDFOREACH(SOURCE)


---------------------
( https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L672 )
THis make s abetter copy routine; it tests to see the type of header(file)
and possible substitutions...  still kinda some debugging coments (#)  in
there... this adds it as a rule, so it only generates the target source if
the source is referenced.  therefore also onlly when those C files change
do new copies get made.

macro( COPY_CPLUSPLUS FILE_LIST )
FOREACH(SOURCE ${ARGN} )
   if( ${SOURCE} MATCHES "${SACK_BASE}/(.*)\\.c$" )
      set( FILEOK 1 )
      set( BASENAME ${CMAKE_MATCH_1} )
      set( FILEEXT .cpp )
   elseif( ${SOURCE} MATCHES "${SACK_BASE}/(.*)\\.h$" )
      set( FILEOK 1 )
      set( BASENAME ${CMAKE_MATCH_1} )
      set( FILEEXT .h )
   elseif( ${SOURCE} MATCHES "(.*)\\.c$" )
      set( FILEOK 1 )
      set( BASENAME ${CMAKE_MATCH_1} )
      set( FILEEXT .cpp )
   elseif( ${SOURCE} MATCHES "(.*)\\.h$" )
      set( FILEOK 1 )
      set( BASENAME ${CMAKE_MATCH_1} )
      set( FILEEXT .h )
   else()
      set( FILEOK 0 )
      set( BASENAME "" )
   endif()

   if( FILEOK )
       get_source_file_property(SOURCE_FOLDER ${SOURCE} FOLDER)

       if( ${SOURCE} MATCHES "^${PROJECT_SOURCE_DIR}.*" )
          if( NOT ${SOURCE_FOLDER} MATCHES "NOTFOUND" )
            #message( "err folder : ${SOURCE_FOLDER} " )
            SOURCE_GROUP( ${SOURCE_FOLDER} FILES ${SOURCE} )
            SOURCE_GROUP( ${SOURCE_FOLDER} FILES
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
          endif()
          add_custom_command( OUTPUT
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
                              DEPENDS ${SOURCE}
                              COMMAND ${CMAKE_COMMAND} -E copy_if_different
${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
                              #COMMAND ${CMAKE_COMMAND} -E touch
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
                              )
          #EXECUTE_PROCESS(COMMAND cmake -E copy_if_different ${SOURCE}
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )

       else( ${SOURCE} MATCHES "^${PROJECT_SOURCE_DIR}.*" )
         if( NOT ${SOURCE_FOLDER} MATCHES "NOTFOUND" )
           #message( "err folder : ${SOURCE_FOLDER} " )
           SOURCE_GROUP( ${SOURCE_FOLDER} FILES
${PROJECT_SOURCE_DIR}/${SOURCE} )
           SOURCE_GROUP( ${SOURCE_FOLDER} FILES
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
         endif()
         add_custom_command( OUTPUT
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
                             DEPENDS ${PROJECT_SOURCE_DIR}/${SOURCE}
                             COMMAND ${CMAKE_COMMAND} -E copy_if_different
${PROJECT_SOURCE_DIR}/${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
                             #COMMAND ${CMAKE_COMMAND} -E touch
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
                             )
         #EXECUTE_PROCESS(COMMAND cmake -E copy_if_different
${PROJECT_SOURCE_DIR}/${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
         #message( "LIB2_SOURCE2 : ${BASENAME}  ${SOURCE}" )
       endif()
     set( ${FILE_LIST} ${${FILE_LIST}}
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
     #set( cplusplus_sources ${cplusplus_sources}
${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
   else()
      #message( "NOT THING ${SOURCE}" )
   endif()
ENDFOREACH(SOURCE)
endmacro( COPY_CPLUSPLUS )



On Wed, Jan 17, 2018 at 10:05 AM, Jimi Damon <jdamon at accesio.com> wrote:

> Hi,
>
> I want to use Gtest for some unit tests on a number of the C functions
> that comprise my C executable.  However, Gtest ( And gMock ) are C++
> testing frameworks.
>
> What I would like to have is a project for my exe and then a separate
> project for my C++ library and be able to change the source properties to
> use the language CXX just before compiling.
>
> The problem I'm having is that CMake uses the CXX compiler for the C files.
>
>
> Here's what I would like to have
>
> project(cexe)
> set(SOURCES foo.c bar.c )
> add_executable( cexe  ${SOURCES} )
>
> project(cpplib)
> set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX )
> add_library( cpplib SHARED ${SOURCES} )
>
>
>
> Is there a way to do this ?
>
> Can target_compile_options set the compile type for a given target ?
>
>
> In the past I've had to copy the .C files to some renamed .CPP equivalent
> and then compile off of that.
>
> I'm hoping that enough new functionality has been added to Cmake to allow
> separation between compiles.
>
>
> Thanks,
>
>
>
>
> --
>
> Jimi Damon
> ACCES I/O Products, Inc.
> <http://accesio.com/go.cgi?p=/contact/contact.html>
> Linux Engineer
> JDamon at accesio.com
> (858) 550-7320 x3015
> [image: ACCES I/O Logo]
> 10623 Roselle Street San Diego CA 92121-1506 <http://accesio.com/>
>
>
> WARNING - This e-mail or its attachments may contain controlled technical
> data or controlled technology within the definition of the International
> Traffic in Arms Regulations (ITAR) or Export Administration Regulations
> (EAR), and are subject to the export control laws of the U.S. Government.
> Transfer of this data or technology by any means to a foreign person,
> whether in the United States or abroad, without an export license or other
> approval from the U.S. Government, is prohibited. The information contained
> in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc.
> Any unauthorized review, use, disclosure or distribution is prohibited
> without express written consent of ACCES I/O Products, Inc. If you are not
> the intended recipient, please contact the sender and destroy all copies of
> the original message and enclosed attachments.
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/3ed2f870/attachment-0001.html>

From robert.maynard at kitware.com  Wed Jan 17 14:39:23 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 17 Jan 2018 14:39:23 -0500
Subject: [CMake] How can I create a C executable and C++ library from
 the same source
In-Reply-To: <CAA2GJqUt5uGopeqH_E0mp2qSU8Mgvuk0_LPV9eYGODFzioeY2g@mail.gmail.com>
References: <CA+1aDq6hw9WXY4A1SKQ0qh0STSSyd0UdZZSZFj9hJEf+Hd=7hg@mail.gmail.com>
 <CAA2GJqUt5uGopeqH_E0mp2qSU8Mgvuk0_LPV9eYGODFzioeY2g@mail.gmail.com>
Message-ID: <CAFzjYVr0Uid2kzo5_N3ARdYnLMGY=HgZSHBO-6VvE5odE5pbFQ@mail.gmail.com>

As stated CMake tracks source files globally so they can only have a single
language.

Project that I work on have migrated over to using file(GENERATE) to
produce the files as it only
requires a couple lines of CMake code.

get_filename_component(c_fname "${c_source_file}" NAME_WE)
get_filename_component(c_fullpath "${c_source_file}" ABSOLUTE)
file(GENERATE
      OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${c_fname}.cpp
      CONTENT "#include \"${c_fullpath}\"")

What ever approach you take I recommend not using an approach that copies
the contents of the
source file itself. Those will generally than require CMake to re-run every
time you modify the file. Instead
use an include statement so CMake won't re-run.

On Wed, Jan 17, 2018 at 1:29 PM, J Decker <d3ck0r at gmail.com> wrote:

> No.
> CMake tracks each source file name exactly once.  If you set properties on
> it, it will be treated that way always.  Have to make  a copy of the source
> to cpp...
>
> copies to cmake_binary_dir/<source name>
> plusplus_file_dup is the resulting list
> ( https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L655 )
>
> (really this is just for headers... src/csrc.h should be
> ${binary}/src/csrc.h in target too because #include "crsc.h"
>
> FOREACH(SOURCE ${PLUSPLUS_FILES_TO_COPY})
>    if( ${SOURCE} MATCHES "${SOURCES_ROOT}(.*)$" )
>        set( BASENAME ${CMAKE_MATCH_1} )
>        set( plusplus_file_dup ${plusplus_file_dup} ${CMAKE_BINARY_DIR}/${BASENAME}
> )
>        add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${BASENAME}
>                            DEPENDS ${SOURCE}
>                            COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}
>                            #COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_BINARY_DIR}/${BASENAME}
>                            )
>    else()
>    endif()
> ENDFOREACH(SOURCE)
>
>
> ---------------------
> ( https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L672 )
> THis make s abetter copy routine; it tests to see the type of header(file)
> and possible substitutions...  still kinda some debugging coments (#)  in
> there... this adds it as a rule, so it only generates the target source if
> the source is referenced.  therefore also onlly when those C files change
> do new copies get made.
>
> macro( COPY_CPLUSPLUS FILE_LIST )
> FOREACH(SOURCE ${ARGN} )
>    if( ${SOURCE} MATCHES "${SACK_BASE}/(.*)\\.c$" )
>       set( FILEOK 1 )
>       set( BASENAME ${CMAKE_MATCH_1} )
>       set( FILEEXT .cpp )
>    elseif( ${SOURCE} MATCHES "${SACK_BASE}/(.*)\\.h$" )
>       set( FILEOK 1 )
>       set( BASENAME ${CMAKE_MATCH_1} )
>       set( FILEEXT .h )
>    elseif( ${SOURCE} MATCHES "(.*)\\.c$" )
>       set( FILEOK 1 )
>       set( BASENAME ${CMAKE_MATCH_1} )
>       set( FILEEXT .cpp )
>    elseif( ${SOURCE} MATCHES "(.*)\\.h$" )
>       set( FILEOK 1 )
>       set( BASENAME ${CMAKE_MATCH_1} )
>       set( FILEEXT .h )
>    else()
>       set( FILEOK 0 )
>       set( BASENAME "" )
>    endif()
>
>    if( FILEOK )
>        get_source_file_property(SOURCE_FOLDER ${SOURCE} FOLDER)
>
>        if( ${SOURCE} MATCHES "^${PROJECT_SOURCE_DIR}.*" )
>           if( NOT ${SOURCE_FOLDER} MATCHES "NOTFOUND" )
>             #message( "err folder : ${SOURCE_FOLDER} " )
>             SOURCE_GROUP( ${SOURCE_FOLDER} FILES ${SOURCE} )
>             SOURCE_GROUP( ${SOURCE_FOLDER} FILES ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>           endif()
>           add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${
> BASENAME}${FILEEXT}
>                               DEPENDS ${SOURCE}
>                               COMMAND ${CMAKE_COMMAND} -E
> copy_if_different ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>                               #COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>                               )
>           #EXECUTE_PROCESS(COMMAND cmake -E copy_if_different ${SOURCE}
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
>
>        else( ${SOURCE} MATCHES "^${PROJECT_SOURCE_DIR}.*" )
>          if( NOT ${SOURCE_FOLDER} MATCHES "NOTFOUND" )
>            #message( "err folder : ${SOURCE_FOLDER} " )
>            SOURCE_GROUP( ${SOURCE_FOLDER} FILES ${PROJECT_SOURCE_DIR}/${SOURCE}
> )
>            SOURCE_GROUP( ${SOURCE_FOLDER} FILES ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>          endif()
>          add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${
> BASENAME}${FILEEXT}
>                              DEPENDS ${PROJECT_SOURCE_DIR}/${SOURCE}
>                              COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${PROJECT_SOURCE_DIR}/${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>                              #COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>                              )
>          #EXECUTE_PROCESS(COMMAND cmake -E copy_if_different
> ${PROJECT_SOURCE_DIR}/${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>          #message( "LIB2_SOURCE2 : ${BASENAME}  ${SOURCE}" )
>        endif()
>      set( ${FILE_LIST} ${${FILE_LIST}} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>      #set( cplusplus_sources ${cplusplus_sources} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>    else()
>       #message( "NOT THING ${SOURCE}" )
>    endif()
> ENDFOREACH(SOURCE)
> endmacro( COPY_CPLUSPLUS )
>
>
>
> On Wed, Jan 17, 2018 at 10:05 AM, Jimi Damon <jdamon at accesio.com> wrote:
>
>> Hi,
>>
>> I want to use Gtest for some unit tests on a number of the C functions
>> that comprise my C executable.  However, Gtest ( And gMock ) are C++
>> testing frameworks.
>>
>> What I would like to have is a project for my exe and then a separate
>> project for my C++ library and be able to change the source properties to
>> use the language CXX just before compiling.
>>
>> The problem I'm having is that CMake uses the CXX compiler for the C
>> files.
>>
>>
>> Here's what I would like to have
>>
>> project(cexe)
>> set(SOURCES foo.c bar.c )
>> add_executable( cexe  ${SOURCES} )
>>
>> project(cpplib)
>> set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX )
>> add_library( cpplib SHARED ${SOURCES} )
>>
>>
>>
>> Is there a way to do this ?
>>
>> Can target_compile_options set the compile type for a given target ?
>>
>>
>> In the past I've had to copy the .C files to some renamed .CPP equivalent
>> and then compile off of that.
>>
>> I'm hoping that enough new functionality has been added to Cmake to allow
>> separation between compiles.
>>
>>
>> Thanks,
>>
>>
>>
>>
>> --
>>
>> Jimi Damon
>> ACCES I/O Products, Inc.
>> <http://accesio.com/go.cgi?p=/contact/contact.html>
>> Linux Engineer
>> JDamon at accesio.com
>> (858) 550-7320 x3015
>> [image: ACCES I/O Logo]
>> 10623 Roselle Street San Diego CA 92121-1506 <http://accesio.com/>
>>
>>
>> WARNING - This e-mail or its attachments may contain controlled technical
>> data or controlled technology within the definition of the International
>> Traffic in Arms Regulations (ITAR) or Export Administration Regulations
>> (EAR), and are subject to the export control laws of the U.S. Government.
>> Transfer of this data or technology by any means to a foreign person,
>> whether in the United States or abroad, without an export license or other
>> approval from the U.S. Government, is prohibited. The information contained
>> in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc.
>> Any unauthorized review, use, disclosure or distribution is prohibited
>> without express written consent of ACCES I/O Products, Inc. If you are not
>> the intended recipient, please contact the sender and destroy all copies of
>> the original message and enclosed attachments.
>> --
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/f9009300/attachment.html>

From kgt at lanl.gov  Wed Jan 17 16:02:23 2018
From: kgt at lanl.gov (Thompson, KT)
Date: Wed, 17 Jan 2018 21:02:23 +0000
Subject: [CMake] CDash calendar button no longer works?
Message-ID: <f4dcfd5990ff49bb9c66ef2554992e77@lanl.gov>

Hi,

The 'calendar' button in our CDash installation (v. 2.5.0) stopped working recently (no changes to our CDash installation and only regular security patches to the web server).  Everything else works fine.  Does anyone have any ideas on how to diagnose why my calendar no longer works?

BTW - the calendar works fine for https://open.cdash.org, so I don't think this is a browser issue.  There is probably something misconfigured on my web server, but I don't know where to start looking.

Thanks for any input you can provide.

-kt
Kelly (KT) Thompson
kgt at lanl.gov<mailto:kgt at lanl.gov>
505.665.8090

Los Alamos National Laboratory
CCS-2, MS D409, TA-3/B-422/R-101

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/10b46d8c/attachment-0001.html>

From lucas.soltic at orange.fr  Wed Jan 17 17:49:16 2018
From: lucas.soltic at orange.fr (Lucas Soltic)
Date: Wed, 17 Jan 2018 23:49:16 +0100
Subject: [CMake] Recommandation for macOS framework install rules
Message-ID: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>

Hello,

By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local by default) as a base for relative install paths. But when you define install rules for macOS frameworks, it doesn't make much sense to install them there. I'd rather expect something like /Library/Frameworks.

On the other side, if you have more things to install like a "readme" or documentation that should go into /usr/local/share, it doesn't make sense to have them installed in /Library/Frameworks. So you can't just change CMAKE_INSTALL_PREFIX to be /Library/Frameworks.

What do you recommend to keep installation rules simple (ie. remain relative) and yet support installation of both frameworks and other things?

Best regards,
Lucas

From d3ck0r at gmail.com  Wed Jan 17 18:19:01 2018
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 17 Jan 2018 15:19:01 -0800
Subject: [CMake] Recommandation for macOS framework install rules
In-Reply-To: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
References: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
Message-ID: <CAA2GJqV-5oAgzxJ0kcs+2vrJ8KwFiyExS7O0yMPHu=D=mf5vzg@mail.gmail.com>

It's not entirely related other than Mac....

I had to test

if( __COMPILER_GNU AND NOT CMAKE_COMPILER_IS_GNUCC )

instead of just CMAKE_COMPILER_IS_GNUCC (which was unset)

__COMPILER_GNU was found after doing a dump...

I suppose there's some modern way I'm supposed to test GCC that works on
all systems?


On Wed, Jan 17, 2018 at 2:49 PM, Lucas Soltic <lucas.soltic at orange.fr>
wrote:

> Hello,
>
> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local
> by default) as a base for relative install paths. But when you define
> install rules for macOS frameworks, it doesn't make much sense to install
> them there. I'd rather expect something like /Library/Frameworks.
>
> On the other side, if you have more things to install like a "readme" or
> documentation that should go into /usr/local/share, it doesn't make sense
> to have them installed in /Library/Frameworks. So you can't just change
> CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
>
> What do you recommend to keep installation rules simple (ie. remain
> relative) and yet support installation of both frameworks and other things?
>
> Best regards,
> Lucas
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180117/f439f808/attachment.html>

From cvniekerk at emss.co.za  Thu Jan 18 02:48:48 2018
From: cvniekerk at emss.co.za (Charl van Niekerk)
Date: Thu, 18 Jan 2018 07:48:48 +0000
Subject: [CMake] Platform/x86_64-unknown-linux-gnu
In-Reply-To: <447fe33c14114497868e14c2c332f557@ROME.emss.co.za>
References: <447fe33c14114497868e14c2c332f557@ROME.emss.co.za>
Message-ID: <9d82e7d89bbd41acaa0b47eaf5cb9fa7@ROME.emss.co.za>

Does not want to cross compile for my Linux ARM processor.

Charl van Niekerk
Development Engineer
EMSS Antennas
18 Techno Avenue, Technopark
Stellenbosch 7600
South Africa

Postal Address:
EMSS Antennas
PO Box 492
Stellenbosch 7599
South Africa

Phone      +27 (0)21 880 1188
Fax           +27 (0)21 880 1982
Mobile     +27 (0)83 608 4638
e-mail     cvniekerk at emss.co.za<mailto:cvniekerk at emss.co.za>
web         www.emss.co.za<http://www.emss.co.za/>

[Description: emsslogo_Blank.jpg]

Disclaimer<http://www.emss.co.za/emss-email-disclaimer.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180118/5126f11e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11076 bytes
Desc: image001.png
URL: <https://cmake.org/pipermail/cmake/attachments/20180118/5126f11e/attachment-0001.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CopyOfCMakeCache.txt
URL: <https://cmake.org/pipermail/cmake/attachments/20180118/5126f11e/attachment-0001.txt>

From robert.maynard at kitware.com  Thu Jan 18 11:16:43 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 18 Jan 2018 11:16:43 -0500
Subject: [CMake] Recommandation for macOS framework install rules
In-Reply-To: <CAA2GJqV-5oAgzxJ0kcs+2vrJ8KwFiyExS7O0yMPHu=D=mf5vzg@mail.gmail.com>
References: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
 <CAA2GJqV-5oAgzxJ0kcs+2vrJ8KwFiyExS7O0yMPHu=D=mf5vzg@mail.gmail.com>
Message-ID: <CAFzjYVpGNXPRENBQr+qfY-BESw7nfqfgsMnYFb9usCoPNmpbEA@mail.gmail.com>

Are you just checking if the compiler is GCC? if so I would use
COMPILER_ID https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER_ID.html

On Wed, Jan 17, 2018 at 6:19 PM, J Decker <d3ck0r at gmail.com> wrote:
> It's not entirely related other than Mac....
>
> I had to test
>
> if( __COMPILER_GNU AND NOT CMAKE_COMPILER_IS_GNUCC )
>
> instead of just CMAKE_COMPILER_IS_GNUCC (which was unset)
>
> __COMPILER_GNU was found after doing a dump...
>
> I suppose there's some modern way I'm supposed to test GCC that works on all
> systems?
>
>
> On Wed, Jan 17, 2018 at 2:49 PM, Lucas Soltic <lucas.soltic at orange.fr>
> wrote:
>>
>> Hello,
>>
>> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local
>> by default) as a base for relative install paths. But when you define
>> install rules for macOS frameworks, it doesn't make much sense to install
>> them there. I'd rather expect something like /Library/Frameworks.
>>
>> On the other side, if you have more things to install like a "readme" or
>> documentation that should go into /usr/local/share, it doesn't make sense to
>> have them installed in /Library/Frameworks. So you can't just change
>> CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
>>
>> What do you recommend to keep installation rules simple (ie. remain
>> relative) and yet support installation of both frameworks and other things?
>>
>> Best regards,
>> Lucas
>> --
>>
>> 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
>

From simon.rit at creatis.insa-lyon.fr  Thu Jan 18 11:58:01 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 18 Jan 2018 17:58:01 +0100
Subject: [CMake] Unexpected recompilation with ctest compiled MSVC project
Message-ID: <CAF0oig3xE_Kj_jM09QDETwmCZyEwNVSDkusWFkq2QEiBNThmpg@mail.gmail.com>

Hello,
I'm happily using ctest to test my project:
http://my.cdash.org/index.php?project=RTK
One feature that I like is that if a problem appears with one config, I can
easily try to modify the sources and then run make in the nightly built
directory, only the object that failed to compile and object files impacted
by the changes will be (re-)compiled. This works perfectly under linux with
makefiles.
However, the behavior is not the same under MSVC and since I am not used to
this IDE, I'd like some explanation. When I have a problem with a
compilation and I open the nightly configured MSVC project in the IDE, then
everything is recompiled, including those files that compiled without any
issue. Is this an expected behavior and, if yes, is there any way to
recompile only what has failed, as I am used too under linux?
I hope this is clear (enough). Thanks,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180118/9d269d14/attachment.html>

From robert.maynard at kitware.com  Thu Jan 18 12:15:14 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 18 Jan 2018 12:15:14 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.10.2 available for download
Message-ID: <CAFzjYVqpcjv2TpYTOaD+DPAMhLk4i+THxb3hLmGUa95A=aDVQQ@mail.gmail.com>

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

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

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.10.2 since 3.10.1:

Brad King (2):
      KWIML: Backport RISC-V update to CMake 3.10
      CMake 3.10.2

Egor Pugin (1):
      FindPostgreSQL: Add support for PG10

Joel T. Frederico (1):
      cmGraphVizWriter: Updated to create and follow dependers for
      interface targets

Sebastian Holtermann (2):
      Autogen: Fix for problematic nested list separator
      Autogen: Ignore not existing source files in cmMakefile

From kris.f.thielemans at gmail.com  Thu Jan 18 15:01:23 2018
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Thu, 18 Jan 2018 20:01:23 -0000
Subject: [CMake] Unexpected recompilation with ctest compiled MSVC
 project
In-Reply-To: <CAF0oig3xE_Kj_jM09QDETwmCZyEwNVSDkusWFkq2QEiBNThmpg@mail.gmail.com>
References: <CAF0oig3xE_Kj_jM09QDETwmCZyEwNVSDkusWFkq2QEiBNThmpg@mail.gmail.com>
Message-ID: <010c01d39097$1e2132f0$5a6398d0$@gmail.com>

Hi Simon

 

It definitely isn?t expected behaviour. MSVC should do exactly the same. It seems to point to a problem in your CMake files or elsewhere. Does the same thing happen if you just build immediately? Obviously, you shouldn?t do ?rebuild? but just ?build?. 

 

I haven?t checked RTK. Sorry. 

 

Kris

 

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Simon Rit
Sent: 18 January 2018 16:58
To: cmake at cmake.org
Subject: [CMake] Unexpected recompilation with ctest compiled MSVC project

 

Hello,

I'm happily using ctest to test my project:
http://my.cdash.org/index.php?project=RTK
One feature that I like is that if a problem appears with one config, I can easily try to modify the sources and then run make in the nightly built directory, only the object that failed to compile and object files impacted by the changes will be (re-)compiled. This works perfectly under linux with makefiles.

However, the behavior is not the same under MSVC and since I am not used to this IDE, I'd like some explanation. When I have a problem with a compilation and I open the nightly configured MSVC project in the IDE, then everything is recompiled, including those files that compiled without any issue. Is this an expected behavior and, if yes, is there any way to recompile only what has failed, as I am used too under linux?

I hope this is clear (enough). Thanks,

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180118/5e8ddcbd/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Fri Jan 19 05:01:24 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 19 Jan 2018 11:01:24 +0100
Subject: [CMake] Unexpected recompilation with ctest compiled MSVC
 project
In-Reply-To: <010c01d39097$1e2132f0$5a6398d0$@gmail.com>
References: <CAF0oig3xE_Kj_jM09QDETwmCZyEwNVSDkusWFkq2QEiBNThmpg@mail.gmail.com>
 <010c01d39097$1e2132f0$5a6398d0$@gmail.com>
Message-ID: <CAF0oig1aTqmOhP8PChzQqGRYvN=73aTunDdxLAyxhTsP_vdqUg@mail.gmail.com>

Hi,
If I do two consecutive builds with the same project, then it does not
recompile the second time, no. It behaves as if something is different (a
flag or something else) between the command line ctest build and the build
in the gui.
Simon

On Thu, Jan 18, 2018 at 9:01 PM, Kris Thielemans <
kris.f.thielemans at gmail.com> wrote:

> Hi Simon
>
>
>
> It definitely isn?t expected behaviour. MSVC should do exactly the same.
> It seems to point to a problem in your CMake files or elsewhere. Does the
> same thing happen if you just build immediately? Obviously, you shouldn?t
> do ?rebuild? but just ?build?.
>
>
>
> I haven?t checked RTK. Sorry.
>
>
>
> Kris
>
>
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Simon Rit
> *Sent:* 18 January 2018 16:58
> *To:* cmake at cmake.org
> *Subject:* [CMake] Unexpected recompilation with ctest compiled MSVC
> project
>
>
>
> Hello,
>
> I'm happily using ctest to test my project:
> http://my.cdash.org/index.php?project=RTK
> One feature that I like is that if a problem appears with one config, I
> can easily try to modify the sources and then run make in the nightly built
> directory, only the object that failed to compile and object files impacted
> by the changes will be (re-)compiled. This works perfectly under linux with
> makefiles.
>
> However, the behavior is not the same under MSVC and since I am not used
> to this IDE, I'd like some explanation. When I have a problem with a
> compilation and I open the nightly configured MSVC project in the IDE, then
> everything is recompiled, including those files that compiled without any
> issue. Is this an expected behavior and, if yes, is there any way to
> recompile only what has failed, as I am used too under linux?
>
> I hope this is clear (enough). Thanks,
>
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180119/18443a5e/attachment.html>

From zack.galbreath at kitware.com  Fri Jan 19 09:24:19 2018
From: zack.galbreath at kitware.com (Zack Galbreath)
Date: Fri, 19 Jan 2018 09:24:19 -0500
Subject: [CMake] CDash calendar button no longer works?
In-Reply-To: <f4dcfd5990ff49bb9c66ef2554992e77@lanl.gov>
References: <f4dcfd5990ff49bb9c66ef2554992e77@lanl.gov>
Message-ID: <CANgkMA4M0=iw6qeQW-tZoeA1NXdTQtQSNvjWMycFi+7huxgYHg@mail.gmail.com>

On Wed, Jan 17, 2018 at 4:02 PM, Thompson, KT <kgt at lanl.gov> wrote:

> Hi,
>
>
>
> The 'calendar' button in our CDash installation (v. 2.5.0) stopped working
> recently (no changes to our CDash installation and only regular security
> patches to the web server).  Everything else works fine.  Does anyone have
> any ideas on how to diagnose why my calendar no longer works?
>

The fact that this happened without a CDash upgrade is quite mysterious.
Does your web browser throw any JavaScript errors when you click the
Calendar button? You can check by opening the JavaScript console. On
Chrome, this can be accessed as View -> Developer -> JavaScript Console.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180119/7706531c/attachment.html>

From paul at mad-scientist.net  Fri Jan 19 09:55:59 2018
From: paul at mad-scientist.net (Paul Smith)
Date: Fri, 19 Jan 2018 09:55:59 -0500
Subject: [CMake] Building cmake: why is openssl linked?
In-Reply-To: <CAE1uMrUis3tYMAujoSOyOarLnuvQrsFotfVvWE1DMnqwpLKLrg@mail.gmail.com>
References: <1515885337.3068.55.camel@mad-scientist.net>
 <CAE1uMrUis3tYMAujoSOyOarLnuvQrsFotfVvWE1DMnqwpLKLrg@mail.gmail.com>
Message-ID: <1516373759.6809.98.camel@mad-scientist.net>

On Sun, 2018-01-14 at 01:08 +0100, Jean-Micha?l Celerier wrote:
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
> 
> since CMake can download stuff, it needs to support https, hence SSL,
> hence OpenSSL

OK, thanks.

Does anyone know if there is way to convince CMake to use a decent SSL
library, like libressl or something, rather than the really horribly
managed openssl?

In the meantime I'll omit support for this in my builds of cmake, since
I don't actually use that feature.


From kgt at lanl.gov  Fri Jan 19 11:09:14 2018
From: kgt at lanl.gov (Thompson, KT)
Date: Fri, 19 Jan 2018 16:09:14 +0000
Subject: [CMake] CDash calendar button no longer works?
In-Reply-To: <CANgkMA4M0=iw6qeQW-tZoeA1NXdTQtQSNvjWMycFi+7huxgYHg@mail.gmail.com>
References: <f4dcfd5990ff49bb9c66ef2554992e77@lanl.gov>
 <CANgkMA4M0=iw6qeQW-tZoeA1NXdTQtQSNvjWMycFi+7huxgYHg@mail.gmail.com>
Message-ID: <ff01fd3dfe0b4a2693daee45e458c639@lanl.gov>

Zack,

Thanks for responding.

I agree that the broken calendar behavior is strange.  My CDash calendar stopped working after some RHEL7 system patches were installed.  I'm not the admin of the machine, so I don't have the details.  However, everyone who uses my CDash server sees the same problem.

My Java console prints these messages when I refresh the page:

VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/build/views/partials/header_2.5.0.html".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.214 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/build/views/partials/footer_2.5.0.html".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.288 angular.js:10770 [Violation] 'load' handler took 255ms
09:07:45.751 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/api/v1/index.php?date=2018-01-19&filterstring=&project=Jayenne".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.829 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/views/partials/header.html".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.833 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/views/partials/footer.html".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.837 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/build/views/partials/filterdataTemplate_2.5.0.html".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.875 angular.js:10770 [Violation] 'load' handler took 457ms
09:07:45.900 [Violation] Forced reflow while executing JavaScript took 31ms
09:07:45.935 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/build/views/partials/build_2.5.0.html".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:46.007 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/ajax/getfeed.php?projectid=2".
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:46.138 VM15408:1 XHR finished loading: GET "https://rtt.lanl.gov/cdash/api/v1/filterdata.php?date=2018-01-19&filterstring=&page_id=index.php&project=Jayenne&showlimit=0".

However, pressing the "calendar" button doesn't seem to do anything (no output to the java console or any other change that I can see).

-kt


From: Zack Galbreath [mailto:zack.galbreath at kitware.com]
Sent: Friday, January 19, 2018 7:24 AM
To: Thompson, KT <kgt at lanl.gov>
Cc: cmake at cmake.org
Subject: Re: [CMake] CDash calendar button no longer works?

On Wed, Jan 17, 2018 at 4:02 PM, Thompson, KT <kgt at lanl.gov<mailto:kgt at lanl.gov>> wrote:
Hi,

The 'calendar' button in our CDash installation (v. 2.5.0) stopped working recently (no changes to our CDash installation and only regular security patches to the web server).  Everything else works fine.  Does anyone have any ideas on how to diagnose why my calendar no longer works?

The fact that this happened without a CDash upgrade is quite mysterious. Does your web browser throw any JavaScript errors when you click the Calendar button? You can check by opening the JavaScript console. On Chrome, this can be accessed as View -> Developer -> JavaScript Console.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180119/a709e537/attachment-0001.html>

From chuck.atkins at kitware.com  Fri Jan 19 13:22:04 2018
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Fri, 19 Jan 2018 13:22:04 -0500
Subject: [CMake] how to detect architecture ?
In-Reply-To: <544314714.15938853.1515510268977.JavaMail.zimbra@inria.fr>
References: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
 <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
 <173831515510055@web29o.yandex.ru>
 <544314714.15938853.1515510268977.JavaMail.zimbra@inria.fr>
Message-ID: <CAOXZzG5RbYgj68XDV_OG3VFVa9bfsB+yXYBsQB77RGtwzW9sVA@mail.gmail.com>

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 <stdio.h>

static inline
void get_library_filename(char* filename, const char* libname)
{
  sprintf(filename, "@CMAKE_SHARED_LIBRARY_PREFIX@
%s at 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 <stdio.h>
#include <util.h>

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&D Engineer, Scientific Computing
Kitware, Inc.


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

> Thanks !
>
> ----- Mail original -----
> > De: "Konstantin Tokarev" <annulen at yandex.ru>
> > ?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <
> cmake at 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.houssen at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180119/e7641d23/attachment.html>

From petr.elexa at comap.cz  Fri Jan 19 13:19:07 2018
From: petr.elexa at comap.cz (Elexa Petr)
Date: Fri, 19 Jan 2018 18:19:07 +0000
Subject: [CMake] Space after CMAKE_LINK_LIBRARY_FILE_FLAG
Message-ID: <VI1PR07MB14869D0B1484BBE18844A44AF5EF0@VI1PR07MB1486.eurprd07.prod.outlook.com>

Hello,

I am trying to add support for Renesas CCRX compiler by creating a platform file.

I have come across a problem where I try to set the CMAKE_LINK_LIBRARY_FILE_FLAG to "-library=" a space is added after the flag by CMake. Which is not the case with CMAKE_INCLUDE_FLAG_<LANG> variable.

Example command produced to link executable (notice the space between equals sign and path to a library):
rlink -nologo -library= path_to_some_lib_a.lib -library= path_to_some_lib_b.lib -form=stype -output=myprogram.mot some_object_file.obj

but I need it to look like this:
rlink -nologo -library=path_to_some_lib_a.lib -library=path_to_some_lib_b.lib -form=stype -output=myprogram.mot some_object_file.obj

Is there a way to tell the cmake to not put the space there? Or any other way to do it?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180119/4ee5b39a/attachment.html>

From annulen at yandex.ru  Fri Jan 19 13:26:48 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 19 Jan 2018 21:26:48 +0300
Subject: [CMake] how to detect architecture ?
In-Reply-To: <CAOXZzG5RbYgj68XDV_OG3VFVa9bfsB+yXYBsQB77RGtwzW9sVA@mail.gmail.com>
References: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
 <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
 <173831515510055@web29o.yandex.ru>
 <544314714.15938853.1515510268977.JavaMail.zimbra@inria.fr>
 <CAOXZzG5RbYgj68XDV_OG3VFVa9bfsB+yXYBsQB77RGtwzW9sVA@mail.gmail.com>
Message-ID: <1608381516386408@web6o.yandex.ru>



19.01.2018, 21:22, "Chuck Atkins" <chuck.atkins at kitware.com>:
> 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 <stdio.h>
>
> static inline
> void get_library_filename(char* filename, const char* libname)
> {
> ? sprintf(filename, "@CMAKE_SHARED_LIBRARY_PREFIX@%s at 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 <stdio.h>
> #include <util.h>
>
> 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.

Note that Windows DLLs may also happen to have to lib prefix (e.g. CMake adds them
by default when building projects with MinGW).

>
> ----------
> Chuck Atkins
> Staff R&D Engineer, Scientific Computing
> Kitware, Inc.
>
> On Tue, Jan 9, 2018 at 10:04 AM, Franck Houssen <franck.houssen at inria.fr> wrote:
>> Thanks !
>>
>> ----- Mail original -----
>>> De: "Konstantin Tokarev" <annulen at yandex.ru>
>>> ?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <cmake at 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.houssen at 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


--?
Regards,
Konstantin

From lucas.soltic at orange.fr  Fri Jan 19 13:44:03 2018
From: lucas.soltic at orange.fr (Lucas Soltic)
Date: Fri, 19 Jan 2018 19:44:03 +0100
Subject: [CMake] Recommandation for macOS framework install rules
In-Reply-To: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
References: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
Message-ID: <17CE0013-D542-4782-ABEE-305693D8E37F@orange.fr>

Hello,
Should I conclude that there are no recommendations?

Best regards,
Lucas

> Le 17 janv. 2018 ? 23:49, Lucas Soltic <lucas.soltic at orange.fr> a ?crit :
> 
> Hello,
> 
> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local by default) as a base for relative install paths. But when you define install rules for macOS frameworks, it doesn't make much sense to install them there. I'd rather expect something like /Library/Frameworks.
> 
> On the other side, if you have more things to install like a "readme" or documentation that should go into /usr/local/share, it doesn't make sense to have them installed in /Library/Frameworks. So you can't just change CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
> 
> What do you recommend to keep installation rules simple (ie. remain relative) and yet support installation of both frameworks and other things?
> 
> Best regards,
> Lucas
> -- 
> 
> 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


From franck.houssen at inria.fr  Sat Jan 20 06:20:38 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Sat, 20 Jan 2018 12:20:38 +0100 (CET)
Subject: [CMake] how to detect architecture ?
In-Reply-To: <1608381516386408@web6o.yandex.ru>
References: <201657027.15919526.1515509207865.JavaMail.zimbra@inria.fr>
 <1328068172.15929831.1515509865289.JavaMail.zimbra@inria.fr>
 <173831515510055@web29o.yandex.ru>
 <544314714.15938853.1515510268977.JavaMail.zimbra@inria.fr>
 <CAOXZzG5RbYgj68XDV_OG3VFVa9bfsB+yXYBsQB77RGtwzW9sVA@mail.gmail.com>
 <1608381516386408@web6o.yandex.ru>
Message-ID: <1274485896.21271461.1516447238581.JavaMail.zimbra@inria.fr>

Got it, thanks.
I'll do that even if Windows is not an OS I target (I guess tests will not run on Windows - run bash script like ./test.sh in which I redirect outputs with > and other stuffs the unix way).

----- Mail original -----
> De: "Konstantin Tokarev" <annulen at yandex.ru>
> ?: "Chuck Atkins" <chuck.atkins at kitware.com>, "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Vendredi 19 Janvier 2018 19:26:48
> Objet: Re: [CMake] how to detect architecture ?
> 
> 
> 
> 19.01.2018, 21:22, "Chuck Atkins" <chuck.atkins at kitware.com>:
> > 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 <stdio.h>
> >
> > static inline
> > void get_library_filename(char* filename, const char* libname)
> > {
> > ? sprintf(filename,
> > ? "@CMAKE_SHARED_LIBRARY_PREFIX@%s at 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 <stdio.h>
> > #include <util.h>
> >
> > 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.
> 
> Note that Windows DLLs may also happen to have to lib prefix (e.g. CMake adds
> them
> by default when building projects with MinGW).
> 
> >
> > ----------
> > Chuck Atkins
> > Staff R&D Engineer, Scientific Computing
> > Kitware, Inc.
> >
> > On Tue, Jan 9, 2018 at 10:04 AM, Franck Houssen <franck.houssen at inria.fr>
> > wrote:
> >> Thanks !
> >>
> >> ----- Mail original -----
> >>> De: "Konstantin Tokarev" <annulen at yandex.ru>
> >>> ?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List"
> >>> <cmake at 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.houssen at 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
> 
> 
> --
> Regards,
> Konstantin
> 

From biddisco at cscs.ch  Sat Jan 20 18:12:06 2018
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Sat, 20 Jan 2018 23:12:06 +0000
Subject: [CMake] cmake 3.10.1 findMpi unusable
Message-ID: <50320452A334BD42A5EC72BAD2145099556DF24A@MBX110.d.ethz.ch>

My system updated cmake to 3.10.1 and now findpackage(mpi) is now unusable

After trying everything I can think of, I have ended up with this, but it still does not find mpi as the trycompile step fails to build a test mpi due to missing mpi.h

It used to be so simple. I do not want to use compiler wrappers or any other fancy detection, all I want to do is tell it an include path and a library.

Can anyone tell me what cmake var am I missing? Thanks

JB

cmake --debug-try-compile \
  -DHPX_DIR=~/build/hpx-debug/lib/cmake/HPX \
  -DMPI_SKIP_COMPILER_WRAPPER=ON \
  -DMPI_ASSUME_NO_BUILTIN_MPI=ON  \
  -DMPI_ROOT=$HOME/apps/mpich \
  -DMPI_BASE_DIR=$HOME/apps/mpich \
  -DMPI_INCLUDE_PATH=$HOME/apps/mpich/include \
  -DMPI_C_INCLUDE_PATH=$HOME/apps/mpich/include \
  -DMPI_CXX_INCLUDE_PATH=$HOME/apps/mpich/include \
  -DMPI_INCLUDE_DIRS=$HOME/apps/mpich/include \
  -DMPI_C_INCLUDE_DIRS=$HOME/apps/mpich/include \
  -DMPI_CXX_INCLUDE_DIRS=$HOME/apps/mpich/include \
  -DMPI_HEADER_DIR=$HOME/apps/mpich/include \
  -DMPI_C_HEADER_DIR=$HOME/apps/mpich/include \
  -DMPI_CXX_HEADER_DIR=$HOME/apps/mpich/include \
  -DMPI_ADDITIONAL_INCLUDE_DIRS=$HOME/apps/mpich/include \
  -DMPI_C_ADDITIONAL_INCLUDE_DIRS=$HOME/apps/mpich/include \
  -DMPI_CXX_ADDITIONAL_INCLUDE_DIRS=$HOME/apps/mpich/include \
  -DMPI_LIBRARY=$HOME/apps/mpich/lib/libmpi.so \
  -DMPI_C_LIBRARY=$HOME/apps/mpich/lib/libmpi.so \
  -DMPI_CXX_LIBRARY=$HOME/apps/mpich/lib/libmpi.so \
  -DMPI_LIBRARIES=$HOME/apps/mpich/lib/libmpich.so \
  -DMPI_C_LIBRARIES=$HOME/apps/mpich/lib/libmpich.so \
  -DMPI_CXX_LIBRARIES=$HOME/apps/mpich/lib/libmpich.so \
  ~/src/hvtkm/linear_algebra/ 
  


-- 
John Biddiscombe,????????????????????????email:biddisco @.at.@ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre? | Tel:? +41 (91) 610.82.07
Via Trevano 131, 6900 Lugano, Switzerland?? | Fax:? +41 (91) 610.82.82


From kai.wolf at gmail.com  Sun Jan 21 05:16:22 2018
From: kai.wolf at gmail.com (Kai Wolf)
Date: Sun, 21 Jan 2018 11:16:22 +0100
Subject: [CMake] Concerning IDE support for superbuilds
Message-ID: <3A2439A9-C04D-42FF-87AF-CFDCC173548A@gmail.com>

Hi all,

a common approach for dealing with larger dependencies in a project is using a superbuild approach, where all dependencies get downloaded in a separate repository using ExternalProject_Add() and the actual project is included as a sub repository (e.g. using git submodules) and also build as an external project [1], [2], [3]. This is necessary since external projects don?t play well as a direct dependency for internal targets, as the external projects won?t be created and available until build time, whereas CMake needs some information already at configure time for creating a proper build system.

As discussed previously on this mailing list this approach has some significant drawbacks: Since the actual project is also build as an external project, CMake treats it as an external source respectively and IDE support is not available. One possible solution to this problem is to let the outer project generate a cache file which subsequently can be used in the actual project to configure all paths to the previously downloaded and built external dependencies:

    +----------------+
    |   Superbuild   |  ----> generates init-cache.cmake
    +----------------+

    +----------------+
    | actual project |  ----> uses: cmake -C init-cache.cmake
    +----------------+

However, this means we now need two steps to configure and build the actual project and also cannot easily maintain the external dependencies within one large project.

After thinking about this for a while I came up with the following hackish solution and would like to ask you, if you see any drawback in using this. Basically all I?m doing is to include the actual project first as a dummy external project and set the external projects as dependencies, thus they?ll get built beforehand and in the BUILD_COMMAND of the actual project I?m calling CMake to the project?s CMakeLists.txt again to trigger a reconfigure, writing a cache file and set a specific variable |project_deps_installed| which is used as an indicator in the CMakeLists. configuration to include the actual project via add_subdirectory(). For instance:

    CMakeLists.txt:
    option(BUILD_MYPROJECT ?Build the actual project? ON)
    if(BUILD_MYPROJECT)
      if(project_deps_installed)
        include(${CMAKE_CURRENT_BINARY_DIR}/init-cache.cmake)
        add_subdirectory(MyProject)
      else()
        include(External_project)
      endif()
    endif()

    External_project.cmake
    ExternalProject_Add(MyProject
      SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/MyProject
      BUILD_COMMAND ${CMAKE_COMMAND} -E chdir ${CMAKE_CURRENT_BINARY_DIR}
        ${CMAKE_COMMAND} ${CMAKE_CURRENT_SOURCE_DIR}
      INSTALL_COMMAND ?"
      DEPENDS ${external_deps})

    write_cmake_cache_file(?${cache_script}? ?${cache_args}?)
    set(project_deps_installed TRUE CACHE BOOL ??)

As a result, all external dependencies get build and installed via ExternalProject_Add() and the actual project is configured properly and included via add_subdirectory(), thus it can continue using find_package() as usual and will be pointed to the previously configured dependencies. So far, I haven?t found any downside to this and consider making this part of CMake itself, in case you don?t see any problems using this approach?


Thanks in advance for your input.


[1] https://github.com/OpenChemistry/openchemistry
[2] https://github.com/MITK/MITK
[3] https://github.com/SuperElastix/SuperElastix

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20180121/3d1d05cd/attachment.sig>

From craig.scott at crascit.com  Sun Jan 21 06:22:51 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Sun, 21 Jan 2018 22:22:51 +1100
Subject: [CMake] Concerning IDE support for superbuilds
In-Reply-To: <3A2439A9-C04D-42FF-87AF-CFDCC173548A@gmail.com>
References: <3A2439A9-C04D-42FF-87AF-CFDCC173548A@gmail.com>
Message-ID: <CA+dygY=0+AEo8=hYPKGv1oiU6+NiZ1KsYRBgOf4QsqY3adv_OA@mail.gmail.com>

Please excuse the brevity of this response, but a couple of links you may
want to read which may be somewhat related or provide further ideas for you:


   - The new FetchContent module
   <https://cmake.org/cmake/help/git-master/module/FetchContent.html> which
   is on master but not yet in any release. I expect it will be available in
   3.11.0 when it comes out. This offers an alternative way of incorporating
   dependencies in a way which will make them all appear directly in an IDE
   just like the rest of the project.
   - Invoking a nested build to provide something that can be used
   immediately in the main CMake run is discussed in this stackoverflow
   question and answer <https://stackoverflow.com/q/36084785/1938798> (by
   me). Pay special attention to the comments in the Updated section about
   what can happen if a CMake run is aborted/interrupted, leaving the main
   build trapped by the sub-build.



On Sun, Jan 21, 2018 at 9:16 PM, Kai Wolf <kai.wolf at gmail.com> wrote:

> Hi all,
>
> a common approach for dealing with larger dependencies in a project is
> using a superbuild approach, where all dependencies get downloaded in a
> separate repository using ExternalProject_Add() and the actual project is
> included as a sub repository (e.g. using git submodules) and also build as
> an external project [1], [2], [3]. This is necessary since external
> projects don?t play well as a direct dependency for internal targets, as
> the external projects won?t be created and available until build time,
> whereas CMake needs some information already at configure time for creating
> a proper build system.
>
> As discussed previously on this mailing list this approach has some
> significant drawbacks: Since the actual project is also build as an
> external project, CMake treats it as an external source respectively and
> IDE support is not available. One possible solution to this problem is to
> let the outer project generate a cache file which subsequently can be used
> in the actual project to configure all paths to the previously downloaded
> and built external dependencies:
>
>     +----------------+
>     |   Superbuild   |  ----> generates init-cache.cmake
>     +----------------+
>
>     +----------------+
>     | actual project |  ----> uses: cmake -C init-cache.cmake
>     +----------------+
>
> However, this means we now need two steps to configure and build the
> actual project and also cannot easily maintain the external dependencies
> within one large project.
>
> After thinking about this for a while I came up with the following hackish
> solution and would like to ask you, if you see any drawback in using this.
> Basically all I?m doing is to include the actual project first as a dummy
> external project and set the external projects as dependencies, thus
> they?ll get built beforehand and in the BUILD_COMMAND of the actual project
> I?m calling CMake to the project?s CMakeLists.txt again to trigger a
> reconfigure, writing a cache file and set a specific variable
> |project_deps_installed| which is used as an indicator in the CMakeLists.
> configuration to include the actual project via add_subdirectory(). For
> instance:
>
>     CMakeLists.txt:
>     option(BUILD_MYPROJECT ?Build the actual project? ON)
>     if(BUILD_MYPROJECT)
>       if(project_deps_installed)
>         include(${CMAKE_CURRENT_BINARY_DIR}/init-cache.cmake)
>         add_subdirectory(MyProject)
>       else()
>         include(External_project)
>       endif()
>     endif()
>
>     External_project.cmake
>     ExternalProject_Add(MyProject
>       SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/MyProject
>       BUILD_COMMAND ${CMAKE_COMMAND} -E chdir ${CMAKE_CURRENT_BINARY_DIR}
>         ${CMAKE_COMMAND} ${CMAKE_CURRENT_SOURCE_DIR}
>       INSTALL_COMMAND ?"
>       DEPENDS ${external_deps})
>
>     write_cmake_cache_file(?${cache_script}? ?${cache_args}?)
>     set(project_deps_installed TRUE CACHE BOOL ??)
>
> As a result, all external dependencies get build and installed via
> ExternalProject_Add() and the actual project is configured properly and
> included via add_subdirectory(), thus it can continue using find_package()
> as usual and will be pointed to the previously configured dependencies. So
> far, I haven?t found any downside to this and consider making this part of
> CMake itself, in case you don?t see any problems using this approach?
>
>
> Thanks in advance for your input.
>
>
> [1] https://github.com/OpenChemistry/openchemistry
> [2] https://github.com/MITK/MITK
> [3] https://github.com/SuperElastix/SuperElastix
>
>
> --
>
> 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
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180121/d255e90a/attachment.html>

From kai.wolf at gmail.com  Mon Jan 22 08:26:25 2018
From: kai.wolf at gmail.com (Kai Wolf)
Date: Mon, 22 Jan 2018 14:26:25 +0100
Subject: [CMake] How to include external (shared) library with several
 dlls/dylibs
Message-ID: <CAEOrzjo5Lxe9TkiecEd6tQGyPMDPQp+zX3_iG4KoMp_9ghPAGQ@mail.gmail.com>

Hi,

I need to integrate an externally built (shared) library as a logical
build target into my CMake configuration which consists of several
shared library files (dlls/dylibs).
Usually I'd do the following:

    find_path(MyLib_INCLUDE_DIR mylib.h HINTS ${MyLib_PATH}/include)
    find_library(MyLib_LIBRARY NAMES MyLib HINTS ${MyLib_PATH}/bin)
    find_library(MyLib_LIBRARY_DEBUG NAMES MyLib_d ${MyLib_PATH}/bin)

    include(FindPackageHandleStandardArgs)
    find_package_handle_standard_args(MyLib DEFAULT_MSG
      MyLib_LIBRARY MyLib_LIBRARY_DEBUG MyLib_INCLUDE_DIR)

    if(MyLib_FOUND AND NOT TARGET MyLib::MyLib)
      set(MyLib_LIBRARIES ${MyLib_LIBRARY})
      set(MyLib_INCLUDE_DIRS ${MyLib_INCLUDE_DIR})

      add_library(MyLib::MyLib UNKNOWN IMPORTED)
      set_target_properties(MyLib::MyLib PROPERTIES
        INTERFACE_INCLUDE_DIRECTORIES ${MyLib_INCLUDE_DIR}
        IMPORTED_LOCATION ${MyLib_LIBRARY}
        IMPORTED_LOCATION_DEBUG ${MyLib_LIBRARY_DEBUG})

        mark_as_advanced(MyLib_INCLUDE_DIR MyLib_LIBRARY MyLib_LIBRARY_DEBUG)
    endif()

My understanding is that add_library(... UNKOWN IMPORTED) will CMake
figure out shared/static libraries by itself (and based on the option
BUILD_SHARED_LIBS probably, but this shouldn't be necessary). However,
CMake doesn't allow to add a list of libraries to the property
IMPORTED_LOCATION. For Instance, in case I want to import MyLib,
MyLibFoo and MyLibBar both as debug and release builds, this is not
possible using the listed approach.

I'm aware of add_library(MyLib::MyLib INTERFACE IMPORTED) and set a
list of libraries to the property INTERFACE_LINK_LIBRARIES, but this
is problematic in the case of creating relocatable packages (as
mentioned in the CMake documentation). Furthermore, there's no such
property as INTERFACE_LINK_LIBRARIES_DEBUG, thus it would only be
possible to refer to either the release or debug builds of my
externally imported library.

So, how am I supposed to import my externally built library as an
relocatable-ready logical CMake target which actually includes several
either debug or release build shared library files?

Thanks in advance.

From mailsik at gmail.com  Mon Jan 22 10:16:50 2018
From: mailsik at gmail.com (Sik)
Date: Mon, 22 Jan 2018 15:16:50 +0000
Subject: [CMake] [cmake] [RFC] rewriting FindMKL
In-Reply-To: <CA+7QG_OSkbt90mfR=KtaUc0mPxD2CD7NSc97qULFsyd+UsG_Xw@mail.gmail.com>
References: <CA+7QG_OSkbt90mfR=KtaUc0mPxD2CD7NSc97qULFsyd+UsG_Xw@mail.gmail.com>
Message-ID: <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>

Hello CMake users and devs,

In openmeeg we are reviewing our MKL package finder to make it more
maintainable for ourselves and others who had adopted our solution.
Therefore I'm writing you requesting comments and feedback so that is
useful for everyone.

Here is the project we have set up in order to test it. It has a simple
example using MKL and CI for different scenarios.

https://github.com/openmeeg/findmkl_cmake

Thx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180122/5f53be10/attachment.html>

From sean at rogue-research.com  Mon Jan 22 11:33:59 2018
From: sean at rogue-research.com (Sean McBride)
Date: Mon, 22 Jan 2018 11:33:59 -0500
Subject: [CMake] Recommandation for macOS framework install rules
In-Reply-To: <17CE0013-D542-4782-ABEE-305693D8E37F@orange.fr>
References: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
 <17CE0013-D542-4782-ABEE-305693D8E37F@orange.fr>
Message-ID: <20180122163359.2083293862@mail.rogue-research.com>

On macOS, the most usual thing is for your code to be self-contained in your .app bundle.  Perhaps if you described more what kind of thing you are building and why you don't want to do the usual thing, people will have more advice...


On Fri, 19 Jan 2018 19:44:03 +0100, Lucas Soltic said:

>Hello,
>Should I conclude that there are no recommendations?
>
>Best regards,
>Lucas
>
>> Le 17 janv. 2018 ? 23:49, Lucas Soltic <lucas.soltic at orange.fr> a ?crit :
>> 
>> Hello,
>> 
>> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/
>local by default) as a base for relative install paths. But when you
>define install rules for macOS frameworks, it doesn't make much sense to
>install them there. I'd rather expect something like /Library/Frameworks.
>> 
>> On the other side, if you have more things to install like a "readme"
>or documentation that should go into /usr/local/share, it doesn't make
>sense to have them installed in /Library/Frameworks. So you can't just
>change CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
>> 
>> What do you recommend to keep installation rules simple (ie. remain
>relative) and yet support installation of both frameworks and other things?



From lucas.soltic at orange.fr  Mon Jan 22 12:49:40 2018
From: lucas.soltic at orange.fr (Lucas Soltic)
Date: Mon, 22 Jan 2018 18:49:40 +0100
Subject: [CMake] Recommandation for macOS framework install rules
In-Reply-To: <CAA2GJqUgxOCr0kAtmVhy_qGN0JZZ=doLPMUW5dt0SMrFqUuVjw@mail.gmail.com>
References: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
 <17CE0013-D542-4782-ABEE-305693D8E37F@orange.fr>
 <CAA2GJqUgxOCr0kAtmVhy_qGN0JZZ=doLPMUW5dt0SMrFqUuVjw@mail.gmail.com>
Message-ID: <1258A337-FF05-4E5C-B346-3F089BCB1BEE@orange.fr>



> Le 19 janv. 2018 ? 20:01, J Decker <d3ck0r at gmail.com> a ?crit :
> 
> 
> 
>> On Fri, Jan 19, 2018 at 10:44 AM, Lucas Soltic <lucas.soltic at orange.fr> wrote:
>> Hello,
>> Should I conclude that there are no recommendations?
>> 
> I would think if there were platform exceptions they would be modifications to this... 
> 
> https://apimirror.com/cmake~3.8/module/gnuinstalldirs

Thanks for your time :) I didn?t find anything related to frameworks there. But I don?t expect GNU-related page to contain anything specific to macOS. Nice documentation website though, didn?t know about it.

I also did a grep in CMake modules but didn?t find anything close to a framework install prefix.

>> Best regards,
>> Lucas
>> 
>> > Le 17 janv. 2018 ? 23:49, Lucas Soltic <lucas.soltic at orange.fr> a ?crit :
>> >
>> > Hello,
>> >
>> > By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local by default) as a base for relative install paths. But when you define install rules for macOS frameworks, it doesn't make much sense to install them there. I'd rather expect something like /Library/Frameworks.
>> >
>> > On the other side, if you have more things to install like a "readme" or documentation that should go into /usr/local/share, it doesn't make sense to have them installed in /Library/Frameworks. So you can't just change CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
>> >
>> > What do you recommend to keep installation rules simple (ie. remain relative) and yet support installation of both frameworks and other things?
>> >
>> > Best regards,
>> > Lucas
>> > --
>> >
>> > 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180122/fb9d5da5/attachment.html>

From lucas.soltic at orange.fr  Mon Jan 22 13:27:07 2018
From: lucas.soltic at orange.fr (Lucas Soltic)
Date: Mon, 22 Jan 2018 19:27:07 +0100
Subject: [CMake] Recommandation for macOS framework install rules
In-Reply-To: <20180122163359.2083293862@mail.rogue-research.com>
References: <6442A9BC-41BE-41BC-8C32-0D43CDCB9FC8@orange.fr>
 <17CE0013-D542-4782-ABEE-305693D8E37F@orange.fr>
 <20180122163359.2083293862@mail.rogue-research.com>
Message-ID: <063E347D-7FB8-4E0F-B3E6-A06472954B62@orange.fr>

Hello,

The product is a cross-platform API that relies on CMake for the config part. We ship static and dynamic libraries for Linux, Windows and macOS. Additionally on macOS we want to provide frameworks to ease integration (headers and a few dependencies in the bundle framework, etc). In addition to the libraries, with also ship documentation, sample codes, etc.

When we ship we do a manual packaging of the files for now. We also have install rules if a user executes the install target from his own build of the product.

And by default as CMake also installs frameworks relatively to CMAKE_INSTALL_PREFIX, they get installed in /usr/local or one of its subdirectories. This might be ok for all the other files to install but not for frameworks, as documented on https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html <https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html>

Also I don't want to specify an absolute path in the install rule of the frameworks, because we generate a <Project>Config.cmake file and giving an absolute path to install() command makes the generated config non-relocatable. It doesn't look to be documented in https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages <https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages> but that's what I noticed.

Finally as we don't ship a .app bundle, we can't install our stuff in it. I hope it's clearer, please tell me if you still miss information.

Best regards,
Lucas

> Le 22 janv. 2018 ? 17:33, Sean McBride <sean at rogue-research.com> a ?crit :
> 
> On macOS, the most usual thing is for your code to be self-contained in your .app bundle.  Perhaps if you described more what kind of thing you are building and why you don't want to do the usual thing, people will have more advice...
> 
> 
> On Fri, 19 Jan 2018 19:44:03 +0100, Lucas Soltic said:
> 
>> Hello,
>> Should I conclude that there are no recommendations?
>> 
>> Best regards,
>> Lucas
>> 
>>> Le 17 janv. 2018 ? 23:49, Lucas Soltic <lucas.soltic at orange.fr> a ?crit :
>>> 
>>> Hello,
>>> 
>>> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/
>> local by default) as a base for relative install paths. But when you
>> define install rules for macOS frameworks, it doesn't make much sense to
>> install them there. I'd rather expect something like /Library/Frameworks.
>>> 
>>> On the other side, if you have more things to install like a "readme"
>> or documentation that should go into /usr/local/share, it doesn't make
>> sense to have them installed in /Library/Frameworks. So you can't just
>> change CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
>>> 
>>> What do you recommend to keep installation rules simple (ie. remain
>> relative) and yet support installation of both frameworks and other things?
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180122/35ef77f3/attachment.html>

From neundorf at kde.org  Mon Jan 22 16:20:52 2018
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 22 Jan 2018 22:20:52 +0100
Subject: [CMake] [cmake] [RFC] rewriting FindMKL
In-Reply-To: <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>
References: <CA+7QG_OSkbt90mfR=KtaUc0mPxD2CD7NSc97qULFsyd+UsG_Xw@mail.gmail.com>
 <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>
Message-ID: <3023311.aPJettor5r@linux-l7nd>

On 2018 M01 22, Mon 15:16:50 CET Sik wrote:
> Hello CMake users and devs,
> 
> In openmeeg we are reviewing our MKL package finder to make it more
> maintainable for ourselves and others who had adopted our solution.
> Therefore I'm writing you requesting comments and feedback so that is
> useful for everyone.
> 
> Here is the project we have set up in order to test it. It has a simple
> example using MKL and CI for different scenarios.
> 
> https://github.com/openmeeg/findmkl_cmake

that's quite a lot of stuff, I'll try to test itin the next days.

Just a few quick comments:

The MESSAGE() in line 39 is ALL_UPPERCASE.

MKL_ROOT_DIR from line 31 is put into the cache, reusing the same variable 
name in line 35 probably works, but the interaction between cache- and non-
cache variables is somewhat complicated, so I would recommend to use different 
names.

When searching mkl_cblas.h in line 31, in case the Intel compiler is used, the 
install directory of CMAKE_CXX_COMPILER could be used in some way as a hint to 
help finding MKL.

I don't like the error message in line 39, I usually prefer using 
CMAKE_PREFIX_PATH.

Lines 87 to 95 are not correctly indented, also lines 105 to 112.

Is BLA_STATIC in line 117 correct, or is this a typo ?

Alex


From kai.wolf at gmail.com  Tue Jan 23 04:40:45 2018
From: kai.wolf at gmail.com (Kai Wolf)
Date: Tue, 23 Jan 2018 10:40:45 +0100
Subject: [CMake] [cmake] [RFC] rewriting FindMKL
In-Reply-To: <3023311.aPJettor5r@linux-l7nd>
References: <CA+7QG_OSkbt90mfR=KtaUc0mPxD2CD7NSc97qULFsyd+UsG_Xw@mail.gmail.com>
 <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>
 <3023311.aPJettor5r@linux-l7nd>
Message-ID: <CAEOrzjpev9sESFHTPpQkFr2j1ME47gDwB99zb-LTkeSDAG_Scg@mail.gmail.com>

I've fixed some (mentioned) issues already and opened up a PR on
GitHub. You might want to check that out, otherwise I'll just delete
my PR.


2018-01-22 22:20 GMT+01:00 Alexander Neundorf <neundorf at kde.org>:
> On 2018 M01 22, Mon 15:16:50 CET Sik wrote:
>> Hello CMake users and devs,
>>
>> In openmeeg we are reviewing our MKL package finder to make it more
>> maintainable for ourselves and others who had adopted our solution.
>> Therefore I'm writing you requesting comments and feedback so that is
>> useful for everyone.
>>
>> Here is the project we have set up in order to test it. It has a simple
>> example using MKL and CI for different scenarios.
>>
>> https://github.com/openmeeg/findmkl_cmake
>
> that's quite a lot of stuff, I'll try to test itin the next days.
>
> Just a few quick comments:
>
> The MESSAGE() in line 39 is ALL_UPPERCASE.
>
> MKL_ROOT_DIR from line 31 is put into the cache, reusing the same variable
> name in line 35 probably works, but the interaction between cache- and non-
> cache variables is somewhat complicated, so I would recommend to use different
> names.
>
> When searching mkl_cblas.h in line 31, in case the Intel compiler is used, the
> install directory of CMAKE_CXX_COMPILER could be used in some way as a hint to
> help finding MKL.
>
> I don't like the error message in line 39, I usually prefer using
> CMAKE_PREFIX_PATH.
>
> Lines 87 to 95 are not correctly indented, also lines 105 to 112.
>
> Is BLA_STATIC in line 117 correct, or is this a typo ?
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From julius.caro at gmail.com  Tue Jan 23 05:25:07 2018
From: julius.caro at gmail.com (Luis Caro Campos)
Date: Tue, 23 Jan 2018 10:25:07 +0000
Subject: [CMake] [cmake] [RFC] rewriting FindMKL
In-Reply-To: <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>
References: <CA+7QG_OSkbt90mfR=KtaUc0mPxD2CD7NSc97qULFsyd+UsG_Xw@mail.gmail.com>
 <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>
Message-ID: <CANjb7DrwoLz47Uqv4fnwct91uoEXLe1dFm5zuk3L8MVYSgq7+w@mail.gmail.com>

As a comment, would it be possible to include imported targets that
encapsulate include dirs, linker arguments and compile definitions? I would
say the CMake community is trying to move away from the old-style find
packages that define variables instead of targets.

Regards,
Luis

On Mon, Jan 22, 2018 at 3:16 PM, Sik <mailsik at gmail.com> wrote:

> Hello CMake users and devs,
>
> In openmeeg we are reviewing our MKL package finder to make it more
> maintainable for ourselves and others who had adopted our solution.
> Therefore I'm writing you requesting comments and feedback so that is
> useful for everyone.
>
> Here is the project we have set up in order to test it. It has a simple
> example using MKL and CI for different scenarios.
>
> https://github.com/openmeeg/findmkl_cmake
>
> Thx
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180123/7f8a150d/attachment-0001.html>

From mailsik at gmail.com  Tue Jan 23 11:24:52 2018
From: mailsik at gmail.com (Sik)
Date: Tue, 23 Jan 2018 16:24:52 +0000
Subject: [CMake] [cmake] [RFC] rewriting FindMKL
In-Reply-To: <CANjb7DrwoLz47Uqv4fnwct91uoEXLe1dFm5zuk3L8MVYSgq7+w@mail.gmail.com>
References: <CA+7QG_OSkbt90mfR=KtaUc0mPxD2CD7NSc97qULFsyd+UsG_Xw@mail.gmail.com>
 <CA+7QG_NfJ36tCefGYiBre8DrUouTDkiARCvCZ9c9wDwNUsoGYg@mail.gmail.com>
 <CANjb7DrwoLz47Uqv4fnwct91uoEXLe1dFm5zuk3L8MVYSgq7+w@mail.gmail.com>
Message-ID: <CA+7QG_Pfm-3vDdm0Qv+QELKNNpPKFCeo1TBDQmxhhdc6SB2fVg@mail.gmail.com>

I made a PR based on your comment, is this what you were referring to?
https://github.com/openmeeg/findmkl_cmake/pull/8


On Tue, Jan 23, 2018 at 11:25 AM Luis Caro Campos <julius.caro at gmail.com>
wrote:

> As a comment, would it be possible to include imported targets that
> encapsulate include dirs, linker arguments and compile definitions? I would
> say the CMake community is trying to move away from the old-style find
> packages that define variables instead of targets.
>
> Regards,
> Luis
>
> On Mon, Jan 22, 2018 at 3:16 PM, Sik <mailsik at gmail.com> wrote:
>
>> Hello CMake users and devs,
>>
>> In openmeeg we are reviewing our MKL package finder to make it more
>> maintainable for ourselves and others who had adopted our solution.
>> Therefore I'm writing you requesting comments and feedback so that is
>> useful for everyone.
>>
>> Here is the project we have set up in order to test it. It has a simple
>> example using MKL and CI for different scenarios.
>>
>> https://github.com/openmeeg/findmkl_cmake
>>
>> Thx
>>
>> --
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180123/5047d2da/attachment.html>

From rcdailey.lists at gmail.com  Tue Jan 23 12:27:36 2018
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 23 Jan 2018 11:27:36 -0600
Subject: [CMake] Confusion with range-based FOREACH logic
Message-ID: <CAHd499DQWoLs1RtTBSWFZXhLUUh2tQf+ukLgSutAQTk8xFqK8w@mail.gmail.com>

I am doing the following:

```
set( CS_THIRD_PARTY_REFERENCES
    Iconic.Zip ${CMAKE_CURRENT_SOURCE_DIR}/DotNetZip/Iconic.Zip.dll
)

if( CS_THIRD_PARTY_REFERENCES )
    list( LENGTH CS_THIRD_PARTY_REFERENCES len )
    message( STATUS "len: ${len}" )
    foreach( i RANGE 0 ${len} 2 )
        message( STATUS "i: ${i}" )
        list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_name )
        math( EXPR i "${i}+1" )
        list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_path )
        set_property( TARGET ${target_name} PROPERTY
            VS_DOTNET_REFERENCE_${assembly_name} ${assembly_path}
        )
        message( STATUS "i: ${i}" )
        message( STATUS "assembly_name: ${assembly_name}" )
        message( STATUS "assembly_path: ${assembly_path}" )
    endforeach()
endif()
```

I am finding that the foreach() loops 2 times when ${len} is 2. What I
expect during the 2nd iteration is that it does ${i}+STEP (0+2) which
would equal 2, and so long as 2<${len} (2<2), then it would continue
to iterate. In this case, it should stop after the first iteration.
I'm thinking that this should work like a C++ for loop. Is this not
the case? How should I be iterating over a list of 2 times at a time?

From budikusasi at gmail.com  Tue Jan 23 23:22:17 2018
From: budikusasi at gmail.com (Budi)
Date: Wed, 24 Jan 2018 11:22:17 +0700
Subject: [CMake] (no subject)
Message-ID: <CAH0GyZBt+boVBguPp9v6MkozkpKBgR_XMo0JFb6+Nuwygu7f7w@mail.gmail.com>

How to set up  environment to bulid along with CPPAN ( I want to build
tesseract)

From niels_dekker_address_until_2024 at xs4all.nl  Wed Jan 24 15:06:09 2018
From: niels_dekker_address_until_2024 at xs4all.nl (Niels Dekker)
Date: Wed, 24 Jan 2018 21:06:09 +0100
Subject: [CMake] Link Time Code Generation (LTGC) by default,
 for Release configurations of Visual Studio projects?
Message-ID: <d181a5231af0ec0d144f98b2ccad0671@xs4all.nl>

When a Visual C++ project is created within Visual Studio (by File menu, 
New, Project...), it has Link Time Code Generation (LTGC) by default, 
for its Release configurations: Compiler option /GL and linker option 
/LTCG. However, when the Visual C++ project is generated by CMake, it 
does not have LTGC, by default. LTCG looks like a very useful feature to 
me. I think it's worth enabling the feature by default, for Release 
configurations. What do you think?


Some details:

I created a "dummy" Visual C++ project in Visual Studio 2017 (Version 
15.5.4), by File menu, New, Project..., and I also generated one by 
CMake (version 3.10.2), using a very minimal CMakeLists.txt

The Visual C++ project created by Visual Studio 2017 has the following 
compile options, by default, for Release (x64):

/permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl 
/Fd"x64\Release\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS" 
/errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" 
/EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\MyVS2015Project.pch" 
/diagnostics:classic

And the following linker options:

/OUT:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.exe" 
/MANIFEST /LTCG:incremental /NXCOMPAT 
/PDB:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pdb" 
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" 
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" 
"uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FULL /MACHINE:X64 /OPT:REF 
/PGD:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pgd" 
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
/ManifestFile:"x64\Release\MyVS2015Project.exe.intermediate.manifest" 
/OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

The vcxproj file created by Visual Studio has 
"<WholeProgramOptimization>true</WholeProgramOptimization>" for its 
Release configurations.


The Visual C++ project generated by CMake (Generator: Visual Studio 15 
2017 Win64) has the following compile options, for its Release 
configuration:

/GS /TP /W3 /Zc:wchar_t /Gm- /O2 /Ob2 
/Fd"MyExecutable.dir\Release\vc141.pdb" /Zc:inline /fp:precise /D 
"WIN32" /D "_WINDOWS" /D "NDEBUG" /D "CMAKE_INTDIR=\"Release\"" /D 
"_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /Fa"Release/" 
/EHsc /nologo /Fo"MyExecutable.dir\Release\" 
/Fp"MyExecutable.dir\Release\MyExecutable.pch" /diagnostics:classic

And the following linker options:

/OUT:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.exe" /MANIFEST 
/NXCOMPAT /PDB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.pdb" 
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" 
"shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" 
"advapi32.lib" 
/IMPLIB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.lib" 
/MACHINE:X64 /INCREMENTAL:NO 
/PGD:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.pgd" 
/SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
/ManifestFile:"MyExecutable.dir\Release\MyExecutable.exe.intermediate.manifest" 
/ERRORREPORT:PROMPT /NOLOGO /TLBID:1

The vcxproj file generated by CMake does not have a 
"<WholeProgramOptimization>" tag.


I hope you can consider adding LTCG to Release configurations of Visual 
C++ projects generated by CMake, by default.


Kind regards, Niels
-- 
Niels Dekker
Scientific programmer
LKEB, Leiden University Medical Center

From cristian.adam at gmail.com  Wed Jan 24 15:42:23 2018
From: cristian.adam at gmail.com (Cristian Adam)
Date: Wed, 24 Jan 2018 21:42:23 +0100
Subject: [CMake] Link Time Code Generation (LTGC) by default,
 for Release configurations of Visual Studio projects?
In-Reply-To: <d181a5231af0ec0d144f98b2ccad0671@xs4all.nl>
References: <d181a5231af0ec0d144f98b2ccad0671@xs4all.nl>
Message-ID: <CA+u+m-L88tHW3Zw5xV5X-ecSp0yXp0VQx3pHkPdzSUCWDC=8AQ@mail.gmail.com>

Hi,

I had a quick check to see if CMake 3.10 for which compilers it has support
for Interprocedural Optimization
<https://cmake.org/cmake/help/v3.10/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html#prop_tgt:INTERPROCEDURAL_OPTIMIZATION>
(IPO, or LTCG as known on Visual C++).

Modules/Compiler had only for *GNU*, *Clang* and *PGI* the following:
set(_CMAKE_${lang}_IPO_MAY_BE_SUPPORTED_BY_COMPILER YES)

QNX with QCC didn't have it set to YES even though nowdays QNX comes with
GCC 5.4.0 on QNX 7.0, which should be just fine.

It would be nice if CMake would have support for IPO on Visual C++.

The steps would be to set the right variables into
Modules/Compiler/MSVC-CXX.cmake, change the CheckIPOSupported
<https://cmake.org/cmake/help/v3.10/module/CheckIPOSupported.html?#module:CheckIPOSupported>
module, change some flags in some places,update tests, documentation, and
so on.

Shouldn't be hard to add this feature.

Cheers,
Cristian.



On Wed, Jan 24, 2018 at 9:06 PM, Niels Dekker <
niels_dekker_address_until_2024 at xs4all.nl> wrote:

> When a Visual C++ project is created within Visual Studio (by File menu,
> New, Project...), it has Link Time Code Generation (LTGC) by default, for
> its Release configurations: Compiler option /GL and linker option /LTCG.
> However, when the Visual C++ project is generated by CMake, it does not
> have LTGC, by default. LTCG looks like a very useful feature to me. I think
> it's worth enabling the feature by default, for Release configurations.
> What do you think?
>
>
> Some details:
>
> I created a "dummy" Visual C++ project in Visual Studio 2017 (Version
> 15.5.4), by File menu, New, Project..., and I also generated one by CMake
> (version 3.10.2), using a very minimal CMakeLists.txt
>
> The Visual C++ project created by Visual Studio 2017 has the following
> compile options, by default, for Release (x64):
>
> /permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl
> /Fd"x64\Release\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS"
> /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc
> /nologo /Fo"x64\Release\" /Fp"x64\Release\MyVS2015Project.pch"
> /diagnostics:classic
>
> And the following linker options:
>
> /OUT:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.exe"
> /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"F:\X\Src\MyProject\MyVS2
> 015Project\x64\Release\MyVS2015Project.pdb" /DYNAMICBASE "kernel32.lib"
> "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib"
> "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib"
> "odbccp32.lib" /DEBUG:FULL /MACHINE:X64 /OPT:REF
> /PGD:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pgd"
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
> /ManifestFile:"x64\Release\MyVS2015Project.exe.intermediate.manifest"
> /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
>
> The vcxproj file created by Visual Studio has
> "<WholeProgramOptimization>true</WholeProgramOptimization>" for its
> Release configurations.
>
>
> The Visual C++ project generated by CMake (Generator: Visual Studio 15
> 2017 Win64) has the following compile options, for its Release
> configuration:
>
> /GS /TP /W3 /Zc:wchar_t /Gm- /O2 /Ob2 /Fd"MyExecutable.dir\Release\vc141.pdb"
> /Zc:inline /fp:precise /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D
> "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope
> /GR /Gd /MD /Fa"Release/" /EHsc /nologo /Fo"MyExecutable.dir\Release\"
> /Fp"MyExecutable.dir\Release\MyExecutable.pch" /diagnostics:classic
>
> And the following linker options:
>
> /OUT:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.exe" /MANIFEST
> /NXCOMPAT /PDB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.pdb"
> /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
> "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib"
> "advapi32.lib" /IMPLIB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.lib"
> /MACHINE:X64 /INCREMENTAL:NO /PGD:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.pgd"
> /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
> /ManifestFile:"MyExecutable.dir\Release\MyExecutable.exe.intermediate.manifest"
> /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
>
> The vcxproj file generated by CMake does not have a
> "<WholeProgramOptimization>" tag.
>
>
> I hope you can consider adding LTCG to Release configurations of Visual
> C++ projects generated by CMake, by default.
>
>
> Kind regards, Niels
> --
> Niels Dekker
> Scientific programmer
> LKEB, Leiden University Medical Center
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180124/89e69ed4/attachment.html>

From scott at towel42.com  Wed Jan 24 16:25:37 2018
From: scott at towel42.com (Scott Bloom)
Date: Wed, 24 Jan 2018 21:25:37 +0000
Subject: [CMake] compile_pdb_name example
Message-ID: <CY1PR10MB09811B228C975C99DEEDEB5DA9E20@CY1PR10MB0981.namprd10.prod.outlook.com>

Does anyone have an example of COMPILE_PDB_NAME and how to set it?

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180124/9fdbe49e/attachment.html>

From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de  Thu Jan 25 08:54:14 2018
From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian)
Date: Thu, 25 Jan 2018 13:54:14 +0000
Subject: [CMake] Link Time Code Generation (LTGC) by default,
 for Release configurations of Visual Studio projects?
In-Reply-To: <CA+u+m-L88tHW3Zw5xV5X-ecSp0yXp0VQx3pHkPdzSUCWDC=8AQ@mail.gmail.com>
References: <d181a5231af0ec0d144f98b2ccad0671@xs4all.nl>
 <CA+u+m-L88tHW3Zw5xV5X-ecSp0yXp0VQx3pHkPdzSUCWDC=8AQ@mail.gmail.com>
Message-ID: <8D981219EEA621479C112DA9BDC39A8E8B912663@EXMBS1.ad.igd.fraunhofer.de>

This would be a great feature! Currently I override my release flags by setting CMAKE_<LANG>_FLAGS_RELEASE_INIT and CMAKE_<TYPE>_LINKER_FLAGS_RELEASE_INIT in a CMAKE_USER_MAKE_RULES_OVERRIDE script. Direct support for /GL and /LTCG in CMake would be great. Fewer target specifics to worry about?

Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de<mailto:johannes.mueller-roemer at igd.fraunhofer.de> | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Cristian Adam
Sent: Wednesday, January 24, 2018 21:42
To: Niels Dekker <niels_dekker_address_until_2024 at xs4all.nl>
Cc: cmake <cmake at cmake.org>
Subject: Re: [CMake] Link Time Code Generation (LTGC) by default, for Release configurations of Visual Studio projects?

Hi,

I had a quick check to see if CMake 3.10 for which compilers it has support for Interprocedural Optimization<https://cmake.org/cmake/help/v3.10/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html#prop_tgt:INTERPROCEDURAL_OPTIMIZATION> (IPO, or LTCG as known on Visual C++).

Modules/Compiler had only for GNU, Clang and PGI the following:
set(_CMAKE_${lang}_IPO_MAY_BE_SUPPORTED_BY_COMPILER YES)

QNX with QCC didn't have it set to YES even though nowdays QNX comes with GCC 5.4.0 on QNX 7.0, which should be just fine.

It would be nice if CMake would have support for IPO on Visual C++.

The steps would be to set the right variables into Modules/Compiler/MSVC-CXX.cmake, change the CheckIPOSupported<https://cmake.org/cmake/help/v3.10/module/CheckIPOSupported.html?#module:CheckIPOSupported> module, change some flags in some places,update tests, documentation, and so on.

Shouldn't be hard to add this feature.

Cheers,
Cristian.



On Wed, Jan 24, 2018 at 9:06 PM, Niels Dekker <niels_dekker_address_until_2024 at xs4all.nl<mailto:niels_dekker_address_until_2024 at xs4all.nl>> wrote:
When a Visual C++ project is created within Visual Studio (by File menu, New, Project...), it has Link Time Code Generation (LTGC) by default, for its Release configurations: Compiler option /GL and linker option /LTCG. However, when the Visual C++ project is generated by CMake, it does not have LTGC, by default. LTCG looks like a very useful feature to me. I think it's worth enabling the feature by default, for Release configurations. What do you think?


Some details:

I created a "dummy" Visual C++ project in Visual Studio 2017 (Version 15.5.4), by File menu, New, Project..., and I also generated one by CMake (version 3.10.2), using a very minimal CMakeLists.txt

The Visual C++ project created by Visual Studio 2017 has the following compile options, by default, for Release (x64):

/permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\MyVS2015Project.pch" /diagnostics:classic

And the following linker options:

/OUT:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.exe" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FULL /MACHINE:X64 /OPT:REF /PGD:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pgd" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\MyVS2015Project.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

The vcxproj file created by Visual Studio has "<WholeProgramOptimization>true</WholeProgramOptimization>" for its Release configurations.


The Visual C++ project generated by CMake (Generator: Visual Studio 15 2017 Win64) has the following compile options, for its Release configuration:

/GS /TP /W3 /Zc:wchar_t /Gm- /O2 /Ob2 /Fd"MyExecutable.dir\Release\vc141.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /Fa"Release/" /EHsc /nologo /Fo"MyExecutable.dir\Release\" /Fp"MyExecutable.dir\Release\MyExecutable.pch" /diagnostics:classic

And the following linker options:

/OUT:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.exe" /MANIFEST /NXCOMPAT /PDB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" /IMPLIB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.lib" /MACHINE:X64 /INCREMENTAL:NO /PGD:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"MyExecutable.dir\Release\MyExecutable.exe.int<http://MyExecutable.exe.int>ermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

The vcxproj file generated by CMake does not have a "<WholeProgramOptimization>" tag.


I hope you can consider adding LTCG to Release configurations of Visual C++ projects generated by CMake, by default.


Kind regards, Niels
--
Niels Dekker
Scientific programmer
LKEB, Leiden University Medical Center
--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180125/7362408b/attachment-0001.html>

From niels_dekker_address_until_2024 at xs4all.nl  Fri Jan 26 11:04:52 2018
From: niels_dekker_address_until_2024 at xs4all.nl (Niels Dekker)
Date: Fri, 26 Jan 2018 17:04:52 +0100
Subject: [CMake] Link Time Code Generation (LTGC) by default,
 for Release configurations of Visual Studio projects?
In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E8B912663@EXMBS1.ad.igd.fraunhofer.de>
References: <d181a5231af0ec0d144f98b2ccad0671@xs4all.nl>
 <CA+u+m-L88tHW3Zw5xV5X-ecSp0yXp0VQx3pHkPdzSUCWDC=8AQ@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E8B912663@EXMBS1.ad.igd.fraunhofer.de>
Message-ID: <3dc85ea5a558f6e98a6b1106ac350d6e@xs4all.nl>

Thank you for your encouraging replies, Johannes and Cristian.

In the meantime I created "default" Visual C++ projects on Visual Studio 
2008, Visual Studio 2010, Visual Studio 2013, Visual Studio 2015 and 
Visual Studio 2017 (from within the IDE, without using CMake). It 
appears that each of these Visual Studio versions hast Link Time Code 
Generation by default, for Release configurations.

I don't have access to a machine with Visual Studio 2005. Can someone 
tell me whether this version also has Link Time Code Generation by 
default, for Release configurations?

Kind regards, Niels


On 2018-01-25 14:54, Mueller-Roemer, Johannes Sebastian wrote:
> This would be a great feature! Currently I override my release flags
> by setting CMAKE_<LANG>_FLAGS_RELEASE_INIT and
> CMAKE_<TYPE>_LINKER_FLAGS_RELEASE_INIT in a
> CMAKE_USER_MAKE_RULES_OVERRIDE script. Direct support for /GL and
> /LTCG in CMake would be great. Fewer target specifics to worry
> about?
> 
> 
> FROM: Cristian Adam
> SENT: Wednesday, January 24, 2018 21:42
> TO: Niels Dekker
> CC: cmake <cmake at cmake.org>
> SUBJECT: Re: [CMake] Link Time Code Generation (LTGC) by default, for
> Release configurations of Visual Studio projects?
> 
> Hi,
> 
> I had a quick check to see if CMake 3.10 for which compilers it has
> support for Interprocedural Optimization  (IPO, or LTCG as known on
> Visual C++).
> 
> Modules/Compiler had only for GNU, CLANG and PGI the following:
> 
> set(_CMAKE_${lang}_IPO_MAY_BE_SUPPORTED_BY_COMPILER YES)
> 
> QNX with QCC didn't have it set to YES even though nowdays QNX comes
> with GCC 5.4.0 on QNX 7.0, which should be just fine.
> 
> It would be nice if CMake would have support for IPO on Visual C++.
> 
> The steps would be to set the right variables into
> Modules/Compiler/MSVC-CXX.cmake, change the CheckIPOSupported
> module, change some flags in some places,update tests, documentation,
> and so on.
> 
> Shouldn't be hard to add this feature.
> 
> Cheers,
> 
> Cristian.
> 
> On Wed, Jan 24, 2018 at 9:06 PM, Niels Dekker wrote:
> 
>> When a Visual C++ project is created within Visual Studio (by File
>> menu, New, Project...), it has Link Time Code Generation (LTGC) by
>> default, for its Release configurations: Compiler option /GL and
>> linker option /LTCG. However, when the Visual C++ project is
>> generated by CMake, it does not have LTGC, by default. LTCG looks
>> like a very useful feature to me. I think it's worth enabling the
>> feature by default, for Release configurations. What do you think?
>> 
>> Some details:
>> 
>> I created a "dummy" Visual C++ project in Visual Studio 2017
>> (Version 15.5.4), by File menu, New, Project..., and I also
>> generated one by CMake (version 3.10.2), using a very minimal
>> CMakeLists.txt
>> 
>> The Visual C++ project created by Visual Studio 2017 has the
>> following compile options, by default, for Release (x64):
>> 
>> /permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl
>> /Fd"x64\Release\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS"
>> /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\"
>> /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\MyVS2015Project.pch"
>> /diagnostics:classic
>> 
>> And the following linker options:
>> 
>> 
> /OUT:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.exe"
>> /MANIFEST /LTCG:incremental /NXCOMPAT
>> 
> /PDB:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pdb"
>> /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
>> "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib"
>> "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FULL
>> /MACHINE:X64 /OPT:REF
>> 
> /PGD:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pgd"
>> /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
>> 
> /ManifestFile:"x64\Release\MyVS2015Project.exe.intermediate.manifest"
>> /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
>> 
>> The vcxproj file created by Visual Studio has
>> "<WholeProgramOptimization>true</WholeProgramOptimization>" for its
>> Release configurations.
>> 
>> The Visual C++ project generated by CMake (Generator: Visual Studio
>> 15 2017 Win64) has the following compile options, for its Release
>> configuration:
>> 
>> /GS /TP /W3 /Zc:wchar_t /Gm- /O2 /Ob2
>> /Fd"MyExecutable.dir\Release\vc141.pdb" /Zc:inline /fp:precise /D
>> "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "CMAKE_INTDIR=\"Release\"" /D
>> "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD
>> /Fa"Release/" /EHsc /nologo /Fo"MyExecutable.dir\Release\"
>> /Fp"MyExecutable.dir\Release\MyExecutable.pch" /diagnostics:classic
>> 
>> And the following linker options:
>> 
>> /OUT:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.exe"
>> /MANIFEST /NXCOMPAT
>> /PDB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.pdb"
>> /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
>> "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib"
>> "advapi32.lib"
>> /IMPLIB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.lib"
>> /MACHINE:X64 /INCREMENTAL:NO
>> /PGD:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.pgd"
>> /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
>> /ManifestFile:"MyExecutable.dir\Release\MyExecutable.exe.int
>> [1]ermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
>> 
>> The vcxproj file generated by CMake does not have a
>> "<WholeProgramOptimization>" tag.
>> 
>> I hope you can consider adding LTCG to Release configurations of
>> Visual C++ projects generated by CMake, by default.
>> 
>> Kind regards, Niels

-- 
Niels Dekker
Scientific programmer
LKEB, Leiden University Medical Center

From christoph at ruediger.engineering  Fri Jan 26 13:30:01 2018
From: christoph at ruediger.engineering (christoph at ruediger.engineering)
Date: Fri, 26 Jan 2018 18:30:01 +0000
Subject: [CMake] CMake detects suspicious compiler
Message-ID: <EDE6516D-E1B2-4531-88FF-B339F2B20CE2@ruediger.engineering>

Hi,

I?ve one Linux system here, where cmake always detects a C compiler from a cross-toolchain. Doesn?t sound strange up to now, but the real deal is that the path to the compiler is totally unknown to the shell. It is not in PATH, CC and CXX env variables are empty and CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are not set. The build server is used by multiple users and all but one can use cmake without issues. So I assume that it is some kind of per-user setting.

Does anyone have a hint for me where to continue digging?

The detected compiler path looks a bit like cmake is automatically pulling a toolchain file, without having any toolchain file specified on the command line. Is there some mechanism for specifying a default toolchain file, i.e. via environment variable or config file?

Regards
Christoph

--
r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180126/9d4370be/attachment.html>

From hintonda at gmail.com  Fri Jan 26 14:48:49 2018
From: hintonda at gmail.com (Don Hinton)
Date: Fri, 26 Jan 2018 11:48:49 -0800
Subject: [CMake] CMake detects suspicious compiler
In-Reply-To: <EDE6516D-E1B2-4531-88FF-B339F2B20CE2@ruediger.engineering>
References: <EDE6516D-E1B2-4531-88FF-B339F2B20CE2@ruediger.engineering>
Message-ID: <CAL2T-v7kffVwP3C4yPkkieAH+wewts5Ek_gr6K2pLp3yhBcRfw@mail.gmail.com>

Sounds like it might be a shell cache issue.

https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables


On Fri, Jan 26, 2018 at 10:30 AM, christoph at ruediger.engineering <
christoph at ruediger.engineering> wrote:

> Hi,
>
>
>
> I?ve one Linux system here, where cmake always detects a C compiler from a
> cross-toolchain. Doesn?t sound strange up to now, but the real deal is that
> the path to the compiler is totally unknown to the shell. It is not in
> PATH, CC and CXX env variables are empty and CMAKE_C_COMPILER and
> CMAKE_CXX_COMPILER are not set. The build server is used by multiple users
> and all but one can use cmake without issues. So I assume that it is some
> kind of per-user setting.
>
>
>
> Does anyone have a hint for me where to continue digging?
>
>
>
> The detected compiler path looks a bit like cmake is automatically pulling
> a toolchain file, without having any toolchain file specified on the
> command line. Is there some mechanism for specifying a default toolchain
> file, i.e. via environment variable or config file?
>
>
>
> Regards
>
> Christoph
>
>
>
> --
>
> r?diger.engineering
>
> Christoph R?diger
>
> D?sseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180126/d282c224/attachment.html>

From kris.f.thielemans at gmail.com  Sat Jan 27 06:12:32 2018
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 27 Jan 2018 11:12:32 -0000
Subject: [CMake] downloading ftp URL problems
In-Reply-To: <033201d378a1$66df89f0$349e9dd0$@gmail.com>
References: <033201d378a1$66df89f0$349e9dd0$@gmail.com>
Message-ID: <00e801d3975f$ba418620$2ec49260$@gmail.com>

Dear all

 

I have had no response to this. The problem continues with CMake 3.10.2. I
have no idea what causes this or how to fix it. Any help would be much
appreciated.

 

Kris

 

From: Kris Thielemans 

Sent: 19 December 2017 08:15
To: cmake at cmake.org
Subject: downloading ftp URL problems

 

Hi

 

I'm try to get a file via ftp in EXTERNAL_PROJECT_ADD by specifying the URL.
This takes a long time on my Windows machine using CMake 3.10.1 (and
previous versions of CMake) as it needs multiple retries:

 

2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'

2>  -- Retrying...

2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'

2>  -- Retry after 5 seconds (attempt #2) ...

2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'

2>  -- Retry after 5 seconds (attempt #3) ...

2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'

2>  -- Retry after 15 seconds (attempt #4) ...

2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'

2>  -- Retry after 60 seconds (attempt #5) ...

2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip' 

-- [download 0% complete]

...

 

When using on https link, the download starts immediately. 

 

Any suggestions why this happens, what I can do about it, or how I could
specify an initial sleep period to skip the first retries (but I'm not sure
if that'd help)?

 

Some more detail:

I'm using Windows 10 home with latest CMake installed via the msi.

 

Using the URL in a browser  (firefox) works fine but does need a ~5s wait
before I get the "save" dialog box. 

 

Checking the created download.cmake, it is just a loop with different
sleep_seconds doing the following

 

Set(url "ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip")

execute_process(COMMAND "${CMAKE_COMMAND}" -E sleep "${sleep_seconds}")

 

   file(

       DOWNLOAD

       "${url}" "C:/Users/krisf/Documents/devel/fftw-3.3.5-dll64.zip"

       SHOW_PROGRESS

       # no TIMEOUT

       STATUS status

       LOG log

   )

 

Thanks for your help

 

Kris Thielemans
Reader in Medical Imaging Physics at University College London,
Institute of Nuclear Medicine, UCL Hospital, Tower 5,
235 Euston Road, London NW1 2BU, UK

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180127/f0cc1e4e/attachment-0001.html>

From cristian.adam at gmail.com  Sat Jan 27 07:07:38 2018
From: cristian.adam at gmail.com (Cristian Adam)
Date: Sat, 27 Jan 2018 13:07:38 +0100
Subject: [CMake] downloading ftp URL problems
In-Reply-To: <00e801d3975f$ba418620$2ec49260$@gmail.com>
References: <033201d378a1$66df89f0$349e9dd0$@gmail.com>
 <00e801d3975f$ba418620$2ec49260$@gmail.com>
Message-ID: <CA+u+m-+zbdMUoRcWeF7B1RQXq7-xAotn8OW=p=o5vaN3KVCW7Q@mail.gmail.com>

On Sat, Jan 27, 2018 at 12:12 PM, Kris Thielemans <
kris.f.thielemans at gmail.com> wrote:

> Dear all
>
>
>
> I have had no response to this. The problem continues with CMake 3.10.2. I
> have no idea what causes this or how to fix it. Any help would be much
> appreciated.
>
>
>
> Kris
>
>
>
> *From:* Kris Thielemans
>
> *Sent:* 19 December 2017 08:15
> *To:* cmake at cmake.org
> *Subject:* downloading ftp URL problems
>
>
>
> Hi
>
>
>
> I?m try to get a file via ftp in EXTERNAL_PROJECT_ADD by specifying the
> URL. This takes a long time on my Windows machine using CMake 3.10.1 (and
> previous versions of CMake) as it needs multiple retries:
>
>
>
> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>
> 2>  -- Retrying...
>
> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>
> 2>  -- Retry after 5 seconds (attempt #2) ...
>
> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>
> 2>  -- Retry after 5 seconds (attempt #3) ...
>
> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>
> 2>  -- Retry after 15 seconds (attempt #4) ...
>
> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>
> 2>  -- Retry after 60 seconds (attempt #5) ...
>
> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>
> -- [download 0% complete]
>
> ...
>
>
>
> When using on https link, the download starts immediately.
>
>
>
> Any suggestions why this happens, what I can do about it, or how I could
> specify an initial sleep period to skip the first retries (but I?m not sure
> if that?d help)?
>
>
>
> Some more detail:
>
> I?m using Windows 10 home with latest CMake installed via the msi.
>
>
>
> Using the URL in a browser  (firefox) works fine but does need a ~5s wait
> before I get the ?save? dialog box.
>
>
>
> Checking the created download.cmake, it is just a loop with different
> sleep_seconds doing the following
>
>
>
> Set(url ?ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip?)
>
> execute_process(COMMAND "${CMAKE_COMMAND}" -E sleep "${sleep_seconds}")
>
>
>
>    file(
>
>        DOWNLOAD
>
>        "${url}" "C:/Users/krisf/Documents/devel/fftw-3.3.5-dll64.zip"
>
>        SHOW_PROGRESS
>
>        # no TIMEOUT
>
>        STATUS status
>
>        LOG log
>
>    )
>
>
>
> Thanks for your help
>
>
>

CMake, as far as I know, uses libcurl to handle network transfers.
You should compare cmake downloading with a curl build
<https://curl.haxx.se/download.html>not with Firefox.
Rumor has it that curl is part of Windows now.

If the https link works instantly, why not use it also with cmake?

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180127/5ff0ad1e/attachment.html>

From kris.f.thielemans at gmail.com  Sat Jan 27 07:42:48 2018
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 27 Jan 2018 12:42:48 +0000
Subject: [CMake] downloading ftp URL problems
In-Reply-To: <CA+u+m-+zbdMUoRcWeF7B1RQXq7-xAotn8OW=p=o5vaN3KVCW7Q@mail.gmail.com>
References: <033201d378a1$66df89f0$349e9dd0$@gmail.com>
 <00e801d3975f$ba418620$2ec49260$@gmail.com>
 <CA+u+m-+zbdMUoRcWeF7B1RQXq7-xAotn8OW=p=o5vaN3KVCW7Q@mail.gmail.com>
Message-ID: <CAFNfyPkOeP=ZjY9T1niX9T=r9UC78=ppumqrZGnko3GgD=asPw@mail.gmail.com>

Thanks Cristian

I'll look at curl.

Https links work instantly but there isn't one for FFTW....

Kris

On 27 Jan 2018 12:07, "Cristian Adam" <cristian.adam at gmail.com> wrote:

> On Sat, Jan 27, 2018 at 12:12 PM, Kris Thielemans <
> kris.f.thielemans at gmail.com> wrote:
>
>> Dear all
>>
>>
>>
>> I have had no response to this. The problem continues with CMake 3.10.2.
>> I have no idea what causes this or how to fix it. Any help would be much
>> appreciated.
>>
>>
>>
>> Kris
>>
>>
>>
>> *From:* Kris Thielemans
>>
>> *Sent:* 19 December 2017 08:15
>> *To:* cmake at cmake.org
>> *Subject:* downloading ftp URL problems
>>
>>
>>
>> Hi
>>
>>
>>
>> I?m try to get a file via ftp in EXTERNAL_PROJECT_ADD by specifying the
>> URL. This takes a long time on my Windows machine using CMake 3.10.1 (and
>> previous versions of CMake) as it needs multiple retries:
>>
>>
>>
>> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>>
>> 2>  -- Retrying...
>>
>> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>>
>> 2>  -- Retry after 5 seconds (attempt #2) ...
>>
>> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>>
>> 2>  -- Retry after 5 seconds (attempt #3) ...
>>
>> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>>
>> 2>  -- Retry after 15 seconds (attempt #4) ...
>>
>> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>>
>> 2>  -- Retry after 60 seconds (attempt #5) ...
>>
>> 2>  -- Using src='ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip'
>>
>> -- [download 0% complete]
>>
>> ...
>>
>>
>>
>> When using on https link, the download starts immediately.
>>
>>
>>
>> Any suggestions why this happens, what I can do about it, or how I could
>> specify an initial sleep period to skip the first retries (but I?m not sure
>> if that?d help)?
>>
>>
>>
>> Some more detail:
>>
>> I?m using Windows 10 home with latest CMake installed via the msi.
>>
>>
>>
>> Using the URL in a browser  (firefox) works fine but does need a ~5s wait
>> before I get the ?save? dialog box.
>>
>>
>>
>> Checking the created download.cmake, it is just a loop with different
>> sleep_seconds doing the following
>>
>>
>>
>> Set(url ?ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll64.zip?)
>>
>> execute_process(COMMAND "${CMAKE_COMMAND}" -E sleep "${sleep_seconds}")
>>
>>
>>
>>    file(
>>
>>        DOWNLOAD
>>
>>        "${url}" "C:/Users/krisf/Documents/devel/fftw-3.3.5-dll64.zip"
>>
>>        SHOW_PROGRESS
>>
>>        # no TIMEOUT
>>
>>        STATUS status
>>
>>        LOG log
>>
>>    )
>>
>>
>>
>> Thanks for your help
>>
>>
>>
>
> CMake, as far as I know, uses libcurl to handle network transfers.
> You should compare cmake downloading with a curl build
> <https://curl.haxx.se/download.html>not with Firefox.
> Rumor has it that curl is part of Windows now.
>
> If the https link works instantly, why not use it also with cmake?
>
> Cheers,
> Cristian.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180127/d8c98529/attachment.html>

From a1ba.omarov at gmail.com  Mon Jan 29 04:30:12 2018
From: a1ba.omarov at gmail.com (Alibek Omarov)
Date: Mon, 29 Jan 2018 12:30:12 +0300
Subject: [CMake] My macro library for CMake
In-Reply-To: <CAKyg=SWZkcqhOMPddRBkN0yGzrCghtGsgHmXr1eKe1f4zLKhYA@mail.gmail.com>
References: <CAKyg=SWZkcqhOMPddRBkN0yGzrCghtGsgHmXr1eKe1f4zLKhYA@mail.gmail.com>
Message-ID: <CAKyg=SVhCwSRFMp7CtnJxekRoYBkk5gUo_zyQR+M=LcVoRZduQ@mail.gmail.com>

Hello, fellow CMake users!

For almost 3 years of using CMake in my opensource project, I everytime
encounter the verbosity of CMake scripts. So now I have written a small
library of shorthand utility macros.

At this time it have some macros specific for my project, but I hope others
can find it useful too.
List of macros:
1. fwgs_install -- installs library file. On MSVC installs in separate
directories, corresponding to selected configuration in Visual Studio. For
Debug it also installs PDB file automatically.
2. fwgs_conditional_subproject -- adds subdirectory if conditions was met.
I did this because there is some subdirectories, which can be omitted in
some configurations.
3. fwgs_set_default_properties -- default properties for target. For me it
enables PIC and removes "lib" prefix on Windows.
4. fwgs_string_option -- option() but for strings.
5. fwgs_library_dependency -- downloads dependency from Web, unpacks it,
calls find_library to configure and links to the target. Also does a cache
check, if developer have deleted dependency folder for some reason. Just a
big shortcut.
6. fwgs_add_compile_options -- like add_compile_options, but with language
specification: C for C/C++ flags, CXX for C++ flags, CONLY for C only
flags. Also should work with CMake 2.8, which is still used in Ubuntu
12.04, Debian 7 and Steam Runtime toolchain.

There is other too, but I plan to rework them.

https://github.com/FWGS/xash3d/blob/master/cmake/FWGSLib.cmake

I accept any criticism. I understand that many of them maybe aren't needed,
I just doesn't found any equivalent in documentation.

Thanks for attention!
Alibek Omarov a.k.a a1batross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180129/a4a24a7f/attachment.html>

From christoph at ruediger.engineering  Mon Jan 29 05:35:41 2018
From: christoph at ruediger.engineering (christoph at ruediger.engineering)
Date: Mon, 29 Jan 2018 10:35:41 +0000
Subject: [CMake] CMake detects suspicious compiler
In-Reply-To: <CAL2T-v7kffVwP3C4yPkkieAH+wewts5Ek_gr6K2pLp3yhBcRfw@mail.gmail.com>
References: <EDE6516D-E1B2-4531-88FF-B339F2B20CE2@ruediger.engineering>
 <CAL2T-v7kffVwP3C4yPkkieAH+wewts5Ek_gr6K2pLp3yhBcRfw@mail.gmail.com>
Message-ID: <D0015BD2-C2E5-42E1-ADB0-20BF580FAAA1@ruediger.engineering>

Sadly, it?s not a cache issue. The behavior survives `hash -h` and exists also in a clean new shell. Any other ideas?

Regards
Christoph

r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58
Von: Don Hinton <hintonda at gmail.com>
Datum: Freitag, 26. Januar 2018 um 20:48
An: "christoph at ruediger.engineering" <christoph at ruediger.engineering>
Cc: "cmake at cmake.org" <cmake at cmake.org>
Betreff: Re: [CMake] CMake detects suspicious compiler

Sounds like it might be a shell cache issue.

https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables


On Fri, Jan 26, 2018 at 10:30 AM, christoph at ruediger.engineering <christoph at ruediger.engineering<mailto:christoph at ruediger.engineering>> wrote:
Hi,

I?ve one Linux system here, where cmake always detects a C compiler from a cross-toolchain. Doesn?t sound strange up to now, but the real deal is that the path to the compiler is totally unknown to the shell. It is not in PATH, CC and CXX env variables are empty and CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are not set. The build server is used by multiple users and all but one can use cmake without issues. So I assume that it is some kind of per-user setting.

Does anyone have a hint for me where to continue digging?

The detected compiler path looks a bit like cmake is automatically pulling a toolchain file, without having any toolchain file specified on the command line. Is there some mechanism for specifying a default toolchain file, i.e. via environment variable or config file?

Regards
Christoph

--
r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58

--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180129/5f1036ff/attachment-0001.html>

From christoph at ruediger.engineering  Mon Jan 29 05:45:53 2018
From: christoph at ruediger.engineering (christoph at ruediger.engineering)
Date: Mon, 29 Jan 2018 10:45:53 +0000
Subject: [CMake] CMake detects suspicious compiler
In-Reply-To: <D0015BD2-C2E5-42E1-ADB0-20BF580FAAA1@ruediger.engineering>
References: <EDE6516D-E1B2-4531-88FF-B339F2B20CE2@ruediger.engineering>
 <CAL2T-v7kffVwP3C4yPkkieAH+wewts5Ek_gr6K2pLp3yhBcRfw@mail.gmail.com>
 <D0015BD2-C2E5-42E1-ADB0-20BF580FAAA1@ruediger.engineering>
Message-ID: <E83DD035-505D-4BA9-94A7-9F40D0772EC4@ruediger.engineering>

Oh, sorry. I meant it survives `hash -r`.

r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58
Von: CMake <cmake-bounces at cmake.org> im Auftrag von "christoph at ruediger.engineering" <christoph at ruediger.engineering>
Datum: Montag, 29. Januar 2018 um 11:45
An: Don Hinton <hintonda at gmail.com>
Cc: "cmake at cmake.org" <cmake at cmake.org>
Betreff: Re: [CMake] CMake detects suspicious compiler

Sadly, it?s not a cache issue. The behavior survives `hash -h` and exists also in a clean new shell. Any other ideas?

Regards
Christoph

r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58
Von: Don Hinton <hintonda at gmail.com>
Datum: Freitag, 26. Januar 2018 um 20:48
An: "christoph at ruediger.engineering" <christoph at ruediger.engineering>
Cc: "cmake at cmake.org" <cmake at cmake.org>
Betreff: Re: [CMake] CMake detects suspicious compiler

Sounds like it might be a shell cache issue.

https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables


On Fri, Jan 26, 2018 at 10:30 AM, christoph at ruediger.engineering <christoph at ruediger.engineering<mailto:christoph at ruediger.engineering>> wrote:
Hi,

I?ve one Linux system here, where cmake always detects a C compiler from a cross-toolchain. Doesn?t sound strange up to now, but the real deal is that the path to the compiler is totally unknown to the shell. It is not in PATH, CC and CXX env variables are empty and CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are not set. The build server is used by multiple users and all but one can use cmake without issues. So I assume that it is some kind of per-user setting.

Does anyone have a hint for me where to continue digging?

The detected compiler path looks a bit like cmake is automatically pulling a toolchain file, without having any toolchain file specified on the command line. Is there some mechanism for specifying a default toolchain file, i.e. via environment variable or config file?

Regards
Christoph

--
r?diger.engineering
Christoph R?diger
D?sseldorfer Str. 12
45145 Essen
Germany

phone: +49 201 458 478 58

--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180129/85946e4a/attachment.html>

From robert.maynard at kitware.com  Mon Jan 29 08:24:48 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 29 Jan 2018 08:24:48 -0500
Subject: [CMake] Confusion with range-based FOREACH logic
In-Reply-To: <CAHd499DQWoLs1RtTBSWFZXhLUUh2tQf+ukLgSutAQTk8xFqK8w@mail.gmail.com>
References: <CAHd499DQWoLs1RtTBSWFZXhLUUh2tQf+ukLgSutAQTk8xFqK8w@mail.gmail.com>
Message-ID: <CAFzjYVq4Qxz3buA9c0fKz399T0vpsSxU4Y-EqHWyGtYBZ6t4Sg@mail.gmail.com>

Hi,

Looking at the documentation for 'RANGE' indicates that it is
inclusive on both ends (but poorly), which as you point out is not
what most people will expect. To solve your problem you can subtract 1
from len before you loop to have the behavior you want.


On Tue, Jan 23, 2018 at 12:27 PM, Robert Dailey
<rcdailey.lists at gmail.com> wrote:
> I am doing the following:
>
> ```
> set( CS_THIRD_PARTY_REFERENCES
>     Iconic.Zip ${CMAKE_CURRENT_SOURCE_DIR}/DotNetZip/Iconic.Zip.dll
> )
>
> if( CS_THIRD_PARTY_REFERENCES )
>     list( LENGTH CS_THIRD_PARTY_REFERENCES len )
>     message( STATUS "len: ${len}" )
>     foreach( i RANGE 0 ${len} 2 )
>         message( STATUS "i: ${i}" )
>         list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_name )
>         math( EXPR i "${i}+1" )
>         list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_path )
>         set_property( TARGET ${target_name} PROPERTY
>             VS_DOTNET_REFERENCE_${assembly_name} ${assembly_path}
>         )
>         message( STATUS "i: ${i}" )
>         message( STATUS "assembly_name: ${assembly_name}" )
>         message( STATUS "assembly_path: ${assembly_path}" )
>     endforeach()
> endif()
> ```
>
> I am finding that the foreach() loops 2 times when ${len} is 2. What I
> expect during the 2nd iteration is that it does ${i}+STEP (0+2) which
> would equal 2, and so long as 2<${len} (2<2), then it would continue
> to iterate. In this case, it should stop after the first iteration.
> I'm thinking that this should work like a C++ for loop. Is this not
> the case? How should I be iterating over a list of 2 times at a time?
> --
>
> 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

From robert.maynard at kitware.com  Mon Jan 29 08:36:13 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 29 Jan 2018 08:36:13 -0500
Subject: [CMake] CMake detects suspicious compiler
In-Reply-To: <E83DD035-505D-4BA9-94A7-9F40D0772EC4@ruediger.engineering>
References: <EDE6516D-E1B2-4531-88FF-B339F2B20CE2@ruediger.engineering>
 <CAL2T-v7kffVwP3C4yPkkieAH+wewts5Ek_gr6K2pLp3yhBcRfw@mail.gmail.com>
 <D0015BD2-C2E5-42E1-ADB0-20BF580FAAA1@ruediger.engineering>
 <E83DD035-505D-4BA9-94A7-9F40D0772EC4@ruediger.engineering>
Message-ID: <CAFzjYVru7b+xtBhk=VxZHQ7aVAWXaVNu4c5MwLE3fQRj26W1nA@mail.gmail.com>

Have you tried running with '--trace-expand' with a clean build
directory? I would start by looking for where the execute_process
occurs that verifies the C compiler and work backwards from that
point.

On Mon, Jan 29, 2018 at 5:45 AM, christoph at ruediger.engineering
<christoph at ruediger.engineering> wrote:
> Oh, sorry. I meant it survives `hash -r`.
>
>
>
> r?diger.engineering
>
> Christoph R?diger
>
> D?sseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
> Von: CMake <cmake-bounces at cmake.org> im Auftrag von
> "christoph at ruediger.engineering" <christoph at ruediger.engineering>
> Datum: Montag, 29. Januar 2018 um 11:45
> An: Don Hinton <hintonda at gmail.com>
>
>
> Cc: "cmake at cmake.org" <cmake at cmake.org>
> Betreff: Re: [CMake] CMake detects suspicious compiler
>
>
>
> Sadly, it?s not a cache issue. The behavior survives `hash -h` and exists
> also in a clean new shell. Any other ideas?
>
>
>
> Regards
>
> Christoph
>
>
>
> r?diger.engineering
>
> Christoph R?diger
>
> D?sseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
> Von: Don Hinton <hintonda at gmail.com>
> Datum: Freitag, 26. Januar 2018 um 20:48
> An: "christoph at ruediger.engineering" <christoph at ruediger.engineering>
> Cc: "cmake at cmake.org" <cmake at cmake.org>
> Betreff: Re: [CMake] CMake detects suspicious compiler
>
>
>
> Sounds like it might be a shell cache issue.
>
>
>
> https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables
>
>
>
>
>
> On Fri, Jan 26, 2018 at 10:30 AM, christoph at ruediger.engineering
> <christoph at ruediger.engineering> wrote:
>
> Hi,
>
>
>
> I?ve one Linux system here, where cmake always detects a C compiler from a
> cross-toolchain. Doesn?t sound strange up to now, but the real deal is that
> the path to the compiler is totally unknown to the shell. It is not in PATH,
> CC and CXX env variables are empty and CMAKE_C_COMPILER and
> CMAKE_CXX_COMPILER are not set. The build server is used by multiple users
> and all but one can use cmake without issues. So I assume that it is some
> kind of per-user setting.
>
>
>
> Does anyone have a hint for me where to continue digging?
>
>
>
> The detected compiler path looks a bit like cmake is automatically pulling a
> toolchain file, without having any toolchain file specified on the command
> line. Is there some mechanism for specifying a default toolchain file, i.e.
> via environment variable or config file?
>
>
>
> Regards
>
> Christoph
>
>
>
> --
>
> r?diger.engineering
>
> Christoph R?diger
>
> D?sseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
>
> --
>
> 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
>

From d3ck0r at gmail.com  Tue Jan 30 03:11:08 2018
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 30 Jan 2018 00:11:08 -0800
Subject: [CMake] Hard to do if in Macro
Message-ID: <CAA2GJqUeWU9+J=eHjmYrMGj1gtR+Es_k7PrhA7fQV4mxrXJsRA@mail.gmail.com>

Why do I have to do

if( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
endif( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")

in a macro like...
----------------------

set( __ANDROID__ 1 )

macro( test __ANDROID__ )

  if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
    message( "Included..... " )
  endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")

  if( __ANDROID__ )
    message( "ALWAYS Included ${__ANDROID__}" )
  endif( __ANDROID__ )

endmacro( test )

test( __ANDROID__ )
test( ${__ANDROID__} )
test( OFF )

----------
Output

Included.....
ALWAYS Included __ANDROID__
Included.....
ALWAYS Included 1
ALWAYS Included OFF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180130/946bae81/attachment.html>

From petr.kmoch at gmail.com  Tue Jan 30 03:35:33 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 30 Jan 2018 09:35:33 +0100
Subject: [CMake] Hard to do if in Macro
In-Reply-To: <CAA2GJqUeWU9+J=eHjmYrMGj1gtR+Es_k7PrhA7fQV4mxrXJsRA@mail.gmail.com>
References: <CAA2GJqUeWU9+J=eHjmYrMGj1gtR+Es_k7PrhA7fQV4mxrXJsRA@mail.gmail.com>
Message-ID: <CAKohaZfQVHFtSXRLZL4f-MzZAsdVKrEcRA7kgQD2VRMG99pUpg@mail.gmail.com>

Macros aren't functions, and macro parameters aren't CMake variables.
Expanding a macro parameter is effectively *textual* substitution, whereas
dereferencing a CMake variable is a semantic one.

In other words, inside your macro, the text __ANDROID__ (when not expanded)
never refers to the macro parameter. Macro parameters "don't exist" outside
of expansion context. The `if(__ANDROID__)` bit therefore always refers to
the variable __ANDROID__, never to the macro parameter __ANDROID__.

You still don't have to spell out the conditional as explicitly as you're
doing it now, but you have to expand the parameter:

macro(test __ANDROID__)
  if(${__ANDROID__})
    message( "Included..... " )
  endif()
endmacro()

This is what the evaluation will look like based on how you call it:

test(__ANDROID__)   -> if(__ANDROID__) -> refers to the variable
set(__ANDROID__ 1)
test(${__ANDROID__})   -> if(1)
set(__ANDROID__ 0)
test(${__ANDROID__})   -> if(0)
test(OFF)   -> if(OFF)

CMake macros have a lot of specific and potentially weird/counterintuitive
behaviour. In general, you should always write your commands as functions
and only resort to macros if you explicitly need their specific behaviour.

Petr



On 30 January 2018 at 09:11, J Decker <d3ck0r at gmail.com> wrote:

> Why do I have to do
>
> if( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
> endif( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
>
> in a macro like...
> ----------------------
>
> set( __ANDROID__ 1 )
>
> macro( test __ANDROID__ )
>
>   if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>     message( "Included..... " )
>   endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>
>   if( __ANDROID__ )
>     message( "ALWAYS Included ${__ANDROID__}" )
>   endif( __ANDROID__ )
>
> endmacro( test )
>
> test( __ANDROID__ )
> test( ${__ANDROID__} )
> test( OFF )
>
> ----------
> Output
>
> Included.....
> ALWAYS Included __ANDROID__
> Included.....
> ALWAYS Included 1
> ALWAYS Included OFF
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180130/18db2dd3/attachment.html>

From joern.hauser at sevencs.com  Tue Jan 30 04:55:53 2018
From: joern.hauser at sevencs.com (Joern Hauser)
Date: Tue, 30 Jan 2018 09:55:53 +0000
Subject: [CMake] Referencing nuget packages in csharp csproj files
Message-ID: <7511d7a9b7374f1483cd873ee0c3915f@EXMBX22.SFP-Net.skyfillers.local>

Hello,

we're looking into generating our C# projects using CMAKE. We can generate working solution files, but we're still struggling with dependencies. We would like to manage nuget packages via the nuget.exe command line tool. With the install or restore parameter this deems us a good approach for managing dependencies. However, CMAKE currently only supports the Reference tag in the csproj file. Without an additional HintPath subtag into the package's folder the reference is not resolved. This HintPath points down the whole path to the DLL of the package, including version etc. So far I have not found a way how to extract this path from nuget.exe and I would not like having to guess it to fill the HintPath tag.

Any ideas how to solve this issue?

We found that using the new PackageReference tag (new since VS2017) would work fine without a HintPath and would offer complete configuration of dependencies via nuget.

So we wondered if CMAKE could support this new PackageReference tag, too, like it does for the Reference tag by means of the VS_DOTNET_REFERENCES? Or is there any way how we could inject the XML into the generated csproj file ourselves from the project's CMakeLists.txt? Looking into the CMAKE source code, I think supporting the PackageReference tag would basically require going along the lines of the VS_DOTNET_REFERENCES property handling. However, I don't know if another property like this (e.g. VS_DOTNET_PACKAGEREFERENCES) would be appreciated by the CMAKE team or whether there are better solutions? If such a property were acceptable maybe we could even try to offer a patch for CMAKE.

Thank you!

Cheers,
J?rn



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180130/42d5639f/attachment.html>

From d3ck0r at gmail.com  Tue Jan 30 11:07:19 2018
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 30 Jan 2018 08:07:19 -0800
Subject: [CMake] Hard to do if in Macro
In-Reply-To: <CAKohaZfQVHFtSXRLZL4f-MzZAsdVKrEcRA7kgQD2VRMG99pUpg@mail.gmail.com>
References: <CAA2GJqUeWU9+J=eHjmYrMGj1gtR+Es_k7PrhA7fQV4mxrXJsRA@mail.gmail.com>
 <CAKohaZfQVHFtSXRLZL4f-MzZAsdVKrEcRA7kgQD2VRMG99pUpg@mail.gmail.com>
Message-ID: <CAA2GJqW3KsNMf0LPmCmw-=2hrcYt9bKtpVbzyht3qec45P30Lw@mail.gmail.com>

Okay... but then with function I can't set external variables; but if(
__ANDROID__ ) works.

`result` never changes.

---------------------------

set( __ANDROID__ 1 )

function( test __ANDROID__ RETVAL )

  if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
    set( ${RETVAL} ${${RETVAL}} qwer2 )
    message( "Included..... " )
  endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")

  if( __ANDROID__ )
    set( ${RETVAL} ${${RETVAL}} asdf )
    message( "ALWAYS Included ${__ANDROID__}" )
  endif( __ANDROID__ )

endfunction( test )


set( result "default" )

test( __ANDROID__ "result" )
message( "REsult:${result}" )

test( ${__ANDROID__} "result" )
message( "REsult:${result}" )

test( OFF  "result")
message( "REsult:${result}" )

---------------------------




On Tue, Jan 30, 2018 at 12:35 AM, Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Macros aren't functions, and macro parameters aren't CMake variables.
> Expanding a macro parameter is effectively *textual* substitution, whereas
> dereferencing a CMake variable is a semantic one.
>
> In other words, inside your macro, the text __ANDROID__ (when not
> expanded) never refers to the macro parameter. Macro parameters "don't
> exist" outside of expansion context. The `if(__ANDROID__)` bit therefore
> always refers to the variable __ANDROID__, never to the macro parameter
> __ANDROID__.
>
> You still don't have to spell out the conditional as explicitly as you're
> doing it now, but you have to expand the parameter:
>
> macro(test __ANDROID__)
>   if(${__ANDROID__})
>     message( "Included..... " )
>   endif()
> endmacro()
>
> This is what the evaluation will look like based on how you call it:
>
> test(__ANDROID__)   -> if(__ANDROID__) -> refers to the variable
> set(__ANDROID__ 1)
> test(${__ANDROID__})   -> if(1)
> set(__ANDROID__ 0)
> test(${__ANDROID__})   -> if(0)
> test(OFF)   -> if(OFF)
>
> CMake macros have a lot of specific and potentially weird/counterintuitive
> behaviour. In general, you should always write your commands as functions
> and only resort to macros if you explicitly need their specific behaviour.
>
> Petr
>
>
>
> On 30 January 2018 at 09:11, J Decker <d3ck0r at gmail.com> wrote:
>
>> Why do I have to do
>>
>> if( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
>> endif( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
>>
>> in a macro like...
>> ----------------------
>>
>> set( __ANDROID__ 1 )
>>
>> macro( test __ANDROID__ )
>>
>>   if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>>     message( "Included..... " )
>>   endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>>
>>   if( __ANDROID__ )
>>     message( "ALWAYS Included ${__ANDROID__}" )
>>   endif( __ANDROID__ )
>>
>> endmacro( test )
>>
>> test( __ANDROID__ )
>> test( ${__ANDROID__} )
>> test( OFF )
>>
>> ----------
>> Output
>>
>> Included.....
>> ALWAYS Included __ANDROID__
>> Included.....
>> ALWAYS Included 1
>> ALWAYS Included OFF
>>
>> --
>>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180130/25d63346/attachment-0001.html>

From petr.kmoch at gmail.com  Wed Jan 31 03:19:45 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 31 Jan 2018 09:19:45 +0100
Subject: [CMake] Hard to do if in Macro
In-Reply-To: <CAA2GJqW3KsNMf0LPmCmw-=2hrcYt9bKtpVbzyht3qec45P30Lw@mail.gmail.com>
References: <CAA2GJqUeWU9+J=eHjmYrMGj1gtR+Es_k7PrhA7fQV4mxrXJsRA@mail.gmail.com>
 <CAKohaZfQVHFtSXRLZL4f-MzZAsdVKrEcRA7kgQD2VRMG99pUpg@mail.gmail.com>
 <CAA2GJqW3KsNMf0LPmCmw-=2hrcYt9bKtpVbzyht3qec45P30Lw@mail.gmail.com>
Message-ID: <CAKohaZemwzAVUAUqOJh2BfbTBTrXHN6W2HWTT5GKycFE4=+fhQ@mail.gmail.com>

When returning values from a function, you have to use the PARENT_SCOPE
argument of set():

function( test __ANDROID__ RETVAL )

  if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
    set( ${RETVAL} ${${RETVAL}} qwer2 PASRENT_SCOPE)
    message( "Included..... " )
  endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")

  if( __ANDROID__ )
    set( ${RETVAL} ${${RETVAL}} asdf PARENT_SCOPE)
    message( "ALWAYS Included ${__ANDROID__}" )
  endif( __ANDROID__ )

endfunction( test )

Petr


On 30 January 2018 at 17:07, J Decker <d3ck0r at gmail.com> wrote:

> Okay... but then with function I can't set external variables; but if(
> __ANDROID__ ) works.
>
> `result` never changes.
>
> ---------------------------
>
> set( __ANDROID__ 1 )
>
> function( test __ANDROID__ RETVAL )
>
>   if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>     set( ${RETVAL} ${${RETVAL}} qwer2 )
>     message( "Included..... " )
>   endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>
>   if( __ANDROID__ )
>     set( ${RETVAL} ${${RETVAL}} asdf )
>     message( "ALWAYS Included ${__ANDROID__}" )
>   endif( __ANDROID__ )
>
> endfunction( test )
>
>
> set( result "default" )
>
> test( __ANDROID__ "result" )
> message( "REsult:${result}" )
>
> test( ${__ANDROID__} "result" )
> message( "REsult:${result}" )
>
> test( OFF  "result")
> message( "REsult:${result}" )
>
> ---------------------------
>
>
>
>
> On Tue, Jan 30, 2018 at 12:35 AM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
>
>> Macros aren't functions, and macro parameters aren't CMake variables.
>> Expanding a macro parameter is effectively *textual* substitution, whereas
>> dereferencing a CMake variable is a semantic one.
>>
>> In other words, inside your macro, the text __ANDROID__ (when not
>> expanded) never refers to the macro parameter. Macro parameters "don't
>> exist" outside of expansion context. The `if(__ANDROID__)` bit therefore
>> always refers to the variable __ANDROID__, never to the macro parameter
>> __ANDROID__.
>>
>> You still don't have to spell out the conditional as explicitly as you're
>> doing it now, but you have to expand the parameter:
>>
>> macro(test __ANDROID__)
>>   if(${__ANDROID__})
>>     message( "Included..... " )
>>   endif()
>> endmacro()
>>
>> This is what the evaluation will look like based on how you call it:
>>
>> test(__ANDROID__)   -> if(__ANDROID__) -> refers to the variable
>> set(__ANDROID__ 1)
>> test(${__ANDROID__})   -> if(1)
>> set(__ANDROID__ 0)
>> test(${__ANDROID__})   -> if(0)
>> test(OFF)   -> if(OFF)
>>
>> CMake macros have a lot of specific and potentially
>> weird/counterintuitive behaviour. In general, you should always write your
>> commands as functions and only resort to macros if you explicitly need
>> their specific behaviour.
>>
>> Petr
>>
>>
>>
>> On 30 January 2018 at 09:11, J Decker <d3ck0r at gmail.com> wrote:
>>
>>> Why do I have to do
>>>
>>> if( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
>>> endif( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
>>>
>>> in a macro like...
>>> ----------------------
>>>
>>> set( __ANDROID__ 1 )
>>>
>>> macro( test __ANDROID__ )
>>>
>>>   if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>>>     message( "Included..... " )
>>>   endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
>>>
>>>   if( __ANDROID__ )
>>>     message( "ALWAYS Included ${__ANDROID__}" )
>>>   endif( __ANDROID__ )
>>>
>>> endmacro( test )
>>>
>>> test( __ANDROID__ )
>>> test( ${__ANDROID__} )
>>> test( OFF )
>>>
>>> ----------
>>> Output
>>>
>>> Included.....
>>> ALWAYS Included __ANDROID__
>>> Included.....
>>> ALWAYS Included 1
>>> ALWAYS Included OFF
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/9cd37862/attachment.html>

From Dvir.Yitzchaki at ceva-dsp.com  Wed Jan 31 03:19:32 2018
From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki)
Date: Wed, 31 Jan 2018 08:19:32 +0000
Subject: [CMake] [Digital Signature Failure] Re: Hard to do if in Macro
In-Reply-To: <CAA2GJqW3KsNMf0LPmCmw-=2hrcYt9bKtpVbzyht3qec45P30Lw@mail.gmail.com>
References: <CAA2GJqUeWU9+J=eHjmYrMGj1gtR+Es_k7PrhA7fQV4mxrXJsRA@mail.gmail.com>
 <CAKohaZfQVHFtSXRLZL4f-MzZAsdVKrEcRA7kgQD2VRMG99pUpg@mail.gmail.com>
 <CAA2GJqW3KsNMf0LPmCmw-=2hrcYt9bKtpVbzyht3qec45P30Lw@mail.gmail.com>
Message-ID: <5b78ecd5b1724a1f8ec9ead64331b8bb@ceva-dsp.com>

You can add PARENT_SCOPE to set command to set the value on the calling code.

Regards,
Dvir

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of J Decker
Sent: Tuesday, January 30, 2018 18:07
To: Petr Kmoch <petr.kmoch at gmail.com>
Cc: CMake Mail List <cmake at cmake.org>
Subject: [Digital Signature Failure] Re: [CMake] Hard to do if in Macro

Okay... but then with function I can't set external variables; but if( __ANDROID__ ) works.

`result` never changes.

---------------------------

set( __ANDROID__ 1 )

function( test __ANDROID__ RETVAL )

  if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
    set( ${RETVAL} ${${RETVAL}} qwer2 )
    message( "Included..... " )
  endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")

  if( __ANDROID__ )
    set( ${RETVAL} ${${RETVAL}} asdf )
    message( "ALWAYS Included ${__ANDROID__}" )
  endif( __ANDROID__ )

endfunction( test )


set( result "default" )

test( __ANDROID__ "result" )
message( "REsult:${result}" )

test( ${__ANDROID__} "result" )
message( "REsult:${result}" )

test( OFF  "result")
message( "REsult:${result}" )

---------------------------




On Tue, Jan 30, 2018 at 12:35 AM, Petr Kmoch <petr.kmoch at gmail.com<mailto:petr.kmoch at gmail.com>> wrote:
Macros aren't functions, and macro parameters aren't CMake variables. Expanding a macro parameter is effectively *textual* substitution, whereas dereferencing a CMake variable is a semantic one.
In other words, inside your macro, the text __ANDROID__ (when not expanded) never refers to the macro parameter. Macro parameters "don't exist" outside of expansion context. The `if(__ANDROID__)` bit therefore always refers to the variable __ANDROID__, never to the macro parameter __ANDROID__.
You still don't have to spell out the conditional as explicitly as you're doing it now, but you have to expand the parameter:
macro(test __ANDROID__)
  if(${__ANDROID__})
    message( "Included..... " )
  endif()
endmacro()
This is what the evaluation will look like based on how you call it:
test(__ANDROID__)   -> if(__ANDROID__) -> refers to the variable
set(__ANDROID__ 1)
test(${__ANDROID__})   -> if(1)
set(__ANDROID__ 0)
test(${__ANDROID__})   -> if(0)
test(OFF)   -> if(OFF)
CMake macros have a lot of specific and potentially weird/counterintuitive behaviour. In general, you should always write your commands as functions and only resort to macros if you explicitly need their specific behaviour.
Petr



On 30 January 2018 at 09:11, J Decker <d3ck0r at gmail.com<mailto:d3ck0r at gmail.com>> wrote:
Why do I have to do

if( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")
endif( ${M__ANDROID__} EQUAL 1 OR ${M__ANDROID__} STREQUAL "ON")

in a macro like...
----------------------

set( __ANDROID__ 1 )

macro( test __ANDROID__ )

  if( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")
    message( "Included..... " )
  endif( ${__ANDROID__} EQUAL 1 OR ${__ANDROID__} STREQUAL "ON")

  if( __ANDROID__ )
    message( "ALWAYS Included ${__ANDROID__}" )
  endif( __ANDROID__ )

endmacro( test )

test( __ANDROID__ )
test( ${__ANDROID__} )
test( OFF )

----------
Output

Included.....
ALWAYS Included __ANDROID__
Included.....
ALWAYS Included 1
ALWAYS Included OFF

--

Powered by www.kitware.com<http://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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/820b0849/attachment-0001.html>

From franck.houssen at inria.fr  Wed Jan 31 04:39:51 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Wed, 31 Jan 2018 10:39:51 +0100 (CET)
Subject: [CMake] How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?
In-Reply-To: <120891492.25817514.1517390958758.JavaMail.zimbra@inria.fr>
Message-ID: <611765536.25823387.1517391591763.JavaMail.zimbra@inria.fr>

How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ? 

I would like to create a *.pc/cmake file for users to find a library I provide. As there is possibly a LOT of dependencies (libraries) I may not even be able to list, the most simple way to do that is to use RPATH. I know that for gcc, RPATH is set with "-Wl,-rpath". But what about others compilers (pgi, icc) ? This option could not be the same. 

Is it possible to "grab" the correct RPATH option (-Wl,-rpath) according to the compiler ? Something like a CMAKE_RPATH_OPTIONS to substitute in a *.pc/cmake.in template file ? (to create a *.pc/cmake file in the install directory using configure_file) 

Franck 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/53e22146/attachment.html>

From rainer.poisel at gmail.com  Wed Jan 31 05:37:41 2018
From: rainer.poisel at gmail.com (Rainer Poisel)
Date: Wed, 31 Jan 2018 11:37:41 +0100
Subject: [CMake] Core-dumping CTest tests that fail
Message-ID: <CADpFnzww4KuKkA7a3qV761YAP_A3Oj1wyX8c8zyYJULL-=v6Yw@mail.gmail.com>

Hello,

I have a few CTest tests that fail (e. g. SEGFAULT) or timeout on
Linux from time to time. The tests are performed in a Continuous
Integration (CI) environment and I would like to simplify the analysis
in case a test fails.

Is there a way to make failing CTest tests to dump their core? In my
CI I would then invoke gdb automatically to print a call-stack of all
involved threads.

Thanks and regards,
  Rainer

From gael.de-chalendar at cea.fr  Wed Jan 31 11:11:00 2018
From: gael.de-chalendar at cea.fr (=?ISO-8859-1?Q?Ga=EBl?= de Chalendar)
Date: Wed, 31 Jan 2018 17:11:00 +0100
Subject: [CMake] Wrong MSVC with ExternalProject_Add
Message-ID: <58370451.EOqfgVrzbx@brezhoneg>

Hi,

I encounter a problem using cmake (3.9 an 3.10) with Visual c++ 2015 under 
Windows 10. 

My build works with the "Visual Studio 14 2015 Win64" generator but I fail to 
build using the Ninja generator.

I first solved a first step with help from stackoverflow and a blog post:
https://stackoverflow.com/questions/47904633/how-to-use-together-buildbot-cmake-ninja-and-visual-studio-c-compiler

Now, the initial cmake step runs well:

cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_IGNORE_PATH=C:/Strawberry/c/
bin -DCMAKE_INSTALL_PREFIX=C:\disk\amose-buildbot-worker\lima-master-
windows-10\Dist\master\Release -DWITH_ARCH=ON -DLIMA_RESOURCES=build -
DLIMA_VERSION_RELEASE=master -DSHORTEN_POR_CORPUS_FOR_SVMLEARN=TRUE C:\disk
\amose-buildbot-worker\lima-master-windows-10\Sources
 in dir Z:\b (timeout 1200 secs)
 watching logfiles {}
 argv: [b'cmake', b'-G', b'Ninja', b'-DCMAKE_BUILD_TYPE=Release', b'-
DCMAKE_IGNORE_PATH=C:/Strawberry/c/bin', b'-DCMAKE_INSTALL_PREFIX=C:\\disk\
\amose-buildbot-worker\\lima-master-windows-10\\Dist\\master\\Release', b'-
DWITH_ARCH=ON', b'-DLIMA_RESOURCES=build', b'-DLIMA_VERSION_RELEASE=master', 
b'-DSHORTEN_POR_CORPUS_FOR_SVMLEARN=TRUE', b'C:\\disk\\amose-buildbot-worker\
\lima-master-windows-10\\Sources']
 environment:
<snip environment variables>
-- The C compiler identification is MSVC 19.0.24210.0
-- The CXX compiler identification is MSVC 19.0.24210.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
SHORTEN_POR_CORPUS_FOR_SVMLEARN=TRUE
WITH_ASAN=OFF
WITH_ARCH=ON
Windows flags
PERL5LIB=C:/disk/amose-buildbot-worker/lima-master-windows-10/Sources/
lima_pelf/evalPosTagging/SVM/SVMTool-1.3.1/lib:
PATH=C:/disk/amose-buildbot-worker/lima-master-windows-10/Sources/lima_pelf/
evalPosTagging/SVM/SVMTool-1.3.1/bin:C:/Users/buildbot/Projets/externals
\bin;C:/Users/buildbot/Projets/externals\lib;C:\disk\amose-buildbot-worker
\lima-master-windows-10\Dist\master\Release\bin;C:\disk\amose-buildbot-worker
\lima-master-windows-10\Dist\master\Release\lib;C:\Program Files (x86)\MSBuild
\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN
\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows
\Microsoft.NET\Framework64\;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:
\Program Files (x86)\Windows Kits\8.1\bin\x86;c:\d\bin;c:\d\share\apps\lima
\scripts;C:\Qt\Qt5.6.3\5.6.3\msvc2015_64\bin;%BOOST_LIBRARYDIR%;c:\msys64\usr
\bin;C:\ProgramData\chocolatey\lib\msys2;C:\tools\msys64;C:\tools\msys64\usr
\bin;C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs
\Microsoft.UniversalCRT.Debug\10.0.10240.0\Redist\Debug\x86;C:
\Python36\Scripts\;C:\Python36\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS
\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\ProgramData
\chocolatey\bin;C:\Program Files\Git\cmd;C:\Program Files (x86)\Windows Kits
\8.1\Windows Performance Toolkit\;C:\local\boost_1_58_0\lib64-msvc-12.0;C:
\Program Files\CMake\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:
\Strawberry\perl\bin;C:\Program Files\Java\jdk1.8.0_162\bin;C:\Users\buildbot
\AppData\Local\Microsoft\WindowsApps;c:\Qt\Qt5.6.3\5.6.3\msvc2015_64;;c:
\python36\lib\site-packages\pypiwin32_system32
Found Qt5 5.6.3
Adding module Core
Adding module Core
-- Configuring done
-- Generating done
-- Build files have been written to: Z:/b
program finished with exit code 0
elapsedTime=35.421545

But wen the build step runs, the configuration of the first ExternalProject_Add 
fails:

cmake --build . --config Release
 in dir Z:\b (timeout 3600 secs)
 watching logfiles {}
 argv: [b'cmake', b'--build', b'.', b'--config', b'Release']
 environment:
<snip environment  variables>
 using PTY: False
[1/55] Creating directories for 'lima_common'
[1/55] No download step for 'lima_common'
[2/55] No update step for 'lima_common'
[3/55] No patch step for 'lima_common'
[4/55] Performing configure step for 'lima_common'
-- The C compiler identification is MSVC 19.0.24210.0
-- The CXX compiler identification is MSVC
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/amd64/cl.exe
CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/Platform/
Windows-MSVC.cmake:67 (message):
  MSVC compiler version not detected properly:
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.10/Modules/Platform/Windows-MSVC-
CXX.cmake:1 (include)
  C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeCXXInformation.cmake:48 
(include)
  Z:/b/lima_common/src/lima_common-build/CMakeFiles/CMakeTmp/CMakeLists.txt:2 
(project)
CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/
CMakeTestCXXCompiler.cmake:30 (try_compile):
  Failed to configure test project build system.
Call Stack (most recent call first):
  CMakeLists.txt:17 (project)
-- Configuring incomplete, errors occurred!
See also "Z:/b/lima_common/src/lima_common-build/CMakeFiles/CMakeOutput.log".
FAILED: lima_common/src/lima_common-stamp/lima_common-configure 
cmd.exe /C "cd /D Z:\b\lima_common\src\lima_common-build && "C:\Program Files
\CMake\bin\cmake.exe" -DCMAKE_INSTALL_PREFIX:PATH=C:\disk\amose-buildbot-
worker\lima-master-windows-10\Dist\master\Release -
DCMAKE_BUILD_TYPE:STRING=Release -DLIMA_VERSION_RELEASE:STRING=\"master\" -
DBoost_DEBUG=ON -DWITH_ASAN:BOOL=OFF -DWITH_ARCH:BOOL=ON -
DSHORTEN_POR_CORPUS_FOR_SVMLEARN:BOOL=TRUE -DCMAKE_IGNORE_PATH=C:/Strawberry/
c/bin "-DCMAKE_CXX_FLAGS:STRING=/Zc:wchar_t- /EHsc /GR /W4 /MP /FAu /DWIN32 /
D_WINDOWS /W3 /GR /EHsc" "-DCMAKE_CXX_FLAGS_DEBUG:STRING=/MDd /Zi /Ob0 /Od /
RTC1" "-DCMAKE_CXX_FLAGS_RELEASE:STRING=/MD /O2 /Ob2 /DNDEBUG" -
DBOOST_ROOT:STRING= -DBOOST_LIBRARYDIR:STRING= -DENVPATH:STRING=C:/disk/amose-
buildbot-worker/lima-master-windows-10/Sources/lima_pelf/evalPosTagging/SVM/
SVMTool-1.3.1/bin:C:/Users/buildbot/Projets/externals\bin C:/Users/buildbot/
Projets/externals\lib C:\disk\amose-buildbot-worker\lima-master-
windows-10\Dist\master\Release\bin C:\disk\amose-buildbot-worker\lima-master-
windows-10\Dist\master\Release\lib "C:\Program Files (x86)\MSBuild\14.0\bin
\amd64" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64" C:
\Windows\Microsoft.NET\Framework64\v4.0.30319 C:\Windows\Microsoft.NET
\Framework64 "C:\Program Files (x86)\Windows Kits\8.1\bin\x64" "C:\Program 
Files (x86)\Windows Kits\8.1\bin\x86" c:\d\bin c:\d\share\apps\lima\scripts C:
\Qt\Qt5.6.3\5.6.3\msvc2015_64\bin %BOOST_LIBRARYDIR% c:\msys64\usr\bin C:
\ProgramData\chocolatey\lib\msys2 C:\tools\msys64 C:\tools\msys64\usr\bin "C:
\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs
\Microsoft.UniversalCRT.Debug\10.0.10240.0\Redist\Debug\x86" C:
\Python36\Scripts C:\Python36 C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS
\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\ProgramData
\chocolatey\bin "C:\Program Files\Git\cmd" "C:\Program Files (x86)\Windows 
Kits\8.1\Windows Performance Toolkit" C:\local\boost_1_58_0\lib64-msvc-12.0 
"C:\Program Files\CMake\bin" C:\Strawberry\c\bin C:\Strawberry\perl\site\bin 
C:\Strawberry\perl\bin "C:\Program Files\Java\jdk1.8.0_162\bin" C:\Users
\buildbot\AppData\Local\Microsoft\WindowsApps c:\Qt\Qt5.6.3\5.6.3\msvc2015_64 
c:\python36\lib\site-packages\pypiwin32_system32 -DENVPERL5LIB:STRING=C:/disk/
amose-buildbot-worker/lima-master-windows-10/Sources/lima_pelf/evalPosTagging/
SVM/SVMTool-1.3.1/lib: -GNinja C:/disk/amose-buildbot-worker/lima-master-
windows-10/Sources/lima_common/ && "C:\Program Files\CMake\bin\cmake.exe" -E 
touch Z:/b/lima_common/src/lima_common-stamp/lima_common-configure"
ninja: build stopped: subcommand failed.
program finished with exit code 1
elapsedTime=18.751174

Environment variables are the same at both configure and build steps.

Here is the code of the externalproject_add (from a macro, thus the 
variables):
  ## Add external project
  ExternalProject_Add(
    ${_project}
    PREFIX "${_project}"
    DOWNLOAD_COMMAND ""
    PATCH_COMMAND ""
    UPDATE_COMMAND ""
    SOURCE_DIR ${CMAKE_SOURCE_DIR}/${_project}/
    INSTALL_DIR $ENV{LIMA_DIST}
    USES_TERMINAL_DOWNLOAD 1
    USES_TERMINAL_UPDATE 1
    USES_TERMINAL_CONFIGURE 1
    USES_TERMINAL_BUILD 1
    USES_TERMINAL_TEST 1
    USES_TERMINAL_INSTALL 1
    TEST_AFTER_INSTALL 1
    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=$ENV{LIMA_DIST} 
        -DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE} 
        -DLIMA_VERSION_RELEASE:STRING="${LIMA_VERSION_RELEASE}" 
        -DBoost_DEBUG=ON 
        -DWITH_ASAN:BOOL=${WITH_ASAN} 
        -DWITH_ARCH:BOOL=${WITH_ARCH} 
        -DSHORTEN_POR_CORPUS_FOR_SVMLEARN:BOOL=$
{SHORTEN_POR_CORPUS_FOR_SVMLEARN}
        -DCMAKE_IGNORE_PATH=${CMAKE_IGNORE_PATH}
        -DCMAKE_CXX_FLAGS:STRING=${CMAKE_CXX_FLAGS}
        -DCMAKE_CXX_FLAGS_DEBUG:STRING=${CMAKE_CXX_FLAGS_DEBUG}
        -DCMAKE_CXX_FLAGS_RELEASE:STRING=${CMAKE_CXX_FLAGS_RELEASE}
        -DBOOST_ROOT:STRING=${BOOST_ROOT}
        -DBOOST_LIBRARYDIR:STRING=${BOOST_LIBRARYDIR}
        -DENVPATH:STRING=$ENV{PATH}
        -DENVPERL5LIB:STRING=$ENV{PERL5LIB}
  )

Any idea of what to search for next ?

Best regards,

Ga?l
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3493 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/6bc344c2/attachment.bin>

From kartikay000555000 at gmail.com  Wed Jan 31 12:29:42 2018
From: kartikay000555000 at gmail.com (kartikay gupta)
Date: Wed, 31 Jan 2018 22:59:42 +0530
Subject: [CMake] (no subject)
Message-ID: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>

Hi

I want to install cmake 3.10 to my institute high performace computing
without root access, in local directory. I am able to install it, but still
when I call the command 'cmake .. -DUSE_CUDA=ON' , it asks to upgrade cmake
to atleast 3.5.
What should be done to load cmake 3.10?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/e650c19f/attachment.html>

From saadrustam at gmail.com  Wed Jan 31 12:36:24 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Wed, 31 Jan 2018 17:36:24 +0000
Subject: [CMake] Relaying all command line arguments from SuperBuild to
 ExternalProject_Add
Message-ID: <CAEM70sO+z_ontZezsxt_aqeZsboZrdPxp2d5g+5984cjCoA5zg@mail.gmail.com>

I have the following setup:
Superbuild
   - ExternalProject_Add(a...)
   - ExternalProject_Add(b...)
   - ExternalProject_Add(c...)
   - ExternalProject_Add(d...)

The SuperBuild is built from command line with some options e.g.
-DMY_OPTION=TRUE. I would like all these options to be passed to each of
the ExternalProject_Add CMAKE_ARGS.

I tried to capture the arguments using the solution posted here:
https://stackoverflow.com/a/10218582/368599

The arguments are captured properly (i.e. I printed them out to make sure
they are correct) but relaying them to ExternalProject_Add appears to be
problematic. I tried the following ways to forward the arguments (as
outlined in the stackoverflow solution):

ExternalProject_Add(...
  CMAKE_ARGS ${CMAKE_ARGS}
  )

ExternalProject_Add(...
  CMAKE_ARGS "${CMAKE_ARGS}" # quotes
  )

ExternalProject_Add(...
  CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
conflicts
  )

None of that seems to work. CMake appears to ignore the commands forwarded.

Is there something I am missing?

Thanks,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/3d6b23c1/attachment.html>

From eric.noulard at gmail.com  Wed Jan 31 12:46:56 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 31 Jan 2018 18:46:56 +0100
Subject: [CMake] (no subject)
In-Reply-To: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
References: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
Message-ID: <CAPASGLoN4N+ej7B5D2eOdfTaCsajjPQwNkrwhb=txAU7Rsc_xw@mail.gmail.com>

2018-01-31 18:29 GMT+01:00 kartikay gupta <kartikay000555000 at gmail.com>:

> Hi
>
> I want to install cmake 3.10 to my institute high performace computing
> without root access, in local directory. I am able to install it, but still
> when I call the command 'cmake .. -DUSE_CUDA=ON' , it asks to upgrade cmake
> to atleast 3.5.
> What should be done to load cmake 3.10?
>

You should use the complete path to your locally installed cmake (or change
your path).

i.e. something like:

/home/kartikay/local/cmake/bin/cmake .. -DUSE_CUDA=ON


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/66ffdae9/attachment.html>

From kartikay000555000 at gmail.com  Wed Jan 31 12:48:03 2018
From: kartikay000555000 at gmail.com (kartikay gupta)
Date: Wed, 31 Jan 2018 23:18:03 +0530
Subject: [CMake] (no subject)
In-Reply-To: <CAPASGLoN4N+ej7B5D2eOdfTaCsajjPQwNkrwhb=txAU7Rsc_xw@mail.gmail.com>
References: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
 <CAPASGLoN4N+ej7B5D2eOdfTaCsajjPQwNkrwhb=txAU7Rsc_xw@mail.gmail.com>
Message-ID: <CADKYkAPXnEMthQcsFabKhtgz0Ff8rDeUf0e4pRXj26eMnHpN6w@mail.gmail.com>

yes, I got it. Thanks.

On Wed, Jan 31, 2018 at 11:16 PM, Eric Noulard <eric.noulard at gmail.com>
wrote:

>
>
> 2018-01-31 18:29 GMT+01:00 kartikay gupta <kartikay000555000 at gmail.com>:
>
>> Hi
>>
>> I want to install cmake 3.10 to my institute high performace computing
>> without root access, in local directory. I am able to install it, but still
>> when I call the command 'cmake .. -DUSE_CUDA=ON' , it asks to upgrade cmake
>> to atleast 3.5.
>> What should be done to load cmake 3.10?
>>
>
> You should use the complete path to your locally installed cmake (or
> change your path).
>
> i.e. something like:
>
> /home/kartikay/local/cmake/bin/cmake .. -DUSE_CUDA=ON
>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/83ad9306/attachment.html>

From marco.schuler at gmail.com  Wed Jan 31 12:52:02 2018
From: marco.schuler at gmail.com (Marco Schuler)
Date: Wed, 31 Jan 2018 17:52:02 +0000
Subject: [CMake] (no subject)
In-Reply-To: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
References: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
Message-ID: <CAEHCvasZV-uwQGohzR6OrJjHsU=JQY3FEwaTA5pgvHT9gytSZw@mail.gmail.com>

In your cmakelists.txt search for cmake_minumum_required and replace the
version with the version of cmake that you have installed. You might be
lucky and your program compiles.

P.S.: Please do not leave empty the subject of your e-mail...

Am 31.01.2018 18:29 schrieb "kartikay gupta" <kartikay000555000 at gmail.com>:

> Hi
>
> I want to install cmake 3.10 to my institute high performace computing
> without root access, in local directory. I am able to install it, but still
> when I call the command 'cmake .. -DUSE_CUDA=ON' , it asks to upgrade cmake
> to atleast 3.5.
> What should be done to load cmake 3.10?
>
>
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/74962e0b/attachment.html>

From d3ck0r at gmail.com  Wed Jan 31 15:27:14 2018
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 31 Jan 2018 12:27:14 -0800
Subject: [CMake] Relaying all command line arguments from SuperBuild to
 ExternalProject_Add
In-Reply-To: <CAEM70sO+z_ontZezsxt_aqeZsboZrdPxp2d5g+5984cjCoA5zg@mail.gmail.com>
References: <CAEM70sO+z_ontZezsxt_aqeZsboZrdPxp2d5g+5984cjCoA5zg@mail.gmail.com>
Message-ID: <CAA2GJqWiyeohJ-DT0V4+jeRTYcw+XG8pmXHR9GFObpyimd6R-A@mail.gmail.com>

(platfrom defines is a variable suitable for like ADD_DEFINITIONS(
${PLATFORM_DEFINES} )


  string( REPLACE ";" " " PLATFORM_DEFINES_ARG "${PLATFORM_DEFINES}" )
  ExternalProject_Add( target
    ....
CMAKE_ARGS -DPLATFORM_DEFINES=${PLATFORM_DEFINES_ARG}
    ......
 )


and in the target cmakelists to use the argument


STRING( REPLACE " " ";" PLATFORM_DEFINES ${PLATFORM_DEFINES} )

add_definitions( ${PLATFORM_DEFINES} )



On Wed, Jan 31, 2018 at 9:36 AM, Saad Khattak <saadrustam at gmail.com> wrote:

> I have the following setup:
> Superbuild
>    - ExternalProject_Add(a...)
>    - ExternalProject_Add(b...)
>    - ExternalProject_Add(c...)
>    - ExternalProject_Add(d...)
>
> The SuperBuild is built from command line with some options e.g.
> -DMY_OPTION=TRUE. I would like all these options to be passed to each of
> the ExternalProject_Add CMAKE_ARGS.
>
> I tried to capture the arguments using the solution posted here:
> https://stackoverflow.com/a/10218582/368599
>
> The arguments are captured properly (i.e. I printed them out to make sure
> they are correct) but relaying them to ExternalProject_Add appears to be
> problematic. I tried the following ways to forward the arguments (as
> outlined in the stackoverflow solution):
>
> ExternalProject_Add(...
>   CMAKE_ARGS ${CMAKE_ARGS}
>   )
>
> ExternalProject_Add(...
>   CMAKE_ARGS "${CMAKE_ARGS}" # quotes
>   )
>
> ExternalProject_Add(...
>   CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
> conflicts
>   )
>
> None of that seems to work. CMake appears to ignore the commands forwarded.
>
> Is there something I am missing?
>
> Thanks,
> Saad
>
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/a4e586b0/attachment-0001.html>

From kris.f.thielemans at gmail.com  Wed Jan 31 15:37:39 2018
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Wed, 31 Jan 2018 20:37:39 -0000
Subject: [CMake] (no subject)
In-Reply-To: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
References: <CADKYkAPAnde5E5enmKtAE15NnH2V-d9iOPYSN3sb7JDN+7NJRQ@mail.gmail.com>
Message-ID: <00ff01d39ad3$561cc7a0$025656e0$@gmail.com>

You have to specify the full path to the locally installed cmake, or add its location to your PATH environment variables (before anything else)

 

ATB

Kris

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of kartikay gupta
Sent: 31 January 2018 17:30
To: cmake at cmake.org
Subject: [CMake] (no subject)

 

Hi

 

I want to install cmake 3.10 to my institute high performace computing without root access, in local directory. I am able to install it, but still when I call the command 'cmake .. -DUSE_CUDA=ON' , it asks to upgrade cmake to atleast 3.5. 

What should be done to load cmake 3.10?

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/aebe7435/attachment.html>

From saadrustam at gmail.com  Wed Jan 31 21:47:54 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Thu, 01 Feb 2018 02:47:54 +0000
Subject: [CMake] Relaying all command line arguments from SuperBuild to
 ExternalProject_Add
In-Reply-To: <CAA2GJqWiyeohJ-DT0V4+jeRTYcw+XG8pmXHR9GFObpyimd6R-A@mail.gmail.com>
References: <CAEM70sO+z_ontZezsxt_aqeZsboZrdPxp2d5g+5984cjCoA5zg@mail.gmail.com>
 <CAA2GJqWiyeohJ-DT0V4+jeRTYcw+XG8pmXHR9GFObpyimd6R-A@mail.gmail.com>
Message-ID: <CAEM70sOXsjUdJ0BYeKKeAULYwOBZk0iCuCbBwTXPOxAMiNxQnQ@mail.gmail.com>

Thanks J. I could use that to add preprocessor definitions.

However, my question was how I could forward 'all' the command line options
that the user uses to generate the SuperBuild project. Suppose I somehow
managed to capture all the command line arguments which can include
variables specific to CMake and/or projects (i.e. nothing to do with
preprocessor definitions) in a variable called CL_CMAKE_ARGS.

If I do message(${CL_CMAKE_ARGS}) I get:

 -DMY_OPTION_ONE=ON -DMY_OPTION_TWO=OFF -DSOME_VAR_1="Foo"

Now, when I try something like this:

ExternalProject_Add(target
...
CMAKE_ARGS ${CL_CMAKE_ARGS}
...
)

One would expect CL_CMAKE_ARGS to be expanded and the arguments passed to
the ExternalProject_Add function, but that is not the case. I also tried:

ExternalProject_Add(target
...
CMAKE_ARGS "${CL_CMAKE_ARGS}"
...
)

Neither works. It seems like a bug in CMake but I wanted to confirm that I
am not missing something.

On Wed, Jan 31, 2018 at 3:27 PM J Decker <d3ck0r at gmail.com> wrote:

>
> (platfrom defines is a variable suitable for like ADD_DEFINITIONS(
> ${PLATFORM_DEFINES} )
>
>
>   string( REPLACE ";" " " PLATFORM_DEFINES_ARG "${PLATFORM_DEFINES}" )
>   ExternalProject_Add( target
>     ....
> CMAKE_ARGS -DPLATFORM_DEFINES=${PLATFORM_DEFINES_ARG}
>     ......
>  )
>
>
> and in the target cmakelists to use the argument
>
>
> STRING( REPLACE " " ";" PLATFORM_DEFINES ${PLATFORM_DEFINES} )
>
> add_definitions( ${PLATFORM_DEFINES} )
>
>
>
> On Wed, Jan 31, 2018 at 9:36 AM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
>> I have the following setup:
>> Superbuild
>>    - ExternalProject_Add(a...)
>>    - ExternalProject_Add(b...)
>>    - ExternalProject_Add(c...)
>>    - ExternalProject_Add(d...)
>>
>> The SuperBuild is built from command line with some options e.g.
>> -DMY_OPTION=TRUE. I would like all these options to be passed to each of
>> the ExternalProject_Add CMAKE_ARGS.
>>
>> I tried to capture the arguments using the solution posted here:
>> https://stackoverflow.com/a/10218582/368599
>>
>> The arguments are captured properly (i.e. I printed them out to make sure
>> they are correct) but relaying them to ExternalProject_Add appears to be
>> problematic. I tried the following ways to forward the arguments (as
>> outlined in the stackoverflow solution):
>>
>> ExternalProject_Add(...
>>   CMAKE_ARGS ${CMAKE_ARGS}
>>   )
>>
>> ExternalProject_Add(...
>>   CMAKE_ARGS "${CMAKE_ARGS}" # quotes
>>   )
>>
>> ExternalProject_Add(...
>>   CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
>> conflicts
>>   )
>>
>> None of that seems to work. CMake appears to ignore the commands
>> forwarded.
>>
>> Is there something I am missing?
>>
>> Thanks,
>> Saad
>>
>>
>> --
>>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/8656ec4b/attachment.html>

From hintonda at gmail.com  Wed Jan 31 22:14:20 2018
From: hintonda at gmail.com (Don Hinton)
Date: Wed, 31 Jan 2018 19:14:20 -0800
Subject: [CMake] Relaying all command line arguments from SuperBuild to
 ExternalProject_Add
In-Reply-To: <CAEM70sOXsjUdJ0BYeKKeAULYwOBZk0iCuCbBwTXPOxAMiNxQnQ@mail.gmail.com>
References: <CAEM70sO+z_ontZezsxt_aqeZsboZrdPxp2d5g+5984cjCoA5zg@mail.gmail.com>
 <CAA2GJqWiyeohJ-DT0V4+jeRTYcw+XG8pmXHR9GFObpyimd6R-A@mail.gmail.com>
 <CAEM70sOXsjUdJ0BYeKKeAULYwOBZk0iCuCbBwTXPOxAMiNxQnQ@mail.gmail.com>
Message-ID: <CAL2T-v7Yj21Xs+CZ5ukwMqEj1V9qYxXA3yEsieNbGQpZLKZsGg@mail.gmail.com>

Hi Saad:

On Wed, Jan 31, 2018 at 6:47 PM, Saad Khattak <saadrustam at gmail.com> wrote:

> Thanks J. I could use that to add preprocessor definitions.
>
> However, my question was how I could forward 'all' the command line
> options that the user uses to generate the SuperBuild project. Suppose I
> somehow managed to capture all the command line arguments which can include
> variables specific to CMake and/or projects (i.e. nothing to do with
> preprocessor definitions) in a variable called CL_CMAKE_ARGS.
>

The example you are using is close, but not quite correct.

You need to harvest the comandline arguments before calling `project()`,
just note that it won't work if CMakeCache.txt already exists.

Some CMAKE variables will still have HELPSTRINGS, even if passed via the
command line, and users can also set a random or blank HELPSTRING if they
use a cache file.  To overcome these issues, just harvest all cache
variables and exclude the invariant ones, e.g., CMAKE_COMMAND, etc., e.g.:

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.5)

message(STATUS "*** All CACHE_VARIABLES ***")
get_cmake_property(vars CACHE_VARIABLES)
foreach(var ${vars})
  get_property(currentHelpString CACHE "${var}" PROPERTY HELPSTRING)
        message("${var} = [${${var}}]  --  ${currentHelpString}")
endforeach()

project(xxx)
message(STATUS "project() called.")

message(STATUS "*** Only CACHE_VARIABLES with HELPSTRING empty or matching
\"No help,...\" ***")
get_cmake_property(vars CACHE_VARIABLES)
foreach(var ${vars})
  get_property(currentHelpString CACHE "${var}" PROPERTY HELPSTRING)
        if("${currentHelpString}" MATCHES "No help, variable specified on
the command line." OR "${currentHelpString}" STREQUAL "")
                message("${var} = [${${var}}]  --  ${currentHelpString}")
        endif()
endforeach()

$ rm -rf * && cmake -DFOO=1 -DCMAKE_BUILD_TYPE=Release -GNinja ..
-- *** All CACHE_VARIABLES ***
CMAKE_BUILD_TYPE = [Release]  --  No help, variable specified on the
command line.
CMAKE_COMMAND = [/opt/local/bin/cmake]  --  Path to CMake executable.
CMAKE_CPACK_COMMAND = [/opt/local/bin/cpack]  --  Path to cpack program
executable.
CMAKE_CTEST_COMMAND = [/opt/local/bin/ctest]  --  Path to ctest program
executable.
CMAKE_EXTRA_GENERATOR = []  --  Name of external makefile project generator.
CMAKE_GENERATOR = [Ninja]  --  Name of generator.
CMAKE_GENERATOR_PLATFORM = []  --  Name of generator platform.
CMAKE_GENERATOR_TOOLSET = []  --  Name of generator toolset.
CMAKE_HOME_DIRECTORY = [/Users/dhinton/cmake_test]  --  Source directory
with the top level CMakeLists.txt file for this project
CMAKE_ROOT = [/opt/local/share/cmake-3.10]  --  Path to CMake installation.
FOO = [1]  --  No help, variable specified on the command line.
-- The C compiler identification is AppleClang 9.0.0.9000039
-- The CXX compiler identification is AppleClang 9.0.0.9000039
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- project() called.
-- *** Only CACHE_VARIABLES with HELPSTRING empty or matching "No help,..."
***
FOO = [1]  --  No help, variable specified on the command line.
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/dhinton/cmake_test/build

hth...
don


> If I do message(${CL_CMAKE_ARGS}) I get:
>
>  -DMY_OPTION_ONE=ON -DMY_OPTION_TWO=OFF -DSOME_VAR_1="Foo"
>
> Now, when I try something like this:
>
> ExternalProject_Add(target
> ...
> CMAKE_ARGS ${CL_CMAKE_ARGS}
> ...
> )
>
> One would expect CL_CMAKE_ARGS to be expanded and the arguments passed to
> the ExternalProject_Add function, but that is not the case. I also tried:
>
> ExternalProject_Add(target
> ...
> CMAKE_ARGS "${CL_CMAKE_ARGS}"
> ...
> )
>
> Neither works. It seems like a bug in CMake but I wanted to confirm that I
> am not missing something.
>
> On Wed, Jan 31, 2018 at 3:27 PM J Decker <d3ck0r at gmail.com> wrote:
>
>>
>> (platfrom defines is a variable suitable for like ADD_DEFINITIONS(
>> ${PLATFORM_DEFINES} )
>>
>>
>>   string( REPLACE ";" " " PLATFORM_DEFINES_ARG "${PLATFORM_DEFINES}" )
>>   ExternalProject_Add( target
>>     ....
>> CMAKE_ARGS -DPLATFORM_DEFINES=${PLATFORM_DEFINES_ARG}
>>     ......
>>  )
>>
>>
>> and in the target cmakelists to use the argument
>>
>>
>> STRING( REPLACE " " ";" PLATFORM_DEFINES ${PLATFORM_DEFINES} )
>>
>> add_definitions( ${PLATFORM_DEFINES} )
>>
>>
>>
>> On Wed, Jan 31, 2018 at 9:36 AM, Saad Khattak <saadrustam at gmail.com>
>> wrote:
>>
>>> I have the following setup:
>>> Superbuild
>>>    - ExternalProject_Add(a...)
>>>    - ExternalProject_Add(b...)
>>>    - ExternalProject_Add(c...)
>>>    - ExternalProject_Add(d...)
>>>
>>> The SuperBuild is built from command line with some options e.g.
>>> -DMY_OPTION=TRUE. I would like all these options to be passed to each of
>>> the ExternalProject_Add CMAKE_ARGS.
>>>
>>> I tried to capture the arguments using the solution posted here:
>>> https://stackoverflow.com/a/10218582/368599
>>>
>>> The arguments are captured properly (i.e. I printed them out to make
>>> sure they are correct) but relaying them to ExternalProject_Add appears to
>>> be problematic. I tried the following ways to forward the arguments (as
>>> outlined in the stackoverflow solution):
>>>
>>> ExternalProject_Add(...
>>>   CMAKE_ARGS ${CMAKE_ARGS}
>>>   )
>>>
>>> ExternalProject_Add(...
>>>   CMAKE_ARGS "${CMAKE_ARGS}" # quotes
>>>   )
>>>
>>> ExternalProject_Add(...
>>>   CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
>>> conflicts
>>>   )
>>>
>>> None of that seems to work. CMake appears to ignore the commands
>>> forwarded.
>>>
>>> Is there something I am missing?
>>>
>>> Thanks,
>>> Saad
>>>
>>>
>>> --
>>>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180131/94277acb/attachment-0001.html>

From saadrustam at gmail.com  Wed Jan 31 22:51:14 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Thu, 01 Feb 2018 03:51:14 +0000
Subject: [CMake] Relaying all command line arguments from SuperBuild to
 ExternalProject_Add
In-Reply-To: <CAL2T-v7Yj21Xs+CZ5ukwMqEj1V9qYxXA3yEsieNbGQpZLKZsGg@mail.gmail.com>
References: <CAEM70sO+z_ontZezsxt_aqeZsboZrdPxp2d5g+5984cjCoA5zg@mail.gmail.com>
 <CAA2GJqWiyeohJ-DT0V4+jeRTYcw+XG8pmXHR9GFObpyimd6R-A@mail.gmail.com>
 <CAEM70sOXsjUdJ0BYeKKeAULYwOBZk0iCuCbBwTXPOxAMiNxQnQ@mail.gmail.com>
 <CAL2T-v7Yj21Xs+CZ5ukwMqEj1V9qYxXA3yEsieNbGQpZLKZsGg@mail.gmail.com>
Message-ID: <CAEM70sPEHqt=HoxztemQyhnCcyKnTwqBdTc5RCyD_7t-MkOYyw@mail.gmail.com>

Thank you Don, that was it. Querying and storing the args before a call to
'project' and your loop and your conditional were the key.

On Wed, Jan 31, 2018 at 10:14 PM Don Hinton <hintonda at gmail.com> wrote:

> Hi Saad:
>
> On Wed, Jan 31, 2018 at 6:47 PM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
>> Thanks J. I could use that to add preprocessor definitions.
>>
>> However, my question was how I could forward 'all' the command line
>> options that the user uses to generate the SuperBuild project. Suppose I
>> somehow managed to capture all the command line arguments which can include
>> variables specific to CMake and/or projects (i.e. nothing to do with
>> preprocessor definitions) in a variable called CL_CMAKE_ARGS.
>>
>
> The example you are using is close, but not quite correct.
>
> You need to harvest the comandline arguments before calling `project()`,
> just note that it won't work if CMakeCache.txt already exists.
>
> Some CMAKE variables will still have HELPSTRINGS, even if passed via the
> command line, and users can also set a random or blank HELPSTRING if they
> use a cache file.  To overcome these issues, just harvest all cache
> variables and exclude the invariant ones, e.g., CMAKE_COMMAND, etc., e.g.:
>
> $ cat ../CMakeLists.txt
> cmake_minimum_required(VERSION 3.5)
>
> message(STATUS "*** All CACHE_VARIABLES ***")
> get_cmake_property(vars CACHE_VARIABLES)
> foreach(var ${vars})
>   get_property(currentHelpString CACHE "${var}" PROPERTY HELPSTRING)
>         message("${var} = [${${var}}]  --  ${currentHelpString}")
> endforeach()
>
> project(xxx)
> message(STATUS "project() called.")
>
> message(STATUS "*** Only CACHE_VARIABLES with HELPSTRING empty or matching
> \"No help,...\" ***")
> get_cmake_property(vars CACHE_VARIABLES)
> foreach(var ${vars})
>   get_property(currentHelpString CACHE "${var}" PROPERTY HELPSTRING)
>         if("${currentHelpString}" MATCHES "No help, variable specified on
> the command line." OR "${currentHelpString}" STREQUAL "")
>                 message("${var} = [${${var}}]  --  ${currentHelpString}")
>         endif()
> endforeach()
>
> $ rm -rf * && cmake -DFOO=1 -DCMAKE_BUILD_TYPE=Release -GNinja ..
> -- *** All CACHE_VARIABLES ***
> CMAKE_BUILD_TYPE = [Release]  --  No help, variable specified on the
> command line.
> CMAKE_COMMAND = [/opt/local/bin/cmake]  --  Path to CMake executable.
> CMAKE_CPACK_COMMAND = [/opt/local/bin/cpack]  --  Path to cpack program
> executable.
> CMAKE_CTEST_COMMAND = [/opt/local/bin/ctest]  --  Path to ctest program
> executable.
> CMAKE_EXTRA_GENERATOR = []  --  Name of external makefile project
> generator.
> CMAKE_GENERATOR = [Ninja]  --  Name of generator.
> CMAKE_GENERATOR_PLATFORM = []  --  Name of generator platform.
> CMAKE_GENERATOR_TOOLSET = []  --  Name of generator toolset.
> CMAKE_HOME_DIRECTORY = [/Users/dhinton/cmake_test]  --  Source directory
> with the top level CMakeLists.txt file for this project
> CMAKE_ROOT = [/opt/local/share/cmake-3.10]  --  Path to CMake installation.
> FOO = [1]  --  No help, variable specified on the command line.
> -- The C compiler identification is AppleClang 9.0.0.9000039
> -- The CXX compiler identification is AppleClang 9.0.0.9000039
> -- Check for working C compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> -- Check for working C compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -- Check for working CXX compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- project() called.
> -- *** Only CACHE_VARIABLES with HELPSTRING empty or matching "No
> help,..." ***
> FOO = [1]  --  No help, variable specified on the command line.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/dhinton/cmake_test/build
>
> hth...
> don
>
>
>> If I do message(${CL_CMAKE_ARGS}) I get:
>>
>>  -DMY_OPTION_ONE=ON -DMY_OPTION_TWO=OFF -DSOME_VAR_1="Foo"
>>
>> Now, when I try something like this:
>>
>> ExternalProject_Add(target
>> ...
>> CMAKE_ARGS ${CL_CMAKE_ARGS}
>> ...
>> )
>>
>> One would expect CL_CMAKE_ARGS to be expanded and the arguments passed to
>> the ExternalProject_Add function, but that is not the case. I also tried:
>>
>> ExternalProject_Add(target
>> ...
>> CMAKE_ARGS "${CL_CMAKE_ARGS}"
>> ...
>> )
>>
>> Neither works. It seems like a bug in CMake but I wanted to confirm that
>> I am not missing something.
>>
>> On Wed, Jan 31, 2018 at 3:27 PM J Decker <d3ck0r at gmail.com> wrote:
>>
>>>
>>> (platfrom defines is a variable suitable for like ADD_DEFINITIONS(
>>> ${PLATFORM_DEFINES} )
>>>
>>>
>>>   string( REPLACE ";" " " PLATFORM_DEFINES_ARG "${PLATFORM_DEFINES}" )
>>>   ExternalProject_Add( target
>>>     ....
>>> CMAKE_ARGS -DPLATFORM_DEFINES=${PLATFORM_DEFINES_ARG}
>>>     ......
>>>  )
>>>
>>>
>>> and in the target cmakelists to use the argument
>>>
>>>
>>> STRING( REPLACE " " ";" PLATFORM_DEFINES ${PLATFORM_DEFINES} )
>>>
>>> add_definitions( ${PLATFORM_DEFINES} )
>>>
>>>
>>>
>>> On Wed, Jan 31, 2018 at 9:36 AM, Saad Khattak <saadrustam at gmail.com>
>>> wrote:
>>>
>>>> I have the following setup:
>>>> Superbuild
>>>>    - ExternalProject_Add(a...)
>>>>    - ExternalProject_Add(b...)
>>>>    - ExternalProject_Add(c...)
>>>>    - ExternalProject_Add(d...)
>>>>
>>>> The SuperBuild is built from command line with some options e.g.
>>>> -DMY_OPTION=TRUE. I would like all these options to be passed to each of
>>>> the ExternalProject_Add CMAKE_ARGS.
>>>>
>>>> I tried to capture the arguments using the solution posted here:
>>>> https://stackoverflow.com/a/10218582/368599
>>>>
>>>> The arguments are captured properly (i.e. I printed them out to make
>>>> sure they are correct) but relaying them to ExternalProject_Add appears to
>>>> be problematic. I tried the following ways to forward the arguments (as
>>>> outlined in the stackoverflow solution):
>>>>
>>>> ExternalProject_Add(...
>>>>   CMAKE_ARGS ${CMAKE_ARGS}
>>>>   )
>>>>
>>>> ExternalProject_Add(...
>>>>   CMAKE_ARGS "${CMAKE_ARGS}" # quotes
>>>>   )
>>>>
>>>> ExternalProject_Add(...
>>>>   CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
>>>> conflicts
>>>>   )
>>>>
>>>> None of that seems to work. CMake appears to ignore the commands
>>>> forwarded.
>>>>
>>>> Is there something I am missing?
>>>>
>>>> Thanks,
>>>> Saad
>>>>
>>>>
>>>> --
>>>>
>>>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/a3f8d1bc/attachment.html>