From davidklind at gmail.com  Fri Dec  1 10:47:55 2017
From: davidklind at gmail.com (DKLind)
Date: Fri, 1 Dec 2017 08:47:55 -0700 (MST)
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
Message-ID: <1512143275596-0.post@n2.nabble.com>

This is precisely my situation. I have a large project where 50+ packages are
generated. I wanted, needed, to be able to set each packages' version
uniquely. Using the CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION variable seemed
to be the correct way, except it doesn't work. My patch allows
CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION to be recognized by CPack and it's
value used when the package is created. The patch doesn't break the existing
functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see
of CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION is set. If it is, use it's
value. It isn't not set use the value of CPACK_PACKAGE_VERSION.



--
Sent from: http://cmake.3232098.n2.nabble.com/

From domen.vrankar at gmail.com  Fri Dec  1 11:50:36 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 1 Dec 2017 17:50:36 +0100
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
Message-ID: <CAKgx6BLjd10vko5fWMubBJVL-UCieVVAMcR7W1AKgRu9-GxoKQ@mail.gmail.com>

2017-12-01 5:41 GMT+01:00 Craig Scott <craig.scott at crascit.com>:

>
>
> On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar <domen.vrankar at gmail.com>
> wrote:
>
>> 2017-11-29 17:07 GMT+01:00 DKLind <davidklind at gmail.com>:
>>
>>> I have finally found time to work on a patch so
>>> CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION is recognized. I am amazed how
>>> simple the fix actually is.
>>>
>>> I plan on submitting a formal patch soon for Debian and RPM. I don't know
>>> anything about other CMake packaging features that might benefit from
>>> this
>>> patch.
>>>
>>
>> Hi,
>>
>> I've also been working on a bit larger feature extension that would
>> possibly be of interest to you: https://gitlab.kitware.com/cma
>> ke/cmake/merge_requests/1545
>>
>> I haven't decided on implementing per component versioning since it makes
>> no sense to version different components of the same release differently
>> unless they are a separate project which requires more variable overrides
>> and manual setting of components - ExternalProject seems a better
>> alternative in such cases. Maybe your solution can convince me otherwise.
>>
>
> An example where per-component versions would be really useful is if you
> have one large build that produces multiple products (i.e. one git repo and
> one CMake build). You may want to be able to create a release package for
> each product, but if each product has its own distinct version number, then
> you currently can't quite do it with CMake for some package types. I have
> exactly this situation at work at the moment. In one project, I get away
> with it because the release packages are tar balls so I just provide a
> custom name that embeds the version number for each product using
> CPACK_ARCHIVE_<component-name>_FILE_NAME. But I have other projects which
> produce RPMs and for those I don't currently have a solution.
>

The thing is that components are one package split into sub-packages which
are still connected under the same base package name so they should be of
the same version (e.g. I'd be surprised to download Boost rpm packages that
have different version for each component [filesystem, ASIO, Spirit, ...]
and still claim to be the same package group/release).

In super/uber build multiple projects require multiple packages of which
each can have sub-package components and in this case it is logical that
each project has its own package name, version, release notes, debug
package(s) etc.

This is what I'm trying to address with my MR that is work in progress for
now and since it requires changes not just to CPack but also CMake I've
pushed before I invest the time to write all the tests to see what other
people think about it.

As DKLind already found out the addition of per component overrides for
CPack Deb and RPM is trivial but for the past two years I've had the
(possibly misguided) opinion that the first/trivial solution is the wrong
one.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171201/7b2920dd/attachment-0001.html>

From domen.vrankar at gmail.com  Fri Dec  1 12:04:06 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 1 Dec 2017 18:04:06 +0100
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <1512143275596-0.post@n2.nabble.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
 <1512143275596-0.post@n2.nabble.com>
Message-ID: <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>

2017-12-01 16:47 GMT+01:00 DKLind <davidklind at gmail.com>:

> This is precisely my situation. I have a large project where 50+ packages
> are
> generated. I wanted, needed, to be able to set each packages' version
> uniquely. Using the CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION variable
> seemed
> to be the correct way, except it doesn't work. My patch allows
> CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION to be recognized by CPack and
> it's
> value used when the package is created. The patch doesn't break the
> existing
> functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see
> of CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION is set. If it is, use it's
> value. It isn't not set use the value of CPACK_PACKAGE_VERSION.
>

This is exactly what I've described in the reply to Craig. If projects are
related they should have the same version and release notes and if they
aren't and are instead just depending on each other (your case) they should
have a different package name with its own sub-packages, release notes and
versions. Simply changing the version and release notes but still
containing one base package name is confusing, hard to maintain and in my
opinion abusal of sub-packages as the Linux distros that use Rpm and Deb
packages know them.

This is a case where ExternalProject would be a valid choice but I'm
guessing that you decided against it as it causes issues when the projects
are still interdependent enough to warrant extension of functionality on
all (some) of them at the same time. This was the case on one of the
projects on which I've worked for a few years now where you have a core and
different modules that are installed at different clients but not all at
once (e.g. client one has modules 1, 2 and 3 while client two has 1, 3, 4
and 5). For such a project you can put everything into one project and
write "make install" which sets up your entire development environment
where you can test all the modules interacting with each other and make
improvements on them.

So my patch adds an alternative to ExternalProject for such cases but still
packages all of the projects as if they were stand alone projects - a
superbuild.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171201/7c1b170a/attachment.html>

From domen.vrankar at gmail.com  Fri Dec  1 12:46:08 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 1 Dec 2017 18:46:08 +0100
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
 <1512143275596-0.post@n2.nabble.com>
 <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>
Message-ID: <CAKgx6BLUSNRKFFgE-mtZQ+5OjynmWX_X8t6u=_VbvujmYeLzqQ@mail.gmail.com>

2017-12-01 18:04 GMT+01:00 Domen Vrankar <domen.vrankar at gmail.com>:

> 2017-12-01 16:47 GMT+01:00 DKLind <davidklind at gmail.com>:
>
>> This is precisely my situation. I have a large project where 50+ packages
>> are
>> generated. I wanted, needed, to be able to set each packages' version
>> uniquely. Using the CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION variable
>> seemed
>> to be the correct way, except it doesn't work. My patch allows
>> CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION to be recognized by CPack and
>> it's
>> value used when the package is created. The patch doesn't break the
>> existing
>> functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see
>> of CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION is set. If it is, use it's
>> value. It isn't not set use the value of CPACK_PACKAGE_VERSION.
>>
>
> This is exactly what I've described in the reply to Craig. If projects are
> related they should have the same version and release notes and if they
> aren't and are instead just depending on each other (your case) they should
> have a different package name with its own sub-packages, release notes and
> versions. Simply changing the version and release notes but still
> containing one base package name is confusing, hard to maintain and in my
> opinion abusal of sub-packages as the Linux distros that use Rpm and Deb
> packages know them.
>
> This is a case where ExternalProject would be a valid choice but I'm
> guessing that you decided against it as it causes issues when the projects
> are still interdependent enough to warrant extension of functionality on
> all (some) of them at the same time. This was the case on one of the
> projects on which I've worked for a few years now where you have a core and
> different modules that are installed at different clients but not all at
> once (e.g. client one has modules 1, 2 and 3 while client two has 1, 3, 4
> and 5). For such a project you can put everything into one project and
> write "make install" which sets up your entire development environment
> where you can test all the modules interacting with each other and make
> improvements on them.
>
> So my patch adds an alternative to ExternalProject for such cases but
> still packages all of the projects as if they were stand alone projects - a
> superbuild.
>

Craig, David the usual (expected) way of packaging things is (per package
group versioning - currently supported and what my MR enables):

product_1-component_1-1.0.0
product_1-component_2-1.0.0
product_2-component_1-3.5.7
product_2-component_2-3.5.7

And what you are suggesting is (per component versioning):

distro_or_company-product_1-1.0.0
distro_or_company-product_2-3.5.7

On the product where I worked the compromise was to package:

product-component_1_1-1.0.0_3.5.7
product-component_1_2-1.0.0_3.5.7
product-component_2_1-1.0.0_3.5.7
product-component_2_2-1.0.0_3.5.7

Which I would say that it's a bad solution but it gave us what we needed -
group of products that can be built and tested together without a
combination of ExternalProject commands and a build_all.sh script, have
components but their versions increase independently.

The first option is supported by the intuitive use of Linux distributions
by simply running something like "sudo apt search libboost" but it's
possible that the alternative way of packaging is possibly also feasible
for others (and what we did is simply an ugly compromise hack when you need
to hurry and don't want to extend CPack).

Given all of this and if both my proposal and the alternative would be
already implemented in CMake/CPack would you be using the alternative
version from time to time or not?

The alternative would be from my point of view confusing and would probably
add additional custom CPack variable per-component override requirements
but if you think that it would be useful or if my MR is too far off from
where CMake should be going it would still be feasible to implement the per
component version/release notes override.

What do you think?

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171201/e02131a6/attachment.html>

From sebastianspublicaddress at googlemail.com  Fri Dec  1 15:44:38 2017
From: sebastianspublicaddress at googlemail.com (Sebastian)
Date: Fri, 1 Dec 2017 21:44:38 +0100
Subject: [CMake] Which targets are affected by
 CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE?
Message-ID: <20171201214438.00001807@googlemail.com>

Hi,

The documentation https://cmake.org/cmake/help/v3.10/variable/CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE.html
states "CMake automatically adds for each ... target".

I assume the variable has directory scope. So it affects all targets in that directory? Or only targets which are created (by add_library, for example) AFTER setting the variable?
In other words: Which commands evaluates the variable? add_library? target_include_directories?

The documentation could be a bit more clear on this...

Thanks,
Sebastian

From kaba1729.ai at gmail.com  Sat Dec  2 03:12:06 2017
From: kaba1729.ai at gmail.com (Yusuf Kaba)
Date: Sat, 2 Dec 2017 09:12:06 +0100
Subject: [CMake] Use ExternalProject_Add to include Opus in Android
Message-ID: <CAHCF5tLqZjbJmXb3XvVoXtYe2UXcpF8KBP-GUz4URnpuSVRmVw@mail.gmail.com>

I have an Android project that uses NDK. I will like to include the opus
<https://opus-codec.org/downloads/> source code in the native code. I have
tried using the ExternalProject_Add property of CMake but my native code
still cannot import headers from the Opus library and fails to build.

Some of my native classes are dependent on the Opus source code. I was able
to include the Opus source using by adding a Makefile to the source and
including that in the Android.mk file so I want to do something similar
with CMake. Is it possible to include local sources in CMake and specify an
Android.mk file that will be used to build such sources.

Best,

NB: Here's my current ExternalProject_Add definition:

ExternalProject_Add(project_opus
  URL https://archive.mozilla.org/pub/opus/opus-1.2.1.tar.gz
  CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
  BUILD_COMMAND make
  INSTALL_COMMAND make install)
ExternalProject_Get_Property(project_opus install_dir)
include_directories(${install_dir}/include)

add_library(opus SHARED IMPORTED)
add_dependencies(opus project_opus)

target_link_libraries( # Specifies the target library.
                       native-lib

                       # Links the target library to the log library
                       # included in the NDK.
                       ${log-lib} opus oboe OpenSLES)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171202/3c9eede5/attachment-0001.html>

From cary at txcorp.com  Sat Dec  2 04:17:04 2017
From: cary at txcorp.com (JR Cary)
Date: Sat, 2 Dec 2017 02:17:04 -0700
Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015
In-Reply-To: <f47e7952-fd73-a2c5-bd5d-c1306df621f5@txcorp.com>
References: <f47e7952-fd73-a2c5-bd5d-c1306df621f5@txcorp.com>
Message-ID: <ebab065d-4458-e695-b245-3d95e160a2fd@txcorp.com>


> Does it work with 3.10?
?
It works with no version from  3.9.0 - 3.10.0.

> Also, look in the CMakeFiles/CMakeError.log file to find out why this 
> happened: - Detecting Fortran/C Interface - Failed to compile.

Compiling the Fortran compiler identification source file "CMakeFortranCompilerId.F" failed.
Compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe
Build flags:
Id flags: -v

The output was:
0
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.6.285 Build 20151119
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
ifort: command line warning #10006: ignoring unknown option '/v'

CMakeFortranCompilerId.F(2): warning #5117: Bad # preprocessor line
#if 0
...

Looks from https://stackoverflow.com/questions/36557120/usual-causes-for-bad-preprocessor-warning
that the preprocessor is not being run.  It requires -fpp to be added to the Fortran compiler
flags.  I do not see how to do that for CMakeFortranCompilerId.F.  Tried 

  set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fpp")

but that did not help. 



On 11/26/17 4:29 PM, JR Cary wrote:
> Works with 3.8.2.
>
> Compilers specified by
>
> -DCMAKE_C_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE
> 2015/bin/intel64/icl.exe' -DCMAKE_CXX_COMPILER:FILEPATH='C:/Program
> Files (x86)/Intel/Composer XE 2015/bin/intel64/icl.exe'
> -DCMAKE_Fortran_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer
> XE 2015/bin/intel64/ifort.exe'
>
> The cmake code is
>
> include(FortranCInterface)
> FortranCInterface_HEADER(
> ? ${CMAKE_BINARY_DIR}/FCMangle.h
> ? MACRO_NAMESPACE "FC_"
> ? SYMBOL_NAMESPACE "FC_"
> ? SYMBOLS mysub mymod:my_sub
> )
>
> The relevant output is
>
> -- Detecting Fortran/C Interface
> -- Detecting Fortran/C Interface - Failed to compile
> CMake Warning (dev) at
> C:/winsame/cary/usim/contrib-icl15/cmake-3.9.0-ser/share/
> cmake-3.9/Modules/FortranCInterface.cmake:309 (message):
> ? No FortranCInterface mangling known for mysub
> Call Stack (most recent call first):
> ? scimake/SciFortranChecks.cmake:269 (FortranCInterface_HEADER)
> ? scimake/SciInit.cmake:232 (include)
> ? CMakeLists.txt:28 (include)
> This warning is for project developers.? Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> C:/winsame/cary/usim/contrib-icl15/cmake-3.9.0-ser/share/
> cmake-3.9/Modules/FortranCInterface.cmake:295 (message):
> ? No FortranCInterface mangling known for mymod:my_sub
> Call Stack (most recent call first):
> ? scimake/SciFortranChecks.cmake:269 (FortranCInterface_HEADER)
> ? scimake/SciInit.cmake:232 (include)
> ? CMakeLists.txt:28 (include)
> This warning is for project developers.? Use -Wno-dev to suppress it.
>
> The resulting file is
>
> $ cat FCMangle.h
> #ifndef FC_HEADER_INCLUDED
> #define FC_HEADER_INCLUDED
>
> /*--------------------------------------------------------------------------*/
> /* Mangle some symbols
> automatically.?????????????????????????????????????? */
>
> #endif
>
> Any help appreciated..........John Cary
>
>
>
>


From carsten.fuchs at cafu.de  Mon Dec  4 05:36:33 2017
From: carsten.fuchs at cafu.de (Carsten Fuchs)
Date: Mon, 4 Dec 2017 11:36:33 +0100
Subject: [CMake] Using find_package() portably?
In-Reply-To: <b6564d37-4883-4831-d31e-e8b18ab8fc3e@gmail.com>
References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de>
 <5662152.4nPEXIznPt@ersa> <d918c66a-49f5-31cb-2146-4d996687905b@cafu.de>
 <3171356.xi6d4M9i8k@ersa> <b6564d37-4883-4831-d31e-e8b18ab8fc3e@gmail.com>
Message-ID: <773abfaf-9c9c-d2db-e37a-f8f58bd18344@cafu.de>

Thanks to all!

Well, I guess I'm among the people mentioned by Lectem at 
https://www.mail-archive.com/cmake-developers at cmake.org/msg18267.html

I'll try to dig my way through it, but at this point I consider staying 
with SCons under Linux, where finding packages is important and the 
command line is used anyway, and using CMake under Windows only, where 
quasi all external libraries are shipped along with the project and the 
real goal is to obtain a Visual Studio solution. (I already have a 
complete build with SCons that works under Windows and Linux for my 
project which is of average complexity.)

Best regards,
Carsten

$ ls Cafu/ExtLibs/ -1
bullet
Cg
fbx
fmod
freealut
freetype
glfw
jpeg
libogg
libpng
libvorbis
lua
lwo
MersenneTwister.h
minizip
mpg123
noise
openal-soft
openal-win
pstdint.h
tclap
wxWidgets
zlib



Am 29.11.2017 um 21:17 schrieb Florent Castelli:
> On 29/11/2017 12:02, Johannes Zarl-Zierl wrote:
>> Hello Carsten,
>>
>> On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote:
>>> Thanks for your reply, but how can I proceed from here?
>>>
>>> In order to be able to write in the parent script something that works
>>> in either case, that is,
>>>
>>> target_link_libraries(main_program <either JPEG::JPEG or ${JPEG...} 
>>> or ???>)
>> Well, that's one way, but that doesn't really provide any benefit 
>> above the
>> original solution (i.e. just define the JPEG_INCLUDES and JPEG_LIBRARIES
>> variables accordingly).
>>
>>> it seems that I either
>>>
>>> ??? - have to make a copy of FindJPEG.cmake, customize it to define
>>> target JPEG::JEPG and ship it along with my project,
>> Either that or you define it yourself:
>> find_package(JPEG)
>> if (JPEG_FOUND)
> 
> I'd say "if(JPEG_FOUND AND NOT TARGET JPEG::JPEG)"
> If someone improves FindJPEG.cmake, you won't break your build.
> 
>> ? add_library(JPEG::JPEG UNKNOWN IMPORTED)
>> ? set_property(
>> ?? TARGET JPEG::JPEG
>> ?? PROPERTY IMPORTED_LOCATION ${JPEG_LIBRARIES}
>> ?? )
>> ? set_property(
>> ?? TARGET JPEG::JPEG PROPERTY
>> ?? INTERFACE_INCLUDE_DIRECTORIES ${JPEG_INCLUDES}
>> ? )
>> endif()
>>
>> I admit it's not a huge benefit over just using the variables. The 
>> advantages:
>> - you get slightly better error handling
>> - your target_link_libraries commands are slightly more readable.
>>
>>> ??? - or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it 
>>> globally
>>> defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS
>> That will work, too.
>>
>>
>> Cheers,
>> ?? Johannes
>>
> 


From ramya.gopalkrishna at accoliteindia.com  Mon Dec  4 10:23:22 2017
From: ramya.gopalkrishna at accoliteindia.com (ramya.gopalkrishna at accoliteindia.com)
Date: Mon, 4 Dec 2017 20:53:22 +0530
Subject: [CMake] [CMAKE] -  custom compiler for Android
Message-ID: <000601d36d13$d629dbb0$827d9310$@accoliteindia.com>

HI All,

 

I am reposting the below email. Any help is highly appreciated. 

 

We are working towards creating a toolchain file for an ANDROID compiler

 

We understand that the flow in CMAKE, when CMAKE_SYSTEM_NAME is specified in
Android is different when compared to specifying CMAKE_SYSTEM_NAME as IOS or
LINUX

 

Please validate our current understanding when a toolchain file or
command-line option sets CMAKE_SYSTEM_NAME to "Android" 

 

*	CMakeDetermineSystem.cmake loads this file:
Android-Determine.cmake
*	Next is the platform-specific initialization step:
CMakeSystemSpecificInitialize.cmake which loads Android-Initialize.cmake to
select the sysroot.
*	A "determine" step also runs for each language when it is first
enabled in a new build tree:

 

Android-Determine-C.cmake

Android-Determine-CXX.cmake

 

*	The language files go here:

 

Determine-Compiler.cmake

Determine-Compiler-NDK.cmake

 

*	The latter file is where we parse a bunch of information from the
NDK.

The results persist in CMakeFiles/$v/CMake${lang}Compiler.cmake for future
runs.

 

Next is the language-specific initialization step. For  Example - in case
{lang} is C :     CMakeCInformation.cmake

 

That loads one of these:

 

Android-GNU-C.cmake

Android-Clang-C.cmake

 

which loads one of these:

 

Android-GNU.cmake

Android-Clang.cmake  

 

Determine-Compiler-NDK.cmake is where cmake looks for versions of clang or
gcc or llvm toolchains and sets the appropriate compiler.

 

 

Our Requirement and Problem statement

When we tried manually setting a c and cxx compiler from a toolchain file,
cmake would not allow us to point to our own compilers. Ideally, we want our
toolchain file to tell cmake the libraries to include/link and the compilers
to use. But once, System has been determined as android, cmake goes through
the above sequence of events and expects toolchains to be specified for
either clang, gcc or llvm compilers.

 

We would probably need to make changes in the following files to accommodate
cmake to use our own compilers.

Determine-Compiler-NDK.cmake  - We would need to add support for an
"NewCompiler Toolchain" which would contain android libraries and compilers.

 

New Android-{NewCompiler}-C.cmake, Android-{ NewCompiler }-CXX.cmake,
Android-{ NewCompiler }.cmake and another appropriate toolchain file to set
target architecture and compiler flags.

 

 

Can you please provide your suggestions and validate the understanding as
well

 

Thanks & Regards,

Ramya

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171204/fca5840a/attachment.html>

From davidklind at gmail.com  Mon Dec  4 13:57:24 2017
From: davidklind at gmail.com (DKLind)
Date: Mon, 4 Dec 2017 11:57:24 -0700 (MST)
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <CAKgx6BLUSNRKFFgE-mtZQ+5OjynmWX_X8t6u=_VbvujmYeLzqQ@mail.gmail.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
 <1512143275596-0.post@n2.nabble.com>
 <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>
 <CAKgx6BLUSNRKFFgE-mtZQ+5OjynmWX_X8t6u=_VbvujmYeLzqQ@mail.gmail.com>
Message-ID: <1512413844802-0.post@n2.nabble.com>

Domen Vrankar wrote
> product_1-component_1-1.0.0
> product_1-component_2-1.0.0
> product_2-component_1-3.5.7
> product_2-component_2-3.5.7

This too is what my patch fixes. Attached is the patch.

CPackDeb.patch
<http://cmake.3232098.n2.nabble.com/file/t397522/CPackDeb.patch>  



--
Sent from: http://cmake.3232098.n2.nabble.com/

From domen.vrankar at gmail.com  Mon Dec  4 14:08:38 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 4 Dec 2017 20:08:38 +0100
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <1512413844802-0.post@n2.nabble.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
 <1512143275596-0.post@n2.nabble.com>
 <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>
 <CAKgx6BLUSNRKFFgE-mtZQ+5OjynmWX_X8t6u=_VbvujmYeLzqQ@mail.gmail.com>
 <1512413844802-0.post@n2.nabble.com>
Message-ID: <CAKgx6BKauzzGzKti96sdVnbxZPGZjs681wp-pcHHpOjz+mcFpw@mail.gmail.com>

2017-12-04 19:57 GMT+01:00 DKLind <davidklind at gmail.com>:

> Domen Vrankar wrote
> > product_1-component_1-1.0.0
> > product_1-component_2-1.0.0
> > product_2-component_1-3.5.7
> > product_2-component_2-3.5.7
>
> This too is what my patch fixes. Attached is the patch.
>
> CPackDeb.patch
> <http://cmake.3232098.n2.nabble.com/file/t397522/CPackDeb.patch>
>

I'm a bit confused. Is there something missing in the patch?
Attached patch only adds per component version override - it doesn't even
touch the multiple calls to `include(CPack)` and naming of different
packages (not their components but different package names).

Could you please provide a simple example of the intended use for packaging
of multiple packages with multiple sub-packages?

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171204/06d35bfe/attachment.html>

From davidklind at gmail.com  Mon Dec  4 14:35:39 2017
From: davidklind at gmail.com (DKLind)
Date: Mon, 4 Dec 2017 12:35:39 -0700 (MST)
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <CAKgx6BKauzzGzKti96sdVnbxZPGZjs681wp-pcHHpOjz+mcFpw@mail.gmail.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
 <1512143275596-0.post@n2.nabble.com>
 <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>
 <CAKgx6BLUSNRKFFgE-mtZQ+5OjynmWX_X8t6u=_VbvujmYeLzqQ@mail.gmail.com>
 <1512413844802-0.post@n2.nabble.com>
 <CAKgx6BKauzzGzKti96sdVnbxZPGZjs681wp-pcHHpOjz+mcFpw@mail.gmail.com>
Message-ID: <1512416139330-0.post@n2.nabble.com>

Domen Vrankar wrote
> I'm a bit confused. Is there something missing in the patch?
> Attached patch only adds per component version override - it doesn't even
> touch the multiple calls to `include(CPack)` and naming of different
> packages (not their components but different package names).
> 
> Could you please provide a simple example of the intended use for
> packaging
> of multiple packages with multiple sub-packages?

I have a macro that each sub-project calls. See package macro below.

Each sub project calls CMake install for it's various pieces (.so, .conf,
init.d, etc.) then:
    For a simple library package:
    package(${PROJECT_NAME}
        ${LIBRARY_VERSION}
        "My library description"
    )

    For a daemon package:
    package(${PROJECT_NAME}
        ${DAEMONX_VERSION}
        "My daemonx description"
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/conffiles;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postinst;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postrm;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/prerm
    )

The last thing the top level CMakeLists.txt does is:
    string(TOLOWER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)
    if(${CMAKE_BUILD_TYPE} STREQUAL release)
        set(CPACK_STRIP_FILES TRUE)
    endif()

    string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION
${BUILD_VERSION})
    string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
${BUILD_VERSION})
    string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
BUILD_PATCH_VERSION ${BUILD_VERSION})

    set(CPACK_GENERATOR DEB)
    set(CPACK_PACKAGE_VERSION_MAJOR ${BUILD_MAJOR_VERSION})
    set(CPACK_PACKAGE_VERSION_MINOR ${BUILD_MINOR_VERSION})
    set(CPACK_PACKAGE_VERSION_PATCH ${BUILD_PATCH_VERSION})
    set(CPACK_PACKAGE_VERSION ${BUILD_VERSION})
    set(CPACK_DEBIAN_PACKAGE_MAINTAINER "maintainer <maintainer at xyx.com>")
    set(CPACK_PACKAGE_VENDOR xyz)

    set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})

    set(CPACK_DEB_COMPONENT_INSTALL TRUE)
    set(CPACK_DEB_PACKAGE_COMPONENT TRUE)


In the macro, CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION works because of the
patch.


macro(package target version description)
    string(TOUPPER ${target} TARGET)

    string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION ${version})
    string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
${version})
    string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
BUILD_PATCH_VERSION ${version})

    set(CPACK_DEBIAN_${TARGET}_PACKAGE_NAME ${target} CACHE STRING "package
${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION ${version} CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_SECTION main CACHE STRING "package
${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_PRIORITY standard CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_ARCHITECTURE
${CMAKE_SYSTEM_PROCESSOR} CACHE STRING "package ${target}")
    set(CPACK_COMPONENT_${TARGET}_DESCRIPTION ${description} CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_CONTROL_EXTRA ${ARGN} CACHE STRING
"package ${target}")

    set(CPACK_DEBIAN_${TARGET}_FILE_NAME
${target}_${version}_${CMAKE_PACKAGE_PLATFORM}.deb CACHE STRING "package
${target}")
endmacro()



--
Sent from: http://cmake.3232098.n2.nabble.com/

From bill.hoffman at kitware.com  Mon Dec  4 15:53:14 2017
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 4 Dec 2017 15:53:14 -0500
Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015
In-Reply-To: <ebab065d-4458-e695-b245-3d95e160a2fd@txcorp.com>
References: <f47e7952-fd73-a2c5-bd5d-c1306df621f5@txcorp.com>
 <ebab065d-4458-e695-b245-3d95e160a2fd@txcorp.com>
Message-ID: <8ff53b7e-dc39-b01d-673f-4da6c622aa07@kitware.com>

Can you just send me a zip or tar file of the build tree from your project?

Thanks.

On 12/2/2017 4:17 AM, JR Cary wrote:
> 
>> Does it work with 3.10?
>   
> It works with no version from  3.9.0 - 3.10.0.
> 
>> Also, look in the CMakeFiles/CMakeError.log file to find out why this
>> happened: - Detecting Fortran/C Interface - Failed to compile.
> 
> Compiling the Fortran compiler identification source file "CMakeFortranCompilerId.F" failed.
> Compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe
> Build flags:
> Id flags: -v
> 
> The output was:
> 0
> Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.6.285 Build 20151119
> Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
> ifort: command line warning #10006: ignoring unknown option '/v'
> 
> CMakeFortranCompilerId.F(2): warning #5117: Bad # preprocessor line
> #if 0
> ...
> 
> Looks from https://stackoverflow.com/questions/36557120/usual-causes-for-bad-preprocessor-warning
> that the preprocessor is not being run.  It requires -fpp to be added to the Fortran compiler
> flags.  I do not see how to do that for CMakeFortranCompilerId.F.  Tried
> 
>    set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fpp")
> 
> but that did not help.
> 
> 
> 
> On 11/26/17 4:29 PM, JR Cary wrote:
>> Works with 3.8.2.
>>
>> Compilers specified by
>>
>> -DCMAKE_C_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE
>> 2015/bin/intel64/icl.exe' -DCMAKE_CXX_COMPILER:FILEPATH='C:/Program
>> Files (x86)/Intel/Composer XE 2015/bin/intel64/icl.exe'
>> -DCMAKE_Fortran_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer
>> XE 2015/bin/intel64/ifort.exe'
>>
>> The cmake code is
>>
>> include(FortranCInterface)
>> FortranCInterface_HEADER(
>>  ? ${CMAKE_BINARY_DIR}/FCMangle.h
>>  ? MACRO_NAMESPACE "FC_"
>>  ? SYMBOL_NAMESPACE "FC_"
>>  ? SYMBOLS mysub mymod:my_sub
>> )
>>
>> The relevant output is
>>
>> -- Detecting Fortran/C Interface
>> -- Detecting Fortran/C Interface - Failed to compile
>> CMake Warning (dev) at
>> C:/winsame/cary/usim/contrib-icl15/cmake-3.9.0-ser/share/
>> cmake-3.9/Modules/FortranCInterface.cmake:309 (message):
>>  ? No FortranCInterface mangling known for mysub
>> Call Stack (most recent call first):
>>  ? scimake/SciFortranChecks.cmake:269 (FortranCInterface_HEADER)
>>  ? scimake/SciInit.cmake:232 (include)
>>  ? CMakeLists.txt:28 (include)
>> This warning is for project developers.? Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at
>> C:/winsame/cary/usim/contrib-icl15/cmake-3.9.0-ser/share/
>> cmake-3.9/Modules/FortranCInterface.cmake:295 (message):
>>  ? No FortranCInterface mangling known for mymod:my_sub
>> Call Stack (most recent call first):
>>  ? scimake/SciFortranChecks.cmake:269 (FortranCInterface_HEADER)
>>  ? scimake/SciInit.cmake:232 (include)
>>  ? CMakeLists.txt:28 (include)
>> This warning is for project developers.? Use -Wno-dev to suppress it.
>>
>> The resulting file is
>>
>> $ cat FCMangle.h
>> #ifndef FC_HEADER_INCLUDED
>> #define FC_HEADER_INCLUDED
>>
>> /*--------------------------------------------------------------------------*/
>> /* Mangle some symbols
>> automatically.?????????????????????????????????????? */
>>
>> #endif
>>
>> Any help appreciated..........John Cary
>>
>>
>>
>>
> 


-- 
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoffman at kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573

From j.david.berger at gmail.com  Mon Dec  4 16:27:10 2017
From: j.david.berger at gmail.com (Justin Berger)
Date: Mon, 4 Dec 2017 14:27:10 -0700
Subject: [CMake] INSTALL EXPORT for Debug and Release
Message-ID: <CAPWb3NTWqA6w-=DMBV6fWFwCQCMkdiMcfTSk+pFwx+fdGx1EBw@mail.gmail.com>

With two build directories -- one for release and one for debug -- using
the Makefile generator, it seems like calling one 'make install' replaces
out the export files for the other with the message:

> Old export file "<project>.cmake" will be replaced.  Removing files
[<project>-debug.cmake]

The INSTALL snippet just looks like:

> install(EXPORT <project> DESTINATION lib/<project>)

The question is, is it possible to use a single config generator like
Makefiles to install both a working release and debug version of a library?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171204/6153899a/attachment.html>

From saadrustam at gmail.com  Mon Dec  4 17:17:23 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Mon, 04 Dec 2017 22:17:23 +0000
Subject: [CMake] INTERFACE libraries and <lib>-config.cmake files
Message-ID: <CAEM70sOZ+AJtnjBrG1cD0aeGepvytSXFGK0dGDR1wE6sMVoCwg@mail.gmail.com>

Hi,

I have an interface library and I am not sure how I would get CMake to
generate the usual <lib>-config.cmake file for the library so that I can
then use "find_package" on the interface library from an external project.

I am adding (and installing) the library like this:

add_library(myLib INTERFACE)
target_include_directories(myLib INTERFACE
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include/>
    )

and then installing like this:

install(TARGETS myLib EXPORT myLib_targets INCLUDES DESTINATION include)
install(EXPORT myLib_targets DESTINATION "lib/cmake")
install(FILES ${MY_HEADERS} DESTINATION "include/")

Obviously, I am doing it wrong or missing some steps as I do not see the
myLib-config.cmake file anywhere in the install folder (or the build
directory for that matter) that is usually generated when using install
commands.

Ultimately, I would like to use the "find_package" command on the interface
library from another CMake project.

Thank you,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171204/e019bd67/attachment.html>

From domen.vrankar at gmail.com  Mon Dec  4 18:07:34 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 5 Dec 2017 00:07:34 +0100
Subject: [CMake] INTERFACE libraries and <lib>-config.cmake files
In-Reply-To: <CAEM70sOZ+AJtnjBrG1cD0aeGepvytSXFGK0dGDR1wE6sMVoCwg@mail.gmail.com>
References: <CAEM70sOZ+AJtnjBrG1cD0aeGepvytSXFGK0dGDR1wE6sMVoCwg@mail.gmail.com>
Message-ID: <CAKgx6BLTYsJkmJd8LKvDEZYFA2sx0c12s2oFoiewDhkE98do-w@mail.gmail.com>

2017-12-04 23:17 GMT+01:00 Saad Khattak <saadrustam at gmail.com>:

> Hi,
>
> I have an interface library and I am not sure how I would get CMake to
> generate the usual <lib>-config.cmake file for the library so that I can
> then use "find_package" on the interface library from an external project.
>
> I am adding (and installing) the library like this:
>
> add_library(myLib INTERFACE)
> target_include_directories(myLib INTERFACE
>     $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
>     $<INSTALL_INTERFACE:include/>
>     )
>
> and then installing like this:
>
> install(TARGETS myLib EXPORT myLib_targets INCLUDES DESTINATION include)
> install(EXPORT myLib_targets DESTINATION "lib/cmake")
> install(FILES ${MY_HEADERS} DESTINATION "include/")
>
> Obviously, I am doing it wrong or missing some steps as I do not see the
> myLib-config.cmake file anywhere in the install folder (or the build
> directory for that matter) that is usually generated when using install
> commands.
>
> Ultimately, I would like to use the "find_package" command on the
> interface library from another CMake project.
>

install(EXPORT myLib_targets ,..) will produce myLib_targets.cmake file if
I remember correctly from the top of my head. Just rename it to
"install(EXPORT mylib-config ...)" or create a new config file named
"myLib-config.cmake" and include cmake script produced by the export in
there.

You'll probably also want to create a version file with something like this:

include(CMakePackageConfigHelpers)
write_basic_package_version_file("mylib-config-version.cmake"
  VERSION ${myLib_VERSION}
  COMPATIBILITY SameMajorVersion
)
install(FILES "${CMAKE_CURRENT_BINARY_DIR}/mylib-config-version.cmake"
  DESTINATION lib/cmake
)

Hope this helps.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171205/551ff572/attachment-0001.html>

From domen.vrankar at gmail.com  Mon Dec  4 19:13:29 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 5 Dec 2017 01:13:29 +0100
Subject: [CMake] CPack: Create debian packge for each sub-project
In-Reply-To: <1512416139330-0.post@n2.nabble.com>
References: <1500681322140-7595889.post@n2.nabble.com>
 <1511971678430-0.post@n2.nabble.com>
 <CAKgx6BK5HpsOHAqhwEZHtOhFpwmF8mQOEtxBbmfqU25=bCrysQ@mail.gmail.com>
 <CA+dygYm-SKNGhYYZnBRQo_VJ3R+8kXTZBn8ykn6FhPkgo6arJg@mail.gmail.com>
 <1512143275596-0.post@n2.nabble.com>
 <CAKgx6B+uWcfhWCXbYxbOVUOB0=KY1swnzLVkUfZW7iAwKME6-Q@mail.gmail.com>
 <CAKgx6BLUSNRKFFgE-mtZQ+5OjynmWX_X8t6u=_VbvujmYeLzqQ@mail.gmail.com>
 <1512413844802-0.post@n2.nabble.com>
 <CAKgx6BKauzzGzKti96sdVnbxZPGZjs681wp-pcHHpOjz+mcFpw@mail.gmail.com>
 <1512416139330-0.post@n2.nabble.com>
Message-ID: <CAKgx6BKeciorBE-TUgoCrBpO+fdqvEryzL8yL5XfhY4yS4OQug@mail.gmail.com>

2017-12-04 20:35 GMT+01:00 DKLind <davidklind at gmail.com>:

> Domen Vrankar wrote
> > I'm a bit confused. Is there something missing in the patch?
> > Attached patch only adds per component version override - it doesn't even
> > touch the multiple calls to `include(CPack)` and naming of different
> > packages (not their components but different package names).
> >
> > Could you please provide a simple example of the intended use for
> > packaging
> > of multiple packages with multiple sub-packages?
>
> I have a macro that each sub-project calls. See package macro below.
>
> Each sub project calls CMake install for it's various pieces (.so, .conf,
> init.d, etc.) then:
>     For a simple library package:
>     package(${PROJECT_NAME}
>         ${LIBRARY_VERSION}
>         "My library description"
>     )
>
>     For a daemon package:
>     package(${PROJECT_NAME}
>         ${DAEMONX_VERSION}
>         "My daemonx description"
>         ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/conffiles;
>         ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postinst;
>         ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postrm;
>         ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/prerm
>     )
>
> The last thing the top level CMakeLists.txt does is:
>     string(TOLOWER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)
>     if(${CMAKE_BUILD_TYPE} STREQUAL release)
>         set(CPACK_STRIP_FILES TRUE)
>     endif()
>
>     string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION
> ${BUILD_VERSION})
>     string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
> ${BUILD_VERSION})
>     string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
> BUILD_PATCH_VERSION ${BUILD_VERSION})
>
>     set(CPACK_GENERATOR DEB)
>     set(CPACK_PACKAGE_VERSION_MAJOR ${BUILD_MAJOR_VERSION})
>     set(CPACK_PACKAGE_VERSION_MINOR ${BUILD_MINOR_VERSION})
>     set(CPACK_PACKAGE_VERSION_PATCH ${BUILD_PATCH_VERSION})
>     set(CPACK_PACKAGE_VERSION ${BUILD_VERSION})
>     set(CPACK_DEBIAN_PACKAGE_MAINTAINER "maintainer <maintainer at xyx.com>")
>     set(CPACK_PACKAGE_VENDOR xyz)
>
>     set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
>
>     set(CPACK_DEB_COMPONENT_INSTALL TRUE)
>     set(CPACK_DEB_PACKAGE_COMPONENT TRUE)
>
>
> In the macro, CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION works because of the
> patch.
>
>
> macro(package target version description)
>     string(TOUPPER ${target} TARGET)
>
>     string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION
> ${version})
>     string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
> ${version})
>     string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
> BUILD_PATCH_VERSION ${version})
>
>     set(CPACK_DEBIAN_${TARGET}_PACKAGE_NAME ${target} CACHE STRING
> "package
> ${target}")
>     set(CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION ${version} CACHE STRING
> "package ${target}")
>     set(CPACK_DEBIAN_${TARGET}_PACKAGE_SECTION main CACHE STRING "package
> ${target}")
>     set(CPACK_DEBIAN_${TARGET}_PACKAGE_PRIORITY standard CACHE STRING
> "package ${target}")
>     set(CPACK_DEBIAN_${TARGET}_PACKAGE_ARCHITECTURE
> ${CMAKE_SYSTEM_PROCESSOR} CACHE STRING "package ${target}")
>     set(CPACK_COMPONENT_${TARGET}_DESCRIPTION ${description} CACHE STRING
> "package ${target}")
>     set(CPACK_DEBIAN_${TARGET}_PACKAGE_CONTROL_EXTRA ${ARGN} CACHE STRING
> "package ${target}")
>
>     set(CPACK_DEBIAN_${TARGET}_FILE_NAME
> ${target}_${version}_${CMAKE_PACKAGE_PLATFORM}.deb CACHE STRING "package
> ${target}")
> endmacro()
>

Try using this on CPackRPM with debuginfo packages or rpm default naming
convention enabled (with this second part it's the same with CPackDeb
apckages) - these are just two parts that you break that immediately come
to mind.
Now you have to rename every package by hand, require a non standard macro
just to set things up, you forfeit instead of gain automation (e.g. auto
component deduction from install commands, package naming...). And you
still cant override all the variables (e.g. maintainer).

While this might be enough for your use case and CPackDeb it wouldn't play
nice with all CPackRPM features so it would cause them to diverge even
further.

I'm still not convinced that it's worth it.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171205/e8b19780/attachment.html>

From r030t1 at gmail.com  Mon Dec  4 19:27:31 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Mon, 4 Dec 2017 18:27:31 -0600
Subject: [CMake] Using find_package() portably?
In-Reply-To: <773abfaf-9c9c-d2db-e37a-f8f58bd18344@cafu.de>
References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de>
 <5662152.4nPEXIznPt@ersa>
 <d918c66a-49f5-31cb-2146-4d996687905b@cafu.de> <3171356.xi6d4M9i8k@ersa>
 <b6564d37-4883-4831-d31e-e8b18ab8fc3e@gmail.com>
 <773abfaf-9c9c-d2db-e37a-f8f58bd18344@cafu.de>
Message-ID: <CAAD4mYhFnN5Qa95VLDZ70F9DjhBLGFH6Zy983pHZSy30zwZepw@mail.gmail.com>

On Monday, December 4, 2017, Carsten Fuchs <carsten.fuchs at cafu.de> wrote:
> Thanks to all!
>
> Well, I guess I'm among the people mentioned by Lectem at
https://www.mail-archive.com/cmake-developers at cmake.org/msg18267.html
>
> I'll try to dig my way through it, but at this point I consider staying
with SCons under Linux, where finding packages is important and the command
line is used anyway, and using CMake under Windows only, where quasi all
external libraries are shipped along with the project and the real goal is
to obtain a Visual Studio solution. (I already have a complete build with
SCons that works under Windows and Linux for my project which is of average
complexity.)
>

Hello,

Are you able to link to your project? I am interested in how you have set
up your build system.

Cheers,
    R0b0t1

> Best regards,
> Carsten
>
> $ ls Cafu/ExtLibs/ -1
> bullet
> Cg
> fbx
> fmod
> freealut
> freetype
> glfw
> jpeg
> libogg
> libpng
> libvorbis
> lua
> lwo
> MersenneTwister.h
> minizip
> mpg123
> noise
> openal-soft
> openal-win
> pstdint.h
> tclap
> wxWidgets
> zlib
>
>
>
> Am 29.11.2017 um 21:17 schrieb Florent Castelli:
>>
>> On 29/11/2017 12:02, Johannes Zarl-Zierl wrote:
>>>
>>> Hello Carsten,
>>>
>>> On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote:
>>>>
>>>> Thanks for your reply, but how can I proceed from here?
>>>>
>>>> In order to be able to write in the parent script something that works
>>>> in either case, that is,
>>>>
>>>> target_link_libraries(main_program <either JPEG::JPEG or ${JPEG...} or
???>)
>>>
>>> Well, that's one way, but that doesn't really provide any benefit above
the
>>> original solution (i.e. just define the JPEG_INCLUDES and JPEG_LIBRARIES
>>> variables accordingly).
>>>
>>>> it seems that I either
>>>>
>>>>     - have to make a copy of FindJPEG.cmake, customize it to define
>>>> target JPEG::JEPG and ship it along with my project,
>>>
>>> Either that or you define it yourself:
>>> find_package(JPEG)
>>> if (JPEG_FOUND)
>>
>> I'd say "if(JPEG_FOUND AND NOT TARGET JPEG::JPEG)"
>> If someone improves FindJPEG.cmake, you won't break your build.
>>
>>>   add_library(JPEG::JPEG UNKNOWN IMPORTED)
>>>   set_property(
>>>    TARGET JPEG::JPEG
>>>    PROPERTY IMPORTED_LOCATION ${JPEG_LIBRARIES}
>>>    )
>>>   set_property(
>>>    TARGET JPEG::JPEG PROPERTY
>>>    INTERFACE_INCLUDE_DIRECTORIES ${JPEG_INCLUDES}
>>>   )
>>> endif()
>>>
>>> I admit it's not a huge benefit over just using the variables. The
advantages:
>>> - you get slightly better error handling
>>> - your target_link_libraries commands are slightly more readable.
>>>
>>>>     - or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it
globally
>>>> defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS
>>>
>>> That will work, too.
>>>
>>>
>>> Cheers,
>>>    Johannes
>>>
>>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171204/0416037e/attachment.html>

From carsten.fuchs at cafu.de  Tue Dec  5 04:19:56 2017
From: carsten.fuchs at cafu.de (Carsten Fuchs)
Date: Tue, 5 Dec 2017 10:19:56 +0100
Subject: [CMake] Using find_package() portably?
In-Reply-To: <CAAD4mYhFnN5Qa95VLDZ70F9DjhBLGFH6Zy983pHZSy30zwZepw@mail.gmail.com>
References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de>
 <5662152.4nPEXIznPt@ersa> <d918c66a-49f5-31cb-2146-4d996687905b@cafu.de>
 <3171356.xi6d4M9i8k@ersa> <b6564d37-4883-4831-d31e-e8b18ab8fc3e@gmail.com>
 <773abfaf-9c9c-d2db-e37a-f8f58bd18344@cafu.de>
 <CAAD4mYhFnN5Qa95VLDZ70F9DjhBLGFH6Zy983pHZSy30zwZepw@mail.gmail.com>
Message-ID: <a70d5266-c3a6-c554-3142-b35555ba285a@cafu.de>

Hi,

Am 2017-12-05 um 01:27 schrieb R0b0t1:
> Are you able to link to your project? I am interested in how you have 
> set up your build system.

https://www.cafu.de

If you're specifically looking at the SCons scripts, please note that 
they historically grew and are not perfect either: Especially, I used to 
use custom builds of quasi all direct external dependencies under Linux 
either, using only libpng and zlib from the system. This was mainly 
motivated by the fact that I needed to ship them for Windows anyways, 
the system's versions were in some cases very outdated (if available at 
all) and that I sometimes added a fix or patch here and there. 
Especially wxWidgets is a special case of which I plan to use the 
system's copy in the future; this in turn will make it possible to also 
use other system libraries as well.

Best regards,
Carsten

From ramya.gopalkrishna at accoliteindia.com  Tue Dec  5 12:05:58 2017
From: ramya.gopalkrishna at accoliteindia.com (ramya.gopalkrishna at accoliteindia.com)
Date: Tue, 5 Dec 2017 22:35:58 +0530
Subject: [CMake] [CMAKE] -  custom compiler for Android
Message-ID: <00f201d36deb$5464f140$fd2ed3c0$@accoliteindia.com>

Hi,

 

I am reposting the below email. Your help is highly appreciated. 

 

We are working towards creating a toolchain file for an ANDROID compiler

 

We understand that the flow in CMAKE, when CMAKE_SYSTEM_NAME is specified in
Android, is different when compared to specifying CMAKE_SYSTEM_NAME as IOS
or LINUX

 

Please validate our current understanding when a toolchain file or
command-line option sets CMAKE_SYSTEM_NAME to "Android" 

 

*	CMakeDetermineSystem.cmake loads this file:
Android-Determine.cmake
*	Next is the platform-specific initialization step:
CMakeSystemSpecificInitialize.cmake which loads Android-Initialize.cmake to
select the sysroot.
*	A "determine" step also runs for each language when it is first
enabled in a new build tree:

 

Android-Determine-C.cmake

Android-Determine-CXX.cmake

 

*	The language files go here:

 

Determine-Compiler.cmake

Determine-Compiler-NDK.cmake

 

*	The latter file is where we parse a bunch of information from the
NDK.

The results persist in CMakeFiles/$v/CMake${lang}Compiler.cmake for future
runs.

 

Next is the language-specific initialization step. For  Example - in case
{lang} is C :     CMakeCInformation.cmake

 

That loads one of these:

 

Android-GNU-C.cmake

Android-Clang-C.cmake

 

which loads one of these:

 

Android-GNU.cmake

Android-Clang.cmake  

 

Determine-Compiler-NDK.cmake is where cmake looks for versions of clang or
gcc or llvm toolchains and sets the appropriate compiler.

 

 

Our Requirement and Problem statement

When we tried manually setting a c and cxx compiler from a toolchain file,
cmake would not allow us to point to our own compilers. Ideally, we want our
toolchain file to tell cmake the libraries to include/link and the compilers
to use. But once, System has been determined as android, cmake goes through
the above sequence of events and expects toolchains to be specified for
either clang, gcc or llvm compilers.

 

We would probably need to make changes in the following files to accommodate
cmake to use our own compilers.

Determine-Compiler-NDK.cmake  - We would need to add support for an
"NewCompiler Toolchain" which would contain android libraries and compilers.

 

New Android-{NewCompiler}-C.cmake, Android-{ NewCompiler }-CXX.cmake,
Android-{ NewCompiler }.cmake and another appropriate toolchain file to set
target architecture and compiler flags.

 

 

Can you please provide your suggestions and validate the understanding as
well

 

Thanks & Regards,

Ramya

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171205/9f4199f0/attachment.html>

From brad.king at kitware.com  Tue Dec  5 14:54:16 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Dec 2017 14:54:16 -0500
Subject: [CMake] [CMAKE] - custom compiler for Android
In-Reply-To: <00f201d36deb$5464f140$fd2ed3c0$@accoliteindia.com>
References: <00f201d36deb$5464f140$fd2ed3c0$@accoliteindia.com>
Message-ID: <abf476cd-b395-b465-5dfd-f28dc9d13eaf@kitware.com>

On 12/05/2017 12:05 PM, ramya.gopalkrishna at accoliteindia.com wrote:
> Please validate our current understanding when a toolchain file or
> command-line option sets CMAKE_SYSTEM_NAME to "Android"

You may find this note helpful:

  https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971

> Ideally, we want our toolchain file to tell cmake the libraries to
> include/link and the compilers to use.

Toolchain files can set the path to compilers on the host, but
target-platform-wide information like the set of libraries and
include directories to use typically belongs in platform information
modules (e.g. `Platform/Android-...` and the like).

> But once, System has been determined as android, cmake goes
> through the above sequence of events and expects toolchains to be
> specified for either clang, gcc or llvm compilers.

We try to support the compilers that come with the NDK out of the box.
More work may be needed to support other compilers, just as would be
the case for any new platform or new compiler.

> Determine-Compiler-NDK.cmake? - We would need to add support for an
> "NewCompiler Toolchain" which would contain android libraries and compilers.

Since your compiler doesn't come with the NDK, perhaps you could look
at using the standalone toolchain mode.

> New Android-{NewCompiler}-C.cmake, Android-{ NewCompiler }-CXX.cmake,
> Android-{ NewCompiler }.cmake and another appropriate toolchain file to
> set target architecture and compiler flags.

If you have some new compiler then something like that would be needed.
This would be the case for a new compiler on any platform.

-Brad

From neal.kruis at bigladdersoftware.com  Tue Dec  5 17:36:11 2017
From: neal.kruis at bigladdersoftware.com (Neal Kruis)
Date: Tue, 5 Dec 2017 15:36:11 -0700
Subject: [CMake] Understanding default Visual Studio compiler flags
Message-ID: <CAOG8z51VnYhAeAMUSEw0RBDxdjakBm7x1BSsmF3TZ2qxd9yTog@mail.gmail.com>

Hi all,

I'm hoping someone can clarify some confusion I have regarding the flags
used in Visual Studio Cmake builds.

For example, in a release build, there are the defaults:

CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc
CMAKE_CXX_FLAGS_RELEASE:STRING=/MD /O2 /Ob2 /DNDEBUG

We can obviously append to or modify these within our CMakeLists.txt files.
However, my actual build flags look like this:

/nologo /W3 /WX- /O2 /Ob2 /Oy- /D WIN32 /D _WINDOWS /D NDEBUG /D
"CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /EHsc /MT /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"PROJECT.DIR\RELEASE\\"
/Fd"PROJECT.DIR\RELEASE\VC140.PDB" /Gd /TP /analyze-

Where are all these other flags coming from? Some of these I appreciate are
necessary for the CMake mechanics to work, but what if (for whatever
reason) I wanted to remove one of the other flags that isn't defined by
CMAKE_CXX_FLAGS or CMAKE_CXX_FLAGS_RELEASE (e.g., /Zc:wchar_t)?

Can Cmake users override the values from the default flag table
<https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmVS141CLFlagTable.h>
?

Regards,

Neal Kruis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171205/7f869535/attachment.html>

From ramya.gopalkrishna at accoliteindia.com  Wed Dec  6 11:39:06 2017
From: ramya.gopalkrishna at accoliteindia.com (ramya.gopalkrishna at accoliteindia.com)
Date: Wed, 6 Dec 2017 22:09:06 +0530
Subject: [CMake] [CMAKE] - custom compiler for Android
In-Reply-To: <abf476cd-b395-b465-5dfd-f28dc9d13eaf@kitware.com>
References: <00f201d36deb$5464f140$fd2ed3c0$@accoliteindia.com>
 <abf476cd-b395-b465-5dfd-f28dc9d13eaf@kitware.com>
Message-ID: <010601d36eb0$be051560$3a0f4020$@accoliteindia.com>

HI Brad,

Thank you for the response
However we want more guidance on how do we start with the changes needed for
the compiler support

To be more clear, we are trying to build support for the embarcadero
compilers bccaarm.exe. To give more insight on the work and our query, we
have attached a working toolchain that we created and works fine with CMAKE
and the compiler. But we have given the system name CMAKE_SYSTEM_NAME as
"_Android"
Since we havent given it as "Android", it reads all the libraries and the
compilers from our toolchain file and gives the desired output. 

Can you please give us some guidance to achieve the same with
CMAKE_SYSTEM_NAME as "Android"

Thanks & Regards,
Ramya

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, December 06, 2017 1:24 AM
To: ramya.gopalkrishna at accoliteindia.com
Cc: CMake at cmake.org; 'Sumit Chourasia' <sumit.chourasia at accoliteindia.com>
Subject: Re: [CMAKE] - custom compiler for Android

On 12/05/2017 12:05 PM, ramya.gopalkrishna at accoliteindia.com wrote:
> Please validate our current understanding when a toolchain file or 
> command-line option sets CMAKE_SYSTEM_NAME to "Android"

You may find this note helpful:

  https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971

> Ideally, we want our toolchain file to tell cmake the libraries to 
> include/link and the compilers to use.

Toolchain files can set the path to compilers on the host, but
target-platform-wide information like the set of libraries and include
directories to use typically belongs in platform information modules (e.g.
`Platform/Android-...` and the like).

> But once, System has been determined as android, cmake goes through 
> the above sequence of events and expects toolchains to be specified 
> for either clang, gcc or llvm compilers.

We try to support the compilers that come with the NDK out of the box.
More work may be needed to support other compilers, just as would be the
case for any new platform or new compiler.

> Determine-Compiler-NDK.cmake? - We would need to add support for an 
> "NewCompiler Toolchain" which would contain android libraries and
compilers.

Since your compiler doesn't come with the NDK, perhaps you could look at
using the standalone toolchain mode.

> New Android-{NewCompiler}-C.cmake, Android-{ NewCompiler }-CXX.cmake, 
> Android-{ NewCompiler }.cmake and another appropriate toolchain file 
> to set target architecture and compiler flags.

If you have some new compiler then something like that would be needed.
This would be the case for a new compiler on any platform.

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bccaarm.cmake
Type: application/octet-stream
Size: 1193 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171206/5fd4ea87/attachment-0001.obj>

From mike.jackson at bluequartz.net  Wed Dec  6 12:01:02 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 06 Dec 2017 12:01:02 -0500
Subject: [CMake] CMake 3.10 adding mystery source file to target?
Message-ID: <FA33316C-2417-4683-ADF4-6A8D62F1EB81@bluequartz.net>

I just tried to configure our project with CMake 3.10 and got some errors. The same project configures fine with CMake 3.8.x and 3.9.x as evidenced here (http://my.cdash.org/index.php?project=DREAM3D).

I get an error about a Qt5 qrc generated file not being found. 

-- Configuring done
CMake Error in /Users/mjackson/Workspace/DREAM3D_Plugins/AskNDEToolbox/Applications/ScanViewer/CMakeLists.txt:
  Cannot find source file:

    /Users/mjackson/Workspace/DREAM3D-Build/3.10/Plugins/AskNDEToolbox/qrc_AskNDEToolbox.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx


-- Generating done
-- Build files have been written to: /Users/mjackson/Workspace/DREAM3D-Build/3.10


But the issue is that if I actually print out all the source files for the " ScanViewer " taget, "qrc_AskNDEToolbox.cpp" NEVER shows up? There is another target that uses that file but NOT ScanViewer.

I am also getting some errors on the same project but on Windows (the previous was on macOS Sierra) where some of our plugins that get configured all of a sudden cannot find some of their files. I have not tried on Linux x64 yet to figure out if anything is broken on that side. 

Thanks for any information anyone may have. Thoughts. Ideas. All are welcome.

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net



From Odera_Dim at student.uml.edu  Wed Dec  6 15:40:12 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Wed, 6 Dec 2017 20:40:12 +0000
Subject: [CMake] Building ROOT into Geant4 Application
Message-ID: <BY2PR02MB214954A34AD0DA2526520F12D1320@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi CMake Experts,


Please I use CMake to build my Geant4 applications with no issues. However, recently I needed to build ROOT into my Geant4 application for the purpose of extracting and processing simulation data. I have followed the many instructions which exist online both on the Genat4 and ROOT sides but none seems to produce the required results. The issue i'm having I believe is related to the linkage of both Geant4 and ROOT libraries top the generated executable during compilation. I am able to configure and generate build files with a CMakeLists with no errors. Compilation also seems to also complete with no errors but when I run the application I get an error which specifies that LLVM are exposed to Cling and so I need to hide them. In my CMakeLists (which I can provide to you) I do not explicitly link Cling to my executable all I do is link the executable to ROOT libraries (${ROOT_LIBRARIES}). Please, could you help me with this issue or do you know a way that I could link libraries and not expose LLVM to Cling? Thank you.


Dim Odera

UMass Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171206/beb9c94b/attachment.html>

From r030t1 at gmail.com  Thu Dec  7 01:53:32 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 7 Dec 2017 00:53:32 -0600
Subject: [CMake] Building ROOT into Geant4 Application
In-Reply-To: <BY2PR02MB214954A34AD0DA2526520F12D1320@BY2PR02MB2149.namprd02.prod.outlook.com>
References: <BY2PR02MB214954A34AD0DA2526520F12D1320@BY2PR02MB2149.namprd02.prod.outlook.com>
Message-ID: <CAAD4mYg=qpOc4a8An6UtA-7MTr0SNgQZEmSPJqBxdwZsnqBu2g@mail.gmail.com>

Mr. Odera,

On Wed, Dec 6, 2017 at 2:40 PM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi CMake Experts,
>
>
> Please I use CMake to build my Geant4 applications with no issues. However,
> recently I needed to build ROOT into my Geant4 application for the purpose
> of extracting and processing simulation data. I have followed the many
> instructions which exist online both on the Genat4 and ROOT sides but none
> seems to produce the required results. The issue i'm having I believe is
> related to the linkage of both Geant4 and ROOT libraries top the generated
> executable during compilation. I am able to configure and generate build
> files with a CMakeLists with no errors. Compilation also seems to also
> complete with no errors but when I run the application I get an error which
> specifies that LLVM are exposed to Cling and so I need to hide them. In my
> CMakeLists (which I can provide to you) I do not explicitly link Cling to my
> executable all I do is link the executable to ROOT libraries
> (${ROOT_LIBRARIES}). Please, could you help me with this issue or do you
> know a way that I could link libraries and not expose LLVM to Cling? Thank
> you.
>

Can you provide the text of the errors as they are given? Are you
experiencing build errors, or are you wanting to quiet runtime
messages?

Which OS are you compiling and running on? Which build instructions
are you following? What are the build commands that you ran? Are you
using Clang, and is it necessary that you use Clang?

If we can't resolve your problem here it is possible I can refer you
to someone off-list, but I am not entirely sure what difficulty you
are having.

Cheers,
     R0b0t1

From damienrg+list at gmail.com  Thu Dec  7 03:24:29 2017
From: damienrg+list at gmail.com (Damien R)
Date: Thu, 7 Dec 2017 09:24:29 +0100
Subject: [CMake] check_cxx_compiler_flag usage
Message-ID: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>

Hi,

I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if the
compiler supports asan.
The CMakeLists.txt is:
cmake_minimum_required(VERSION 3.9)
include(CheckCXXCompilerFlag)
check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)

I always got:
-- Performing Test COMPILER_SUPPORT_FLAG - Failed

Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
work.
Can you tell me why CHECK_CXX_COMPILER_FLAG use
CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
and what is the official way for checking this flag?

Regards,

Damien R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/8fd155df/attachment.html>

From lectem at gmail.com  Thu Dec  7 03:35:47 2017
From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=)
Date: Thu, 07 Dec 2017 08:35:47 +0000
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
Message-ID: <CACzuyg5ZAf2a3Kzugy1vdNUrSKp9YUz+nYBY91PzwnqCwXsvCw@mail.gmail.com>

That's probably an issue with linking because it doesn't know it has to
link asan.
Either way, settings asan flags is the job of the user, not the
cmakelists.txt.
Such things should be kept in tool chain or config files IMHO.
You can try running cmake in verbose mode for more information.

Le jeu. 7 d?c. 2017 ? 09:25, Damien R <damienrg+list at gmail.com> a ?crit :

> Hi,
>
> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if the
> compiler supports asan.
> The CMakeLists.txt is:
> cmake_minimum_required(VERSION 3.9)
> include(CheckCXXCompilerFlag)
> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>
> I always got:
> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>
> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
> work.
> Can you tell me why CHECK_CXX_COMPILER_FLAG use
> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
> and what is the official way for checking this flag?
>
> Regards,
>
> Damien R.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/bbfa8b1b/attachment-0001.html>

From eric.noulard at gmail.com  Thu Dec  7 04:35:37 2017
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 7 Dec 2017 10:35:37 +0100
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
Message-ID: <CAPASGLrCX8ST=x7f9R_4saSvp6Nj-JuDD=42KMMNadz9fyzONQ@mail.gmail.com>

Not really answering the question but
did you try to use an existing CMake module for handling sanitizers config?

I find this one https://github.com/arsenm/sanitizers-cmake very effective,
with
modern CMake target oriented features.




2017-12-07 9:24 GMT+01:00 Damien R <damienrg+list at gmail.com>:

> Hi,
>
> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if the
> compiler supports asan.
> The CMakeLists.txt is:
> cmake_minimum_required(VERSION 3.9)
> include(CheckCXXCompilerFlag)
> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>
> I always got:
> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>
> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
> work.
> Can you tell me why CHECK_CXX_COMPILER_FLAG use CMAKE_REQUIRED_DEFINITIONS instead
> of CMAKE_REQUIRED_FLAGS
> and what is the official way for checking this flag?
>
> Regards,
>
> Damien R.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/2c224778/attachment.html>

From eric.noulard at gmail.com  Thu Dec  7 04:38:53 2017
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 7 Dec 2017 10:38:53 +0100
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CACzuyg5ZAf2a3Kzugy1vdNUrSKp9YUz+nYBY91PzwnqCwXsvCw@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
 <CACzuyg5ZAf2a3Kzugy1vdNUrSKp9YUz+nYBY91PzwnqCwXsvCw@mail.gmail.com>
Message-ID: <CAPASGLomwq8hSkmLTw2fDiP5g2jXUUERUBTrWk+yNT+w1_Tr5g@mail.gmail.com>

2017-12-07 9:35 GMT+01:00 Cl?ment Gregoire <lectem at gmail.com>:

> That's probably an issue with linking because it doesn't know it has to
> link asan.
> Either way, settings asan flags is the job of the user, not the
> cmakelists.txt.
> Such things should be kept in tool chain or config files IMHO.
>

I do not agree with you.

Most of the time you will have to handle various type of build for the same
toolchain: i.e. debug, optimize, profiling etc...
sanitizing is another case of build type.
I wouldn't put it in the toolchain since it could work with various
toolchain and at least with GCC or Clang.

I don't know what you mean by "config file".


> You can try running cmake in verbose mode for more information.
>
> Le jeu. 7 d?c. 2017 ? 09:25, Damien R <damienrg+list at gmail.com> a ?crit :
>
>> Hi,
>>
>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if the
>> compiler supports asan.
>> The CMakeLists.txt is:
>> cmake_minimum_required(VERSION 3.9)
>> include(CheckCXXCompilerFlag)
>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>
>> I always got:
>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>
>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>> work.
>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>> and what is the official way for checking this flag?
>>
>> Regards,
>>
>> Damien R.
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/
>> opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/28dc6db4/attachment.html>

From lectem at gmail.com  Thu Dec  7 06:29:15 2017
From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=)
Date: Thu, 07 Dec 2017 11:29:15 +0000
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CAPASGLomwq8hSkmLTw2fDiP5g2jXUUERUBTrWk+yNT+w1_Tr5g@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
 <CACzuyg5ZAf2a3Kzugy1vdNUrSKp9YUz+nYBY91PzwnqCwXsvCw@mail.gmail.com>
 <CAPASGLomwq8hSkmLTw2fDiP5g2jXUUERUBTrWk+yNT+w1_Tr5g@mail.gmail.com>
Message-ID: <CACzuyg4DHtXnh=X9=VsS=nATO8u6NhUgLzLAc5FwEMgXKXQnPw@mail.gmail.com>

Well to be honest, as long as it's done correctly I don't really have any
issues with it.
The issue is that I've seen many Cmakelists.txt changing CMAKE_CXX_FLAGS
directly and forcing it upon the user by adding a target_add_* which most
of the time is not what you want.
Adding a new configuration type is indeed the best solution (though it
forces it on all the targets), it's also what I use for my coverage builds.

Le jeu. 7 d?c. 2017 ? 10:38, Eric Noulard <eric.noulard at gmail.com> a ?crit :

> 2017-12-07 9:35 GMT+01:00 Cl?ment Gregoire <lectem at gmail.com>:
>
>> That's probably an issue with linking because it doesn't know it has to
>> link asan.
>> Either way, settings asan flags is the job of the user, not the
>> cmakelists.txt.
>> Such things should be kept in tool chain or config files IMHO.
>>
>
> I do not agree with you.
>
> Most of the time you will have to handle various type of build for the
> same toolchain: i.e. debug, optimize, profiling etc...
> sanitizing is another case of build type.
> I wouldn't put it in the toolchain since it could work with various
> toolchain and at least with GCC or Clang.
>
> I don't know what you mean by "config file".
>
>
>> You can try running cmake in verbose mode for more information.
>>
>> Le jeu. 7 d?c. 2017 ? 09:25, Damien R <damienrg+list at gmail.com> a ?crit :
>>
>>> Hi,
>>>
>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>> the compiler supports asan.
>>> The CMakeLists.txt is:
>>> cmake_minimum_required(VERSION 3.9)
>>> include(CheckCXXCompilerFlag)
>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>
>>> I always got:
>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>
>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>>> work.
>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>> and what is the official way for checking this flag?
>>>
>>> Regards,
>>>
>>> Damien R.
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/92092cbc/attachment-0001.html>

From damienrg+list at gmail.com  Thu Dec  7 08:31:33 2017
From: damienrg+list at gmail.com (Damien R)
Date: Thu, 7 Dec 2017 14:31:33 +0100
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CAPASGLrCX8ST=x7f9R_4saSvp6Nj-JuDD=42KMMNadz9fyzONQ@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
 <CAPASGLrCX8ST=x7f9R_4saSvp6Nj-JuDD=42KMMNadz9fyzONQ@mail.gmail.com>
Message-ID: <CAKPeRicwuXEti_=72Zn6GFC3bXFAaRU9q8Bmas-eEiVaDg2TFQ@mail.gmail.com>

Thank you for pointing that. It increments the number of people using
CMAKE_REQUIRED_FLAGS "trick" to make it working with
check_cxx_compiler_flag.

But my question is more about :
 - why they coded CHECK_CXX_COMPILER_FLAG this way?
 - is my usage valid or not? If not what should I do? If yes, is it a bug?

Regards,

Damien R.



On 7 December 2017 at 10:35, Eric Noulard <eric.noulard at gmail.com> wrote:

>
> Not really answering the question but
> did you try to use an existing CMake module for handling sanitizers config?
>
> I find this one https://github.com/arsenm/sanitizers-cmake very
> effective, with
> modern CMake target oriented features.
>
>
>
>
> 2017-12-07 9:24 GMT+01:00 Damien R <damienrg+list at gmail.com>:
>
>> Hi,
>>
>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if the
>> compiler supports asan.
>> The CMakeLists.txt is:
>> cmake_minimum_required(VERSION 3.9)
>> include(CheckCXXCompilerFlag)
>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>
>> I always got:
>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>
>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>> work.
>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>> and what is the official way for checking this flag?
>>
>> Regards,
>>
>> Damien R.
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/6675e7fc/attachment.html>

From lectem at gmail.com  Thu Dec  7 09:13:08 2017
From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=)
Date: Thu, 7 Dec 2017 15:13:08 +0100
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CAKPeRicwuXEti_=72Zn6GFC3bXFAaRU9q8Bmas-eEiVaDg2TFQ@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
 <CAPASGLrCX8ST=x7f9R_4saSvp6Nj-JuDD=42KMMNadz9fyzONQ@mail.gmail.com>
 <CAKPeRicwuXEti_=72Zn6GFC3bXFAaRU9q8Bmas-eEiVaDg2TFQ@mail.gmail.com>
Message-ID: <CACzuyg7JP9tcsDevprrOkt8AoUTDhUum4Mge9O4o3AVdKjt74w@mail.gmail.com>

Your usage of check_cxx_compiler_flag is correct, it's probably just
missing link flags or something.
Can you check the error log of cmake to know why it fails to compile ? It
is in your buildfolder : CMakeFiles/CMakeError.log

Here's how I did it for coverage by the way (not perfect, but was enough
for my usage):

https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake#L42




2017-12-07 14:31 GMT+01:00 Damien R <damienrg+list at gmail.com>:

> Thank you for pointing that. It increments the number of people using
> CMAKE_REQUIRED_FLAGS "trick" to make it working with
> check_cxx_compiler_flag.
>
> But my question is more about :
>  - why they coded CHECK_CXX_COMPILER_FLAG this way?
>  - is my usage valid or not? If not what should I do? If yes, is it a bug?
>
> Regards,
>
> Damien R.
>
>
>
> On 7 December 2017 at 10:35, Eric Noulard <eric.noulard at gmail.com> wrote:
>
>>
>> Not really answering the question but
>> did you try to use an existing CMake module for handling sanitizers
>> config?
>>
>> I find this one https://github.com/arsenm/sanitizers-cmake very
>> effective, with
>> modern CMake target oriented features.
>>
>>
>>
>>
>> 2017-12-07 9:24 GMT+01:00 Damien R <damienrg+list at gmail.com>:
>>
>>> Hi,
>>>
>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>> the compiler supports asan.
>>> The CMakeLists.txt is:
>>> cmake_minimum_required(VERSION 3.9)
>>> include(CheckCXXCompilerFlag)
>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>
>>> I always got:
>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>
>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>>> work.
>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>> and what is the official way for checking this flag?
>>>
>>> Regards,
>>>
>>> Damien R.
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> Eric
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/de64e4b2/attachment.html>

From Odera_Dim at student.uml.edu  Thu Dec  7 09:30:10 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Thu, 7 Dec 2017 14:30:10 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
Message-ID: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi CMake Experts,

Please I use CMake to build my Geant4 applications with no issues. However, recently I needed to build ROOT into my Geant4 application for the purpose of extracting and processing simulation data. I have followed the many instructions which exist online both on the Genat4 and ROOT sides but none seems to produce the required results. The issue i'm having I believe is related to the linkage of both Geant4 and ROOT libraries top the generated executable during compilation. I am able to configure and generate build files with a CMakeLists with no errors. Compilation also seems to also complete with no errors but when I run the application I get an error which specifies that LLVM are exposed to Cling and so I need to hide them. In my CMakeLists (which I can provide to you) I do not explicitly link Cling to my executable all I do is link the executable to ROOT libraries (${ROOT_LIBRARIES}). Please, could you help me with this issue or do you know a way that I could link libraries and not expose LLVM to Cling? Thank you.

Dim Odera
UMass Lowell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/0b66986c/attachment-0001.html>

From volo.zyko at gmail.com  Thu Dec  7 09:35:16 2017
From: volo.zyko at gmail.com (Volo Zyko)
Date: Thu, 7 Dec 2017 16:35:16 +0200
Subject: [CMake] Problem with removing directories containing soft links on
	MSYS
Message-ID: <CA+bO-ckrNErU424XiF+NA7TyVTLv7-1GVPXW698_3ZbYsFYdUg@mail.gmail.com>

The following list of bash commands ends with fail at least on MSYS
(don't know about Cygwin).

$> test_dir=$PWD/cmake

$> mkdir -p $test_dir/1
$> ln -s $test_dir/1/ $test_dir/a

$> cmake -E remove_directory $test_dir

Final CMake invocation reports: Error removing directory "C:/cmake".
It looks like cmake first removes "$test_dir/1" and then cannot remove
dangling "$test_dir/a". Is this something known?

 Volo Zyko

From volo.zyko at gmail.com  Thu Dec  7 11:36:16 2017
From: volo.zyko at gmail.com (Volo Zyko)
Date: Thu, 7 Dec 2017 18:36:16 +0200
Subject: [CMake] Problem with removing directories containing soft links
	on MSYS
In-Reply-To: <CA+bO-ckrNErU424XiF+NA7TyVTLv7-1GVPXW698_3ZbYsFYdUg@mail.gmail.com>
References: <CA+bO-ckrNErU424XiF+NA7TyVTLv7-1GVPXW698_3ZbYsFYdUg@mail.gmail.com>
Message-ID: <CA+bO-cn0suuimTkGgqmuOx5cqxiJDSsUTJO+PvMod1d6ff_G2w@mail.gmail.com>

Additionally investigated that the following also fails:

$> test_dir=$PWD/cmake

$> mkdir -p $test_dir/z
$> ln -s $test_dir/z/ $test_dir/a

$> cmake -E remove_directory $test_dir

In this case $test_dir/z is not removed at all.

Also, I checked cmake 3.5.1 and 3.9.2.

 Volo Zyko


On Thu, Dec 7, 2017 at 4:35 PM, Volo Zyko <volo.zyko at gmail.com> wrote:
> The following list of bash commands ends with fail at least on MSYS
> (don't know about Cygwin).
>
> $> test_dir=$PWD/cmake
>
> $> mkdir -p $test_dir/1
> $> ln -s $test_dir/1/ $test_dir/a
>
> $> cmake -E remove_directory $test_dir
>
> Final CMake invocation reports: Error removing directory "C:/cmake".
> It looks like cmake first removes "$test_dir/1" and then cannot remove
> dangling "$test_dir/a". Is this something known?
>
>  Volo Zyko

From damienrg+list at gmail.com  Thu Dec  7 16:03:36 2017
From: damienrg+list at gmail.com (Damien R)
Date: Thu, 7 Dec 2017 22:03:36 +0100
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CACzuyg7JP9tcsDevprrOkt8AoUTDhUum4Mge9O4o3AVdKjt74w@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
 <CAPASGLrCX8ST=x7f9R_4saSvp6Nj-JuDD=42KMMNadz9fyzONQ@mail.gmail.com>
 <CAKPeRicwuXEti_=72Zn6GFC3bXFAaRU9q8Bmas-eEiVaDg2TFQ@mail.gmail.com>
 <CACzuyg7JP9tcsDevprrOkt8AoUTDhUum4Mge9O4o3AVdKjt74w@mail.gmail.com>
Message-ID: <CAKPeRido9XbX6BajT2CCr81RNoC3VC645XVkW1hQbdGwVh6yyQ@mail.gmail.com>

check_cxx_compiler_flag uses CMAKE_REQUIRED_DEFINITIONS. For me its means
that only "-DSOME_FLAG=VALUE" should be tested with this macro and I think
that the name is misleading.
Some people define CMAKE_REQUIRED_FLAGS / CMAKE_REQUIRED_LIBRARIES before
invoking check_cxx_compiler_flag but I think that they should use
check_cxx_source_compiles.
In your case I would use CMAKE_REQUIRED_FLAGS and check_cxx_source_compiles.

But as I am not the developer which has written this cmake code there may
be some points that invalidate what I just said.

Regards,

Damien R.


On 7 December 2017 at 15:13, Cl?ment Gregoire <lectem at gmail.com> wrote:

> Your usage of check_cxx_compiler_flag is correct, it's probably just
> missing link flags or something.
> Can you check the error log of cmake to know why it fails to compile ? It
> is in your buildfolder : CMakeFiles/CMakeError.log
>
> Here's how I did it for coverage by the way (not perfect, but was enough
> for my usage):
>
> https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/
> Coverage.cmake#L42
>
>
>
>
> 2017-12-07 14:31 GMT+01:00 Damien R <damienrg+list at gmail.com>:
>
>> Thank you for pointing that. It increments the number of people using
>> CMAKE_REQUIRED_FLAGS "trick" to make it working with
>> check_cxx_compiler_flag.
>>
>> But my question is more about :
>>  - why they coded CHECK_CXX_COMPILER_FLAG this way?
>>  - is my usage valid or not? If not what should I do? If yes, is it a bug?
>>
>> Regards,
>>
>> Damien R.
>>
>>
>>
>> On 7 December 2017 at 10:35, Eric Noulard <eric.noulard at gmail.com> wrote:
>>
>>>
>>> Not really answering the question but
>>> did you try to use an existing CMake module for handling sanitizers
>>> config?
>>>
>>> I find this one https://github.com/arsenm/sanitizers-cmake very
>>> effective, with
>>> modern CMake target oriented features.
>>>
>>>
>>>
>>>
>>> 2017-12-07 9:24 GMT+01:00 Damien R <damienrg+list at gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>>> the compiler supports asan.
>>>> The CMakeLists.txt is:
>>>> cmake_minimum_required(VERSION 3.9)
>>>> include(CheckCXXCompilerFlag)
>>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>>
>>>> I always got:
>>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>>
>>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>>>> work.
>>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>>> and what is the official way for checking this flag?
>>>>
>>>> Regards,
>>>>
>>>> Damien R.
>>>>
>>>>
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/cmake
>>>>
>>>
>>>
>>>
>>> --
>>> Eric
>>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/500acf2e/attachment.html>

From r030t1 at gmail.com  Thu Dec  7 16:24:15 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 7 Dec 2017 15:24:15 -0600
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
Message-ID: <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>

Mr. Odera,

On Thu, Dec 7, 2017 at 8:30 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi CMake Experts,
>
> Please I use CMake to build my Geant4 applications with no issues. However,
> recently I needed to build ROOT into my Geant4 application for the purpose
> of extracting and processing simulation data. I have followed the many
> instructions which exist online both on the Genat4 and ROOT sides but none
> seems to produce the required results. The issue i'm having I believe is
> related to the linkage of both Geant4 and ROOT libraries top the generated
> executable during compilation. I am able to configure and generate build
> files with a CMakeLists with no errors. Compilation also seems to also
> complete with no errors but when I run the application I get an error which
> specifies that LLVM are exposed to Cling and so I need to hide them. In my
> CMakeLists (which I can provide to you) I do not explicitly link Cling to my
> executable all I do is link the executable to ROOT libraries
> (${ROOT_LIBRARIES}). Please, could you help me with this issue or do you
> know a way that I could link libraries and not expose LLVM to Cling? Thank
> you.
>

If you want help you really should try to answer some of the questions
I asked in my previous email. It happens that I have some experience
with the packages you are trying to use, but you seem to be using them
in a configuration I am not familiar with (i.e. you generated a
standalone demo that you want to distribute?).

It is important I know where you got the packages, how you built them,
and even better, what precisely you are trying to do with them; it
sounds almost like this is a question more suited to ROOT/Geant4
developers than this mailing list.

Cheers,
     R0b0t1

From Odera_Dim at student.uml.edu  Thu Dec  7 17:25:49 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Thu, 7 Dec 2017 22:25:49 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
Message-ID: <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>

Hi,

First of all sorry but I didn't get any previous mail before this, hence my lack of response. I actually had to ask Libby to help me some moments ago before I now just received your email.

Secondly, I have tried to post this issue on both the ROOT and Geant4 forums and have not received any feedback so far.

The application I'm building is for in-house use so it won't be distributed. The application I have built in Geant4 has a class (i.e. analysis.cc<http://analysis.cc>) that uses a number of function header like TH2D.h, TROOT etc to setup a means to extract data produced in my Geant4 application. For example I have created an instance of analysis.cc<http://analysis.cc> in my events class such that after each even I can collect the number of particles produced. Now what I have in my CMakeList.txt is structured such that the Geant4 application can function weather ROOT is installed or not. I have attached my CMakeList.txt file for you to kindly look through.

The error I get as I may have mentioned before in my previous email occurs when I run the Geant4 application. Since the error makes mention of the LLVM being exposed to cling my little knowledge on the subject inclines me to thinking that some how the way I have the Libraries linked to my application might be the issue (however, I may be wrong). Also I have been able to build, compile and run this Geant4 application with no error if I remove ROOT from my build. On the other-hand I have also used ROOT independently of Geant4 to process data. Please let me know if you have more question as I still don't have the email you sent before the current one. Thank you.

Dim Odera
Nuclear Engineering
UMass Lowell

On Dec 7, 2017, at 4:24 PM, R0b0t1 <r030t1 at gmail.com<mailto:r030t1 at gmail.com>> wrote:

Mr. Odera,

On Thu, Dec 7, 2017 at 8:30 AM, Dim, Odera U <Odera_Dim at student.uml.edu<mailto:Odera_Dim at student.uml.edu>> wrote:
Hi CMake Experts,

Please I use CMake to build my Geant4 applications with no issues. However,
recently I needed to build ROOT into my Geant4 application for the purpose
of extracting and processing simulation data. I have followed the many
instructions which exist online both on the Genat4 and ROOT sides but none
seems to produce the required results. The issue i'm having I believe is
related to the linkage of both Geant4 and ROOT libraries top the generated
executable during compilation. I am able to configure and generate build
files with a CMakeLists with no errors. Compilation also seems to also
complete with no errors but when I run the application I get an error which
specifies that LLVM are exposed to Cling and so I need to hide them. In my
CMakeLists (which I can provide to you) I do not explicitly link Cling to my
executable all I do is link the executable to ROOT libraries
(${ROOT_LIBRARIES}). Please, could you help me with this issue or do you
know a way that I could link libraries and not expose LLVM to Cling? Thank
you.


If you want help you really should try to answer some of the questions
I asked in my previous email. It happens that I have some experience
with the packages you are trying to use, but you seem to be using them
in a configuration I am not familiar with (i.e. you generated a
standalone demo that you want to distribute?).

It is important I know where you got the packages, how you built them,
and even better, what precisely you are trying to do with them; it
sounds almost like this is a question more suited to ROOT/Geant4
developers than this mailing list.

Cheers,
    R0b0t1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/fa5e8276/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171207/fa5e8276/attachment-0001.txt>

From r030t1 at gmail.com  Thu Dec  7 19:54:05 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 7 Dec 2017 18:54:05 -0600
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
Message-ID: <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>

Mr. Odera,

On Thu, Dec 7, 2017 at 4:25 PM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
> First of all sorry but I didn't get any previous mail before this, hence my
> lack of response. I actually had to ask Libby to help me some moments ago
> before I now just received your email.
>
> Secondly, I have tried to post this issue on both the ROOT and Geant4 forums
> and have not received any feedback so far.
>
> The application I'm building is for in-house use so it won't be distributed.
> The application I have built in Geant4 has a class (i.e. analysis.cc) that
> uses a number of function header like TH2D.h, TROOT etc to setup a means to
> extract data produced in my Geant4 application. For example I have created
> an instance of analysis.cc in my events class such that after each even I
> can collect the number of particles produced. Now what I have in my
> CMakeList.txt is structured such that the Geant4 application can function
> weather ROOT is installed or not. I have attached my CMakeList.txt file for
> you to kindly look through.
>

The CMakeList.txt is a good start, but I still need the full text of
the error(s) and I may need the rest of your project to demonstrate
the issue. If you can't publicly share your project you will need to
create a minimum working example that exhibits your problem.

That you didn't initially include any of these is likely why you did
not receive responses on the ROOT and Geant4 forums.

> The error I get as I may have mentioned before in my previous email occurs
> when I run the Geant4 application. Since the error makes mention of the LLVM
> being exposed to cling my little knowledge on the subject inclines me to
> thinking that some how the way I have the Libraries linked to my application
> might be the issue (however, I may be wrong). Also I have been able to
> build, compile and run this Geant4 application with no error if I remove
> ROOT from my build. On the other-hand I have also used ROOT independently of
> Geant4 to process data. Please let me know if you have more question as I
> still don't have the email you sent before the current one. Thank you.
>

Here are my previous questions:

> Can you provide the text of the errors as they are given? Are you
> experiencing build errors, or are you wanting to quiet runtime
> messages?
>
> Which OS are you compiling and running on? Which build instructions
>are you following? What are the build commands that you ran?

To add to this, how did you acquire ROOT/Geant4 and which options are
enabled, since it seems your question is about building a program of
your own? Regardless of whether or not you will be distributing
binaries, these are important questions to ask to make sure your
program can be built easily in the future.

Cheers,
     R0b0t1

From JHancox at tmvse.com  Fri Dec  8 03:56:48 2017
From: JHancox at tmvse.com (Hancox, James)
Date: Fri, 8 Dec 2017 08:56:48 +0000
Subject: [CMake] CUDA support- no way to set GPUDebugInfo to be False ?
Message-ID: <821AF9D715B4204EAF7006E66A706406FFD37E93@EDIEXCHANGE.local.tmvse.com>

Hi,

I'm working on porting an existing FindCUDA project over to using the new CMake built-in CUDA support, with Visual Studio 15.4.1, CUDA 9.0.176, and CMake 3.10.0. I am currently trying to find a way to disable the -G compilation flag for NVCC with Debug builds. (Due to the nature of our code, building with -G set takes an inordinately long time and still produces terrible debug info, so we prefer to leave it off- but we still want Debug builds so that we can easily debug CPU side code.)

Unfortunately by default the Nvidia CUDA plugin for Visual Studio sets -G by default for debug builds. Disabling it requires the addition of

<GPUDebugInfo>false</GPUDebugInfo>

to the <CudaCompile> section of the .vcxproj file. I can't currently find any way to do this through Cmake. Have I missed something obvious, or is this not a supported feature?

Many thanks,
James Hancox


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/7d9f79bb/attachment.html>

From brad.king at kitware.com  Fri Dec  8 06:36:18 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 8 Dec 2017 06:36:18 -0500
Subject: [CMake] [CMAKE] - custom compiler for Android
In-Reply-To: <010601d36eb0$be051560$3a0f4020$@accoliteindia.com>
References: <00f201d36deb$5464f140$fd2ed3c0$@accoliteindia.com>
 <abf476cd-b395-b465-5dfd-f28dc9d13eaf@kitware.com>
 <010601d36eb0$be051560$3a0f4020$@accoliteindia.com>
Message-ID: <1fe1a280-11ee-241a-ebac-0e653677879c@kitware.com>

On 12/06/2017 11:39 AM, ramya.gopalkrishna at accoliteindia.com wrote:
> Can you please give us some guidance to achieve the same with
> CMAKE_SYSTEM_NAME as "Android"

You'd need to teach

  Modules/Compiler/Embarcadero-DetermineCompiler.cmake

to recognize the compiler as Embarcadero if it doesn't already,
and then add Modules/Platform/Android* modules named with that
compiler id.

-Brad

From robert.maynard at kitware.com  Fri Dec  8 08:32:49 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 8 Dec 2017 08:32:49 -0500
Subject: [CMake] CUDA support- no way to set GPUDebugInfo to be False ?
In-Reply-To: <821AF9D715B4204EAF7006E66A706406FFD37E93@EDIEXCHANGE.local.tmvse.com>
References: <821AF9D715B4204EAF7006E66A706406FFD37E93@EDIEXCHANGE.local.tmvse.com>
Message-ID: <CAFzjYVociNojmec9yMXhdC6Opa1bw3dyLYxkN2Mrd60iQtNFBQ@mail.gmail.com>

This is an oversight rather than an unsupported feature. Can you
report this as an issue on https://gitlab.kitware.com/cmake/cmake

On Fri, Dec 8, 2017 at 3:56 AM, Hancox, James <JHancox at tmvse.com> wrote:
> Hi,
>
>
>
> I?m working on porting an existing FindCUDA project over to using the new
> CMake built-in CUDA support, with Visual Studio 15.4.1, CUDA 9.0.176, and
> CMake 3.10.0. I am currently trying to find a way to disable the -G
> compilation flag for NVCC with Debug builds. (Due to the nature of our code,
> building with -G set takes an inordinately long time and still produces
> terrible debug info, so we prefer to leave it off- but we still want Debug
> builds so that we can easily debug CPU side code.)
>
>
>
> Unfortunately by default the Nvidia CUDA plugin for Visual Studio sets -G by
> default for debug builds. Disabling it requires the addition of
>
> <GPUDebugInfo>false</GPUDebugInfo>
>
>
>
> to the <CudaCompile> section of the .vcxproj file. I can?t currently find
> any way to do this through Cmake. Have I missed something obvious, or is
> this not a supported feature?
>
>
>
> Many thanks,
>
> James Hancox
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From eric.noulard at gmail.com  Fri Dec  8 10:42:52 2017
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 8 Dec 2017 16:42:52 +0100
Subject: [CMake] INTERFACE library and path to source.
Message-ID: <CAPASGLonEaAaCpkhXAkjFRfRByRN5PuzFC8Aa_cCZXwUo9bD3w@mail.gmail.com>

Hi there,

I encounter a weird issue with header-only library.

Somewhere in my source tree I have an header library which consist in a
bunch of headers:

The concerned CMakeLists.txt looks like this:

add_library(MyHeaderLIB INTERFACE)

target_include_directories(MyHeaderLIB INTERFACE
    ${CMAKE_CURRENT_SOURCE_DIR})

target_sources(MyHeaderLIB INTERFACE
  whatever.h)


Somewhere else (in another directory) I have another CMakeLists.txt:

add_executable(myexe myexe.cpp)
target_link_libraries(myexe MyHeaderLIB)

and CMake complains when processing it that he cannot find "whatever.h"...

The problem disappear if I use full path in target_source, i.e.:

target_sources(MyHeaderLIB INTERFACE
 ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h)


Why should I do that?
I this the expected behavior / way to create header only library?


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/c3ebe66b/attachment.html>

From Odera_Dim at student.uml.edu  Fri Dec  8 12:36:01 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Fri, 8 Dec 2017 17:36:01 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>,
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
Message-ID: <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi,


You are right about this but in my honest defense no one asked me to send the files. I have included a RAR file containing the application giving the  error stated (Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE EXPOSED TO CLING! This will cause problems; please hide them or dlopen() them after the call to TROOT::InitInterpreter()!

Segmentation fault). Although this project is not completely under my control I have scaled down the application to a minimum that still generates the error above . Thank so much you for your offer to help with this issue. Cheers.

Dim Odera

________________________________
From: R0b0t1 <r030t1 at gmail.com>
Sent: Thursday, December 7, 2017 7:54:05 PM
To: Dim, Odera U
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application

Mr. Odera,

On Thu, Dec 7, 2017 at 4:25 PM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
> First of all sorry but I didn't get any previous mail before this, hence my
> lack of response. I actually had to ask Libby to help me some moments ago
> before I now just received your email.
>
> Secondly, I have tried to post this issue on both the ROOT and Geant4 forums
> and have not received any feedback so far.
>
> The application I'm building is for in-house use so it won't be distributed.
> The application I have built in Geant4 has a class (i.e. analysis.cc) that
> uses a number of function header like TH2D.h, TROOT etc to setup a means to
> extract data produced in my Geant4 application. For example I have created
> an instance of analysis.cc in my events class such that after each even I
> can collect the number of particles produced. Now what I have in my
> CMakeList.txt is structured such that the Geant4 application can function
> weather ROOT is installed or not. I have attached my CMakeList.txt file for
> you to kindly look through.
>

The CMakeList.txt is a good start, but I still need the full text of
the error(s) and I may need the rest of your project to demonstrate
the issue. If you can't publicly share your project you will need to
create a minimum working example that exhibits your problem.

That you didn't initially include any of these is likely why you did
not receive responses on the ROOT and Geant4 forums.

> The error I get as I may have mentioned before in my previous email occurs
> when I run the Geant4 application. Since the error makes mention of the LLVM
> being exposed to cling my little knowledge on the subject inclines me to
> thinking that some how the way I have the Libraries linked to my application
> might be the issue (however, I may be wrong). Also I have been able to
> build, compile and run this Geant4 application with no error if I remove
> ROOT from my build. On the other-hand I have also used ROOT independently of
> Geant4 to process data. Please let me know if you have more question as I
> still don't have the email you sent before the current one. Thank you.
>

Here are my previous questions:

> Can you provide the text of the errors as they are given? Are you
> experiencing build errors, or are you wanting to quiet runtime
> messages?
>
> Which OS are you compiling and running on? Which build instructions
>are you following? What are the build commands that you ran?

To add to this, how did you acquire ROOT/Geant4 and which options are
enabled, since it seems your question is about building a program of
your own? Regardless of whether or not you will be distributing
binaries, these are important questions to ask to make sure your
program can be built easily in the future.

Cheers,
     R0b0t1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/5e894416/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KitWare.rar
Type: application/octet-stream
Size: 50816 bytes
Desc: KitWare.rar
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/5e894416/attachment-0001.obj>

From Odera_Dim at student.uml.edu  Fri Dec  8 12:43:42 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Fri, 8 Dec 2017 17:43:42 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>,
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>,
 <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
Message-ID: <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi,


I just tried to sent the files you and the email server bounced it (I attempted sending it as a RAR file). Please what do you suggest I do?


Thanks.

________________________________
From: Dim, Odera U
Sent: Friday, December 8, 2017 12:36:01 PM
To: R0b0t1
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application


Hi,


You are right about this but in my honest defense no one asked me to send the files. I have included a RAR file containing the application giving the  error stated (Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE EXPOSED TO CLING! This will cause problems; please hide them or dlopen() them after the call to TROOT::InitInterpreter()!

Segmentation fault). Although this project is not completely under my control I have scaled down the application to a minimum that still generates the error above . Thank so much you for your offer to help with this issue. Cheers.

Dim Odera

________________________________
From: R0b0t1 <r030t1 at gmail.com>
Sent: Thursday, December 7, 2017 7:54:05 PM
To: Dim, Odera U
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application

Mr. Odera,

On Thu, Dec 7, 2017 at 4:25 PM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
> First of all sorry but I didn't get any previous mail before this, hence my
> lack of response. I actually had to ask Libby to help me some moments ago
> before I now just received your email.
>
> Secondly, I have tried to post this issue on both the ROOT and Geant4 forums
> and have not received any feedback so far.
>
> The application I'm building is for in-house use so it won't be distributed.
> The application I have built in Geant4 has a class (i.e. analysis.cc) that
> uses a number of function header like TH2D.h, TROOT etc to setup a means to
> extract data produced in my Geant4 application. For example I have created
> an instance of analysis.cc in my events class such that after each even I
> can collect the number of particles produced. Now what I have in my
> CMakeList.txt is structured such that the Geant4 application can function
> weather ROOT is installed or not. I have attached my CMakeList.txt file for
> you to kindly look through.
>

The CMakeList.txt is a good start, but I still need the full text of
the error(s) and I may need the rest of your project to demonstrate
the issue. If you can't publicly share your project you will need to
create a minimum working example that exhibits your problem.

That you didn't initially include any of these is likely why you did
not receive responses on the ROOT and Geant4 forums.

> The error I get as I may have mentioned before in my previous email occurs
> when I run the Geant4 application. Since the error makes mention of the LLVM
> being exposed to cling my little knowledge on the subject inclines me to
> thinking that some how the way I have the Libraries linked to my application
> might be the issue (however, I may be wrong). Also I have been able to
> build, compile and run this Geant4 application with no error if I remove
> ROOT from my build. On the other-hand I have also used ROOT independently of
> Geant4 to process data. Please let me know if you have more question as I
> still don't have the email you sent before the current one. Thank you.
>

Here are my previous questions:

> Can you provide the text of the errors as they are given? Are you
> experiencing build errors, or are you wanting to quiet runtime
> messages?
>
> Which OS are you compiling and running on? Which build instructions
>are you following? What are the build commands that you ran?

To add to this, how did you acquire ROOT/Geant4 and which options are
enabled, since it seems your question is about building a program of
your own? Regardless of whether or not you will be distributing
binaries, these are important questions to ask to make sure your
program can be built easily in the future.

Cheers,
     R0b0t1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/53a48ada/attachment.html>

From hashemi at brandeis.edu  Fri Dec  8 14:15:26 2017
From: hashemi at brandeis.edu (Kevan Hashemi)
Date: Fri, 8 Dec 2017 14:15:26 -0500
Subject: [CMake] MinGW Compilers on Windows
Message-ID: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>

Greetings,

I'm new to CMake, so please forgive this basic question.

I'd like to use CMake to build OpenCV on Windows 7 using the C and C++ compilers that come with my 
installation of MinGW. I compile all my other code with GCC compilers, from the command line of the 
MSYS Bash shell, so I figure I can be certain to link OpenCV to my existing code if I compile with 
GCC compilers.

I installed the Windows GUI of CMake and I told it to use the MinGW C and C++ compilers. I point 
CMake at my OpenCV directory and a build directory. When I press configure, I get this error:

Selecting Windows SDK version to target Windows 6.1.7601.
CMake Error at CMakeLists.txt:64 (project):
Failed to run MSBuild command:
MSBuild.exe to get the value of VCTargetsPath:
The system cannot find the file specified
Configuring incomplete, errors occurred!
See also "F:/OpenCV/build/CMakeFiles/CMakeOutput.log".

If my understanding of CMake is correct, this error cannot not come directly from CMake, but rather 
is caused by OpenCV asking for MSBuild. But I can find no instance of the styring "MSBuild" in the 
OpenCV diretory tree. So my understanding must be wrong.

Why is CMake looking for MSBuild? Can I build on Windows using compilers of my choice?

Yours, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

From annulen at yandex.ru  Fri Dec  8 14:17:55 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 08 Dec 2017 22:17:55 +0300
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
Message-ID: <4651711512760675@web57j.yandex.ru>



08.12.2017, 22:16, "Kevan Hashemi" <hashemi at brandeis.edu>:
> Greetings,
>
> I'm new to CMake, so please forgive this basic question.
>
> I'd like to use CMake to build OpenCV on Windows 7 using the C and C++ compilers that come with my
> installation of MinGW. I compile all my other code with GCC compilers, from the command line of the
> MSYS Bash shell, so I figure I can be certain to link OpenCV to my existing code if I compile with
> GCC compilers.
>
> I installed the Windows GUI of CMake and I told it to use the MinGW C and C++ compilers. I point
> CMake at my OpenCV directory and a build directory. When I press configure, I get this error:
>
> Selecting Windows SDK version to target Windows 6.1.7601.
> CMake Error at CMakeLists.txt:64 (project):
> Failed to run MSBuild command:
> MSBuild.exe to get the value of VCTargetsPath:
> The system cannot find the file specified
> Configuring incomplete, errors occurred!
> See also "F:/OpenCV/build/CMakeFiles/CMakeOutput.log".
>
> If my understanding of CMake is correct, this error cannot not come directly from CMake, but rather
> is caused by OpenCV asking for MSBuild. But I can find no instance of the styring "MSBuild" in the
> OpenCV diretory tree. So my understanding must be wrong.
>
> Why is CMake looking for MSBuild? Can I build on Windows using compilers of my choice?

Of course, but you should choose a suitable generator, e.g. -G "MinGW Makefiles"

>
> Yours, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://alignment.hep.brandeis.edu/
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 
Regards,
Konstantin

From hashemi at brandeis.edu  Fri Dec  8 14:44:54 2017
From: hashemi at brandeis.edu (Kevan Hashemi)
Date: Fri, 8 Dec 2017 14:44:54 -0500
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <4651711512760675@web57j.yandex.ru>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
Message-ID: <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>

Dear Konstantin,

> Of course, but you should choose a suitable generator, e.g. -G "MinGW Makefiles"

That makes perfect sense. Indeed, having selected "MinGW Makefiles" I don't evgen have to specify 
the compilers, I can say "use native compilers". I also had to add MinGW/bin to the Winodws path, so 
that CMake could run the native compilers and test them without launching MSYS.

Thank you, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

From r030t1 at gmail.com  Fri Dec  8 15:35:45 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Fri, 8 Dec 2017 14:35:45 -0600
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
 <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
Message-ID: <CAAD4mYjf-+kU67G36pRqzLTfsNDADBCxyKANE9ofchW6-YQFDg@mail.gmail.com>

On Fri, Dec 8, 2017 at 11:36 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> You are right about this but in my honest defense no one asked me to send
> the files. I have included a RAR file containing the application giving the
> error stated (Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE
> EXPOSED TO CLING! This will cause problems; please hide them or dlopen()
> them after the call to TROOT::InitInterpreter()!
>
> Segmentation fault). Although this project is not completely under my
> control I have scaled down the application to a minimum that still generates
> the error above . Thank so much you for your offer to help with this issue.
> Cheers.
>

Right, I didn't mean to sound unfriendly, but I think the explanation
would be helpful. Can you provide more context? Please also address my
other questions if you can, or explain how you do not know enough to
answer.

The problem is starting to look like an issue with how you have
installed ROOT or Geant4, which is why I asked about how you acquired
them.


On Fri, Dec 8, 2017 at 11:43 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> I just tried to sent the files you and the email server bounced it (I
> attempted sending it as a RAR file). Please what do you suggest I do?
>

If you can, putting it on GitHub would be the best option
(https://git-scm.com/download/win and see GitHub tutorials). Otherwise
you can look at a file host like https://mega.co.nz. Should you want
to try by email again, some lists will accept .tar.bz2, .tar.gz, and
.tar.xz. If you are on Windows you will probably need to install
Cygwin (https://www.cygwin.com/) or 7zip (http://www.7-zip.org/) to
create an archive of those types.

Cheers,
     R0b0t1

From lectem at gmail.com  Fri Dec  8 15:58:22 2017
From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=)
Date: Fri, 08 Dec 2017 20:58:22 +0000
Subject: [CMake] check_cxx_compiler_flag usage
In-Reply-To: <CAKPeRido9XbX6BajT2CCr81RNoC3VC645XVkW1hQbdGwVh6yyQ@mail.gmail.com>
References: <CAKPeRifNBoUaRk+5+HchS-ZD8+enny1Gr0QEOu3kNp1LU3OBEQ@mail.gmail.com>
 <CAPASGLrCX8ST=x7f9R_4saSvp6Nj-JuDD=42KMMNadz9fyzONQ@mail.gmail.com>
 <CAKPeRicwuXEti_=72Zn6GFC3bXFAaRU9q8Bmas-eEiVaDg2TFQ@mail.gmail.com>
 <CACzuyg7JP9tcsDevprrOkt8AoUTDhUum4Mge9O4o3AVdKjt74w@mail.gmail.com>
 <CAKPeRido9XbX6BajT2CCr81RNoC3VC645XVkW1hQbdGwVh6yyQ@mail.gmail.com>
Message-ID: <CACzuyg7vVG5X3iw-1bZ_EMPTWd96XnaH8=99irSsG4ZDU8eRnQ@mail.gmail.com>

Sorry I got confused in what you were trying to say.
It indeed seems to be an error, as checking if a compiler supports some
defines does not make sense. Might be that an error occurred when
COMPILE_FLAGS became COMPILE_OPTIONS or something.
I would suggest opening an issue on cmake gitlab about it. (I also added
the cmake-dev list to cc)

However, it does indeed work for me, the script I linked before really
tries to use the - -coverage, and fails accordingly when using msvc, and
works with GCC. It wouldn't surprise me if cmake had some fallback when
detecting options in the definition variable.


I still think that checking the CMakeError.log to see what command is used
for the test in your case would be interesting to know what really happens
in your case.

Regards,
Lectem.

Le jeu. 7 d?c. 2017 ? 22:04, Damien R <damienrg+list at gmail.com> a ?crit :

> check_cxx_compiler_flag uses CMAKE_REQUIRED_DEFINITIONS. For me its means
> that only "-DSOME_FLAG=VALUE" should be tested with this macro and I think
> that the name is misleading.
> Some people define CMAKE_REQUIRED_FLAGS / CMAKE_REQUIRED_LIBRARIES before
> invoking check_cxx_compiler_flag but I think that they should use
> check_cxx_source_compiles.
> In your case I would use CMAKE_REQUIRED_FLAGS and
> check_cxx_source_compiles.
>
> But as I am not the developer which has written this cmake code there may
> be some points that invalidate what I just said.
>
> Regards,
>
> Damien R.
>
>
> On 7 December 2017 at 15:13, Cl?ment Gregoire <lectem at gmail.com> wrote:
>
>> Your usage of check_cxx_compiler_flag is correct, it's probably just
>> missing link flags or something.
>> Can you check the error log of cmake to know why it fails to compile ? It
>> is in your buildfolder : CMakeFiles/CMakeError.log
>>
>> Here's how I did it for coverage by the way (not perfect, but was enough
>> for my usage):
>>
>>
>> https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake#L42
>>
>>
>>
>>
>> 2017-12-07 14:31 GMT+01:00 Damien R <damienrg+list at gmail.com>:
>>
>>> Thank you for pointing that. It increments the number of people using
>>> CMAKE_REQUIRED_FLAGS "trick" to make it working with
>>> check_cxx_compiler_flag.
>>>
>>> But my question is more about :
>>>  - why they coded CHECK_CXX_COMPILER_FLAG this way?
>>>  - is my usage valid or not? If not what should I do? If yes, is it a
>>> bug?
>>>
>>> Regards,
>>>
>>> Damien R.
>>>
>>>
>>>
>>> On 7 December 2017 at 10:35, Eric Noulard <eric.noulard at gmail.com>
>>> wrote:
>>>
>>>>
>>>> Not really answering the question but
>>>> did you try to use an existing CMake module for handling sanitizers
>>>> config?
>>>>
>>>> I find this one https://github.com/arsenm/sanitizers-cmake very
>>>> effective, with
>>>> modern CMake target oriented features.
>>>>
>>>>
>>>>
>>>>
>>>> 2017-12-07 9:24 GMT+01:00 Damien R <damienrg+list at gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>>>> the compiler supports asan.
>>>>> The CMakeLists.txt is:
>>>>> cmake_minimum_required(VERSION 3.9)
>>>>> include(CheckCXXCompilerFlag)
>>>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>>>
>>>>> I always got:
>>>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>>>
>>>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>>>>> work.
>>>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>>>> and what is the official way for checking this flag?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Damien R.
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>
>>>>> Kitware offers various services to support the CMake community. For
>>>>> more information on each offering, please visit:
>>>>>
>>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/cmake
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Eric
>>>>
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/09c89ecc/attachment.html>

From irwin at beluga.phys.uvic.ca  Fri Dec  8 15:57:18 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 8 Dec 2017 12:57:18 -0800 (PST)
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
 <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
Message-ID: <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>

On 2017-12-08 14:44-0500 Kevan Hashemi wrote:

> Dear Konstantin,
>
>> Of course, but you should choose a suitable generator, e.g. -G "MinGW 
>> Makefiles"
>
> That makes perfect sense. Indeed, having selected "MinGW Makefiles" I don't 
> evgen have to specify the compilers, I can say "use native compilers". I also 
> had to add MinGW/bin to the Winodws path, so that CMake could run the native 
> compilers and test them without launching MSYS.

If you need/prefer Unix tools provided by MSYS to build your software,
another possible generator you should look at is "MSYS Makefiles". We
never tried it before PLplot moved on to using MinGW-w64/MSYS2 (see
below), but I think "Unix Makefiles" might work for most MinGW/MSYS
build needs as well.

You certainly have those three generator choices for the modern
rewrite of the MinGW/MSYS platform, MinGW-w64/MSYS2
<https://github.com/msys2/msys2/wiki>.  In addition, MinGW-w64/MSYS2
provides many more free-software libraries than provided by MinGW/MSYS
so if your software has soft dependencies on lots of such libraries
(as in our PLplot case) the MinGW-w64/MSYS2 platform is far
preferred over the MinGW/MSYS platform.

Note some of the above statements are summaries of what has been
figured out by those on the PLplot development team who have access to
the Microsoft version of Windows.  I only have access to the Wine
version of Windows which works OK for MinGW/MSYS, but there is currently
a Wine bug that blocks my attempts to install MinGW-w64/MSYS2.

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 Odera_Dim at student.uml.edu  Fri Dec  8 16:44:47 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Fri, 8 Dec 2017 21:44:47 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <CAAD4mYjf-+kU67G36pRqzLTfsNDADBCxyKANE9ofchW6-YQFDg@mail.gmail.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
 <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>,
 <CAAD4mYjf-+kU67G36pRqzLTfsNDADBCxyKANE9ofchW6-YQFDg@mail.gmail.com>
Message-ID: <BY2PR02MB21494175631DF092D6285D67D1300@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi,


Thank you for your prompt response. I found downloading 7zip the easier route to get the files into a .tar format which would enable them to be sent to you. One question which I did not address which you asked is where I accesses the Geant4 and ROOT. I downloaded both CERN website and installed them on a remote Unix cluster which I have access to. I followed the prescribed installation process which is available on the CERN website. Although, I have Genat4 complied for Multi-threading I do not use the feature yet because my application is still undergoing many modifications. I will send the previous email I sent when the initial file got bounced by your email server. Cheers.


Dim Odera

________________________________
From: R0b0t1 <r030t1 at gmail.com>
Sent: Friday, December 8, 2017 3:35:45 PM
To: Dim, Odera U
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application

On Fri, Dec 8, 2017 at 11:36 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> You are right about this but in my honest defense no one asked me to send
> the files. I have included a RAR file containing the application giving the
> error stated (Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE
> EXPOSED TO CLING! This will cause problems; please hide them or dlopen()
> them after the call to TROOT::InitInterpreter()!
>
> Segmentation fault). Although this project is not completely under my
> control I have scaled down the application to a minimum that still generates
> the error above . Thank so much you for your offer to help with this issue.
> Cheers.
>

Right, I didn't mean to sound unfriendly, but I think the explanation
would be helpful. Can you provide more context? Please also address my
other questions if you can, or explain how you do not know enough to
answer.

The problem is starting to look like an issue with how you have
installed ROOT or Geant4, which is why I asked about how you acquired
them.


On Fri, Dec 8, 2017 at 11:43 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> I just tried to sent the files you and the email server bounced it (I
> attempted sending it as a RAR file). Please what do you suggest I do?
>

If you can, putting it on GitHub would be the best option
(https://git-scm.com/download/win and see GitHub tutorials). Otherwise
you can look at a file host like https://mega.co.nz. Should you want
to try by email again, some lists will accept .tar.bz2, .tar.gz, and
.tar.xz. If you are on Windows you will probably need to install
Cygwin (https://www.cygwin.com/) or 7zip (http://www.7-zip.org/) to
create an archive of those types.

Cheers,
     R0b0t1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/7438c2b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KitWare.tar
Type: application/x-tar
Size: 181760 bytes
Desc: KitWare.tar
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/7438c2b1/attachment-0001.tar>

From Odera_Dim at student.uml.edu  Fri Dec  8 16:48:15 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Fri, 8 Dec 2017 21:48:15 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <BY2PR02MB21494175631DF092D6285D67D1300@BY2PR02MB2149.namprd02.prod.outlook.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
 <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>,
 <CAAD4mYjf-+kU67G36pRqzLTfsNDADBCxyKANE9ofchW6-YQFDg@mail.gmail.com>,
 <BY2PR02MB21494175631DF092D6285D67D1300@BY2PR02MB2149.namprd02.prod.outlook.com>
Message-ID: <BY2PR02MB214914D00F9B41A221B5F206D1300@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi,


This is the text of the initial message I set to you without the .rar file. You are right about this but in my honest defense no one asked me to send the files. I have included a RAR file containing the application giving the  error stated (Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE EXPOSED TO CLING! This will cause problems; please hide them or dlopen() them after the call to TROOT::InitInterpreter()!

Segmentation fault). Although this project is not completely under my control I have scaled down the application to a minimum that still generates the error above . Thank so much you for your offer to help with this issue. Cheers.

Dim Odera


________________________________
From: Dim, Odera U
Sent: Friday, December 8, 2017 4:44:47 PM
To: R0b0t1
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application


Hi,


Thank you for your prompt response. I found downloading 7zip the easier route to get the files into a .tar format which would enable them to be sent to you. One question which I did not address which you asked is where I accesses the Geant4 and ROOT. I downloaded both CERN website and installed them on a remote Unix cluster which I have access to. I followed the prescribed installation process which is available on the CERN website. Although, I have Genat4 complied for Multi-threading I do not use the feature yet because my application is still undergoing many modifications. I will send the previous email I sent when the initial file got bounced by your email server. Cheers.


Dim Odera

________________________________
From: R0b0t1 <r030t1 at gmail.com>
Sent: Friday, December 8, 2017 3:35:45 PM
To: Dim, Odera U
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application

On Fri, Dec 8, 2017 at 11:36 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> You are right about this but in my honest defense no one asked me to send
> the files. I have included a RAR file containing the application giving the
> error stated (Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE
> EXPOSED TO CLING! This will cause problems; please hide them or dlopen()
> them after the call to TROOT::InitInterpreter()!
>
> Segmentation fault). Although this project is not completely under my
> control I have scaled down the application to a minimum that still generates
> the error above . Thank so much you for your offer to help with this issue.
> Cheers.
>

Right, I didn't mean to sound unfriendly, but I think the explanation
would be helpful. Can you provide more context? Please also address my
other questions if you can, or explain how you do not know enough to
answer.

The problem is starting to look like an issue with how you have
installed ROOT or Geant4, which is why I asked about how you acquired
them.


On Fri, Dec 8, 2017 at 11:43 AM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> I just tried to sent the files you and the email server bounced it (I
> attempted sending it as a RAR file). Please what do you suggest I do?
>

If you can, putting it on GitHub would be the best option
(https://git-scm.com/download/win and see GitHub tutorials). Otherwise
you can look at a file host like https://mega.co.nz. Should you want
to try by email again, some lists will accept .tar.bz2, .tar.gz, and
.tar.xz. If you are on Windows you will probably need to install
Cygwin (https://www.cygwin.com/) or 7zip (http://www.7-zip.org/) to
create an archive of those types.

Cheers,
     R0b0t1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171208/de86beb1/attachment.html>

From oleksii.vilchanskyi at gmail.com  Fri Dec  8 19:37:40 2017
From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi)
Date: Sat, 9 Dec 2017 01:37:40 +0100
Subject: [CMake] INTERFACE library and path to source.
In-Reply-To: <CAPASGLonEaAaCpkhXAkjFRfRByRN5PuzFC8Aa_cCZXwUo9bD3w@mail.gmail.com>
References: <CAPASGLonEaAaCpkhXAkjFRfRByRN5PuzFC8Aa_cCZXwUo9bD3w@mail.gmail.com>
Message-ID: <aa29a7d8-c3fa-2212-4278-79e136793c06@gmail.com>

Hello Eric,

> Why should I do that?
> Is this the expected behavior / way to create header only library?

Yes, this is the expected behaviour. CMake interprets a relative path to
the file according to the target's add_library() or add_executable()
call directory. I will provide a minimal, reproducible example:

> .
> ??? CMakeLists.txt
> ??? lib
> ??? ??? CMakeLists.txt
> ??? ??? lib.h
> ??? main
>     ??? CMakeLists.txt
>     ??? main.c

First listfile:

> cmake_minimum_required(VERSION 3.10)
> project(main LANGUAGES C)
> add_subdirectory(lib)
> add_subdirectory(main)

Listfile under `lib`:

> add_library(lib INTERFACE)
> target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
> target_sources(lib INTERFACE "lib.h")

Listfile under `main`:

> add_executable(main "main.c")
> target_link_libraries(main PRIVATE lib)

Now, let's look at the diagnostics:

> CMake Error at main/CMakeLists.txt:1 (add_executable):
>   Cannot find source file:
> 
>     lib.h

So, the problem occurs when CMake cannot find `lib.h` relatively to
`add_executable(main "main.c")` call. Whether it's the expected
behaviour is debatable (I personally would prefer CMake to search
relatively to `add_library(lib INTERFACE)`), and the documentation is
silent on this caveat either, so there's that.

One way to solve this is to provide a path to `lib.h` relatively to
`main` directory, another way is to provide a full path.
On 12/8/17 4:42 PM, Eric Noulard wrote:
> Hi there,
> 
> I encounter a weird issue with header-only library.
> 
> Somewhere in my source tree I have an header library which consist in a
> bunch of headers:
> 
> The concerned CMakeLists.txt looks like this:
> 
> add_library(MyHeaderLIB INTERFACE)
> 
> target_include_directories(MyHeaderLIB?INTERFACE
> ? ? ${CMAKE_CURRENT_SOURCE_DIR})
> 
> target_sources(MyHeaderLIB?INTERFACE
> ? whatever.h)
> 
> 
> Somewhere else (in another directory) I have another CMakeLists.txt:
> 
> add_executable(myexe myexe.cpp)
> target_link_libraries(myexe MyHeaderLIB)
> 
> and CMake complains when processing it that he cannot find "whatever.h"...
> 
> The problem disappear if I use full path in target_source, i.e.:
> 
> target_sources(MyHeaderLIB?INTERFACE
> ?${CMAKE_CURRENT_SOURCE_DIR}/whatever.h)
> 
> 
> Why should I do that?
> I this the expected behavior / way to create header only library?
> 
> 
> -- 
> Eric
> 
> 

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338

***
All the world's a pipeline,
And all the men and women merely instructions.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171209/7350ff83/attachment.sig>

From rob.a.mcdonald at gmail.com  Sat Dec  9 12:22:58 2017
From: rob.a.mcdonald at gmail.com (Rob McDonald)
Date: Sat, 9 Dec 2017 09:22:58 -0800
Subject: [CMake] SWIG_ADD_LIBRARY Documentation?
Message-ID: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>

In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
target.  From the documentation, the options are this:

https://cmake.org/cmake/help/v3.8/module/UseSWIG.html

TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>

However, I can find no documentation of what these options mean and
why someone would choose one over the other.

I found some developer comments in KitWare's bug tracker proposing a
change of the default, but it looks like they left it as 'MODULE'.
https://gitlab.kitware.com/cmake/cmake/merge_requests/253

However, even which TYPE value is default appears undocumented.

If we want to generalize from ADD_LIBRARY, we can get an idea of what
some of the options generally mean:
https://cmake.org/cmake/help/v3.0/command/add_library.html

However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
alternate default in the referenced proposal.

So, can anyone explain in the context of SWIG/C++/Python, why I would
want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
be the practical impact on my wrapper, how it is built, its
dependencies, etc.

Thanks for any help,

Rob

From calebwherry at gmail.com  Sat Dec  9 12:43:56 2017
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Sat, 09 Dec 2017 17:43:56 +0000
Subject: [CMake] SWIG_ADD_LIBRARY Documentation?
In-Reply-To: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>
References: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>
Message-ID: <CAJxY6Xq4PdX3CMVjUoXWQNqQARNzRR=NW2WWW0KCFEdHXMQR+A@mail.gmail.com>

USE_BUILD_SHARED_LIB literally means use whatever is set by
BUILD_SHARED_LIBS. Typically, this is the preferred method for either
building a static or shared lib since the user can control what they
want/need. You don?t have to specify the type of lib to build when calling
add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise static.

Otherwise you can specify the TYPE and the user can?t override it, they
always get the type of lib you set.

-Caleb

On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <rob.a.mcdonald at gmail.com>
wrote:

> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
> target.  From the documentation, the options are this:
>
> https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
>
> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
>
> However, I can find no documentation of what these options mean and
> why someone would choose one over the other.
>
> I found some developer comments in KitWare's bug tracker proposing a
> change of the default, but it looks like they left it as 'MODULE'.
> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
>
> However, even which TYPE value is default appears undocumented.
>
> If we want to generalize from ADD_LIBRARY, we can get an idea of what
> some of the options generally mean:
> https://cmake.org/cmake/help/v3.0/command/add_library.html
>
> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
> alternate default in the referenced proposal.
>
> So, can anyone explain in the context of SWIG/C++/Python, why I would
> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
> be the practical impact on my wrapper, how it is built, its
> dependencies, etc.
>
> Thanks for any help,
>
> Rob
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171209/7b006d1b/attachment.html>

From calebwherry at gmail.com  Sat Dec  9 14:08:30 2017
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Sat, 09 Dec 2017 19:08:30 +0000
Subject: [CMake] SWIG_ADD_LIBRARY Documentation?
In-Reply-To: <CAEppYpE4oSMVK=kOS8qzk3kim60gErbypHMG-EqV-QGMi9cptw@mail.gmail.com>
References: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>
 <CAJxY6Xq4PdX3CMVjUoXWQNqQARNzRR=NW2WWW0KCFEdHXMQR+A@mail.gmail.com>
 <CAEppYpE4oSMVK=kOS8qzk3kim60gErbypHMG-EqV-QGMi9cptw@mail.gmail.com>
Message-ID: <CAJxY6XqxyXoUhm1EQ3Dgr0Hh_+gVMFisg76Ob+2wME2CgVKyjg@mail.gmail.com>

(Adding the CMake list back so others can reference it)

FYI: I only use the CMake SWIG macros for Java wrappers so my reference is
for that.

With Java, the Java wrapper SWIG creates does a load library on the library
created from the swig_add_library_call. So at the end of the day, it
doesn?t matter if it?s a shared or static library, the Java 8 JNI can load
it. I have no idea how python deals with the library created from this
call. But if it deals with loading the lib the same as Java, then it
doesn?t matter.

For our Java wrappers, I always compile shared libs. And as for mac, SWIG
has a special convention and names shared libs ?name.jnilib?, not the
standard ?name.dylib?.

>From a practical standpoint (and my opinion): shared libs are generally
better since they (usually) have a well defined interface and only include
the code needed for the lib?s interface. A static lib potentially leaks a
lot more about your build/files/etc instead of shared libs. Shared libs are
generally smaller too.

-Caleb

On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdonald at gmail.com>
wrote:

> Ok, thanks.
>
> In the context of a SWIG wrapper, what would happen if I chose STATIC?
>
> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
> would I then have to re-build Python and statically link that binding
> in to get it all to work?
>
> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
>
> What is the practical difference of these choices?
>
> Rob
>
>
>
>
> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwherry at gmail.com>
> wrote:
> > USE_BUILD_SHARED_LIB literally means use whatever is set by
> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either
> > building a static or shared lib since the user can control what they
> > want/need. You don?t have to specify the type of lib to build when
> calling
> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise
> static.
> >
> > Otherwise you can specify the TYPE and the user can?t override it, they
> > always get the type of lib you set.
> >
> > -Caleb
> >
> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <rob.a.mcdonald at gmail.com>
> > wrote:
> >>
> >> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
> >> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
> >> target.  From the documentation, the options are this:
> >>
> >> https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
> >>
> >> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
> >>
> >> However, I can find no documentation of what these options mean and
> >> why someone would choose one over the other.
> >>
> >> I found some developer comments in KitWare's bug tracker proposing a
> >> change of the default, but it looks like they left it as 'MODULE'.
> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
> >>
> >> However, even which TYPE value is default appears undocumented.
> >>
> >> If we want to generalize from ADD_LIBRARY, we can get an idea of what
> >> some of the options generally mean:
> >> https://cmake.org/cmake/help/v3.0/command/add_library.html
> >>
> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
> >> alternate default in the referenced proposal.
> >>
> >> So, can anyone explain in the context of SWIG/C++/Python, why I would
> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
> >> be the practical impact on my wrapper, how it is built, its
> >> dependencies, etc.
> >>
> >> Thanks for any help,
> >>
> >> Rob
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> >> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For more
> >> information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/cmake
> >
> > --
> > Sent from my iPhone 4s
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171209/660e3e32/attachment.html>

From rob.a.mcdonald at gmail.com  Sat Dec  9 14:26:15 2017
From: rob.a.mcdonald at gmail.com (Rob McDonald)
Date: Sat, 9 Dec 2017 11:26:15 -0800
Subject: [CMake] SWIG_ADD_LIBRARY Documentation?
In-Reply-To: <CAJxY6XqxyXoUhm1EQ3Dgr0Hh_+gVMFisg76Ob+2wME2CgVKyjg@mail.gmail.com>
References: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>
 <CAJxY6Xq4PdX3CMVjUoXWQNqQARNzRR=NW2WWW0KCFEdHXMQR+A@mail.gmail.com>
 <CAEppYpE4oSMVK=kOS8qzk3kim60gErbypHMG-EqV-QGMi9cptw@mail.gmail.com>
 <CAJxY6XqxyXoUhm1EQ3Dgr0Hh_+gVMFisg76Ob+2wME2CgVKyjg@mail.gmail.com>
Message-ID: <CAEppYpGia73vv7wdvsj5sbGXvNWFO9fPVr2yju_k8ZdeqqAxmQ@mail.gmail.com>

Thanks much for your patient and detailed answers -- and sorry for
dropping the mailing list.

It seems very foreign to me to load a static library at runtime -- oh well.

How is 'MODULE' different from 'SHARED' ?

Rob


On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry <calebwherry at gmail.com> wrote:
> (Adding the CMake list back so others can reference it)
>
> FYI: I only use the CMake SWIG macros for Java wrappers so my reference is
> for that.
>
> With Java, the Java wrapper SWIG creates does a load library on the library
> created from the swig_add_library_call. So at the end of the day, it doesn?t
> matter if it?s a shared or static library, the Java 8 JNI can load it. I
> have no idea how python deals with the library created from this call. But
> if it deals with loading the lib the same as Java, then it doesn?t matter.
>
> For our Java wrappers, I always compile shared libs. And as for mac, SWIG
> has a special convention and names shared libs ?name.jnilib?, not the
> standard ?name.dylib?.
>
> From a practical standpoint (and my opinion): shared libs are generally
> better since they (usually) have a well defined interface and only include
> the code needed for the lib?s interface. A static lib potentially leaks a
> lot more about your build/files/etc instead of shared libs. Shared libs are
> generally smaller too.
>
> -Caleb
>
> On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdonald at gmail.com>
> wrote:
>>
>> Ok, thanks.
>>
>> In the context of a SWIG wrapper, what would happen if I chose STATIC?
>>
>> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
>> would I then have to re-build Python and statically link that binding
>> in to get it all to work?
>>
>> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
>>
>> What is the practical difference of these choices?
>>
>> Rob
>>
>>
>>
>>
>> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwherry at gmail.com>
>> wrote:
>> > USE_BUILD_SHARED_LIB literally means use whatever is set by
>> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either
>> > building a static or shared lib since the user can control what they
>> > want/need. You don?t have to specify the type of lib to build when
>> > calling
>> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise
>> > static.
>> >
>> > Otherwise you can specify the TYPE and the user can?t override it, they
>> > always get the type of lib you set.
>> >
>> > -Caleb
>> >
>> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <rob.a.mcdonald at gmail.com>
>> > wrote:
>> >>
>> >> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
>> >> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
>> >> target.  From the documentation, the options are this:
>> >>
>> >> https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
>> >>
>> >> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
>> >>
>> >> However, I can find no documentation of what these options mean and
>> >> why someone would choose one over the other.
>> >>
>> >> I found some developer comments in KitWare's bug tracker proposing a
>> >> change of the default, but it looks like they left it as 'MODULE'.
>> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
>> >>
>> >> However, even which TYPE value is default appears undocumented.
>> >>
>> >> If we want to generalize from ADD_LIBRARY, we can get an idea of what
>> >> some of the options generally mean:
>> >> https://cmake.org/cmake/help/v3.0/command/add_library.html
>> >>
>> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
>> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
>> >> alternate default in the referenced proposal.
>> >>
>> >> So, can anyone explain in the context of SWIG/C++/Python, why I would
>> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
>> >> be the practical impact on my wrapper, how it is built, its
>> >> dependencies, etc.
>> >>
>> >> Thanks for any help,
>> >>
>> >> Rob
>> >> --
>> >>
>> >> Powered by www.kitware.com
>> >>
>> >> Please keep messages on-topic and check the CMake FAQ at:
>> >> http://www.cmake.org/Wiki/CMake_FAQ
>> >>
>> >> Kitware offers various services to support the CMake community. For
>> >> more
>> >> information on each offering, please visit:
>> >>
>> >> CMake Support: http://cmake.org/cmake/help/support.html
>> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >>
>> >> Visit other Kitware open-source projects at
>> >> http://www.kitware.com/opensource/opensource.html
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://public.kitware.com/mailman/listinfo/cmake
>> >
>> > --
>> > Sent from my iPhone 4s
>
> --
> Sent from my iPhone 4s

From calebwherry at gmail.com  Sat Dec  9 14:46:48 2017
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Sat, 09 Dec 2017 19:46:48 +0000
Subject: [CMake] SWIG_ADD_LIBRARY Documentation?
In-Reply-To: <CAEppYpGia73vv7wdvsj5sbGXvNWFO9fPVr2yju_k8ZdeqqAxmQ@mail.gmail.com>
References: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>
 <CAJxY6Xq4PdX3CMVjUoXWQNqQARNzRR=NW2WWW0KCFEdHXMQR+A@mail.gmail.com>
 <CAEppYpE4oSMVK=kOS8qzk3kim60gErbypHMG-EqV-QGMi9cptw@mail.gmail.com>
 <CAJxY6XqxyXoUhm1EQ3Dgr0Hh_+gVMFisg76Ob+2wME2CgVKyjg@mail.gmail.com>
 <CAEppYpGia73vv7wdvsj5sbGXvNWFO9fPVr2yju_k8ZdeqqAxmQ@mail.gmail.com>
Message-ID: <CAJxY6XpEKC+e_3DpoB3GBdvSrM2WLCkRsCPtVUnbmDtguBuZQA@mail.gmail.com>

I think you intuition is spot on here, I also think loading a static lib at
runtime is strange. That is why I always build the SWIG libs as shared.

To be honest, I don?t even know why static is an option. I?m sure there is
some case or reason but I wouldn?t ever build it as a static lib.

As for MODULE vs SHARED, here is a good answer:
https://stackoverflow.com/a/4968940. As the comments point out, it isn?t
obvious or documented what platforms this is actually for. On windows, you
get the same dll when you specify either.

If all the SWIG wrappers load the libraries dynamically (which glancing at
the examples it looks like they do), MODULE is more fitting. However since
I can?t find much on what platforms actually support this I don?t see the
point in using it over SHARED.

-Caleb

On Sat, Dec 9, 2017 at 2:26 PM Rob McDonald <rob.a.mcdonald at gmail.com>
wrote:

> Thanks much for your patient and detailed answers -- and sorry for
> dropping the mailing list.
>
> It seems very foreign to me to load a static library at runtime -- oh well.
>
> How is 'MODULE' different from 'SHARED' ?
>
> Rob
>
>
> On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry <calebwherry at gmail.com>
> wrote:
> > (Adding the CMake list back so others can reference it)
> >
> > FYI: I only use the CMake SWIG macros for Java wrappers so my reference
> is
> > for that.
> >
> > With Java, the Java wrapper SWIG creates does a load library on the
> library
> > created from the swig_add_library_call. So at the end of the day, it
> doesn?t
> > matter if it?s a shared or static library, the Java 8 JNI can load it. I
> > have no idea how python deals with the library created from this call.
> But
> > if it deals with loading the lib the same as Java, then it doesn?t
> matter.
> >
> > For our Java wrappers, I always compile shared libs. And as for mac, SWIG
> > has a special convention and names shared libs ?name.jnilib?, not the
> > standard ?name.dylib?.
> >
> > From a practical standpoint (and my opinion): shared libs are generally
> > better since they (usually) have a well defined interface and only
> include
> > the code needed for the lib?s interface. A static lib potentially leaks a
> > lot more about your build/files/etc instead of shared libs. Shared libs
> are
> > generally smaller too.
> >
> > -Caleb
> >
> > On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdonald at gmail.com>
> > wrote:
> >>
> >> Ok, thanks.
> >>
> >> In the context of a SWIG wrapper, what would happen if I chose STATIC?
> >>
> >> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
> >> would I then have to re-build Python and statically link that binding
> >> in to get it all to work?
> >>
> >> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
> >>
> >> What is the practical difference of these choices?
> >>
> >> Rob
> >>
> >>
> >>
> >>
> >> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwherry at gmail.com>
> >> wrote:
> >> > USE_BUILD_SHARED_LIB literally means use whatever is set by
> >> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either
> >> > building a static or shared lib since the user can control what they
> >> > want/need. You don?t have to specify the type of lib to build when
> >> > calling
> >> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise
> >> > static.
> >> >
> >> > Otherwise you can specify the TYPE and the user can?t override it,
> they
> >> > always get the type of lib you set.
> >> >
> >> > -Caleb
> >> >
> >> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <
> rob.a.mcdonald at gmail.com>
> >> > wrote:
> >> >>
> >> >> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
> >> >> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
> >> >> target.  From the documentation, the options are this:
> >> >>
> >> >> https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
> >> >>
> >> >> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
> >> >>
> >> >> However, I can find no documentation of what these options mean and
> >> >> why someone would choose one over the other.
> >> >>
> >> >> I found some developer comments in KitWare's bug tracker proposing a
> >> >> change of the default, but it looks like they left it as 'MODULE'.
> >> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
> >> >>
> >> >> However, even which TYPE value is default appears undocumented.
> >> >>
> >> >> If we want to generalize from ADD_LIBRARY, we can get an idea of what
> >> >> some of the options generally mean:
> >> >> https://cmake.org/cmake/help/v3.0/command/add_library.html
> >> >>
> >> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
> >> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
> >> >> alternate default in the referenced proposal.
> >> >>
> >> >> So, can anyone explain in the context of SWIG/C++/Python, why I would
> >> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
> >> >> be the practical impact on my wrapper, how it is built, its
> >> >> dependencies, etc.
> >> >>
> >> >> Thanks for any help,
> >> >>
> >> >> Rob
> >> >> --
> >> >>
> >> >> Powered by www.kitware.com
> >> >>
> >> >> Please keep messages on-topic and check the CMake FAQ at:
> >> >> http://www.cmake.org/Wiki/CMake_FAQ
> >> >>
> >> >> Kitware offers various services to support the CMake community. For
> >> >> more
> >> >> information on each offering, please visit:
> >> >>
> >> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >> >>
> >> >> Visit other Kitware open-source projects at
> >> >> http://www.kitware.com/opensource/opensource.html
> >> >>
> >> >> Follow this link to subscribe/unsubscribe:
> >> >> http://public.kitware.com/mailman/listinfo/cmake
> >> >
> >> > --
> >> > Sent from my iPhone 4s
> >
> > --
> > Sent from my iPhone 4s
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171209/701cfc26/attachment.html>

From rob.a.mcdonald at gmail.com  Sat Dec  9 17:01:48 2017
From: rob.a.mcdonald at gmail.com (Rob McDonald)
Date: Sat, 9 Dec 2017 14:01:48 -0800
Subject: [CMake] SWIG_ADD_LIBRARY Documentation?
In-Reply-To: <CAJxY6XpEKC+e_3DpoB3GBdvSrM2WLCkRsCPtVUnbmDtguBuZQA@mail.gmail.com>
References: <CAEppYpF0fptdPpZc7mkgvzxzBZ+LbF0SRpn_Ybvp4y3ShkGt9w@mail.gmail.com>
 <CAJxY6Xq4PdX3CMVjUoXWQNqQARNzRR=NW2WWW0KCFEdHXMQR+A@mail.gmail.com>
 <CAEppYpE4oSMVK=kOS8qzk3kim60gErbypHMG-EqV-QGMi9cptw@mail.gmail.com>
 <CAJxY6XqxyXoUhm1EQ3Dgr0Hh_+gVMFisg76Ob+2wME2CgVKyjg@mail.gmail.com>
 <CAEppYpGia73vv7wdvsj5sbGXvNWFO9fPVr2yju_k8ZdeqqAxmQ@mail.gmail.com>
 <CAJxY6XpEKC+e_3DpoB3GBdvSrM2WLCkRsCPtVUnbmDtguBuZQA@mail.gmail.com>
Message-ID: <CAEppYpGEmrXZ=Ewo9uUPf3JvUZX2ENk6V9sC9iyGT71gK9wzOQ@mail.gmail.com>

Wow.  That is rather subtle/esoteric.  Thanks for chasing that down.

It makes me wonder what use case / platform drove them to even support
the other options -- and to deprecate working functionality.

Looks like I'll stick with MODULE.

Best,

Rob

On Sat, Dec 9, 2017 at 11:46 AM, J. Caleb Wherry <calebwherry at gmail.com> wrote:
> I think you intuition is spot on here, I also think loading a static lib at
> runtime is strange. That is why I always build the SWIG libs as shared.
>
> To be honest, I don?t even know why static is an option. I?m sure there is
> some case or reason but I wouldn?t ever build it as a static lib.
>
> As for MODULE vs SHARED, here is a good answer:
> https://stackoverflow.com/a/4968940. As the comments point out, it isn?t
> obvious or documented what platforms this is actually for. On windows, you
> get the same dll when you specify either.
>
> If all the SWIG wrappers load the libraries dynamically (which glancing at
> the examples it looks like they do), MODULE is more fitting. However since I
> can?t find much on what platforms actually support this I don?t see the
> point in using it over SHARED.
>
> -Caleb
>
> On Sat, Dec 9, 2017 at 2:26 PM Rob McDonald <rob.a.mcdonald at gmail.com>
> wrote:
>>
>> Thanks much for your patient and detailed answers -- and sorry for
>> dropping the mailing list.
>>
>> It seems very foreign to me to load a static library at runtime -- oh
>> well.
>>
>> How is 'MODULE' different from 'SHARED' ?
>>
>> Rob
>>
>>
>> On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry <calebwherry at gmail.com>
>> wrote:
>> > (Adding the CMake list back so others can reference it)
>> >
>> > FYI: I only use the CMake SWIG macros for Java wrappers so my reference
>> > is
>> > for that.
>> >
>> > With Java, the Java wrapper SWIG creates does a load library on the
>> > library
>> > created from the swig_add_library_call. So at the end of the day, it
>> > doesn?t
>> > matter if it?s a shared or static library, the Java 8 JNI can load it. I
>> > have no idea how python deals with the library created from this call.
>> > But
>> > if it deals with loading the lib the same as Java, then it doesn?t
>> > matter.
>> >
>> > For our Java wrappers, I always compile shared libs. And as for mac,
>> > SWIG
>> > has a special convention and names shared libs ?name.jnilib?, not the
>> > standard ?name.dylib?.
>> >
>> > From a practical standpoint (and my opinion): shared libs are generally
>> > better since they (usually) have a well defined interface and only
>> > include
>> > the code needed for the lib?s interface. A static lib potentially leaks
>> > a
>> > lot more about your build/files/etc instead of shared libs. Shared libs
>> > are
>> > generally smaller too.
>> >
>> > -Caleb
>> >
>> > On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdonald at gmail.com>
>> > wrote:
>> >>
>> >> Ok, thanks.
>> >>
>> >> In the context of a SWIG wrapper, what would happen if I chose STATIC?
>> >>
>> >> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
>> >> would I then have to re-build Python and statically link that binding
>> >> in to get it all to work?
>> >>
>> >> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
>> >>
>> >> What is the practical difference of these choices?
>> >>
>> >> Rob
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwherry at gmail.com>
>> >> wrote:
>> >> > USE_BUILD_SHARED_LIB literally means use whatever is set by
>> >> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either
>> >> > building a static or shared lib since the user can control what they
>> >> > want/need. You don?t have to specify the type of lib to build when
>> >> > calling
>> >> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise
>> >> > static.
>> >> >
>> >> > Otherwise you can specify the TYPE and the user can?t override it,
>> >> > they
>> >> > always get the type of lib you set.
>> >> >
>> >> > -Caleb
>> >> >
>> >> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald
>> >> > <rob.a.mcdonald at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
>> >> >> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for
>> >> >> the
>> >> >> target.  From the documentation, the options are this:
>> >> >>
>> >> >> https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
>> >> >>
>> >> >> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
>> >> >>
>> >> >> However, I can find no documentation of what these options mean and
>> >> >> why someone would choose one over the other.
>> >> >>
>> >> >> I found some developer comments in KitWare's bug tracker proposing a
>> >> >> change of the default, but it looks like they left it as 'MODULE'.
>> >> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
>> >> >>
>> >> >> However, even which TYPE value is default appears undocumented.
>> >> >>
>> >> >> If we want to generalize from ADD_LIBRARY, we can get an idea of
>> >> >> what
>> >> >> some of the options generally mean:
>> >> >> https://cmake.org/cmake/help/v3.0/command/add_library.html
>> >> >>
>> >> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which
>> >> >> appears
>> >> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
>> >> >> alternate default in the referenced proposal.
>> >> >>
>> >> >> So, can anyone explain in the context of SWIG/C++/Python, why I
>> >> >> would
>> >> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
>> >> >> be the practical impact on my wrapper, how it is built, its
>> >> >> dependencies, etc.
>> >> >>
>> >> >> Thanks for any help,
>> >> >>
>> >> >> Rob
>> >> >> --
>> >> >>
>> >> >> Powered by www.kitware.com
>> >> >>
>> >> >> Please keep messages on-topic and check the CMake FAQ at:
>> >> >> http://www.cmake.org/Wiki/CMake_FAQ
>> >> >>
>> >> >> Kitware offers various services to support the CMake community. For
>> >> >> more
>> >> >> information on each offering, please visit:
>> >> >>
>> >> >> CMake Support: http://cmake.org/cmake/help/support.html
>> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >> >>
>> >> >> Visit other Kitware open-source projects at
>> >> >> http://www.kitware.com/opensource/opensource.html
>> >> >>
>> >> >> Follow this link to subscribe/unsubscribe:
>> >> >> http://public.kitware.com/mailman/listinfo/cmake
>> >> >
>> >> > --
>> >> > Sent from my iPhone 4s
>> >
>> > --
>> > Sent from my iPhone 4s
>
> --
> Sent from my iPhone 4s

From espakm at gmail.com  Sun Dec 10 09:04:50 2017
From: espakm at gmail.com (Miklos Espak)
Date: Sun, 10 Dec 2017 14:04:50 +0000
Subject: [CMake] fixup_bundle removes runpath from qt shared libs?
Message-ID: <CAOVq=oO3-8Z8fU=CVKPmcWdaiR9rxD3=VGrF1C8uL4XsQydnng@mail.gmail.com>

Hi,

I'd like to package a simple application on linux. One main executable, one
shared lib, a few Qt shared libs and the xcb platform plugin.

I could package the app, but I can launch the it only if I set the
LD_LIBRARY_PATH manually, or with a wrapper script that does that.
Moreover, all the dependent libraries are copied into the bin folder of the
package, the plugin is under bin/plugins/platforms that I find a bit messy.

>From what I've learned, setting the RPATH should resolve the first issue.
So, I set it to "$ORIGIN/", as everything is in 'bin'. However, the
application still does not start without setting LD_LIBRARY_PATH manually,
the xcb plugin cannot be loaded.

What I see with readelf:

1. The RPATH is set on the main executable.
2. The RPATH is not set on my shared lib.
3. The xcb plugin has a runpath set to '$ORIGIN/../../lib'. This is the
original value from the qt installation, fixup_bundle did not touch it.
4. The other qt shared libs do not have either rpath or runpath, although
they *did* have runpath in the Qt install directory from where they had
been copied over.

Is this what should happen? 2. and 4. looks wrong to me. 3. is good, but it
would be even better if I could instruct the fixup_bundle function to copy
the libraries to the lib folder, not the bin, like with the install command.

Is there any way to get this work?

Thanks for any hints.

Cheers,
Miklos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171210/33169c78/attachment-0001.html>

From hashemi at brandeis.edu  Sun Dec 10 09:18:18 2017
From: hashemi at brandeis.edu (Kevan Hashemi)
Date: Sun, 10 Dec 2017 09:18:18 -0500
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
 <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
 <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>
Message-ID: <b30aa24d-9747-3f41-da87-bd42456c8843@brandeis.edu>

Dear Alan,

> If you need/prefer Unix tools provided by MSYS to build your software,
> another possible generator you should look at is "MSYS Makefiles".

Thank you for this suggestion.

The CMake configuration and generation of OpenCV completes without errors using "MinGW Makefiles". I 
get one warning:

CMake Warning at cmake/OpenCVPackaging.cmake:23 (message):
CPACK_PACKAGE_VERSION does not match version provided by version.hpp header!

I assume that's a minor OpenCV-related error. When I "make", however, I enter some alternate shell 
program with a Microsoft copyright at the top. I suspect this is because I have sh.exe in my MSYS 
path, having seen this mentioned along the way, but if I remove sh.exe from the MSYS path, MSYS 
won't even execute "ls", so I'm not sure how to fix that problem, nor do I understand why it is a 
problem.

When I use "MSYS Makile", on the other hand, the OpenCV configuration and generation completes 
without warnings. When I "make", off it goes, compiling. After editing MinGW's commctrl.h file to 
solve an error related to OpenCV, the make completes and I have OpenCV built completely, which is 
really cool. I looked through the Makefile and it is awesome.

I'm curious as to why the "make" for the MinGW generator does not work. But I have a working build 
procedure, so I'm all set.

Yours, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

From r030t1 at gmail.com  Sun Dec 10 16:15:06 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Sun, 10 Dec 2017 15:15:06 -0600
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <BY2PR02MB21494175631DF092D6285D67D1300@BY2PR02MB2149.namprd02.prod.outlook.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
 <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYjf-+kU67G36pRqzLTfsNDADBCxyKANE9ofchW6-YQFDg@mail.gmail.com>
 <BY2PR02MB21494175631DF092D6285D67D1300@BY2PR02MB2149.namprd02.prod.outlook.com>
Message-ID: <CAAD4mYjNdxke11hRmwz=6eq=Z4rMrzTQBbKfBfwd2iiBd1dQNw@mail.gmail.com>

On Fri, Dec 8, 2017 at 3:44 PM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> Thank you for your prompt response. I found downloading 7zip the easier
> route to get the files into a .tar format which would enable them to be sent
> to you. One question which I did not address which you asked is where I
> accesses the Geant4 and ROOT. I downloaded both CERN website and installed
> them on a remote Unix cluster which I have access to. I followed the
> prescribed installation process which is available on the CERN website.
> Although, I have Genat4 complied for Multi-threading I do not use the
> feature yet because my application is still undergoing many modifications. I
> will send the previous email I sent when the initial file got bounced by
> your email server. Cheers.
>

Did you download binaries? If you built the packages from source, how
did you build it? Which options are enabled? Which OS are you using,
and what is the version of your compiler?

I really do need to know all of these things. Look at the type of
information requested in the bug reports below. Further, the people I
know that use ROOT/Geant4 are often forced to target a specific set of
dependencies with specific options enabled simply because ROOT/Geant4
and programs which link against them are very fragile. ROOT is not
"properly" packaged for most distributions, so I'm going to need to
compile it myself, and I need to make sure it matches what you have.

I found some discussions about your issue, which you have likely found:
1) https://github.com/JuliaLang/julia/issues/12644
2) https://root-forum.cern.ch/t/tfile-llvm-symbols-exposed/17816
3) https://github.com/ALLPix/allpix/issues/14
4) https://root-forum.cern.ch/t/llvm-symbols-are-exposed-to-cling-problem/20889/5
6) https://bugs.freedesktop.org/show_bug.cgi?id=93103

It's starting to sound like it will be a good idea to get the
attention of the ROOT developers, and they will want the same
information I am asking you for. Sadly this might leave you waiting.

Something you might want to do on your own (or you can send it to the
list) is to look at the Makefile generated by CMake, and check to make
sure that Cling is not linked in. If it is this is likely an issue
with FindROOT.cmake. If it's not, you can try using a Makefile.

Cheers,
     R0b0t1

From bill.hoffman at kitware.com  Sun Dec 10 17:39:52 2017
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Sun, 10 Dec 2017 17:39:52 -0500
Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015
In-Reply-To: <ebab065d-4458-e695-b245-3d95e160a2fd@txcorp.com>
References: <f47e7952-fd73-a2c5-bd5d-c1306df621f5@txcorp.com>
 <ebab065d-4458-e695-b245-3d95e160a2fd@txcorp.com>
Message-ID: <73f20f77-773c-39bb-97c3-d391adb4206a@kitware.com>

Thanks for sending the files.  I think I might have found something. 
The FortranCInterface.exe is not linking because of mismatched linker 
commands.  Here are the errors:

Did you change any of the default compiler/linker flags?  It looks like 
it is mixing run time libraries somehow.


[100%] Linking Fortran executable FortranCInterface.exe

LINK: command "xilink /nologo 
@CMakeFiles\FortranCInterface.dir\objects1.rsp 
/out:FortranCInterface.exe /implib:FortranCInterface.lib 
/pdb:C:\winsame\cary\usimall\builds\ulixes\ser\CMakeFiles\FortranCInterface\FortranCInterface.pdb 
/version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console symbols.lib 
myfort.lib user32.lib /MANIFEST 
/MANIFESTFILE:FortranCInterface.exe.manifest" failed (exit code 1169) 
with the following output:
xilink: executing 'link'

LIBCMT.lib(winapisupp.obj) : error LNK2005: 
__crtSetUnhandledExceptionFilter already defined in MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(crtheap.obj) : error LNK2005: _calloc_crt already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(crt0dat.obj) : error LNK2005: _amsg_exit already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(crt0dat.obj) : error LNK2005: _cexit already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(crt0dat.obj) : error LNK2005: _exit already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(crt0dat.obj) : error LNK2005: _initterm_e already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(crt0dat.obj) : error LNK2005: exit already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(mlock.obj) : error LNK2005: _lock already defined in 
MSVCRT.lib(MSVCR120.dll)

LIBCMT.lib(mlock.obj) : error LNK2005: _unlock already defined in 
MSVCRT.lib(MSVCR120.dll)




-- 
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoffman at kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573

From Odera_Dim at student.uml.edu  Sun Dec 10 19:37:10 2017
From: Odera_Dim at student.uml.edu (Dim, Odera U)
Date: Mon, 11 Dec 2017 00:37:10 +0000
Subject: [CMake] Integrating ROOT into Geant4 application
In-Reply-To: <CAAD4mYjNdxke11hRmwz=6eq=Z4rMrzTQBbKfBfwd2iiBd1dQNw@mail.gmail.com>
References: <BY2PR02MB2149BEC823ED5BF17243D437D1330@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYj-UCU3ZHe9DVpToWgJfm24E8GjC9VgBDkVTauvz=-JTw@mail.gmail.com>
 <276F3202-4CA5-4CA0-9A32-40CA3571398A@student.uml.edu>
 <CAAD4mYiBCVfhj_ZnHWEezj=x30LCEr+8aHW6-XXS4qgiHFqMUw@mail.gmail.com>
 <BY2PR02MB214978A7E44984E33770073AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <BY2PR02MB2149DCF22847674D447C4E6AD1300@BY2PR02MB2149.namprd02.prod.outlook.com>
 <CAAD4mYjf-+kU67G36pRqzLTfsNDADBCxyKANE9ofchW6-YQFDg@mail.gmail.com>
 <BY2PR02MB21494175631DF092D6285D67D1300@BY2PR02MB2149.namprd02.prod.outlook.com>,
 <CAAD4mYjNdxke11hRmwz=6eq=Z4rMrzTQBbKfBfwd2iiBd1dQNw@mail.gmail.com>
Message-ID: <BY2PR02MB21496D2B9A79041483B14829D1360@BY2PR02MB2149.namprd02.prod.outlook.com>

Hi,


Thank you for your response. I obtained source files not binaries. I will attempt to provide the information you require. First of all the operating system i'm using is:

Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.4 (Santiago)
Release:        6.4
Codename:       Santiago

My compiler version:


gcc version 5.1.0 (GCC)


What build options were selected: I used the default options meaning I built using just the command


cmake --build [no options selected]


I have also included the CMakeCache files for geant4 and ROOT so you can see what options might have constituted the default build on  my system.


Check for Cling:


I have checked the MakeFile generated during the build of my application to see if there is any reference to Cling being linked in and I cant see any. I have Included the MakeFiles ao you may confirm as well as I am definitely no expert at this.


Also, I have posted this question to the ROOT forum and its been there for 2 weeks. I ran into this same issue 3 months ago and posted it on the forum and got no response back then but had to use an alternative method back then which did not require ROOT. This time around I do not have a work around besides trying to make it work some how.


Thanks once again for your efforts. Cheers.


Odera Dim




________________________________
From: R0b0t1 <r030t1 at gmail.com>
Sent: Sunday, December 10, 2017 4:15:06 PM
To: Dim, Odera U
Cc: cmake at cmake.org
Subject: Re: [CMake] Integrating ROOT into Geant4 application

On Fri, Dec 8, 2017 at 3:44 PM, Dim, Odera U <Odera_Dim at student.uml.edu> wrote:
> Hi,
>
>
> Thank you for your prompt response. I found downloading 7zip the easier
> route to get the files into a .tar format which would enable them to be sent
> to you. One question which I did not address which you asked is where I
> accesses the Geant4 and ROOT. I downloaded both CERN website and installed
> them on a remote Unix cluster which I have access to. I followed the
> prescribed installation process which is available on the CERN website.
> Although, I have Genat4 complied for Multi-threading I do not use the
> feature yet because my application is still undergoing many modifications. I
> will send the previous email I sent when the initial file got bounced by
> your email server. Cheers.
>

Did you download binaries? If you built the packages from source, how
did you build it? Which options are enabled? Which OS are you using,
and what is the version of your compiler?

I really do need to know all of these things. Look at the type of
information requested in the bug reports below. Further, the people I
know that use ROOT/Geant4 are often forced to target a specific set of
dependencies with specific options enabled simply because ROOT/Geant4
and programs which link against them are very fragile. ROOT is not
"properly" packaged for most distributions, so I'm going to need to
compile it myself, and I need to make sure it matches what you have.

I found some discussions about your issue, which you have likely found:
1) https://github.com/JuliaLang/julia/issues/12644
2) https://root-forum.cern.ch/t/tfile-llvm-symbols-exposed/17816
3) https://github.com/ALLPix/allpix/issues/14
4) https://root-forum.cern.ch/t/llvm-symbols-are-exposed-to-cling-problem/20889/5
6) https://bugs.freedesktop.org/show_bug.cgi?id=93103

It's starting to sound like it will be a good idea to get the
attention of the ROOT developers, and they will want the same
information I am asking you for. Sadly this might leave you waiting.

Something you might want to do on your own (or you can send it to the
list) is to look at the Makefile generated by CMake, and check to make
sure that Cling is not linked in. If it is this is likely an issue
with FindROOT.cmake. If it's not, you can try using a Makefile.

Cheers,
     R0b0t1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/95e148f1/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeCache (Geant4).txt
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/95e148f1/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeCache (ROOT).txt
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/95e148f1/attachment-0003.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 24555 bytes
Desc: Makefile
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/95e148f1/attachment-0001.obj>

From eric.noulard at gmail.com  Mon Dec 11 03:20:10 2017
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 11 Dec 2017 09:20:10 +0100
Subject: [CMake] INTERFACE library and path to source.
In-Reply-To: <aa29a7d8-c3fa-2212-4278-79e136793c06@gmail.com>
References: <CAPASGLonEaAaCpkhXAkjFRfRByRN5PuzFC8Aa_cCZXwUo9bD3w@mail.gmail.com>
 <aa29a7d8-c3fa-2212-4278-79e136793c06@gmail.com>
Message-ID: <CAPASGLp6THy1sviyh3XS25p_Km7=NMjpfbxVfkPqLepV4gW0Zg@mail.gmail.com>

2017-12-09 1:37 GMT+01:00 Oleksii Vilchanskyi <oleksii.vilchanskyi at gmail.com
>:

> Hello Eric,
>
> > Why should I do that?
> > Is this the expected behavior / way to create header only library?
>
> Yes, this is the expected behaviour. CMake interprets a relative path to
> the file according to the target's add_library() or add_executable()
> call directory. I will provide a minimal, reproducible example:
>

Hi Oleksii,

Thanks you for the minimal reproducible example.
I'm bot that sure that this is the "expected" behavior


> Listfile under `lib`:
>
> > add_library(lib INTERFACE)
> > target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
> > target_sources(lib INTERFACE "lib.h")
>

With the previous one would expect that any target linking to this
interface target
will be provided with the include directories provided in its interface.
In your case (and in mine too) this is given with **full path**


>
> Listfile under `main`:
>
> > add_executable(main "main.c")
> > target_link_libraries(main PRIVATE lib)
>
> Now, let's look at the diagnostics:
>
> > CMake Error at main/CMakeLists.txt:1 (add_executable):
> >   Cannot find source file:
> >
> >     lib.h
>
> So, the problem occurs when CMake cannot find `lib.h` relatively to
> `add_executable(main "main.c")` call. Whether it's the expected
> behaviour is debatable (I personally would prefer CMake to search
> relatively to `add_library(lib INTERFACE)`), and the documentation is
> silent on this caveat either, so there's that.
>

Yes precisely. This seems to work OK for imported targets but not for
header-only in-project lib.


>
> One way to solve this is to provide a path to `lib.h` relatively to
> `main` directory, another way is to provide a full path.
>

We (you and me) already provide
 target_include_directories
with full path.

I cannot provide the file themselves with relative path since they may be
used
from different place.

I guess I will open an issue unless someone explain me the rational behind
that behavior.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/585e44fc/attachment.html>

From irwin at beluga.phys.uvic.ca  Mon Dec 11 05:45:14 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 11 Dec 2017 02:45:14 -0800 (PST)
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <b30aa24d-9747-3f41-da87-bd42456c8843@brandeis.edu>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
 <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
 <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>
 <b30aa24d-9747-3f41-da87-bd42456c8843@brandeis.edu>
Message-ID: <alpine.DEB.2.11.1712110153080.2797@enira.zlyna.ubzr>

On 2017-12-10 09:18-0500 Kevan Hashemi wrote:

> Dear Alan,
>
>> If you need/prefer Unix tools provided by MSYS to build your software,
>> another possible generator you should look at is "MSYS Makefiles".
>
> Thank you for this suggestion.
>
> The CMake configuration and generation of OpenCV completes without errors 
> using "MinGW Makefiles". I get one warning:
>
> CMake Warning at cmake/OpenCVPackaging.cmake:23 (message):
> CPACK_PACKAGE_VERSION does not match version provided by version.hpp header!
>
> I assume that's a minor OpenCV-related error. When I "make", however, I enter 
> some alternate shell program with a Microsoft copyright at the top. I suspect 
> this is because I have sh.exe in my MSYS path, having seen this mentioned 
> along the way, but if I remove sh.exe from the MSYS path, MSYS won't even 
> execute "ls", so I'm not sure how to fix that problem, nor do I understand 
> why it is a problem.
>
> When I use "MSYS Makile", on the other hand, the OpenCV configuration and 
> generation completes without warnings. When I "make", off it goes, compiling. 
> After editing MinGW's commctrl.h file to solve an error related to OpenCV, 
> the make completes and I have OpenCV built completely, which is really cool. 
> I looked through the Makefile and it is awesome.
>
> I'm curious as to why the "make" for the MinGW generator does not work. But I 
> have a working build procedure, so I'm all set.

Hi Kevan:

Glad everything is working for you with "MSYS Makefiles".

Just to follow up on the "MinGW Makefiles" issue you ran into, it has
a test for sh.exe in the PATH, and if it finds it, it (rightly)
refuses to configure.  As far as I can tell using the "strings"
executable, mingw32-make.exe (the MinGW version of make you should use
with this generator) depends on sh.exe so I presume that means it has
different behaviour if sh.exe is in the PATH and the generator test
for "MinGW Makefiles" is designed to avoid that alternate behaviour.

So if you are further interested in the "MinGW Makefiles" generator,
you should remove all sh.exe versions from your PATH (including sh.exe
provided by raw Windows), get into a CMD environment, execute cmake
with the "MinGW Makefiles", and then build your software with

mingw32-make.exe

which internally uses CMD commands rather than Unix shell commands
to build software.  Note you should keep sh.exe out of your PATH not
only for the configuration stage, but also the build stage (to
avoid that presumed alternate behaviour of mingw32-make.exe in that
case).

For the Wine version of Windows I found this method of building
software was quicker than building using the "MSYS Makefiles"
generator.  I assume that is because the CMD environment is faster
than bash.exe. One complication for us is our PLplot test system
depends on bash scripts so requires bash.exe and other Unix tools to
be available.  So I tricked "MinGW Makefiles" into working fine with
our test system by putting a copy of MSYS in my path *but with sh.exe
removed*.  Thus, the build and test fundamentally depends on a CMD
environment, but most of the test commands executed in that
environment for us correspond to CMD executing bash.exe to run the
test scripts.

The above is from my own extensive but likely now dated experience
with MinGW/MSYS/Wine. My understanding from other's experience is the
MinGW-w64/MSYS2 platform has a similar "split personality" where you
have to very carefully distinguish between make versions from the
"mingw" versus "msys" repositories (with the former using CMD commands
to build and the latter using Unix shell commands to build) when using
the "MinGW Makefiles" generator versus the "MSYS Makefiles" generator.

I hope the above discussion allows you to have success with "MinGW
Makefiles" so you can compare its results with the corresponding "MSYS
Makefiles" results.

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 oleksii.vilchanskyi at gmail.com  Mon Dec 11 09:12:54 2017
From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi)
Date: Mon, 11 Dec 2017 15:12:54 +0100
Subject: [CMake] INTERFACE library and path to source.
In-Reply-To: <CAPASGLp6THy1sviyh3XS25p_Km7=NMjpfbxVfkPqLepV4gW0Zg@mail.gmail.com>
References: <CAPASGLonEaAaCpkhXAkjFRfRByRN5PuzFC8Aa_cCZXwUo9bD3w@mail.gmail.com>
 <aa29a7d8-c3fa-2212-4278-79e136793c06@gmail.com>
 <CAPASGLp6THy1sviyh3XS25p_Km7=NMjpfbxVfkPqLepV4gW0Zg@mail.gmail.com>
Message-ID: <e31b129d-aee6-a467-1efc-0dbfb0f1e41a@gmail.com>

> I'm not that sure that this is the "expected" behavior

Yes, now it looks like a bug to me, too. Being written as it was in the
last message,
> target_sources(lib INTERFACE lib.h)
can be treated as the equivalent of
> target_sources(main PRIVATE lib.h)
(and therefore generating an error).

However,
> target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
on the command line resolves to
> -I/home/l2y/<...>/lib
and
> target_include_directories(lib INTERFACE ".")
resolves to
> -I/home/l2y/<...>/lib/.

Also, looking at `<build_dir>/main/CMakeFiles/main.dir/depend.internal`:

> main/CMakeFiles/main.dir/main.c.o
>  ../lib/lib.h
>  /home/l2y/<...>/main/main.c
So, all elements in `target_include_directories()` resolve to full
paths, as well as `target_sources()`, while `target_sources(INTERFACE)`
stay relative, which causes trouble.

On 11.12.2017 09:20, Eric Noulard wrote:
> 
> 
> 2017-12-09 1:37 GMT+01:00 Oleksii Vilchanskyi
> <oleksii.vilchanskyi at gmail.com <mailto:oleksii.vilchanskyi at gmail.com>>:
> 
>     Hello Eric,
> 
>     > Why should I do that?
>     > Is this the expected behavior / way to create header only library?
> 
>     Yes, this is the expected behaviour. CMake interprets a relative path to
>     the file according to the target's add_library() or add_executable()
>     call directory. I will provide a minimal, reproducible example:
> 
> 
> Hi Oleksii,
> 
> Thanks you for the minimal reproducible example.
> I'm bot that sure that this is the "expected" behavior
> ?
> 
>     Listfile under `lib`:
> 
>     > add_library(lib INTERFACE)
>     > target_include_directories(lib INTERFACE
>     "${CMAKE_CURRENT_SOURCE_DIR}")
>     > target_sources(lib INTERFACE "lib.h")
> 
> 
> With the previous one would expect that any target linking to this
> interface target
> will be provided with the include directories provided in its interface.
> In your case (and in mine too) this is given with **full path**
> ?
> 
> 
>     Listfile under `main`:
> 
>     > add_executable(main "main.c")
>     > target_link_libraries(main PRIVATE lib)
> 
>     Now, let's look at the diagnostics:
> 
>     > CMake Error at main/CMakeLists.txt:1 (add_executable):
>     >? ?Cannot find source file:
>     >
>     >? ? ?lib.h
> 
>     So, the problem occurs when CMake cannot find `lib.h` relatively to
>     `add_executable(main "main.c")` call. Whether it's the expected
>     behaviour is debatable (I personally would prefer CMake to search
>     relatively to `add_library(lib INTERFACE)`), and the documentation is
>     silent on this caveat either, so there's that.
> 
> 
> Yes precisely. This seems to work OK for imported targets but not for
> header-only in-project lib.
> ?
> 
> 
>     One way to solve this is to provide a path to `lib.h` relatively to
>     `main` directory, another way is to provide a full path.
> 
> 
> We (you and me) already provide?
> ?target_include_directories
> with full path.
> 
> I cannot provide the file themselves with relative path since they may
> be used
> from different place.
> 
> I guess I will open an issue unless someone explain me the rational
> behind that behavior.
> 
> 
> -- 
> Eric

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/40be0201/attachment.sig>

From cary at txcorp.com  Mon Dec 11 13:07:14 2017
From: cary at txcorp.com (John Cary)
Date: Mon, 11 Dec 2017 11:07:14 -0700
Subject: [CMake] Fwd: Re: FortranCInterface not working with 3.9.0 with
 Intel 2015
In-Reply-To: <c64b9ce1-5549-e57f-97c1-6f1046e6472c@txcorp.com>
References: <c64b9ce1-5549-e57f-97c1-6f1046e6472c@txcorp.com>
Message-ID: <467ab9f8-c02e-e1d0-51d7-305b77fdc29f@txcorp.com>

Yes, we do a replacement of MD with MT as we need fully static builds.

We do this early in configuration, using

The "Dynamic Replace" method described at

https://cmake.org/Wiki/CMake_FAQ

specifically

https://cmake.org/Wiki/CMake_FAQ#Dynamic_Replace

This is possible with 3.8.2.? Is there a way
to get that behavior back?

Thx........


From Harry.Mallon at codex.online  Mon Dec 11 13:13:59 2017
From: Harry.Mallon at codex.online (Harry Mallon)
Date: Mon, 11 Dec 2017 18:13:59 +0000
Subject: [CMake] add_subdirectory and common libraries
Message-ID: <3918DBB5-3032-4FE3-940F-607EC4EF8906@contoso.com>

Hello all,

Has anyone got any good recommendations for the following setup?

?large_repo? contains code for a binary and two git submodules. One is ?library? which is added with add_subdirectory(). The other is some common library ?util_library? (something like gtest which is generally useful) which is added as a git submodule with add_subdirectory(). ?library? also needs ?util_library? which is added to its repo in the same git submodule style.

It is possible to namespace the names in an add_subdirectory call? Or something like that? Or maybe I should go back to the install and find_package() methods I used to use?

========
??? large_repo
    ??? library
    ?   ??? util_library
    ??? util_library
========


Thanks,
Harry


Harry Mallon
CODEX | Senior Software Engineer
60 Poland Street | London | England | W1F 7NT
E harry.mallon at codex.online | T +44 203 7000 989

From waldovalenzuela at yahoo.com  Mon Dec 11 14:07:55 2017
From: waldovalenzuela at yahoo.com (Waldo Valenzuela)
Date: Mon, 11 Dec 2017 20:07:55 +0100
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
Message-ID: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>

Dear All,

I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac no problem to created the standalone app, but in Ubuntu 16.04  I have several problems.

I am using CodeBlocks to compile and run the app, and from CodeBlocks when I run the app there is no problem, it work normally like in windows and mac, but after run the installation, and If I want to run the app from the installation folder (./app ) I have several problems.


the CMakeList.txt is 

FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})

SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})

MESSAGE("Project libraries: ${QTPLUGINS}")


INSTALL(CODE "
	INCLUDE(BundleUtilities)
	FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
    	     " 
	COMPONENT ${PROJECT_NAME})

First I have this:

-- fixup_bundle: fixing...
-- 132/260: fix-up not required on this platform '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
-- 133/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
-- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5?

-- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
-- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
-- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1

then when I run: ldd ./app I have:

	libQt5Concurrent.so.5 => not found
	libvtkRenderingImage-9.0.so.1 => not found
	libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found

then if I fix manually the path of the libraries like this:

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"

I can run the application from through the command line from the installation folder, but I have this message and I can not see nothing

QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
QOpenGLWidget: Failed to create context
composeAndFlush: makeCurrent() failed


I think that the FIXUP_BUNDLE is doing nothing.

Any help is welcome.

Best regards,

Waldo.

From craig.scott at crascit.com  Mon Dec 11 16:00:20 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 12 Dec 2017 08:00:20 +1100
Subject: [CMake] add_subdirectory and common libraries
In-Reply-To: <3918DBB5-3032-4FE3-940F-607EC4EF8906@contoso.com>
References: <3918DBB5-3032-4FE3-940F-607EC4EF8906@contoso.com>
Message-ID: <CA+dygYmr+OzhfJrrg5aDTKAwgLzbpvay-D25hvG7cztmj-kiPQ@mail.gmail.com>

On Tue, Dec 12, 2017 at 5:13 AM, Harry Mallon <Harry.Mallon at codex.online>
wrote:

> Hello all,
>
> Has anyone got any good recommendations for the following setup?
>
> ?large_repo? contains code for a binary and two git submodules. One is
> ?library? which is added with add_subdirectory(). The other is some common
> library ?util_library? (something like gtest which is generally useful)
> which is added as a git submodule with add_subdirectory(). ?library? also
> needs ?util_library? which is added to its repo in the same git submodule
> style.
>
> It is possible to namespace the names in an add_subdirectory call? Or
> something like that? Or maybe I should go back to the install and
> find_package() methods I used to use?
>
> ========
> ??? large_repo
>     ??? library
>     ?   ??? util_library
>     ??? util_library
> ========
>

It won't really help you right now, but this is a classic scenario that the
new FetchContent module
<https://cmake.org/cmake/help/git-master/module/FetchContent.html> would
address. It's not part of CMake 3.10 but it is on master and should be
available from CMake 3.11 when it is eventually released.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171212/56cb5677/attachment.html>

From cary at txcorp.com  Mon Dec 11 16:34:38 2017
From: cary at txcorp.com (John Cary)
Date: Mon, 11 Dec 2017 14:34:38 -0700
Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015
In-Reply-To: <467ab9f8-c02e-e1d0-51d7-305b77fdc29f@txcorp.com>
References: <467ab9f8-c02e-e1d0-51d7-305b77fdc29f@txcorp.com>
Message-ID: <229c70f0-112d-ccec-d864-3d61d3c85ecd@txcorp.com>

Thanks for your help.

Yes, we do a replacement of MD with MT as we need fully static builds.

We do this early in configuration, using

The "Dynamic Replace" method described at

https://cmake.org/Wiki/CMake_FAQ

specifically

https://cmake.org/Wiki/CMake_FAQ#Dynamic_Replace

This is possible with 3.8.2.? Is there a way
to get that behavior back?

Thx........


> Thanks for sending the files.  I think I might have found something.
> The FortranCInterface.exe is not linking because of mismatched linker
> commands.  Here are the errors:
>
> Did you change any of the default compiler/linker flags?  It looks like
> it is mixing run time libraries somehow.
>
>
> [100%] Linking Fortran executable FortranCInterface.exe
>
> LINK: command "xilink /nologo
> @CMakeFiles\FortranCInterface.dir\objects1.rsp
> /out:FortranCInterface.exe /implib:FortranCInterface.lib
> /pdb:C:\winsame\cary\usimall\builds\ulixes\ser\CMakeFiles\FortranCInterface\FortranCInterface.pdb
> /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console symbols.lib
> myfort.lib user32.lib /MANIFEST
> /MANIFESTFILE:FortranCInterface.exe.manifest" failed (exit code 1169)
> with the following output:
> xilink: executing 'link'
>
> LIBCMT.lib(winapisupp.obj) : error LNK2005:
> __crtSetUnhandledExceptionFilter already defined in MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(crtheap.obj) : error LNK2005: _calloc_crt already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(crt0dat.obj) : error LNK2005: _amsg_exit already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(crt0dat.obj) : error LNK2005: _cexit already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(crt0dat.obj) : error LNK2005: _exit already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(crt0dat.obj) : error LNK2005: _initterm_e already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(crt0dat.obj) : error LNK2005: exit already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(mlock.obj) : error LNK2005: _lock already defined in
> MSVCRT.lib(MSVCR120.dll)
>
> LIBCMT.lib(mlock.obj) : error LNK2005: _unlock already defined in
> MSVCRT.lib(MSVCR120.dll)


From eric.noulard at gmail.com  Tue Dec 12 06:10:10 2017
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 12 Dec 2017 12:10:10 +0100
Subject: [CMake] INTERFACE library and path to source.
In-Reply-To: <e31b129d-aee6-a467-1efc-0dbfb0f1e41a@gmail.com>
References: <CAPASGLonEaAaCpkhXAkjFRfRByRN5PuzFC8Aa_cCZXwUo9bD3w@mail.gmail.com>
 <aa29a7d8-c3fa-2212-4278-79e136793c06@gmail.com>
 <CAPASGLp6THy1sviyh3XS25p_Km7=NMjpfbxVfkPqLepV4gW0Zg@mail.gmail.com>
 <e31b129d-aee6-a467-1efc-0dbfb0f1e41a@gmail.com>
Message-ID: <CAPASGLqVNwPB37Ks=s4d-NuMODNto96yhpMwfHYn1BQNpRuz4A@mail.gmail.com>

I did file a bug report then:

https://gitlab.kitware.com/cmake/cmake/issues/17556

2017-12-11 15:12 GMT+01:00 Oleksii Vilchanskyi <
oleksii.vilchanskyi at gmail.com>:

> > I'm not that sure that this is the "expected" behavior
>
> Yes, now it looks like a bug to me, too. Being written as it was in the
> last message,
> > target_sources(lib INTERFACE lib.h)
> can be treated as the equivalent of
> > target_sources(main PRIVATE lib.h)
> (and therefore generating an error).
>
> However,
> > target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
> on the command line resolves to
> > -I/home/l2y/<...>/lib
> and
> > target_include_directories(lib INTERFACE ".")
> resolves to
> > -I/home/l2y/<...>/lib/.
>
> Also, looking at `<build_dir>/main/CMakeFiles/main.dir/depend.internal`:
>
> > main/CMakeFiles/main.dir/main.c.o
> >  ../lib/lib.h
> >  /home/l2y/<...>/main/main.c
> So, all elements in `target_include_directories()` resolve to full
> paths, as well as `target_sources()`, while `target_sources(INTERFACE)`
> stay relative, which causes trouble.
>
> On 11.12.2017 09:20, Eric Noulard wrote:
> >
> >
> > 2017-12-09 1:37 GMT+01:00 Oleksii Vilchanskyi
> > <oleksii.vilchanskyi at gmail.com <mailto:oleksii.vilchanskyi at gmail.com>>:
> >
> >     Hello Eric,
> >
> >     > Why should I do that?
> >     > Is this the expected behavior / way to create header only library?
> >
> >     Yes, this is the expected behaviour. CMake interprets a relative
> path to
> >     the file according to the target's add_library() or add_executable()
> >     call directory. I will provide a minimal, reproducible example:
> >
> >
> > Hi Oleksii,
> >
> > Thanks you for the minimal reproducible example.
> > I'm bot that sure that this is the "expected" behavior
> >
> >
> >     Listfile under `lib`:
> >
> >     > add_library(lib INTERFACE)
> >     > target_include_directories(lib INTERFACE
> >     "${CMAKE_CURRENT_SOURCE_DIR}")
> >     > target_sources(lib INTERFACE "lib.h")
> >
> >
> > With the previous one would expect that any target linking to this
> > interface target
> > will be provided with the include directories provided in its interface.
> > In your case (and in mine too) this is given with **full path**
> >
> >
> >
> >     Listfile under `main`:
> >
> >     > add_executable(main "main.c")
> >     > target_link_libraries(main PRIVATE lib)
> >
> >     Now, let's look at the diagnostics:
> >
> >     > CMake Error at main/CMakeLists.txt:1 (add_executable):
> >     >   Cannot find source file:
> >     >
> >     >     lib.h
> >
> >     So, the problem occurs when CMake cannot find `lib.h` relatively to
> >     `add_executable(main "main.c")` call. Whether it's the expected
> >     behaviour is debatable (I personally would prefer CMake to search
> >     relatively to `add_library(lib INTERFACE)`), and the documentation is
> >     silent on this caveat either, so there's that.
> >
> >
> > Yes precisely. This seems to work OK for imported targets but not for
> > header-only in-project lib.
> >
> >
> >
> >     One way to solve this is to provide a path to `lib.h` relatively to
> >     `main` directory, another way is to provide a full path.
> >
> >
> > We (you and me) already provide
> >  target_include_directories
> > with full path.
> >
> > I cannot provide the file themselves with relative path since they may
> > be used
> > from different place.
> >
> > I guess I will open an issue unless someone explain me the rational
> > behind that behavior.
> >
> >
> > --
> > Eric
>
> --
> Regards,
> Oleksii Vilchanskyi
> PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338
>
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171212/4cf88e31/attachment-0001.html>

From brad.king at kitware.com  Tue Dec 12 07:50:37 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 12 Dec 2017 07:50:37 -0500
Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015
In-Reply-To: <229c70f0-112d-ccec-d864-3d61d3c85ecd@txcorp.com>
References: <467ab9f8-c02e-e1d0-51d7-305b77fdc29f@txcorp.com>
 <229c70f0-112d-ccec-d864-3d61d3c85ecd@txcorp.com>
Message-ID: <df40ece9-ebc2-ab90-9217-56dd29cf4e0a@kitware.com>

On 12/11/2017 04:34 PM, John Cary wrote:
> Bill Hoffman wrote:
>> LINK: command "xilink ... /out:FortranCInterface.exe ..." failed (exit code 1169)
>> LIBCMT.lib(winapisupp.obj) : error LNK2005:
>> __crtSetUnhandledExceptionFilter already defined in MSVCRT.lib(MSVCR120.dll)
>>
>> Did you change any of the default compiler/linker flags?  It looks like
>> it is mixing run time libraries somehow.
>
> Yes, we do a replacement of MD with MT as we need fully static builds.
> 
> We do this early in configuration, using
> 
> The "Dynamic Replace" method described at
> 
> https://cmake.org/Wiki/CMake_FAQ#Dynamic_Replace
> 
> This is possible with 3.8.2.? Is there a way to get that behavior back?

This is likely due to commit v3.9.0-rc1~144^2~1:

```
FortranCInt: Pass CONFIG flags to try_compile

This change ensures that Intel Fortran's /libs: in
CMAKE_Fortran_FLAGS and Visual C++'s /MT or /MD in the
CMAKE_C_FLAGS_RELEASE do not conflict with each other.
```

With that change I'm able to reproduce the failure with
VS 2013 and Intel 2016:

```
cmake_minimum_required (VERSION 3.7)
project(Test C Fortran)
string(REPLACE "/MD" "/MT" CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}")
include(FortranCInterface)
FortranCInterface_VERIFY()
```

If the project is changing the C and C++ flags to use a static
runtime library, it should do that for Fortran too:

```
string(REPLACE "/libs:dll" "/libs:static" CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS}")
```

Adding that line fixes the problem for me.

-Brad

From saadrustam at gmail.com  Tue Dec 12 19:34:35 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Wed, 13 Dec 2017 00:34:35 +0000
Subject: [CMake] Using CMake include does not seem to work intuatively
Message-ID: <CAEM70sO1xbaD0pXmz8_U3GYCMdvJiNXPp4mDe3w2+5hLVC_2tg@mail.gmail.com>

Hi,

Let's say I have the following directory structure:
~/Repos/MyRepo/CMakeLists.txt
~/CMakeFiles/Foo.cmake
~/CMakeFiles/Bar.cmake

In the CMakeLists.txt I have the following command:

include(~/CMakeFiles/Foo.cmake)

And in Foo.cmake I have the following command:

include(Bar.cmake)

Turns out that he `include(Bar.cmake)` from `Foo.cmake` fails. This is
counter to what I would expect (e.g. how #include works in C).

Is this a bug or is this behavior expected? If it's expected, what is the
workaround? We have a lot of common cmake files which in turn include files
relative to each other and not the calling CMakeLists.txt.

Thank you,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/dc81881c/attachment.html>

From espakm at gmail.com  Tue Dec 12 21:58:30 2017
From: espakm at gmail.com (Miklos Espak)
Date: Wed, 13 Dec 2017 02:58:30 +0000
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
Message-ID: <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>

Hi,

you need to add the directory where the Qt libs have been installed (along
with your application binaries) to the LD_LIBRARY_PATH. In your case it is
'/home/waldo/Developer/install/Release/bratumia/bin/', as I see.

Also, you do *not* need to add the Qt plugin directories to the library
path. The plugins are loaded at run-time. So that they can be found, you
need to install a qt.conf file in the bin directory with the following
contents:

[Paths]
Prefix=.

You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the
library path. These libraries are searched for by default. If you did it
because your Qt installation is there, that's wrong. The fixup_bundle
function should have copied the necessary Qt libs in the install bin
folder, so you just need to add that folder to the path.

Also, make sure that the DIRS variable contains all the directories where
there are libraries to install, including dependencies.

I hope that helps.

Best regards,
Miklos



On 11 December 2017 at 19:07, Waldo Valenzuela via CMake <cmake at cmake.org>
wrote:

> Dear All,
>
> I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and
> Mac no problem to created the standalone app, but in Ubuntu 16.04  I have
> several problems.
>
> I am using CodeBlocks to compile and run the app, and from CodeBlocks when
> I run the app there is no problem, it work normally like in windows and
> mac, but after run the installation, and If I want to run the app from the
> installation folder (./app ) I have several problems.
>
>
> the CMakeList.txt is
>
> FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/
> imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
> FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/
> platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>
> SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
>
> MESSAGE("Project libraries: ${QTPLUGINS}")
>
>
> INSTALL(CODE "
>         INCLUDE(BundleUtilities)
>         FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
>              "
>         COMPONENT ${PROJECT_NAME})
>
> First I have this:
>
> -- fixup_bundle: fixing...
> -- 132/260: fix-up not required on this platform
> '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
> -- 133/260: fix-up not required on this platform '/home/waldo/Developer/
> install/Release/bratumia/bin/libQt5Core.so.5'
> -- 134/260: fix-up not required on this platform '/home/waldo/Developer/
> install/Release/bratumia/bin/libQt5Gui.so.5?
>
> -- 167/260: fix-up not required on this platform '/home/waldo/Developer/
> install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
> -- 168/260: fix-up not required on this platform '/home/waldo/Developer/
> install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
> -- 169/260: fix-up not required on this platform '/home/waldo/Developer/
> install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1
>
> then when I run: ldd ./app I have:
>
>         libQt5Concurrent.so.5 => not found
>         libvtkRenderingImage-9.0.so.1 => not found
>         libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found
>
> then if I fix manually the path of the libraries like this:
>
> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-
> linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/
> waldo/app/bin/plugins/platforms"
>
> I can run the application from through the command line from the
> installation folder, but I have this message and I can not see nothing
>
> QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor
> EGL are enabled
> QOpenGLWidget: Failed to create context
> composeAndFlush: makeCurrent() failed
>
>
> I think that the FIXUP_BUNDLE is doing nothing.
>
> Any help is welcome.
>
> Best regards,
>
> Waldo.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/374010f0/attachment.html>

From petr.kmoch at gmail.com  Wed Dec 13 03:03:23 2017
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 13 Dec 2017 09:03:23 +0100
Subject: [CMake] Using CMake include does not seem to work intuatively
In-Reply-To: <CAEM70sO1xbaD0pXmz8_U3GYCMdvJiNXPp4mDe3w2+5hLVC_2tg@mail.gmail.com>
References: <CAEM70sO1xbaD0pXmz8_U3GYCMdvJiNXPp4mDe3w2+5hLVC_2tg@mail.gmail.com>
Message-ID: <CAKohaZeNa2BtVYPO0DmJc6z-1ZSkyU2xe15QzcLPVaQ3k0RBAQ@mail.gmail.com>

Hi Saad.

I can't comment on whether the behaviour is correct or expectable, but to
get it working the way you want, you can specify the path fully:

include(${CMAKE_CURRENT_LIST_DIR}/Bar.cmake)

Petr


On 13 December 2017 at 01:34, Saad Khattak <saadrustam at gmail.com> wrote:

> Hi,
>
> Let's say I have the following directory structure:
> ~/Repos/MyRepo/CMakeLists.txt
> ~/CMakeFiles/Foo.cmake
> ~/CMakeFiles/Bar.cmake
>
> In the CMakeLists.txt I have the following command:
>
> include(~/CMakeFiles/Foo.cmake)
>
> And in Foo.cmake I have the following command:
>
> include(Bar.cmake)
>
> Turns out that he `include(Bar.cmake)` from `Foo.cmake` fails. This is
> counter to what I would expect (e.g. how #include works in C).
>
> Is this a bug or is this behavior expected? If it's expected, what is the
> workaround? We have a lot of common cmake files which in turn include files
> relative to each other and not the calling CMakeLists.txt.
>
> Thank you,
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/4d827479/attachment.html>

From mario at emmenlauer.de  Wed Dec 13 04:06:17 2017
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Wed, 13 Dec 2017 10:06:17 +0100
Subject: [CMake] absolute library path, sorry for the question
Message-ID: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>


Dear cmake users,

I have found good documentation on the cmake wiki about RPATH and
its different variables, and also on the mailing lists. But somehow
it still does not add up for me. Can you please help?

I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
amongst others. I build many standard libraries (like tiff and jpeg)
into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
them there. On newer Linux and Windows, cmake uses always the absolute
path to those libraries, and everything works fine. But on older Linux
like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
library in the correct absolute thirdparty directory, and I can confirm
this by printing the 'XXX_LIBRARIES' variable in the find script. But
later the Makefile will link with '-lxxx' instead of the full path.
This makes 'ld' use the system library instead!

I completely fail to understand at what point cmake changes XXX_LIBRARIES
from an absolute path to '-lxxx', for example for libjpeg.

I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
The only workaround I could find is to add the thirdparty directory to
LDFLAGS. Then 'ld' will also find the correct library.


Is this a bug, or an expected behavior? What parameters should I add
when I invoke cmake so that it will always use libraries with their
full path?


Cheers,

    Mario Emmenlauer



PS: since I build thirdparty libraries, I prefer not to change their
CMakeLists.txt but would rather prefer to set better cmake command line
parameters.


References:
https://cmake.org/Wiki/CMake_RPATH_handling
https://cmake.org/pipermail/cmake/2015-September/061462.html



--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From bo.schwarzstein at gmail.com  Wed Dec 13 05:12:00 2017
From: bo.schwarzstein at gmail.com (Bo Zhou)
Date: Wed, 13 Dec 2017 19:12:00 +0900
Subject: [CMake] absolute library path, sorry for the question
In-Reply-To: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
References: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
Message-ID: <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>

Hi

CMAKE_SKIP_RPATH usually is used for the shared module which might want to
have the customized distributed path such as within the application.
According personal experience on POSIX systems (Linux, UNIX, OSX), always
enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the
final distribution, (if needed) put shared libraries into the lib folder of
distribution.

According your description, I'm not sure how did you pick up your library
into the application from CMake, usually we have to make sure the CMake
always chooses the libraries from 3rd-party directory not system or another
places. In our system, it has a variable THIRDPARTY_DIR for command
FIND_PATH() to locate the folder which contains the all built libraries,
then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to
locate the correct paths for the pre-built libraries, so the linking should
be okay.

If everything has no error, but just the application always picks up the
system's library not the 3rd-party libraries we prepared, one solution
would add another loader script for the application, from the loader script
it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual
application executable file. A lot of commercial application on Linux solve
the similar issue by this way.

Wish my reply is helpful.

Thank you very much.

On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer <mario at emmenlauer.de>
wrote:

>
> Dear cmake users,
>
> I have found good documentation on the cmake wiki about RPATH and
> its different variables, and also on the mailing lists. But somehow
> it still does not add up for me. Can you please help?
>
> I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
> amongst others. I build many standard libraries (like tiff and jpeg)
> into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
> them there. On newer Linux and Windows, cmake uses always the absolute
> path to those libraries, and everything works fine. But on older Linux
> like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
> library in the correct absolute thirdparty directory, and I can confirm
> this by printing the 'XXX_LIBRARIES' variable in the find script. But
> later the Makefile will link with '-lxxx' instead of the full path.
> This makes 'ld' use the system library instead!
>
> I completely fail to understand at what point cmake changes XXX_LIBRARIES
> from an absolute path to '-lxxx', for example for libjpeg.
>
> I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
> The only workaround I could find is to add the thirdparty directory to
> LDFLAGS. Then 'ld' will also find the correct library.
>
>
> Is this a bug, or an expected behavior? What parameters should I add
> when I invoke cmake so that it will always use libraries with their
> full path?
>
>
> Cheers,
>
>     Mario Emmenlauer
>
>
>
> PS: since I build thirdparty libraries, I prefer not to change their
> CMakeLists.txt but would rather prefer to set better cmake command line
> parameters.
>
>
> References:
> https://cmake.org/Wiki/CMake_RPATH_handling
> https://cmake.org/pipermail/cmake/2015-September/061462.html
>
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
> Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
> D-81669 M?nchen                          http://www.biodataanalysis.de/
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/150473bc/attachment.html>

From mario at emmenlauer.de  Wed Dec 13 05:45:06 2017
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Wed, 13 Dec 2017 11:45:06 +0100
Subject: [CMake] absolute library path, sorry for the question
In-Reply-To: <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>
References: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
 <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>
Message-ID: <377028c6-4c41-60a1-ca92-7b580715716c@emmenlauer.de>


Dear Bo Zhou,

Thank you for your reply!! Your explanation is very helpful for writing
my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
that comes with the libraries. For example libtiff, turbojpeg, thrift,
and many others...

As an example, I build libtiff in the following way:
        cmake ../$TIFFVERSION \
            -Wno-dev \
            -G"Unix Makefiles" \
            -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
            -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
            -DCMAKE_BUILD_TYPE="Release" \
            -DBUILD_SHARED_LIBS="ON" \
            -Djpeg="ON" \
            -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
            -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
        make VERBOSE="1" && make install

In the build log, I can see that cmake detects the jpeg library to be
'$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
instead of my thirdparty libjpeg.

So at some point between FindJPEG.cmake and the final Makefile, cmake
changed the JPEG_LIBRARIES variable from absolute to relative. And I can
not understand why or when this happens. The documentation also does not
help me, because it explains that this should happen 'if the full path is
not know or if the full path is one of the system library dirs' (see
https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
I override to use jpeg with a known, existing path that is not a system
library.

All the best,

   Mario




On 13.12.2017 11:12, Bo Zhou wrote:
> Hi
> 
> CMAKE_SKIP_RPATH usually is used for the shared module which might want to have the customized distributed path such as within the application. According
> personal experience on POSIX systems (Linux, UNIX, OSX), always enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final distribution,
> (if needed) put shared libraries into the lib folder of distribution.
> 
> According your description, I'm not sure how did you pick up your library into the application from CMake, usually we have to make sure the CMake always chooses
> the libraries from 3rd-party directory not system or another places. In our system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
> folder which contains the all built libraries, then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
> pre-built libraries, so the linking should be okay.
> 
> If everything has no error, but just the application always picks up the system's library not the 3rd-party libraries we prepared, one solution would add
> another loader script for the application, from the loader script it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual application
> executable file. A lot of commercial application on Linux solve the similar issue by this way.
> 
> Wish my reply is helpful.
> 
> Thank you very much.
> 
> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer <mario at emmenlauer.de <mailto:mario at emmenlauer.de>> wrote:
> 
> 
>     Dear cmake users,
> 
>     I have found good documentation on the cmake wiki about RPATH and
>     its different variables, and also on the mailing lists. But somehow
>     it still does not add up for me. Can you please help?
> 
>     I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
>     amongst others. I build many standard libraries (like tiff and jpeg)
>     into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
>     them there. On newer Linux and Windows, cmake uses always the absolute
>     path to those libraries, and everything works fine. But on older Linux
>     like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
>     library in the correct absolute thirdparty directory, and I can confirm
>     this by printing the 'XXX_LIBRARIES' variable in the find script. But
>     later the Makefile will link with '-lxxx' instead of the full path.
>     This makes 'ld' use the system library instead!
> 
>     I completely fail to understand at what point cmake changes XXX_LIBRARIES
>     from an absolute path to '-lxxx', for example for libjpeg.
> 
>     I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
>     The only workaround I could find is to add the thirdparty directory to
>     LDFLAGS. Then 'ld' will also find the correct library.
> 
> 
>     Is this a bug, or an expected behavior? What parameters should I add
>     when I invoke cmake so that it will always use libraries with their
>     full path?
> 
> 
>     Cheers,
> 
>     ? ? Mario Emmenlauer
> 
> 
> 
>     PS: since I build thirdparty libraries, I prefer not to change their
>     CMakeLists.txt but would rather prefer to set better cmake command line
>     parameters.
> 
> 
>     References:
>     https://cmake.org/Wiki/CMake_RPATH_handling <https://cmake.org/Wiki/CMake_RPATH_handling>
>     https://cmake.org/pipermail/cmake/2015-September/061462.html <https://cmake.org/pipermail/cmake/2015-September/061462.html>
> 
> 
> 


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From mike.jackson at bluequartz.net  Wed Dec 13 08:27:16 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 13 Dec 2017 08:27:16 -0500
Subject: [CMake] Using CMake include does not seem to work intuatively
In-Reply-To: <CAKohaZeNa2BtVYPO0DmJc6z-1ZSkyU2xe15QzcLPVaQ3k0RBAQ@mail.gmail.com>
References: <CAEM70sO1xbaD0pXmz8_U3GYCMdvJiNXPp4mDe3w2+5hLVC_2tg@mail.gmail.com>
 <CAKohaZeNa2BtVYPO0DmJc6z-1ZSkyU2xe15QzcLPVaQ3k0RBAQ@mail.gmail.com>
Message-ID: <2F87E1D7-24E6-4BB6-BBF8-59704D1C06F9@bluequartz.net>

The way "include" was explained to me years ago was that it operates in much the same way as literally "pasting" all the code from the included file directly into the place where the include() command is used. With this in mind the "include(Bar.cmake)" from the Foo.cmake file and the associated error make sense. If you were to copy-paste the code from Foo.cmake into your CMakeLIsts.txt file then it would be looking for a Bar.cmake file in the same directory as "CMakeLists.txt". 

 

--

Michael Jackson | Owner, President

      BlueQuartz Software

[e] mike.jackson at bluequartz.net

[w] www.bluequartz.net

 

From: CMake <cmake-bounces at cmake.org> on behalf of Petr Kmoch <petr.kmoch at gmail.com>
Date: Wednesday, December 13, 2017 at 3:03 AM
To: Saad Khattak <saadrustam at gmail.com>
Cc: CMake Mail List <cmake at cmake.org>
Subject: Re: [CMake] Using CMake include does not seem to work intuatively

 

Hi Saad.

I can't comment on whether the behaviour is correct or expectable, but to get it working the way you want, you can specify the path fully:

include(${CMAKE_CURRENT_LIST_DIR}/Bar.cmake)

Petr

 

 

On 13 December 2017 at 01:34, Saad Khattak <saadrustam at gmail.com> wrote:

Hi,

 

Let's say I have the following directory structure:

~/Repos/MyRepo/CMakeLists.txt

~/CMakeFiles/Foo.cmake

~/CMakeFiles/Bar.cmake

 

In the CMakeLists.txt I have the following command:

 

include(~/CMakeFiles/Foo.cmake)

 

And in Foo.cmake I have the following command:

 

include(Bar.cmake)

 

Turns out that he `include(Bar.cmake)` from `Foo.cmake` fails. This is counter to what I would expect (e.g. how #include works in C).

 

Is this a bug or is this behavior expected? If it's expected, what is the workaround? We have a lot of common cmake files which in turn include files relative to each other and not the calling CMakeLists.txt.

 

Thank you,

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:
http://public.kitware.com/mailman/listinfo/cmake

 

-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/2a511776/attachment-0001.html>

From waldovalenzuela at yahoo.com  Wed Dec 13 14:15:43 2017
From: waldovalenzuela at yahoo.com (Waldo Valenzuela)
Date: Wed, 13 Dec 2017 20:15:43 +0100
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
 <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>
Message-ID: <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>

Dear Miklos,

thanks for the email, and your suggestions, but the problem with fixup_bundle in ubuntu is that is not fixing the libraries locations from the executables meaning:

if I execute the idd command like this ? idd ./app? where ?app? is the executable, the locations of the library is still is ?no found", that should be in the location that was copy after running the INSTALL.

when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I modified the environment configuration of O.S.. The idea is that I want to create a standalone application.

Under this scenario, if I have an executable called ?app? and a shared library call ?lib.so?, fixup_bundle should fix the location of the ?lib.so? in the same folder where is ?app?.

Then if I run the command "idd ./app? the output should be:

lib.so => ?xxxx?, where xxxx is folder where is located ?app"

Cheers,

Waldo.


> On 13 Dec 2017, at 03:58, Miklos Espak <espakm at gmail.com> wrote:
> 
> Hi,
> 
> you need to add the directory where the Qt libs have been installed (along with your application binaries) to the LD_LIBRARY_PATH. In your case it is '/home/waldo/Developer/install/Release/bratumia/bin/', as I see.
> 
> Also, you do *not* need to add the Qt plugin directories to the library path. The plugins are loaded at run-time. So that they can be found, you need to install a qt.conf file in the bin directory with the following contents:
> 
> [Paths]
> Prefix=.
> 
> You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the library path. These libraries are searched for by default. If you did it because your Qt installation is there, that's wrong. The fixup_bundle function should have copied the necessary Qt libs in the install bin folder, so you just need to add that folder to the path.
> 
> Also, make sure that the DIRS variable contains all the directories where there are libraries to install, including dependencies.
> 
> I hope that helps.
> 
> Best regards,
> Miklos
> 
> 
> 
> On 11 December 2017 at 19:07, Waldo Valenzuela via CMake <cmake at cmake.org <mailto:cmake at cmake.org>> wrote:
> Dear All,
> 
> I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac no problem to created the standalone app, but in Ubuntu 16.04  I have several problems.
> 
> I am using CodeBlocks to compile and run the app, and from CodeBlocks when I run the app there is no problem, it work normally like in windows and mac, but after run the installation, and If I want to run the app from the installation folder (./app ) I have several problems.
> 
> 
> the CMakeList.txt is
> 
> FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
> FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
> 
> SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
> 
> MESSAGE("Project libraries: ${QTPLUGINS}")
> 
> 
> INSTALL(CODE "
>         INCLUDE(BundleUtilities)
>         FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
>              "
>         COMPONENT ${PROJECT_NAME})
> 
> First I have this:
> 
> -- fixup_bundle: fixing...
> -- 132/260: fix-up not required on this platform '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
> -- 133/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
> -- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5?
> 
> -- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
> -- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
> -- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1
> 
> then when I run: ldd ./app I have:
> 
>         libQt5Concurrent.so.5 => not found
>         libvtkRenderingImage-9.0.so.1 => not found
>         libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found
> 
> then if I fix manually the path of the libraries like this:
> 
> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"
> 
> I can run the application from through the command line from the installation folder, but I have this message and I can not see nothing
> 
> QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
> QOpenGLWidget: Failed to create context
> composeAndFlush: makeCurrent() failed
> 
> 
> I think that the FIXUP_BUNDLE is doing nothing.
> 
> Any help is welcome.
> 
> Best regards,
> 
> Waldo.
> --
> 
> 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 <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 <http://cmake.org/cmake/help/support.html>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake <http://public.kitware.com/mailman/listinfo/cmake>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/ee817682/attachment.html>

From annulen at yandex.ru  Wed Dec 13 14:19:05 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 13 Dec 2017 22:19:05 +0300
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
 <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>
 <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
Message-ID: <535191513192745@web45g.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/c0d799da/attachment-0001.html>

From waldovalenzuela at yahoo.com  Wed Dec 13 14:31:09 2017
From: waldovalenzuela at yahoo.com (Waldo Valenzuela)
Date: Wed, 13 Dec 2017 20:31:09 +0100
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <535191513192745@web45g.yandex.ru>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
 <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>
 <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
 <535191513192745@web45g.yandex.ru>
Message-ID: <AAAC1D31-A39E-4271-90C6-806053FC7450@yahoo.com>

Dear Konstantin,


Thanks for the email, yes you are right, I was looking this tool time ago, but the fixup_bundle is just a part of the bigger problem, meaning if I want to create a DEB  package with CMake/CPack, how I could tell CPACK to use linuxdeployqt, in runtime.


CMake/CPack in windows and mac osx are doing their job, but in linux no, in linux we need to many additional tools to create a package.

Cheers,

Waldo.

> On 13 Dec 2017, at 20:19, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 
>  
>  
> 13.12.2017, 22:16, "Waldo Valenzuela via CMake" <cmake at cmake.org <mailto:cmake at cmake.org>>:
>> Dear Miklos,
>>  
>> thanks for the email, and your suggestions, but the problem with fixup_bundle in ubuntu is that is not fixing the libraries locations from the executables meaning:
>>  
>> if I execute the idd command like this ? idd ./app? where ?app? is the executable, the locations of the library is still is ?no found", that should be in the location that was copy after running the INSTALL.
>>  
>> when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I modified the environment configuration of O.S.. The idea is that I want to create a standalone application.
>>  
>> Under this scenario, if I have an executable called ?app? and a shared library call ?lib.so?, fixup_bundle should fix the location of the ?lib.so? in the same folder where is ?app?.
>>  
>> Then if I run the command "idd ./app? the output should be:
>>  
>> lib.so => ?xxxx?, where xxxx is folder where is located ?app"
>  
> Use linuxdeployqt (https://github.com/probonopd/linuxdeployqt <https://github.com/probonopd/linuxdeployqt>)
>  
>>  
>> Cheers,
>>  
>> Waldo.
>>  
>>  
>>> 
>>> On 13 Dec 2017, at 03:58, Miklos Espak <espakm at gmail.com <mailto:espakm at gmail.com>> wrote:
>>>  
>>> Hi,
>>>  
>>> you need to add the directory where the Qt libs have been installed (along with your application binaries) to the LD_LIBRARY_PATH. In your case it is '/home/waldo/Developer/install/Release/bratumia/bin/', as I see.
>>>  
>>> Also, you do *not* need to add the Qt plugin directories to the library path. The plugins are loaded at run-time. So that they can be found, you need to install a qt.conf file in the bin directory with the following contents:
>>>  
>>> [Paths]
>>> Prefix=.
>>>  
>>> You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the library path. These libraries are searched for by default. If you did it because your Qt installation is there, that's wrong. The fixup_bundle function should have copied the necessary Qt libs in the install bin folder, so you just need to add that folder to the path.
>>>  
>>> Also, make sure that the DIRS variable contains all the directories where there are libraries to install, including dependencies.
>>>  
>>> I hope that helps.
>>>  
>>> Best regards,
>>> Miklos
>>>  
>>>  
>>>  
>>> On 11 December 2017 at 19:07, Waldo Valenzuela via CMake <cmake at cmake.org <mailto:cmake at cmake.org>> wrote:
>>> Dear All,
>>> 
>>> I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac no problem to created the standalone app, but in Ubuntu 16.04  I have several problems.
>>> 
>>> I am using CodeBlocks to compile and run the app, and from CodeBlocks when I run the app there is no problem, it work normally like in windows and mac, but after run the installation, and If I want to run the app from the installation folder (./app ) I have several problems.
>>> 
>>> 
>>> the CMakeList.txt is
>>> 
>>> FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>>> FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>>> 
>>> SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
>>> 
>>> MESSAGE("Project libraries: ${QTPLUGINS}")
>>> 
>>> 
>>> INSTALL(CODE "
>>>         INCLUDE(BundleUtilities)
>>>         FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
>>>              "
>>>         COMPONENT ${PROJECT_NAME})
>>> 
>>> First I have this:
>>> 
>>> -- fixup_bundle: fixing...
>>> -- 132/260: fix-up not required on this platform '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
>>> -- 133/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
>>> -- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5?
>>> 
>>> -- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
>>> -- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
>>> -- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1
>>> 
>>> then when I run: ldd ./app I have:
>>> 
>>>         libQt5Concurrent.so.5 => not found
>>>         libvtkRenderingImage-9.0.so.1 => not found
>>>         libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found
>>> 
>>> then if I fix manually the path of the libraries like this:
>>> 
>>> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"
>>> 
>>> I can run the application from through the command line from the installation folder, but I have this message and I can not see nothing
>>> 
>>> QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
>>> QOpenGLWidget: Failed to create context
>>> composeAndFlush: makeCurrent() failed
>>> 
>>> 
>>> I think that the FIXUP_BUNDLE is doing nothing.
>>> 
>>> Any help is welcome.
>>> 
>>> Best regards,
>>> 
>>> Waldo.
>>> --
>>> 
>>> 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 <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 <http://cmake.org/cmake/help/support.html>
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
>>> 
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake <http://public.kitware.com/mailman/listinfo/cmake>,-- 
>> 
>> 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 <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 <http://cmake.org/cmake/help/support.html>
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
>> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake <http://public.kitware.com/mailman/listinfo/cmake> 
>  
> -- 
> Regards,
> Konstantin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/50b2a9c9/attachment.html>

From dschepler at scalable-networks.com  Wed Dec 13 14:32:35 2017
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Wed, 13 Dec 2017 19:32:35 +0000
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
 <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>,
 <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C940136004FAF@SNTMAIL01.snt.loc>

You would need to set the INSTALL_RPATH property of the targets to something like "$ORIGIN/../lib" .

You might also need to add "-Wl,--disable-new-dtags" to the CMAKE_*_LINK_FLAGS variables - otherwise, the RPATH settings will only take effect for direct dependencies of the executables (and any plugins or shared libraries) you build but not for dependencies of these dependencies.

(We also tend not to include copies of glibc or OpenGL libraries - for the former, that tends to have issues if there are any mismatches between the exact build of glibc included in the installer and the NSS modules from the system.  For the latter, the OpenGL libraries vary too much between Mesa and the NVidia and AMD proprietary driver versions for any one of them to work on all systems.)
--
Daniel Schepler
________________________________
From: CMake [cmake-bounces at cmake.org] on behalf of Waldo Valenzuela via CMake [cmake at cmake.org]
Sent: Wednesday, December 13, 2017 11:15 AM
To: Miklos Espak
Cc: cmake at cmake.org
Subject: Re: [CMake] CMake fixup_bundle for ubuntu 16.04

Dear Miklos,

thanks for the email, and your suggestions, but the problem with fixup_bundle in ubuntu is that is not fixing the libraries locations from the executables meaning:

if I execute the idd command like this ? idd ./app? where ?app? is the executable, the locations of the library is still is ?no found", that should be in the location that was copy after running the INSTALL.

when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I modified the environment configuration of O.S.. The idea is that I want to create a standalone application.

Under this scenario, if I have an executable called ?app? and a shared library call ?lib.so?, fixup_bundle should fix the location of the ?lib.so? in the same folder where is ?app?.

Then if I run the command "idd ./app? the output should be:

lib.so => ?xxxx?, where xxxx is folder where is located ?app"

Cheers,

Waldo.


On 13 Dec 2017, at 03:58, Miklos Espak <espakm at gmail.com<mailto:espakm at gmail.com>> wrote:

Hi,

you need to add the directory where the Qt libs have been installed (along with your application binaries) to the LD_LIBRARY_PATH. In your case it is '/home/waldo/Developer/install/Release/bratumia/bin/', as I see.

Also, you do *not* need to add the Qt plugin directories to the library path. The plugins are loaded at run-time. So that they can be found, you need to install a qt.conf file in the bin directory with the following contents:

[Paths]
Prefix=.

You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the library path. These libraries are searched for by default. If you did it because your Qt installation is there, that's wrong. The fixup_bundle function should have copied the necessary Qt libs in the install bin folder, so you just need to add that folder to the path.

Also, make sure that the DIRS variable contains all the directories where there are libraries to install, including dependencies.

I hope that helps.

Best regards,
Miklos



On 11 December 2017 at 19:07, Waldo Valenzuela via CMake <cmake at cmake.org<mailto:cmake at cmake.org>> wrote:
Dear All,

I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac no problem to created the standalone app, but in Ubuntu 16.04  I have several problems.

I am using CodeBlocks to compile and run the app, and from CodeBlocks when I run the app there is no problem, it work normally like in windows and mac, but after run the installation, and If I want to run the app from the installation folder (./app ) I have several problems.


the CMakeList.txt is

FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})

SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})

MESSAGE("Project libraries: ${QTPLUGINS}")


INSTALL(CODE "
        INCLUDE(BundleUtilities)
        FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
             "
        COMPONENT ${PROJECT_NAME})

First I have this:

-- fixup_bundle: fixing...
-- 132/260: fix-up not required on this platform '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
-- 133/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
-- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5?

-- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
-- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
-- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1

then when I run: ldd ./app I have:

        libQt5Concurrent.so.5 => not found
        libvtkRenderingImage-9.0.so.1 => not found
        libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found

then if I fix manually the path of the libraries like this:

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"

I can run the application from through the command line from the installation folder, but I have this message and I can not see nothing

QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
QOpenGLWidget: Failed to create context
composeAndFlush: makeCurrent() failed


I think that the FIXUP_BUNDLE is doing nothing.

Any help is welcome.

Best regards,

Waldo.
--

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:
http://public.kitware.com/mailman/listinfo/cmake


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/2c7c2c5e/attachment-0001.html>

From waldovalenzuela at yahoo.com  Wed Dec 13 15:31:17 2017
From: waldovalenzuela at yahoo.com (Waldo Valenzuela)
Date: Wed, 13 Dec 2017 21:31:17 +0100
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C940136004FAF@SNTMAIL01.snt.loc>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
 <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>
 <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C940136004FAF@SNTMAIL01.snt.loc>
Message-ID: <FA1A85B6-2796-4814-9F59-8A06CA5F683E@yahoo.com>

Dear Daniel,

Thanks for the email, I was trying different combinations of CMAKE_INSTALL_RPATH, with full and relative paths and were not working, I did not about the link flags, thanks for the advice I will test it. 

Also, the relative onces is not clear for me, if I set  "$ORIGIN/../lib?, this is reconstructed from the installation directory of the executable of from cpack tmp directory where is copy during the packaged process.

In this topic are missing examples in the CMake documentation (https://cmake.org/Wiki/CMake_RPATH_handling), here they do not mention nothing about the flags also.

Also, I am completely agree with you regarding the OpenGL, vary too much between the different venders.

Best regards,

Waldo

> On 13 Dec 2017, at 20:32, Daniel Schepler <dschepler at scalable-networks.com> wrote:
> 
> You would need to set the INSTALL_RPATH property of the targets to something like "$ORIGIN/../lib" .
> 
> You might also need to add "-Wl,--disable-new-dtags" to the CMAKE_*_LINK_FLAGS variables - otherwise, the RPATH settings will only take effect for direct dependencies of the executables (and any plugins or shared libraries) you build but not for dependencies of these dependencies.
> 
> (We also tend not to include copies of glibc or OpenGL libraries - for the former, that tends to have issues if there are any mismatches between the exact build of glibc included in the installer and the NSS modules from the system.  For the latter, the OpenGL libraries vary too much between Mesa and the NVidia and AMD proprietary driver versions for any one of them to work on all systems.)
> -- 
> Daniel Schepler
> From: CMake [cmake-bounces at cmake.org] on behalf of Waldo Valenzuela via CMake [cmake at cmake.org]
> Sent: Wednesday, December 13, 2017 11:15 AM
> To: Miklos Espak
> Cc: cmake at cmake.org
> Subject: Re: [CMake] CMake fixup_bundle for ubuntu 16.04
> 
> Dear Miklos,
> 
> thanks for the email, and your suggestions, but the problem with fixup_bundle in ubuntu is that is not fixing the libraries locations from the executables meaning:
> 
> if I execute the idd command like this ? idd ./app? where ?app? is the executable, the locations of the library is still is ?no found", that should be in the location that was copy after running the INSTALL.
> 
> when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I modified the environment configuration of O.S.. The idea is that I want to create a standalone application.
> 
> Under this scenario, if I have an executable called ?app? and a shared library call ?lib.so?, fixup_bundle should fix the location of the ?lib.so? in the same folder where is ?app?.
> 
> Then if I run the command "idd ./app? the output should be:
> 
> lib.so => ?xxxx?, where xxxx is folder where is located ?app"
> 
> Cheers,
> 
> Waldo.
> 
> 
>> On 13 Dec 2017, at 03:58, Miklos Espak <espakm at gmail.com <mailto:espakm at gmail.com>> wrote:
>> 
>> Hi,
>> 
>> you need to add the directory where the Qt libs have been installed (along with your application binaries) to the LD_LIBRARY_PATH. In your case it is '/home/waldo/Developer/install/Release/bratumia/bin/', as I see.
>> 
>> Also, you do *not* need to add the Qt plugin directories to the library path. The plugins are loaded at run-time. So that they can be found, you need to install a qt.conf file in the bin directory with the following contents:
>> 
>> [Paths]
>> Prefix=.
>> 
>> You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the library path. These libraries are searched for by default. If you did it because your Qt installation is there, that's wrong. The fixup_bundle function should have copied the necessary Qt libs in the install bin folder, so you just need to add that folder to the path.
>> 
>> Also, make sure that the DIRS variable contains all the directories where there are libraries to install, including dependencies.
>> 
>> I hope that helps.
>> 
>> Best regards,
>> Miklos
>> 
>> 
>> 
>> On 11 December 2017 at 19:07, Waldo Valenzuela via CMake <cmake at cmake.org <mailto:cmake at cmake.org>> wrote:
>> Dear All,
>> 
>> I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac no problem to created the standalone app, but in Ubuntu 16.04  I have several problems.
>> 
>> I am using CodeBlocks to compile and run the app, and from CodeBlocks when I run the app there is no problem, it work normally like in windows and mac, but after run the installation, and If I want to run the app from the installation folder (./app ) I have several problems.
>> 
>> 
>> the CMakeList.txt is
>> 
>> FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>> FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>> 
>> SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
>> 
>> MESSAGE("Project libraries: ${QTPLUGINS}")
>> 
>> 
>> INSTALL(CODE "
>>         INCLUDE(BundleUtilities)
>>         FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
>>              "
>>         COMPONENT ${PROJECT_NAME})
>> 
>> First I have this:
>> 
>> -- fixup_bundle: fixing...
>> -- 132/260: fix-up not required on this platform '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
>> -- 133/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
>> -- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5?
>> 
>> -- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
>> -- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
>> -- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1
>> 
>> then when I run: ldd ./app I have:
>> 
>>         libQt5Concurrent.so.5 => not found
>>         libvtkRenderingImage-9.0.so.1 => not found
>>         libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found
>> 
>> then if I fix manually the path of the libraries like this:
>> 
>> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"
>> 
>> I can run the application from through the command line from the installation folder, but I have this message and I can not see nothing
>> 
>> QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
>> QOpenGLWidget: Failed to create context
>> composeAndFlush: makeCurrent() failed
>> 
>> 
>> I think that the FIXUP_BUNDLE is doing nothing.
>> 
>> Any help is welcome.
>> 
>> Best regards,
>> 
>> Waldo.
>> --
>> 
>> 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 <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 <http://cmake.org/cmake/help/support.html>
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
>> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake <http://public.kitware.com/mailman/listinfo/cmake>
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/bb685311/attachment-0001.html>

From saadrustam at gmail.com  Wed Dec 13 16:22:08 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Wed, 13 Dec 2017 21:22:08 +0000
Subject: [CMake] Using SET_TARGET_PROPERTIES and
	IMPORTED_LINK_INTERFACE_LIBRARIES
Message-ID: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>

Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is
either LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
properly:

set_target_properties(${LIB_NAME}
    PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
    )

Now let's say I have another imported library LibD that depends on LibA and
LibB such that any executable that uses LibD must also link with LibA and
LibB. To do that, I use:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

However, the above syntax is incorrect and CMake complains that
SET_TARGET_PROPERTIES was called with incorrect number of arguments.

So I thought maybe the following will work:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA
    IMPORTED_LINK_INTERFACE_LIBRARIES LibB
  )

Although this time CMake doesn't complaint, only LibB's libraries are
linked ultimately, LibA is overwritten. Doing the following, of course,
doesn't work because LibA is now an imported library and not exactly a
variable that can be used directly:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "${LibA};${LibB}" # not correct
because LibA and LibB are CMake imported libraries, not direct paths to
libraries
  )

Is there any way to specify, for an imported target, multiple dependencies
on other libraries (and/or dependencies on other imported libraries).

Thanks,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171213/a98204dc/attachment.html>

From craig.scott at crascit.com  Wed Dec 13 16:32:48 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 14 Dec 2017 08:32:48 +1100
Subject: [CMake] Using SET_TARGET_PROPERTIES and
	IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
Message-ID: <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>

On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com> wrote:

> Hi,
>
> I have several imported libraries:
>
> LibA
> LibB
> LibC
>
> Where each imported library has been populated by (where ${LIB_NAME} is
> either LibA, LibB or LibC):
>
> add_library(${LIB_NAME} STATIC IMPORTED)
>
> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
> properly:
>
> set_target_properties(${LIB_NAME}
>     PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>    "location/of/library.lib"
>     )
>
> Now let's say I have another imported library LibD that depends on LibA
> and LibB such that any executable that uses LibD must also link with LibA
> and LibB. To do that, I use:
>
> set_target_properties(LibD
>   PROPERTIES
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>   )
>

You probably want this instead:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
)


Note that if the property value is a list, you have to provide it as a
single string (i.e. "LibA;LibB" rather than LibA LibB)



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171214/2878f433/attachment.html>

From saadrustam at gmail.com  Wed Dec 13 21:19:58 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Thu, 14 Dec 2017 02:19:58 +0000
Subject: [CMake] Using SET_TARGET_PROPERTIES and
	IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
Message-ID: <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using
"add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
both have some properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
they have their own include and link directories and other library
dependencies.

The nice thing about using LibA directly is then LibD inherits all the
include and link directories of LibA and LibB which then get inherited by
any library or executable that includes LibD (and ultimately, the whole
point of modern CMake):

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
IMPORTED CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library
names of the imported CMake libraries LibA and LibB. Then, I have to call
"target_include_directories" and "target_link_libraries" for all
dependencies of LibA and LibB, even though these dependencies were defined
in their own respective CMake files when calling "add_library(LibA STATIC
IMPORTED)"

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
recognizes LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com> wrote:

> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
>> Hi,
>>
>> I have several imported libraries:
>>
>> LibA
>> LibB
>> LibC
>>
>> Where each imported library has been populated by (where ${LIB_NAME} is
>> either LibA, LibB or LibC):
>>
>> add_library(${LIB_NAME} STATIC IMPORTED)
>>
>> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
>> properly:
>>
>> set_target_properties(${LIB_NAME}
>>     PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>>    "location/of/library.lib"
>>     )
>>
>> Now let's say I have another imported library LibD that depends on LibA
>> and LibB such that any executable that uses LibD must also link with LibA
>> and LibB. To do that, I use:
>>
>> set_target_properties(LibD
>>   PROPERTIES
>>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>>   )
>>
>
> You probably want this instead:
>
> set_target_properties(LibD
>   PROPERTIES
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
> )
>
>
> Note that if the property value is a list, you have to provide it as a
> single string (i.e. "LibA;LibB" rather than LibA LibB)
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171214/5bb078ce/attachment.html>

From petr.kmoch at gmail.com  Thu Dec 14 03:34:50 2017
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 14 Dec 2017 09:34:50 +0100
Subject: [CMake] Using SET_TARGET_PROPERTIES and
 IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
 <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
Message-ID: <CAKohaZdWPtpwaH0uDfKkr65jdeUWZGbWNmtpd38hT3XAC0u9JA@mail.gmail.com>

Hi Saad,

have you read the docs on IMPORTED_LINK_INTERFACE_LIBRARIES? (
https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LINK_INTERFACE_LIBRARIES.html
):

  "This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead."

Setting INTERFACE_LINK_LIBRARIES to "LibA;LibB" should do exactly what you
want.

As a side note, the shorthand funciton set_target_properties() and friends
are best suited when multiple properties to one value each. When setting a
list, it's usually more convenient to use the general set_property():

set_property(
  TARGET LibD
  PROPERTY INTERFACE_LINK_LIBRARIES
  LibA LibB
)

Petr


On 14 December 2017 at 03:19, Saad Khattak <saadrustam at gmail.com> wrote:

> Thanks Craig for your reply.
>
> The issue is that both "LibA" and "LibB" have been set using
> "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
> both have some properties that are being set.
>
> Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
> they have their own include and link directories and other library
> dependencies.
>
> The nice thing about using LibA directly is then LibD inherits all the
> include and link directories of LibA and LibB which then get inherited by
> any library or executable that includes LibD (and ultimately, the whole
> point of modern CMake):
>
> set_target_properties(LibD
>   PROPERTIES
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
> IMPORTED CMake libraries
> )
>
> If I use "LibA;LibB" then first, I have to manually extract the library
> names of the imported CMake libraries LibA and LibB. Then, I have to call
> "target_include_directories" and "target_link_libraries" for all
> dependencies of LibA and LibB, even though these dependencies were defined
> in their own respective CMake files when calling "add_library(LibA STATIC
> IMPORTED)"
>
> set_target_properties(LibD
>   PROPERTIES
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
> recognizes LibA and LibB as IMPORTED CMake libraries
> )
>
> Regards,
> Saad
>
> On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
>> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have several imported libraries:
>>>
>>> LibA
>>> LibB
>>> LibC
>>>
>>> Where each imported library has been populated by (where ${LIB_NAME} is
>>> either LibA, LibB or LibC):
>>>
>>> add_library(${LIB_NAME} STATIC IMPORTED)
>>>
>>> And each library has the properties IMPORT_LOCATION_${CONFIGURATION}
>>> set properly:
>>>
>>> set_target_properties(${LIB_NAME}
>>>     PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>>>    "location/of/library.lib"
>>>     )
>>>
>>> Now let's say I have another imported library LibD that depends on LibA
>>> and LibB such that any executable that uses LibD must also link with LibA
>>> and LibB. To do that, I use:
>>>
>>> set_target_properties(LibD
>>>   PROPERTIES
>>>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>>>   )
>>>
>>
>> You probably want this instead:
>>
>> set_target_properties(LibD
>>   PROPERTIES
>>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
>> )
>>
>>
>> Note that if the property value is a list, you have to provide it as a
>> single string (i.e. "LibA;LibB" rather than LibA LibB)
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171214/c0328b4f/attachment-0001.html>

From marc.chevrier at sap.com  Thu Dec 14 03:40:22 2017
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Thu, 14 Dec 2017 08:40:22 +0000
Subject: [CMake] Using SET_TARGET_PROPERTIES and
 IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
 <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
Message-ID: <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>

I think you can fill a bug about erroneous behaviour when a list is specified with command set_target_properties for property IMPORTED_LINK_INTERFACE_LIBRARIES.

Another way to specify the property is to use command set_property which supports multiple values for a property:
set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB)


From: CMake <cmake-bounces at cmake.org> on behalf of Saad Khattak <saadrustam at gmail.com>
Date: Thursday 14 December 2017 at 03:20
To: Craig Scott <craig.scott at crascit.com>
Cc: Cmake Mailing List <cmake at cmake.org>
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and both have some properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and they have their own include and link directories and other library dependencies.

The nice thing about using LibA directly is then LibD inherits all the include and link directories of LibA and LibB which then get inherited by any library or executable that includes LibD (and ultimately, the whole point of modern CMake):

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as IMPORTED CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library names of the imported CMake libraries LibA and LibB. Then, I have to call "target_include_directories" and "target_link_libraries" for all dependencies of LibA and LibB, even though these dependencies were defined in their own respective CMake files when calling "add_library(LibA STATIC IMPORTED)"

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer recognizes LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>> wrote:
On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com<mailto:saadrustam at gmail.com>> wrote:
Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is either LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set properly:

set_target_properties(${LIB_NAME}
    PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
    )

Now let's say I have another imported library LibD that depends on LibA and LibB such that any executable that uses LibD must also link with LibA and LibB. To do that, I use:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

You probably want this instead:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
)

Note that if the property value is a list, you have to provide it as a single string (i.e. "LibA;LibB" rather than LibA LibB)



--
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171214/fa04840a/attachment.html>

From annulen at yandex.ru  Thu Dec 14 05:17:15 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 14 Dec 2017 13:17:15 +0300
Subject: [CMake] CMake fixup_bundle for ubuntu 16.04
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C940136004FAF@SNTMAIL01.snt.loc>
References: <4B2B63ED-5305-4141-A5F6-CAEF06EE024E@yahoo.com>
 <CAOVq=oOL-VzAvoHKwCA2iP9y=9Gf8eTmASFiX1VPd5rsQ-W1RQ@mail.gmail.com>,
 <DAABA03E-E8DB-430B-8BF1-C20C695FE37A@yahoo.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C940136004FAF@SNTMAIL01.snt.loc>
Message-ID: <477001513246635@web33o.yandex.ru>



13.12.2017, 23:08, "Daniel Schepler" <dschepler at scalable-networks.com>:
> You would need to set the INSTALL_RPATH property of the targets to something like "$ORIGIN/../lib" .
>
> You might also need to add "-Wl,--disable-new-dtags" to the CMAKE_*_LINK_FLAGS variables - otherwise, the RPATH settings will only take effect for direct dependencies of the executables (and any plugins or shared libraries) you build but not for dependencies of these dependencies.
>
> (We also tend not to include copies of glibc or OpenGL libraries - for the former, that tends to have issues if there are any mismatches between the exact build of glibc included in the installer and the NSS modules from the system.? For the latter, the OpenGL libraries vary too much between Mesa and the NVidia and AMD proprietary driver versions for any one of them to work on all systems.)

Note that if your application loads at least one library from the host system, you must use system libc.

(Also, bundling libc requires rewriting of loader (INTERP ELF header), it can be done with patchelf --set-interpreter)

> --
> Daniel Schepler
> ----------------------------------------
> From: CMake [cmake-bounces at cmake.org] on behalf of Waldo Valenzuela via CMake [cmake at cmake.org]
> Sent: Wednesday, December 13, 2017 11:15 AM
> To: Miklos Espak
> Cc: cmake at cmake.org
> Subject: Re: [CMake] CMake fixup_bundle for ubuntu 16.04
>
> Dear Miklos,
>
> thanks for the email, and your suggestions, but the problem with?fixup_bundle in ubuntu is that is not fixing the libraries locations from the executables meaning:
>
> if I execute the idd command like this ??idd ./app? where ?app? is the executable, the locations of the library is still is ?no found", that should be in the location that was copy after running the INSTALL.
>
> when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I modified the environment configuration of O.S.. The idea is that I want to create a standalone application.
>
> Under this scenario, if I have an executable called ?app? and a shared library call ?lib.so?, fixup_bundle should fix the location of the ?lib.so? in the same folder where is ?app?.
>
> Then if I run the command "idd ./app? the output should be:
>
> lib.so => ?xxxx?, where xxxx is folder where is located ?app"
>
> Cheers,
>
> Waldo.
>
>> On 13 Dec 2017, at 03:58, Miklos Espak <espakm at gmail.com> wrote:
>>
>> Hi,
>>
>> you need to add the directory where the Qt libs have been installed (along with your application binaries) to the LD_LIBRARY_PATH. In your case it is?'/home/waldo/Developer/install/Release/bratumia/bin/', as I see.
>>
>> Also, you do *not* need to add the Qt plugin directories to the library path. The plugins are loaded at run-time. So that they can be found, you need to install a qt.conf file in the bin directory with the following contents:
>>
>> [Paths]
>> Prefix=.
>>
>> You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the library path. These libraries are searched for by default. If you did it because your Qt installation is there, that's wrong. The fixup_bundle function should have copied the necessary Qt libs in the install bin folder, so you just need to add that folder to the path.
>>
>> Also, make sure that the DIRS variable contains all the directories where there are libraries to install, including dependencies.
>>
>> I hope that helps.
>>
>> Best regards,
>> Miklos
>>
>> On 11 December 2017 at 19:07, Waldo Valenzuela via CMake <cmake at cmake.org> wrote:
>>> Dear All,
>>>
>>> I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac no problem to created the standalone app, but in Ubuntu 16.04? I have several problems.
>>>
>>> I am using CodeBlocks to compile and run the app, and from CodeBlocks when I run the app there is no problem, it work normally like in windows and mac, but after run the installation, and If I want to run the app from the installation folder (./app ) I have several problems.
>>>
>>> the CMakeList.txt is
>>>
>>> FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>>> FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>>>
>>> SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
>>>
>>> MESSAGE("Project libraries: ${QTPLUGINS}")
>>>
>>> INSTALL(CODE "
>>> ? ? ? ? INCLUDE(BundleUtilities)
>>> ? ? ? ? FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
>>> ? ? ? ? ? ? ?"
>>> ? ? ? ? COMPONENT ${PROJECT_NAME})
>>>
>>> First I have this:
>>>
>>> -- fixup_bundle: fixing...
>>> -- 132/260: fix-up not required on this platform '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
>>> -- 133/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
>>> -- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5?
>>>
>>> -- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
>>> -- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
>>> -- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1
>>>
>>> then when I run: ldd ./app I have:
>>>
>>> ? ? ? ? libQt5Concurrent.so.5 => not found
>>> ? ? ? ? libvtkRenderingImage-9.0.so.1 => not found
>>> ? ? ? ? libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found
>>>
>>> then if I fix manually the path of the libraries like this:
>>>
>>> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"
>>>
>>> I can run the application from through the command line from the installation folder, but I have this message and I can not see nothing
>>>
>>> QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
>>> QOpenGLWidget: Failed to create context
>>> composeAndFlush: makeCurrent() failed
>>>
>>> I think that the FIXUP_BUNDLE is doing nothing.
>>>
>>> Any help is welcome.
>>>
>>> Best regards,
>>>
>>> Waldo.
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
> ,--
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake


--?
Regards,
Konstantin

From robert.maynard at kitware.com  Thu Dec 14 09:29:23 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 14 Dec 2017 09:29:23 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.10.1 available for download
Message-ID: <CAFzjYVpbLdpTo3of_5da9trnospGmjxR9unjdUBp2TehRGGioQ@mail.gmail.com>

We are pleased to announce that CMake 3.10.1 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.1 since 3.10.0:

Adam Ciarci?ski (1):
      bootstrap: Check support for unordered_map from compiler mode

Alexander Wittig (1):
      CPack: Fix macOS PKG component dependency information

Brad King (3):
      CUDA: Treat /usr/include as an implicit include directory
      server: Revert "Report backtraces in codemodel response"
      CMake 3.10.1

Christian Pfeiffer (4):
      FindMPI: Correct legacy variable handling
      FindMPI: Fix multiple configure runs
      FindMPI: Fix various legacy problems
      IRSL: Fix MSVC variable deferencing

Islam Amer (1):
      IAR: FindBinUtils should work for CXX as well as C

Matthew Woehlke (4):
      GoogleTest: Fix multiple discovery on same target
      GoogleTest: Improve gtest_discover_tests messages
      GoogleTest: Add timeout to discovery
      GoogleTest: Add test for missing test executable

Robert Maynard (1):
      CUDA: Shared libraries on Darwin properly setup @rpath install_names

Sebastian Holtermann (2):
      Autogen: Fix for AUTOMOC on macOS frameworks in CMake 3.10
      Autogen: Tests: Add test for MacOS frameworks

?smail D?nmez (1):
      Clang: Do not mistake clang-cl 6.0 for GNU-like clang

From mike.jackson at bluequartz.net  Thu Dec 14 13:51:42 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 14 Dec 2017 13:51:42 -0500
Subject: [CMake] Configuration under CMake 3.10.1 fails but succeeds with
 3.9.6
Message-ID: <D14A0EF1-5D5B-4993-8B08-F551C87D8C42@bluequartz.net>

I just tried out the latest CMake release 3.10.1 and it fails to configure (from a clean build directory) our project where CMake 3.9.x and below (down to CMake 3.7.x) configures it completely and correctly. The configure error I get is"

-- Configuring done
CMake Error in /Users/mjackson/Workspace/DREAM3D_Plugins/AskNDEToolbox/Applications/ScanViewer/CMakeLists.txt:
  Cannot find source file:

    /Users/mjackson/Workspace/DREAM3D-Build/3.10.1/Plugins/AskNDEToolbox/qrc_AskNDEToolbox.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

Now, the funny thing about this is that nowhere in the CMakeLists files for the "ScaneViewer" application should it be adding the generated qrc_AskNDEToolbox.cpp file. That file is added higher up in the heirarchy of projects, but not that particular application. Does anyone have any thoughts on this issue?

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net



From irwin at beluga.phys.uvic.ca  Thu Dec 14 14:54:05 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 14 Dec 2017 11:54:05 -0800 (PST)
Subject: [CMake] Configuration under CMake 3.10.1 fails but succeeds
 with 3.9.6
In-Reply-To: <D14A0EF1-5D5B-4993-8B08-F551C87D8C42@bluequartz.net>
References: <D14A0EF1-5D5B-4993-8B08-F551C87D8C42@bluequartz.net>
Message-ID: <alpine.DEB.2.11.1712141118410.18536@enira.zlyna.ubzr>

On 2017-12-14 13:51-0500 Michael Jackson wrote:

> I just tried out the latest CMake release 3.10.1 and it fails to configure (from a clean build directory) our project where CMake 3.9.x and below (down to CMake 3.7.x) configures it completely and correctly. The configure error I get is"
>
> -- Configuring done
> CMake Error in /Users/mjackson/Workspace/DREAM3D_Plugins/AskNDEToolbox/Applications/ScanViewer/CMakeLists.txt:
>  Cannot find source file:
>
>    /Users/mjackson/Workspace/DREAM3D-Build/3.10.1/Plugins/AskNDEToolbox/qrc_AskNDEToolbox.cpp
>
>  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
>  .hxx .in .txx
>

> Now, the funny thing about this is that nowhere in the CMakeLists
files for the "ScaneViewer" application should it be adding the
generated qrc_AskNDEToolbox.cpp file. That file is added higher up in
the heirarchy of projects, but not that particular application. Does
anyone have any thoughts on this issue?

Hi Michael:

This is just speculation but I wonder if you are inheriting a property
from higher in the directory tree, that you weren't inheriting before?

By the way, once you solve this, I would recommend for your peace of
mind that you arrange with the CMake developers for a contract test
for your project.  See examples of this in Tests/Contracts in the git
master branch of CMake where such contract tests have already been
enabled for PLplot, Trilinos, and VTK.  The idea of such contracts is
you configure your computer to automatically build and test the staged
version of CMake (the version the CMake developers want to be
thoroughly tested that typically changes from one night to the next). 
And one of those tests is the contract test you configure where you
build some version of your project (that you change from time to time
to some recent well-tested version such as your latest release).

The results of such tests are automatically reported at
<https://open.cdash.org/index.php?project=CMake>.  Note, my recent
"raven" results there demonstrate success for all CMake tests including
"Contracts.PLplot".  Both the PLplot and CMake software projects
benefit from this "contract".  I am assured I get early warning of any
bad interactions between staged CMake changes and the build system for
my software (such as you discovered above), and the CMake developers
get some real build-system testing (as opposed to their usual unit
tests which obviously found no issues with 3.10.1) of the staged version of
CMake that they need to test to evaluate what commits from their
staged version get into the next release.

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 mike at mdb977.de  Fri Dec 15 09:43:04 2017
From: mike at mdb977.de (Mike Bergmann)
Date: Fri, 15 Dec 2017 14:43:04 +0000
Subject: [CMake] Building cmake with CMAKE_FIND_ROOT_PATH - binary
 containing dash within RPATH
Message-ID: <ea5f5c56d6fad8253f7e53a40501bcad@mdb977.de>

I try to build cmake using my own libraries. I configured using:

--system-curl --system-expat --system-zlib --system-bzip2

and modified CMakeLists.txt to include:

SET(CMAKE_FIND_ROOT_PATH /home/mdb/Toco/sdk/bsp/local)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

after building cmake (by using make, building bootstrap cmake, building cmake) I checked the RPATH via:

objdump -x cmake | grep RPATH

and got:

RPATH                -/home/mdb/Toco/sdk/bsp/local/lib:-/home/mdb/Toco/sdk/bsp/local/usr/lib

The (strange?) dash in front of the path is preventing cmake to find the libraries provided in /home/mdb/Toco/sdk/bsp/local/ and the binary is using /lib/x86_64-linux-gnu/ instead.

The same is happening if I use 

set (CMAKE_SYSTEM_LIBRARY_PATH /home/mdb/Toco/sdk/bsp/local/lib)
set (CMAKE_LIBRARY_PATH /home/mdb/Toco/sdk/bsp/local/lib)

within CMakeLists.txt

If I patch the cmake binary using chrpath to contain the path without the dash it seems to work.

What's the dash within the RPATH for?
How do I get rid of this dash?

Thanks a lot

Mike

From hashemi at brandeis.edu  Fri Dec 15 10:39:55 2017
From: hashemi at brandeis.edu (Kevan Hashemi)
Date: Fri, 15 Dec 2017 10:39:55 -0500
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <alpine.DEB.2.11.1712110153080.2797@enira.zlyna.ubzr>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
 <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
 <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>
 <b30aa24d-9747-3f41-da87-bd42456c8843@brandeis.edu>
 <alpine.DEB.2.11.1712110153080.2797@enira.zlyna.ubzr>
Message-ID: <77017d82-0167-bad2-40b5-ff2db14b497e@brandeis.edu>

Dear Alan,

Thank you for your encouragement to use the "MinGW Makefiles" generator on Windows, and for pointing 
out the mingw32-make alternative to just "make" in MSYS.

> So if you are further interested in the "MinGW Makefiles" generator,
> you should remove all sh.exe versions from your PATH (including sh.exe
> provided by raw Windows), get into a CMD environment, execute cmake
> with the "MinGW Makefiles", and then build your software with
> 
> mingw32-make.exe

I installed the latest version of MinGW with MSYS on my 32-bit Windows 7 virtual machine (which is 
running in VMBox on a MacOS 10.12.6 host computer). I open a CMD terminal (DOS prompt). I do not 
move any sh.exe files. I run cmake with -G "MinGW Makefiles" for Executable_A. The configuration and 
generation complete with no errors and only one warning. In the CMD terminal, I use mingw32-make.exe 
to build Executable_A. The executable runs perfectly when linked dynamically to libraries I 
previously built with "MSYS Makefiles".

I repeat the above process, but when it comes to the build itself, I switch from the CMD terminal to 
the MSYS terminal, and use mingw32-make.exe instead of just "make" (as noted previously, "make" 
takes me to an alternate shell with a Microsoft copyright). The build completes and Executable_A 
runs just fine.

I rebuild my libraries with the "MinGW Makefiles" process, staying in the CMD terminal for both 
stages. The CMake completes with a few minor warnings. The CMD build proceeds at about the same 
speed as the MSYS build (you found the CMD build to be faster). When the build completes, I run 
Executable_A linking dynamically to the new set of "MinGW Makefiles" libraries. The executable runs 
perfectly.

Conclusion: Easiest way to get MinGW Makefile generation is to do it in the CMD terminal. After 
that, you make with mingw32-make in eithger CMD or MSYS. Libraries compiled with either process are 
compatible with one another at any stage of compiling or linking.

Yours, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

From d3ck0r at gmail.com  Fri Dec 15 10:49:42 2017
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 15 Dec 2017 07:49:42 -0800
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <77017d82-0167-bad2-40b5-ff2db14b497e@brandeis.edu>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
 <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
 <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>
 <b30aa24d-9747-3f41-da87-bd42456c8843@brandeis.edu>
 <alpine.DEB.2.11.1712110153080.2797@enira.zlyna.ubzr>
 <77017d82-0167-bad2-40b5-ff2db14b497e@brandeis.edu>
Message-ID: <CAA2GJqUMyKRghS41xWTEDGmk+zRYuko6mF5FnPndoM3bPVN3VA@mail.gmail.com>

On Fri, Dec 15, 2017 at 7:39 AM, Kevan Hashemi <hashemi at brandeis.edu> wrote:

> Dear Alan,
>
> Thank you for your encouragement to use the "MinGW Makefiles" generator on
> Windows, and for pointing out the mingw32-make alternative to just "make"
> in MSYS.
>
> So if you are further interested in the "MinGW Makefiles" generator,
>> you should remove all sh.exe versions from your PATH (including sh.exe
>> provided by raw Windows), get into a CMD environment, execute cmake
>> with the "MinGW Makefiles", and then build your software with
>>
>> mingw32-make.exe
>>
>
> I installed the latest version of MinGW with MSYS on my 32-bit Windows 7
> virtual machine (which is running in VMBox on a MacOS 10.12.6 host
> computer). I open a CMD terminal (DOS prompt). I do not move any sh.exe
> files. I run cmake with -G "MinGW Makefiles" for Executable_A. The
> configuration and generation complete with no errors and only one warning.
> In the CMD terminal, I use mingw32-make.exe to build Executable_A. The
> executable runs perfectly when linked dynamically to libraries I previously
> built with "MSYS Makefiles".
>
> I repeat the above process, but when it comes to the build itself, I
> switch from the CMD terminal to the MSYS terminal, and use mingw32-make.exe
> instead of just "make" (as noted previously, "make" takes me to an
> alternate shell with a Microsoft copyright). The build completes and
> Executable_A runs just fine.
>
> I rebuild my libraries with the "MinGW Makefiles" process, staying in the
> CMD terminal for both stages. The CMake completes with a few minor
> warnings. The CMD build proceeds at about the same speed as the MSYS build
> (you found the CMD build to be faster). When the build completes, I run
> Executable_A linking dynamically to the new set of "MinGW Makefiles"
> libraries. The executable runs perfectly.
>
> Conclusion: Easiest way to get MinGW Makefile generation is to do it in
> the CMD terminal. After that, you make with mingw32-make in eithger CMD or
> MSYS. Libraries compiled with either process are compatible with one
> another at any stage of compiling or linking.
>
>
I just want to throw out there, I use MinGW (with MingW Makefiles) wihtout
MSYS just fine for most things.... including OpenCV which I tested first
day and had no issues... but by then others had already commented.    All
that requires is mingw(64).bin and cmake/bin in your path....



> Yours, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://alignment.hep.brandeis.edu/
> --
>
> 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: <http://cmake.org/pipermail/cmake/attachments/20171215/95f2ae80/attachment-0001.html>

From brennonbrimhall at gmail.com  Fri Dec 15 15:24:48 2017
From: brennonbrimhall at gmail.com (Brennon Brimhall)
Date: Fri, 15 Dec 2017 13:24:48 -0700
Subject: [CMake] CMake and RPATH
Message-ID: <03479734-8E9A-4203-A7DA-5597C3F1C0AA@gmail.com>

I'm trying to install OpenCV onto an HPC system.  We're trying to make sure we use RPATH, as it helps our dependency management significantly with our environment modules system.  However, I've not had any success following the documentation available at https://cmake.org/Wiki/CMake_RPATH_handling.  It appears that CMAKE_INSTALL_RPATH_USE_LINK_PATH isn't setting the RPATH properly per the output of `readelf -d`.  It appears that setting that option hasn't been altering the produced RPATH at all.  Is this a known problem?

From cary at txcorp.com  Fri Dec 15 15:29:58 2017
From: cary at txcorp.com (JR Cary)
Date: Fri, 15 Dec 2017 13:29:58 -0700
Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015
In-Reply-To: <df40ece9-ebc2-ab90-9217-56dd29cf4e0a@kitware.com>
References: <467ab9f8-c02e-e1d0-51d7-305b77fdc29f@txcorp.com>
 <229c70f0-112d-ccec-d864-3d61d3c85ecd@txcorp.com>
 <df40ece9-ebc2-ab90-9217-56dd29cf4e0a@kitware.com>
Message-ID: <02359e3c-aafd-5f71-698d-1ecff4374c14@txcorp.com>

Thanks.? All now configures with 3.9.4.

On 12/12/17 5:50 AM, Brad King wrote:
> On 12/11/2017 04:34 PM, John Cary wrote:
>> Bill Hoffman wrote:
>>> LINK: command "xilink ... /out:FortranCInterface.exe ..." failed (exit code 1169)
>>> LIBCMT.lib(winapisupp.obj) : error LNK2005:
>>> __crtSetUnhandledExceptionFilter already defined in MSVCRT.lib(MSVCR120.dll)
>>>
>>> Did you change any of the default compiler/linker flags?  It looks like
>>> it is mixing run time libraries somehow.
>> Yes, we do a replacement of MD with MT as we need fully static builds.
>>
>> We do this early in configuration, using
>>
>> The "Dynamic Replace" method described at
>>
>> https://cmake.org/Wiki/CMake_FAQ#Dynamic_Replace
>>
>> This is possible with 3.8.2.? Is there a way to get that behavior back?
> This is likely due to commit v3.9.0-rc1~144^2~1:
>
> ```
> FortranCInt: Pass CONFIG flags to try_compile
>
> This change ensures that Intel Fortran's /libs: in
> CMAKE_Fortran_FLAGS and Visual C++'s /MT or /MD in the
> CMAKE_C_FLAGS_RELEASE do not conflict with each other.
> ```
>
> With that change I'm able to reproduce the failure with
> VS 2013 and Intel 2016:
>
> ```
> cmake_minimum_required (VERSION 3.7)
> project(Test C Fortran)
> string(REPLACE "/MD" "/MT" CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}")
> include(FortranCInterface)
> FortranCInterface_VERIFY()
> ```
>
> If the project is changing the C and C++ flags to use a static
> runtime library, it should do that for Fortran too:
>
> ```
> string(REPLACE "/libs:dll" "/libs:static" CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS}")
> ```
>
> Adding that line fixes the problem for me.
>
> -Brad
>


From saadrustam at gmail.com  Fri Dec 15 18:18:26 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Fri, 15 Dec 2017 23:18:26 +0000
Subject: [CMake] Installing and exporting multiple configurations of the
 same library
Message-ID: <CAEM70sPjSYCyi0FjTbLdms+NZzP0B4VdWN8QcVa9N+NVkzp7MA@mail.gmail.com>

Hi,

I have 4 configurations (2 for Debug and 2 for Release) and I would like to
install the libraries such that they are installed in the correct
directories.

Installing without worrying about configurations looks like this:

    install(TARGETS ${LIB_NAME}
        EXPORT ${LIB_NAME}Config
        PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
        LIBRARY DESTINATION "bin/${LIB_NAME}/"
        ARCHIVE DESTINATION "lib/${LIB_NAME}/"
        )

However, different configurations overwrite the binaries. So instead, I did
something like this (I'm going over all my configurations in a foreach):

    install(TARGETS ${LIB_NAME}
        CONFIGURATIONS DEBUG
        EXPORT ${LIB_NAME}Config
        PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
        LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
        ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
        )

    install(TARGETS ${LIB_NAME}
        CONFIGURATIONS RELEASE
        EXPORT ${LIB_NAME}Config
        PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
        LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
        ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
        )

however, that results in the error:
CMake Error: INSTALL(EXPORT ...) includes target "MyLibrary" more than once
in the export set.

The error makes sense, in that I cannot have multiple exports in the same
export set, in this case ${LIB_NAME}Config. However, I would like CMake to
choose a different directory based on the configuration.

Now there is a workaround... sort of. I could name the binaries based on
the configuration but that doesn't work with our existing build systems. We
want the following:

lib/${LIB_NAME}/${CONFIG}/libname

Any way to get CMake to install the libraries this way?

Thank you,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171215/d464db7d/attachment.html>

From craig.scott at crascit.com  Fri Dec 15 18:24:19 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 16 Dec 2017 10:24:19 +1100
Subject: [CMake] Using SET_TARGET_PROPERTIES and
 IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
 <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
 <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>
Message-ID: <CA+dygYk-8f8x4_Fq_gAHYu=p29CrN7TVgF1Yxeg1M_Sipm8u-w@mail.gmail.com>

On Thu, Dec 14, 2017 at 7:40 PM, CHEVRIER, Marc <marc.chevrier at sap.com>
wrote:

> I think you can fill a bug about erroneous behaviour when a list is
> specified with command set_target_properties for property
> IMPORTED_LINK_INTERFACE_LIBRARIES.
>

You can set multiple properties with set_target_properties() and you are
allowed to define your own property names, so CMake could never know for
sure if you are defining a list for one property or defining multiple
properties.




>
>
> Another way to specify the property is to use command set_property which
> supports multiple values for a property:
>
> set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA
> LibB)
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Saad Khattak <
> saadrustam at gmail.com>
> *Date: *Thursday 14 December 2017 at 03:20
> *To: *Craig Scott <craig.scott at crascit.com>
> *Cc: *Cmake Mailing List <cmake at cmake.org>
> *Subject: *Re: [CMake] Using SET_TARGET_PROPERTIES and
> IMPORTED_LINK_INTERFACE_LIBRARIES
>
>
>
> Thanks Craig for your reply.
>
>
>
> The issue is that both "LibA" and "LibB" have been set using
> "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
> both have some properties that are being set.
>
>
>
> Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
> they have their own include and link directories and other library
> dependencies.
>
>
>
> The nice thing about using LibA directly is then LibD inherits all the
> include and link directories of LibA and LibB which then get inherited by
> any library or executable that includes LibD (and ultimately, the whole
> point of modern CMake):
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
> IMPORTED CMake libraries
>
> )
>
>
>
> If I use "LibA;LibB" then first, I have to manually extract the library
> names of the imported CMake libraries LibA and LibB. Then, I have to call
> "target_include_directories" and "target_link_libraries" for all
> dependencies of LibA and LibB, even though these dependencies were defined
> in their own respective CMake files when calling "add_library(LibA STATIC
> IMPORTED)"
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
> recognizes LibA and LibB as IMPORTED CMake libraries
>
> )
>
>
>
> Regards,
>
> Saad
>
>
>
> On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
> Hi,
>
>
>
> I have several imported libraries:
>
>
>
> LibA
>
> LibB
>
> LibC
>
>
>
> Where each imported library has been populated by (where ${LIB_NAME} is
> either LibA, LibB or LibC):
>
>
>
> add_library(${LIB_NAME} STATIC IMPORTED)
>
>
>
> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
> properly:
>
>
>
> set_target_properties(${LIB_NAME}
>
>     PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>
>    "location/of/library.lib"
>
>     )
>
>
>
> Now let's say I have another imported library LibD that depends on LibA
> and LibB such that any executable that uses LibD must also link with LibA
> and LibB. To do that, I use:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>
>   )
>
>
>
> You probably want this instead:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
>
> )
>
>
>
> Note that if the property value is a list, you have to provide it as a
> single string (i.e. "LibA;LibB" rather than LibA LibB)
>
>
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>


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

From saadrustam at gmail.com  Fri Dec 15 18:39:27 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Fri, 15 Dec 2017 23:39:27 +0000
Subject: [CMake] Using SET_TARGET_PROPERTIES and
 IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
 <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
 <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>
Message-ID: <CAEM70sMFfc=1d6nAuS1UQmQk=ht6Nqz3akNcLsiHEwuDXZu+Rg@mail.gmail.com>

Thank you Marc. I found that the following also works:

target_link_libraries(LibD INTERFACE LibA LibB)

However, my guess is that in the future the above may break as it is
assuming LibD is an INTERFACE instead of an IMPORTED library. I'll switch
to your version instead as it seems to be more correct.

On Thu, Dec 14, 2017 at 3:40 AM CHEVRIER, Marc <marc.chevrier at sap.com>
wrote:

> I think you can fill a bug about erroneous behaviour when a list is
> specified with command set_target_properties for property
> IMPORTED_LINK_INTERFACE_LIBRARIES.
>
>
>
> Another way to specify the property is to use command set_property which
> supports multiple values for a property:
>
> set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA
> LibB)
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Saad Khattak <
> saadrustam at gmail.com>
> *Date: *Thursday 14 December 2017 at 03:20
> *To: *Craig Scott <craig.scott at crascit.com>
> *Cc: *Cmake Mailing List <cmake at cmake.org>
> *Subject: *Re: [CMake] Using SET_TARGET_PROPERTIES and
> IMPORTED_LINK_INTERFACE_LIBRARIES
>
>
>
> Thanks Craig for your reply.
>
>
>
> The issue is that both "LibA" and "LibB" have been set using
> "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
> both have some properties that are being set.
>
>
>
> Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
> they have their own include and link directories and other library
> dependencies.
>
>
>
> The nice thing about using LibA directly is then LibD inherits all the
> include and link directories of LibA and LibB which then get inherited by
> any library or executable that includes LibD (and ultimately, the whole
> point of modern CMake):
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
> IMPORTED CMake libraries
>
> )
>
>
>
> If I use "LibA;LibB" then first, I have to manually extract the library
> names of the imported CMake libraries LibA and LibB. Then, I have to call
> "target_include_directories" and "target_link_libraries" for all
> dependencies of LibA and LibB, even though these dependencies were defined
> in their own respective CMake files when calling "add_library(LibA STATIC
> IMPORTED)"
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
> recognizes LibA and LibB as IMPORTED CMake libraries
>
> )
>
>
>
> Regards,
>
> Saad
>
>
>
> On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
> Hi,
>
>
>
> I have several imported libraries:
>
>
>
> LibA
>
> LibB
>
> LibC
>
>
>
> Where each imported library has been populated by (where ${LIB_NAME} is
> either LibA, LibB or LibC):
>
>
>
> add_library(${LIB_NAME} STATIC IMPORTED)
>
>
>
> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
> properly:
>
>
>
> set_target_properties(${LIB_NAME}
>
>     PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>
>    "location/of/library.lib"
>
>     )
>
>
>
> Now let's say I have another imported library LibD that depends on LibA
> and LibB such that any executable that uses LibD must also link with LibA
> and LibB. To do that, I use:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>
>   )
>
>
>
> You probably want this instead:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
>
> )
>
>
>
> Note that if the property value is a list, you have to provide it as a
> single string (i.e. "LibA;LibB" rather than LibA LibB)
>
>
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171215/4c4b1d08/attachment.html>

From ajay.panyala at gmail.com  Fri Dec 15 21:25:52 2017
From: ajay.panyala at gmail.com (Ajay Panyala)
Date: Fri, 15 Dec 2017 18:25:52 -0800
Subject: [CMake] cuda_wrap_srcs error
Message-ID: <CALgJuApaG6QkPfbU85O18M+_t5_mLR_Krh=ep-zT+n+jdONfxw@mail.gmail.com>

Hello,

I am trying to compile a simple cuda program to an object file with
"cuda_wrap_srcs" using the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.7 FATAL_ERROR)
> project (TEST C CXX)
> include(FindCUDA)
> cuda_wrap_srcs(hello OBJ hello_test hello-world.cu OPTIONS -O3)


*I see the following error: *https://paste.ee/p/8XaH1

I am not sure what I am missing in the call to cuda_wrap_srcs.

Thanks
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171215/1677c38c/attachment.html>

From saadrustam at gmail.com  Sat Dec 16 11:15:31 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Sat, 16 Dec 2017 16:15:31 +0000
Subject: [CMake] CMake skip unnecessary compiler checks
Message-ID: <CAEM70sM+j1gUtTPoHX-D_A85WbQDNGHNE1as+f=anXFFeGwiTQ@mail.gmail.com>

Hi,

We have about a hundred projects that use CMake to do the compilation. Each
night, we do a clean build and CMake performs unnecessary compiler checks
for every single project:

-- The C compiler identification is MSVC 17.0.61030.0
-- The CXX compiler identification is MSVC 17.0.61030.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_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 11.0/VC/bin/x86_amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: xxxxx

Now I can understand if CMake needs to do it once, but when it does this
100 times, the build slows down a few seconds per project for no reason
especially when we know, after the first project generation, that things
are working.

Using the workaround "project(myProj NONE)" is not good because it has
other side effects. I would like CMake to cache the result of the above
checks somehow for subsequent projects.

Also, just as an FYI for anyone on Linux, CMake's compiler identification
and checking for a working compiler works almost instantaneously on Linux
(e.g. trying the same on Linux will start the generation process pretty
much instantaneously). On Windows this takes a while (about 8 seconds). Not
sure why there is a big discrepancy in the way the compilers are identified
and checked.

Thank you,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171216/a82a0e29/attachment.html>

From domen.vrankar at gmail.com  Sat Dec 16 14:56:11 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Sat, 16 Dec 2017 20:56:11 +0100
Subject: [CMake] Installing and exporting multiple configurations of the
 same library
In-Reply-To: <CAEM70sPjSYCyi0FjTbLdms+NZzP0B4VdWN8QcVa9N+NVkzp7MA@mail.gmail.com>
References: <CAEM70sPjSYCyi0FjTbLdms+NZzP0B4VdWN8QcVa9N+NVkzp7MA@mail.gmail.com>
Message-ID: <CAKgx6BJrY+pi3=kBd=VG47CQqkMPP0YXyUrJ-GFsC6HWz0R=tQ@mail.gmail.com>

2017-12-16 0:18 GMT+01:00 Saad Khattak <saadrustam at gmail.com>:

> Hi,
>
> I have 4 configurations (2 for Debug and 2 for Release) and I would like
> to install the libraries such that they are installed in the correct
> directories.
>
> Installing without worrying about configurations looks like this:
>
>     install(TARGETS ${LIB_NAME}
>         EXPORT ${LIB_NAME}Config
>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>         LIBRARY DESTINATION "bin/${LIB_NAME}/"
>         ARCHIVE DESTINATION "lib/${LIB_NAME}/"
>         )
>
> However, different configurations overwrite the binaries. So instead, I
> did something like this (I'm going over all my configurations in a foreach):
>
>     install(TARGETS ${LIB_NAME}
>         CONFIGURATIONS DEBUG
>         EXPORT ${LIB_NAME}Config
>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>         LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
>         ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
>         )
>
>     install(TARGETS ${LIB_NAME}
>         CONFIGURATIONS RELEASE
>         EXPORT ${LIB_NAME}Config
>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>         LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
>         ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
>         )
>
> however, that results in the error:
> CMake Error: INSTALL(EXPORT ...) includes target "MyLibrary" more than
> once in the export set.
>
> The error makes sense, in that I cannot have multiple exports in the same
> export set, in this case ${LIB_NAME}Config. However, I would like CMake to
> choose a different directory based on the configuration.
>

A simple solution would be to write

    install(TARGETS ${LIB_NAME}
        CONFIGURATIONS DEBUG
        EXPORT ${LIB_NAME}Config-d
        PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
        LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
        ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
        )

    install(TARGETS ${LIB_NAME}
        CONFIGURATIONS RELEASE
        EXPORT ${LIB_NAME}Config
        PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
        LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
        ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
        )

and then use FILE parameter for install(EXPORT ... FILE
${LIB_NAME}Config.cmake ...) command to rename the file from
${LIB_NAME}Config-d.cmake to ${LIB_NAME}Config.cmake.

See here for details:
https://cmake.org/cmake/help/latest/command/install.html#installing-exports.

Also one thing that you can do is set:

set(CMAKE_DEBUG_POSTFIX "-debug")

so that your libraries when built in Debug mode will automatically get
-debug suffix (example: my_lib.so for Release and my_lib-debug.so for
debug). This way you don't need to install the library in two separate sub
directories (named debug/ and release/ in your case).


> Now there is a workaround... sort of. I could name the binaries based on
> the configuration but that doesn't work with our existing build systems. We
> want the following:
>
> lib/${LIB_NAME}/${CONFIG}/libname
>
> Any way to get CMake to install the libraries this way?
>

Not certain what the intended way of doing this debug/releas export on
Linux is as you can only build one build type at a time but the
install(EXPORT ...) command already generates:
${LIB_NAME}Config.cmake and ${LIB_NAME}Config-debug.cmake or
${LIB_NAME}Config-release.cmake

If you install the files in two separate directories and diff them you'll
notice that ${LIB_NAME}Config.cmake files (and Version files if you
generate one) are the same and -debug.cmake and -release.cmake differ so
possibly it's intended to simply override the two files and don't care
about it since the build specific files are exported under different names
and included automatically in ${LIB_NAME}Config.cmake file anyway.

I hope somebody else will shed some light on this part.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171216/aa323f6e/attachment.html>

From hashemi at brandeis.edu  Sat Dec 16 22:17:04 2017
From: hashemi at brandeis.edu (Kevan Hashemi)
Date: Sat, 16 Dec 2017 22:17:04 -0500
Subject: [CMake] MinGW Compilers on Windows
In-Reply-To: <CAA2GJqUMyKRghS41xWTEDGmk+zRYuko6mF5FnPndoM3bPVN3VA@mail.gmail.com>
References: <26f14cf3-0b46-c8f7-4814-1ad179442ea7@brandeis.edu>
 <4651711512760675@web57j.yandex.ru>
 <0a663b3e-7c73-117b-587b-1befe30ee1d0@brandeis.edu>
 <alpine.DEB.2.11.1712081227190.2797@enira.zlyna.ubzr>
 <b30aa24d-9747-3f41-da87-bd42456c8843@brandeis.edu>
 <alpine.DEB.2.11.1712110153080.2797@enira.zlyna.ubzr>
 <77017d82-0167-bad2-40b5-ff2db14b497e@brandeis.edu>
 <CAA2GJqUMyKRghS41xWTEDGmk+zRYuko6mF5FnPndoM3bPVN3VA@mail.gmail.com>
Message-ID: <645d4a52-fd8a-0630-11ed-e597eed7c07a@brandeis.edu>

> I just want to throw out there, I use MinGW (with MingW Makefiles) wihtout
> MSYS just fine for most things.... including OpenCV which I tested first
> day and had no issues... but by then others had already commented.    All
> that requires is mingw(64).bin and cmake/bin in your path....

Thank you, that's reassuring. I have not started on the 64-bit build yet. Kevan


-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

From saadrustam at gmail.com  Sun Dec 17 16:29:24 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Sun, 17 Dec 2017 21:29:24 +0000
Subject: [CMake] Installing and exporting multiple configurations of the
 same library
In-Reply-To: <CAKgx6BJrY+pi3=kBd=VG47CQqkMPP0YXyUrJ-GFsC6HWz0R=tQ@mail.gmail.com>
References: <CAEM70sPjSYCyi0FjTbLdms+NZzP0B4VdWN8QcVa9N+NVkzp7MA@mail.gmail.com>
 <CAKgx6BJrY+pi3=kBd=VG47CQqkMPP0YXyUrJ-GFsC6HWz0R=tQ@mail.gmail.com>
Message-ID: <CAEM70sMj8FfrGuLmRR1ep6dGu73yhBWok7_buK1o+7rpTMpJiw@mail.gmail.com>

Thank you Domen for the workaround. With the workaround I'll have to pick
the correct CMake config file by directory. I was hoping for one
${LIB_NAME}Config.cmake file for all configurations.

I did indeed set the postfix, however our current build requirements (since
we have a mix of CMake and non-CMake enabled projects) dictate the specific
folder structure. Otherwise, I would be fine with the configuration postfix.

The main reason for the directory structure is to allow existing projects
to work while getting the newer projects to rely on CMake.

On Sat, Dec 16, 2017 at 2:56 PM Domen Vrankar <domen.vrankar at gmail.com>
wrote:

> 2017-12-16 0:18 GMT+01:00 Saad Khattak <saadrustam at gmail.com>:
>
>> Hi,
>>
>> I have 4 configurations (2 for Debug and 2 for Release) and I would like
>> to install the libraries such that they are installed in the correct
>> directories.
>>
>> Installing without worrying about configurations looks like this:
>>
>>     install(TARGETS ${LIB_NAME}
>>         EXPORT ${LIB_NAME}Config
>>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>>         LIBRARY DESTINATION "bin/${LIB_NAME}/"
>>         ARCHIVE DESTINATION "lib/${LIB_NAME}/"
>>         )
>>
>> However, different configurations overwrite the binaries. So instead, I
>> did something like this (I'm going over all my configurations in a foreach):
>>
>>     install(TARGETS ${LIB_NAME}
>>         CONFIGURATIONS DEBUG
>>         EXPORT ${LIB_NAME}Config
>>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>>         LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
>>         ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
>>         )
>>
>>     install(TARGETS ${LIB_NAME}
>>         CONFIGURATIONS RELEASE
>>         EXPORT ${LIB_NAME}Config
>>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>>         LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
>>         ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
>>         )
>>
>> however, that results in the error:
>> CMake Error: INSTALL(EXPORT ...) includes target "MyLibrary" more than
>> once in the export set.
>>
>> The error makes sense, in that I cannot have multiple exports in the same
>> export set, in this case ${LIB_NAME}Config. However, I would like CMake to
>> choose a different directory based on the configuration.
>>
>
> A simple solution would be to write
>
>     install(TARGETS ${LIB_NAME}
>         CONFIGURATIONS DEBUG
>         EXPORT ${LIB_NAME}Config-d
>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>         LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
>         ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
>         )
>     install(TARGETS ${LIB_NAME}
>         CONFIGURATIONS RELEASE
>         EXPORT ${LIB_NAME}Config
>         PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>         LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
>         ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
>         )
>
> and then use FILE parameter for install(EXPORT ... FILE
> ${LIB_NAME}Config.cmake ...) command to rename the file from
> ${LIB_NAME}Config-d.cmake to ${LIB_NAME}Config.cmake.
>
> See here for details:
> https://cmake.org/cmake/help/latest/command/install.html#installing-exports
> .
>
> Also one thing that you can do is set:
>
> set(CMAKE_DEBUG_POSTFIX "-debug")
>
> so that your libraries when built in Debug mode will automatically get
> -debug suffix (example: my_lib.so for Release and my_lib-debug.so for
> debug). This way you don't need to install the library in two separate sub
> directories (named debug/ and release/ in your case).
>
>
>> Now there is a workaround... sort of. I could name the binaries based on
>> the configuration but that doesn't work with our existing build systems. We
>> want the following:
>>
>> lib/${LIB_NAME}/${CONFIG}/libname
>>
>> Any way to get CMake to install the libraries this way?
>>
>
> Not certain what the intended way of doing this debug/releas export on
> Linux is as you can only build one build type at a time but the
> install(EXPORT ...) command already generates:
> ${LIB_NAME}Config.cmake and ${LIB_NAME}Config-debug.cmake or
> ${LIB_NAME}Config-release.cmake
>
> If you install the files in two separate directories and diff them you'll
> notice that ${LIB_NAME}Config.cmake files (and Version files if you
> generate one) are the same and -debug.cmake and -release.cmake differ so
> possibly it's intended to simply override the two files and don't care
> about it since the build specific files are exported under different names
> and included automatically in ${LIB_NAME}Config.cmake file anyway.
>
> I hope somebody else will shed some light on this part.
>
> Regards,
> Domen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171217/2d08ee81/attachment.html>

From kevinushey at gmail.com  Sun Dec 17 16:37:44 2017
From: kevinushey at gmail.com (Kevin Ushey)
Date: Sun, 17 Dec 2017 13:37:44 -0800
Subject: [CMake] Working directory for install-time CMake scripts?
Message-ID: <CAJXgQP3_EWCS_DsRV8QiwmMgiiOhVTA-42ss7fGQnQEMEo_ApA@mail.gmail.com>

Hi,

It's possible to request a CMake script to be run at installation time,
with e.g.

    install(SCRIPT <script>.cmake)

I think this is most commonly used for fixing up bundles generating during
install time (e.g. rpath munging or other muckery). Within such a script,
I'd like to execute a shell script that does the heavy lifting, e.g. within
the above script I might have:

    execute_process(COMMAND sh <script>.sh)

I'd like to have this bash script run within the install directory. It
seems like one can get this directory with e.g.

    $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}

but this sort of usage seems somewhat thinly documented.
https://cmake.org/cmake/help/v3.10/variable/CMAKE_INSTALL_PREFIX.html
suggests DESTDIR can be used when one is using 'make' to build the project,
but I'm guessing this may not be portable to other generators. For example,
NSIS suggests that the following build directory is used (
https://cmake.org/Wiki/CMake:CPackNSISAdvancedTips):


${CMAKE_BINARY_DIR}\_CPack_Packages\${CPACK_TOPLEVEL_TAG}\${CPACK_GENERATOR}\

For what it's worth, I'm trying this out on Linux when using CPack to
generate DEB/RPM packages, and all seems well so far, but I suspect there
may be a simpler, or more idiomatic, way to accomplish what I'm trying to
do.

tl;dr: Is there a portable way to get the path to the directory being used
during the install phase? Or do I need to rethink the way I'm approaching
this?

Thanks,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171217/03219e5b/attachment.html>

From marc.chevrier at sap.com  Mon Dec 18 03:06:45 2017
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Mon, 18 Dec 2017 08:06:45 +0000
Subject: [CMake] Using SET_TARGET_PROPERTIES and
 IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <CAEM70sMFfc=1d6nAuS1UQmQk=ht6Nqz3akNcLsiHEwuDXZu+Rg@mail.gmail.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
 <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
 <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>
 <CAEM70sMFfc=1d6nAuS1UQmQk=ht6Nqz3akNcLsiHEwuDXZu+Rg@mail.gmail.com>
Message-ID: <C87642E7-1E7D-4E3F-A71B-4AC28BD0AB1A@sap.com>

Hi,

Your assumption is erroneous. INTERFACE keyword is related to dependencies behavior against target (see target_link_libraries<https://cmake.org/cmake/help/git-master/command/target_link_libraries.html> documentation). It do not specify type of target, so IMPORTED libraries will work as well.


From: Saad Khattak <saadrustam at gmail.com>
Date: Saturday 16 December 2017 at 00:39
To: "CHEVRIER, Marc" <marc.chevrier at sap.com>
Cc: Craig Scott <craig.scott at crascit.com>, Cmake Mailing List <cmake at cmake.org>
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

Thank you Marc. I found that the following also works:

target_link_libraries(LibD INTERFACE LibA LibB)

However, my guess is that in the future the above may break as it is assuming LibD is an INTERFACE instead of an IMPORTED library. I'll switch to your version instead as it seems to be more correct.

On Thu, Dec 14, 2017 at 3:40 AM CHEVRIER, Marc <marc.chevrier at sap.com<mailto:marc.chevrier at sap.com>> wrote:
I think you can fill a bug about erroneous behaviour when a list is specified with command set_target_properties for property IMPORTED_LINK_INTERFACE_LIBRARIES.

Another way to specify the property is to use command set_property which supports multiple values for a property:
set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB)


From: CMake <cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>> on behalf of Saad Khattak <saadrustam at gmail.com<mailto:saadrustam at gmail.com>>
Date: Thursday 14 December 2017 at 03:20
To: Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>>
Cc: Cmake Mailing List <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and both have some properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and they have their own include and link directories and other library dependencies.

The nice thing about using LibA directly is then LibD inherits all the include and link directories of LibA and LibB which then get inherited by any library or executable that includes LibD (and ultimately, the whole point of modern CMake):

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as IMPORTED CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library names of the imported CMake libraries LibA and LibB. Then, I have to call "target_include_directories" and "target_link_libraries" for all dependencies of LibA and LibB, even though these dependencies were defined in their own respective CMake files when calling "add_library(LibA STATIC IMPORTED)"

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer recognizes LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>> wrote:
On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com<mailto:saadrustam at gmail.com>> wrote:
Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is either LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set properly:

set_target_properties(${LIB_NAME}
    PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
    )

Now let's say I have another imported library LibD that depends on LibA and LibB such that any executable that uses LibD must also link with LibA and LibB. To do that, I use:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

You probably want this instead:

set_target_properties(LibD
  PROPERTIES
    IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
)

Note that if the property value is a list, you have to provide it as a single string (i.e. "LibA;LibB" rather than LibA LibB)



--
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171218/34818d89/attachment-0001.html>

From saadrustam at gmail.com  Mon Dec 18 08:47:09 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Mon, 18 Dec 2017 13:47:09 +0000
Subject: [CMake] Using SET_TARGET_PROPERTIES and
 IMPORTED_LINK_INTERFACE_LIBRARIES
In-Reply-To: <C87642E7-1E7D-4E3F-A71B-4AC28BD0AB1A@sap.com>
References: <CAEM70sMNLswhRMPfkceDB7DgO2+tzFc2d-A+6b0d1S6i+8FHcw@mail.gmail.com>
 <CA+dygYnug1TmV4BJ+Gqn302Kt_zt7YxpYZzQDkU+ocZ+AyP_Ng@mail.gmail.com>
 <CAEM70sNuRd5saPPU4Xe50JHdqF1A3qqAOs6UO2wDhPvnMV7DSw@mail.gmail.com>
 <16ED6236-BEFA-441C-8298-91F9A334A9CC@sap.com>
 <CAEM70sMFfc=1d6nAuS1UQmQk=ht6Nqz3akNcLsiHEwuDXZu+Rg@mail.gmail.com>
 <C87642E7-1E7D-4E3F-A71B-4AC28BD0AB1A@sap.com>
Message-ID: <CAEM70sOfZGf3=7nYJ2GoSLvhAVnhHhQ4v--dNYZd8p8-b0_e4g@mail.gmail.com>

Thank you for clearing that up Marc! I'll continue to use
target_link_libraries (... INTERFACE ...) for imported libraries.

On Mon, Dec 18, 2017 at 3:06 AM CHEVRIER, Marc <marc.chevrier at sap.com>
wrote:

> Hi,
>
>
>
> Your assumption is erroneous. INTERFACE keyword is related to dependencies
> behavior against target (see target_link_libraries
> <https://cmake.org/cmake/help/git-master/command/target_link_libraries.html>
> documentation). It do not specify type of target, so IMPORTED libraries
> will work as well.
>
>
>
>
>
> *From: *Saad Khattak <saadrustam at gmail.com>
> *Date: *Saturday 16 December 2017 at 00:39
> *To: *"CHEVRIER, Marc" <marc.chevrier at sap.com>
> *Cc: *Craig Scott <craig.scott at crascit.com>, Cmake Mailing List <
> cmake at cmake.org>
>
>
> *Subject: *Re: [CMake] Using SET_TARGET_PROPERTIES and
> IMPORTED_LINK_INTERFACE_LIBRARIES
>
>
>
> Thank you Marc. I found that the following also works:
>
>
>
> target_link_libraries(LibD INTERFACE LibA LibB)
>
>
>
> However, my guess is that in the future the above may break as it is
> assuming LibD is an INTERFACE instead of an IMPORTED library. I'll switch
> to your version instead as it seems to be more correct.
>
>
>
> On Thu, Dec 14, 2017 at 3:40 AM CHEVRIER, Marc <marc.chevrier at sap.com>
> wrote:
>
> I think you can fill a bug about erroneous behaviour when a list is
> specified with command set_target_properties for property
> IMPORTED_LINK_INTERFACE_LIBRARIES.
>
>
>
> Another way to specify the property is to use command set_property which
> supports multiple values for a property:
>
> set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA
> LibB)
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Saad Khattak <
> saadrustam at gmail.com>
> *Date: *Thursday 14 December 2017 at 03:20
> *To: *Craig Scott <craig.scott at crascit.com>
> *Cc: *Cmake Mailing List <cmake at cmake.org>
> *Subject: *Re: [CMake] Using SET_TARGET_PROPERTIES and
> IMPORTED_LINK_INTERFACE_LIBRARIES
>
>
>
> Thanks Craig for your reply.
>
>
>
> The issue is that both "LibA" and "LibB" have been set using
> "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
> both have some properties that are being set.
>
>
>
> Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
> they have their own include and link directories and other library
> dependencies.
>
>
>
> The nice thing about using LibA directly is then LibD inherits all the
> include and link directories of LibA and LibB which then get inherited by
> any library or executable that includes LibD (and ultimately, the whole
> point of modern CMake):
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
> IMPORTED CMake libraries
>
> )
>
>
>
> If I use "LibA;LibB" then first, I have to manually extract the library
> names of the imported CMake libraries LibA and LibB. Then, I have to call
> "target_include_directories" and "target_link_libraries" for all
> dependencies of LibA and LibB, even though these dependencies were defined
> in their own respective CMake files when calling "add_library(LibA STATIC
> IMPORTED)"
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
> recognizes LibA and LibB as IMPORTED CMake libraries
>
> )
>
>
>
> Regards,
>
> Saad
>
>
>
> On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrustam at gmail.com>
> wrote:
>
> Hi,
>
>
>
> I have several imported libraries:
>
>
>
> LibA
>
> LibB
>
> LibC
>
>
>
> Where each imported library has been populated by (where ${LIB_NAME} is
> either LibA, LibB or LibC):
>
>
>
> add_library(${LIB_NAME} STATIC IMPORTED)
>
>
>
> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
> properly:
>
>
>
> set_target_properties(${LIB_NAME}
>
>     PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>
>    "location/of/library.lib"
>
>     )
>
>
>
> Now let's say I have another imported library LibD that depends on LibA
> and LibB such that any executable that uses LibD must also link with LibA
> and LibB. To do that, I use:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>
>   )
>
>
>
> You probably want this instead:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
>     IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
>
> )
>
>
>
> Note that if the property value is a list, you have to provide it as a
> single string (i.e. "LibA;LibB" rather than LibA LibB)
>
>
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171218/5c03c698/attachment.html>

From sam.lunt at transmarketgroup.com  Mon Dec 18 11:26:04 2017
From: sam.lunt at transmarketgroup.com (Sam Lunt)
Date: Mon, 18 Dec 2017 10:26:04 -0600
Subject: [CMake] Fwd: Per-Component value for CPACK_PACKAGING_INSTALL_PREFIX
 with RPM Generator
In-Reply-To: <CADjN2kc_bt+qOg35wrRk_NsZwAqcKoXMgtRX1ySwuLWoW+0-AA@mail.gmail.com>
References: <CADjN2kc_bt+qOg35wrRk_NsZwAqcKoXMgtRX1ySwuLWoW+0-AA@mail.gmail.com>
Message-ID: <CADjN2kc58u=7qLeDDXCO9CMgCV_eqLzZ8FsNZ+6JCQHn=XLepQ@mail.gmail.com>

I am trying to set a per-component value for
CPACK_PACKAGING_INSTALL_PREFIX when using the RPM generator, but I'm
not having any success.

The CMake documentation for CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX says
that "May be used to set per component CPACK_PACKAGING_INSTALL_PREFIX
for relocatable RPM packages." However, this doesn't seem to be the
case (though I may be misunderstanding something).

Here is a simple CMakeLists that demonstrates the problem:

    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/foobar")

    set(CPACK_RPM_COMPONENT_INSTALL ON)
    #set(CPACK_RPM_FOO_COMP_PACKAGE_PREFIX "/tmp/foo")
    #set(CPACK_RPM_BAR_COMP_PACKAGE_PREFIX "/tmp/bar")

    set(CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION "/tmp")

    include(CPack)

As is, the example works fine: when the target install is built, the
executables are installed to
${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}, and when the RPM is
generated and used to install the files, they go to
${CPACK_PACKAGING_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}.
Importantly, the RPM is relocatable (i.e. --prefix and --relocate are
no longer supported with the rpm command).

The issue is when the commented-out lines are uncommented. Instead of
installing each component to its respective packaging prefix, they are
still installed using CPACK_PACKAGING_INSTALL_PREFIX, but now they are
no longer relocatable.

If the install commands are changed to:

    install(TARGETS foo
        DESTINATION "/tmp/foo/${CMAKE_INSTALL_BINDIR}"
        COMPONENT Foo_Comp
    )

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

then the packages are relocatable and RPM installs them as expected,
but CMAKE_INSTALL_PREFIX no longer works correctly.

Is there a way that I can have relocatable RPMs with different
per-component packaging install prefix without breaking the install
target?

Thanks in advance for any help.

From test35965 at gmail.com  Mon Dec 18 19:14:40 2017
From: test35965 at gmail.com (Alexander G. Riccio)
Date: Mon, 18 Dec 2017 19:14:40 -0500
Subject: [CMake] Ubuntu package versioning
Message-ID: <CAN3N+znfO5vv=g+HboHUVZU9FgP-o5eck_ibWudJ7T3MaxTNug@mail.gmail.com>

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.


Sincerely,
Alexander Riccio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171218/3639790e/attachment.html>

From irwin at beluga.phys.uvic.ca  Mon Dec 18 22:39:44 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 18 Dec 2017 19:39:44 -0800 (PST)
Subject: [CMake] Ubuntu package versioning
In-Reply-To: <CAN3N+znfO5vv=g+HboHUVZU9FgP-o5eck_ibWudJ7T3MaxTNug@mail.gmail.com>
References: <CAN3N+znfO5vv=g+HboHUVZU9FgP-o5eck_ibWudJ7T3MaxTNug@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1712181907020.18536@enira.zlyna.ubzr>

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.

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 rwan.work at gmail.com  Mon Dec 18 22:45:04 2017
From: rwan.work at gmail.com (Raymond Wan)
Date: Tue, 19 Dec 2017 11:45:04 +0800
Subject: [CMake] Ubuntu package versioning
In-Reply-To: <alpine.DEB.2.11.1712181907020.18536@enira.zlyna.ubzr>
References: <CAN3N+znfO5vv=g+HboHUVZU9FgP-o5eck_ibWudJ7T3MaxTNug@mail.gmail.com>
 <alpine.DEB.2.11.1712181907020.18536@enira.zlyna.ubzr>
Message-ID: <CAH8UK3Wtp8UyA34w-Fa1hUkGYcQa5KaNRxroiBnLZFvqDYhCDQ@mail.gmail.com>

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

Ray

From test35965 at gmail.com  Mon Dec 18 22:51:23 2017
From: test35965 at gmail.com (Alexander G. Riccio)
Date: Mon, 18 Dec 2017 22:51:23 -0500
Subject: [CMake] Ubuntu package versioning
In-Reply-To: <alpine.DEB.2.11.1712181907020.18536@enira.zlyna.ubzr>
References: <CAN3N+znfO5vv=g+HboHUVZU9FgP-o5eck_ibWudJ7T3MaxTNug@mail.gmail.com>
 <alpine.DEB.2.11.1712181907020.18536@enira.zlyna.ubzr>
Message-ID: <CAN3N+znQwSsigdp4RevbEtPfhSrxVzM0NjHsN_gs4FMo2kR_AQ@mail.gmail.com>

Uggh, it's an LTS thing? Yeah, well then it's my fault entirely. Maybe I
shouldn't've gone for the LTS install.

And yeah, I've already installed the most recent version.

On Dec 18, 2017 10:39 PM, "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.
>
> 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
> __________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171218/d39bf77c/attachment.html>

From kris.f.thielemans at gmail.com  Tue Dec 19 03:14:32 2017
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Tue, 19 Dec 2017 08:14:32 -0000
Subject: [CMake] downloading ftp URL problems
Message-ID: <033201d378a1$66df89f0$349e9dd0$@gmail.com>

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: <http://cmake.org/pipermail/cmake/attachments/20171219/0874afc1/attachment-0001.html>

From gblues+cmake at gmail.com  Tue Dec 19 11:48:52 2017
From: gblues+cmake at gmail.com (Nathan Strong)
Date: Tue, 19 Dec 2017 08:48:52 -0800
Subject: [CMake] Bootstrap fails to detect C++11 compiler on AIX 7.1/XL C
 13.1.3 toolset
Message-ID: <CALUrYo=NaoUtsc07eQh7LyDPL+D_nmiB7zP5NVr_C6FxsEXQvw@mail.gmail.com>

I am having difficulty building CMake on AIX 7.1 using IBM XL C 13.1.3,
which seems to be the newest version as of April 2017.

The bootstrap script fails with the following error:

---------------------------------------------
CMake 3.10.1, Copyright 2000-2017 Kitware, Inc. and Contributors
Found XL toolchain
C compiler on this system is: xlc
---------------------------------------------
Error when bootstrapping CMake:
Cannot find a C++ compiler supporting C++11 on this system.
Please specify one using environment variable CXX.
See cmake_bootstrap.log for compilers attempted.
---------------------------------------------
Log of errors: src/cmake-3.10.1/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------

Given that AIX is explicitly listed as a supported platform, and I am using
the latest version of the IBM AIX compiler, I find this error dubious.

Below is a the contents of the cmake_bootstrap.log, where we can see that
it does try to use the appropriate -q flag to enable the compiler's
supported C++11 features.

Is XL C simply unsupported?

--- paste below ---
Checking for XL toolchain
Try: xlc
Line: xlc  cmake_bootstrap_18350136_test.c -o cmake_bootstrap_18350136_test
----------  file   -----------------------
int main() { return 0; }
------------------------------------------
Test succeeded
Try: xlC
Line: xlC  cmake_bootstrap_18350136_test.cpp -o
cmake_bootstrap_18350136_test
----------  file   -----------------------
int main() { return 0; }
------------------------------------------
Test succeeded
Checking whether 'xlc  ' works.
Try: xlc
Line: xlc   cmake_bootstrap_18350136_test.c -o cmake_bootstrap_18350136_test
----------  file   -----------------------

#ifdef __cplusplus
# error "The CMAKE_C_COMPILER is set to a C++ compiler"
#endif

#if defined(__sun) && __STDC_VERSION__ < 199901L
#error "On Solaris we need C99."
#endif

#include <stdio.h>

int main(int argc, char* argv[])
{
  printf("%d%c", (argv != 0), (char)0x0a);
  return argc - 1;
}

------------------------------------------
1
Test succeeded
Checking whether 'xlC  ' works.
Try: xlC
Line: xlC   cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  ' works.
Try: xlC
Line: xlC   cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  -qlanglvl=extended1y' works.
Try: xlC
Line: xlC  -qlanglvl=extended1y cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
1540-5200 (W) The option "langlvl=extended1y" is not supported.
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  ' works.
Try: xlC
Line: xlC   cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  -std=gnu++11' works.
Try: xlC
Line: xlC  -std=gnu++11 cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
/opt/IBM/xlC/13.1.3/bin/.orig/xlC: 1501-210 (W) command option t contains
an incorrect subargument
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  -qlanglvl=extended0x' works.
Try: xlC
Line: xlC  -qlanglvl=extended0x cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  -qlanglvl=extended0x' works.
Try: xlC
Line: xlC  -qlanglvl=extended0x cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
Checking whether 'xlC  -qlanglvl=extended0x' works.
Try: xlC
Line: xlC  -qlanglvl=extended0x cmake_bootstrap_18350136_test.cxx -o
cmake_bootstrap_18350136_test
----------  file   -----------------------

#include <iostream>
#include <memory>
#include <unordered_map>

#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
#endif

#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
#error "SunPro <= 5.13 mode not supported due to bug in move semantics."
#endif

class Class
{
public:
  int Get() const { return this->Member; }
private:
  int Member = 1;
};
int main()
{
  auto const c = std::unique_ptr<Class>(new Class);
  std::cout << c->Get() << std::endl;
  return 0;
}

------------------------------------------
"/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
#error directive: To use the unordered map library, macro __IBMCPP_TR1__
must be defined
by user to non zero integer value..
"cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
directive: "Compiler is not in a mode aware of C++11.".
Test failed to compile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171219/a4f3a835/attachment.html>

From chuck.atkins at kitware.com  Tue Dec 19 14:50:47 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Tue, 19 Dec 2017 14:50:47 -0500
Subject: [CMake] Bootstrap fails to detect C++11 compiler on AIX 7.1/XL
 C 13.1.3 toolset
In-Reply-To: <CALUrYo=NaoUtsc07eQh7LyDPL+D_nmiB7zP5NVr_C6FxsEXQvw@mail.gmail.com>
References: <CALUrYo=NaoUtsc07eQh7LyDPL+D_nmiB7zP5NVr_C6FxsEXQvw@mail.gmail.com>
Message-ID: <CAOXZzG7OEVKrfVaM=nKcB6j7zoQ0vAwQg3AoGvpEdJx06Lh8tw@mail.gmail.com>

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

I will investigate...

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

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

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

From cgorac at gmail.com  Tue Dec 19 15:14:50 2017
From: cgorac at gmail.com (Crni Gorac)
Date: Tue, 19 Dec 2017 21:14:50 +0100
Subject: [CMake] "modern" CUDA handling and static libraries
Message-ID: <CAO65DGdGpowmssT5xhSCs8ax8MMFAh-h8_7b8Wu6h3mfVO9tcg@mail.gmail.com>

Hello,

My project is alike for what is described by following CMakeLists.txt
for Cuda/Complex test case from CMake source distribution:

#########################
cmake_minimum_required(VERSION 3.8)
project (CudaComplex CXX CUDA)

string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_30,code=compute_30")
set(CMAKE_CUDA_STANDARD 11)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CUDA_STANDARD_REQUIRED TRUE)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)

add_library(CudaLib STATIC dynamic.cu file1.cu file2.cu file3.cu mixed.cu)
set_target_properties(CudaLib PROPERTIES CUDA_SEPARABLE_COMPILATION OFF)
set_target_properties(CudaLib PROPERTIES POSITION_INDEPENDENT_CODE OFF)

add_library(CppLib STATIC dynamic.cpp mixed.cpp)

add_executable(CudaComplex main.cpp)
target_link_libraries(CudaComplex PUBLIC CudaLib CppLib)
#########################

So basically I want to build all my .cu files into one static library,
and all my .cpp files (except for main.cpp) into another static
library. These two libraries are then linked into main.cpp above. This
works fine, and make output is:

#########################
Scanning dependencies of target CppLib
Scanning dependencies of target CudaLib
[  8%] Building CXX object CMakeFiles/CppLib.dir/mixed.cpp.o
[ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file1.cu.o
[ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file2.cu.o
[ 33%] Building CXX object CMakeFiles/CppLib.dir/dynamic.cpp.o
[ 41%] Building CUDA object CMakeFiles/CudaLib.dir/dynamic.cu.o
[ 50%] Building CUDA object CMakeFiles/CudaLib.dir/file3.cu.o
[ 58%] Building CUDA object CMakeFiles/CudaLib.dir/mixed.cu.o
[ 66%] Linking CXX static library libCppLib.a
[ 66%] Built target CppLib
[ 75%] Linking CUDA static library libCudaLib.a
[ 75%] Built target CudaLib
Scanning dependencies of target CudaComplex
[ 83%] Building CXX object CMakeFiles/CudaComplex.dir/main.cpp.o
[ 91%] Linking CUDA device code CMakeFiles/CudaComplex.dir/cmake_device_link.o
[100%] Linking CXX executable CudaComplex
#########################

However, in my case these static libraries are actually to be
delivered to a client.  The problem is that the dynamic linking of
CUDA code (this is this line "Linking CUDA device code
CMakeFiles/CudaComplex.dir/cmake_device_link.o" in the make output
above) would still have to get done on client side, i.e. they would
have to install CUDA SDK and provide that this step is accomplished
through their build system.  So my question is: is it possible to
somehow generate static library with CUDA code, using this new
"...LANGUAGE CUDA..." CMake functionality, but that CUDA linking is
completed on my side (note that on client side no CUDA code will be
added to project)?

Thanks.

From robert.maynard at kitware.com  Tue Dec 19 17:47:48 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 19 Dec 2017 17:47:48 -0500
Subject: [CMake] "modern" CUDA handling and static libraries
In-Reply-To: <CAO65DGdGpowmssT5xhSCs8ax8MMFAh-h8_7b8Wu6h3mfVO9tcg@mail.gmail.com>
References: <CAO65DGdGpowmssT5xhSCs8ax8MMFAh-h8_7b8Wu6h3mfVO9tcg@mail.gmail.com>
Message-ID: <CAFzjYVoeU7JGfYUzPTKjs38tsBAsDd4y3BuKAPk+KArGKBbkJw@mail.gmail.com>

Hi,

The CUDA_RESOLVE_DEVICE_SYMBOLS property was added for this exact
situation. You can find it documented at
https://cmake.org/cmake/help/v3.10/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS.html

Here is an example of it being used:
https://gitlab.kitware.com/cmake/cmake/commit/493671a5212c6548b2d7376c7065f5f76692a792#0eb128c2e695da6e4cedb9a408b108f117bd4fe3

On Tue, Dec 19, 2017 at 3:14 PM, Crni Gorac <cgorac at gmail.com> wrote:
> Hello,
>
> My project is alike for what is described by following CMakeLists.txt
> for Cuda/Complex test case from CMake source distribution:
>
> #########################
> cmake_minimum_required(VERSION 3.8)
> project (CudaComplex CXX CUDA)
>
> string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_30,code=compute_30")
> set(CMAKE_CUDA_STANDARD 11)
> set(CMAKE_CXX_STANDARD 11)
> set(CMAKE_CUDA_STANDARD_REQUIRED TRUE)
> set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
>
> add_library(CudaLib STATIC dynamic.cu file1.cu file2.cu file3.cu mixed.cu)
> set_target_properties(CudaLib PROPERTIES CUDA_SEPARABLE_COMPILATION OFF)
> set_target_properties(CudaLib PROPERTIES POSITION_INDEPENDENT_CODE OFF)
>
> add_library(CppLib STATIC dynamic.cpp mixed.cpp)
>
> add_executable(CudaComplex main.cpp)
> target_link_libraries(CudaComplex PUBLIC CudaLib CppLib)
> #########################
>
> So basically I want to build all my .cu files into one static library,
> and all my .cpp files (except for main.cpp) into another static
> library. These two libraries are then linked into main.cpp above. This
> works fine, and make output is:
>
> #########################
> Scanning dependencies of target CppLib
> Scanning dependencies of target CudaLib
> [  8%] Building CXX object CMakeFiles/CppLib.dir/mixed.cpp.o
> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file1.cu.o
> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file2.cu.o
> [ 33%] Building CXX object CMakeFiles/CppLib.dir/dynamic.cpp.o
> [ 41%] Building CUDA object CMakeFiles/CudaLib.dir/dynamic.cu.o
> [ 50%] Building CUDA object CMakeFiles/CudaLib.dir/file3.cu.o
> [ 58%] Building CUDA object CMakeFiles/CudaLib.dir/mixed.cu.o
> [ 66%] Linking CXX static library libCppLib.a
> [ 66%] Built target CppLib
> [ 75%] Linking CUDA static library libCudaLib.a
> [ 75%] Built target CudaLib
> Scanning dependencies of target CudaComplex
> [ 83%] Building CXX object CMakeFiles/CudaComplex.dir/main.cpp.o
> [ 91%] Linking CUDA device code CMakeFiles/CudaComplex.dir/cmake_device_link.o
> [100%] Linking CXX executable CudaComplex
> #########################
>
> However, in my case these static libraries are actually to be
> delivered to a client.  The problem is that the dynamic linking of
> CUDA code (this is this line "Linking CUDA device code
> CMakeFiles/CudaComplex.dir/cmake_device_link.o" in the make output
> above) would still have to get done on client side, i.e. they would
> have to install CUDA SDK and provide that this step is accomplished
> through their build system.  So my question is: is it possible to
> somehow generate static library with CUDA code, using this new
> "...LANGUAGE CUDA..." CMake functionality, but that CUDA linking is
> completed on my side (note that on client side no CUDA code will be
> added to project)?
>
> 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 cgorac at gmail.com  Wed Dec 20 15:46:18 2017
From: cgorac at gmail.com (Crni Gorac)
Date: Wed, 20 Dec 2017 21:46:18 +0100
Subject: [CMake] "modern" CUDA handling and static libraries
In-Reply-To: <CAFzjYVoeU7JGfYUzPTKjs38tsBAsDd4y3BuKAPk+KArGKBbkJw@mail.gmail.com>
References: <CAO65DGdGpowmssT5xhSCs8ax8MMFAh-h8_7b8Wu6h3mfVO9tcg@mail.gmail.com>
 <CAFzjYVoeU7JGfYUzPTKjs38tsBAsDd4y3BuKAPk+KArGKBbkJw@mail.gmail.com>
Message-ID: <CAO65DGdEai26EQpoE80_fGhd4QA-BsvBEprNRL-xkXx64gnmSA@mail.gmail.com>

Thanks for your reply.

That seems to work, but only if the library consist solely of .cu
files.  If a .cpp file is added to library, then it won't work.  Is
this a known limitation?

On a related note: what is the equivalent of
"set(CUDA_PROPAGATE_HOST_FLAGS OFF)" now?

Regards.

On Tue, Dec 19, 2017 at 11:47 PM, Robert Maynard
<robert.maynard at kitware.com> wrote:
> Hi,
>
> The CUDA_RESOLVE_DEVICE_SYMBOLS property was added for this exact
> situation. You can find it documented at
> https://cmake.org/cmake/help/v3.10/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS.html
>
> Here is an example of it being used:
> https://gitlab.kitware.com/cmake/cmake/commit/493671a5212c6548b2d7376c7065f5f76692a792#0eb128c2e695da6e4cedb9a408b108f117bd4fe3
>
> On Tue, Dec 19, 2017 at 3:14 PM, Crni Gorac <cgorac at gmail.com> wrote:
>> Hello,
>>
>> My project is alike for what is described by following CMakeLists.txt
>> for Cuda/Complex test case from CMake source distribution:
>>
>> #########################
>> cmake_minimum_required(VERSION 3.8)
>> project (CudaComplex CXX CUDA)
>>
>> string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_30,code=compute_30")
>> set(CMAKE_CUDA_STANDARD 11)
>> set(CMAKE_CXX_STANDARD 11)
>> set(CMAKE_CUDA_STANDARD_REQUIRED TRUE)
>> set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
>>
>> add_library(CudaLib STATIC dynamic.cu file1.cu file2.cu file3.cu mixed.cu)
>> set_target_properties(CudaLib PROPERTIES CUDA_SEPARABLE_COMPILATION OFF)
>> set_target_properties(CudaLib PROPERTIES POSITION_INDEPENDENT_CODE OFF)
>>
>> add_library(CppLib STATIC dynamic.cpp mixed.cpp)
>>
>> add_executable(CudaComplex main.cpp)
>> target_link_libraries(CudaComplex PUBLIC CudaLib CppLib)
>> #########################
>>
>> So basically I want to build all my .cu files into one static library,
>> and all my .cpp files (except for main.cpp) into another static
>> library. These two libraries are then linked into main.cpp above. This
>> works fine, and make output is:
>>
>> #########################
>> Scanning dependencies of target CppLib
>> Scanning dependencies of target CudaLib
>> [  8%] Building CXX object CMakeFiles/CppLib.dir/mixed.cpp.o
>> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file1.cu.o
>> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file2.cu.o
>> [ 33%] Building CXX object CMakeFiles/CppLib.dir/dynamic.cpp.o
>> [ 41%] Building CUDA object CMakeFiles/CudaLib.dir/dynamic.cu.o
>> [ 50%] Building CUDA object CMakeFiles/CudaLib.dir/file3.cu.o
>> [ 58%] Building CUDA object CMakeFiles/CudaLib.dir/mixed.cu.o
>> [ 66%] Linking CXX static library libCppLib.a
>> [ 66%] Built target CppLib
>> [ 75%] Linking CUDA static library libCudaLib.a
>> [ 75%] Built target CudaLib
>> Scanning dependencies of target CudaComplex
>> [ 83%] Building CXX object CMakeFiles/CudaComplex.dir/main.cpp.o
>> [ 91%] Linking CUDA device code CMakeFiles/CudaComplex.dir/cmake_device_link.o
>> [100%] Linking CXX executable CudaComplex
>> #########################
>>
>> However, in my case these static libraries are actually to be
>> delivered to a client.  The problem is that the dynamic linking of
>> CUDA code (this is this line "Linking CUDA device code
>> CMakeFiles/CudaComplex.dir/cmake_device_link.o" in the make output
>> above) would still have to get done on client side, i.e. they would
>> have to install CUDA SDK and provide that this step is accomplished
>> through their build system.  So my question is: is it possible to
>> somehow generate static library with CUDA code, using this new
>> "...LANGUAGE CUDA..." CMake functionality, but that CUDA linking is
>> completed on my side (note that on client side no CUDA code will be
>> added to project)?
>>
>> 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 robert.maynard at kitware.com  Wed Dec 20 16:41:47 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 20 Dec 2017 16:41:47 -0500
Subject: [CMake] "modern" CUDA handling and static libraries
In-Reply-To: <CAO65DGdEai26EQpoE80_fGhd4QA-BsvBEprNRL-xkXx64gnmSA@mail.gmail.com>
References: <CAO65DGdGpowmssT5xhSCs8ax8MMFAh-h8_7b8Wu6h3mfVO9tcg@mail.gmail.com>
 <CAFzjYVoeU7JGfYUzPTKjs38tsBAsDd4y3BuKAPk+KArGKBbkJw@mail.gmail.com>
 <CAO65DGdEai26EQpoE80_fGhd4QA-BsvBEprNRL-xkXx64gnmSA@mail.gmail.com>
Message-ID: <CAFzjYVoe6OGgaM7Lun4JL+aJ4Ukt-vJW8Xy-n315tf5A9sFXiQ@mail.gmail.com>

> If a .cpp file is added to library, then it won't work.

If this is occurring it is a bug. Can you fill a bug report at:
https://gitlab.kitware.com/cmake/cmake

> CUDA_PROPAGATE_HOST_FLAGS

CUDA as a first class language propagates zero C++ flags as it is a
separate language, and we expect people to set CXX_FLAGS and
CUDA_FLAGS

On Wed, Dec 20, 2017 at 3:46 PM, Crni Gorac <cgorac at gmail.com> wrote:
> Thanks for your reply.
>
> That seems to work, but only if the library consist solely of .cu
> files.  If a .cpp file is added to library, then it won't work.  Is
> this a known limitation?
>
> On a related note: what is the equivalent of
> "set(CUDA_PROPAGATE_HOST_FLAGS OFF)" now?
>
> Regards.
>
> On Tue, Dec 19, 2017 at 11:47 PM, Robert Maynard
> <robert.maynard at kitware.com> wrote:
>> Hi,
>>
>> The CUDA_RESOLVE_DEVICE_SYMBOLS property was added for this exact
>> situation. You can find it documented at
>> https://cmake.org/cmake/help/v3.10/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS.html
>>
>> Here is an example of it being used:
>> https://gitlab.kitware.com/cmake/cmake/commit/493671a5212c6548b2d7376c7065f5f76692a792#0eb128c2e695da6e4cedb9a408b108f117bd4fe3
>>
>> On Tue, Dec 19, 2017 at 3:14 PM, Crni Gorac <cgorac at gmail.com> wrote:
>>> Hello,
>>>
>>> My project is alike for what is described by following CMakeLists.txt
>>> for Cuda/Complex test case from CMake source distribution:
>>>
>>> #########################
>>> cmake_minimum_required(VERSION 3.8)
>>> project (CudaComplex CXX CUDA)
>>>
>>> string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_30,code=compute_30")
>>> set(CMAKE_CUDA_STANDARD 11)
>>> set(CMAKE_CXX_STANDARD 11)
>>> set(CMAKE_CUDA_STANDARD_REQUIRED TRUE)
>>> set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
>>>
>>> add_library(CudaLib STATIC dynamic.cu file1.cu file2.cu file3.cu mixed.cu)
>>> set_target_properties(CudaLib PROPERTIES CUDA_SEPARABLE_COMPILATION OFF)
>>> set_target_properties(CudaLib PROPERTIES POSITION_INDEPENDENT_CODE OFF)
>>>
>>> add_library(CppLib STATIC dynamic.cpp mixed.cpp)
>>>
>>> add_executable(CudaComplex main.cpp)
>>> target_link_libraries(CudaComplex PUBLIC CudaLib CppLib)
>>> #########################
>>>
>>> So basically I want to build all my .cu files into one static library,
>>> and all my .cpp files (except for main.cpp) into another static
>>> library. These two libraries are then linked into main.cpp above. This
>>> works fine, and make output is:
>>>
>>> #########################
>>> Scanning dependencies of target CppLib
>>> Scanning dependencies of target CudaLib
>>> [  8%] Building CXX object CMakeFiles/CppLib.dir/mixed.cpp.o
>>> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file1.cu.o
>>> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file2.cu.o
>>> [ 33%] Building CXX object CMakeFiles/CppLib.dir/dynamic.cpp.o
>>> [ 41%] Building CUDA object CMakeFiles/CudaLib.dir/dynamic.cu.o
>>> [ 50%] Building CUDA object CMakeFiles/CudaLib.dir/file3.cu.o
>>> [ 58%] Building CUDA object CMakeFiles/CudaLib.dir/mixed.cu.o
>>> [ 66%] Linking CXX static library libCppLib.a
>>> [ 66%] Built target CppLib
>>> [ 75%] Linking CUDA static library libCudaLib.a
>>> [ 75%] Built target CudaLib
>>> Scanning dependencies of target CudaComplex
>>> [ 83%] Building CXX object CMakeFiles/CudaComplex.dir/main.cpp.o
>>> [ 91%] Linking CUDA device code CMakeFiles/CudaComplex.dir/cmake_device_link.o
>>> [100%] Linking CXX executable CudaComplex
>>> #########################
>>>
>>> However, in my case these static libraries are actually to be
>>> delivered to a client.  The problem is that the dynamic linking of
>>> CUDA code (this is this line "Linking CUDA device code
>>> CMakeFiles/CudaComplex.dir/cmake_device_link.o" in the make output
>>> above) would still have to get done on client side, i.e. they would
>>> have to install CUDA SDK and provide that this step is accomplished
>>> through their build system.  So my question is: is it possible to
>>> somehow generate static library with CUDA code, using this new
>>> "...LANGUAGE CUDA..." CMake functionality, but that CUDA linking is
>>> completed on my side (note that on client side no CUDA code will be
>>> added to project)?
>>>
>>> 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
> --
>
> 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 cgorac at gmail.com  Wed Dec 20 17:26:35 2017
From: cgorac at gmail.com (Crni Gorac)
Date: Wed, 20 Dec 2017 23:26:35 +0100
Subject: [CMake] "modern" CUDA handling and static libraries
In-Reply-To: <CAFzjYVoe6OGgaM7Lun4JL+aJ4Ukt-vJW8Xy-n315tf5A9sFXiQ@mail.gmail.com>
References: <CAO65DGdGpowmssT5xhSCs8ax8MMFAh-h8_7b8Wu6h3mfVO9tcg@mail.gmail.com>
 <CAFzjYVoeU7JGfYUzPTKjs38tsBAsDd4y3BuKAPk+KArGKBbkJw@mail.gmail.com>
 <CAO65DGdEai26EQpoE80_fGhd4QA-BsvBEprNRL-xkXx64gnmSA@mail.gmail.com>
 <CAFzjYVoe6OGgaM7Lun4JL+aJ4Ukt-vJW8Xy-n315tf5A9sFXiQ@mail.gmail.com>
Message-ID: <CAO65DGdW6yHFQz2Pa97QMx-WQ1uhyntu3iq3sMhNjUNGVrcHDg@mail.gmail.com>

On Wed, Dec 20, 2017 at 10:41 PM, Robert Maynard
<robert.maynard at kitware.com> wrote:
>> If a .cpp file is added to library, then it won't work.
>
> If this is occurring it is a bug. Can you fill a bug report at:
> https://gitlab.kitware.com/cmake/cmake

I just did it, it's here: https://gitlab.kitware.com/cmake/cmake/issues/17586.

What I my options in the meantime?  I tried with setting all of
CUDA_SEPARABLE_COMPILATION, CUDA_RESOLVE_DEVICE_SYMBOLS and
POSITION_INDEPENDENT_CODE to OFF, but the behavior is the same.  Is my
only option to revert everything back to using FindCUDA.cmake?

From saadrustam at gmail.com  Fri Dec 22 10:17:01 2017
From: saadrustam at gmail.com (Saad Khattak)
Date: Fri, 22 Dec 2017 15:17:01 +0000
Subject: [CMake] Include directories of IMPORTED libraries not propagating
Message-ID: <CAEM70sOVj3pDHba9PgDOwgQOLEShx4WBP_9sOTmDEWoAVMCEvg@mail.gmail.com>

Hi,

I have the following setup:

ImportedLib (sets location of library files and public include directories)
LibA             (publicly includes ImporteLib with
target_link_libraries(...))
Exe              (finds LibA and links against it)

Where ImportedLib uses "set_target_properties(ImportedLib PROPERTIES
IMPORTED_LOCATION_DEBUG ... INTERFACE_INCLUDE_DIRECTORIES ...)" to set its
include directories and prebuilt libraries for linking.

LibA uses "target_link_libraries(LibA PUBLIC ImportedLib)". CMake correctly
generates the project such that LibA now has the include directories of the
ImportedLib. LibA then uses the "install(...)" feature so that "Exe" can
find LibA.

With Exe, I find LibA using "find_package(LibA REQUIRED)" and then
"target_link_libraries(Exe LibA)". Exe inherits LibA's include directories
and links against it. Exe is also able to link against ImportedLib.
However, what Exe does not inherit is the public include directories
specified by ImportedLib. This seems like a bug because it is able to know
about and is able to link against ImportLib prebuilt library files.

If it's not a bug, how do I make sure ImportedLib include directories are
propagated properly?

Regards,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171222/2118eb33/attachment.html>

From mario at emmenlauer.de  Fri Dec 22 11:42:18 2017
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Fri, 22 Dec 2017 17:42:18 +0100
Subject: [CMake] absolute library path, sorry for the question
In-Reply-To: <377028c6-4c41-60a1-ca92-7b580715716c@emmenlauer.de>
References: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
 <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>
 <377028c6-4c41-60a1-ca92-7b580715716c@emmenlauer.de>
Message-ID: <097f92c3-abb4-21cd-1100-245d521381c4@emmenlauer.de>


Can anyone help to force cmake use absolute paths?

On 13.12.2017 11:45, Mario Emmenlauer wrote:
> Thank you for your reply!! Your explanation is very helpful for writing
> my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
> that comes with the libraries. For example libtiff, turbojpeg, thrift,
> and many others...
> 
> As an example, I build libtiff in the following way:
>         cmake ../$TIFFVERSION \
>             -Wno-dev \
>             -G"Unix Makefiles" \
>             -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
>             -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
>             -DCMAKE_BUILD_TYPE="Release" \
>             -DBUILD_SHARED_LIBS="ON" \
>             -Djpeg="ON" \
>             -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
>             -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
>         make VERBOSE="1" && make install
> 
> In the build log, I can see that cmake detects the jpeg library to be
> '$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
> Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
> And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
> instead of my thirdparty libjpeg.
> 
> So at some point between FindJPEG.cmake and the final Makefile, cmake
> changed the JPEG_LIBRARIES variable from absolute to relative. And I can
> not understand why or when this happens. The documentation also does not
> help me, because it explains that this should happen 'if the full path is
> not know or if the full path is one of the system library dirs' (see
> https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
> I override to use jpeg with a known, existing path that is not a system
> library.
> 
> All the best,
> 
>    Mario
> 
> 
> 
> 
> On 13.12.2017 11:12, Bo Zhou wrote:
>> Hi
>>
>> CMAKE_SKIP_RPATH usually is used for the shared module which might want to have the customized distributed path such as within the application. According
>> personal experience on POSIX systems (Linux, UNIX, OSX), always enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final distribution,
>> (if needed) put shared libraries into the lib folder of distribution.
>>
>> According your description, I'm not sure how did you pick up your library into the application from CMake, usually we have to make sure the CMake always chooses
>> the libraries from 3rd-party directory not system or another places. In our system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
>> folder which contains the all built libraries, then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
>> pre-built libraries, so the linking should be okay.
>>
>> If everything has no error, but just the application always picks up the system's library not the 3rd-party libraries we prepared, one solution would add
>> another loader script for the application, from the loader script it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual application
>> executable file. A lot of commercial application on Linux solve the similar issue by this way.
>>
>> Wish my reply is helpful.
>>
>> Thank you very much.
>>
>> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer <mario at emmenlauer.de <mailto:mario at emmenlauer.de>> wrote:
>>
>>
>>     Dear cmake users,
>>
>>     I have found good documentation on the cmake wiki about RPATH and
>>     its different variables, and also on the mailing lists. But somehow
>>     it still does not add up for me. Can you please help?
>>
>>     I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
>>     amongst others. I build many standard libraries (like tiff and jpeg)
>>     into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
>>     them there. On newer Linux and Windows, cmake uses always the absolute
>>     path to those libraries, and everything works fine. But on older Linux
>>     like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
>>     library in the correct absolute thirdparty directory, and I can confirm
>>     this by printing the 'XXX_LIBRARIES' variable in the find script. But
>>     later the Makefile will link with '-lxxx' instead of the full path.
>>     This makes 'ld' use the system library instead!
>>
>>     I completely fail to understand at what point cmake changes XXX_LIBRARIES
>>     from an absolute path to '-lxxx', for example for libjpeg.
>>
>>     I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
>>     The only workaround I could find is to add the thirdparty directory to
>>     LDFLAGS. Then 'ld' will also find the correct library.
>>
>>
>>     Is this a bug, or an expected behavior? What parameters should I add
>>     when I invoke cmake so that it will always use libraries with their
>>     full path?
>>
>>
>>     Cheers,
>>
>>     ? ? Mario Emmenlauer
>>
>>
>>
>>     PS: since I build thirdparty libraries, I prefer not to change their
>>     CMakeLists.txt but would rather prefer to set better cmake command line
>>     parameters.
>>
>>
>>     References:
>>     https://cmake.org/Wiki/CMake_RPATH_handling <https://cmake.org/Wiki/CMake_RPATH_handling>
>>     https://cmake.org/pipermail/cmake/2015-September/061462.html <https://cmake.org/pipermail/cmake/2015-September/061462.html>


From robert.maynard at kitware.com  Fri Dec 22 13:51:53 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 22 Dec 2017 13:51:53 -0500
Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues
In-Reply-To: <CAFzjYVpgSto4S-g7i5+6+8iYD0-5nF9az-TGNdWw5V_VDagPtQ@mail.gmail.com>
References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de>
 <CAFzjYVrxtPYbrG-iv6ytqGptF8vuP4QBhjVQukMnAgLSCJRMcQ@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de>
 <CAFzjYVr17gF03vGJNFbAFf5o4JcD8WzSsZpU-bsmhMvcd6vnvw@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E7098FE66@EXMBS2.ad.igd.fraunhofer.de>
 <CAFzjYVr7erVPxLVMK+Odf+83AsyLB5C+ctB3cn36MTOKsExhxw@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E7098FE9C@EXMBS2.ad.igd.fraunhofer.de>
 <CAFzjYVpgSto4S-g7i5+6+8iYD0-5nF9az-TGNdWw5V_VDagPtQ@mail.gmail.com>
Message-ID: <CAFzjYVqm0pVPLtVh80qsoRVVz3O_R7H_WJVV=Zh8zEm9SefzOg@mail.gmail.com>

Hi,

I have a MR open for CMake that resolves this bug
(https://gitlab.kitware.com/cmake/cmake/merge_requests/1618)

On Thu, Sep 7, 2017 at 9:48 AM, Robert Maynard
<robert.maynard at kitware.com> wrote:
> Okay I have opened an issue on CMake for handling multiple gencode with
> multiple code targets.
>
> On Wed, Sep 6, 2017 at 3:19 PM, Mueller-Roemer, Johannes Sebastian
> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>>
>> Yes
>>
>> ________________________________
>> From: Robert Maynard [robert.maynard at kitware.com]
>> Sent: Wednesday, September 06, 2017 6:58 PM
>> To: Mueller-Roemer, Johannes Sebastian
>> Cc: cmake at cmake.org
>> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
>> issues
>>
>> So it works when they are separate gen-code options, but fails when they
>> are combined. Is that correct?
>>
>>
>> On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian
>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de<mailto:Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>>
>> wrote:
>> The long form fills the Code Generation field with
>> compute_20,sm_20;compute_20,compute_20 (the default without gencode
>> parameters is compute_20,sm_20) and results in the following command line:
>>
>> D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU
>> Computing Toolkit\CUDA\v8.0\bin\nvcc.exe"
>> -gencode=arch=compute_20,code=\"sm_20,compute_20\"
>> -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env
>> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
>> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
>> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
>> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
>> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g
>> -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
>> A.dir\Debug\a.cu.obj
>> "D:\jsroemer\projects\cuda-pdb-test\a\a.cu<http://a.cu>"
>>
>> Which is somewhat redundant
>>
>> MSVC turns compute_20,sm_20 into
>> -gencode=arch=compute_20,code=\"sm_20,compute_20\" and compute_20,compute_20
>> into -gencode=arch=compute_20,code=\"compute_20,compute_20\"
>>
>>
>> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>> Tel +49 6151 155-606<tel:+49%206151%20155606>  |  Fax +49 6151
>> 155-139<tel:+49%206151%20155139>
>>
>> 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: Robert Maynard
>> [mailto:robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>]
>> Sent: Wednesday, September 6, 2017 16:44
>>
>> To: Mueller-Roemer, Johannes Sebastian
>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de<mailto:Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>>
>> Cc: cmake at cmake.org<mailto:cmake at cmake.org>
>> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
>> issues
>>
>> Yes I was responding to comment 3.
>>
>> I am curious, does the longer form signature "-gencode
>> arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20" work
>> correctly? CMake has to parse the gencode flags and move them to special
>> msbuild entries, and I wonder if there is a bug when parsing multiple code
>> options.
>>
>> On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian
>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de<mailto:Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>>
>> wrote:
>> If the comment is wrt 3., the result is the same no matter if I use a
>> space or an equals sign, if I double escape the quotes (e.g., use the value
>> as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS
>> becomes compute_20,"sm_20,compute_20" instead of
>> compute_20,sm_20,compute_20, which is equally illegal and will cause the
>> same error message, also double escaping should not be necessary for a
>> subset of flags (Xcompiler works fine without it, even if the default values
>> are pointless).
>> If the comment is wrt 2., this is the line automatically generated by
>> CMake/VS when not passing in any gencode flags explicitly.
>>
>> Or am I misunderstanding what you mean?
>>
>> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>> Tel +49 6151 155-606<tel:+49%206151%20155606>  |  Fax +49 6151
>> 155-139<tel:+49%206151%20155139>
>>
>> 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: Robert Maynard
>> [mailto:robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>]
>> Sent: Wednesday, September 6, 2017 15:38
>> To: Mueller-Roemer, Johannes Sebastian
>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de<mailto:Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>>
>> Cc: cmake at cmake.org<mailto:cmake at cmake.org>
>> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
>> issues
>>
>> As far as gencode goes, your line has errors. With CUDA 8 it should look
>> like:
>>
>> -gencode arch=compute_20,code=\"sm_20,compute_20\"
>>
>>
>>
>> On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian
>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de<mailto:Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>>
>> wrote:
>> I?m having two issues with debug symbols for CUDA libraries on a project:
>>
>>
>> 1.       The PDBs are not placed where the linker later expects to find
>> them (haven?t been able to replicate this in a minimal project yet)
>>
>> 2.       Trying to circumnavigate this issue by using ?/Z7? instead of
>> ?/Zi? does not work, Zi is always used (replicable in any project with CUDA)
>>
>> Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by
>> -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning
>> D9025: overriding '/Z7' with '/Zi'? in the output window.
>> And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build
>> tools seem to determine these automatically anyways? for example I get the
>> following call in the above scenario:
>>
>> "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe"
>> -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env
>> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
>> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
>> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
>> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
>> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g
>> -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
>> A.dir\Debug\a.cu.obj
>> "D:\jsroemer\projects\cuda-pdb-test\a\a.cu<http://a.cu>"
>>
>> 3.       Also, -gencode flags do not behave as expected when given in the
>> form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS
>> build system to error out:
>>
>> C:\Program Files
>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA
>> 8.0.targets(216,9): error : Item '..\..\a\a.cu<http://a.cu>' Code Generation
>> value is not in the expected format '[Arch],[Code]'.
>>
>> The code generation value in this example is set to
>> compute_20,sm_20,compute_20 by CMake.
>>
>> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>> Tel +49 6151 155-606<tel:+49%206151%20155606>  |  Fax +49 6151
>> 155-139<tel:+49%206151%20155139>
>>
>> johannes.mueller-roemer at igd.fraunhofer.de<mailto:johannes.mueller-roemer at igd.fraunhofer.de>
>> | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>
>>
>>
>> --
>>
>> 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:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>>
>>
>

From mike.jackson at bluequartz.net  Fri Dec 22 14:51:09 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Fri, 22 Dec 2017 14:51:09 -0500
Subject: [CMake] ExternalProject_Add and Git Update? How do I make these
 work?
Message-ID: <4BCB8B08-D2C7-40D0-B583-1C5B742D8A2D@bluequartz.net>

ExternalProject_Add(${extProjectName}
  GIT_REPOSITORY "git://github.com/BlueQuartzSoftware/discount.git"
  GIT_PROGRESS 1
  #GIT_TAG master

  TMP_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/tmp/${CMAKE_BUILD_TYPE}"
  STAMP_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Stamp"
  DOWNLOAD_DIR ${DREAM3D_SDK}/superbuild/${extProjectName}/Download
  SOURCE_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Source"
  BINARY_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Build/${CMAKE_BUILD_TYPE}"
  INSTALL_DIR "${DREAM3D_SDK}/${extProjectName}-${discount_VERSION}-${CMAKE_BUILD_TYPE}"

  #UPDATE_COMMAND "${GIT_EXECUTABLE} pull --rebase origin master"
  PATCH_COMMAND ""

  CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>

  LOG_DOWNLOAD 1
  LOG_UPDATE 1
  LOG_CONFIGURE 1
  LOG_BUILD 1
  LOG_TEST 1
  LOG_INSTALL 1
)

The above is my cmake code. This worked great the first time through. Then I discovered an issue in the project that I was cloning (discount) and fixed it and pushed it. Now the repository at GitHub is a few commits ahead of what I have. So I rerun CMake and then "ninja" and I get an error when the "update" command is run:

Cannot rebase: You have unstaged changes.
Please commit or stash them.
No rebase in progress?
CMake Error at /Users/Shared/DREAM3D_SDK/superbuild/discount/tmp/Debug/discount-gitupdate.cmake:105 (message):
  

  Failed to rebase in:
  '/Users/Shared/DREAM3D_SDK/superbuild/discount/Source/'.

  You will have to resolve the conflicts manually


Doing a "git status" in the "Source" directory gives this:

[mjackson at ferb:Source]$ git status
On branch master
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	"tests/mu\303\261oz.t"

nothing added to commit but untracked files present (use "git add" to track)


There was something funning with the file that is untracked. Not sure if this is causing the issues? 
--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net



From annulen at yandex.ru  Fri Dec 22 15:24:11 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 22 Dec 2017 23:24:11 +0300
Subject: [CMake] ExternalProject_Add and Git Update? How do I make these
 work?
In-Reply-To: <4BCB8B08-D2C7-40D0-B583-1C5B742D8A2D@bluequartz.net>
References: <4BCB8B08-D2C7-40D0-B583-1C5B742D8A2D@bluequartz.net>
Message-ID: <188591513974251@web21j.yandex.ru>



> ExternalProject_Add(${extProjectName}
> GIT_REPOSITORY "git://github.com/BlueQuartzSoftware/discount.git"
> GIT_PROGRESS 1
> #GIT_TAG master
> 
> TMP_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/tmp/${CMAKE_BUILD_TYPE}"
> STAMP_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Stamp"
> DOWNLOAD_DIR ${DREAM3D_SDK}/superbuild/${extProjectName}/Download
> SOURCE_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Source"
> BINARY_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Build/${CMAKE_BUILD_TYPE}"
> INSTALL_DIR "${DREAM3D_SDK}/${extProjectName}-${discount_VERSION}-${CMAKE_BUILD_TYPE}"
> 
> #UPDATE_COMMAND "${GIT_EXECUTABLE} pull --rebase origin master"
> PATCH_COMMAND ""
> 
> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
> 
> LOG_DOWNLOAD 1
> LOG_UPDATE 1
> LOG_CONFIGURE 1
> LOG_BUILD 1
> LOG_TEST 1
> LOG_INSTALL 1
> )
> 
> The above is my cmake code. This worked great the first time through. Then I discovered an issue in the project that I was cloning (discount) and fixed it and pushed it. Now the repository at GitHub is a few commits ahead of what I have. 

If you want to make modifications in projects that you build with ExternalProject, you might want to use
git submodules instead of specifying GIT_REPOSITORY in ExternalProject_Add

>So I rerun CMake and then "ninja" and I get an error when the "update" command is run:
> 
> Cannot rebase: You have unstaged changes.
> Please commit or stash them.
> No rebase in progress?
> CMake Error at /Users/Shared/DREAM3D_SDK/superbuild/discount/tmp/Debug/discount-gitupdate.cmake:105 (message):
> 
> Failed to rebase in:
> '/Users/Shared/DREAM3D_SDK/superbuild/discount/Source/'.
> 
> You will have to resolve the conflicts manually
> 
> Doing a "git status" in the "Source" directory gives this:
> 
> [mjackson at ferb:Source]$ git status
> On branch master
> Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
> (use "git pull" to update your local branch)
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
> 
> "tests/mu\303\261oz.t"
> 
> nothing added to commit but untracked files present (use "git add" to track)
> 
> There was something funning with the file that is untracked. Not sure if this is causing the issues?
> 
> --
> Michael Jackson | Owner, President
> BlueQuartz Software
> [e] mike.jackson at bluequartz.net
> [w] www.bluequartz.net
> 
> --
> 
> 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 kris.f.thielemans at gmail.com  Sat Dec 23 03:03:43 2017
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 23 Dec 2017 08:03:43 -0000
Subject: [CMake] ExternalProject_Add and Git Update? How do I make these
 work?
In-Reply-To: <4BCB8B08-D2C7-40D0-B583-1C5B742D8A2D@bluequartz.net>
References: <4BCB8B08-D2C7-40D0-B583-1C5B742D8A2D@bluequartz.net>
Message-ID: <002e01d37bc4$8d792690$a86b73b0$@gmail.com>

Hi

The strange thing here is

Cannot rebase: You have unstaged changes.
Please commit or stash them.
No rebase in progress?

Why would it be rebasing? Maybe a local config setting that a pull is always
pull --rebase? In any case, my guess is that your discount/Source is in a
funny state compare to the github version. Try a "git pull" there manually
to see what happens then.

HTH
kris

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Michael Jackson
Sent: 22 December 2017 19:51
To: CMake Mail List <cmake at cmake.org>
Subject: [CMake] ExternalProject_Add and Git Update? How do I make these
work?

ExternalProject_Add(${extProjectName}
  GIT_REPOSITORY "g
it://github.com/BlueQuartzSoftware/discount.git"
  GIT_PROGRESS 1
  #GIT_TAG master

  TMP_DIR
"${DREAM3D_SDK}/superbuild/${extProjectName}/tmp/${CMAKE_BUILD_TYPE}"
  STAMP_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Stamp"
  DOWNLOAD_DIR ${DREAM3D_SDK}/superbuild/${extProjectName}/Download
  SOURCE_DIR "${DREAM3D_SDK}/superbuild/${extProjectName}/Source"
  BINARY_DIR
"${DREAM3D_SDK}/superbuild/${extProjectName}/Build/${CMAKE_BUILD_TYPE}"
  INSTALL_DIR
"${DREAM3D_SDK}/${extProjectName}-${discount_VERSION}-${CMAKE_BUILD_TYPE}"

  #UPDATE_COMMAND "${GIT_EXECUTABLE} pull --rebase origin master"
  PATCH_COMMAND ""

  CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>

  LOG_DOWNLOAD 1
  LOG_UPDATE 1
  LOG_CONFIGURE 1
  LOG_BUILD 1
  LOG_TEST 1
  LOG_INSTALL 1
)

The above is my cmake code. This worked great the first time through. Then I
discovered an issue in the project that I was cloning (discount) and fixed
it and pushed it. Now the repository at GitHub is a few commits ahead of
what I have. So I rerun CMake and then "ninja" and I get an error when the
"update" command is run:

Cannot rebase: You have unstaged changes.
Please commit or stash them.
No rebase in progress?
CMake Error at
/Users/Shared/DREAM3D_SDK/superbuild/discount/tmp/Debug/discount-gitupdate.c
make:105 (message):
  

  Failed to rebase in:
  '/Users/Shared/DREAM3D_SDK/superbuild/discount/Source/'.

  You will have to resolve the conflicts manually


Doing a "git status" in the "Source" directory gives this:

[mjackson at ferb:Source]$ git status
On branch master
Your branch is behind 'origin/master' by 2 commits, and can be
fast-forwarded.
  (use "git pull" to update your local branch) Untracked files:
  (use "git add <file>..." to include in what will be committed)

	"tests/mu\303\261oz.t"

nothing added to commit but untracked files present (use "git add" to track)


There was something funning with the file that is untracked. Not sure if
this is causing the issues? 
--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net


-- 

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 kris.f.thielemans at gmail.com  Sat Dec 23 03:12:26 2017
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 23 Dec 2017 08:12:26 -0000
Subject: [CMake] how to add a test that calls ctest
Message-ID: <003f01d37bc5$c558a0d0$5009e270$@gmail.com>

Hi

 

We have a superbuild-type project
https://github.com/CCPPETMR/SIRF-SuperBuild where we want to add tests that
call ctest for the dependent projects. We do this as

 

 

               COMMAND ${CMAKE_CTEST_COMMAND} WORKING_DIRECTORY
${CMAKE_CURRENT_BINARY_DIR}/SIRF-prefix/src/SIRF-build/)

 

which works fine when using Makefiles, but fails with Visual Studio as we
don't pass the "-C config" flag. So how do we put this in? I tried

 

               COMMAND ${CMAKE_CTEST_COMMAND} -C ${CMAKE_CFG_INTDIR} -VV
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/SIRF-prefix/src/SIRF-build/)

 

But this gives me errors like

 

1: 4: Test command: NOT_AVAILABLE

1: Test not available in configuration "$(Configuration)".

 

Best wishes

 

 

Kris Thielemans
Reader in Medical Imaging Physics at University College London

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171223/c5dc73a6/attachment-0001.html>

From Andreas-Naumann at gmx.net  Sat Dec 23 04:47:38 2017
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Sat, 23 Dec 2017 10:47:38 +0100
Subject: [CMake] absolute library path, sorry for the question
In-Reply-To: <097f92c3-abb4-21cd-1100-245d521381c4@emmenlauer.de>
References: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
 <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>
 <377028c6-4c41-60a1-ca92-7b580715716c@emmenlauer.de>
 <097f92c3-abb4-21cd-1100-245d521381c4@emmenlauer.de>
Message-ID: <22b9b08c-a8a0-016e-e0cb-3381ba9231c3@gmx.net>

your problem is hard to analyse. If you have a "minimal" example, which 
shows this behavior, we could test it. In your last mail, you wrote 
about building and installing libtiff using your own libjpeg. But than 
you write about a later build. So something must happen in the "later 
build".

Interesting enough, you said, that with newer systems, you do not have 
this problem. Do these old systems use a different cmake version?

Seasons Greetings,
Andreas
Am 22.12.2017 um 17:42 schrieb Mario Emmenlauer:
> Can anyone help to force cmake use absolute paths?
>
> On 13.12.2017 11:45, Mario Emmenlauer wrote:
>> Thank you for your reply!! Your explanation is very helpful for writing
>> my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
>> that comes with the libraries. For example libtiff, turbojpeg, thrift,
>> and many others...
>>
>> As an example, I build libtiff in the following way:
>>          cmake ../$TIFFVERSION \
>>              -Wno-dev \
>>              -G"Unix Makefiles" \
>>              -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
>>              -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
>>              -DCMAKE_BUILD_TYPE="Release" \
>>              -DBUILD_SHARED_LIBS="ON" \
>>              -Djpeg="ON" \
>>              -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
>>              -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
>>          make VERBOSE="1" && make install
>>
>> In the build log, I can see that cmake detects the jpeg library to be
>> '$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
>> Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
>> And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
>> instead of my thirdparty libjpeg.
>>
>> So at some point between FindJPEG.cmake and the final Makefile, cmake
>> changed the JPEG_LIBRARIES variable from absolute to relative. And I can
>> not understand why or when this happens. The documentation also does not
>> help me, because it explains that this should happen 'if the full path is
>> not know or if the full path is one of the system library dirs' (see
>> https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
>> I override to use jpeg with a known, existing path that is not a system
>> library.
>>
>> All the best,
>>
>>     Mario
>>
>>
>>
>>
>> On 13.12.2017 11:12, Bo Zhou wrote:
>>> Hi
>>>
>>> CMAKE_SKIP_RPATH usually is used for the shared module which might want to have the customized distributed path such as within the application. According
>>> personal experience on POSIX systems (Linux, UNIX, OSX), always enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final distribution,
>>> (if needed) put shared libraries into the lib folder of distribution.
>>>
>>> According your description, I'm not sure how did you pick up your library into the application from CMake, usually we have to make sure the CMake always chooses
>>> the libraries from 3rd-party directory not system or another places. In our system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
>>> folder which contains the all built libraries, then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
>>> pre-built libraries, so the linking should be okay.
>>>
>>> If everything has no error, but just the application always picks up the system's library not the 3rd-party libraries we prepared, one solution would add
>>> another loader script for the application, from the loader script it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual application
>>> executable file. A lot of commercial application on Linux solve the similar issue by this way.
>>>
>>> Wish my reply is helpful.
>>>
>>> Thank you very much.
>>>
>>> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer <mario at emmenlauer.de <mailto:mario at emmenlauer.de>> wrote:
>>>
>>>
>>>      Dear cmake users,
>>>
>>>      I have found good documentation on the cmake wiki about RPATH and
>>>      its different variables, and also on the mailing lists. But somehow
>>>      it still does not add up for me. Can you please help?
>>>
>>>      I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
>>>      amongst others. I build many standard libraries (like tiff and jpeg)
>>>      into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
>>>      them there. On newer Linux and Windows, cmake uses always the absolute
>>>      path to those libraries, and everything works fine. But on older Linux
>>>      like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
>>>      library in the correct absolute thirdparty directory, and I can confirm
>>>      this by printing the 'XXX_LIBRARIES' variable in the find script. But
>>>      later the Makefile will link with '-lxxx' instead of the full path.
>>>      This makes 'ld' use the system library instead!
>>>
>>>      I completely fail to understand at what point cmake changes XXX_LIBRARIES
>>>      from an absolute path to '-lxxx', for example for libjpeg.
>>>
>>>      I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
>>>      The only workaround I could find is to add the thirdparty directory to
>>>      LDFLAGS. Then 'ld' will also find the correct library.
>>>
>>>
>>>      Is this a bug, or an expected behavior? What parameters should I add
>>>      when I invoke cmake so that it will always use libraries with their
>>>      full path?
>>>
>>>
>>>      Cheers,
>>>
>>>          Mario Emmenlauer
>>>
>>>
>>>
>>>      PS: since I build thirdparty libraries, I prefer not to change their
>>>      CMakeLists.txt but would rather prefer to set better cmake command line
>>>      parameters.
>>>
>>>
>>>      References:
>>>      https://cmake.org/Wiki/CMake_RPATH_handling <https://cmake.org/Wiki/CMake_RPATH_handling>
>>>      https://cmake.org/pipermail/cmake/2015-September/061462.html <https://cmake.org/pipermail/cmake/2015-September/061462.html>


From irwin at beluga.phys.uvic.ca  Sat Dec 23 13:50:57 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sat, 23 Dec 2017 10:50:57 -0800 (PST)
Subject: [CMake] absolute library path, sorry for the question
In-Reply-To: <22b9b08c-a8a0-016e-e0cb-3381ba9231c3@gmx.net>
References: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
 <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>
 <377028c6-4c41-60a1-ca92-7b580715716c@emmenlauer.de>
 <097f92c3-abb4-21cd-1100-245d521381c4@emmenlauer.de>
 <22b9b08c-a8a0-016e-e0cb-3381ba9231c3@gmx.net>
Message-ID: <alpine.DEB.2.11.1712231014470.18536@enira.zlyna.ubzr>

On 2017-12-23 10:47+0100 Andreas Naumann wrote:

> your problem is hard to analyse. If you have a "minimal" example, which shows 
> this behavior, we could test it. In your last mail, you wrote about building 
> and installing libtiff using your own libjpeg. But than you write about a 
> later build. So something must happen in the "later build".

@Mario:

I second everything said here by Andreas.  So I think, for example,
that your next step should be to create a minimal example (e.g., a
"hello, world" minimal test C executable that is [over-]linked to one
of your libraries in a non-standard location).  Then compare your
"make VERBOSE=1" results for that simple example on your multiple
platforms to see whether the linking is done with the library in the
correct non-standard location rather than the system library.

Furthermore you stated in your original post that for some of your
platforms CMake use the -l linking option to link, and you thought
that was an issue.  Actually, that is fine if CMake also generates an
-L option pointing to the correct non-standard location since linkers
use the combination of -L and -l options to locate the library if it
is not specified as an absolute path.

So my guess from what you have said is you forgot about the -L option
also generated by CMake, and, in fact, CMake is working correctly to
link your code on all platforms.  Anyway, if your "make VERBOSE=1"
results prove that is the case, then your next step should be to
configure your build system so that an -rpath option is used by the
linker so that the system loader for your executable can find the
library in its non-standard location at run time.

My own linking experience (currently with CMake-3.6.2 and higher) is 
just limited to my Debian platform at this time, but I do successfully
use some libraries that are installed in non-standard system
locations.  And my experience is a properly configured CMake-based
build system links those libraries with the appropriate -rpath option
with good results (using the library version in the non-standard
location) both at link time and run time.

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 bo.schwarzstein at gmail.com  Sat Dec 23 23:02:45 2017
From: bo.schwarzstein at gmail.com (Bo Zhou)
Date: Sun, 24 Dec 2017 13:02:45 +0900
Subject: [CMake] absolute library path, sorry for the question
In-Reply-To: <alpine.DEB.2.11.1712231014470.18536@enira.zlyna.ubzr>
References: <2f71a530-68c6-71c4-83cf-68dc47ba8ca6@emmenlauer.de>
 <CAMX42NC3_9rHgXG--4omApixYi+GL+jqQ5R3_Cy7qdc1wOCBgA@mail.gmail.com>
 <377028c6-4c41-60a1-ca92-7b580715716c@emmenlauer.de>
 <097f92c3-abb4-21cd-1100-245d521381c4@emmenlauer.de>
 <22b9b08c-a8a0-016e-e0cb-3381ba9231c3@gmx.net>
 <alpine.DEB.2.11.1712231014470.18536@enira.zlyna.ubzr>
Message-ID: <CAMX42NCXqzFNPxxXpPaYrKny2HSADthKg6Q9hRwexeDGkWH3Mw@mail.gmail.com>

https://cmake.org/cmake/help/v3.0/command/find_path.html

Please try to pass the NO_CMAKE_SYSTEM_PATH to find_path() and
find_library(), but use the HINT to pass the path to thirdparty paths.

Of course use the CMAKE_VERBOSE_MAKEFILE to check the log.

At the last check the CMakeCache.txt to verify everything is okay.

On Sun, Dec 24, 2017 at 3:50 AM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> On 2017-12-23 10:47+0100 Andreas Naumann wrote:
>
> your problem is hard to analyse. If you have a "minimal" example, which
>> shows this behavior, we could test it. In your last mail, you wrote about
>> building and installing libtiff using your own libjpeg. But than you write
>> about a later build. So something must happen in the "later build".
>>
>
> @Mario:
>
> I second everything said here by Andreas.  So I think, for example,
> that your next step should be to create a minimal example (e.g., a
> "hello, world" minimal test C executable that is [over-]linked to one
> of your libraries in a non-standard location).  Then compare your
> "make VERBOSE=1" results for that simple example on your multiple
> platforms to see whether the linking is done with the library in the
> correct non-standard location rather than the system library.
>
> Furthermore you stated in your original post that for some of your
> platforms CMake use the -l linking option to link, and you thought
> that was an issue.  Actually, that is fine if CMake also generates an
> -L option pointing to the correct non-standard location since linkers
> use the combination of -L and -l options to locate the library if it
> is not specified as an absolute path.
>
> So my guess from what you have said is you forgot about the -L option
> also generated by CMake, and, in fact, CMake is working correctly to
> link your code on all platforms.  Anyway, if your "make VERBOSE=1"
> results prove that is the case, then your next step should be to
> configure your build system so that an -rpath option is used by the
> linker so that the system loader for your executable can find the
> library in its non-standard location at run time.
>
> My own linking experience (currently with CMake-3.6.2 and higher) is just
> limited to my Debian platform at this time, but I do successfully
> use some libraries that are installed in non-standard system
> locations.  And my experience is a properly configured CMake-based
> build system links those libraries with the appropriate -rpath option
> with good results (using the library version in the non-standard
> location) both at link time and run time.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171224/32d6fb89/attachment.html>

From drakedog2008 at outlook.com  Wed Dec 27 03:04:05 2017
From: drakedog2008 at outlook.com (LightGoLeft)
Date: Wed, 27 Dec 2017 01:04:05 -0700 (MST)
Subject: [CMake] CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32
 argument
Message-ID: <1514361845752-0.post@n2.nabble.com>

Hello, 

I am currently using TDM-GCC-64 (MinGW) and MSVC to build binaries on 64 bit
Windows to build both 32 and 64bit binaries. However, I found architecture
passed to GNUtoMS bat is determined by CMAKE_SIZEOF_VOID_P which is not
correctly set. 

For GCC, I set
  SET(CMAKE_CXX_FLAGS "-m32 ${CMAKE_CXX_FLAGS}")
  SET(CMAKE_C_FLAGS "-m32 ${CMAKE_C_FLAGS}")
But, message(${CMAKE_SIZEOF_VOID_P }) is always 8. That causes GNUtoMS
generating x64 *.lib from x86 *.a. I don't know whether this is a bug or by
design. 

Thanks, 
Hao. 




--
Sent from: http://cmake.3232098.n2.nabble.com/

From craig.scott at crascit.com  Wed Dec 27 08:35:44 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 28 Dec 2017 00:35:44 +1100
Subject: [CMake] CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC
 -m32 argument
In-Reply-To: <1514361845752-0.post@n2.nabble.com>
References: <1514361845752-0.post@n2.nabble.com>
Message-ID: <CA+dygYni3QwOWrA9=Su+P6S+x_=375kDDb69TzJYVk0vP3vC+Q@mail.gmail.com>

On Wed, Dec 27, 2017 at 7:04 PM, LightGoLeft <drakedog2008 at outlook.com>
wrote:

> Hello,
>
> I am currently using TDM-GCC-64 (MinGW) and MSVC to build binaries on 64
> bit
> Windows to build both 32 and 64bit binaries. However, I found architecture
> passed to GNUtoMS bat is determined by CMAKE_SIZEOF_VOID_P which is not
> correctly set.
>
> For GCC, I set
>   SET(CMAKE_CXX_FLAGS "-m32 ${CMAKE_CXX_FLAGS}")
>   SET(CMAKE_C_FLAGS "-m32 ${CMAKE_C_FLAGS}")
> But, message(${CMAKE_SIZEOF_VOID_P }) is always 8. That causes GNUtoMS
> generating x64 *.lib from x86 *.a. I don't know whether this is a bug or by
> design.
>

CMake determines the bitness of the target when it does its compiler
checks, which is performed at the first project() command it hits, and it
caches the result for all subsequent CMake invocations. If you need to pass
a flag like -m32 to build for 32-bit targets on a 64-bit host, you need to
use a toolchain file and specify the -m32 option in there. If you simply
add lines like your example above to your project's CMakeLists.txt file,
they won't be picked up properly when CMake does its compiler tests. The
correct way to specify this sort of flag in a toolchain file would look
something like this (note the use of ..._INIT variables):

set(CMAKE_C_FLAGS_INIT   -m32)
set(CMAKE_CXX_FLAGS_INIT -m32)

set(CMAKE_EXE_LINKER_FLAGS_INIT    -m32)
set(CMAKE_MODULE_LINKER_FLAGS_INIT -m32)
set(CMAKE_SHARED_LINKER_FLAGS_INIT -m32)

Your toolchain file should also be setting
CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_VERSION and CMAKE_SYSTEM_PROCESSOR to
whatever is appropriate for your target architecture/platform (sorry, I'm
not sure off the top of my head what these would typically be for your
case). Be sure to clear any previous build if you want to experiment with
this, since CMake caches its results after the first run.

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

From drakedog2008 at outlook.com  Wed Dec 27 22:13:10 2017
From: drakedog2008 at outlook.com (Hao Jiang)
Date: Thu, 28 Dec 2017 03:13:10 +0000
Subject: [CMake] CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC
 -m32 argument
In-Reply-To: <CA+dygYni3QwOWrA9=Su+P6S+x_=375kDDb69TzJYVk0vP3vC+Q@mail.gmail.com>
References: <1514361845752-0.post@n2.nabble.com>,
 <CA+dygYni3QwOWrA9=Su+P6S+x_=375kDDb69TzJYVk0vP3vC+Q@mail.gmail.com>
Message-ID: <MWHPR14MB1487EE03CFE1A46D316A543AC3040@MWHPR14MB1487.namprd14.prod.outlook.com>

Hi Scott,

Thanks for the reply. It worked.

Hao.
From: Craig Scott<mailto:craig.scott at crascit.com>
Sent: 2017?12?27? 21:35
To: LightGoLeft<mailto:drakedog2008 at outlook.com>
Cc: CMake<mailto:cmake at cmake.org>
Subject: Re: [CMake] CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32 argument



On Wed, Dec 27, 2017 at 7:04 PM, LightGoLeft <drakedog2008 at outlook.com<mailto:drakedog2008 at outlook.com>> wrote:
Hello,

I am currently using TDM-GCC-64 (MinGW) and MSVC to build binaries on 64 bit
Windows to build both 32 and 64bit binaries. However, I found architecture
passed to GNUtoMS bat is determined by CMAKE_SIZEOF_VOID_P which is not
correctly set.

For GCC, I set
  SET(CMAKE_CXX_FLAGS "-m32 ${CMAKE_CXX_FLAGS}")
  SET(CMAKE_C_FLAGS "-m32 ${CMAKE_C_FLAGS}")
But, message(${CMAKE_SIZEOF_VOID_P }) is always 8. That causes GNUtoMS
generating x64 *.lib from x86 *.a. I don't know whether this is a bug or by
design.

CMake determines the bitness of the target when it does its compiler checks, which is performed at the first project() command it hits, and it caches the result for all subsequent CMake invocations. If you need to pass a flag like -m32 to build for 32-bit targets on a 64-bit host, you need to use a toolchain file and specify the -m32 option in there. If you simply add lines like your example above to your project's CMakeLists.txt file, they won't be picked up properly when CMake does its compiler tests. The correct way to specify this sort of flag in a toolchain file would look something like this (note the use of ..._INIT variables):

set(CMAKE_C_FLAGS_INIT   -m32)
set(CMAKE_CXX_FLAGS_INIT -m32)

set(CMAKE_EXE_LINKER_FLAGS_INIT    -m32)
set(CMAKE_MODULE_LINKER_FLAGS_INIT -m32)
set(CMAKE_SHARED_LINKER_FLAGS_INIT -m32)

Your toolchain file should also be setting CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_VERSION and CMAKE_SYSTEM_PROCESSOR to whatever is appropriate for your target architecture/platform (sorry, I'm not sure off the top of my head what these would typically be for your case). Be sure to clear any previous build if you want to experiment with this, since CMake caches its results after the first run.

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

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

From mike.jackson at bluequartz.net  Thu Dec 28 17:49:47 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 28 Dec 2017 17:49:47 -0500
Subject: [CMake] How to determine or set the order that targets are built
Message-ID: <CAABC947-CA6F-4739-8743-1EE6023E1BC8@bluequartz.net>

My current project builds a bunch (30) different plugins that do NOT depend on each other. One of those plugins has about 200 files of highly templated C++ code to build which takes a while to compile and link. Meanwhile the other plugins only have about 20-40 files of "run-of-the-mill" c++ codes which all compile in a reasonably fast time. Is there a way to give a hint to CMake or the build system (Ninja or Visual Studio) to start the build of that target before the others? I know about the set target dependencies which in a way would solve the problem but I would hate to use that since there isn't an actual dependency and it really wouldn't work anyways. The link time for this large plugin is on the order of minutes on a FAST machine (Core i7 8700k overclocked).

Are the targets treated in lexographical order perhaps if there are no dependencies? I would definintely consider renaming the plugin if that meant it would kick off earlier.

Any suggestions would be great.

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net



From jomofisher at gmail.com  Thu Dec 28 17:58:47 2017
From: jomofisher at gmail.com (Jom O'Fisher)
Date: Thu, 28 Dec 2017 14:58:47 -0800
Subject: [CMake] Build failure due to {cd bindir} failed on Windows/Ninja
Message-ID: <CAMxEm-LkkOa8tu39H=RPihzEVyLzsfAd2KThGayY-+d_m-B2Vg@mail.gmail.com>

I have an issue that's really difficult to track down because it only seems
to repro on certain machines which don't have access to.

The sequence of events seems to be:
(1) Invoke cmake to generate ninja project. Success.
* Note that generated rules.ninja has .o compilation dependencies with
absolute paths and .so link dependencies with relative paths.
(2) Invoke "cmake --build my-path --target my-target"
(3) CMake changes tries to change it's working directory here:
https://github.com/Kitware/CMake/blob/08ce62bee5bee6805fbb01c1821c43
8028e858dc/Source/cmGlobalGenerator.cxx#L1811
(4) Evidence suggests this fails and is silently ignored here:
https://github.com/Kitware/CMake/blob/967ba2e18055943faabf6eec39703b
cad95a7551/Source/cmWorkingDirectory.cxx#L10
(5) CMake invokes ninja.exe to build.
(6) Ninja eventually tries to link the resulting .so and this fails because
the .so path is relative in rules.ninja and the output folder doesn't exist
relative to the current directory.

A common theme of the machines this repros on seems to be that they run a
non-US-English Windows. There has to be more to it though because I tried
that myself and still didn't repro. A theory I had was that CMakeCache.txt
is written in some encoding that loses information in the presence of
Unicode characters. I tried this and it didn't seem to pan out.

Mainly I'd like to see if anyone has ideas that would help me reproduce the
issue and also whether you suspect it may be fixed in versions of CMake
after 3.6.

My tracking bug which has the full history: https://issuetracker.
google.com/37131900

Thanks for your help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20171228/1fcddec8/attachment.html>

From hintonda at gmail.com  Thu Dec 28 18:39:43 2017
From: hintonda at gmail.com (Don Hinton)
Date: Thu, 28 Dec 2017 15:39:43 -0800
Subject: [CMake] How to determine or set the order that targets are built
In-Reply-To: <CAABC947-CA6F-4739-8743-1EE6023E1BC8@bluequartz.net>
References: <CAABC947-CA6F-4739-8743-1EE6023E1BC8@bluequartz.net>
Message-ID: <CAL2T-v5BWdqJJsAL7DP+fjFvng3wnKuphoko0GdY85et800Oew@mail.gmail.com>

Take a look at job pools which are implemented in ninja.

You should be able to setup 2 pools and put the expensive target in one
pool and the rest in the other, which should give you the desired behavior.

  https://cmake.org/cmake/help/latest/prop_gbl/JOB_POOLS.html
  https://ninja-build.org/manual.html#ref_pool

hth...
don

On Thu, Dec 28, 2017 at 2:49 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> My current project builds a bunch (30) different plugins that do NOT
> depend on each other. One of those plugins has about 200 files of highly
> templated C++ code to build which takes a while to compile and link.
> Meanwhile the other plugins only have about 20-40 files of
> "run-of-the-mill" c++ codes which all compile in a reasonably fast time. Is
> there a way to give a hint to CMake or the build system (Ninja or Visual
> Studio) to start the build of that target before the others? I know about
> the set target dependencies which in a way would solve the problem but I
> would hate to use that since there isn't an actual dependency and it really
> wouldn't work anyways. The link time for this large plugin is on the order
> of minutes on a FAST machine (Core i7 8700k overclocked).
>
> Are the targets treated in lexographical order perhaps if there are no
> dependencies? I would definintely consider renaming the plugin if that
> meant it would kick off earlier.
>
> Any suggestions would be great.
>
> --
> Michael Jackson | Owner, President
>       BlueQuartz Software
> [e] mike.jackson at bluequartz.net
> [w] www.bluequartz.net
>
>
> --
>
> 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/20171228/87f0b291/attachment.html>

From Andreas-Naumann at gmx.net  Fri Dec 29 06:06:47 2017
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Fri, 29 Dec 2017 12:06:47 +0100
Subject: [CMake] cmake-server, path length for pipe
Message-ID: <f18840ea-7f56-e0b4-489b-e7b936c7cba2@gmx.net>

Hey cmakers,

I use visual studio code with the extension "vscode-cmake-tools" [1]. 
This extension uses the cmake-server functionality,
Recently, I have encountered the strange error message
     [cmake-server] CMake Error: Internal Error with 
<longPath>/release/.cmserver.18775: EADDRINUSE

where the length of longPath is 101 characters. The same error is also 
discussed in the issue 197 in [2].

After that, I did two small tests using the cmake server. Starting from 
the longPath above, I tried

     cmake -E server --experimental --pipe=`pwd`/release/foo
and
     cmake -E server --experimental --pipe=./release/foo

The first test led to the error, whereas the second one worked.

Is there a path length restriction for the cmake server?

And there is an error in the cmake-server manpage. The pipe argument is 
"--pipe=<named pipe> " instead of "--pipe <named pipe>"

I used cmake version 3.9.5.

Regards,
Andreas



[1] https://github.com/vector-of-bool/vscode-cmake-tools/
[2] https://github.com/vector-of-bool/vscode-cmake-tools/issues/197

From m.tmatma at gmail.com  Sat Dec 30 04:56:57 2017
From: m.tmatma at gmail.com (masaru tsuchiyama)
Date: Sat, 30 Dec 2017 18:56:57 +0900
Subject: [CMake] Install cmake 3.10.1 failed
Message-ID: <CAKQP9eeAq2Y7gPP608yArsxujLfho5K4rJT-PMLeFAA9aToy+Q@mail.gmail.com>

Hi,

I tried to install cmake 3.10.1 (cmake-3.10.1-Darwin-x86_64.dmg) to Mac OS
X High Sierra. But it failed with the attached error.

cmake 3.9.4 has been already installed on the machine.


The error message says some necessary items were not found, the operation
couldn't be completed (the error code is -43).

What should I do to fix it?

Regards.
Masaru.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20171230/e5233650/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot1.png
Type: image/png
Size: 75696 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20171230/e5233650/attachment-0001.png>

From m.tmatma at gmail.com  Sat Dec 30 04:59:11 2017
From: m.tmatma at gmail.com (masaru tsuchiyama)
Date: Sat, 30 Dec 2017 18:59:11 +0900
Subject: [CMake] how to build cmake installer for Mac OSX
Message-ID: <CAKQP9efT-nmsNsE49PKr9qLMtyt-QFdD6KZuGx5wRf95KujOKg@mail.gmail.com>

Hi,

Could you tell me how to build cmake installer for Mac OSX (dmg file)?

Regards.
Masaru.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20171230/26708d15/attachment.html>

From noflaco at gmail.com  Sat Dec 30 06:10:07 2017
From: noflaco at gmail.com (Carlton Banks)
Date: Sat, 30 Dec 2017 12:10:07 +0100
Subject: [CMake] Install cmake 3.10.1 failed
In-Reply-To: <CAKQP9ecZiPAYRm8qaE1a67sBad6eQLAU-Qvz2e3zH6ecx5Gzjw@mail.gmail.com>
References: <CAKQP9eeAq2Y7gPP608yArsxujLfho5K4rJT-PMLeFAA9aToy+Q@mail.gmail.com>
 <8EBC2308-4969-468F-9707-C7309D9033BD@gmail.com>
 <CAKQP9ecZiPAYRm8qaE1a67sBad6eQLAU-Qvz2e3zH6ecx5Gzjw@mail.gmail.com>
Message-ID: <70FBF576-2E20-475B-84FB-61D90486A307@gmail.com>

redirected..

> Den 30. dec. 2017 kl. 12.09 skrev masaru tsuchiyama <m.tmatma at gmail.com>:
> 
> Hi,
> 
> Thank you for the reply.
> I installed from the GUI installer.
> 
> I could find the reason and fix the problem.
> There was a file system error and the error had nothing to do with cmake installer.
> 
> I booted my Mac with the safe mode by pressing command + R key.
> By booting the safe mode, Mac boot disk error seems to be fixed automatically.
> 
> Regards.
> Masaru.
> 
> 
> 
> 2017-12-30 19:13 GMT+09:00 Noflanco <noflaco at gmail.com <mailto:noflaco at gmail.com>>:
> Have you tried to install from the terminal....   btw. What does it say when you type cmake -v in the terminal?
> 
> > Den 30. dec. 2017 kl. 10.56 skrev masaru tsuchiyama <m.tmatma at gmail.com <mailto:m.tmatma at gmail.com>>:
> >
> > Hi,
> >
> > I tried to install cmake 3.10.1 (cmake-3.10.1-Darwin-x86_64.dmg) to Mac OS X High Sierra. But it failed with the attached error.
> >
> > cmake 3.9.4 has been already installed on the machine.
> >
> >
> > The error message says some necessary items were not found, the operation couldn't be completed (the error code is -43).
> >
> > What should I do to fix it?
> >
> > Regards.
> > Masaru.
> >
> > <screenshot1.png>
> > --
> >
> > 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 <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 <http://cmake.org/cmake/help/support.html>
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
> > CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake <https://cmake.org/mailman/listinfo/cmake>
> 

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

From cgorac at gmail.com  Sat Dec 30 12:29:31 2017
From: cgorac at gmail.com (Crni Gorac)
Date: Sat, 30 Dec 2017 18:29:31 +0100
Subject: [CMake] how to find CUDA libraries under new CUDA framework?
Message-ID: <CAO65DGd9=t4MEWWohko4WO2uSJgsRt5NUaBoDV3=ZV2z571dmg@mail.gmail.com>

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.

From kris.f.thielemans at gmail.com  Sat Dec 30 17:28:25 2017
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 30 Dec 2017 23:28:25 +0100
Subject: [CMake] how to add a test that calls ctest
In-Reply-To: <003f01d37bc5$c558a0d0$5009e270$@gmail.com>
References: <003f01d37bc5$c558a0d0$5009e270$@gmail.com>
Message-ID: <053901d381bd$82e7d5b0$88b78110$@gmail.com>

Hi all

 

I've managed to solve my own question. The trick is to use the
$<CONFIGURATION>  generator expression. Here is the correct line (this time
with the add_test command included, which I had forgotten to copy-paste
before, which no doubt confused everyone).

 

add_test(NAME SIRF_TESTS

               COMMAND ${CMAKE_CTEST_COMMAND} -C $<CONFIGURATION> 

               WORKING_DIRECTORY
${CMAKE_CURRENT_BINARY_DIR}/SIRF-prefix/src/SIRF-build/)

 

Best wishes 

 

Kris 

 

From: Kris Thielemans 
Sent: 23 December 2017 09:12
To: 'CMake Mail List' <cmake at cmake.org>
Subject: how to add a test that calls ctest

 

Hi

 

We have a superbuild-type project
https://github.com/CCPPETMR/SIRF-SuperBuild where we want to add tests that
call ctest for the dependent projects. We do this as

 

 

               COMMAND ${CMAKE_CTEST_COMMAND} WORKING_DIRECTORY
${CMAKE_CURRENT_BINARY_DIR}/SIRF-prefix/src/SIRF-build/)

 

which works fine when using Makefiles, but fails with Visual Studio as we
don't pass the "-C config" flag. So how do we put this in? I tried

 

               COMMAND ${CMAKE_CTEST_COMMAND} -C ${CMAKE_CFG_INTDIR} -VV
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/SIRF-prefix/src/SIRF-build/)

 

But this gives me errors like

 

1: 4: Test command: NOT_AVAILABLE

1: Test not available in configuration "$(Configuration)".

 

Best wishes

 

 

Kris Thielemans
Reader in Medical Imaging Physics at University College London

 

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