From craig.scott at crascit.com  Wed Feb  1 08:11:17 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 2 Feb 2017 00:11:17 +1100
Subject: [CMake] CCACHE_DIR Environment Variable
In-Reply-To: <819107cb-7d5f-30fd-7015-f85982ec22fa@gmail.com>
References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com>
 <CA+dygYmOiKS7LgmUb+MryNNpORxLa5ezvcVvY8ms81o2J_wJeQ@mail.gmail.com>
 <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com>
 <CA+dygYmyVi_nOEyLQhP8XRb89GfMJ3dPUEEz5smko48Xjjof_A@mail.gmail.com>
 <C0826A79-FD48-43F8-AEEA-6C8327D55491@gmail.com>
 <CA+dygYncg=_Ac9wjRwn7xAxenU3T9ry5VjyNHwsYzVZVaK5Xqg@mail.gmail.com>
 <819107cb-7d5f-30fd-7015-f85982ec22fa@gmail.com>
Message-ID: <CA+dygY=Y5b_OwXzaZTs5wCND9Mg6Wc5pK3jyR+dKAE_xpMa7nw@mail.gmail.com>

For those following along, David's problem was related to the blog article
not routing the ccache calls through the launch scripts for Ninja and
Makefiles and instead invoking ccache directly. The Xcode arrangement was
the only thing using the launch scripts. While this was okay, it wasn't
necessarily what devs always expected. The article has been updated and now
shows how to route all three through the same set of launch scripts for
consistent behaviour.


On Wed, Feb 1, 2017 at 10:49 AM, Florent Castelli <
florent.castelli at gmail.com> wrote:

> On 31/01/2017 23:34, Craig Scott wrote:
>
>
> If you need to set CCACHE_DIR as an environment variable, then my previous
> email shows how to embed that in the launcher script, which will work for
> both Xcode and Linux (since the same launcher script is ultimately being
> invoked for both cases). All that said, I've never needed to set CCACHE_DIR
> and I mix OSX and iOS builds on the same machine. As has already been
> mentioned by someone else, ccache is smart enough to recognise the two
> builds as different because the command lines will be different, hence you
> don't get an iOS object file for a OSX build, for example.
>
> To that, I will add that ccache is certainly smart enough to save both
> iOS, macOS or Android builds in the same cache, but you need to be careful
> and maybe set higher limits for the cache size folder as the default one
> might not be suitable for your usage.
> See the documentation on how to set it higher.
>
> /Florent
>



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

From bballet at ivsweb.com  Wed Feb  1 11:16:14 2017
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Wed, 1 Feb 2017 17:16:14 +0100
Subject: [CMake] cmake install ends with error code 0xC0000022
Message-ID: <CAJoWGD2FvZq=bbEfUO+n4EKxoAtjz7FtPDkzbM_vw9z6p=O2+w@mail.gmail.com>

Hi,

I'm using install(CODE"... to run windeployqt.exe during installation

It works fine for a few exe or dll then it fails the installation with
error code 0xC0000022 because of the last execute_process(...
If I remove the incriminating dll, it fails with the next one.

Any hints ?


-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170201/9ef86ca5/attachment.html>

From matthew.woehlke at kitware.com  Wed Feb  1 15:12:37 2017
From: matthew.woehlke at kitware.com (Matthew Woehlke)
Date: Wed, 1 Feb 2017 15:12:37 -0500
Subject: [CMake] COMMAND dependencies with add_custom_command()
In-Reply-To: <CA+dygYkobX+iV0=VaiR3=sH4at=mD0PPsOk+FQ5jehX5ofSLvw@mail.gmail.com>
References: <CA+dygYkobX+iV0=VaiR3=sH4at=mD0PPsOk+FQ5jehX5ofSLvw@mail.gmail.com>
Message-ID: <58924135.9000507@kitware.com>

On 2017-01-25 20:25, Craig Scott wrote:
> The documentation for add_custom_command() contains this little nugget when
> discussing the COMMAND keyword:
> 
> If COMMAND specifies an executable target name ...<snip>... Additionally a
>> target-level dependency will be added so that the executable target will be
>> built before any target using this custom command. However this does NOT
>> add a file-level dependency that would cause the custom command to re-run
>> whenever the executable is recompiled.
> 
> I'm struggling to come up with a scenario where that last part about file
> level dependencies becomes relevant. Can anyone come up with a simple use
> case which highlights that particular aspect of dependencies and commands?

Let's start with an example, so we can talk about this concretely:

  add_executable(my_generator generate.cpp)
  add_custom_command(
    OUTPUT generated.out
    DEPENDS content.in
    COMMAND my_generator ...)

I think what this is saying is that the dependencies will be such that
if `generated.out` needs to be built, the build will ensure that
`my_generator` is built first (since the command would obviously fail
otherwise). However, the build will NOT be set up such that a change to
`generate.cpp` causes `generated.out` to be recreated. IOW, if
`generated.out` exists, it will only be considered "dirty" if it is
older than `content.in`, but NOT if it is older than `my_generator`.

Does that help?

-- 
Matthew

From M.Moller at tudelft.nl  Wed Feb  1 19:35:34 2017
From: M.Moller at tudelft.nl (=?utf-8?B?TWF0dGhpYXMgTcO2bGxlcg==?=)
Date: Thu, 2 Feb 2017 00:35:34 +0000
Subject: [CMake] Generate content of flags.make manually
Message-ID: <428F9E77-D7AD-438B-A324-D195C100E3FF@tudelft.nl>

Dear all,

for a JIT compiler framework I would like to store the compiler settings created by CMake and used to compile the main code in an XML file.
Under Linux/Mac I find all information I would need in the flags.make file that is generated if I choose "Unix Makefile? as target.

Example:

# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.7

# compile CXX with /usr/local/homebrew/bin/g++-6
CXX_FLAGS =  -Wall -Wno-long-long -Wattributes -ftrack-macro-expansion=0 -fopenmp -O2 -g    -std=c++11

CXX_DEFINES = -DMOTOR_DATA_DIR=\"/Users/mmoller/codes/gismo.svn/motor/filedata/\"

CXX_INCLUDES = -I/Users/mmoller/codes/gismo.svn/devel/src -I/Users/mmoller/codes/gismo.svn/stable/src -I/Users/mmoller/codes/gismo.svn/stable/external -I/Users/mmoller/codes/gismo.svn/stable/extensions -I/Users/mmoller/codes/gismo.svn/build-gcc6-compflow/stable/extensions/gsCoDiPack/CoDiPack/include -I/Users/mmoller/codes/gismo.svn/build-gcc6-compflow/stable -I/Users/mmoller/codes/gismo.svn/devel/external -I/Users/mmoller/codes/gismo.svn/build-gcc6-compflow/devel -I/Users/mmoller/codes/gismo.svn/motor/src -I/Users/mmoller/codes/gismo.svn/motor/tud/src


Is there an easy mechanism to explicitly force the generation of the above variables in CMakeLists.txt so that I could pass them to a configure file?

Thanks in advanced and kind regards,
Matthias


From Nospi at abwesend.de  Thu Feb  2 04:40:44 2017
From: Nospi at abwesend.de (Nospi at abwesend.de)
Date: Thu, 2 Feb 2017 10:40:44 +0100
Subject: [CMake] PCL+CUDA results in error: "nvcc fatal single input file is
 required" when compiled with Visual Studio 2015
Message-ID: <trinity-5a14cf76-30dd-42d6-a43f-4c828ac17fec-1486028444654@3capp-gmx-bs08>


Hi everyone,
I'd like to ask how to use find_package for PCL (http://pointclouds.org/) and CUDA in the same build. I get a fatal error from NVCC (see below) if i try.
To reproduce create a CMake file:
?
cmake_minimum_required(VERSION 3.4 FATAL_ERROR)
find_package(PCL 1.8 REQUIRED)
find_package(CUDA "8.0" REQUIRED)
cuda_add_library(cuda STATIC main.cu) # content of main.cu does not matter
?
?
?
Run cmake and compile with Visual Studio 2015.
For me this results in:
?
------ Build started: Project: cuda, Configuration: Release x64 ------
? Building NVCC (Device) object CMakeFiles/cuda.dir/Release/cuda_generated_main.cu.obj
? CMake Warning (dev) in cuda_generated_main.cu.obj.cmake:
??? Syntax Warning in cmake code at
?
????? <path>/CMakeFiles/cuda.dir/cuda_generated_main.cu.obj.cmake:79:146
?
??? Argument not separated from preceding token by whitespace.
? This warning is for project developers.? Use -Wno-dev to suppress it.
?
? CMake Warning (dev) in cuda_generated_main.cu.obj.cmake:
??? Syntax Warning in cmake code at
?
????? <path>/CMakeFiles/cuda.dir/cuda_generated_main.cu.obj.cmake:79:402
?
??? Argument not separated from preceding token by whitespace.
? This warning is for project developers.? Use -Wno-dev to suppress it.
?
? nvcc fatal?? : A single input file is required for a non-link phase when an outputfile is specified
?
? CMake Error at cuda_generated_main.cu.obj.cmake:207 (message):
??? Error generating
??? <path>/CMakeFiles/cuda.dir//Release/cuda_generated_main.cu.obj
?
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006: "cmd.exe" exited with code 1.
?
?
?
I found this page (http://idav.ucdavis.edu/~anjul/cudaErrors.htm) in regard to the nvcc error, it says to avoid using quotations in the nvcc include directories. In my case the ${CUDA_INCLUDE_DIRS} variable does not contain any quotations marks.
I posted to PCL user's mailing list a while ago but had no responses (http://www.pcl-users.org/Including-pcl-in-CMake-causes-error-if-also-including-cuda-td4042597.html).
FWIW, I had the same error when using PCL 1.7, CUDA 8.0 and Visual Studio 2012.

Up to now I'm stuck with separating CUDA and PCL in my source. Since that is getting more and more inconvenient, I'd be grateful for any hint how to resolve this.

Best regards,
Peter


?

From neewill+cmake at gmail.com  Thu Feb  2 06:12:47 2017
From: neewill+cmake at gmail.com (Neil Williams)
Date: Thu, 2 Feb 2017 11:12:47 +0000
Subject: [CMake] fixup_bundle fails for read-only .dylib files
Message-ID: <CAOqC5kegRS2ywmkcUNwOiJEwc6-M3k_=kw=4+AgP52pWES5+Sg@mail.gmail.com>

Hello,

We use perforce for our source control system, which has a typical
configuration where files need to be explicitly checked out prior to them
being changed. If they are not checked the files are marked as read only.

When trying to use fixup_bundle with a dylib in the perforce depot it
fails, as it copies the files from the source location into the .app bundle
and preserves the read-only flag, so the call to install_name_tool fails.

Using Cmake 2.8.11.2.

Should this be considered a cmake bug?

Any ideas/suggestions in the short term for a workaround?

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

From sergboec at yandex.ru  Thu Feb  2 10:15:45 2017
From: sergboec at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCR0L7QudGG0L7Qsg==?=)
Date: Thu, 02 Feb 2017 18:15:45 +0300
Subject: [CMake] Mac OS. Cmake changes it's behaviout when building
	framework for iOS simulator
Message-ID: <4566411486048545@web10o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170202/e5043517/attachment.html>

From andrew.amaclean at gmail.com  Thu Feb  2 18:01:46 2017
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 3 Feb 2017 10:01:46 +1100
Subject: [CMake] Changing /W3 to /W4 does not update CMakeCache.txt
Message-ID: <CAHDsG9PfgPRhNX5Ev0ab2c3wAvk8oS_FQ2WN6b71EjB1En6YUg@mail.gmail.com>

Consider the attached CMakeLists.txt script.

When run, CMAKE_CXX_FLAGS is updated correctly, however the line:
CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc
in CMakeCache.txt is never updated.

However the build instructions e.g build.ninja reflect the correct command:
 FLAGS = /DWIN32 /D_WINDOWS /W4 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1
Similarly for the Visual Studio Build.

I see this behaviour in my own code and also in VTK.

Is there a reason why CMakeCache.txt does not get the update?

Andrew


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170203/d7067a0a/attachment.html>
-------------- next part --------------
cmake_minimum_required(VERSION 3.7 FATAL_ERROR)

#-----------------------------------------------------------------------------
project ( FIIK )

#-----------------------------------------------------------------------------
# Directory where the CMakeFiles are
set ( CMAKE_FILE_DIR
  ${PROJECT_SOURCE_DIR}/CMake
)

#-----------------------------------------------------------------------------
# Set the compiler warning level and other compiler settings.
#include(${CMAKE_FILE_DIR}/DetermineCompilerFlags.cmake)

message("Old CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS}")
IF(MSVC)
# Use the highest warning level for visual c++ compiler.
  SET(CMAKE_CXX_WARNING_LEVEL 4)
  IF(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
    STRING(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
  ELSE(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
    SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
  ENDIF(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
ENDIF(MSVC)
message("New CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS}")

add_executable(${PROJECT_NAME} main.cxx)
-------------- next part --------------
#include <cstdlib>
int main()
{
    return EXIT_SUCCESS;
}

From craig.scott at crascit.com  Thu Feb  2 18:26:48 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 3 Feb 2017 10:26:48 +1100
Subject: [CMake] Changing /W3 to /W4 does not update CMakeCache.txt
In-Reply-To: <CAHDsG9PfgPRhNX5Ev0ab2c3wAvk8oS_FQ2WN6b71EjB1En6YUg@mail.gmail.com>
References: <CAHDsG9PfgPRhNX5Ev0ab2c3wAvk8oS_FQ2WN6b71EjB1En6YUg@mail.gmail.com>
Message-ID: <CA+dygYnBSq2nX51zaM83uLPLOghb67S4kmj2esJjpo5HDsXt7A@mail.gmail.com>

Your CMakeLists.txt file is modifying the *non-cache* variable
CMAKE_CXX_FLAGS. During CMake processing, a non-cache variable will
override a cache variable of the same name, but modifying a non-cache
variable won't update the cache. CMake is working as designed with regard
to the handling of CMAKE_CXX_FLAGS here, your expectation of the cache
being updated to reflect your changes to the non-cache variable is the
source of the confusion. Please review the following link which describes
this in more detail:

https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#variables


On Fri, Feb 3, 2017 at 10:01 AM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Consider the attached CMakeLists.txt script.
>
> When run, CMAKE_CXX_FLAGS is updated correctly, however the line:
> CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc
> in CMakeCache.txt is never updated.
>
> However the build instructions e.g build.ninja reflect the correct command:
>  FLAGS = /DWIN32 /D_WINDOWS /W4 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1
> Similarly for the Visual Studio Build.
>
> I see this behaviour in my own code and also in VTK.
>
> Is there a reason why CMakeCache.txt does not get the update?
>
> Andrew
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
>



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

From jchris.fillionr at kitware.com  Thu Feb  2 20:07:29 2017
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Thu, 2 Feb 2017 20:07:29 -0500
Subject: [CMake] Forcing linking compatability to old libc / libstdc++
	(Linux)
In-Reply-To: <1823948.9KigSHuUzn@linux-l7nd>
References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com>
 <1823948.9KigSHuUzn@linux-l7nd>
Message-ID: <CANLz8R7-5j6r3ofgAJWNXHtPVDg-x8B2f78J4+DiteM2guaDsg@mail.gmail.com>

Hi Gonzalo,

Using the dockcross/manylinux-x64 docker image should allow to build you
project out-of-the-box.
It is based on Centos5, include recent gcc, CMake, Git, etc ...

See https://github.com/dockcross/dockcross

In a nutshell,

# Pull image
docker pull dockcross/manylinux-x64

# Generate helper script
docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
chmod +x ./dockcross-manylinux-x64
mv ./dockcross-manylinux-x64 ~/bin/

# Build your project
cd /path/to/src
dockcross cmake -Bbuild -H. -GNinja


The directory build will then contain the build tree of your project
compiled using gcc provided by the Centos5 image and link against an old
glibc.

To learn more about the glibc version used in the image, see
https://www.python.org/dev/peps/pep-0513/

Hth
Jc






On Sun, Jan 29, 2017 at 4:36 PM, Alexander Neundorf <a.neundorf-work at gmx.net
> wrote:

> On 2017 M01 26, Thu 18:23:05 CET Gonzalo Garramu?o wrote:
> > I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my
> > work.    I distribute a binary image viewer.   However, recently one of
> > my users tried to run the viewer on a CentOS 7 distro and found out that
> > that distro libc and libstdc++ are older and incompatible.
> >
> > I would like to compile my program targeting the older libc and
> > libstdc++.  Those files come with symbol version and visibility. Is
> > there an easy way to do that other than copying the old libraries?
>
> you may consider using docker to provide a build environment for an "old"
> distribution (CentOS 7 is actually quite bleeding edge... ;-) )
> There are some CentOS5 images on dockerhub.
>
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170202/d9acecf7/attachment.html>

From andrew.amaclean at gmail.com  Thu Feb  2 20:19:35 2017
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 3 Feb 2017 12:19:35 +1100
Subject: [CMake] Changing /W3 to /W4 does not update CMakeCache.txt
In-Reply-To: <CA+dygYnBSq2nX51zaM83uLPLOghb67S4kmj2esJjpo5HDsXt7A@mail.gmail.com>
References: <CAHDsG9PfgPRhNX5Ev0ab2c3wAvk8oS_FQ2WN6b71EjB1En6YUg@mail.gmail.com>
 <CA+dygYnBSq2nX51zaM83uLPLOghb67S4kmj2esJjpo5HDsXt7A@mail.gmail.com>
Message-ID: <CAHDsG9MsOm7tFiOvNd6ew2_5mixXAcoKnNEK0ZDkUWKYNSd-Cw@mail.gmail.com>

Craig,
   Thanks for this, I had forgotten the distinction between non-cached
variables and cached variables

I guess the issue is that whilst it is possible to modify the cached entry,
it will never be used since the non-cached variable will always override it
whenever cmake is invoked.

Andrew

On Fri, Feb 3, 2017 at 10:26 AM, Craig Scott <craig.scott at crascit.com>
wrote:

> Your CMakeLists.txt file is modifying the *non-cache* variable
> CMAKE_CXX_FLAGS. During CMake processing, a non-cache variable will
> override a cache variable of the same name, but modifying a non-cache
> variable won't update the cache. CMake is working as designed with regard
> to the handling of CMAKE_CXX_FLAGS here, your expectation of the cache
> being updated to reflect your changes to the non-cache variable is the
> source of the confusion. Please review the following link which describes
> this in more detail:
>
> https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#variables
>
>
> On Fri, Feb 3, 2017 at 10:01 AM, Andrew Maclean <andrew.amaclean at gmail.com
> > wrote:
>
>> Consider the attached CMakeLists.txt script.
>>
>> When run, CMAKE_CXX_FLAGS is updated correctly, however the line:
>> CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc
>> in CMakeCache.txt is never updated.
>>
>> However the build instructions e.g build.ninja reflect the correct
>> command:
>>  FLAGS = /DWIN32 /D_WINDOWS /W4 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1
>> Similarly for the Visual Studio Build.
>>
>> I see this behaviour in my own code and also in VTK.
>>
>> Is there a reason why CMakeCache.txt does not get the update?
>>
>> Andrew
>>
>>
>> --
>> ___________________________________________
>> Andrew J. P. Maclean
>>
>> ___________________________________________
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>



-- 
___________________________________________
Andrew J. P. Maclean

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

From craig.scott at crascit.com  Thu Feb  2 20:24:38 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 3 Feb 2017 12:24:38 +1100
Subject: [CMake] Changing /W3 to /W4 does not update CMakeCache.txt
In-Reply-To: <CAHDsG9MsOm7tFiOvNd6ew2_5mixXAcoKnNEK0ZDkUWKYNSd-Cw@mail.gmail.com>
References: <CAHDsG9PfgPRhNX5Ev0ab2c3wAvk8oS_FQ2WN6b71EjB1En6YUg@mail.gmail.com>
 <CA+dygYnBSq2nX51zaM83uLPLOghb67S4kmj2esJjpo5HDsXt7A@mail.gmail.com>
 <CAHDsG9MsOm7tFiOvNd6ew2_5mixXAcoKnNEK0ZDkUWKYNSd-Cw@mail.gmail.com>
Message-ID: <CA+dygY=M6vbmxGw0713_VA1fQhHaF-sbTqWC2_T3WXvi0-67dg@mail.gmail.com>

See the first item on the following article for guidance on how to combine
cache and non-cache values for CMAKE_CXX_FLAGS:

http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/


On Fri, Feb 3, 2017 at 12:19 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Craig,
>    Thanks for this, I had forgotten the distinction between non-cached
> variables and cached variables
>
> I guess the issue is that whilst it is possible to modify the cached
> entry, it will never be used since the non-cached variable will always
> override it whenever cmake is invoked.
>
> Andrew
>
> On Fri, Feb 3, 2017 at 10:26 AM, Craig Scott <craig.scott at crascit.com>
> wrote:
>
>> Your CMakeLists.txt file is modifying the *non-cache* variable
>> CMAKE_CXX_FLAGS. During CMake processing, a non-cache variable will
>> override a cache variable of the same name, but modifying a non-cache
>> variable won't update the cache. CMake is working as designed with regard
>> to the handling of CMAKE_CXX_FLAGS here, your expectation of the cache
>> being updated to reflect your changes to the non-cache variable is the
>> source of the confusion. Please review the following link which describes
>> this in more detail:
>>
>> https://cmake.org/cmake/help/latest/manual/cmake-language.7.
>> html#variables
>>
>>
>> On Fri, Feb 3, 2017 at 10:01 AM, Andrew Maclean <
>> andrew.amaclean at gmail.com> wrote:
>>
>>> Consider the attached CMakeLists.txt script.
>>>
>>> When run, CMAKE_CXX_FLAGS is updated correctly, however the line:
>>> CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc
>>> in CMakeCache.txt is never updated.
>>>
>>> However the build instructions e.g build.ninja reflect the correct
>>> command:
>>>  FLAGS = /DWIN32 /D_WINDOWS /W4 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od
>>> /RTC1
>>> Similarly for the Visual Studio Build.
>>>
>>> I see this behaviour in my own code and also in VTK.
>>>
>>> Is there a reason why CMakeCache.txt does not get the update?
>>>
>>> Andrew
>>>
>>>
>>> --
>>> ___________________________________________
>>> Andrew J. P. Maclean
>>>
>>> ___________________________________________
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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
>>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>



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

From neewill+cmake at gmail.com  Fri Feb  3 06:23:57 2017
From: neewill+cmake at gmail.com (Neil Williams)
Date: Fri, 3 Feb 2017 11:23:57 +0000
Subject: [CMake] fixup_bundle fails for read-only .dylib files
In-Reply-To: <CAOqC5kegRS2ywmkcUNwOiJEwc6-M3k_=kw=4+AgP52pWES5+Sg@mail.gmail.com>
References: <CAOqC5kegRS2ywmkcUNwOiJEwc6-M3k_=kw=4+AgP52pWES5+Sg@mail.gmail.com>
Message-ID: <CAOqC5kcQ+mYKiZDUfR4o0KspSGd4vOeYvHS6Gr-2xJa7UHMU5A@mail.gmail.com>

Hello,

I have found a reasonable workaround, override the call to
fixup_bundle_item (called by fixup_bundle) and mark the file as writable:

install(CODE "
    INCLUDE (BundleUtilities)

    macro (fixup_bundle_item resolved_embedded_item exepath dirs)
        message (\"Making writable: \${resolved_embedded_item}\")
        execute_process (COMMAND chmod +w \${resolved_embedded_item})
        _fixup_bundle_item (\${resolved_embedded_item} \${exepath} \${dirs})
    endmacro()

    COPY_AND_FIXUP_BUNDLE (${CMAKE_INSTALL_PREFIX}/test.app
${CMAKE_INSTALL_PREFIX}/test2.app \"\" \"${LIBRARY_DIRECTORIES}\")
    "
    COMPONENT Runtime )

Hope this helps any future readers.

Thanks,
Neil

On Thu, Feb 2, 2017 at 11:12 AM, Neil Williams <neewill+cmake at gmail.com>
wrote:

> Hello,
>
> We use perforce for our source control system, which has a typical
> configuration where files need to be explicitly checked out prior to them
> being changed. If they are not checked the files are marked as read only.
>
> When trying to use fixup_bundle with a dylib in the perforce depot it
> fails, as it copies the files from the source location into the .app bundle
> and preserves the read-only flag, so the call to install_name_tool fails.
>
> Using Cmake 2.8.11.2.
>
> Should this be considered a cmake bug?
>
> Any ideas/suggestions in the short term for a workaround?
>
> Thanks,
> Neil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170203/27afb133/attachment.html>

From gjasny at googlemail.com  Fri Feb  3 07:59:22 2017
From: gjasny at googlemail.com (Gregor Jasny)
Date: Fri, 3 Feb 2017 13:59:22 +0100
Subject: [CMake] Mac OS. Cmake changes it's behaviout when building
 framework for iOS simulator
In-Reply-To: <4566411486048545@web10o.yandex.ru>
References: <4566411486048545@web10o.yandex.ru>
Message-ID: <1bcc8505-e987-7dd8-2b60-6e91f521b93f@googlemail.com>

Hello,

On 02/02/2017 16:15, ?????? ?????? wrote:
> Hello.
> I'm looking for some help cause i have faced a really strange problem
> with building frameworks on Mac OS
> So i have:
>
> Mac OS X : el captain
> Xcode 8.0
> CMake 3.3.2 [1],
> CMake 3.4.5 [2],
> CMake 3.5-3.6 [3]

> CMake [1] produced correct framework
> CMake [2] produced incorrect Version folder that points to C but no C
> folder is produced
> CMake [3] produced no Version folder at all

In contrast to macOS bundles the iOS ones have a more flattened 
structure without Version links:

https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1

See also https://cmake.org/Bug/view.php?id=15833

So the CMake 3.5/3.6 behavior is the desired one. CMake versions before 
were buggy in that regard.

Thanks,
Gregor

From doug.digglington at gmail.com  Fri Feb  3 13:25:14 2017
From: doug.digglington at gmail.com (Doug Digglington)
Date: Fri, 3 Feb 2017 10:25:14 -0800
Subject: [CMake] OSX RPATH linker flags not added on first build
Message-ID: <CACyyt5XMNsjcSiUHrdaekbfhbp0BG-mzCHtz2QQ15_pK5W3BqQ@mail.gmail.com>

Hello,

I am using ExternalProject to download and build a third-party library
(SDL) in my project. I am running into an issue on OSX where the RPATH
linker flags will not be added when my project is built and linked for the
first time. As a result the built executable will not have any RPATH paths
in it. However, when I rerun CMake or touch the main CMakeLists.txt file
and rebuild then the linker flags will be added appropriately.

I have tried explicitly setting the RPATH variables according to the "CMake
RPATH handling" page both for the default and "always full" scenarios but
that did not seem to change this behavior. Here is my current
CMakeLists.txt file:

cmake_minimum_required(VERSION 3.5)
project(shared_object)

set(CMAKE_MACOSX_RPATH TRUE)

set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/sdl/install)
set(LIB_DIR ${LIB_INSTALL_DIR}/lib)
set(LIB_PATH
${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX})

include(ExternalProject)
ExternalProject_Add(
    libsdl
    PREFIX ${CMAKE_BINARY_DIR}/sdl
    URL https://www.libsdl.org/release/SDL2-2.0.5.tar.gz
    URL_MD5 d4055424d556b4a908aa76fad63abd3c
    CMAKE_ARGS
        -DCMAKE_INSTALL_PREFIX=${LIB_INSTALL_DIR}
        -DCMAKE_MACOSX_RPATH=${CMAKE_MACOSX_RPATH}
        -DSDL_STATIC=FALSE
    INSTALL_DIR ${LIB_INSTALL_DIR}
)

add_library(sdl SHARED IMPORTED GLOBAL)
set_target_properties(sdl PROPERTIES
    IMPORTED_LOCATION ${LIB_PATH}
)
add_dependencies(sdl libsdl)
add_executable(shared_object main.cpp)
target_link_libraries(shared_object sdl)

When I run CMake for the first time here are the contents of the
CMakeFiles/shared_object.dir/link.txt file:

/Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
   -Wl,-search_paths_first -Wl,-headerpad_max_install_names
 CMakeFiles/shared_object.dir/main.cpp.o  -o shared_object
sdl/install/lib/libSDL2.dylib

Notice that there are no -Wl,-rpath linker flags. When I run `make` to
build the project there is no RPATH information in the built executable. I
checked this with `otool -l shared_object | grep -A2 RPATH`.

Now if I rerun CMake after everything has been built or if I touch the
CMakeLists.txt file before running `make` again then the contents of the
CMakeFiles/shared_object.dir/link.txt changes and the RPATH information is
linked into the built application. Here is the contents of
CMakeFiles/shared_object.dir/link.txt after I rerun CMake:

/Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
   -Wl,-search_paths_first -Wl,-headerpad_max_install_names
 CMakeFiles/shared_object.dir/main.cpp.o  -o shared_object
-Wl,-rpath,/var/tmp/so/sdl/install/lib sdl/install/lib/libSDL2.dylib

After rebuliding the application it will contain the expected RPATH
information:

otool -l shared_object | grep -A2 RPATH
cmd LC_RPATH
cmdsize 40
path /var/tmp/so/sdl/install/lib (offset 12)

Is there something that I am configuring incorrectly about the external
project or imported library that causes it to not be known or added to the
linker flags the first time CMake is run?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170203/0f882ab5/attachment.html>

From a.neundorf-work at gmx.net  Fri Feb  3 15:46:01 2017
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Fri, 03 Feb 2017 21:46:01 +0100
Subject: [CMake] Forcing linking compatability to old libc / libstdc++
	(Linux)
In-Reply-To: <CANLz8R7-5j6r3ofgAJWNXHtPVDg-x8B2f78J4+DiteM2guaDsg@mail.gmail.com>
References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com>
 <1823948.9KigSHuUzn@linux-l7nd>
 <CANLz8R7-5j6r3ofgAJWNXHtPVDg-x8B2f78J4+DiteM2guaDsg@mail.gmail.com>
Message-ID: <4552473.TgpQ8Zi4ua@linux-l7nd>

On 2017 M02 2, Thu 20:07:29 CET you wrote:
> Hi Gonzalo,
> 
> Using the dockcross/manylinux-x64 docker image should allow to build you
> project out-of-the-box.
> It is based on Centos5, include recent gcc, CMake, Git, etc ...
> 
> See https://github.com/dockcross/dockcross
> 
> In a nutshell,
> 
> # Pull image
> docker pull dockcross/manylinux-x64
> 
> # Generate helper script
> docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> chmod +x ./dockcross-manylinux-x64
> mv ./dockcross-manylinux-x64 ~/bin/
> 
> # Build your project
> cd /path/to/src
> dockcross cmake -Bbuild -H. -GNinja
> 
> 
> The directory build will then contain the build tree of your project
> compiled using gcc provided by the Centos5 image and link against an old
> glibc.

when docker starts, you are usually root in the container, and if then 
something is built, the files belong to root, and not the user as which you are 
logged in.
How do you handle that ?
I just found a hackish way (a shell script which sets up a user with the same 
numerical ID) to have the same user ID in the container as on the host system. 
Is there a better way ?

Alex


From craig.scott at crascit.com  Fri Feb  3 18:48:39 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 4 Feb 2017 10:48:39 +1100
Subject: [CMake] COMMAND dependencies with add_custom_command()
In-Reply-To: <58924135.9000507@kitware.com>
References: <CA+dygYkobX+iV0=VaiR3=sH4at=mD0PPsOk+FQ5jehX5ofSLvw@mail.gmail.com>
 <58924135.9000507@kitware.com>
Message-ID: <CA+dygYmn5QBuGOZXkJbO2zYpcLSUwHPpcdfmeto7fTQFQ5-NWg@mail.gmail.com>

Great, thanks. That was a similar case to the example I was using to
experiment with this stuff, I just hadn't picked up that if generated.out
already existed, it wouldn't be rebuilt if generate.cpp changed. Cheers.

On Thu, Feb 2, 2017 at 7:12 AM, Matthew Woehlke <matthew.woehlke at kitware.com
> wrote:

> On 2017-01-25 20:25, Craig Scott wrote:
> > The documentation for add_custom_command() contains this little nugget
> when
> > discussing the COMMAND keyword:
> >
> > If COMMAND specifies an executable target name ...<snip>... Additionally
> a
> >> target-level dependency will be added so that the executable target
> will be
> >> built before any target using this custom command. However this does NOT
> >> add a file-level dependency that would cause the custom command to
> re-run
> >> whenever the executable is recompiled.
> >
> > I'm struggling to come up with a scenario where that last part about file
> > level dependencies becomes relevant. Can anyone come up with a simple use
> > case which highlights that particular aspect of dependencies and
> commands?
>
> Let's start with an example, so we can talk about this concretely:
>
>   add_executable(my_generator generate.cpp)
>   add_custom_command(
>     OUTPUT generated.out
>     DEPENDS content.in
>     COMMAND my_generator ...)
>
> I think what this is saying is that the dependencies will be such that
> if `generated.out` needs to be built, the build will ensure that
> `my_generator` is built first (since the command would obviously fail
> otherwise). However, the build will NOT be set up such that a change to
> `generate.cpp` causes `generated.out` to be recreated. IOW, if
> `generated.out` exists, it will only be considered "dirty" if it is
> older than `content.in`, but NOT if it is older than `my_generator`.
>
> Does that help?
>
> --
> Matthew
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
>



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

From chuck.atkins at kitware.com  Fri Feb  3 20:32:58 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Fri, 3 Feb 2017 20:32:58 -0500
Subject: [CMake] Forcing linking compatability to old libc / libstdc++
	(Linux)
In-Reply-To: <4552473.TgpQ8Zi4ua@linux-l7nd>
References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com>
 <1823948.9KigSHuUzn@linux-l7nd>
 <CANLz8R7-5j6r3ofgAJWNXHtPVDg-x8B2f78J4+DiteM2guaDsg@mail.gmail.com>
 <4552473.TgpQ8Zi4ua@linux-l7nd>
Message-ID: <CAOXZzG5hUp6Y=z061dwht5N_22kFGs98=U1uB8bS9jyrKPHZBA@mail.gmail.com>

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

- Chuck

On Fri, Feb 3, 2017 at 3:46 PM, Alexander Neundorf <a.neundorf-work at gmx.net>
wrote:

> On 2017 M02 2, Thu 20:07:29 CET you wrote:
> > Hi Gonzalo,
> >
> > Using the dockcross/manylinux-x64 docker image should allow to build you
> > project out-of-the-box.
> > It is based on Centos5, include recent gcc, CMake, Git, etc ...
> >
> > See https://github.com/dockcross/dockcross
> >
> > In a nutshell,
> >
> > # Pull image
> > docker pull dockcross/manylinux-x64
> >
> > # Generate helper script
> > docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> > chmod +x ./dockcross-manylinux-x64
> > mv ./dockcross-manylinux-x64 ~/bin/
> >
> > # Build your project
> > cd /path/to/src
> > dockcross cmake -Bbuild -H. -GNinja
> >
> >
> > The directory build will then contain the build tree of your project
> > compiled using gcc provided by the Centos5 image and link against an old
> > glibc.
>
> when docker starts, you are usually root in the container, and if then
> something is built, the files belong to root, and not the user as which
> you are
> logged in.
> How do you handle that ?
> I just found a hackish way (a shell script which sets up a user with the
> same
> numerical ID) to have the same user ID in the container as on the host
> system.
> Is there a better way ?
>
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170203/b0fce4c2/attachment-0001.html>

From clinton at elemtech.com  Sat Feb  4 09:50:35 2017
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Sat, 4 Feb 2017 07:50:35 -0700 (MST)
Subject: [CMake] OSX RPATH linker flags not added on first build
In-Reply-To: <CACyyt5XMNsjcSiUHrdaekbfhbp0BG-mzCHtz2QQ15_pK5W3BqQ@mail.gmail.com>
References: <CACyyt5XMNsjcSiUHrdaekbfhbp0BG-mzCHtz2QQ15_pK5W3BqQ@mail.gmail.com>
Message-ID: <373302750.1423024.1486219835205.JavaMail.zimbra@elemtech.com>

----- On Feb 3, 2017, at 11:25 AM, Doug Digglington <doug.digglington at gmail.com> wrote: 

> Hello,

> I am using ExternalProject to download and build a third-party library (SDL) in
> my project. I am running into an issue on OSX where the RPATH linker flags will
> not be added when my project is built and linked for the first time. As a
> result the built executable will not have any RPATH paths in it. However, when
> I rerun CMake or touch the main CMakeLists.txt file and rebuild then the linker
> flags will be added appropriately.

> I have tried explicitly setting the RPATH variables according to the "CMake
> RPATH handling" page both for the default and "always full" scenarios but that
> did not seem to change this behavior. Here is my current CMakeLists.txt file:

> cmake_minimum_required(VERSION 3.5)
> project(shared_object)

> set(CMAKE_MACOSX_RPATH TRUE)

> set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/sdl/install)
> set(LIB_DIR ${LIB_INSTALL_DIR}/lib)
> set(LIB_PATH
> ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX})

> include(ExternalProject)
> ExternalProject_Add(
> libsdl
> PREFIX ${CMAKE_BINARY_DIR}/sdl
> URL [ https://www.libsdl.org/release/SDL2-2.0.5.tar.gz |
> https://www.libsdl.org/release/SDL2-2.0.5.tar.gz ]
> URL_MD5 d4055424d556b4a908aa76fad63abd3c
> CMAKE_ARGS
> -DCMAKE_INSTALL_PREFIX=${LIB_INSTALL_DIR}
> -DCMAKE_MACOSX_RPATH=${CMAKE_MACOSX_RPATH}
> -DSDL_STATIC=FALSE
> INSTALL_DIR ${LIB_INSTALL_DIR}
> )

> add_library(sdl SHARED IMPORTED GLOBAL)
> set_target_properties(sdl PROPERTIES
> IMPORTED_LOCATION ${LIB_PATH}
> )

You could try adding another property here. 
set_target_properties(sdl PROPERTIES IMPORTED_SONAME "@rpath/ ${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX}") 

With that hint, CMake would not need to wait until the library exists before being able to find out if it uses @rpath. 

And I see you also set CMAKE_MACOSX_RPATH=TRUE. That will only have an effect on any add_library() calls within the current scope (excluding imported libraries). 

Clint 

> add_dependencies(sdl libsdl)
> add_executable(shared_object main.cpp)
> target_link_libraries(shared_object sdl)

> When I run CMake for the first time here are the contents of the
> CMakeFiles/shared_object.dir/link.txt file:

> /Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> CMakeFiles/shared_object.dir/main.cpp.o -o shared_object
> sdl/install/lib/libSDL2.dylib

> Notice that there are no -Wl,-rpath linker flags. When I run `make` to build the
> project there is no RPATH information in the built executable. I checked this
> with `otool -l shared_object | grep -A2 RPATH`.

> Now if I rerun CMake after everything has been built or if I touch the
> CMakeLists.txt file before running `make` again then the contents of the
> CMakeFiles/shared_object.dir/link.txt changes and the RPATH information is
> linked into the built application. Here is the contents of
> CMakeFiles/shared_object.dir/link.txt after I rerun CMake:

> /Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> CMakeFiles/shared_object.dir/main.cpp.o -o shared_object
> -Wl,-rpath,/var/tmp/so/sdl/install/lib sdl/install/lib/libSDL2.dylib

> After rebuliding the application it will contain the expected RPATH information:

> otool -l shared_object | grep -A2 RPATH
> cmd LC_RPATH
> cmdsize 40
> path /var/tmp/so/sdl/install/lib (offset 12)

> Is there something that I am configuring incorrectly about the external project
> or imported library that causes it to not be known or added to the linker flags
> the first time CMake is run?

> --

> Powered by www.kitware.com

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

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

> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20170204/4629a68c/attachment.html>

From a.neundorf-work at gmx.net  Sat Feb  4 15:08:46 2017
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Sat, 04 Feb 2017 21:08:46 +0100
Subject: [CMake] Forcing linking compatability to old libc / libstdc++
	(Linux)
In-Reply-To: <CAOXZzG5hUp6Y=z061dwht5N_22kFGs98=U1uB8bS9jyrKPHZBA@mail.gmail.com>
References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com>
 <4552473.TgpQ8Zi4ua@linux-l7nd>
 <CAOXZzG5hUp6Y=z061dwht5N_22kFGs98=U1uB8bS9jyrKPHZBA@mail.gmail.com>
Message-ID: <1762367.5TY5c3AnoM@linux-l7nd>

On 2017 M02 3, Fri 20:32:58 CET you wrote:
> FWIW, we've moved to CentOS 6 for the binaries we package and distribute
> for ParaView.  It's about the oldest widely deployed Linux distro that's
> still actively supported (EL5 is EOL'd and most deployments have long since
> moved to 6 or 7).  

Yes, most, but not all ;-)

Alex


From joerg.krause at embedded.rocks  Sun Feb  5 17:03:54 2017
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Sun, 05 Feb 2017 23:03:54 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
Message-ID: <1486332234.12820.4.camel@embedded.rocks>

Hi,

when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
environment, CMake passes the host rpath to the linker:

""" CMakeOutput.log

/home/joerg/host/usr/bin/i586-linux-gcc??
--sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-Os???-DNDEBUG????CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o??-o
cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic /home/joerg/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
/home/joerg/host/usr/i586-buildroot-linux-
musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so?

"""

This leads to a linker error if mbedtls is linked with zlib, as the
linker tries to link with the host zlib and does not find the host
libc:

""" CMakeError.txt

/home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using -rpath
or -rpath-link)
/usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
/usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
/usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
[..]

"""

I did not find any solution which allows me to remove the rpath from
the check. Setting CMAKE_SKIP_RPATH does not change the build behaviour of the check_symbol_exists macro.

>From my understanding, the rpath flag should not be used when the
sysroot flag is passed to the linker, right?

For reference, I added a minimal example which uses Buildroot for
cross-compilation.

""" CMakeLists.txt

cmake_minimum_required(VERSION 2.8.12)

project(test)

list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")

find_package(MbedTLS)
if(MBEDTLS_FOUND)
	message(STATUS "Using mbedTLS")
endif()

"""

""" FindMbedTLS.cmake

include(CheckSymbolExists)

find_path(MBEDTLS_INCLUDE_DIRS
	NAMES mbedtls/ssl.h
	PATH_SUFFIXES include
)

find_library(MBEDTLS_LIBRARY NAMES mbedtls)
find_library(MBEDX509_LIBRARY NAMES mbedx509)
find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)

if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
	set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
	set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
	check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
MBEDTLS_V2)
endif()

"""

""" toolchainfile.cmake

string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
${CMAKE_CURRENT_LIST_DIR})

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR i586)

set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CFLAGS")
set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
CXXFLAGS")

# Build type from the Buildroot configuration
set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
configuration")

# Buildroot defaults flags.
set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
executables")

set(CMAKE_INSTALL_SO_NO_EXE 0)

set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
musl/sysroot")
set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
linux-musl/sysroot")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
buildroot-linux-musl/sysroot")

# This toolchain file can be used both inside and outside Buildroot.
set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-gcc")
set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-g++")

"""

What do I miss?

Best regards,
J?rg Krause



From brad.king at kitware.com  Mon Feb  6 10:45:16 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 6 Feb 2017 10:45:16 -0500
Subject: [CMake] Visual Studio: force use of folders
In-Reply-To: <46fe0e0a1448ce7eb6dc897491576839.squirrel@mail.ahans.de>
References: <46fe0e0a1448ce7eb6dc897491576839.squirrel@mail.ahans.de>
Message-ID: <bfec9579-824e-f6be-0ad7-962f9c492513@kitware.com>

On 01/31/2017 05:17 AM, Alexander Hans wrote:
> What we want is to use Visual Studio 2013 as IDE with the vc100 compilers.
> It is possible to create a Visual Studio 2010 solution with CMake and open
> and compile that with Visual Studio 2013.

Instead you should use the "Visual Studio 12 2013" generator but specify
the `vc100` toolset:

  cmake ../src -G "Visual Studio 12 2013" -T vc100

There is also an option in cmake-gui to do this on initial configuration
of a new build tree.  See also these docs:

  https://cmake.org/cmake/help/v3.7/variable/CMAKE_GENERATOR_TOOLSET.html

This way you get native generation for the VS 2013 IDE but the project
will use the `vc100` tools when built.

-Brad


From joerg.krause at embedded.rocks  Mon Feb  6 16:22:54 2017
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Mon, 06 Feb 2017 22:22:54 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <1486332234.12820.4.camel@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
Message-ID: <1486416174.4950.5.camel@embedded.rocks>

Hi,

On Sun, 2017-02-05 at 23:03 +0100, J?rg Krause wrote:
> Hi,
> 
> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> environment, CMake passes the host rpath to the linker:
> 
> """ CMakeOutput.log
> 
> /home/joerg/host/usr/bin/i586-linux-gcc??
> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -Os???-DNDEBUG????CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o??-o
> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> /home/joerg/host/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so?
> 
> """
> 
> This leads to a linker error if mbedtls is linked with zlib, as the
> linker tries to link with the host zlib and does not find the host
> libc:
> 
> """ CMakeError.txt
> 
> /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
> -rpath
> or -rpath-link)
> /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
> [..]
> 
> """
> 
> I did not find any solution which allows me to remove the rpath from
> the check. Setting CMAKE_SKIP_RPATH does not change the build
> behaviour of the check_symbol_exists macro.
> 
> From my understanding, the rpath flag should not be used when the
> sysroot flag is passed to the linker, right?
> 
> For reference, I added a minimal example which uses Buildroot for
> cross-compilation.
> 
> """ CMakeLists.txt
> 
> cmake_minimum_required(VERSION 2.8.12)
> 
> project(test)
> 
> list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> 
> find_package(MbedTLS)
> if(MBEDTLS_FOUND)
> 	message(STATUS "Using mbedTLS")
> endif()
> 
> """
> 
> """ FindMbedTLS.cmake
> 
> include(CheckSymbolExists)
> 
> find_path(MBEDTLS_INCLUDE_DIRS
> 	NAMES mbedtls/ssl.h
> 	PATH_SUFFIXES include
> )
> 
> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> find_library(MBEDX509_LIBRARY NAMES mbedx509)
> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> 
> if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> 	set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> 	set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> 	check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> MBEDTLS_V2)
> endif()
> 
> """
> 
> """ toolchainfile.cmake
> 
> string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> ${CMAKE_CURRENT_LIST_DIR})
> 
> set(CMAKE_SYSTEM_NAME Linux)
> set(CMAKE_SYSTEM_PROCESSOR i586)
> 
> set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CFLAGS")
> set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> CXXFLAGS")
> 
> # Build type from the Buildroot configuration
> set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> configuration")
> 
> # Buildroot defaults flags.
> set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> executables")
> 
> set(CMAKE_INSTALL_SO_NO_EXE 0)
> 
> set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> musl/sysroot")
> set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> linux-musl/sysroot")
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> buildroot-linux-musl/sysroot")
> 
> # This toolchain file can be used both inside and outside Buildroot.
> set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-gcc")
> set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> g++")
> 
> """
> 
> What do I miss?

Note, that this project was build using CMake 3.7.2 on Debian. When
using CMake 3.6.3, CMake does correctly not add rpath to the cross-
linker and the check_symbol_exists() succeeds.

J?rg

From joerg.krause at embedded.rocks  Mon Feb  6 18:16:06 2017
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Tue, 07 Feb 2017 00:16:06 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <1486416174.4950.5.camel@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
Message-ID: <1486422966.4950.7.camel@embedded.rocks>

On Mon, 2017-02-06 at 22:22 +0100, J?rg Krause wrote:
> Hi,
> 
> On Sun, 2017-02-05 at 23:03 +0100, J?rg Krause wrote:
> > Hi,
> > 
> > when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> > environment, CMake passes the host rpath to the linker:
> > 
> > """ CMakeOutput.log
> > 
> > /home/joerg/host/usr/bin/i586-linux-gcc??
> > --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > -Os???-
> > DNDEBUG????CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o??-o
> > cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> > /home/joerg/host/usr/i586-
> > buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> > /home/joerg/host/usr/i586-buildroot-linux-
> > musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> > buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so?
> > 
> > """
> > 
> > This leads to a linker error if mbedtls is linked with zlib, as the
> > linker tries to link with the host zlib and does not find the host
> > libc:
> > 
> > """ CMakeError.txt
> > 
> > /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
> > libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
> > -rpath
> > or -rpath-link)
> > /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
> > /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
> > /usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
> > [..]
> > 
> > """
> > 
> > I did not find any solution which allows me to remove the rpath
> > from
> > the check. Setting CMAKE_SKIP_RPATH does not change the build
> > behaviour of the check_symbol_exists macro.
> > 
> > From my understanding, the rpath flag should not be used when the
> > sysroot flag is passed to the linker, right?
> > 
> > For reference, I added a minimal example which uses Buildroot for
> > cross-compilation.
> > 
> > """ CMakeLists.txt
> > 
> > cmake_minimum_required(VERSION 2.8.12)
> > 
> > project(test)
> > 
> > list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> > 
> > find_package(MbedTLS)
> > if(MBEDTLS_FOUND)
> > 	message(STATUS "Using mbedTLS")
> > endif()
> > 
> > """
> > 
> > """ FindMbedTLS.cmake
> > 
> > include(CheckSymbolExists)
> > 
> > find_path(MBEDTLS_INCLUDE_DIRS
> > 	NAMES mbedtls/ssl.h
> > 	PATH_SUFFIXES include
> > )
> > 
> > find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> > find_library(MBEDX509_LIBRARY NAMES mbedx509)
> > find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> > 
> > if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> > 	set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> > 	set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> > ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> > 	check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> > MBEDTLS_V2)
> > endif()
> > 
> > """
> > 
> > """ toolchainfile.cmake
> > 
> > string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> > ${CMAKE_CURRENT_LIST_DIR})
> > 
> > set(CMAKE_SYSTEM_NAME Linux)
> > set(CMAKE_SYSTEM_PROCESSOR i586)
> > 
> > set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> > set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> > set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > CFLAGS")
> > set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > CXXFLAGS")
> > 
> > # Build type from the Buildroot configuration
> > set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> > configuration")
> > 
> > # Buildroot defaults flags.
> > set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> > set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> > set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> > executables")
> > 
> > set(CMAKE_INSTALL_SO_NO_EXE 0)
> > 
> > set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> > set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> > musl/sysroot")
> > set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> > linux-musl/sysroot")
> > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> > set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> > buildroot-linux-musl/sysroot")
> > 
> > # This toolchain file can be used both inside and outside
> > Buildroot.
> > set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> > gcc")
> > set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> > g++")
> > 
> > """
> > 
> > What do I miss?
> 
> Note, that this project was build using CMake 3.7.2 on Debian. When
> using CMake 3.6.3, CMake does correctly not add rpath to the cross-
> linker and the check_symbol_exists() succeeds.

I did a git bisect. The behaviour was introduced in commit
896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].

My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.

[1] https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3
cbbcf9a6cce85a16681

Best regards,
J?rg Krause

From mingw.android at gmail.com  Mon Feb  6 20:46:39 2017
From: mingw.android at gmail.com (Ray Donnelly)
Date: Tue, 7 Feb 2017 01:46:39 +0000
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <1486422966.4950.7.camel@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
Message-ID: <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>

I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.

It is the right way to do it IMHO, but I need to find time to finish it
unfortunately.

On Feb 6, 2017 11:16 PM, "J?rg Krause" <joerg.krause at embedded.rocks> wrote:

> On Mon, 2017-02-06 at 22:22 +0100, J?rg Krause wrote:
> > Hi,
> >
> > On Sun, 2017-02-05 at 23:03 +0100, J?rg Krause wrote:
> > > Hi,
> > >
> > > when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> > > environment, CMake passes the host rpath to the linker:
> > >
> > > """ CMakeOutput.log
> > >
> > > /home/joerg/host/usr/bin/i586-linux-gcc
> > > --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> > > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > > -Os   -
> > > DNDEBUG    CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o  -o
> > > cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> > > /home/joerg/host/usr/i586-
> > > buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> > > /home/joerg/host/usr/i586-buildroot-linux-
> > > musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> > > buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
> > >
> > > """
> > >
> > > This leads to a linker error if mbedtls is linked with zlib, as the
> > > linker tries to link with the host zlib and does not find the host
> > > libc:
> > >
> > > """ CMakeError.txt
> > >
> > > /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
> > > libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
> > > -rpath
> > > or -rpath-link)
> > > /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
> > > /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
> > > /usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
> > > [..]
> > >
> > > """
> > >
> > > I did not find any solution which allows me to remove the rpath
> > > from
> > > the check. Setting CMAKE_SKIP_RPATH does not change the build
> > > behaviour of the check_symbol_exists macro.
> > >
> > > From my understanding, the rpath flag should not be used when the
> > > sysroot flag is passed to the linker, right?
> > >
> > > For reference, I added a minimal example which uses Buildroot for
> > > cross-compilation.
> > >
> > > """ CMakeLists.txt
> > >
> > > cmake_minimum_required(VERSION 2.8.12)
> > >
> > > project(test)
> > >
> > > list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> > >
> > > find_package(MbedTLS)
> > > if(MBEDTLS_FOUND)
> > >     message(STATUS "Using mbedTLS")
> > > endif()
> > >
> > > """
> > >
> > > """ FindMbedTLS.cmake
> > >
> > > include(CheckSymbolExists)
> > >
> > > find_path(MBEDTLS_INCLUDE_DIRS
> > >     NAMES mbedtls/ssl.h
> > >     PATH_SUFFIXES include
> > > )
> > >
> > > find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> > > find_library(MBEDX509_LIBRARY NAMES mbedx509)
> > > find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> > >
> > > if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> > >     set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> > >     set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> > > ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> > >     check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> > > MBEDTLS_V2)
> > > endif()
> > >
> > > """
> > >
> > > """ toolchainfile.cmake
> > >
> > > string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> > > ${CMAKE_CURRENT_LIST_DIR})
> > >
> > > set(CMAKE_SYSTEM_NAME Linux)
> > > set(CMAKE_SYSTEM_PROCESSOR i586)
> > >
> > > set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> > > set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> > > set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > > CFLAGS")
> > > set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > > CXXFLAGS")
> > >
> > > # Build type from the Buildroot configuration
> > > set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> > > configuration")
> > >
> > > # Buildroot defaults flags.
> > > set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> > > set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> > > set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> > > executables")
> > >
> > > set(CMAKE_INSTALL_SO_NO_EXE 0)
> > >
> > > set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> > > set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> > > musl/sysroot")
> > > set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> > > linux-musl/sysroot")
> > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> > > set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> > > buildroot-linux-musl/sysroot")
> > >
> > > # This toolchain file can be used both inside and outside
> > > Buildroot.
> > > set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> > > gcc")
> > > set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> > > g++")
> > >
> > > """
> > >
> > > What do I miss?
> >
> > Note, that this project was build using CMake 3.7.2 on Debian. When
> > using CMake 3.6.3, CMake does correctly not add rpath to the cross-
> > linker and the check_symbol_exists() succeeds.
>
> I did a git bisect. The behaviour was introduced in commit
> 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
>
> My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
> FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.
>
> [1] https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3
> cbbcf9a6cce85a16681
>
> Best regards,
> J?rg Krause
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20170207/773609af/attachment-0001.html>

From joerg.krause at embedded.rocks  Tue Feb  7 03:37:40 2017
From: joerg.krause at embedded.rocks (joerg.krause at embedded.rocks)
Date: Tue, 07 Feb 2017 09:37:40 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
Message-ID: <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>

Hi Ray,

Am 2017-02-07 02:46, schrieb Ray Donnelly:
> I have a PR that asks the linker (via the compiler) what its implicit
> search directories are instead.
> 
> It is the right way to do it IMHO, but I need to find time to finish
> it unfortunately.

Do you have a link to the PR?

> On Feb 6, 2017 11:16 PM, "J?rg Krause" <joerg.krause at embedded.rocks>
> wrote:
> 
>> On Mon, 2017-02-06 at 22:22 +0100, J?rg Krause wrote:
>>> Hi,
>>> 
>>> On Sun, 2017-02-05 at 23:03 +0100, J?rg Krause wrote:
>>>> Hi,
>>>> 
>>>> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
>>>> environment, CMake passes the host rpath to the linker:
>>>> 
>>>> """ CMakeOutput.log
>>>> 
>>>> /home/joerg/host/usr/bin/i586-linux-gcc
>>>> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
>>>> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
>>>> -Os -
>>>> DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
>>>> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
>>>> /home/joerg/host/usr/i586-
>>>> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
>>>> /home/joerg/host/usr/i586-buildroot-linux-
>>>> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
>>>> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
>>>> 
>>>> """
>>>> 
>>>> This leads to a linker error if mbedtls is linked with zlib, as
>> the
>>>> linker tries to link with the host zlib and does not find the
>> host
>>>> libc:
>>>> 
>>>> """ CMakeError.txt
>>>> 
>>>> /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
>>>> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
>>>> -rpath
>>>> or -rpath-link)
>>>> /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
>>>> /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
>>>> /usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
>>>> [..]
>>>> 
>>>> """
>>>> 
>>>> I did not find any solution which allows me to remove the rpath
>>>> from
>>>> the check. Setting CMAKE_SKIP_RPATH does not change the build
>>>> behaviour of the check_symbol_exists macro.
>>>> 
>>>> From my understanding, the rpath flag should not be used when
>> the
>>>> sysroot flag is passed to the linker, right?
>>>> 
>>>> For reference, I added a minimal example which uses Buildroot
>> for
>>>> cross-compilation.
>>>> 
>>>> """ CMakeLists.txt
>>>> 
>>>> cmake_minimum_required(VERSION 2.8.12)
>>>> 
>>>> project(test)
>>>> 
>>>> list(APPEND CMAKE_MODULE_PATH
>> "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
>>>> 
>>>> find_package(MbedTLS)
>>>> if(MBEDTLS_FOUND)
>>>> message(STATUS "Using mbedTLS")
>>>> endif()
>>>> 
>>>> """
>>>> 
>>>> """ FindMbedTLS.cmake
>>>> 
>>>> include(CheckSymbolExists)
>>>> 
>>>> find_path(MBEDTLS_INCLUDE_DIRS
>>>> NAMES mbedtls/ssl.h
>>>> PATH_SUFFIXES include
>>>> )
>>>> 
>>>> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
>>>> find_library(MBEDX509_LIBRARY NAMES mbedx509)
>>>> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
>>>> 
>>>> if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
>>>> set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
>>>> set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
>>>> ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
>>>> check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
>>>> MBEDTLS_V2)
>>>> endif()
>>>> 
>>>> """
>>>> 
>>>> """ toolchainfile.cmake
>>>> 
>>>> string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
>>>> ${CMAKE_CURRENT_LIST_DIR})
>>>> 
>>>> set(CMAKE_SYSTEM_NAME Linux)
>>>> set(CMAKE_SYSTEM_PROCESSOR i586)
>>>> 
>>>> set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
>>>> set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
>>>> set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
>>>> CFLAGS")
>>>> set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
>>>> CXXFLAGS")
>>>> 
>>>> # Build type from the Buildroot configuration
>>>> set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
>>>> configuration")
>>>> 
>>>> # Buildroot defaults flags.
>>>> set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>>>> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
>>>> set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>>>> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
>>>> set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS
>> for
>>>> executables")
>>>> 
>>>> set(CMAKE_INSTALL_SO_NO_EXE 0)
>>>> 
>>>> set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
>>>> set(CMAKE_SYSROOT
>> "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
>>>> musl/sysroot")
>>>> set(CMAKE_FIND_ROOT_PATH
>> "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
>>>> linux-musl/sysroot")
>>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>>> set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
>>>> buildroot-linux-musl/sysroot")
>>>> 
>>>> # This toolchain file can be used both inside and outside
>>>> Buildroot.
>>>> set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
>>>> gcc")
>>>> set(CMAKE_CXX_COMPILER
>> "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
>>>> g++")
>>>> 
>>>> """
>>>> 
>>>> What do I miss?
>>> 
>>> Note, that this project was build using CMake 3.7.2 on Debian.
>> When
>>> using CMake 3.6.3, CMake does correctly not add rpath to the
>> cross-
>>> linker and the check_symbol_exists() succeeds.
>> 
>> I did a git bisect. The behaviour was introduced in commit
>> 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
>> 
>> My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
>> FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.
>> 
>> [1]
>> https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3
>> cbbcf9a6cce85a16681
>> 
>> Best regards,
>> J?rg Krause
>> --
>> 
>> Powered by www.kitware.com [1]
>> 
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ [2]
>> 
>> Kitware offers various services to support the CMake community. For
>> more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html [3]
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html [4]
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> [5]
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html [6]
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake [7]
> 
> 
> Links:
> ------
> [1] http://www.kitware.com
> [2] http://www.cmake.org/Wiki/CMake_FAQ
> [3] http://cmake.org/cmake/help/support.html
> [4] http://cmake.org/cmake/help/consulting.html
> [5] http://cmake.org/cmake/help/training.html
> [6] http://www.kitware.com/opensource/opensource.html
> [7] http://public.kitware.com/mailman/listinfo/cmake


From mingw.android at gmail.com  Tue Feb  7 04:40:26 2017
From: mingw.android at gmail.com (Ray Donnelly)
Date: Tue, 7 Feb 2017 09:40:26 +0000
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
Message-ID: <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>

The PR Is closed pending me writing a test-case, but I just now
updated to the my latest version and rebased on top of master:

https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fdaab7d8b812d503f67f8cef69532


Cheers.


On Tue, Feb 7, 2017 at 8:37 AM,  <joerg.krause at embedded.rocks> wrote:
> Hi Ray,
>
> Am 2017-02-07 02:46, schrieb Ray Donnelly:
>>
>> I have a PR that asks the linker (via the compiler) what its implicit
>> search directories are instead.
>>
>> It is the right way to do it IMHO, but I need to find time to finish
>> it unfortunately.
>
>
> Do you have a link to the PR?
>
>> On Feb 6, 2017 11:16 PM, "J?rg Krause" <joerg.krause at embedded.rocks>
>> wrote:
>>
>>> On Mon, 2017-02-06 at 22:22 +0100, J?rg Krause wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Sun, 2017-02-05 at 23:03 +0100, J?rg Krause wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
>>>>> environment, CMake passes the host rpath to the linker:
>>>>>
>>>>> """ CMakeOutput.log
>>>>>
>>>>> /home/joerg/host/usr/bin/i586-linux-gcc
>>>>> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
>>>>> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
>>>>> -Os -
>>>>> DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
>>>>> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
>>>>> /home/joerg/host/usr/i586-
>>>>> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
>>>>> /home/joerg/host/usr/i586-buildroot-linux-
>>>>> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
>>>>> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
>>>>>
>>>>> """
>>>>>
>>>>> This leads to a linker error if mbedtls is linked with zlib, as
>>>
>>> the
>>>>>
>>>>> linker tries to link with the host zlib and does not find the
>>>
>>> host
>>>>>
>>>>> libc:
>>>>>
>>>>> """ CMakeError.txt
>>>>>
>>>>> /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
>>>>> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
>>>>> -rpath
>>>>> or -rpath-link)
>>>>> /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
>>>>> /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
>>>>> /usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
>>>>> [..]
>>>>>
>>>>> """
>>>>>
>>>>> I did not find any solution which allows me to remove the rpath
>>>>> from
>>>>> the check. Setting CMAKE_SKIP_RPATH does not change the build
>>>>> behaviour of the check_symbol_exists macro.
>>>>>
>>>>> From my understanding, the rpath flag should not be used when
>>>
>>> the
>>>>>
>>>>> sysroot flag is passed to the linker, right?
>>>>>
>>>>> For reference, I added a minimal example which uses Buildroot
>>>
>>> for
>>>>>
>>>>> cross-compilation.
>>>>>
>>>>> """ CMakeLists.txt
>>>>>
>>>>> cmake_minimum_required(VERSION 2.8.12)
>>>>>
>>>>> project(test)
>>>>>
>>>>> list(APPEND CMAKE_MODULE_PATH
>>>
>>> "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
>>>>>
>>>>>
>>>>> find_package(MbedTLS)
>>>>> if(MBEDTLS_FOUND)
>>>>> message(STATUS "Using mbedTLS")
>>>>> endif()
>>>>>
>>>>> """
>>>>>
>>>>> """ FindMbedTLS.cmake
>>>>>
>>>>> include(CheckSymbolExists)
>>>>>
>>>>> find_path(MBEDTLS_INCLUDE_DIRS
>>>>> NAMES mbedtls/ssl.h
>>>>> PATH_SUFFIXES include
>>>>> )
>>>>>
>>>>> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
>>>>> find_library(MBEDX509_LIBRARY NAMES mbedx509)
>>>>> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
>>>>>
>>>>> if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
>>>>> set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
>>>>> set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
>>>>> ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
>>>>> check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
>>>>> MBEDTLS_V2)
>>>>> endif()
>>>>>
>>>>> """
>>>>>
>>>>> """ toolchainfile.cmake
>>>>>
>>>>> string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
>>>>> ${CMAKE_CURRENT_LIST_DIR})
>>>>>
>>>>> set(CMAKE_SYSTEM_NAME Linux)
>>>>> set(CMAKE_SYSTEM_PROCESSOR i586)
>>>>>
>>>>> set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
>>>>> set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
>>>>> set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
>>>>> CFLAGS")
>>>>> set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
>>>>> CXXFLAGS")
>>>>>
>>>>> # Build type from the Buildroot configuration
>>>>> set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
>>>>> configuration")
>>>>>
>>>>> # Buildroot defaults flags.
>>>>> set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>>>>> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
>>>>> set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>>>>> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
>>>>> set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS
>>>
>>> for
>>>>>
>>>>> executables")
>>>>>
>>>>> set(CMAKE_INSTALL_SO_NO_EXE 0)
>>>>>
>>>>> set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
>>>>> set(CMAKE_SYSROOT
>>>
>>> "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
>>>>>
>>>>> musl/sysroot")
>>>>> set(CMAKE_FIND_ROOT_PATH
>>>
>>> "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
>>>>>
>>>>> linux-musl/sysroot")
>>>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>>>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>>>> set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
>>>>> buildroot-linux-musl/sysroot")
>>>>>
>>>>> # This toolchain file can be used both inside and outside
>>>>> Buildroot.
>>>>> set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
>>>>> gcc")
>>>>> set(CMAKE_CXX_COMPILER
>>>
>>> "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
>>>>>
>>>>> g++")
>>>>>
>>>>> """
>>>>>
>>>>> What do I miss?
>>>>
>>>>
>>>> Note, that this project was build using CMake 3.7.2 on Debian.
>>>
>>> When
>>>>
>>>> using CMake 3.6.3, CMake does correctly not add rpath to the
>>>
>>> cross-
>>>>
>>>> linker and the check_symbol_exists() succeeds.
>>>
>>>
>>> I did a git bisect. The behaviour was introduced in commit
>>> 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
>>>
>>> My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
>>> FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.
>>>
>>> [1]
>>> https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3
>>> cbbcf9a6cce85a16681
>>>
>>> Best regards,
>>> J?rg Krause
>>> --
>>>
>>> Powered by www.kitware.com [1]
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ [2]
>>>
>>> Kitware offers various services to support the CMake community. For
>>> more information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html [3]
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html [4]
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>> [5]
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html [6]
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake [7]
>>
>>
>>
>> Links:
>> ------
>> [1] http://www.kitware.com
>> [2] http://www.cmake.org/Wiki/CMake_FAQ
>> [3] http://cmake.org/cmake/help/support.html
>> [4] http://cmake.org/cmake/help/consulting.html
>> [5] http://cmake.org/cmake/help/training.html
>> [6] http://www.kitware.com/opensource/opensource.html
>> [7] http://public.kitware.com/mailman/listinfo/cmake
>
>

From nkwmailinglists at gmail.com  Tue Feb  7 12:36:25 2017
From: nkwmailinglists at gmail.com (Kent Williams)
Date: Tue, 07 Feb 2017 17:36:25 +0000
Subject: [CMake] Why can't I build CMake on Centos6 32-bit?
Message-ID: <CAA4Dnn2Wa4Yn03SPpjyK1RMa4SZTVc9kuMd-w_wHFcWBGMMCxA@mail.gmail.com>

This used to work.
Linux build6.leepfrog.com 2.6.32-642.6.2.el6.i686 #1 SMP Wed Oct 26
06:14:53 UTC 2016 i686 i686 i386 GNU/Linux

gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
The first part of the bootstrap succeeds, and then running the second stage
yields this:

loading initial cache file
/home/kwilliams/develop/cmake/build6/Bootstrap.cmk/InitialCacheFlags.cmake
CMake Error at Modules/CMakeCompilerIdDetection.cmake:28 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  Modules/CMakeDetermineCompilerId.cmake:114 (compiler_id_detection)
  Modules/CMakeDetermineCompilerId.cmake:132
(CMAKE_DETERMINE_COMPILER_ID_WRITE)
  Modules/CMakeDetermineCompilerId.cmake:30
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:11 (project)


CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
  file problem creating directory:
  /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC
Call Stack (most recent call first):
  Modules/CMakeDetermineCompilerId.cmake:30
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:11 (project)


CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
  file problem creating directory:
  /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC
Call Stack (most recent call first):
  Modules/CMakeDetermineCompilerId.cmake:30
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:11 (project)


CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
  file problem creating directory:
  /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC
Call Stack (most recent call first):
  Modules/CMakeDetermineCompilerId.cmake:30
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:11 (project)


-- The C compiler identification is unknown
CMake Error: Could not find cmake module file:
/home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CMakeCCompiler.cmake
CMake Error at Modules/CMakeCompilerIdDetection.cmake:28 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  Modules/CMakeDetermineCompilerId.cmake:114 (compiler_id_detection)
  Modules/CMakeDetermineCompilerId.cmake:132
(CMAKE_DETERMINE_COMPILER_ID_WRITE)
  Modules/CMakeDetermineCompilerId.cmake:30
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  Modules/CMakeDetermineCXXCompiler.cmake:104 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:11 (project)


CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
  file problem creating directory:
  /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdCXX
Call Stack (most recent call first):
  Modules/CMakeDetermineCompilerId.cmake:30
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  Modules/CMakeDetermineCXXCompiler.cmake:104 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:11 (project)


-- The CXX compiler identification is unknown
CMake Error: Could not find cmake module file:
/home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CMakeCXXCompiler.cmake
-- Check for working C compiler: /usr/bin/gcc
CMake Error at Modules/CMakeTestCCompiler.cmake:37 (try_compile):
  Unknown extension ".c" for file

    /home/kwilliams/develop/cmake/build6/CMakeFiles/CMakeTmp/testCCompiler.c

  try_compile() works only for enabled languages.  Currently these are:

    C CXX

  See project() command to enable other languages.
Call Stack (most recent call first):
  CMakeLists.txt:11 (project)


-- Check for working C compiler: /usr/bin/gcc -- broken
CMake Error at Modules/CMakeTestCCompiler.cmake:51 (message):
  The C compiler "/usr/bin/gcc" is not able to compile a simple test
program.

  It fails with the following output:





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:11 (project)


-- Configuring incomplete, errors occurred!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170207/d97f65a6/attachment.html>

From robert.maynard at kitware.com  Tue Feb  7 13:13:22 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 7 Feb 2017 13:13:22 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!
Message-ID: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>

I am proud to announce the first CMake 3.8 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.8

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.8/release/3.8.html

Some of the more significant changes in CMake 3.8 are:

* CMake now supports "CSharp" (C#) as a first-class language. It is
  currently supported by the Visual Studio Generators for VS 2010
  and above.

* CMake now supports "CUDA" as a first-class language. It is
  currently supported by the Makefile Generators and the
  "Ninja" generator on Linux, macOS, and Windows. Support for the
  Visual Studio IDE is under development but not included in this
  release.

* The "Compile Features" functionality now offers meta-features that
  request compiler modes for specific language standard levels (e.g.
  "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
  "CMAKE_CXX_KNOWN_FEATURES".

* The "Compile Features" functionality is now aware of C++ 17.  No
  specific features are yet enumerated besides the "cxx_std_17" meta-
  feature.

* The Visual Studio Generators for VS 2013 and above learned to
  support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
  (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
  toolchain on 64-bit hosts.

* The Visual Studio Generators learned to treat files passed to
  "target_link_libraries()" whose names end in ".targets" as MSBuild
  "targets" files to be imported into generated project files.

* The "try_compile()" command source file signature gained new
  options to specify the language standard to use in the generated
  test project.

* The "try_compile()" command source file signature now honors
  language standard variables like "CMAKE_CXX_STANDARD". See policy
  "CMP0067".

* A "BUILD_RPATH" target property and corresponding
  "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
  locations to be added to binaries in the build tree.

* The "COMPILE_FLAGS" source file property learned to support
  "generator expressions".

* A new generator expression "$<IF:cond,true-value,false-value>" was
  added. It resolves to the true-value if the condition is "1" and
  resolves to the false-value if the condition is "0".

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
  and Windows platforms.

* The Visual Studio Generators for VS 2010 and above now place per-
  source file flags after target-wide flags when they are classified
  as raw flags with no project file setting ("AdditionalOptions").
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on "cmake.org"
  now records the installation directory in the Windows Registry under
  the key "HKLM\Software\Kitware\CMake" with a value named
  "InstallDir".

CMake 3.8 Release Notes
***********************

Changes made since CMake 3.7 include the following.


New Features
============


Languages
---------


C#
~~

* CMake learned to support "CSharp" (C#) as a first-class language
  that can be enabled via the "project()" and "enable_language()"
  commands.  It is currently supported by the Visual Studio Generators
  for VS 2010 and above.

  C# assemblies and programs can be added just like common C++ targets
  using the "add_library()" and "add_executable()" commands.
  References between C# targets in the same source tree may be
  specified by "target_link_libraries()" like for C++.  References to
  system or 3rd-party assemblies may be specified by the target
  properties "VS_DOTNET_REFERENCE_<refname>" and
  "VS_DOTNET_REFERENCES".

* More fine tuning of C# targets may be done using target and source
  file properties.  Specifically the target properties related to
  Visual Studio ("VS_*") are worth a look (for setting toolset
  versions, root namespaces, assembly icons, ...).

* Auto-linking in ".csproj" files: In C#/.NET development with
  Visual Studio there are a number of visual editors used which
  generate code.  Both the generated files and the ones edited with
  the UI are connected in the ".csproj" file using "<DependentUpon>"
  tags.  If CMake finds within a C# project any source file with
  extension ".Designer.cs" or ".xaml.cs", it checks sibling files with
  extension ".xaml", ".settings", ".resx" or ".cs" and establishes the
  dependency connection.


CUDA
~~~~

* CMake learned to support "CUDA" as a first-class language that can
  be enabled via the "project()" and "enable_language()" commands.

* "CUDA" is currently supported by the Makefile Generators and the
  "Ninja" generator on Linux, macOS, and Windows. Support for the
  Visual Studio IDE is under development but not included in this
  release.

* The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.


C & C++
~~~~~~~

* The "Compile Features" functionality now offers meta-features that
  request compiler modes for specific language standard levels (e.g.
  "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
  "CMAKE_CXX_KNOWN_FEATURES".

* The "Compile Features" functionality is now aware of C++ 17.  No
  specific features are yet enumerated besides the "cxx_std_17" meta-
  feature.

* The "Compile Features" functionality is now aware of the
  availability of C99 in gcc since version 3.4.


Platforms
---------

* A new minimal platform file for "Fuchsia" was added.


Generators
----------

* The "CodeBlocks" extra generator may now be used to generate with
  "NMake Makefiles JOM".

* The Visual Studio Generators for VS 2013 and above learned to
  support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
  (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
  toolchain on 64-bit hosts.

* The Visual Studio Generators learned to treat files passed to
  "target_link_libraries()" whose names end in ".targets" as MSBuild
  "targets" files to be imported into generated project files.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned the option "COMMAND_EXPAND_LISTS" which causes lists in the
  "COMMAND" argument to be expanded, including lists created by
  generator expressions.

* The "execute_process()" command gained an "ENCODING" option to
  specify on Windows which encoding is used for output from child
  process.

* The "math(EXPR)" command gained support for unary "+" and "-"
  operators.

* The "source_group()" command gained "TREE" and "PREFIX" options to
  add groups following source tree directory structure.

* The "string(TIMESTAMP)" command learned to treat "%%" as a way to
  encode plain "%".

* The "string(TIMESTAMP)" command will now honor the
  "SOURCE_DATE_EPOCH" environment variable and use its value instead
  of the current time.

* The "try_compile()" command source file signature gained new
  options to specify the language standard to use in the generated
  test project.

* The "try_compile()" command source file signature now honors
  language standard variables like "CMAKE_CXX_STANDARD". See policy
  "CMP0067".


Variables
---------

* A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the
  "CodeLite" extra generator to change the generated project to have
  target-centric organization. The "build", "rebuild", and "clean"
  operations within "CodeLite" then work on a selected target rather
  than the whole workspace. (Note that the "Ninja" clean operation on
  a target includes its dependencies, though.)

* The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell
  the "Sublime Text 2" extra generator to place specified environment
  variables in the generated ".sublime-project".

* The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added
  to tell the "Sublime Text 2" extra generator whether to exclude the
  build tree from the ".sublime-project" when it is inside the source
  tree.

* A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added
  to tell Visual Studio Generators for VS 2010 and above to include
  the "PACKAGE" target in the default build, similar to the existing
  "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the
  "INSTALL" target.


Properties
----------

* A "BUILD_RPATH" target property and corresponding
  "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
  locations to be added to binaries in the build tree.

* The "COMPILE_FLAGS" source file property learned to support
  "generator expressions".

* The "FRAMEWORK" target property may now also be applied to static
  libraries on Apple targets.  It will result in a proper Framework
  but with a static library inside.

* Imported Interface Libraries learned new "IMPORTED_LIBNAME" and
  "IMPORTED_LIBNAME_<CONFIG>" target properties to specify a link
  library name since interface libraries do not build their own
  library files.

* A "<LANG>_CPPLINT" target property and supporting
  "CMAKE_<LANG>_CPPLINT" variable were introduced to tell the Makefile
  Generators and the "Ninja" generator to run the "cpplint" style
  checker along with the compiler for "C" and "CXX" languages.

* A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It
  provides a read-only list of dependencies that have been added with
  the "add_dependencies()" command.

* The "MAP_IMPORTED_CONFIG_<CONFIG>" target property learned to
  interpret empty list elements as referring to the configuration-less
  imported location specified by "IMPORTED_LOCATION".

* The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on
  Imported Interface Libraries.

* New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC",
  "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files
  to be excluded from processing by "AUTOMOC", "AUTOUIC", and
  "AUTORCC" target properties.

* A "VS_COPY_TO_OUT_DIR" source file property was added to tell
  Visual Studio Generators for VS 2010 and above whether or not a file
  should e copied to the output directory.

* A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to
  tell Visual Studio Generators for VS 2010 and above what debugger
  working directory should be set for the target.

* A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to
  specify whether to copy referenced assemblies to the output
  directory.

* A "VS_DOTNET_REFERENCE_<refname>" target property was added to
  tell Visual Studio Generators for VS 2010 and above to add a .NET
  reference with a given hint path.

* A "VS_INCLUDE_IN_VSIX" source file property was added to tell
  Visual Studio Generators for VS 2010 and above whether to include
  the file in a Visual Studio extension package.

* A "VS_RESOURCE_GENERATOR" source file property was added to give
  Visual Studio Generators for VS 2010 and above a setting for the
  resource generator ("C#" only).

* A "VS_USER_PROPS" target property was added to tell Visual Studio
  Generators for VS 2010 and above to use a custom MSBuild user
  ".props" file.

* A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added
  to tell the "Xcode" generator whether to emit the
  "EFFECTIVE_PLATFORM_NAME" variable.  This is useful when building
  with multiple SDKs like "macosx" and "iphoneos" in parallel.

* New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target
  properties were created to tell the "Xcode" generator to use custom
  values of the corresponding attributes for a target in the generated
  Xcode project.


Modules
-------

* The "ExternalData" module learned to support multiple content
  links for one data file using different hashes, e.g.
  "img.png.sha256" and "img.png.sha1".  This allows objects to be
  fetched from sources indexed by different hash algorithms.

* The "ExternalProject" module gained the "GIT_PROGRESS" option to
  force Git to show progress when cloning repositories.

* The "ExternalProject" module gained a "GIT_CONFIG" option to pass
  " --config" options to Git when cloning repositories.

* The "FeatureSummary" module "feature_summary()" command now
  accepts a new "QUIET_ON_EMPTY" option that suppresses the output
  when the list of packages that belong to the selected category is
  empty.

* The "FeatureSummary" module "add_feature_info()" command now
  accepts lists of dependencies for deciding whether a feature is
  enabled or not.

* The package types accepted by the "FeatureSummary" module can now
  be tweaked by changing the "FeatureSummary_PKG_TYPES",
  "FeatureSummary_REQUIRED_PKG_TYPES" and
  "FeatureSummary_DEFAULT_PKG_TYPE" global properties.

* The "FindOpenGL" module now provides imported targets "OpenGL::GL"
  and "OpenGL::GLU" when the libraries are found.

* The "UseSWIG" module gained a "swig_add_library" command to give
  more flexibility over the old "swig_add_module" command.

* The "UseSWIG" module "swig_add_source_to_module" command learned a
  new "SWIG_OUTFILE_DIR" option to control the output file location
  ("swig -o").

* The "WriteCompilerDetectionHeader" module gained the
  "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS"
  options that allow creation of headers that will work also with
  unknown or old compilers by simply assuming they do not support any
  of the requested features.


CTest
-----

* The "ctest_memcheck()" command gained a "DEFECT_COUNT <var>"
  option to capture the number of memory defects detected.

* The "ctest_memcheck()" command learned to read the location of
  suppressions files for sanitizers from the
  "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable.

* The "ctest_memcheck()" command learned to support "LeakSanitizer"
  independently from "AddressSanitizer".

* The "ctest_update()" command "CDASH_UPLOAD" signature was taught
  to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options.


CPack
-----

* The "CPackIFWConfigureFile" module was added to define a new
  "cpack_ifw_configure_file()" command to configure file templates
  prepared in QtIFW/SDK/Creator style.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained a new
  "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION",
  "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT",
  "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS"
  options to more specific configuration.

* The "CPackIFW" module "cpack_ifw_configure_component()" command
  gained a new "DEPENDENCIES" alias for "DEPENDS" option.

* The "CPackIFW" module "cpack_ifw_configure_component_group()"
  command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also
  added.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands "PRIORITY" option
  now is deprecated and will be removed in a future version of CMake.
  Please use new "SORTING_PRIORITY" option instead.

* The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK",
  "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND",
  "CPACK_IFW_PACKAGE_WIZARD_STYLE",
  "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH",
  "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and
  "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW
  installer look.

* The "CPackProductBuild" module gained options to sign packages.
  See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME",
  "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME",
  and "CPACK_PKGBUILD_KEYCHAIN_PATH".

* The "CPackRPM" module learned to omit tags that are not supported
  by provided "rpmbuild" tool. If unsupported tags are set they are
  ignored and a developer warning is printed out.

* The "CPackRPM" module learned to generate main component package
  which forces generation of a rpm for defined component without
  component suffix in filename and package name. See
  "CPACK_RPM_MAIN_COMPONENT" variable.

* The "CPackRPM" module learned to generate a single "debuginfo"
  package on demand even if components packaging is used. See
  "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable.

* The "CPackRPM" module learned to support multiple directives per
  file when using "CPACK_RPM_USER_FILELIST" variable.


Other
-----

* CMake functionality using cryptographic hashes now supports SHA-3
  algorithms.

* A new generator expression "$<IF:cond,true-value,false-value>" was
  added. It resolves to the true-value if the condition is "1" and
  resolves to the false-value if the condition is "0".


Deprecated and Removed Features
===============================

* The "FeatureSummary" module commands "set_package_info()",
  "set_feature_info()", "print_enabled_features()", and
  "print_disabled_features()" are now deprecated.

* The "UseSWIG" module "swig_add_module" command is now deprecated
  in favor of "swig_add_library".


Other Changes
=============

* If a command specified by the "<LANG>_CLANG_TIDY" target property
  returns non-zero at build time this is now treated as an error
  instead of silently ignored.

* The "ctest_memcheck()" command no longer automatically adds
  "leak_check=1" to the options used by "AddressSanitizer". The
  default behavior of "AddressSanitizer" is to run *LeakSanitizer* to
  check leaks unless "leak_check=0".

* The "ctest_memcheck()" command was fixed to correctly append extra
  sanitizer options read from the
  "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment
  variables used internally by the sanitizers.

* The "FeatureSummary" module "set_package_properties()" command no
  longer forces the package type to "OPTIONAL" when the type is not
  explicitly set.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
  and Windows platforms.

* Calls to the "FindPkgConfig" module "pkg_check_modules()" command
  following a successful call learned to re-evaluate the cached values
  for a given prefix after changes to the parameters to the command
  for that prefix.

* When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and
  "ui_*" are placed in the
  "<CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include" directory
  which is automatically added to the target's "INCLUDE_DIRECTORIES".
  It is therefore not necessary anymore to have
  "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES".

* The "Sublime Text 2" generator no longer runs the native build
  command (e.g. "ninja" or "make") with verbose build output enabled.

* The "try_compile()" command source file signature now honors the
  "CMAKE_WARN_DEPRECATED" variable value in the generated test
  project.

* The Visual Studio Generators for VS 2010 and above now place per-
  source file flags after target-wide flags when they are classified
  as raw flags with no project file setting ("AdditionalOptions").
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on "cmake.org"
  now records the installation directory in the Windows Registry under
  the key "HKLM\Software\Kitware\CMake" with a value named
  "InstallDir".

From mike.jackson at bluequartz.net  Tue Feb  7 14:23:06 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Tue, 07 Feb 2017 14:23:06 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!
In-Reply-To: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>
References: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>
Message-ID: <589A1E9A.2080505@bluequartz.net>

Are there any improvements to the cmake -server mode? I am testing the 
combination of QtCreator and CMake and there seemed to be an issue where 
the list of projects are in Alphabetical order and not in a "top down" 
order.
-- 
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net


Robert Maynard wrote:
> I am proud to announce the first CMake 3.8 release candidate.
>    https://cmake.org/download/
>
> Documentation is available at:
>    https://cmake.org/cmake/help/v3.8
>
> Release notes appear below and are also published at
>    https://cmake.org/cmake/help/v3.8/release/3.8.html
>
> Some of the more significant changes in CMake 3.8 are:
>
> * CMake now supports "CSharp" (C#) as a first-class language. It is
>    currently supported by the Visual Studio Generators for VS 2010
>    and above.
>
> * CMake now supports "CUDA" as a first-class language. It is
>    currently supported by the Makefile Generators and the
>    "Ninja" generator on Linux, macOS, and Windows. Support for the
>    Visual Studio IDE is under development but not included in this
>    release.
>
> * The "Compile Features" functionality now offers meta-features that
>    request compiler modes for specific language standard levels (e.g.
>    "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
>    "CMAKE_CXX_KNOWN_FEATURES".
>
> * The "Compile Features" functionality is now aware of C++ 17.  No
>    specific features are yet enumerated besides the "cxx_std_17" meta-
>    feature.
>
> * The Visual Studio Generators for VS 2013 and above learned to
>    support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
>    (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
>    toolchain on 64-bit hosts.
>
> * The Visual Studio Generators learned to treat files passed to
>    "target_link_libraries()" whose names end in ".targets" as MSBuild
>    "targets" files to be imported into generated project files.
>
> * The "try_compile()" command source file signature gained new
>    options to specify the language standard to use in the generated
>    test project.
>
> * The "try_compile()" command source file signature now honors
>    language standard variables like "CMAKE_CXX_STANDARD". See policy
>    "CMP0067".
>
> * A "BUILD_RPATH" target property and corresponding
>    "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
>    locations to be added to binaries in the build tree.
>
> * The "COMPILE_FLAGS" source file property learned to support
>    "generator expressions".
>
> * A new generator expression "$<IF:cond,true-value,false-value>" was
>    added. It resolves to the true-value if the condition is "1" and
>    resolves to the false-value if the condition is "0".
>
> * The "Compile Features" functionality is now aware of features
>    supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
>    and Windows platforms.
>
> * The Visual Studio Generators for VS 2010 and above now place per-
>    source file flags after target-wide flags when they are classified
>    as raw flags with no project file setting ("AdditionalOptions").
>    This behavior is more consistent with the ordering of flags produced
>    by other generators, and allows flags on more-specific properties
>    (per-source) to override those on more general ones (per-target).
>
> * The precompiled Windows binary MSI package provided on "cmake.org"
>    now records the installation directory in the Windows Registry under
>    the key "HKLM\Software\Kitware\CMake" with a value named
>    "InstallDir".
>
> CMake 3.8 Release Notes
> ***********************
>
> Changes made since CMake 3.7 include the following.
>
>
> New Features
> ============
>
>
> Languages
> ---------
>
>
> C#
> ~~
>
> * CMake learned to support "CSharp" (C#) as a first-class language
>    that can be enabled via the "project()" and "enable_language()"
>    commands.  It is currently supported by the Visual Studio Generators
>    for VS 2010 and above.
>
>    C# assemblies and programs can be added just like common C++ targets
>    using the "add_library()" and "add_executable()" commands.
>    References between C# targets in the same source tree may be
>    specified by "target_link_libraries()" like for C++.  References to
>    system or 3rd-party assemblies may be specified by the target
>    properties "VS_DOTNET_REFERENCE_<refname>" and
>    "VS_DOTNET_REFERENCES".
>
> * More fine tuning of C# targets may be done using target and source
>    file properties.  Specifically the target properties related to
>    Visual Studio ("VS_*") are worth a look (for setting toolset
>    versions, root namespaces, assembly icons, ...).
>
> * Auto-linking in ".csproj" files: In C#/.NET development with
>    Visual Studio there are a number of visual editors used which
>    generate code.  Both the generated files and the ones edited with
>    the UI are connected in the ".csproj" file using "<DependentUpon>"
>    tags.  If CMake finds within a C# project any source file with
>    extension ".Designer.cs" or ".xaml.cs", it checks sibling files with
>    extension ".xaml", ".settings", ".resx" or ".cs" and establishes the
>    dependency connection.
>
>
> CUDA
> ~~~~
>
> * CMake learned to support "CUDA" as a first-class language that can
>    be enabled via the "project()" and "enable_language()" commands.
>
> * "CUDA" is currently supported by the Makefile Generators and the
>    "Ninja" generator on Linux, macOS, and Windows. Support for the
>    Visual Studio IDE is under development but not included in this
>    release.
>
> * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.
>
>
> C&  C++
> ~~~~~~~
>
> * The "Compile Features" functionality now offers meta-features that
>    request compiler modes for specific language standard levels (e.g.
>    "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
>    "CMAKE_CXX_KNOWN_FEATURES".
>
> * The "Compile Features" functionality is now aware of C++ 17.  No
>    specific features are yet enumerated besides the "cxx_std_17" meta-
>    feature.
>
> * The "Compile Features" functionality is now aware of the
>    availability of C99 in gcc since version 3.4.
>
>
> Platforms
> ---------
>
> * A new minimal platform file for "Fuchsia" was added.
>
>
> Generators
> ----------
>
> * The "CodeBlocks" extra generator may now be used to generate with
>    "NMake Makefiles JOM".
>
> * The Visual Studio Generators for VS 2013 and above learned to
>    support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
>    (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
>    toolchain on 64-bit hosts.
>
> * The Visual Studio Generators learned to treat files passed to
>    "target_link_libraries()" whose names end in ".targets" as MSBuild
>    "targets" files to be imported into generated project files.
>
>
> Commands
> --------
>
> * The "add_custom_command()" and "add_custom_target()" commands
>    learned the option "COMMAND_EXPAND_LISTS" which causes lists in the
>    "COMMAND" argument to be expanded, including lists created by
>    generator expressions.
>
> * The "execute_process()" command gained an "ENCODING" option to
>    specify on Windows which encoding is used for output from child
>    process.
>
> * The "math(EXPR)" command gained support for unary "+" and "-"
>    operators.
>
> * The "source_group()" command gained "TREE" and "PREFIX" options to
>    add groups following source tree directory structure.
>
> * The "string(TIMESTAMP)" command learned to treat "%%" as a way to
>    encode plain "%".
>
> * The "string(TIMESTAMP)" command will now honor the
>    "SOURCE_DATE_EPOCH" environment variable and use its value instead
>    of the current time.
>
> * The "try_compile()" command source file signature gained new
>    options to specify the language standard to use in the generated
>    test project.
>
> * The "try_compile()" command source file signature now honors
>    language standard variables like "CMAKE_CXX_STANDARD". See policy
>    "CMP0067".
>
>
> Variables
> ---------
>
> * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the
>    "CodeLite" extra generator to change the generated project to have
>    target-centric organization. The "build", "rebuild", and "clean"
>    operations within "CodeLite" then work on a selected target rather
>    than the whole workspace. (Note that the "Ninja" clean operation on
>    a target includes its dependencies, though.)
>
> * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell
>    the "Sublime Text 2" extra generator to place specified environment
>    variables in the generated ".sublime-project".
>
> * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added
>    to tell the "Sublime Text 2" extra generator whether to exclude the
>    build tree from the ".sublime-project" when it is inside the source
>    tree.
>
> * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added
>    to tell Visual Studio Generators for VS 2010 and above to include
>    the "PACKAGE" target in the default build, similar to the existing
>    "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the
>    "INSTALL" target.
>
>
> Properties
> ----------
>
> * A "BUILD_RPATH" target property and corresponding
>    "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
>    locations to be added to binaries in the build tree.
>
> * The "COMPILE_FLAGS" source file property learned to support
>    "generator expressions".
>
> * The "FRAMEWORK" target property may now also be applied to static
>    libraries on Apple targets.  It will result in a proper Framework
>    but with a static library inside.
>
> * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and
>    "IMPORTED_LIBNAME_<CONFIG>" target properties to specify a link
>    library name since interface libraries do not build their own
>    library files.
>
> * A "<LANG>_CPPLINT" target property and supporting
>    "CMAKE_<LANG>_CPPLINT" variable were introduced to tell the Makefile
>    Generators and the "Ninja" generator to run the "cpplint" style
>    checker along with the compiler for "C" and "CXX" languages.
>
> * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It
>    provides a read-only list of dependencies that have been added with
>    the "add_dependencies()" command.
>
> * The "MAP_IMPORTED_CONFIG_<CONFIG>" target property learned to
>    interpret empty list elements as referring to the configuration-less
>    imported location specified by "IMPORTED_LOCATION".
>
> * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on
>    Imported Interface Libraries.
>
> * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC",
>    "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files
>    to be excluded from processing by "AUTOMOC", "AUTOUIC", and
>    "AUTORCC" target properties.
>
> * A "VS_COPY_TO_OUT_DIR" source file property was added to tell
>    Visual Studio Generators for VS 2010 and above whether or not a file
>    should e copied to the output directory.
>
> * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to
>    tell Visual Studio Generators for VS 2010 and above what debugger
>    working directory should be set for the target.
>
> * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to
>    specify whether to copy referenced assemblies to the output
>    directory.
>
> * A "VS_DOTNET_REFERENCE_<refname>" target property was added to
>    tell Visual Studio Generators for VS 2010 and above to add a .NET
>    reference with a given hint path.
>
> * A "VS_INCLUDE_IN_VSIX" source file property was added to tell
>    Visual Studio Generators for VS 2010 and above whether to include
>    the file in a Visual Studio extension package.
>
> * A "VS_RESOURCE_GENERATOR" source file property was added to give
>    Visual Studio Generators for VS 2010 and above a setting for the
>    resource generator ("C#" only).
>
> * A "VS_USER_PROPS" target property was added to tell Visual Studio
>    Generators for VS 2010 and above to use a custom MSBuild user
>    ".props" file.
>
> * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added
>    to tell the "Xcode" generator whether to emit the
>    "EFFECTIVE_PLATFORM_NAME" variable.  This is useful when building
>    with multiple SDKs like "macosx" and "iphoneos" in parallel.
>
> * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target
>    properties were created to tell the "Xcode" generator to use custom
>    values of the corresponding attributes for a target in the generated
>    Xcode project.
>
>
> Modules
> -------
>
> * The "ExternalData" module learned to support multiple content
>    links for one data file using different hashes, e.g.
>    "img.png.sha256" and "img.png.sha1".  This allows objects to be
>    fetched from sources indexed by different hash algorithms.
>
> * The "ExternalProject" module gained the "GIT_PROGRESS" option to
>    force Git to show progress when cloning repositories.
>
> * The "ExternalProject" module gained a "GIT_CONFIG" option to pass
>    " --config" options to Git when cloning repositories.
>
> * The "FeatureSummary" module "feature_summary()" command now
>    accepts a new "QUIET_ON_EMPTY" option that suppresses the output
>    when the list of packages that belong to the selected category is
>    empty.
>
> * The "FeatureSummary" module "add_feature_info()" command now
>    accepts lists of dependencies for deciding whether a feature is
>    enabled or not.
>
> * The package types accepted by the "FeatureSummary" module can now
>    be tweaked by changing the "FeatureSummary_PKG_TYPES",
>    "FeatureSummary_REQUIRED_PKG_TYPES" and
>    "FeatureSummary_DEFAULT_PKG_TYPE" global properties.
>
> * The "FindOpenGL" module now provides imported targets "OpenGL::GL"
>    and "OpenGL::GLU" when the libraries are found.
>
> * The "UseSWIG" module gained a "swig_add_library" command to give
>    more flexibility over the old "swig_add_module" command.
>
> * The "UseSWIG" module "swig_add_source_to_module" command learned a
>    new "SWIG_OUTFILE_DIR" option to control the output file location
>    ("swig -o").
>
> * The "WriteCompilerDetectionHeader" module gained the
>    "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS"
>    options that allow creation of headers that will work also with
>    unknown or old compilers by simply assuming they do not support any
>    of the requested features.
>
>
> CTest
> -----
>
> * The "ctest_memcheck()" command gained a "DEFECT_COUNT<var>"
>    option to capture the number of memory defects detected.
>
> * The "ctest_memcheck()" command learned to read the location of
>    suppressions files for sanitizers from the
>    "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable.
>
> * The "ctest_memcheck()" command learned to support "LeakSanitizer"
>    independently from "AddressSanitizer".
>
> * The "ctest_update()" command "CDASH_UPLOAD" signature was taught
>    to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options.
>
>
> CPack
> -----
>
> * The "CPackIFWConfigureFile" module was added to define a new
>    "cpack_ifw_configure_file()" command to configure file templates
>    prepared in QtIFW/SDK/Creator style.
>
> * The "CPackIFW" module "cpack_ifw_configure_component()" and
>    "cpack_ifw_configure_component_group()" commands gained a new
>    "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION",
>    "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT",
>    "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS"
>    options to more specific configuration.
>
> * The "CPackIFW" module "cpack_ifw_configure_component()" command
>    gained a new "DEPENDENCIES" alias for "DEPENDS" option.
>
> * The "CPackIFW" module "cpack_ifw_configure_component_group()"
>    command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also
>    added.
>
> * The "CPackIFW" module "cpack_ifw_configure_component()" and
>    "cpack_ifw_configure_component_group()" commands "PRIORITY" option
>    now is deprecated and will be removed in a future version of CMake.
>    Please use new "SORTING_PRIORITY" option instead.
>
> * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK",
>    "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND",
>    "CPACK_IFW_PACKAGE_WIZARD_STYLE",
>    "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH",
>    "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and
>    "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW
>    installer look.
>
> * The "CPackProductBuild" module gained options to sign packages.
>    See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME",
>    "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME",
>    and "CPACK_PKGBUILD_KEYCHAIN_PATH".
>
> * The "CPackRPM" module learned to omit tags that are not supported
>    by provided "rpmbuild" tool. If unsupported tags are set they are
>    ignored and a developer warning is printed out.
>
> * The "CPackRPM" module learned to generate main component package
>    which forces generation of a rpm for defined component without
>    component suffix in filename and package name. See
>    "CPACK_RPM_MAIN_COMPONENT" variable.
>
> * The "CPackRPM" module learned to generate a single "debuginfo"
>    package on demand even if components packaging is used. See
>    "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable.
>
> * The "CPackRPM" module learned to support multiple directives per
>    file when using "CPACK_RPM_USER_FILELIST" variable.
>
>
> Other
> -----
>
> * CMake functionality using cryptographic hashes now supports SHA-3
>    algorithms.
>
> * A new generator expression "$<IF:cond,true-value,false-value>" was
>    added. It resolves to the true-value if the condition is "1" and
>    resolves to the false-value if the condition is "0".
>
>
> Deprecated and Removed Features
> ===============================
>
> * The "FeatureSummary" module commands "set_package_info()",
>    "set_feature_info()", "print_enabled_features()", and
>    "print_disabled_features()" are now deprecated.
>
> * The "UseSWIG" module "swig_add_module" command is now deprecated
>    in favor of "swig_add_library".
>
>
> Other Changes
> =============
>
> * If a command specified by the "<LANG>_CLANG_TIDY" target property
>    returns non-zero at build time this is now treated as an error
>    instead of silently ignored.
>
> * The "ctest_memcheck()" command no longer automatically adds
>    "leak_check=1" to the options used by "AddressSanitizer". The
>    default behavior of "AddressSanitizer" is to run *LeakSanitizer* to
>    check leaks unless "leak_check=0".
>
> * The "ctest_memcheck()" command was fixed to correctly append extra
>    sanitizer options read from the
>    "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment
>    variables used internally by the sanitizers.
>
> * The "FeatureSummary" module "set_package_properties()" command no
>    longer forces the package type to "OPTIONAL" when the type is not
>    explicitly set.
>
> * The "Compile Features" functionality is now aware of features
>    supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
>    and Windows platforms.
>
> * Calls to the "FindPkgConfig" module "pkg_check_modules()" command
>    following a successful call learned to re-evaluate the cached values
>    for a given prefix after changes to the parameters to the command
>    for that prefix.
>
> * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and
>    "ui_*" are placed in the
>    "<CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include" directory
>    which is automatically added to the target's "INCLUDE_DIRECTORIES".
>    It is therefore not necessary anymore to have
>    "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES".
>
> * The "Sublime Text 2" generator no longer runs the native build
>    command (e.g. "ninja" or "make") with verbose build output enabled.
>
> * The "try_compile()" command source file signature now honors the
>    "CMAKE_WARN_DEPRECATED" variable value in the generated test
>    project.
>
> * The Visual Studio Generators for VS 2010 and above now place per-
>    source file flags after target-wide flags when they are classified
>    as raw flags with no project file setting ("AdditionalOptions").
>    This behavior is more consistent with the ordering of flags produced
>    by other generators, and allows flags on more-specific properties
>    (per-source) to override those on more general ones (per-target).
>
> * The precompiled Windows binary MSI package provided on "cmake.org"
>    now records the installation directory in the Windows Registry under
>    the key "HKLM\Software\Kitware\CMake" with a value named
>    "InstallDir".

From brad.king at kitware.com  Tue Feb  7 14:43:16 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 7 Feb 2017 14:43:16 -0500
Subject: [CMake] cmake server-mode project order (was: CMake 3.8.0-rc1
 now ready for testing!)
In-Reply-To: <589A1E9A.2080505@bluequartz.net>
References: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>
 <589A1E9A.2080505@bluequartz.net>
Message-ID: <d4bb35ac-2694-3067-5638-a752977d7dc6@kitware.com>

On 02/07/2017 02:23 PM, Michael Jackson wrote:
> Are there any improvements to the cmake -server mode? I am testing the 
> combination of QtCreator and CMake and there seemed to be an issue where 
> the list of projects are in Alphabetical order and not in a "top down" 
> order.

Tobias?

-Brad


From mike.jackson at bluequartz.net  Tue Feb  7 16:49:30 2017
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Tue, 07 Feb 2017 16:49:30 -0500
Subject: [CMake] cmake server-mode project order
In-Reply-To: <CAMdWP3FWbW_4OtErLvSdeTdtz2zVRbDT4joWG-QzTkMzDdCRUg@mail.gmail.com>
References: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>
 <589A1E9A.2080505@bluequartz.net>
 <d4bb35ac-2694-3067-5638-a752977d7dc6@kitware.com>
 <CAMdWP3FWbW_4OtErLvSdeTdtz2zVRbDT4joWG-QzTkMzDdCRUg@mail.gmail.com>
Message-ID: <589A40EA.3090308@bluequartz.net>


Tobias Hunger wrote:
>
>
> On Feb 7, 2017 20:43, "Brad King" <brad.king at kitware.com
> <mailto:brad.king at kitware.com>> wrote:
>
>     On 02/07/2017 02:23 PM, Michael Jackson wrote:
>      > Are there any improvements to the cmake -server mode? I am
>     testing the
>      > combination of QtCreator and CMake and there seemed to be an
>     issue where
>      > the list of projects are in Alphabetical order and not in a "top
>     down"
>      > order.
>
>     Tobias?
>
>
> I admit that I did not yet notice that yet:-) I turn the whole thing
> into a tree anyway and do not care about the order of the elements.
>
> Server-mode is not doing anything special, it just grabs the project
> list from cmGlobalGenerator::GetProjectMap() and dumps it. That is a
> map, so now that I think about it, it is sorted by name:-)
>
> Yes, I could re-sort that to be in another order.
>
> Best Regards,
> Tobisa

This comes off mainly as a visual issue but also a but of a usability 
issue. Our project is called "DREAM3D" but has a subproject called 
"AMProcessMonitoring". After loading the project in QtCreator 4.3 beta 
using CMake 3.7.1 (on OS X if that matters at all), the top level is 
listed as "AMProcessMonitoring". Everything generally compiles fine from 
there. If I close the project and go to QtCreators Welcome page I don't 
see "DREAM3D" anymore but I see "AMProcessMonitoring" instead. Clicking 
on the "AMProcessingMonitoring" link correctly opens the project. It is 
just odd to see it that way.

So if you could somehow mark the top level project when you get the list 
from CMake and percolate that to the QtCreator UI it would be really 
great. So far the combination of QtCreator 4.3 and CMake 3.7.1 has 
really great potential. There are still some rough spots but I generally 
am really happy with this combination now.
-- 
Michael A. Jackson                 400 S. Pioneer Blvd
Owner, President                   Springboro, Ohio 45066
BlueQuartz Software, LLC           EMail: mike.jackson at bluequartz.net
Voice: 937-790-1601                Web: http://www.bluequartz.net
Fax: 937-746-0783

From brad.king at kitware.com  Wed Feb  8 07:54:24 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 8 Feb 2017 07:54:24 -0500
Subject: [CMake] cmake server-mode project order
In-Reply-To: <CAMdWP3Gt98=eEx3NS9XcdLPpYypppE13UwL=zmw5xA7d_01ZPw@mail.gmail.com>
References: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>
 <589A1E9A.2080505@bluequartz.net>
 <d4bb35ac-2694-3067-5638-a752977d7dc6@kitware.com>
 <CAMdWP3FWbW_4OtErLvSdeTdtz2zVRbDT4joWG-QzTkMzDdCRUg@mail.gmail.com>
 <589A40EA.3090308@bluequartz.net>
 <CAMdWP3Gt98=eEx3NS9XcdLPpYypppE13UwL=zmw5xA7d_01ZPw@mail.gmail.com>
Message-ID: <d7347f39-3af6-14ef-04f7-cbf087ae40b0@kitware.com>

On 02/08/2017 01:26 AM, Tobias Hunger wrote:
> There still are some rough spots in creators support for server-mode.
> Currently I am trying to get all the basic features in and leave
> polishing and fixing the non-critical bugs for later.

Has it become mature enough that the cmake server protocol should
be made non-experimental for CMake 3.9?

-Brad


From brad.king at kitware.com  Wed Feb  8 09:15:14 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 8 Feb 2017 09:15:14 -0500
Subject: [CMake] cmake server-mode project order
In-Reply-To: <CAMdWP3G5PXa-CK8HuAfBs5m1OUNmTqQWEorX8Z_kUBdCgssjmw@mail.gmail.com>
References: <CAFzjYVomqSWFPLLQAgkf7nwanCtUsm7oFY1LHhbq7AJmcBZ1fg@mail.gmail.com>
 <589A1E9A.2080505@bluequartz.net>
 <d4bb35ac-2694-3067-5638-a752977d7dc6@kitware.com>
 <CAMdWP3FWbW_4OtErLvSdeTdtz2zVRbDT4joWG-QzTkMzDdCRUg@mail.gmail.com>
 <589A40EA.3090308@bluequartz.net>
 <CAMdWP3Gt98=eEx3NS9XcdLPpYypppE13UwL=zmw5xA7d_01ZPw@mail.gmail.com>
 <d7347f39-3af6-14ef-04f7-cbf087ae40b0@kitware.com>
 <CAMdWP3G5PXa-CK8HuAfBs5m1OUNmTqQWEorX8Z_kUBdCgssjmw@mail.gmail.com>
Message-ID: <c486e94c-7803-8165-afca-46cfc4c60f65@kitware.com>

On 02/08/2017 09:13 AM, Tobias Hunger wrote:
> I know a couple of people are looking into using server-mode, so let's
> give them a bit more time and decide shortly before feature freeze for
> CMake 3.9. Does that sound like a reasonable plan?

Sure.  I'll defer to you to decide when it's ready.

Thanks,
-Brad


From robert.maynard at kitware.com  Wed Feb  8 11:17:47 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 8 Feb 2017 11:17:47 -0500
Subject: [CMake] Why can't I build CMake on Centos6 32-bit?
In-Reply-To: <CAA4Dnn2Wa4Yn03SPpjyK1RMa4SZTVc9kuMd-w_wHFcWBGMMCxA@mail.gmail.com>
References: <CAA4Dnn2Wa4Yn03SPpjyK1RMa4SZTVc9kuMd-w_wHFcWBGMMCxA@mail.gmail.com>
Message-ID: <CAFzjYVo68VFmweTfGkCKU_tF7+yx+2x1K3GhXiE7_xF-jeZfFA@mail.gmail.com>

Hi Kent,

We haven't been able to replicate this issue on EL6 32.bit. What exact
version of CMake are you trying to build?



On Tue, Feb 7, 2017 at 12:36 PM, Kent Williams
<nkwmailinglists at gmail.com> wrote:
> This used to work.
> Linux build6.leepfrog.com 2.6.32-642.6.2.el6.i686 #1 SMP Wed Oct 26 06:14:53
> UTC 2016 i686 i686 i386 GNU/Linux
>
> gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
> The first part of the bootstrap succeeds, and then running the second stage
> yields this:
>
> loading initial cache file
> /home/kwilliams/develop/cmake/build6/Bootstrap.cmk/InitialCacheFlags.cmake
> CMake Error at Modules/CMakeCompilerIdDetection.cmake:28 (list):
>   list sub-command REMOVE_ITEM requires two or more arguments.
> Call Stack (most recent call first):
>   Modules/CMakeDetermineCompilerId.cmake:114 (compiler_id_detection)
>   Modules/CMakeDetermineCompilerId.cmake:132
> (CMAKE_DETERMINE_COMPILER_ID_WRITE)
>   Modules/CMakeDetermineCompilerId.cmake:30
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:11 (project)
>
>
> CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
>   file problem creating directory:
>   /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC
> Call Stack (most recent call first):
>   Modules/CMakeDetermineCompilerId.cmake:30
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:11 (project)
>
>
> CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
>   file problem creating directory:
>   /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC
> Call Stack (most recent call first):
>   Modules/CMakeDetermineCompilerId.cmake:30
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:11 (project)
>
>
> CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
>   file problem creating directory:
>   /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC
> Call Stack (most recent call first):
>   Modules/CMakeDetermineCompilerId.cmake:30
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:11 (project)
>
>
> -- The C compiler identification is unknown
> CMake Error: Could not find cmake module file:
> /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CMakeCCompiler.cmake
> CMake Error at Modules/CMakeCompilerIdDetection.cmake:28 (list):
>   list sub-command REMOVE_ITEM requires two or more arguments.
> Call Stack (most recent call first):
>   Modules/CMakeDetermineCompilerId.cmake:114 (compiler_id_detection)
>   Modules/CMakeDetermineCompilerId.cmake:132
> (CMAKE_DETERMINE_COMPILER_ID_WRITE)
>   Modules/CMakeDetermineCompilerId.cmake:30
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   Modules/CMakeDetermineCXXCompiler.cmake:104 (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:11 (project)
>
>
> CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file):
>   file problem creating directory:
>   /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdCXX
> Call Stack (most recent call first):
>   Modules/CMakeDetermineCompilerId.cmake:30
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   Modules/CMakeDetermineCXXCompiler.cmake:104 (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:11 (project)
>
>
> -- The CXX compiler identification is unknown
> CMake Error: Could not find cmake module file:
> /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CMakeCXXCompiler.cmake
> -- Check for working C compiler: /usr/bin/gcc
> CMake Error at Modules/CMakeTestCCompiler.cmake:37 (try_compile):
>   Unknown extension ".c" for file
>
>     /home/kwilliams/develop/cmake/build6/CMakeFiles/CMakeTmp/testCCompiler.c
>
>   try_compile() works only for enabled languages.  Currently these are:
>
>     C CXX
>
>   See project() command to enable other languages.
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (project)
>
>
> -- Check for working C compiler: /usr/bin/gcc -- broken
> CMake Error at Modules/CMakeTestCCompiler.cmake:51 (message):
>   The C compiler "/usr/bin/gcc" is not able to compile a simple test
> program.
>
>   It fails with the following output:
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (project)
>
>
> -- Configuring incomplete, errors occurred!
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 mburns83 at yahoo.com  Wed Feb  8 14:50:22 2017
From: mburns83 at yahoo.com (Michael Burns)
Date: Wed, 8 Feb 2017 11:50:22 -0800
Subject: [CMake] Problem with override file ...
Message-ID: <d69e870d-af79-76de-524c-2ba4bb96b5c8@yahoo.com>

Using the following override file results in the try_compile failing for
both the C compiler and the C++ compiler. The output shows that the
override file is being processed multiple times. The first time it is
processed, the variable PARAM is 'set' as specified on the CMake command
line. However, subsequent processing of the file shows that PARAM is not
'set' and results in the 'bogus-option' being added to the compiler
command line. This, of course, results in the try_compile's failing.

message(STATUS "Processing override_compiler_flags.cmake ...")

if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)
    if(PARAM STREQUAL "set")
        message(AUTHOR_WARNING "PARAM is 'set' ...")
        add_definitions("-DPARAM=1")
    else()
        message(AUTHOR_WARNING "PARAM is not 'set' ...")
        add_definitions("--bogus-option")
    endif()
endif()

The CMake process is initiated with the following command line.

$ cmake -DPARAM=set ..

And, usage of the override file is set with the following before the
project is defined.

set(CMAKE_USER_MAKE_RULES_OVERRIDE
${CMAKE_CURRENT_SOURCE_DIR}/override_compiler_flags.cmake)

I have attached the output of the CMake run as well.

Is this a bug in that subsequent processing of the override file is not
using the cached value of PARAM?
Or, is there something wrong with the override file itself?

Thanks!

Mike

-------------- next part --------------
$ cmake -DPARAM=set ..
-- The C compiler identification is GNU 4.7.3
-- The CXX compiler identification is GNU 4.7.3
-- Processing override_compiler_flags.cmake ...
CMake Warning (dev) at override_compiler_flags.cmake:5 (message):
  PARAM is 'set' ...
Call Stack (most recent call first):
  /usr/local/share/cmake-3.6/Modules/CMakeCInformation.cmake:94 (include)
  CMakeLists.txt:7 (project)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Check for working C compiler: /usr/bin/cc
CMake Warning (dev) at /cmake-test/override_compiler_flags.cmake:8 (message):
  PARAM is not 'set' ...
Call Stack (most recent call first):
  /usr/local/share/cmake-3.6/Modules/CMakeCInformation.cmake:94 (include)
  /cmake-test/test/CMakeFiles/CMakeTmp/CMakeLists.txt:3 (project)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/local/share/cmake-3.6/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "/usr/bin/cc" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /cmake-test/test/CMakeFiles/CMakeTmp

  

  Run Build Command:"/usr/bin/make" "cmTC_68ea8/fast"

  /usr/bin/make -f CMakeFiles/cmTC_68ea8.dir/build.make
  CMakeFiles/cmTC_68ea8.dir/build

  make[1]: Entering directory `/cmake-test/test/CMakeFiles/CMakeTmp'

  Building C object CMakeFiles/cmTC_68ea8.dir/testCCompiler.c.o

  /usr/bin/cc --bogus-option -o CMakeFiles/cmTC_68ea8.dir/testCCompiler.c.o
  -c /cmake-test/test/CMakeFiles/CMakeTmp/testCCompiler.c

  cc: error: unrecognized command line option ?--bogus-option?

  make[1]: *** [CMakeFiles/cmTC_68ea8.dir/testCCompiler.c.o] Error 1

  make[1]: Leaving directory `/cmake-test/test/CMakeFiles/CMakeTmp'

  make: *** [cmTC_68ea8/fast] Error 2

  

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:7 (project)


-- Configuring incomplete, errors occurred!
See also "/cmake-test/test/CMakeFiles/CMakeOutput.log".
See also "/cmake-test/test/CMakeFiles/CMakeError.log".


From esinowitz at bloomberg.net  Wed Feb  8 16:05:28 2017
From: esinowitz at bloomberg.net (Ephi Sinowitz (BLOOMBERG/ 731 LEX))
Date: Wed, 8 Feb 2017 21:05:28 -0000
Subject: [CMake] =?utf-8?q?=2Ed_dependency_files_for_ninja?=
Message-ID: <589B881801F60778003907FC_0_99979@msllnjpmsgsv06>

cmake creates these files for gcc compiler using the -MMD -MMF compiler flags but does not do so for AIX xlc and Sun CC
Is this a known issue? Is there a workaround?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170208/ec0b409a/attachment.html>

From general at matley.com.au  Wed Feb  8 23:53:34 2017
From: general at matley.com.au (Shane Matley)
Date: Thu, 09 Feb 2017 15:53:34 +1100
Subject: [CMake] Ignoring exit code of child process with ctest memcheck run
 using valgrind
Message-ID: <1486616014.1546509.875219504.0FE127A5@webmail.messagingengine.com>

Hi,



I'm using memcheck in ctest to run valgrind on a test binary which may
sometimes return a non-zero exit code. Valgrind will always return the
exit code of its child process if it doesn't find any problems. (This
occurs even with --error-exitcode=1.) This means that valgrind will
return a non-zero exit code if the child process does, which our CI
system is interpreting as a valgrind error. I have gotten around this in
the past by using either an environment variable or argument to the
child process that makes the child process always return 0.


Now that I am using ctest and memcheck instead of calling valgrind
explicitly, I'm finding it difficult to set the environment variable or
pass an argument to the child process only for memcheck tests. Is there
a way of setting an environment variable or adding arguments to a test
for just memcheck tests, while not affecting a normal test run?


Example usage of ctest:



ctest -D ExperimentalMemCheck



With MEMORYCHECK_OPTIONS = "--error-exitcode=1 --leak-check=full"



Thanks,

Shane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170209/3d43dfde/attachment.html>

From jackie at sdiwc.info  Thu Feb  9 02:29:12 2017
From: jackie at sdiwc.info (Jackie Blanco)
Date: Thu, 09 Feb 2017 00:29:12 -0700
Subject: [CMake] CyberSec2017 Deadline Approaching
Message-ID: <83513f3600f0e88b346256d6ebbe91b2@sdiwc.info>

You are invited to participate in the following conference:

THE FIFTH INTERNATIONAL CONFERENCE ON CYBER SECURITY, CYBER WELFARE AND 
DIGITAL FORENSIC (CyberSec2017)

Venue: St. Mary's University, Addis Ababa, Ethiopia
Dates: April 22-24, 2017
URL: https://goo.gl/mbDr7F

The conference aims to enable researchers build connections between 
different digital applications and engineering.

Topics (not limited to):
- Cyber Security
- Enterprise Systems Security
- Hardware-Based security
- Legal Issues
- Operating Systems and Database Security
- SCADA and Embedded systems security
- Security for Future Networks
- Security in Social Networks
- Security protocols
- Digital Forensic
- Cyber-Crimes
- Evidentiary Aspects of Digital Forensics
- File System and Memory Analysis Multimedia Forensic
- Information Hiding
- Large-Scale Investigations
- Network Forensics and Traffic Analysis Hardware Vulnerabilities and 
Device Forensics
- Information Assurance and Security Management
- Corporate Governance
- Decidability and Complexity
- Economics of Security
- Identity Management
- Security Policies and Trust Management
- Cyber Peacefare and Physical Security
- Biometrics Applications
- Cyber Peacefare Trends and Approaches
- New theories and algorithms in biometrics
- Surveillance Systems

Registered papers will be published in the Society of Digital 
Information and Wireless Communications' Digital Library and in the 
proceedings of the conference.

DEADLINES
Paper Submission: April 1, 2017
Notification of Acceptance: April 12, 2017
Camera Ready & Registration: April 16, 2017

From martin.craig at eng.ox.ac.uk  Thu Feb  9 06:08:28 2017
From: martin.craig at eng.ox.ac.uk (Martin Craig)
Date: Thu, 9 Feb 2017 11:08:28 +0000
Subject: [CMake] Using CMAKE_INSTALL_PREFIX in custom install command fails
 with CPack
Message-ID: <B82A960C06B85A44B3F448526229B0D402F103A8@MBX11.ad.oak.ox.ac.uk>

Hi, got this problem which I've boiled down to a simple test case. My source dir contains just one file (realfile) and the installation should install this in bin and make a symlink from linkfile to it. This is the CMakeLists.txt file:

    cmake_minimum_required(VERSION 2.8.0)

    INSTALL(FILES realfile DESTINATION bin)
    INSTALL(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink realfile ${CMAKE_INSTALL_PREFIX}/bin/linkfile)")

    include(CPack)

This works fine with make install provided I can write to ${CMAKE_INSTALL_PREFIX}, however with make package, CMAKE_INSTALL_PREFIX is not apparently set to the temporary install location that CPack is using, and so it fails.

Any idea how I can work around this, or a better way of doing this task? I need it for creating symlinks, and also another install command which generates an index file in the install directory.

Thanks for any help,
Martin.

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

From exphy at web.de  Thu Feb  9 08:56:48 2017
From: exphy at web.de (Georg Schramm)
Date: Thu, 9 Feb 2017 14:56:48 +0100
Subject: [CMake] cmake 3.7.2. find_package(OpenMP) MSVC
Message-ID: <trinity-c0e9cc7f-4bae-4927-a50a-918c3d097fb6-1486648608949@3capp-webde-bap56>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170209/d537de1b/attachment.html>

From doublef.mobile at gmail.com  Thu Feb  9 10:10:58 2017
From: doublef.mobile at gmail.com (Sergey Zakharchenko)
Date: Thu, 9 Feb 2017 18:10:58 +0300
Subject: [CMake] cmake -DX=Y -P : problem unsetting variables defined on
	command line
Message-ID: <CADYCxoPEqJ7dVbF7Wxfka3-ggqXGt2ne6DEjoRRFx1VSMyeZtw@mail.gmail.com>

Hello list,

I've been using CMake for quite some time and have only now found out
this disturbing difference between SET(X) and SET(X ""). It happens in
cmake -P mode when you try to unset variables which are defined on the
command line, e.g.

cmake -DX=Y -P x.cmake

This x.cmake gives "X=Y":

SET(X)
MESSAGE("X=${X}")

This, too, gives "X=Y":

UNSET(X)
MESSAGE("X=${X}")

This one finally gives "X=" (which I would have expected in the first place):

SET(X "")
MESSAGE("X=${X}")

Is this OK? Is this documented anywhere?

Best regards,

-- 
DoubleF

From nilsgladitz at gmail.com  Thu Feb  9 10:26:05 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 9 Feb 2017 16:26:05 +0100
Subject: [CMake] cmake -DX=Y -P : problem unsetting variables defined on
 command line
In-Reply-To: <CADYCxoPEqJ7dVbF7Wxfka3-ggqXGt2ne6DEjoRRFx1VSMyeZtw@mail.gmail.com>
References: <CADYCxoPEqJ7dVbF7Wxfka3-ggqXGt2ne6DEjoRRFx1VSMyeZtw@mail.gmail.com>
Message-ID: <35f96ebb-d7a8-fb5f-b685-c4e36d95c388@gmail.com>

On 02/09/2017 04:10 PM, Sergey Zakharchenko wrote:

> cmake -DX=Y -P x.cmake

The above sets the *cache* variable X.

> This x.cmake gives "X=Y":
>
> SET(X)
> MESSAGE("X=${X}")

The above unsets the *regular* variable X (leaving the cache variable X 
intact).

> This, too, gives "X=Y":
>
> UNSET(X)
> MESSAGE("X=${X}")

This also unsets the *regular* variable X.
To unset the cache variable unset(X CACHE) would have worked.

> This one finally gives "X=" (which I would have expected in the first place):
>
> SET(X "")
> MESSAGE("X=${X}")

Now you've got both a regular and cache variable named X.
When expanded the regular variable takes precedence.

> Is this OK? Is this documented anywhere?

https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#variables

Nils

From doublef.mobile at gmail.com  Thu Feb  9 10:54:28 2017
From: doublef.mobile at gmail.com (Sergey Zakharchenko)
Date: Thu, 9 Feb 2017 18:54:28 +0300
Subject: [CMake] cmake -DX=Y -P : problem unsetting variables defined on
 command line
In-Reply-To: <35f96ebb-d7a8-fb5f-b685-c4e36d95c388@gmail.com>
References: <CADYCxoPEqJ7dVbF7Wxfka3-ggqXGt2ne6DEjoRRFx1VSMyeZtw@mail.gmail.com>
 <35f96ebb-d7a8-fb5f-b685-c4e36d95c388@gmail.com>
Message-ID: <CADYCxoNM__oDAvpGvm9qvdLnxuaCk5zf4FMK8aHkp3sYyJxXrA@mail.gmail.com>

Hello Nils,

>> cmake -DX=Y -P x.cmake
>
>
> The above sets the *cache* variable X.

OK, I didn't think that really applied as the script is executed
standalone, so there's no cache in the regular sense of the word.
Thanks for the explanation.

Best regards,

-- 
DoubleF

From domen.vrankar at gmail.com  Thu Feb  9 14:03:07 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 9 Feb 2017 20:03:07 +0100
Subject: [CMake] Using CMAKE_INSTALL_PREFIX in custom install command
 fails with CPack
In-Reply-To: <B82A960C06B85A44B3F448526229B0D402F103A8@MBX11.ad.oak.ox.ac.uk>
References: <B82A960C06B85A44B3F448526229B0D402F103A8@MBX11.ad.oak.ox.ac.uk>
Message-ID: <CAKgx6BLwvxe5u+AhbxEFsfr_3W5eNYM7r1TF12Pa81=QryouhQ@mail.gmail.com>

2017-02-09 12:08 GMT+01:00 Martin Craig <martin.craig at eng.ox.ac.uk>:

> Hi, got this problem which I've boiled down to a simple test case. My
> source dir contains just one file (realfile) and the installation should
> install this in bin and make a symlink from linkfile to it. This is the
> CMakeLists.txt file:
>
>     cmake_minimum_required(VERSION 2.8.0)
>
>     INSTALL(FILES realfile DESTINATION bin)
>     INSTALL(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E
> create_symlink realfile ${CMAKE_INSTALL_PREFIX}/bin/linkfile)")
>

You could do it in two separate steps and without absolute path:

execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink
../../some_relative_path/bin/realfile linkfile) # at this point path
doesn't need to point to the location of existing file
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/linkfile DESTINATION
some_relative_path COMPONENT libraries)

Not certain which CPack package generator you're using but in case of
CPackRPM there is quite some automated handling of symlink paths (even
support for symlinks in relocatable rpm packages).

In this file are some examples of using symlinks in combination with
CPackRPM (never checked how they behave with other CPack package generators
though...):

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CPackComponentsForAll/CMakeLists.txt;h=344084317166ff4f62850ed77807af2647db6d6a;hb=HEAD

Side note - during packaging CPACK_PACKAGING_INSTALL_PREFIX is used instead
of CMAKE_INSTALL_PREFIX.

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

From cxjohnson at gmail.com  Thu Feb  9 16:26:59 2017
From: cxjohnson at gmail.com (Chris Johnson)
Date: Thu, 9 Feb 2017 15:26:59 -0600
Subject: [CMake] Cross project include/link pathing?
Message-ID: <CAKZJW49vQX5ipDSozKF5iZhgFJ4O=Xq6vOZLaBPUjZjEhR4CjA@mail.gmail.com>

We've been using CMake for a couple of years for C++ application
building.  We effectively set up our CMake project structure once, and
mostly only change it to add new source files, etc.

Currently, all C++ source is checked out of our SVN repository into one
large tree.  This tree actually contains multiple applications.  Many,
but not all, depend on libraries which are also in this same source tree
checkout.  Executables are statically linked to the libraries.

Our source tree has grown to the point where this arrangement really
does not make sense, and is quite far from best practices.  We want to
move to a more project-oriented structure, where there will be multiple
projects, but where the libraries are still shared.

How do I go about this?

In particular, how do I structure each project to find the common,
shared (but statically linked) libraries?  I would assume that each
library itself or the collection of libraries would be a project, with a
top-level CMakeLists.txt file.

Note that each project could be installed in its own unique location in
its deployed VM or container, so placing the libraries into, say,
hard-coded /usr/local/lib is not a feasible solution for us.


Pictorially (use fixed width font for best results):
=====================================================

Current single source tree layout
---------------------------------

.
|-- CMakeLists.txt
|-- application_1/
|   `-- CMakeLists.txt
|-- application_2/
|   |-- CMakeLists.txt
|   |-- util_1/
|   |   `-- CMakeLists.txt
|   |-- util_2/
|   |   `-- CMakeLists.txt
|   `-- util_3/
|       `-- CMakeLists.txt
`-- lib/
    |-- CMakeLists.txt
    |-- lib_1/
    |   `-- CMakeLists.txt
    `-- lib_2/
        `-- CMakeLists.txt


Desired project-oriented layout
-------------------------------

[Application 1 Project]
.
`-- CMakeLists.txt

[Application 2 Project]
.
|-- CMakeLists.txt
|-- util_1/
|   `-- CMakeLists.txt
|-- util_2/
|   `-- CMakeLists.txt
`-- util_3/
    `-- CMakeLists.txt

[Libraries Project]
.
|-- CMakeLists.txt
|-- lib_1/
|   `-- CMakeLists.txt
`-- lib_2/
    `-- CMakeLists.txt



Presently, all of the applications know where to find the library header
files, because they are all in the same tree.  When we run "cmake ." at
the root of the source checkout, CMake knows where everything is, and
correctly provides the include paths to C++ compiler.

Similarly, at link time, CMake has automatically determined where the
compiled static libraries are, and our CMakeLists.txt files only need
mention them by name.  CMake has been brilliant at making this kind of
stuff simple.

But how do I make CMake generate the correct include and link paths when
"cmake ." is run on some individual project's source code, when those
paths will be outside the current tree, i.e. elsewhere?


..chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170209/543f5603/attachment.html>

From Andreas-Naumann at gmx.net  Fri Feb 10 08:02:42 2017
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Fri, 10 Feb 2017 14:02:42 +0100
Subject: [CMake] Cross project include/link pathing?
In-Reply-To: <CAKZJW49vQX5ipDSozKF5iZhgFJ4O=Xq6vOZLaBPUjZjEhR4CjA@mail.gmail.com>
References: <CAKZJW49vQX5ipDSozKF5iZhgFJ4O=Xq6vOZLaBPUjZjEhR4CjA@mail.gmail.com>
Message-ID: <01ea342d-ace7-d774-d246-014aade1f10c@gmx.net>

Dear Chris,

your description looks like the perfect example for ExternalProject_add. 
Than, every library would be a project. Inside each library, it looks 
for its dependency using find_package(<libraryProjectName>) and exports 
the dependency chain.
Your CMakeLists.txt of the application than has two possibilities:
     a) simply assume, that the library is installed in a (known) 
location -> use find_package as described above and proceed as is.
     b) build the library as an external project. In this case, your 
application has to be an external project with dependency to the 
external project of the library.

Hope that helps you and describes at least the idea,

Andreas

Am 09.02.2017 um 22:26 schrieb Chris Johnson:
> We've been using CMake for a couple of years for C++ application
> building.  We effectively set up our CMake project structure once, and
> mostly only change it to add new source files, etc.
>
> Currently, all C++ source is checked out of our SVN repository into one
> large tree.  This tree actually contains multiple applications.  Many,
> but not all, depend on libraries which are also in this same source tree
> checkout.  Executables are statically linked to the libraries.
>
> Our source tree has grown to the point where this arrangement really
> does not make sense, and is quite far from best practices.  We want to
> move to a more project-oriented structure, where there will be multiple
> projects, but where the libraries are still shared.
>
> How do I go about this?
>
> In particular, how do I structure each project to find the common,
> shared (but statically linked) libraries?  I would assume that each
> library itself or the collection of libraries would be a project, with a
> top-level CMakeLists.txt file.
>
> Note that each project could be installed in its own unique location in
> its deployed VM or container, so placing the libraries into, say,
> hard-coded /usr/local/lib is not a feasible solution for us.
>
>
> Pictorially (use fixed width font for best results):
> =====================================================
>
> Current single source tree layout
> ---------------------------------
>
> .
> |-- CMakeLists.txt
> |-- application_1/
> |   `-- CMakeLists.txt
> |-- application_2/
> |   |-- CMakeLists.txt
> |   |-- util_1/
> |   |   `-- CMakeLists.txt
> |   |-- util_2/
> |   |   `-- CMakeLists.txt
> |   `-- util_3/
> |       `-- CMakeLists.txt
> `-- lib/
>     |-- CMakeLists.txt
>     |-- lib_1/
>     |   `-- CMakeLists.txt
>     `-- lib_2/
>         `-- CMakeLists.txt
>
>
> Desired project-oriented layout
> -------------------------------
>
> [Application 1 Project]
> .
> `-- CMakeLists.txt
>
> [Application 2 Project]
> .
> |-- CMakeLists.txt
> |-- util_1/
> |   `-- CMakeLists.txt
> |-- util_2/
> |   `-- CMakeLists.txt
> `-- util_3/
>     `-- CMakeLists.txt
>
> [Libraries Project]
> .
> |-- CMakeLists.txt
> |-- lib_1/
> |   `-- CMakeLists.txt
> `-- lib_2/
>     `-- CMakeLists.txt
>
>
>
> Presently, all of the applications know where to find the library header
> files, because they are all in the same tree.  When we run "cmake ." at
> the root of the source checkout, CMake knows where everything is, and
> correctly provides the include paths to C++ compiler.
>
> Similarly, at link time, CMake has automatically determined where the
> compiled static libraries are, and our CMakeLists.txt files only need
> mention them by name.  CMake has been brilliant at making this kind of
> stuff simple.
>
> But how do I make CMake generate the correct include and link paths when
> "cmake ." is run on some individual project's source code, when those
> paths will be outside the current tree, i.e. elsewhere?
>
>
> ..chris
>
>


From angelv at iac.es  Fri Feb 10 09:13:23 2017
From: angelv at iac.es (Angel de Vicente)
Date: Fri, 10 Feb 2017 14:13:23 +0000
Subject: [CMake] Module dependency with Fortran code (avoiding compilation
	cascades)
Message-ID: <yegy3xe5e2k.fsf@carro.ll.iac.es>

Hi,

our project was using hand-made makefiles which were becoming difficult
to maintain, so I decided to migrate to CMake. This is my first time
with CMake, so still testing it, but there is something that I haven't
figured out how to do, namely avoid compilation cascades.

I'm using right now Intel Fortran and the issue with it is that
everytime you make a change in the source code, the generated .mod file
is also created even if the procedures interfaces were not changed at
all. With our hand made makefiles I was keeping a copy of the .mod files
in another directory, then after the .mod file was generated I stripped
the first bytes (to avoid a timestamp that Intel Fortran puts in the
.mod files) and then compared with the old .mod file. If both were
identical I overwrote the new .mod file with the old one, and since
other object files depended on the .mod files (as per the hand-made
written makefile), then no recompilation of other files using that
module was performed.

I was hoping to get similar behaviour with CMake, but without so much
hand-made tweaking (as I read that CMake could do its own dependency
resolution), but I'm not sure how to proceed, as at least now every time
I just modify anything in one of the source files, every module that
uses it is recompiled (recursively all the project up).

Any pointers on how to avoid compilation cascades with Fortran+CMake?

Many thanks,
-- 
?ngel de Vicente
http://www.iac.es/galeria/angelv/          
---------------------------------------------------------------------------------------------
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protecci?n de Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en


From vbspam at centrum.cz  Sun Feb 12 05:37:46 2017
From: vbspam at centrum.cz (vbspam)
Date: Sun, 12 Feb 2017 11:37:46 +0100
Subject: [CMake] Absolute path printing of CMakeLists.txt files in title of
 CMake error messages.
Message-ID: <780e4130-09c8-09fe-3e70-e6e0f3b72d84@centrum.cz>

Hi CMakers!

I would like to discuss absolute path printing of CMakeLists.txt file in
title of CMake error messages (see cmListFileBacktrace::PrintTitle ).
( code for discussion:
https://gitlab.kitware.com/vbspam/cmake/commit/ab3f992e9f39b81859d5ab3fa17eba25cfc61136
)

*What is the issue?*

When there is a problem in CMakeLists.txt, CMake reports the file the
problem occurs in as relative to its CMAKE_BINARY_DIR. Please see example:

```code

CMake Error at libraries/LibFoo/tests/CMakeLists.txt:16 (set_property):

  set_property could not find TARGET LibFoo.  Perhaps it has not yet been

  created.

Call Stack (most recent call first):

 libraries/LibFoo/tests/CMakeLists.txt:36 (add_simple_test)

```

The issue is that when some automated tools do not know the
CMAKE_SOURCE_DIR, then they have hard time to determine which file is
referred to.
This could happen even by wrong design of 'some automated tool' or by
parallel CMake execution using the same cout/cerr.

Instead it would be nice if there will be an option to print the file
name as absolute path. Please see desired example:


```code

CMake Error at /home/user/Projects/libraries/LibFoo/tests/CMakeLists.txt:16 (set_property):

  set_property could not find TARGET LibFoo.  Perhaps it has not yet been

  created.

Call Stack (most recent call first):

 libraries/LibFoo/tests/CMakeLists.txt:36 (add_simple_test)

```

*What is the real driver behind?*

- I use KDevelop as my Linux IDE which has as you may know pretty nice
CMake integration. The thing is, that when I use out-the-source build,
KDevelop has a problem when parsing the CMake error outputs. It assumes
the file is referred to the build directory (which in fact is correct
because the KDevelop runs the build command in the build directory), but
it is not. The CMake assumes the 'contract' is that the CMakeLists.txt
would be always considered as relative to the CMAKE_SOURCE_DIR.

- Another driver is when I do parallel build on build server, the actual
context of the CMake error line is hard to determine. Here is impossible
to get the proper context (the only relevant context is the printed line
itself).

*Why I bother you with this issue?

*Even though I did my own fixture for myself, I believe that this issue
may influence also other users
(e.g.
- https://cmake.org/pipermail/cmake/2014-March/057164.html
- or the author of the conditional relative printing itself - please see
'GetIsInTryCompile()'' flag
)

Last but not least: it is not much practical to maintain my own CMake
repo just for this change :-).

*What next?

*I would like to know if someone is interested and would accept this as
an issue.
I can then fill this as an issue and in other discussion propose how to
design the absolute/relative path switching.
At this moment the 'GetIsInTryCompile()' flag which influence the
absolute/relative printing is set only as hardcodded value (as far as I
know).

Looking forward for constructive discussion!

Best regards
Venca


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

From steveire at gmail.com  Sun Feb 12 16:25:24 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 12 Feb 2017 21:25:24 +0000
Subject: [CMake] Absolute path printing of CMakeLists.txt files in title
	of CMake error messages.
References: <780e4130-09c8-09fe-3e70-e6e0f3b72d84@centrum.cz>
Message-ID: <o7qjru$mjq$1@blaine.gmane.org>

vbspam wrote:

> *What is the real driver behind?*
> 
> - I use KDevelop as my Linux IDE which has as you may know pretty nice
> CMake integration.

I believe KDevelop is getting support for the cmake server, so exposing 
messages through that would probably solve this aspect. Specifically, there 
is a cmMessenger class and messages go through that. If you add virtual 
method(s?) to it you can add an implementation specifically for the server 
which passes the messages over the protocol to the IDE.

> - Another driver is when I do parallel build on build server, the actual
> context of the CMake error line is hard to determine. Here is impossible
> to get the proper context (the only relevant context is the printed line
> itself).

I'm not familiar with this.

Thanks,

Steve.



From timo.reichl at web.de  Mon Feb 13 07:14:36 2017
From: timo.reichl at web.de (Timo Reichl)
Date: Mon, 13 Feb 2017 13:14:36 +0100
Subject: [CMake] ctest: One timeout causes all following tests to timeout
	aswell
Message-ID: <trinity-a3bc750a-44b6-44bb-9f20-0cfdb2cf24fd-1486988075999@3capp-webde-bap61>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170213/0c91f18a/attachment.html>

From Adrian.Sevcenco at cern.ch  Tue Feb 14 12:22:15 2017
From: Adrian.Sevcenco at cern.ch (Adrian Sevcenco)
Date: Tue, 14 Feb 2017 19:22:15 +0200
Subject: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)
Message-ID: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>

Hi! I am trying to rebuild the f25 srpm on a centos 7 machine but after 
a successful compilation i get this test error :
99% tests passed, 1 tests failed out of 454

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

Total Test time (real) = 257.33 sec

The following tests FAILED:
           6 - kwsys.testSystemTools (Failed)
Errors while running CTest

so, what test is this, and how can i debug this?
it's kind of driving me nuts knowing that the compilation is ok but test 
failed!

anyone, any idea about this?

Thank you!!
Adrian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2292 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170214/2a3ca271/attachment.bin>

From eike at sf-mail.de  Tue Feb 14 12:27:05 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 14 Feb 2017 18:27:05 +0100
Subject: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)
In-Reply-To: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>
References: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>
Message-ID: <20374773.Da6W4JisLC@eto>

Adrian Sevcenco wrote:
> Hi! I am trying to rebuild the f25 srpm on a centos 7 machine but after
> a successful compilation i get this test error :
> 99% tests passed, 1 tests failed out of 454
> 
> Label Time Summary:
> Label1    =   0.20 sec (1 test)
> Label2    =   0.20 sec (1 test)
> 
> Total Test time (real) = 257.33 sec
> 
> The following tests FAILED:
>            6 - kwsys.testSystemTools (Failed)
> Errors while running CTest

ctest -V --rerun-failed

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170214/31ffe990/attachment.sig>

From Adrian.Sevcenco at cern.ch  Tue Feb 14 15:15:25 2017
From: Adrian.Sevcenco at cern.ch (Adrian Sevcenco)
Date: Tue, 14 Feb 2017 22:15:25 +0200
Subject: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)
In-Reply-To: <20374773.Da6W4JisLC@eto>
References: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>
 <20374773.Da6W4JisLC@eto>
Message-ID: <f13929b2-754f-9d8f-d509-2c284f043440@cern.ch>

On 02/14/2017 07:27 PM, Rolf Eike Beer wrote:
> Adrian Sevcenco wrote:
>> Hi! I am trying to rebuild the f25 srpm on a centos 7 machine but after
>> a successful compilation i get this test error :
>> 99% tests passed, 1 tests failed out of 454
>>
>> Label Time Summary:
>> Label1    =   0.20 sec (1 test)
>> Label2    =   0.20 sec (1 test)
>>
>> Total Test time (real) = 257.33 sec
>>
>> The following tests FAILED:
>>            6 - kwsys.testSystemTools (Failed)
>> Errors while running CTest
>
> ctest -V --rerun-failed
Thank you! So i found compilation errors like these :
  Determining if compiler supports C11 _Thread_local failed with the 
following output:
....

/root/rpmbuild/BUILD/cmake-3.7.2/Source/Checks/cm_c11_thread_local.c:1:15: 
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
1:  _Thread_local int i = 42;

or
/root/rpmbuild/BUILD/cmake-3.7.2/Source/Checks/cm_cxx_make_unique.cxx:4:28: 
error: 'make_unique' is not a member of 'std'
1:    std::unique_ptr<int> u = std::make_unique<int>(0);

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

It would have been nice to be mentioned somewhere in release notes :(

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

(i am aware of devtoolset but i dont want to build an rpm that depends 
on the presence of devtoolset)

Thank you!
Adrian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2292 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170214/4bafcf14/attachment-0001.bin>

From Kris.Malfettone at sig.com  Tue Feb 14 16:53:19 2017
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Tue, 14 Feb 2017 21:53:19 +0000
Subject: [CMake] Potential bug: Having executables named "test" causes Ninja
 generator to generate ambiguous rules...
Message-ID: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>

Hi,
I am trying to migrate a very large project from cmake 2.8.11.2 + ninja 1.3.4 to cmake 3.7.2 + ninja 1.7.2 and found what might be a bug with the ninja generator.  In my project we have a number of executables that are named "test".  This is normally not a problem since each one as a different target name that is unique.  However, with the move to CMake 3.7.2 the Ninja generator seems to generate ambiguous target aliases for the project.  If I rename my outputs to something such as "testfoo", the problem goes away.  Looking at the build.ninja that is generated there are clearly multiple ambiguous targets.  One that I generates the output file named "test" and one I believe meant to run our unit tests.  That second part I believe is what is different between the versions of CMake that I am using.

The other thing is I believe even if those are removed there would be a final ambiguity between my executable and built in "test" command because the portion of the code the generates the section of the build.ninja file commented as "# Target aliases." seems to try and avoid ambiguities between targets but fails to consider built in cmake targets such as "test,install,install/strip,etc..."

Again, I am not a build.ninja expert so I may be wrong in my understanding.  Some further info, this does not occur on windows because on windows the targets all end with ".exe" and it does not happen with the Makefile generator on Linux.

Is this expected behavior?
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?

Any help would be appreciated.

Thanks,
Kris Malfettone

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170214/1634fa09/attachment.html>

From nilsgladitz at gmail.com  Wed Feb 15 03:35:40 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 15 Feb 2017 09:35:40 +0100
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
Message-ID: <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>

On 14.02.2017 22:53, Malfettone, Kris wrote:
>
> If so, are executables named ?test? no longer supported?
> Am I missing something or wrong in some way?
>

Issues existed before 3.0 but since 3.0 "test" and similarly problematic 
target names have been explicitly reserved.

Any CMake Version >= 3.0 will issue a warning (when the required version 
is < 3.0) or an error (when the required version is >= 3.0) by default:
     https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/8d01677c/attachment.html>

From tony.garratt at ansys.com  Wed Feb 15 06:34:26 2017
From: tony.garratt at ansys.com (Tony Garratt)
Date: Wed, 15 Feb 2017 11:34:26 +0000
Subject: [CMake] Intel C Generator for Cmake?
Message-ID: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>

I am having to switch to cmake from autotools for a third party tool I want
to build. We use Intel C and Intel Fortran on Windows. I see no mention of
an Intel C generator for cmake. I presume this means there is not one? If
so, can I create my own Intel C generator please?

Rgeards,
Tony

-- 
*Dr Tony Garratt*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/0720937f/attachment.html>

From petr.kmoch at gmail.com  Wed Feb 15 07:25:28 2017
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 15 Feb 2017 13:25:28 +0100
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
Message-ID: <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>

Hi Tony,

generators are for different *buildsystems*: a generator for Makefiles, a
generator for Visual Studio solutions, a generator for Ninja files, a
generator for Eclipse projects etc.

Intel C and Intel Fortran are compilers, not buildsystems. You should be
able to use them with any generator whose buildsystem supports those
compilers.

On Windows, CMake supports generation of vfproj files using the Visual
Studio generator. I don't know if Intel C has its own Visual Studio project
type in the same fashion, and if so, whether CMake supports it.

One of the setups I maintain uses Visual Studio's C++ compiler and Intel
Fortran compiler on Windows using the Visual Studio generator, and
conceptually, it's as simple as this:

call ...\ifortvars.bat ...
set FC=ifort
cmake ...

Petr

On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com> wrote:

> I am having to switch to cmake from autotools for a third party tool I
> want to build. We use Intel C and Intel Fortran on Windows. I see no
> mention of an Intel C generator for cmake. I presume this means there is
> not one? If so, can I create my own Intel C generator please?
>
> Rgeards,
> Tony
>
> --
> *Dr Tony Garratt*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/f282bdb5/attachment.html>

From tony.garratt at ansys.com  Wed Feb 15 07:42:41 2017
From: tony.garratt at ansys.com (Tony Garratt)
Date: Wed, 15 Feb 2017 12:42:41 +0000
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
 <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
Message-ID: <CAMR23VMOm2vY6UVX-PGmR3rjQ6EuLmvLHG4J=xHmp4WX7Fc_Kg@mail.gmail.com>

Thank you so much Petr. I am new to cmake so did quite understand how
everything fits together. I will give your suggestion a try.....

Regards,
Tony

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
> set FC=ifort
> cmake ...
>
> Petr
>
> On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com> wrote:
>
>> I am having to switch to cmake from autotools for a third party tool I
>> want to build. We use Intel C and Intel Fortran on Windows. I see no
>> mention of an Intel C generator for cmake. I presume this means there is
>> not one? If so, can I create my own Intel C generator please?
>>
>> Rgeards,
>> Tony
>>
>> --
>> *Dr Tony Garratt*
>>
>>
>


-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/e4bd7282/attachment-0001.html>

From tony.garratt at ansys.com  Wed Feb 15 08:06:53 2017
From: tony.garratt at ansys.com (Tony Garratt)
Date: Wed, 15 Feb 2017 13:06:53 +0000
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
 <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
Message-ID: <CAMR23VPE6aYmKuAcBzGMU+NUePbJ5T7ft+UAU8HOijydRqB8Dw@mail.gmail.com>

I tried setting the FC and CC variables and yet cmake still wants to use
the Microsoft compiler (BTW what I am building is the CGNS - the CFD common
file format).

Is there something I am missing?

CGNS_Build>set CC=icc

CGNS_Build>set FC=ifort

CGNS_Build>set CC
CC=icc

CGNS_Build>set FC
FC=ifort

CGNS_Build>cmake   -D CMAKE_C_COMPILER:PATH=$CC   -D
CMAKE_CXX_COMPILER:STRING=$CC   -D CMAKE
_Fortran_COMPILER:PATH=$FC   -D CMAKE_BUILD_TYPE:STRING="Release"   -D
CGNS_BUILD_SHARED:BOOL=ON   -D CGNS_ENABLE_LEGACY=ON   -D CGNS_BUIL
DCGNSTOOLS:BOOL=OFF    ..\src
-- Building for: Visual Studio 12 2013
-- The C compiler identification is MSVC 18.0.40629.0
-- The CXX compiler identification is MSVC 18.0.40629.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/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 12.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning (dev) at tools/CMakeLists.txt:6 (link_directories):
  This command specifies the relative path

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
> set FC=ifort
> cmake ...
>
> Petr
>
> On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com> wrote:
>
>> I am having to switch to cmake from autotools for a third party tool I
>> want to build. We use Intel C and Intel Fortran on Windows. I see no
>> mention of an Intel C generator for cmake. I presume this means there is
>> not one? If so, can I create my own Intel C generator please?
>>
>> Rgeards,
>> Tony
>>
>> --
>> *Dr Tony Garratt*
>>
>>
>


-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/76c3b9c9/attachment.html>

From Martin.Wagner at neuberger.net  Wed Feb 15 08:12:57 2017
From: Martin.Wagner at neuberger.net (Wagner Martin)
Date: Wed, 15 Feb 2017 13:12:57 +0000
Subject: [CMake] import external library
Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97C41F79@ROTSRV13.Neuberger.local>

Hi @all,

I?ve tried importing an external library like that: stackoverflow.com/questions/31274577

I have the same use case, except that my custom target does not call make but does unpack a tar archive containing headers and .a.
My problem is that the step
?
# specify where the library is and where to find the headers
set_target_properties(lib2
    PROPERTIES
    IMPORTED_LOCATION ${LIB_FILE}
    INTERFACE_INCLUDE_DIRECTORIES ${LIB_HEADER_FOLDER})
?
fails. When running cmake, I get an error that the header dir specified with ?INTERFACE_INCLUDE_DIRECTORIES? does not exist.
?
CMake Error in src/CMakeLists.txt:
  Imported target "whatever" includes non-existent path

    "/path/to/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.
?

This is true, as the header path is only generated when running the unpack target. Is there a way to tell cmake to skip this check?

Thanks!

Regards,
Martin




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

From tony.garratt at ansys.com  Wed Feb 15 08:21:15 2017
From: tony.garratt at ansys.com (Tony Garratt)
Date: Wed, 15 Feb 2017 13:21:15 +0000
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
 <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
Message-ID: <CAMR23VMYnMrX0POKtHapa1fh_cyc-WDi26bTkzVSj2A1NrQ5Dw@mail.gmail.com>

Re: my previous email. To use the Intel C compilers I just can modify the
VS settings. So I have a way forward.

Regards,
Tony

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
> set FC=ifort
> cmake ...
>
> Petr
>
> On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com> wrote:
>
>> I am having to switch to cmake from autotools for a third party tool I
>> want to build. We use Intel C and Intel Fortran on Windows. I see no
>> mention of an Intel C generator for cmake. I presume this means there is
>> not one? If so, can I create my own Intel C generator please?
>>
>> Rgeards,
>> Tony
>>
>> --
>> *Dr Tony Garratt*
>>
>>
>


-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/94e42e07/attachment-0001.html>

From Kris.Malfettone at sig.com  Wed Feb 15 08:26:40 2017
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Wed, 15 Feb 2017 13:26:40 +0000
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
Message-ID: <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>

Good to know.  Thanks for the quick response.  Though I do not believe I am violating that particular rule here.  That is why I do not receive either a warning or error from CMake in my output.

The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test

It is the ninja generator that is trying to setup aliases for each of them as a shortened form.  So I think one of the following statements are true:

*         The cmake rule intended for the above two target names to be invalid.  But the check to issue a warning or error has a bug causing them to be missed.  This would explain why I do not get the error in my configure results.

*         The cmake rule intended for the above two target names to be valid.  However, on further reflection the rule should be made stricter to include my target names above.  This would then require and update to the cmake code checking that policy and lead to me actually getting a warning or error from cmake during configure.

*         The ninja generator has a bug and is setting up ambiguous aliases for what CMake considers valid target names.

My project is huge so I will try and craft a simplified CMakeLists.txt example to reproduce the problem as well.

Does this make sense?  Am I still missing something?

-Kris


From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com>; cmake at cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?


Issues existed before 3.0 but since 3.0 "test" and similarly problematic target names have been explicitly reserved.

Any CMake Version >= 3.0 will issue a warning (when the required version is < 3.0) or an error (when the required version is >= 3.0) by default:
    https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/071f136b/attachment.html>

From Kris.Malfettone at sig.com  Wed Feb 15 09:06:49 2017
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Wed, 15 Feb 2017 14:06:49 +0000
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
 <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
Message-ID: <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>

So I was able to reproduce the problem with this very simple CMakeLists.txt setup.  I cannot attach source files due to my company's mail server automatically stripping them out attachments with code but here is all you would need to reproduce the problem:

Single CMakeLists.txt with the following:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_executable( "Foo.test" foo_test.cpp )
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
add_test(NAME "Bar.test" COMMAND test )
Two source files named foo_test.cpp and bar_test.cpp both containing the following code in the same directory:
int main( int, char** )
{
   return 0;
}

If you generate a Makefile based solution everything works fine.  However, if you generate a ninja based solution then you get the following:
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

-Kris

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Malfettone, Kris
Sent: Wednesday, February 15, 2017 8:27 AM
To: Nils Gladitz <nilsgladitz at gmail.com>; cmake at cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

Good to know.  Thanks for the quick response.  Though I do not believe I am violating that particular rule here.  That is why I do not receive either a warning or error from CMake in my output.

The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test

It is the ninja generator that is trying to setup aliases for each of them as a shortened form.  So I think one of the following statements are true:

*         The cmake rule intended for the above two target names to be invalid.  But the check to issue a warning or error has a bug causing them to be missed.  This would explain why I do not get the error in my configure results.

*         The cmake rule intended for the above two target names to be valid.  However, on further reflection the rule should be made stricter to include my target names above.  This would then require and update to the cmake code checking that policy and lead to me actually getting a warning or error from cmake during configure.

*         The ninja generator has a bug and is setting up ambiguous aliases for what CMake considers valid target names.

My project is huge so I will try and craft a simplified CMakeLists.txt example to reproduce the problem as well.

Does this make sense?  Am I still missing something?

-Kris

From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com<mailto:Kris.Malfettone at msx.bala.susq.com>>; cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?


Issues existed before 3.0 but since 3.0 "test" and similarly problematic target names have been explicitly reserved.

Any CMake Version >= 3.0 will issue a warning (when the required version is < 3.0) or an error (when the required version is >= 3.0) by default:
    https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/6dfac0c7/attachment-0001.html>

From Kris.Malfettone at sig.com  Wed Feb 15 09:16:54 2017
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Wed, 15 Feb 2017 14:16:54 +0000
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
 <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
 <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>
Message-ID: <545068f9ba584a499b60ec98f847ad14@xchbal500.ds.susq.com>

Just noticed a problem in my example.  In my attempt to simplify my example I moved both outputs into the same folder which in my opinion is invalid because both output file names are the same.  However, the same basic setup does reproduce the problem if you move the two targets into their own subdirs.  I was just trying to avoid describing that in the email.  Here is what I mean below:

Top level CMakeLists.txt:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_subdirectory("subdir")
add_subdirectory("subdir2")
subdir with CMakeLists.txt:
add_executable( "Foo.test" foo_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
subdir2 with CMakeLists.txt:
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Bar.test" COMMAND test )

Contents of both source files (obviously in their respective subdirectories):
int main( int, char** )
{
   return 0;
}

Sorry for that.

From: Malfettone, Kris
Sent: Wednesday, February 15, 2017 9:07 AM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com>; Nils Gladitz <nilsgladitz at gmail.com>; cmake at cmake.org
Subject: RE: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

So I was able to reproduce the problem with this very simple CMakeLists.txt setup.  I cannot attach source files due to my company's mail server automatically stripping them out attachments with code but here is all you would need to reproduce the problem:

Single CMakeLists.txt with the following:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_executable( "Foo.test" foo_test.cpp )
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
add_test(NAME "Bar.test" COMMAND test )
Two source files named foo_test.cpp and bar_test.cpp both containing the following code in the same directory:
int main( int, char** )
{
   return 0;
}

If you generate a Makefile based solution everything works fine.  However, if you generate a ninja based solution then you get the following:
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

-Kris

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Malfettone, Kris
Sent: Wednesday, February 15, 2017 8:27 AM
To: Nils Gladitz <nilsgladitz at gmail.com<mailto:nilsgladitz at gmail.com>>; cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

Good to know.  Thanks for the quick response.  Though I do not believe I am violating that particular rule here.  That is why I do not receive either a warning or error from CMake in my output.

The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test

It is the ninja generator that is trying to setup aliases for each of them as a shortened form.  So I think one of the following statements are true:

*         The cmake rule intended for the above two target names to be invalid.  But the check to issue a warning or error has a bug causing them to be missed.  This would explain why I do not get the error in my configure results.

*         The cmake rule intended for the above two target names to be valid.  However, on further reflection the rule should be made stricter to include my target names above.  This would then require and update to the cmake code checking that policy and lead to me actually getting a warning or error from cmake during configure.

*         The ninja generator has a bug and is setting up ambiguous aliases for what CMake considers valid target names.

My project is huge so I will try and craft a simplified CMakeLists.txt example to reproduce the problem as well.

Does this make sense?  Am I still missing something?

-Kris

From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com<mailto:Kris.Malfettone at msx.bala.susq.com>>; cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?


Issues existed before 3.0 but since 3.0 "test" and similarly problematic target names have been explicitly reserved.

Any CMake Version >= 3.0 will issue a warning (when the required version is < 3.0) or an error (when the required version is >= 3.0) by default:
    https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/d3fe2393/attachment-0001.html>

From nilsgladitz at gmail.com  Wed Feb 15 09:40:39 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 15 Feb 2017 15:40:39 +0100
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <545068f9ba584a499b60ec98f847ad14@xchbal500.ds.susq.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
 <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
 <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>
 <545068f9ba584a499b60ec98f847ad14@xchbal500.ds.susq.com>
Message-ID: <014e73df-efcb-597a-5a70-13bdc19b9423@gmail.com>

On 15.02.2017 15:16, Malfettone, Kris wrote:
>
> Just noticed a problem in my example.  In my attempt to simplify my 
> example I moved both outputs into the same folder which in my opinion 
> is invalid because both output file names are the same.  However, the 
> same basic setup does reproduce the problem if you move the two 
> targets into their own subdirs. I was just trying to avoid describing 
> that in the email. Here is what I mean below:
>

I thought you meant you had a target named "test" but apparently only 
your output is named that way.
That certainly isn't covered by the existing policy.

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/6fb19ff4/attachment.html>

From kgt at lanl.gov  Wed Feb 15 09:42:28 2017
From: kgt at lanl.gov (Thompson, KT)
Date: Wed, 15 Feb 2017 14:42:28 +0000
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <CAMR23VMYnMrX0POKtHapa1fh_cyc-WDi26bTkzVSj2A1NrQ5Dw@mail.gmail.com>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
 <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
 <CAMR23VMYnMrX0POKtHapa1fh_cyc-WDi26bTkzVSj2A1NrQ5Dw@mail.gmail.com>
Message-ID: <c5c448ba704f456bb7311338d879a3fc@EXG13-P-MBX01.win.lanl.gov>

Tony,

I don?t have access to the Intel compiler on Windows to try this out. However, in an old post I found, it was suggested that you can use cmake?s ?-T? option to select the Intel compiler when the generator is ?Visual Studio?.

For example:  -T"Intel C++ Compiler XE 13.0"

Ref: https://software.intel.com/en-us/forums/intel-c-compiler/topic/456288

-kt


From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Tony Garratt
Sent: Wednesday, February 15, 2017 6:21 AM
To: Petr Kmoch <petr.kmoch at gmail.com>
Cc: cmake at cmake.org
Subject: Re: [CMake] Intel C Generator for Cmake?


Re: my previous email. To use the Intel C compilers I just can modify the VS settings. So I have a way forward.

Regards,
Tony

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch <petr.kmoch at gmail.com<mailto:petr.kmoch at gmail.com>> wrote:
Hi Tony,
generators are for different *buildsystems*: a generator for Makefiles, a generator for Visual Studio solutions, a generator for Ninja files, a generator for Eclipse projects etc.
Intel C and Intel Fortran are compilers, not buildsystems. You should be able to use them with any generator whose buildsystem supports those compilers.
On Windows, CMake supports generation of vfproj files using the Visual Studio generator. I don't know if Intel C has its own Visual Studio project type in the same fashion, and if so, whether CMake supports it.
One of the setups I maintain uses Visual Studio's C++ compiler and Intel Fortran compiler on Windows using the Visual Studio generator, and conceptually, it's as simple as this:
call ...\ifortvars.bat ...
set FC=ifort
cmake ...
Petr

On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com<mailto:tony.garratt at ansys.com>> wrote:
I am having to switch to cmake from autotools for a third party tool I want to build. We use Intel C and Intel Fortran on Windows. I see no mention of an Intel C generator for cmake. I presume this means there is not one? If so, can I create my own Intel C generator please?

Rgeards,
Tony

--
Dr Tony Garratt





--
Dr Tony Garratt
Tel: +44 7624 309933
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/96f646af/attachment.html>

From florent.castelli at gmail.com  Wed Feb 15 10:55:03 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Wed, 15 Feb 2017 16:55:03 +0100
Subject: [CMake] import external library
In-Reply-To: <56E920142ED81D4FBE3260E4B9D1DB3E97C41F79@ROTSRV13.Neuberger.local>
References: <56E920142ED81D4FBE3260E4B9D1DB3E97C41F79@ROTSRV13.Neuberger.local>
Message-ID: <c735586f-72a2-528e-b833-39becd4d5c76@gmail.com>

You can either unpack the target at generation time (recommended).
Or you could create an INTERFACE target instead.

The first solution is recommended as I believe it's important to have 
access to all the sources (for IDEs for example) before actually 
starting the build process.

/Florent

On 15/02/2017 14:12, Wagner Martin wrote:
>
> Hi @all,
>
> I?ve tried importing an external library like that: 
> stackoverflow.com/questions/31274577
>
> I have the same use case, except that my custom target does not call 
> make but does unpack a tar archive containing headers and .a.
>
> My problem is that the step
>
> ?
>
> # specify where the library is and where to find the headers
>
> set_target_properties(lib2
>
>     PROPERTIES
>
>     IMPORTED_LOCATION ${LIB_FILE}
>
>     INTERFACE_INCLUDE_DIRECTORIES ${LIB_HEADER_FOLDER})
>
> ?
>
> fails. When running cmake, I get an error that the header dir 
> specified with ?INTERFACE_INCLUDE_DIRECTORIES? does not exist.
>
> ?
>
> CMake Error in src/CMakeLists.txt:
>
>   Imported target "whatever" includes non-existent path
>
>     "/path/to/include"
>
>   in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
>
>   * The path was deleted, renamed, or moved to another location.
>
>   * An install or uninstall procedure did not complete successfully.
>
>   * The installation package was faulty and references files it does not
>
>   provide.
>
> ?
>
> This is true, as the header path is only generated when running the 
> unpack target. Is there a way to tell cmake to skip this check?
>
> Thanks!
>
> Regards,
>
> Martin
>
>
>

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

From d3ck0r at gmail.com  Wed Feb 15 12:05:15 2017
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 15 Feb 2017 09:05:15 -0800
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <c5c448ba704f456bb7311338d879a3fc@EXG13-P-MBX01.win.lanl.gov>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
 <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
 <CAMR23VMYnMrX0POKtHapa1fh_cyc-WDi26bTkzVSj2A1NrQ5Dw@mail.gmail.com>
 <c5c448ba704f456bb7311338d879a3fc@EXG13-P-MBX01.win.lanl.gov>
Message-ID: <CAA2GJqXx-36xEqz-m95JYPQKaZ1e0YQ=Mh=egt0fpdTD3RRVGQ@mail.gmail.com>

Toolchain is probably what you want....

http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-with-icc-via-configuration-options

https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F

"cmake intel toochain" search.

On Wed, Feb 15, 2017 at 6:42 AM, Thompson, KT <kgt at lanl.gov> wrote:

> Tony,
>
>
>
> I don?t have access to the Intel compiler on Windows to try this out.
> However, in an old post I found, it was suggested that you can use cmake?s
> ?-T? option to select the Intel compiler when the generator is ?Visual
> Studio?.
>
>
>
> For example:  -T"Intel C++ Compiler XE 13.0"
>
>
>
> Ref: https://software.intel.com/en-us/forums/intel-c-compiler/topic/456288
>
>
>
> -kt
>
>
>
>
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Tony Garratt
> *Sent:* Wednesday, February 15, 2017 6:21 AM
> *To:* Petr Kmoch <petr.kmoch at gmail.com>
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Intel C Generator for Cmake?
>
>
>
>
>
> Re: my previous email. To use the Intel C compilers I just can modify the
> VS settings. So I have a way forward.
>
>
>
> Regards,
>
> Tony
>
>
>
> On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
>
> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
>
> set FC=ifort
>
> cmake ...
>
> Petr
>
>
>
> On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com> wrote:
>
> I am having to switch to cmake from autotools for a third party tool I
> want to build. We use Intel C and Intel Fortran on Windows. I see no
> mention of an Intel C generator for cmake. I presume this means there is
> not one? If so, can I create my own Intel C generator please?
>
>
>
> Rgeards,
>
> Tony
>
>
>
> --
>
> *Dr Tony Garratt*
>
>
>
>
>
>
>
>
>
> --
>
> *Dr Tony Garratt*
>
> Tel: +44 7624 309933 <+44%2076%202430%209933>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20170215/6db4575c/attachment.html>

From bnewcomb at nvidia.com  Wed Feb 15 11:43:53 2017
From: bnewcomb at nvidia.com (Bill Newcomb)
Date: Wed, 15 Feb 2017 16:43:53 +0000
Subject: [CMake] set_if_not_set
Message-ID: <07e1423d30fd4e89816896575e111b68@HQMAIL112.nvidia.com>

My top-level CMakeLists.txt files always end up with a lot of

if(NOT_DEFINED foo)
     set(foo bar)
endif()

things to allow people to pass interesting things on the command line or 
to write their own "set this and that" CMakeLists.txt and include the 
top-level one.

It would improve readability to have set_if_not_set and friends from 
CTest.cmake available in a separate module or, better still, as language 
primitives, either as-is or like

set(IF_NOT_SET foo bar)

or maybe

set(foo bar IF_NOT_SET)

Obviously I could define set_if_not_set at the top of each top-level 
CMakeLists.txt, but the above would be nicer.

What do you think?

Thanks,
B.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From mburns83 at yahoo.com  Wed Feb 15 12:33:59 2017
From: mburns83 at yahoo.com (Michael Burns)
Date: Wed, 15 Feb 2017 09:33:59 -0800
Subject: [CMake] Problem with override file ...
In-Reply-To: <d69e870d-af79-76de-524c-2ba4bb96b5c8@yahoo.com>
References: <d69e870d-af79-76de-524c-2ba4bb96b5c8@yahoo.com>
Message-ID: <3e5f17e8-88e1-cc03-a1ac-1852d07539f9@yahoo.com>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/d5653466/attachment.html>

From annulen at yandex.ru  Wed Feb 15 13:41:08 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 15 Feb 2017 21:41:08 +0300
Subject: [CMake] set_if_not_set
In-Reply-To: <07e1423d30fd4e89816896575e111b68@HQMAIL112.nvidia.com>
References: <07e1423d30fd4e89816896575e111b68@HQMAIL112.nvidia.com>
Message-ID: <2625351487184068@web14g.yandex.ru>



15.02.2017, 20:08, "Bill Newcomb" <bnewcomb at nvidia.com>:
> My top-level CMakeLists.txt files always end up with a lot of
>
> if(NOT_DEFINED foo)
> ?????set(foo bar)
> endif()
>
> things to allow people to pass interesting things on the command line or
> to write their own "set this and that" CMakeLists.txt and include the
> top-level one.
>
> It would improve readability to have set_if_not_set and friends from
> CTest.cmake available in a separate module or, better still, as language
> primitives, either as-is or like
>
> set(IF_NOT_SET foo bar)
>
> or maybe
>
> set(foo bar IF_NOT_SET)
>
> Obviously I could define set_if_not_set at the top of each top-level
> CMakeLists.txt, but the above would be nicer.
>
> What do you think?

Use options or CACHE variables, default values will be set unless user specifies them
explicitly.

>
> Thanks,
> B.
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 chuck.atkins at kitware.com  Wed Feb 15 14:04:34 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Wed, 15 Feb 2017 14:04:34 -0500
Subject: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)
In-Reply-To: <f13929b2-754f-9d8f-d509-2c284f043440@cern.ch>
References: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>
 <20374773.Da6W4JisLC@eto>
 <f13929b2-754f-9d8f-d509-2c284f043440@cern.ch>
Message-ID: <CAOXZzG7uxA1owrXuciwn62sd0dM1NyGCJwa+nwtwgtts55cmKg@mail.gmail.com>

Hi Adrian,

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

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



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

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

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

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

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

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

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/2fea4ba1/attachment-0001.html>

From kgt at lanl.gov  Wed Feb 15 18:49:44 2017
From: kgt at lanl.gov (Thompson, KT)
Date: Wed, 15 Feb 2017 23:49:44 +0000
Subject: [CMake] Errors from CDash
Message-ID: <4270a4d6575f46b2b056b7e9472dc8a0@EXG13-P-MBX09.win.lanl.gov>

When I run

php5 autoRemoveBuilds.php all

for my cdash 2.2.3 installation, I see the following errors (and old builds are not removed):

removing builds for all
  -- removing old buildids for projectid: 2
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
MySQL server has gone awaySQL error in remove_build():MySQL server has gone awa8
  -- removing old buildids for projectid: 2
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 3
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
 -- removing old buildids for projectid: 7
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 7
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
  -- removing old buildids for projectid: 8
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 8
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
  -- removing old buildids for projectid: 9
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 9
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
  -- removing old buildids for projectid: 10
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 10

Does this make sense to any of you?  How should I prune old builds from my database?

-kt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170215/298ac1da/attachment.html>

From milan at fastmail.com  Thu Feb 16 01:59:48 2017
From: milan at fastmail.com (Milan Ziegler)
Date: Thu, 16 Feb 2017 07:59:48 +0100
Subject: [CMake] Disabling INSTALL target for subdirectory
Message-ID: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>

Hi,

we are using the CMake install mechanism "install(...)" to copy all
relevant files and target binaries of the product into the CMake install
prefix folder, for further packaging. So far so good.

We are also using several thirdparty libraries, hosting them inside our
own repository and building them along with our own code, usually using
add_subdirectory utilizing their native CMake buildsystem.

Turns out, other developers also like the CMake install mechanism.

So now the INSTALL target of our whole project also installs thirdparty
components, which we do not want to deliver with our own product (think
static libraries, which are already linked into our executable).

After a lot of googling, here's my question: Is there a clean way to
disable the install target for a subdirectory _without_ also disabling
it completely for the remaining project?

What we already tried:
* Setting CMAKE_INSTALL_PREFIX to a temporary directory for the
subdirectory (doesn't work)
* "function(install) endfunction()" to disable the install function for
the subdirectory (breaks CMake in hilarious ways)

What we now do:
Using a custom target, we patch the cmake_install.cmake files in the
build directories before installing (works, but it's an  abomination of
a hack)

Any help? I think it's a valid usecase for CMake but there doesn't seem
to be an easy way to do it.

We are using CMake 3.5.


Thank you :)

--
? Milan
? milan at fastmail.com

From konstantin at podsvirov.pro  Thu Feb 16 02:16:59 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Thu, 16 Feb 2017 10:16:59 +0300
Subject: [CMake] Disabling INSTALL target for subdirectory
In-Reply-To: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
References: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
Message-ID: <4166011487229419@web36m.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170216/3e502692/attachment.html>

From craig.scott at crascit.com  Thu Feb 16 02:29:18 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 16 Feb 2017 07:29:18 +0000
Subject: [CMake] Disabling INSTALL target for subdirectory
In-Reply-To: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
References: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
Message-ID: <CA+dygYmqUB+yOO31zVNGbCfyU_j_hOgcndzf-sXSb1_4Pu-1vA@mail.gmail.com>

You can use the COMPONENT option to install() for your own project and then
select a component-based package if you are packaging with CPack. We
currently do this with builds that incorporate other projects with
add_subdirectory() similar to your case.

If you are using install as a build target (ie make install or equivalent),
I don't think the above will help you. I don't recall if the
EXCLUDE_FROM_ALL option to add_subdirectory() affects install or not. I
believe there was some discussion about this in one of the mailing lists or
gitlab issues recently, so maybe someone else can chime in to clarify this
part.


On Thu, 16 Feb 2017 at 3:59 pm, Milan Ziegler <milan at fastmail.com> wrote:

> Hi,
>
> we are using the CMake install mechanism "install(...)" to copy all
> relevant files and target binaries of the product into the CMake install
> prefix folder, for further packaging. So far so good.
>
> We are also using several thirdparty libraries, hosting them inside our
> own repository and building them along with our own code, usually using
> add_subdirectory utilizing their native CMake buildsystem.
>
> Turns out, other developers also like the CMake install mechanism.
>
> So now the INSTALL target of our whole project also installs thirdparty
> components, which we do not want to deliver with our own product (think
> static libraries, which are already linked into our executable).
>
> After a lot of googling, here's my question: Is there a clean way to
> disable the install target for a subdirectory _without_ also disabling
> it completely for the remaining project?
>
> What we already tried:
> * Setting CMAKE_INSTALL_PREFIX to a temporary directory for the
> subdirectory (doesn't work)
> * "function(install) endfunction()" to disable the install function for
> the subdirectory (breaks CMake in hilarious ways)
>
> What we now do:
> Using a custom target, we patch the cmake_install.cmake files in the
> build directories before installing (works, but it's an  abomination of
> a hack)
>
> Any help? I think it's a valid usecase for CMake but there doesn't seem
> to be an easy way to do it.
>
> We are using CMake 3.5.
>
>
> Thank you :)
>
> --
>   Milan
>   milan at fastmail.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

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

From domen.vrankar at gmail.com  Thu Feb 16 03:10:59 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 16 Feb 2017 09:10:59 +0100
Subject: [CMake] Disabling INSTALL target for subdirectory
In-Reply-To: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
References: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
Message-ID: <CAKgx6BLuL_pZ79dadpF+Q28Vp8_+er0FCdQLCjHzpgB-9DyYyw@mail.gmail.com>

2017-02-16 7:59 GMT+01:00 Milan Ziegler <milan at fastmail.com>:

> Hi,
>
> we are using the CMake install mechanism "install(...)" to copy all
> relevant files and target binaries of the product into the CMake install
> prefix folder, for further packaging. So far so good.
>
> We are also using several thirdparty libraries, hosting them inside our
> own repository and building them along with our own code, usually using
> add_subdirectory utilizing their native CMake buildsystem.
>
> Turns out, other developers also like the CMake install mechanism.
>
> So now the INSTALL target of our whole project also installs thirdparty
> components, which we do not want to deliver with our own product (think
> static libraries, which are already linked into our executable).
>
> After a lot of googling, here's my question: Is there a clean way to
> disable the install target for a subdirectory _without_ also disabling
> it completely for the remaining project?
>

I would never add third party libraries to my own project in such a way
mainly because:
- either my project or external project may change a variable (cache it)
and give me a head ache figuring out where the interaction went wrong (and
having to be so intimate with their build scripts is usually poor use of
time) and
- I would rarely/somewhat independently be changing their code.

I would either build external libraries (of course along with the relevant
headers) and install them somewhere on the system (treating them as a
separate project development wise) and then write find scripts for my
project to be used with "find_package()" command
or in case I'll be making some sort of an uberbuild or changing the
external code a bit more regularly (at which point I'd start to question
the design and maturity of the external dependency...) I'd go with
ExternalProject_Add() command and then install the dependencies that I'd
still like to see in my project by calling combination of
"ExternalProject_Get_Property(... binary_dir)" and "install()" commands -
external projects won't rebuild automatically if you change the code but
you can always go into the relevant subdirectory and rebuild it there (I've
found no problems doing that as usually I won't go changing multiple
external dependencies at the same time - doing that would usually indicate
poor design or invalid use of the external dependencies or my code).

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

From Adrian.Sevcenco at cern.ch  Thu Feb 16 03:32:02 2017
From: Adrian.Sevcenco at cern.ch (Adrian Sevcenco)
Date: Thu, 16 Feb 2017 10:32:02 +0200
Subject: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)
In-Reply-To: <CAOXZzG7uxA1owrXuciwn62sd0dM1NyGCJwa+nwtwgtts55cmKg@mail.gmail.com>
References: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>
 <20374773.Da6W4JisLC@eto> <f13929b2-754f-9d8f-d509-2c284f043440@cern.ch>
 <CAOXZzG7uxA1owrXuciwn62sd0dM1NyGCJwa+nwtwgtts55cmKg@mail.gmail.com>
Message-ID: <1846ac2f-63b0-d751-9b71-19addc0bf43c@cern.ch>

On 02/15/2017 09:04 PM, Chuck Atkins wrote:
> Hi Adrian,
Hi! and thank you for looking into this problem!

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

>
>
>
>     So, does anyone have any idea what is the latest 3.x version that
>     can be built on centos 7?
>
>
> All that being said, I wasn't able to reproduce the error with the
> current 3.7.2 release:
>
> [chuck.atkins at deepthought v3.7.2]$ lsb_release -d
> Description:    CentOS Linux release 7.3.1611 (Core)
> [chuck.atkins at deepthought v3.7.2]$ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
> ...
> [chuck.atkins at deepthought v3.7.2]$ ../../source/v3.7.2/bootstrap
> --parallel=28
> ...
> CMake has bootstrapped.  Now run gmake.
> [chuck.atkins at deepthought v3.7.2]$ make -j28
> ...
> 100%] Built target ctest
> [chuck.atkins at deepthought v3.7.2]$ ./bin/ctest -j 28
> ...
> 100% tests passed, 0 tests failed out of 431
>
> Label Time Summary:
> Label1    =   0.51 sec (1 test)
> Label2    =   0.51 sec (1 test)
>
> Total Test time (real) = 247.03 sec
> [chuck.atkins at deepthought v3.7.2]$
>
> What specific versionof EL7 are you running and which version of GCC?
the standard ones :
lsb_release -d
Description:    CentOS Linux release 7.3.1611 (Core)

gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)

i try to create cmake rpm based on the spec of
cmake-3.6.2-6.fc25.src.rpm
from which i removed most of the patches (i just want an rpm for centos 
7) and used source of 3.7.2

Thank you!!
Adrian






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2292 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170216/b1246717/attachment.bin>

From ycollette.nospam at free.fr  Thu Feb 16 04:06:22 2017
From: ycollette.nospam at free.fr (ycollette.nospam at free.fr)
Date: Thu, 16 Feb 2017 10:06:22 +0100 (CET)
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <567454810.97014844.1487235817235.JavaMail.root@zimbra35-e6>
Message-ID: <1604292949.97030776.1487235982959.JavaMail.root@zimbra35-e6>

Hello,

My question is related to CMAKE_*_FLAGS.
I've got a project under linux fedora 24 and, in release mode, this project compiles with the -O2 flag.
But when I switched to other platform (ubuntu, fedora 16 - I now this one is quite old but I need to compile on this platform), this default optimization flag changes. On some platform, it's -O3.
And because with -O3 flag some "risky" optimizations are enabled, my project hangs ...

Is it normal to have such a variations in default optimization flags in release mode ?

Best regards,

YC

From dan at su-root.co.uk  Thu Feb 16 04:26:01 2017
From: dan at su-root.co.uk (Dan Liew)
Date: Thu, 16 Feb 2017 09:26:01 +0000
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <1604292949.97030776.1487235982959.JavaMail.root@zimbra35-e6>
References: <567454810.97014844.1487235817235.JavaMail.root@zimbra35-e6>
 <1604292949.97030776.1487235982959.JavaMail.root@zimbra35-e6>
Message-ID: <CAJ7DczGvA66HpB9EvbKimQqpjGDH7uYnCQvH2SMnEiC+0h-q+A@mail.gmail.com>

Hi,

On 16 February 2017 at 09:06,  <ycollette.nospam at free.fr> wrote:
> Hello,
>
> My question is related to CMAKE_*_FLAGS.
> I've got a project under linux fedora 24 and, in release mode, this project compiles with the -O2 flag.
> But when I switched to other platform (ubuntu, fedora 16 - I now this one is quite old but I need to compile on this platform), this default optimization flag changes. On some platform, it's -O3.
> And because with -O3 flag some "risky" optimizations are enabled, my project hangs ...

You can find CMake's defaults for gcc/clang in

/usr/share/cmake-<version>/Modules/Compiler/GNU.cmake

where <version> is your CMake version.

E.g.

https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake

You'll see lines like

```
string(APPEND CMAKE_${lang}_FLAGS_INIT " ")
string(APPEND CMAKE_${lang}_FLAGS_DEBUG_INIT " -g")
string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
```

It's possible that the defaults changed at some point but I would be
really surprised by this. Are you sure you weren't doing a
RELWITHDEBINFO build on one system and a RELEASE build on the other?

It is possible to override these defaults by writing an overrides file
(example [1]) and then using those overrides before the `project()`
declaration in your root `CMakeLists.txt` file.
Here's an example [2].

So if you need fine grained control over the optimization level used
for different build types then I suggest you use overrides.


[1] https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/cmake/c_flags_override.cmake
[2] https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/CMakeLists.txt#L5

HTH,
Dan.

From ycollette.nospam at free.fr  Thu Feb 16 04:34:12 2017
From: ycollette.nospam at free.fr (ycollette.nospam at free.fr)
Date: Thu, 16 Feb 2017 10:34:12 +0100 (CET)
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <CAJ7DczGvA66HpB9EvbKimQqpjGDH7uYnCQvH2SMnEiC+0h-q+A@mail.gmail.com>
Message-ID: <1297356958.97138463.1487237652904.JavaMail.root@zimbra35-e6>

cmake version on fedora 25: 3.6.2

And the corresponding lines in GNU.cmake (there are some differences):

  # Initial configuration flags.
  set(CMAKE_${lang}_FLAGS_INIT "")
  set(CMAKE_${lang}_FLAGS_DEBUG_INIT "-g")
  set(CMAKE_${lang}_FLAGS_MINSIZEREL_INIT "-Os -DNDEBUG")
  set(CMAKE_${lang}_FLAGS_RELEASE_INIT "-O2 -DNDEBUG")
  set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT "-O2 -g -DNDEBUG")
  set(CMAKE_${lang}_CREATE_PREPROCESSED_SOURCE "<CMAKE_${lang}_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -E <SOURCE> > <PREPROCESSED_SOURCE>")
  set(CMAKE_${lang}_CREATE_ASSEMBLY_SOURCE "<CMAKE_${lang}_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -S <SOURCE> -o <ASSEMBLY_SOURCE>")

So, as you can see, on  Fedora 25, there are no -O3 flags by default.

YC

----- Mail original -----
De: "Dan Liew" <dan at su-root.co.uk>
?: "ycollette nospam" <ycollette.nospam at free.fr>
Cc: "cmake" <cmake at cmake.org>
Envoy?: Jeudi 16 F?vrier 2017 10:26:01
Objet: Re: [CMake] Default CMAKE_C_FLAGS value by OS

Hi,

On 16 February 2017 at 09:06,  <ycollette.nospam at free.fr> wrote:
> Hello,
>
> My question is related to CMAKE_*_FLAGS.
> I've got a project under linux fedora 24 and, in release mode, this project compiles with the -O2 flag.
> But when I switched to other platform (ubuntu, fedora 16 - I now this one is quite old but I need to compile on this platform), this default optimization flag changes. On some platform, it's -O3.
> And because with -O3 flag some "risky" optimizations are enabled, my project hangs ...

You can find CMake's defaults for gcc/clang in

/usr/share/cmake-<version>/Modules/Compiler/GNU.cmake

where <version> is your CMake version.

E.g.

https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake

You'll see lines like

```
string(APPEND CMAKE_${lang}_FLAGS_INIT " ")
string(APPEND CMAKE_${lang}_FLAGS_DEBUG_INIT " -g")
string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
```

It's possible that the defaults changed at some point but I would be
really surprised by this. Are you sure you weren't doing a
RELWITHDEBINFO build on one system and a RELEASE build on the other?

It is possible to override these defaults by writing an overrides file
(example [1]) and then using those overrides before the `project()`
declaration in your root `CMakeLists.txt` file.
Here's an example [2].

So if you need fine grained control over the optimization level used
for different build types then I suggest you use overrides.


[1] https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/cmake/c_flags_override.cmake
[2] https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/CMakeLists.txt#L5

HTH,
Dan.

From zomeck at gmail.com  Thu Feb 16 05:45:22 2017
From: zomeck at gmail.com (Gerard Bahi)
Date: Thu, 16 Feb 2017 11:45:22 +0100
Subject: [CMake] cpack logging question
Message-ID: <CAHZFc0VO_qJ+wVy=O4BSwYPD5-4e9A7vR6BrjOJt0kYeY=N+CA@mail.gmail.com>

Hi,
I am using the cpack variable CPACK_INSTALL_COMMANDS to run an extra
command. (First time I do this)

I have noticed that whenever the script command fails I get a log with the
output in (InstallOtput.log)

However when it runs correctly I have no log at all. I have tried to
redirect the output in the command (e.g.: "echo hi > aFile) but that does
not work either.

Is there any way to actually get the log on success? I don't mind if it is
on standard out or in a file.

Thanks!
Gerard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170216/ac54c564/attachment.html>

From florent.castelli at gmail.com  Thu Feb 16 07:33:06 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Thu, 16 Feb 2017 13:33:06 +0100
Subject: [CMake] Disabling INSTALL target for subdirectory
In-Reply-To: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
References: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
Message-ID: <CACTXgOY-jPVe=m8s9geLkCpRJJATK7ozwanEDjQ3eMUdueR6sw@mail.gmail.com>

Use add_subdirectory(...  EXCLUDE_FROM_ALL) to prevent anything in there to
be installed by default.
I had the issue in one project and it did fix it for us.

Also, 3rdparty libraries should be tagged like that anyway to be built only
when they are used by the main targets.

/Florent

On Feb 16, 2017 07:59, "Milan Ziegler" <milan at fastmail.com> wrote:

> Hi,
>
> we are using the CMake install mechanism "install(...)" to copy all
> relevant files and target binaries of the product into the CMake install
> prefix folder, for further packaging. So far so good.
>
> We are also using several thirdparty libraries, hosting them inside our
> own repository and building them along with our own code, usually using
> add_subdirectory utilizing their native CMake buildsystem.
>
> Turns out, other developers also like the CMake install mechanism.
>
> So now the INSTALL target of our whole project also installs thirdparty
> components, which we do not want to deliver with our own product (think
> static libraries, which are already linked into our executable).
>
> After a lot of googling, here's my question: Is there a clean way to
> disable the install target for a subdirectory _without_ also disabling
> it completely for the remaining project?
>
> What we already tried:
> * Setting CMAKE_INSTALL_PREFIX to a temporary directory for the
> subdirectory (doesn't work)
> * "function(install) endfunction()" to disable the install function for
> the subdirectory (breaks CMake in hilarious ways)
>
> What we now do:
> Using a custom target, we patch the cmake_install.cmake files in the
> build directories before installing (works, but it's an  abomination of
> a hack)
>
> Any help? I think it's a valid usecase for CMake but there doesn't seem
> to be an easy way to do it.
>
> We are using CMake 3.5.
>
>
> Thank you :)
>
> --
>   Milan
>   milan at fastmail.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/20170216/c8603d84/attachment.html>

From chuck.atkins at kitware.com  Thu Feb 16 08:47:19 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Feb 2017 08:47:19 -0500
Subject: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)
In-Reply-To: <1846ac2f-63b0-d751-9b71-19addc0bf43c@cern.ch>
References: <e9745bf3-1658-c08d-0dfb-41d30cdb223d@cern.ch>
 <20374773.Da6W4JisLC@eto>
 <f13929b2-754f-9d8f-d509-2c284f043440@cern.ch>
 <CAOXZzG7uxA1owrXuciwn62sd0dM1NyGCJwa+nwtwgtts55cmKg@mail.gmail.com>
 <1846ac2f-63b0-d751-9b71-19addc0bf43c@cern.ch>
Message-ID: <CAOXZzG6dNOLBh6cGYt23Vnf7sO8hq97fqhE2_Ehmu-_YaYraMg@mail.gmail.com>

Hi Adrian,

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

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

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

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

From chuck.atkins at kitware.com  Thu Feb 16 10:07:21 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Feb 2017 10:07:21 -0500
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <1297356958.97138463.1487237652904.JavaMail.root@zimbra35-e6>
References: <CAJ7DczGvA66HpB9EvbKimQqpjGDH7uYnCQvH2SMnEiC+0h-q+A@mail.gmail.com>
 <1297356958.97138463.1487237652904.JavaMail.root@zimbra35-e6>
Message-ID: <CAOXZzG6m8jzMekNvy-akutXmMpJdMukHWXM-5hVNZQAPTdMkmQ@mail.gmail.com>

Hi YC,


> cmake version on fedora 25: 3.6.2
>

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

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

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170216/981386b9/attachment-0001.html>

From ycollette.nospam at free.fr  Thu Feb 16 10:56:00 2017
From: ycollette.nospam at free.fr (ycollette.nospam at free.fr)
Date: Thu, 16 Feb 2017 16:56:00 +0100 (CET)
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <CAOXZzG6m8jzMekNvy-akutXmMpJdMukHWXM-5hVNZQAPTdMkmQ@mail.gmail.com>
Message-ID: <1002159281.98434854.1487260560198.JavaMail.root@zimbra35-e6>

Thanks a lot for all these informations.
I wrote a macro to be sure to replace all the -O3 flags ...

# replace_ccxx_flag: replace compilation flags from the compiler command line
# flag_orig: the flag to be replace
# flag_dest: the new flag value
macro(replace_ccxx_flag flag_orig flag_dest) 
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS                  "${CMAKE_C_FLAGS}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS                "${CMAKE_CXX_FLAGS}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS_RELEASE          "${CMAKE_C_FLAGS_RELEASE}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS_RELEASE        "${CMAKE_CXX_FLAGS_RELEASE}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS_DEBUG            "${CMAKE_C_FLAGS_DEBUG}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS_DEBUG          "${CMAKE_CXX_FLAGS_DEBUG}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS_RELWITHDEBINFO   "${CMAKE_C_FLAGS_RELWITHDEBINFO}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
endmacro()

Best regards,

YC

----- Mail original -----
De: "Chuck Atkins" <chuck.atkins at kitware.com>
?: "ycollette nospam" <ycollette.nospam at free.fr>
Cc: "Dan Liew" <dan at su-root.co.uk>, "cmake" <cmake at cmake.org>
Envoy?: Jeudi 16 F?vrier 2017 16:07:21
Objet: Re: [CMake] Default CMAKE_C_FLAGS value by OS





Hi YC, 



cmake version on fedora 25: 3.6.2 



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


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


- Chuck 



From chuck.atkins at kitware.com  Thu Feb 16 11:53:18 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Feb 2017 11:53:18 -0500
Subject: [CMake] [cmake-developers] how to use cmake3.7 for building
 fast code infedora 24
In-Reply-To: <1943300789.1062125.1487263071891@mail.yahoo.com>
References: <377226531.582734.1487241731598.ref@mail.yahoo.com>
 <377226531.582734.1487241731598@mail.yahoo.com>
 <1487259655784.506081743@boxbe>
 <1943300789.1062125.1487263071891@mail.yahoo.com>
Message-ID: <CAOXZzG4fGvfynJf7OiFjrKgbFbTDJbSp8zHU=_M=b2ZRqTybPQ@mail.gmail.com>

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


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

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

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

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

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170216/fd684ed3/attachment.html>

From irwin at beluga.phys.uvic.ca  Thu Feb 16 12:06:46 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 16 Feb 2017 09:06:46 -0800 (PST)
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <CAOXZzG6m8jzMekNvy-akutXmMpJdMukHWXM-5hVNZQAPTdMkmQ@mail.gmail.com>
References: <CAJ7DczGvA66HpB9EvbKimQqpjGDH7uYnCQvH2SMnEiC+0h-q+A@mail.gmail.com>
 <1297356958.97138463.1487237652904.JavaMail.root@zimbra35-e6>
 <CAOXZzG6m8jzMekNvy-akutXmMpJdMukHWXM-5hVNZQAPTdMkmQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1702160744010.10983@enira.zlyna.ubzr>

On 2017-02-16 10:07-0500 Chuck Atkins wrote:

> Hi YC,
>
>
>> cmake version on fedora 25: 3.6.2
>>
>
> Fedora is specifically patching CMake in the RPM spec file to reduce the
> gcc flag from O3 to O2 so it's the distributuion's packaging making that
> change, not CMake itself.  If you download and build the source from
> cmake.org then you'll get O3 as default for gcc release builds.
>
> That being said, I do think we should revisit the use of O3 by default
> given the safety issues surounding it.

I agree with RedHat developers that O3 by default (especially if you
only use it for releases in a largely untested way) is likely a bad
idea. But developers of other distros obviously disagree with RedHat. 
Of course, this also means that the decision CMake developers
make about this doesn't affect that many users because distros are
likely going to override whatever decision CMake developers make in
this regard.  And some CMake users like me who build our own CMake version
also ignore all default optimization choices set by CMake developers.

For example, in my case I want to test that PLplot reduces externally
visible library symbols to a minimum, and I want to look for
uninitialized variable possibilities so I typically use

export CFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
export CXXFLAGS='-O3 -fvisibility=hidden -Wuninitialized'

for testing throughout our release cycles and not just at the end of
release cycles in the last-minute rush before release.

But before getting to why I do that, I want to review why some
developers (like me) feel that in certain circumstances -O3 can be
dangerous.

There is an interesting discussion of O3 safety at
<http://stackoverflow.com/questions/11546075/is-optimisation-level-o3-dangerous-in-g>.
Issues discussed that seem to weigh against using O3 for any default
choice were the following:

1. O3 can expose incorrect code assumptions.

2. O3 adds additional optimizations to O2 and is less thoroughly
tested by users so there is more chance of gcc
compiler suite bugs for O3.  (Although nobody was aware at the time of that
discussion of any O3-specific bug in the gcc compiler suite).

3. O3 can sometimes give you slower code due to cache considerations.

My own personal experience is that several years ago I started testing
with -O3 late in a release cycle for a particular PLplot release, and
it started segfaulting like crazy while it was perfectly fine with
-O2.  We finally narrowed the problem to a small recursive routine
that we had implemented, and the only solution to avoid the -O3 issue
was to rewrite that routine in a non-recursive way even though none of
our developers could see anything wrong with the recursive version.

We never did figure out whether we were encountering issue 1 or issue
2, but the story does illustrate the problems you can encounter if you
debug and do the bulk of the testing of your code at low optimization
levels, and then introduce a high optimization level late in a release
cycle.  So now I always test consistently with -O3 throughout the
release cycle (and have never again encountered an issue with that
optimization level, natch).  Also, we don't make binary releases of
PLplot ourselves so essentially we leave it to Linux, Mac, and Windows
distributors of binary versions of PLplot to decide what optimization
level they are going to use for all the binary software projects they
distribute.

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 zlynx at acm.org  Thu Feb 16 12:17:58 2017
From: zlynx at acm.org (Zan Lynx)
Date: Thu, 16 Feb 2017 10:17:58 -0700
Subject: [CMake] Default CMAKE_C_FLAGS value by OS
In-Reply-To: <CAOXZzG6m8jzMekNvy-akutXmMpJdMukHWXM-5hVNZQAPTdMkmQ@mail.gmail.com>
References: <CAJ7DczGvA66HpB9EvbKimQqpjGDH7uYnCQvH2SMnEiC+0h-q+A@mail.gmail.com>
 <1297356958.97138463.1487237652904.JavaMail.root@zimbra35-e6>
 <CAOXZzG6m8jzMekNvy-akutXmMpJdMukHWXM-5hVNZQAPTdMkmQ@mail.gmail.com>
Message-ID: <022ac8ff-6792-9a61-3fab-8b650c17d3ec@acm.org>

On 02/16/2017 08:07 AM, Chuck Atkins wrote:
> That being said, I do think we should revisit the use of O3 by default
> given the safety issues surounding it.

The following is just my opinion:

In my experience if O3 fails it is a bug in the compiler, which should
be fixed and somebody has to find them first. Or a bug in the code being
built with O3, usually something subtle with undefined behavior.

Code bugs that happen to work sort-of correctly under O2 but not O3
aren't really safe. Future compiler versions often include changes that
break the code anyway.

I build a couple of production release C++ projects under several
versions of GCC (Linux releases since 2010). I use O3 and profiling
feedback, which, yes, does reveal some bugs, even up to segfaulting the
compiler, so I have special checks in the Makefile for a few of those
versions.

The thing that makes this safe to do is testing. If the code isn't
working correctly because of O3 I know it because it fails to pass its
tests.

I haven't looked but I would hope CMake has tests that are run against
the optimized code...
-- 
                Knowledge is Power -- Power Corrupts
                        Study Hard -- Be Evil

From milan at fastmail.com  Fri Feb 17 01:32:07 2017
From: milan at fastmail.com (Milan Ziegler)
Date: Fri, 17 Feb 2017 07:32:07 +0100
Subject: [CMake] Disabling INSTALL target for subdirectory
In-Reply-To: <CACTXgOY-jPVe=m8s9geLkCpRJJATK7ozwanEDjQ3eMUdueR6sw@mail.gmail.com>
References: <1487228388.1605213.882736944.3A41E5FB@webmail.messagingengine.com>
 <CACTXgOY-jPVe=m8s9geLkCpRJJATK7ozwanEDjQ3eMUdueR6sw@mail.gmail.com>
Message-ID: <1487313127.1699410.883933920.2EAFA69D@webmail.messagingengine.com>

Hi Florent,



thank you so much. EXCLUDE_FROM_ALL does indeed have the effect of
ignoring any install() invocations from within the subdirectory. I
remember stumbling across this option, but from the docs I didn't get
the impression that this would affect the installation as well.


Maybe the documentation needs a few more words here.



> 

> Also, 3rdparty libraries should be tagged like that anyway to be built
> only when they are used by the main targets.
Yes, this is a good idea.





Thanks again,

Milan





--

  Milan Ziegler

  milan at fastmail.com







On Thu, Feb 16, 2017, at 13:33, Florent Castelli wrote:

> Use add_subdirectory(...  EXCLUDE_FROM_ALL) to prevent anything in
> there to be installed by default.
> I had the issue in one project and it did fix it for us. 

> 

> Also, 3rdparty libraries should be tagged like that anyway to be built
> only when they are used by the main targets.
> 

> /Florent 

> 

> On Feb 16, 2017 07:59, "Milan Ziegler" <milan at fastmail.com> wrote:

>> Hi,

>> 

>>  we are using the CMake install mechanism "install(...)" to copy all
>>  relevant files and target binaries of the product into the CMake
>>  install
>>  prefix folder, for further packaging. So far so good.

>> 

>>  We are also using several thirdparty libraries, hosting them
>>  inside our
>>  own repository and building them along with our own code,
>>  usually using
>>  add_subdirectory utilizing their native CMake buildsystem.

>> 

>>  Turns out, other developers also like the CMake install mechanism.

>> 

>>  So now the INSTALL target of our whole project also installs
>>  thirdparty
>>  components, which we do not want to deliver with our own product
>>  (think
>>  static libraries, which are already linked into our executable).

>> 

>>  After a lot of googling, here's my question: Is there a clean way to
>>  disable the install target for a subdirectory _without_ also
>>  disabling
>>  it completely for the remaining project?

>> 

>>  What we already tried:

>>  * Setting CMAKE_INSTALL_PREFIX to a temporary directory for the

>>  subdirectory (doesn't work)

>>  * "function(install) endfunction()" to disable the install
>>    function for
>>  the subdirectory (breaks CMake in hilarious ways)

>> 

>>  What we now do:

>>  Using a custom target, we patch the cmake_install.cmake files in the
>>  build directories before installing (works, but it's an
>>  abomination of
>>  a hack)

>> 

>>  Any help? I think it's a valid usecase for CMake but there
>>  doesn't seem
>>  to be an easy way to do it.

>> 

>>  We are using CMake 3.5.

>> 

>> 

>>  Thank you :)

>> 

>>  --

>>    Milan

>>    milan at fastmail.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/20170217/5e985b48/attachment.html>

From tonka3100 at gmail.com  Sun Feb 19 14:02:35 2017
From: tonka3100 at gmail.com (tonka3100 at gmail.com)
Date: Sun, 19 Feb 2017 20:02:35 +0100
Subject: [CMake] best practice for bundling 3rdparty dependencies in windows
Message-ID: <CCB19DAF-6C3C-4424-8F95-119B1FD785DF@gmail.com>

Hey @everybody,

I have a question about best practice for app bundling especially 3rdparty libs. In Linux it is not some common to bundle 3rdparty libs with my application but in windows this is highly recommended. What?s a good way to bundle 3rdparty libs (mostly .dll, sometimes also .exe) in windows (maybe macos x has the same ?problem?).

At the moment i use install(FILES ?) to install the 3rdparty libs (i?ve tried to install imported target, but thats not possible :-( ). I use a cmake variable to activate (default is off) to copy 3rdparty libs to the install directory. The only other way i could go is to add a cpack_install_script file, but this is only availabe in cpack time.

So is there a better way to bundle 3rdparty libs or is this the recommended approach?

Thanks in advance
Tonka

From konstantin at podsvirov.pro  Sun Feb 19 14:17:19 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Sun, 19 Feb 2017 22:17:19 +0300
Subject: [CMake] best practice for bundling 3rdparty dependencies in
	windows
In-Reply-To: <CCB19DAF-6C3C-4424-8F95-119B1FD785DF@gmail.com>
References: <CCB19DAF-6C3C-4424-8F95-119B1FD785DF@gmail.com>
Message-ID: <14181331487531839@web11o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170219/aeff78f0/attachment.html>

From aishwaryaselvaraj1708 at gmail.com  Mon Feb 20 04:46:37 2017
From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj)
Date: Mon, 20 Feb 2017 14:16:37 +0430
Subject: [CMake] cmake in windows
Message-ID: <CACWTKSrazxzvij+Kf+EGxFTviPLhwKkp2Wz+WTH+gndtTpouWw@mail.gmail.com>

Hi ,
I wanted to obtain binary file for the .cpp code I have written .
My .cpp make use of two external library
1) libsndfile
2) armadillo

I wrote cmakelists .using external project and other command to build and
obtain the binary file .
I was successfull in doing so .

Now I want to try the similiar operation in Windows .
I have never worked on cmake platform in windows .Can anyone guide me upon
it , specifying even its pre requirements .


Thank you .

-- 
Regards,
Aishwarya Selvaraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170220/d0b6f1f7/attachment.html>

From manojr at ti.com  Mon Feb 20 05:12:44 2017
From: manojr at ti.com (R, Manoj)
Date: Mon, 20 Feb 2017 10:12:44 +0000
Subject: [CMake] Response files not working with TI compilers
In-Reply-To: <CAH4Rq7oApHgKRrA8HYTZ-Us_mnD5ug1=PP4+wmdN7ph+YaVspA@mail.gmail.com>
References: <CAH4Rq7oApHgKRrA8HYTZ-Us_mnD5ug1=PP4+wmdN7ph+YaVspA@mail.gmail.com>
Message-ID: <5DA0BF7A1FCA064A97B178FC4B461049C01302B8@DBDE04.ent.ti.com>

When will these changes be available in the official version of cmake.
I also made similar changes. I am suing 3.8 version of the CMake and the issue is not fixed.

Regards

Manoj R

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Arturo Crespo
Sent: Wednesday, January 11, 2017 9:02 PM
To: cmake at cmake.org
Subject: [CMake] Response files not working with TI compilers

Dear All,

I'm currently using CMake-3.7.1 to build a big project with different TI compilers (cl6x, armcl, cl-arp32)  and since several months ago I started to use linker response files because the linker command line was too long for Windows and the build was failing.

When I tried to do this for the first time I got a linker error with an invalid flag being used, as the TI linker doesn't support response files (-@)

The way CMake invokes the TI linker is as mentioned in the TI documentation by invoking the compiler with an option to run the linker, i.e. cl6x --run_linker [options] filename1, ..., filenameN, in TI-CXX.cmake:
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> --run_linker --output_file=<TARGET> --map_file=<TARGET>.map <CMAKE_CXX_LINK_FLAGS> <LINK_LIBRARIES> <LINK_FLAGS> <OBJECTS>")

The solution that I found was to change the order of the arguments passed to the linker, because the TI compiler supports response files (-@) and it passes that information to the linker, so by moving <OBJECTS> before --run_linker the problem was solved:
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> <OBJECTS> --run_linker --output_file=<TARGET> --map_file=<TARGET>.map <CMAKE_CXX_LINK_FLAGS> <LINK_LIBRARIES> <LINK_FLAGS>")

The same change is needed in TI-C.cmake

This issue is present since at least since CMake-3.3.2

Regards,
Arturo

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

From nilsgladitz at gmail.com  Mon Feb 20 08:02:20 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Mon, 20 Feb 2017 14:02:20 +0100
Subject: [CMake] Response files not working with TI compilers
In-Reply-To: <5DA0BF7A1FCA064A97B178FC4B461049C01302B8@DBDE04.ent.ti.com>
References: <CAH4Rq7oApHgKRrA8HYTZ-Us_mnD5ug1=PP4+wmdN7ph+YaVspA@mail.gmail.com>
 <5DA0BF7A1FCA064A97B178FC4B461049C01302B8@DBDE04.ent.ti.com>
Message-ID: <3c580eba-5e06-78e6-42ce-ea1327a86ace@gmail.com>

On 02/20/2017 11:12 AM, R, Manoj wrote:

> When will these changes be available in the official version of cmake.
>
> I also made similar changes. I am suing 3.8 version of the CMake and 
> the issue is not fixed.
>

The users mailing list might not be the ideal place to bring up issues 
like this.

You might want to report the issue here:
     https://gitlab.kitware.com/cmake/cmake/issues

and/or discuss the fix on the developers mailing list:
     https://cmake.org/mailman/listinfo/cmake-developers

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170220/8f71fbca/attachment-0001.html>

From falk.tristram at cognex.com  Mon Feb 20 08:52:25 2017
From: falk.tristram at cognex.com (Tristram, Falk)
Date: Mon, 20 Feb 2017 13:52:25 +0000
Subject: [CMake] Response files not working with TI compilers
In-Reply-To: <5DA0BF7A1FCA064A97B178FC4B461049C01302B8@DBDE04.ent.ti.com>
References: <CAH4Rq7oApHgKRrA8HYTZ-Us_mnD5ug1=PP4+wmdN7ph+YaVspA@mail.gmail.com>
 <5DA0BF7A1FCA064A97B178FC4B461049C01302B8@DBDE04.ent.ti.com>
Message-ID: <4c1ef2098d6145a6a0ba225d82600993@eupaexcp1.europe.pc.cognex.com>

Hi,

I can confirm issues with the TI-C.cmake, not specifically with your problem,
but for some of the TI tools the command line input is not commutative.

Before changing this in CMake I would like to highlight two important points:

1. I am not sure if anyone of the CMake core developers actually has a TI-Compiler to test certain things.
So the question would be, how to test and verify these changes.

2. CMake is currently supporting several versions of the TI-Compiler and TI platforms.
For example the cg-tools 6 is very different to cg-tools 7.
I didn?t work with cg-tools 8 so far, but according to the release notes it is different to version 7.

All the changes should work with the versions 6,7 and 8. And these are only the C6X compilers/linkers.

Regards,
Falk

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of R, Manoj
Sent: Montag, 20. Februar 2017 11:13
To: Arturo Crespo; cmake at cmake.org
Subject: Re: [CMake] Response files not working with TI compilers

When will these changes be available in the official version of cmake.
I also made similar changes. I am suing 3.8 version of the CMake and the issue is not fixed.

Regards

Manoj R

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Arturo Crespo
Sent: Wednesday, January 11, 2017 9:02 PM
To: cmake at cmake.org<mailto:cmake at cmake.org>
Subject: [CMake] Response files not working with TI compilers

Dear All,

I'm currently using CMake-3.7.1 to build a big project with different TI compilers (cl6x, armcl, cl-arp32)  and since several months ago I started to use linker response files because the linker command line was too long for Windows and the build was failing.

When I tried to do this for the first time I got a linker error with an invalid flag being used, as the TI linker doesn't support response files (-@)

The way CMake invokes the TI linker is as mentioned in the TI documentation by invoking the compiler with an option to run the linker, i.e. cl6x --run_linker [options] filename1, ..., filenameN, in TI-CXX.cmake:
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> --run_linker --output_file=<TARGET> --map_file=<TARGET>.map <CMAKE_CXX_LINK_FLAGS> <LINK_LIBRARIES> <LINK_FLAGS> <OBJECTS>")

The solution that I found was to change the order of the arguments passed to the linker, because the TI compiler supports response files (-@) and it passes that information to the linker, so by moving <OBJECTS> before --run_linker the problem was solved:
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> <OBJECTS> --run_linker --output_file=<TARGET> --map_file=<TARGET>.map <CMAKE_CXX_LINK_FLAGS> <LINK_LIBRARIES> <LINK_FLAGS>")

The same change is needed in TI-C.cmake

This issue is present since at least since CMake-3.3.2

Regards,
Arturo

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

From iraytrace at gmail.com  Mon Feb 20 11:26:33 2017
From: iraytrace at gmail.com (Lee Butler)
Date: Mon, 20 Feb 2017 11:26:33 -0500
Subject: [CMake] best practice for bundling 3rdparty dependencies in,
	windows
In-Reply-To: <mailman.1363.1487595745.15420.cmake@cmake.org>
References: <mailman.1363.1487595745.15420.cmake@cmake.org>
Message-ID: <e3ea4d28-ef6f-fab1-bba8-98f701f9984c@gmail.com>

Since I have wrestled with this on a recurring basis let me offer the following.  We package Qt. OpenSceneGraph and other libraries as 3rdParty content to the application we build/deploy.  Because the 3rd party libraries have their own plugins and dependencies, we end up doing a number of things:

1) install(TARGETS ...) to get the things we build installed
2) install(CODE ...) to get a lot of dependencies installed.

The thing to keep in mind is that CPACK essentially does an install to a directory other than the CMAKE_INSTALL_PREFIX to create the file system structure that it will package.  It seems to do this by setting CMAKE_INSTALL_PREFIX to something it wants.  This is slick but if you are doing things by hand you have to realize that it isn't the location you set when you run CMAKE.

Some of the key code looks like this:set(EXEC_NAME "vsl-bin")

 1. set(EXEC_NAME "vsl-bin")
 2. add_executable(${EXEC_NAME} ${product_SRCS} ${UIS} ${RCS} )
 3. target_link_libraries(${EXEC_NAME} ${product_LIBS})
 4. install(TARGETS ${EXEC_NAME}
 5.       BUNDLE DESTINATION . COMPONENT Runtime
 6.       RUNTIME DESTINATION bin COMPONENT Runtime )
 7. INSTALL(CODE "file(GLOB_RECURSE VSLPLUGINS
    \"\${CMAKE_INSTALL_PREFIX}/bin/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
 8.       FILE(COPY \"${OSG_INCLUDE_DIR}/../bin/osgPlugins-3.4.0\"
    DESTINATION \"\${CMAKE_INSTALL_PREFIX}/bin\")
 9.       FILE(GLOB OSGLIBS
    \"${OSG_INCLUDE_DIR}/../bin/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
10.       FILE(COPY \${OSGLIBS} DESTINATION
    \"\${CMAKE_INSTALL_PREFIX}/bin\")
11.       FILE(GLOB QTPLUGINS \"${Qt5_DIR}/../../../plugins/*\")
12.       FILE(COPY \${QTPLUGINS} DESTINATION
    \"\${CMAKE_INSTALL_PREFIX}/bin\")
13.       include(BundleUtilities)
14. fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/${EXEC_NAME}${CMAKE_EXECUTABLE_SUFFIX}\"
    \"\${VSLPLUGINS}\" \"${DIRS}\")
15.       " COMPONENT Runtime)

This works in conjunction with CPACK to create our installer (using WIX) and zip file installers.
7 Copy the application plugins we just build as part of the project
8 get the OSG plugins from where they live into our bin directory
9 get the list of OSG libraries (precompiled elsewhere)
10 copy the OSG Libraries into our bin directory
11 get all the Qt plugins
12 get Qt plugins into our bin directory
13..14 get libraries that we build and depend on into bin (this introspects on the binary to discover)

Alas, CMake/CPack cannot "recursively" look at libraries to find what dependencies exist in the libraries you depend on.  And of course, finding plugins those libraries depend on isn't really possible.  I would really like to see fixup_bundle improved to help handle this sort of thing.  I'd even be willing to pay Kitware to work on it.

So this is the best we have been able to come up with short of diving into the source code for cmake and cpack themselves.  Hope this helps.

Lee

    I have a question about best practice for app bundling especially 3rdparty libs. In Linux it is not some common to bundle 3rdparty libs with my application but in windows this is highly recommended. What?s a good way to bundle 3rdparty libs (mostly .dll, sometimes also .exe) in windows (maybe macos x has the same ?problem?).

    At the moment i use install(FILES ?) to install the 3rdparty libs (i?ve tried to install imported target, but thats not possible  ). I use a cmake variable to activate (default is off) to copy 3rdparty libs to the install directory. The only other way i could go is to add a cpack_install_script file, but this is only availabe in cpack time.

    So is there a better way to bundle 3rdparty libs or is this the recommended approach?

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

From laasunde at hotmail.com  Tue Feb 21 08:48:00 2017
From: laasunde at hotmail.com (Lars)
Date: Tue, 21 Feb 2017 13:48:00 +0000
Subject: [CMake] CMake install imported target using WIX
Message-ID: <HE1PR0301MB2233E1FF0BF87B59F4B4B1E2CA510@HE1PR0301MB2233.eurprd03.prod.outlook.com>

Hello,


We are using the "config" mode of Find_Package that locates CompConfig.cmake which create IMPORTED targets.


CMakeLists.txt

Find_Package(some_comp ${some_comp_path})


CompConfig.cmake;

add_executable(app IMPORTED)

add_library(lib SHARED IMPORTED)


This works fine and once I read https://public.kitware.com/Bug/view.php?id=14311 I managed to get 'make install' to include the IMPORTED targets.


However, it seems CPack -G WIX does not include the imported executables and libraries in its msi.


There is no trace of 'app' or 'lib' in the files.wxs file produced by CPack.


I wanted to check whether this is the expected behaviour or a known issue? If this is a bug, appreciate any input on how to proceed to debug this issue.


Using CMake 3.5.2 and Windows 7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170221/10efac12/attachment.html>

From nilsgladitz at gmail.com  Tue Feb 21 09:33:09 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Tue, 21 Feb 2017 15:33:09 +0100
Subject: [CMake] CMake install imported target using WIX
In-Reply-To: <HE1PR0301MB2233E1FF0BF87B59F4B4B1E2CA510@HE1PR0301MB2233.eurprd03.prod.outlook.com>
References: <HE1PR0301MB2233E1FF0BF87B59F4B4B1E2CA510@HE1PR0301MB2233.eurprd03.prod.outlook.com>
Message-ID: <eb0b121e-54b2-f0fc-3d56-46b8cd197d02@gmail.com>

On 02/21/2017 02:48 PM, Lars wrote:

> Hello,
>
>
> We are using the "config" mode of Find_Package that locates 
> CompConfig.cmake which create IMPORTED targets.
>
>
> CMakeLists.txt
>
> Find_Package(some_comp ${some_comp_path})
>
>
> CompConfig.cmake;
>
> add_executable(app IMPORTED)
>
> add_library(lib SHARED IMPORTED)
>
>
> This works fine and once I read 
> https://public.kitware.com/Bug/view.php?id=14311 
> <https://public.kitware.com/Bug/view.php?id=14311> I managed to get 
> 'make install' to include the IMPORTED targets.
>

What exactly did you take from the issue report?
What are your install() commands?

Everything installed by "make install" should also land in the package 
assuming what ever install logic you used honors the install time 
CMAKE_INSTALL_PREFIX as set up by CPack.

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170221/6069e04f/attachment.html>

From Kris.Malfettone at sig.com  Wed Feb 22 16:11:52 2017
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Wed, 22 Feb 2017 21:11:52 +0000
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <014e73df-efcb-597a-5a70-13bdc19b9423@gmail.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
 <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
 <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>
 <545068f9ba584a499b60ec98f847ad14@xchbal500.ds.susq.com>
 <014e73df-efcb-597a-5a70-13bdc19b9423@gmail.com>
Message-ID: <fb7c81899056447d9d85d035544eeb12@xchbal500.ds.susq.com>

Is there a bug tracker or somewhere that I should report this as well?  I just want to make sure I put the right information in the right spot so the ninja generator maintainer might see it.

From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
Sent: Wednesday, February 15, 2017 9:41 AM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com>; cmake at cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

On 15.02.2017 15:16, Malfettone, Kris wrote:
Just noticed a problem in my example.  In my attempt to simplify my example I moved both outputs into the same folder which in my opinion is invalid because both output file names are the same.  However, the same basic setup does reproduce the problem if you move the two targets into their own subdirs.  I was just trying to avoid describing that in the email.  Here is what I mean below:

I thought you meant you had a target named "test" but apparently only your output is named that way.
That certainly isn't covered by the existing policy.

Nils

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170222/889c2e5b/attachment.html>

From nilsgladitz at gmail.com  Wed Feb 22 16:16:54 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 22 Feb 2017 22:16:54 +0100
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <fb7c81899056447d9d85d035544eeb12@xchbal500.ds.susq.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
 <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
 <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>
 <545068f9ba584a499b60ec98f847ad14@xchbal500.ds.susq.com>
 <014e73df-efcb-597a-5a70-13bdc19b9423@gmail.com>
 <fb7c81899056447d9d85d035544eeb12@xchbal500.ds.susq.com>
Message-ID: <18bc3f1e-d7a6-f12e-04ee-de73220cbd42@gmail.com>

On 22.02.2017 22:11, Malfettone, Kris wrote:
>
> Is there a bug tracker or somewhere that I should report this as 
> well?  I just want to make sure I put the right information in the 
> right spot so the ninja generator maintainer might see it.
>

I am not sure there is a dedicated maintainer for the Ninja generator 
currently but either way the users mailing list might not be the best 
place to reach the developers.
The issue tracker is available here: 
https://gitlab.kitware.com/cmake/cmake/issues
The developers mailing list here: 
https://cmake.org/mailman/listinfo/cmake-developers

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170222/4acbb2dc/attachment.html>

From Kris.Malfettone at sig.com  Wed Feb 22 16:21:00 2017
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Wed, 22 Feb 2017 21:21:00 +0000
Subject: [CMake] Potential bug: Having executables named "test" causes
 Ninja generator to generate ambiguous rules...
In-Reply-To: <18bc3f1e-d7a6-f12e-04ee-de73220cbd42@gmail.com>
References: <6ba59f78482c422590a89e80d59d01c3@xchbal500.ds.susq.com>
 <4834753e-7c84-15b5-3b40-41a51289a769@gmail.com>
 <8b87744e22374a60be41f3c024a776bb@xchbal500.ds.susq.com>
 <3118684f9c3f4feebdc72b6a7b27d554@xchbal500.ds.susq.com>
 <545068f9ba584a499b60ec98f847ad14@xchbal500.ds.susq.com>
 <014e73df-efcb-597a-5a70-13bdc19b9423@gmail.com>
 <fb7c81899056447d9d85d035544eeb12@xchbal500.ds.susq.com>
 <18bc3f1e-d7a6-f12e-04ee-de73220cbd42@gmail.com>
Message-ID: <320b2ef21ec94a0388ec4a80764191e5@xchbal500.ds.susq.com>

Thank you Nils, will do.

From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
Sent: Wednesday, February 22, 2017 4:17 PM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com>; cmake at cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

On 22.02.2017 22:11, Malfettone, Kris wrote:
Is there a bug tracker or somewhere that I should report this as well?  I just want to make sure I put the right information in the right spot so the ninja generator maintainer might see it.

I am not sure there is a dedicated maintainer for the Ninja generator currently but either way the users mailing list might not be the best place to reach the developers.
The issue tracker is available here: https://gitlab.kitware.com/cmake/cmake/issues
The developers mailing list here: https://cmake.org/mailman/listinfo/cmake-developers

Nils

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170222/4a9301c2/attachment-0001.html>

From tonka3100 at gmail.com  Wed Feb 22 16:58:29 2017
From: tonka3100 at gmail.com (tonka tonka)
Date: Wed, 22 Feb 2017 22:58:29 +0100
Subject: [CMake] best practice for bundling 3rdparty dependencies in,
	windows
In-Reply-To: <e3ea4d28-ef6f-fab1-bba8-98f701f9984c@gmail.com>
References: <mailman.1363.1487595745.15420.cmake@cmake.org>
 <e3ea4d28-ef6f-fab1-bba8-98f701f9984c@gmail.com>
Message-ID: <CAEor4NHaBOoCxTvL-ZQU70VMpcgMAxbY9m6UwOb7AdHWgxSzaA@mail.gmail.com>

Thanks for your answer.
I've see that most of your code is very similar to my code, the only
difference is that you use file(copy ... To be able to copy the file to the
install directory, I use install(FILES ...
But what is fixup_bundle good for?

Am 20.02.2017 17:26 schrieb "Lee Butler" <iraytrace at gmail.com>:

> Since I have wrestled with this on a recurring basis let me offer the following.  We package Qt. OpenSceneGraph and other libraries as 3rdParty content to the application we build/deploy.  Because the 3rd party libraries have their own plugins and dependencies, we end up doing a number of things:
>
> 1) install(TARGETS ...) to get the things we build installed
> 2) install(CODE ...) to get a lot of dependencies installed.
>
> The thing to keep in mind is that CPACK essentially does an install to a directory other than the CMAKE_INSTALL_PREFIX to create the file system structure that it will package.  It seems to do this by setting CMAKE_INSTALL_PREFIX to something it wants.  This is slick but if you are doing things by hand you have to realize that it isn't the location you set when you run CMAKE.
>
> Some of the key code looks like this:set(EXEC_NAME "vsl-bin")
>
>
>    1. set(EXEC_NAME "vsl-bin")
>    2. add_executable(${EXEC_NAME} ${product_SRCS} ${UIS} ${RCS} )
>    3. target_link_libraries(${EXEC_NAME} ${product_LIBS})
>    4. install(TARGETS ${EXEC_NAME}
>    5.      BUNDLE DESTINATION . COMPONENT Runtime
>    6.      RUNTIME DESTINATION bin COMPONENT Runtime )
>    7. INSTALL(CODE "file(GLOB_RECURSE VSLPLUGINS
>    \"\${CMAKE_INSTALL_PREFIX}/bin/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
>    8.      FILE(COPY \"${OSG_INCLUDE_DIR}/../bin/osgPlugins-3.4.0\"
>    DESTINATION \"\${CMAKE_INSTALL_PREFIX}/bin\")
>    9.      FILE(GLOB OSGLIBS \"${OSG_INCLUDE_DIR}/../bin/*$
>    {CMAKE_SHARED_LIBRARY_SUFFIX}\")
>    10.      FILE(COPY \${OSGLIBS} DESTINATION \"\${CMAKE_INSTALL_PREFIX}/
>    bin\")
>    11.      FILE(GLOB QTPLUGINS \"${Qt5_DIR}/../../../plugins/*\")
>    12.      FILE(COPY \${QTPLUGINS} DESTINATION
>    \"\${CMAKE_INSTALL_PREFIX}/bin\")
>    13.      include(BundleUtilities)
>    14.      fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/${EXEC_
>    NAME}${CMAKE_EXECUTABLE_SUFFIX}\" \"\${VSLPLUGINS}\" \"${DIRS}\")
>    15.      " COMPONENT Runtime)
>
>
> This works in conjunction with CPACK to create our installer (using WIX) and zip file installers.
> 7 Copy the application plugins we just build as part of the project
> 8 get the OSG plugins from where they live into our bin directory
> 9 get the list of OSG libraries (precompiled elsewhere)
> 10 copy the OSG Libraries into our bin directory
> 11 get all the Qt plugins
> 12 get Qt plugins into our bin directory
> 13..14 get libraries that we build and depend on into bin (this introspects on the binary to discover)
>
> Alas, CMake/CPack cannot "recursively" look at libraries to find what dependencies exist in the libraries you depend on.  And of course, finding plugins those libraries depend on isn't really possible.  I would really like to see fixup_bundle improved to help handle this sort of thing.  I'd even be willing to pay Kitware to work on it.
>
> So this is the best we have been able to come up with short of diving into the source code for cmake and cpack themselves.  Hope this helps.
>
> Lee
>
>
> I have a question about best practice for app bundling especially 3rdparty libs. In Linux it is not some common to bundle 3rdparty libs with my application but in windows this is highly recommended. What?s a good way to bundle 3rdparty libs (mostly .dll, sometimes also .exe) in windows (maybe macos x has the same ?problem?).
>
> At the moment i use install(FILES ?) to install the 3rdparty libs (i?ve tried to install imported target, but thats not possible  ). I use a cmake variable to activate (default is off) to copy 3rdparty libs to the install directory. The only other way i could go is to add a cpack_install_script file, but this is only availabe in cpack time.
>
> So is there a better way to bundle 3rdparty libs or is this the recommended approach?
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20170222/1075410b/attachment.html>

From frelyn.sdiwc at gmail.com  Wed Feb 22 22:30:35 2017
From: frelyn.sdiwc at gmail.com (Frelyn SDIWC)
Date: Thu, 23 Feb 2017 11:30:35 +0800
Subject: [CMake] [CFP] The 5th International Conference on Digital
 Information Processing, E-Business and Cloud Computing (DIPECC2017)
Message-ID: <CADFM4g__QnC1heNhgRLkV9hS4+AbyTanYFTb2g5NGBq5=qTndg@mail.gmail.com>

Apologies for cross-listing.
=============================
*"The 5th International Conference on Digital Information Processing,
E-Business and Cloud Computing (DIPECC2017)"*
http://sdiwc.net/conferences/5th-international-digital-infor
mation-processing-e-business-cloud-computing/

All registered papers will be published in SDIWC Digital Library, and in
the proceedings of the conference.

==================
You are invited to participate in *The 5th International Conference on
Digital Information Processing, E-Business and Cloud Computing (DIPECC2017)*
that will be held in *Avrasya University, Trabzon, Turkey* on *October
19-21, 2017*. The event will be held over three days, with presentations
delivered by researchers from the international community, including
presentations from keynote speakers and state-of-the-art lectures.

DIPECC2017 welcomes paper on the following (but not limited to) Digital
Information Processing, E-Business, Cloud Computing and other related
topics.

*********
IMPORTANT DATES
*********
Submission Deadline: Open from now until August 15, 2017
Notification of Acceptance: September 28, 2017 or 4 weeks from the
submission date
camera Ready Submission: October 10, 2017
Registration Deadline; October 10, 2017
Conference Dates: October 19-21, 2017
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170223/f7730691/attachment.html>

From cmake at jessiehernandez.com  Fri Feb 24 04:52:07 2017
From: cmake at jessiehernandez.com (Jessie Hernandez)
Date: Fri, 24 Feb 2017 10:52:07 +0100
Subject: [CMake]  weird warning message after compiler upgrade
Message-ID: <f4c03e962e7580a24cc8ea5fd3ae084d.squirrel@mail.jessiehernandez.com>

Hi all,

I have been busy with upgrading my Intel ifort compiler from 14 to 16.
After I generated my Makefiles using CMake and compile my application I
get the following warning
    ifort: command line remark #10148: option 'i_dynamic' not supported

Looking through the CMake mailing list archive I came across the following
thread: https://www.mail-archive.com/cmake at cmake.org/msg54113.html

This seems to be the same problem I am having, but I could not find a
reply on this thread.

Can anybody on the list help me solving this problem?
or maybe point my in what direction I should be looking?

thank for any advice.

-----------------
Jessie Hernandez


From davidklind at gmail.com  Fri Feb 24 19:00:51 2017
From: davidklind at gmail.com (David Lind)
Date: Fri, 24 Feb 2017 17:00:51 -0700
Subject: [CMake] add_custom_target: COMMAND embedded bash code
Message-ID: <4D118D6E-1A60-4255-89AC-5FB99CA91C39@gmail.com>

I would like to create a custom target to run UnitTest++ based unit tests that has builtin default parameters.

For example:
    make unit_test verbose=1 xml-output=1 run=test_name suite=suite_name

The actual parameters passed to the unit_test are:
    unit_test --verbose --xml-output --run=test_name --suite=suite_name

I would prefer NOT to call a shell script but rather have the intelligence in the COMMAND itself.

Here?s what I?ve done:

    add_custom_target(${PROJECT_NAME}_run
        WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
        COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${target} "$(if $(verbose), --verbose)" "$(if $(run), --run=$(run))" "$(if $(suite), --suite=$(suite))" "$(if $(xml-output), --xml-output)" \${PARAMS}
        DEPENDS ${target}
    )

What ends up in build.make is this:
    ?/unit_test $(if\ $(verbose),\ --verbose) $(if\ $(xml-output),\ --xml-output) $(if\ $(run),\ --run=$(run)) $(if\ $(suite),\ --suite=$(suite))

This would work great if CMake didn?t put ?\? characters in build.cmake. I can only assume it?s escaping the spaces within the quotes.

If I don?t use quotes in the COMMAND value I get this:
    $ ( if $(verbose), --verbose )

Is there a way to format the COMMAND value so CMake doesn?t escape the spaces?

I?m using CMake version 3.7.2

?Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170224/1308c920/attachment.html>

From davidklind at gmail.com  Fri Feb 24 19:08:22 2017
From: davidklind at gmail.com (David Lind)
Date: Fri, 24 Feb 2017 17:08:22 -0700
Subject: [CMake] add_custom_target: COMMAND embedded make code
Message-ID: <2DC35FE0-7325-423E-9A34-66119E15A3DA@gmail.com>

I would like to create a custom target to run UnitTest++ based unit tests that has builtin default parameters.

For example:
    make unit_test verbose=1 xml-output=1 run=test_name suite=suite_name

The actual parameters passed to the unit_test are:
    unit_test --verbose --xml-output --run=test_name --suite=suite_name

I would prefer NOT to call a shell script but rather have the intelligence in the COMMAND itself.

Here?s what I?ve done:

    add_custom_target(${PROJECT_NAME}_run
        WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
        COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${target} "$(if $(verbose), --verbose)" "$(if $(run), --run=$(run))" "$(if $(suite), --suite=$(suite))" "$(if $(xml-output), --xml-output)" \${PARAMS}
        DEPENDS ${target}
    )

What ends up in build.make is this:
    ?/unit_test $(if\ $(verbose),\ --verbose) $(if\ $(xml-output),\ --xml-output) $(if\ $(run),\ --run=$(run)) $(if\ $(suite),\ --suite=$(suite))

This would work great if CMake didn?t put ?\? characters in build.cmake. I can only assume it?s escaping the spaces within the quotes.

If I don?t use quotes in the COMMAND value I get this:
    $ ( if $(verbose), --verbose )

Is there a way to format the COMMAND value so CMake doesn?t escape the spaces?

I?m using CMake version 3.7.2

?Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170224/84320807/attachment.html>

From tzsariysk at gmail.com  Fri Feb 24 19:17:39 2017
From: tzsariysk at gmail.com (T.Sariyski)
Date: Fri, 24 Feb 2017 17:17:39 -0700
Subject: [CMake] compiler flags passed to cmake appear doubled at build time
Message-ID: <018101d28efc$937fe160$ba7fa420$@gmail.com>

Hi,

 

For some reason, compiler flags passed to cmake, appear twice at build time.
I have a message line at the bottom of the cmakelist file, and it reports
the compilers flag as expected. 

 

cmake \

    -G "Eclipse CDT4 - Unix Makefiles" \

    -D MPI=ON \

    -D CMAKE_Fortran_FLAGS="-132 -cpp -g -O0 -DIFORT" \

    ..

 

-- CMAKE_Fortran_FLAGS            =  -DMPI -132 -cpp -g -O0 -DIFORT

 

At build time, these flags are doubled:

 

make

[  0%] Building Fortran object
src/modules/CMakeFiles/modules.dir/constants.F90.o

cd /users/tesari/my/build.intel/src/modules &&
/opt/mpi/RH6/intel_PS_XE_2013/openmpi-1.6/bin/mpif90   -DMPI -132 -cpp -g
-O0 -DIFORT -132 -cpp -g -O0 -DIFORT .

 

This is not a critical error, I am just curious what I am doing wrong.

 

Thanks in advance,

Ted

 

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

From davidklind at gmail.com  Fri Feb 24 19:34:53 2017
From: davidklind at gmail.com (DKLind)
Date: Fri, 24 Feb 2017 17:34:53 -0700 (MST)
Subject: [CMake] add_custom_target: COMMAND embedded make code
In-Reply-To: <2DC35FE0-7325-423E-9A34-66119E15A3DA@gmail.com>
References: <2DC35FE0-7325-423E-9A34-66119E15A3DA@gmail.com>
Message-ID: <1487982893586-7595094.post@n2.nabble.com>

Solved problem from another post with similar space escaping.

    set(PARAMS
        "$(if $(verbose), --verbose)"
        "$(if $(xml-output), --xml-output)"
        "$(if $(run), --run=$(run))"
        "$(if $(suite), --suite=$(suite))"
    )
    string(REPLACE " " ";" PARAMS ${PARAMS})
    add_custom_target(${PROJECT_NAME}_run
        WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
$(xml-output), --xml-output)" "$(if $(run), --run=$(run))" "$(if $(suite),
--suite=$(suite))"
        COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${target} ${PARAMS}
        DEPENDS ${target}
    )



--
View this message in context: http://cmake.3232098.n2.nabble.com/add-custom-target-COMMAND-embedded-make-code-tp7595092p7595094.html
Sent from the CMake mailing list archive at Nabble.com.

From cary at txcorp.com  Sat Feb 25 12:56:13 2017
From: cary at txcorp.com (JR Cary)
Date: Sat, 25 Feb 2017 10:56:13 -0700
Subject: [CMake] Convenience libraries with CUDA
Message-ID: <27d3436b-662d-142e-ad59-9e8ea4022ffe@txcorp.com>

This is partially a continuation of the issue described at
http://public.kitware.com/pipermail/cmake/2015-June/060937.html,
where the hope was to be able to use object libraries with cuda.

There was no solution at that time, so we dropped this path,
but now this has become more important.

I tried to follow the path of using CUDA_WRAP_SRCS to get a
list of the object files that would be produced by an nvcc
compilation.  I did get those files, but then when I configure
in a clean directory, cuda_add_library fails with

CMake Error at ...:537 (add_library):
  Cannot find source file:

    /somepath/foo.dir/foo_generated_bar.cu.o

I suppose I could hack with a touch, but perhaps there is a
better way?

Thx....John Cary



From tony.garratt at ansys.com  Sun Feb 26 15:52:32 2017
From: tony.garratt at ansys.com (Tony Garratt)
Date: Sun, 26 Feb 2017 20:52:32 +0000
Subject: [CMake] Intel C Generator for Cmake?
In-Reply-To: <c5c448ba704f456bb7311338d879a3fc@EXG13-P-MBX01.win.lanl.gov>
References: <CAMR23VPxMnhcrCgA08P2+GGE-D7wfHBr2ZK2OguQpdtdrmahZg@mail.gmail.com>
 <CAKohaZfrRCGypYtDKXWBGMZw3dpd4n--UT_uH-Kt5g5rhmnprw@mail.gmail.com>
 <CAMR23VMYnMrX0POKtHapa1fh_cyc-WDi26bTkzVSj2A1NrQ5Dw@mail.gmail.com>
 <c5c448ba704f456bb7311338d879a3fc@EXG13-P-MBX01.win.lanl.gov>
Message-ID: <CAMR23VN=igQfLv2Rb3s+q5v60k9UA1hGkXsj61f70qwwguE-Fg@mail.gmail.com>

Thank you so much for this suggest. It does work - partially anyway (I am
using XE2015). When I use cmake --build it complains about some incorrect
VS parameter. However, if I manually open the VS project created by cmake,
then it does have all the C code being compile using Intel C++ and then if
I build from within VS it builds fine.

Thanks
Tony

On Wed, Feb 15, 2017 at 2:42 PM, Thompson, KT <kgt at lanl.gov> wrote:

> Tony,
>
>
>
> I don?t have access to the Intel compiler on Windows to try this out.
> However, in an old post I found, it was suggested that you can use cmake?s
> ?-T? option to select the Intel compiler when the generator is ?Visual
> Studio?.
>
>
>
> For example:  -T"Intel C++ Compiler XE 13.0"
>
>
>
> Ref: https://software.intel.com/en-us/forums/intel-c-compiler/topic/456288
>
>
>
> -kt
>
>
>
>
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Tony Garratt
> *Sent:* Wednesday, February 15, 2017 6:21 AM
> *To:* Petr Kmoch <petr.kmoch at gmail.com>
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Intel C Generator for Cmake?
>
>
>
>
>
> Re: my previous email. To use the Intel C compilers I just can modify the
> VS settings. So I have a way forward.
>
>
>
> Regards,
>
> Tony
>
>
>
> On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
>
> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
>
> set FC=ifort
>
> cmake ...
>
> Petr
>
>
>
> On 15 February 2017 at 12:34, Tony Garratt <tony.garratt at ansys.com> wrote:
>
> I am having to switch to cmake from autotools for a third party tool I
> want to build. We use Intel C and Intel Fortran on Windows. I see no
> mention of an Intel C generator for cmake. I presume this means there is
> not one? If so, can I create my own Intel C generator please?
>
>
>
> Rgeards,
>
> Tony
>
>
>
> --
>
> *Dr Tony Garratt*
>
>
>
>
>
>
>
>
>
> --
>
> *Dr Tony Garratt*
>
> Tel: +44 7624 309933 <+44%2076%202430%209933>
>



-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170226/45cd36d6/attachment.html>

From laasunde at hotmail.com  Mon Feb 27 07:39:19 2017
From: laasunde at hotmail.com (Lars)
Date: Mon, 27 Feb 2017 12:39:19 +0000
Subject: [CMake] CMake install imported target using WIX
In-Reply-To: <eb0b121e-54b2-f0fc-3d56-46b8cd197d02@gmail.com>
References: <HE1PR0301MB2233E1FF0BF87B59F4B4B1E2CA510@HE1PR0301MB2233.eurprd03.prod.outlook.com>,
 <eb0b121e-54b2-f0fc-3d56-46b8cd197d02@gmail.com>
Message-ID: <HE1PR0301MB22334E7A03B2550875AFBFB5CA570@HE1PR0301MB2233.eurprd03.prod.outlook.com>

Hello,


Sorry for the delayed response. The issue has been resolved and was caused by incorrect component naming in cmake install(...) command.


Regards, Lars

________________________________
Fra: Nils Gladitz <nilsgladitz at gmail.com>
Sendt: 21. februar 2017 15:33
Til: Lars; cmake at cmake.org
Emne: Re: [CMake] CMake install imported target using WIX


On 02/21/2017 02:48 PM, Lars wrote:

Hello,


We are using the "config" mode of Find_Package that locates CompConfig.cmake which create IMPORTED targets.


CMakeLists.txt

Find_Package(some_comp ${some_comp_path})


CompConfig.cmake;

add_executable(app IMPORTED)

add_library(lib SHARED IMPORTED)


This works fine and once I read https://public.kitware.com/Bug/view.php?id=14311 I managed to get 'make install' to include the IMPORTED targets.

What exactly did you take from the issue report?
What are your install() commands?

Everything installed by "make install" should also land in the package assuming what ever install logic you used honors the install time CMAKE_INSTALL_PREFIX as set up by CPack.

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170227/5f71d859/attachment.html>

From brad.king at kitware.com  Mon Feb 27 11:43:18 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 27 Feb 2017 11:43:18 -0500
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
Message-ID: <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>

On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>>> I have a PR that asks the linker (via the compiler) what its implicit
>>> search directories are instead.
>>>
>>> It is the right way to do it IMHO, but I need to find time to finish
>>> it unfortunately.
>>
>> Do you have a link to the PR?
>
> The PR Is closed pending me writing a test-case, but I just now
> updated to the my latest version and rebased on top of master:

The MR was:

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

See discussion there for why it has not yet been accepted.  Basically
I'd like to see a clear explanation of the use case.  The case described
in the MR looks to me like the custom compiler should be configured to
always pass the needed rpath flags to the linker.

On 02/06/2017 06:16 PM, J?rg Krause wrote:
> I did a git bisect. The behaviour was introduced in commit
> 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].

Thanks for the bisect.  I don't think there is anything wrong with that
change on its own.  It merely exposed some existing behavior in a new case.

> My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
> FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.

These are set on by default in `Modules/Platform/UnixPaths.cmake` but
disabled on Debian by `Modules/Platform/Linux.cmake` except when
cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
such that a custom `Platform/MySystem.cmake` file is loaded then
the latter can set them as needed for the target platform.

-Brad

From joerg.krause at embedded.rocks  Mon Feb 27 15:50:08 2017
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Mon, 27 Feb 2017 21:50:08 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
Message-ID: <1488228608.14030.7.camel@embedded.rocks>

Hi Brad,

On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
> > > > I have a PR that asks the linker (via the compiler) what its
> > > > implicit
> > > > search directories are instead.
> > > > 
> > > > It is the right way to do it IMHO, but I need to find time to
> > > > finish
> > > > it unfortunately.
> > > 
> > > Do you have a link to the PR?
> > 
> > The PR Is closed pending me writing a test-case, but I just now
> > updated to the my latest version and rebased on top of master:
> 
> The MR was:
> 
> ?https://gitlab.kitware.com/cmake/cmake/merge_requests/207
> 
> See discussion there for why it has not yet been accepted.??Basically
> I'd like to see a clear explanation of the use case.??The case
> described
> in the MR looks to me like the custom compiler should be configured
> to
> always pass the needed rpath flags to the linker.
> 
> On 02/06/2017 06:16 PM, J?rg Krause wrote:
> > I did a git bisect. The behaviour was introduced in commit
> > 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
> 
> Thanks for the bisect.??I don't think there is anything wrong with
> that
> change on its own.??It merely exposed some existing behavior in a new
> case.

The problem is, that we end up with a host rpath when cross-compiling
which breaks compilations for a number of CMake packages we build on
Buildroot.

Buildroot uses /sysroot/usr/lib as target library path and
/sysroot/usr/lib32 is a symlink to that path. Nothing wrong here.

The addition of FIND_LIBRARY_USE_LIB32_PATHS changes the behavior of
`find_library()`. Before the commit `/sysroot/usr/lib` was
found as library path, but now it's `/sysroot/usr/lib32`.

When determining the runtime search path, CMake compares the paths
found by `find_library()` with a list of implicit runtime pathes. This
list contains `/sysroot/usr/lib` but not `/sysroot/usr/lib32`.

If the library path found by `find_library()` matches a search path
from the list of implicit runtime pathes it is dropped, otherwise it is
added to rpath after removing the `/sysroot` path.

So, as the implicit runtime search paths does *not* contain
`/sysroot/usr/lib32`, find_library() ends up with a rpath set to
`/usr/lib32`.



One example of how cross-compilation is broken is the example I already
quoted:

"""
$SYSROOT/usr/bin/i586-linux-gcc --sysroot=$SYSROOT/usr/i586-buildroot-
linux-musl/sysroot CheckSymbolExists.c.o -o cmTC_cb8f6 -Wl,-
rpath,/usr/lib32 -rdynamic $SYSROOT/usr/i586-buildroot-linux-
musl/sysroot/usr/lib32/libmbedtls.so
"""

If libmbedtls is linked with libz, the linker tries to link the target
libmbedtls with host libz, which fails:

"""
$SYSROOT/usr/i586-buildroot-linux-musl/bin/ld: warning:?
libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using -rpath?
or -rpath-link)?
/usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'?
/usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'?
/usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1?
"""

Note, that Buildroot does not use a /sysroot/usr/lib64 symbolic link.
Therefore, this behavior was not exposed before the commit.

For me, it looks like there is a problem how the rpath is created when
cross-compiling. Maybe the logic should check, if /sysroot/usr/lib32 is
a symlink to an implicit runtime search path?

However, I am not very familiar with CMake and the insights I described
where gathered by some hours of debugging the CMake code. Maybe I
missed something?

> > My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
> > FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on
> > Linux.
> 
> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
> disabled on Debian by `Modules/Platform/Linux.cmake` except when
> cross compiling.??If a toolchain file specifies CMAKE_SYSTEM_NAME
> such that a custom `Platform/MySystem.cmake` file is loaded then
> the latter can set them as needed for the target platform.

Thanks for the hint. We are discussing this setting as a workaround.

Best regards,
J?rg Krause

From mingw.android at gmail.com  Mon Feb 27 15:54:56 2017
From: mingw.android at gmail.com (Ray Donnelly)
Date: Mon, 27 Feb 2017 20:54:56 +0000
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <1488228608.14030.7.camel@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
Message-ID: <CAOYw7duMwgS1-8n-kPqU9zdycQu4AXEbQ5zXNtP4bWAtXvBojQ@mail.gmail.com>

On Mon, Feb 27, 2017 at 8:50 PM, J?rg Krause
<joerg.krause at embedded.rocks> wrote:
> Hi Brad,
>
> On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
>> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>> > > > I have a PR that asks the linker (via the compiler) what its
>> > > > implicit
>> > > > search directories are instead.
>> > > >
>> > > > It is the right way to do it IMHO, but I need to find time to
>> > > > finish
>> > > > it unfortunately.
>> > >
>> > > Do you have a link to the PR?
>> >
>> > The PR Is closed pending me writing a test-case, but I just now
>> > updated to the my latest version and rebased on top of master:
>>
>> The MR was:
>>
>>  https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>>
>> See discussion there for why it has not yet been accepted.  Basically
>> I'd like to see a clear explanation of the use case.  The case
>> described
>> in the MR looks to me like the custom compiler should be configured
>> to
>> always pass the needed rpath flags to the linker.
>>
>> On 02/06/2017 06:16 PM, J?rg Krause wrote:
>> > I did a git bisect. The behaviour was introduced in commit
>> > 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
>>
>> Thanks for the bisect.  I don't think there is anything wrong with
>> that
>> change on its own.  It merely exposed some existing behavior in a new
>> case.
>
> The problem is, that we end up with a host rpath when cross-compiling
> which breaks compilations for a number of CMake packages we build on
> Buildroot.

This is why my PR asks the linker that the compiler will use for the
actual list of implicit link dirs. I'm sorry I've not had time to
write up a clear explanation yet.

>
> Buildroot uses /sysroot/usr/lib as target library path and
> /sysroot/usr/lib32 is a symlink to that path. Nothing wrong here.
>
> The addition of FIND_LIBRARY_USE_LIB32_PATHS changes the behavior of
> `find_library()`. Before the commit `/sysroot/usr/lib` was
> found as library path, but now it's `/sysroot/usr/lib32`.
>
> When determining the runtime search path, CMake compares the paths
> found by `find_library()` with a list of implicit runtime pathes. This
> list contains `/sysroot/usr/lib` but not `/sysroot/usr/lib32`.
>
> If the library path found by `find_library()` matches a search path
> from the list of implicit runtime pathes it is dropped, otherwise it is
> added to rpath after removing the `/sysroot` path.
>
> So, as the implicit runtime search paths does *not* contain
> `/sysroot/usr/lib32`, find_library() ends up with a rpath set to
> `/usr/lib32`.
>
>
>
> One example of how cross-compilation is broken is the example I already
> quoted:
>
> """
> $SYSROOT/usr/bin/i586-linux-gcc --sysroot=$SYSROOT/usr/i586-buildroot-
> linux-musl/sysroot CheckSymbolExists.c.o -o cmTC_cb8f6 -Wl,-
> rpath,/usr/lib32 -rdynamic $SYSROOT/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedtls.so
> """
>
> If libmbedtls is linked with libz, the linker tries to link the target
> libmbedtls with host libz, which fails:
>
> """
> $SYSROOT/usr/i586-buildroot-linux-musl/bin/ld: warning:
> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using -rpath
> or -rpath-link)
> /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64 at GLIBC_2.1
> """
>
> Note, that Buildroot does not use a /sysroot/usr/lib64 symbolic link.
> Therefore, this behavior was not exposed before the commit.
>
> For me, it looks like there is a problem how the rpath is created when
> cross-compiling. Maybe the logic should check, if /sysroot/usr/lib32 is
> a symlink to an implicit runtime search path?
>
> However, I am not very familiar with CMake and the insights I described
> where gathered by some hours of debugging the CMake code. Maybe I
> missed something?
>
>> > My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
>> > FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on
>> > Linux.
>>
>> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
>> disabled on Debian by `Modules/Platform/Linux.cmake` except when
>> cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
>> such that a custom `Platform/MySystem.cmake` file is loaded then
>> the latter can set them as needed for the target platform.
>
> Thanks for the hint. We are discussing this setting as a workaround.
>
> Best regards,
> J?rg Krause

From brad.king at kitware.com  Mon Feb 27 16:33:35 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 27 Feb 2017 16:33:35 -0500
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <1488228608.14030.7.camel@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
Message-ID: <2b76e315-88ed-ef14-456d-8eb63331643a@kitware.com>

On 02/27/2017 03:50 PM, J?rg Krause wrote:
> The problem is...

Thanks.  I've opened an issue for this here:

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

>> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
>> disabled on Debian by `Modules/Platform/Linux.cmake` except when
>> cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
>> such that a custom `Platform/MySystem.cmake` file is loaded then
>> the latter can set them as needed for the target platform.
> 
> Thanks for the hint. We are discussing this setting as a workaround.

It sounds like this target platform does not want the lib32/lib64
suffixes to be searched so this would be an appropriate setting
for the projects to use regardless of what is done about this in
upstream CMake.  That will also fix it for using CMake 3.7.

-Brad

From brad.king at kitware.com  Mon Feb 27 16:39:01 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 27 Feb 2017 16:39:01 -0500
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <CAOYw7duMwgS1-8n-kPqU9zdycQu4AXEbQ5zXNtP4bWAtXvBojQ@mail.gmail.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <CAOYw7duMwgS1-8n-kPqU9zdycQu4AXEbQ5zXNtP4bWAtXvBojQ@mail.gmail.com>
Message-ID: <ffe2ceb8-eed0-475d-41a8-53097c9b1250@kitware.com>

On 02/27/2017 03:54 PM, Ray Donnelly wrote:
> This is why my PR asks the linker that the compiler will use for the
> actual list of implicit link dirs. I'm sorry I've not had time to
> write up a clear explanation yet.

IIUC your case is the opposite of that under discussion in the rest
of this thread.  You want to include a rpath that is not currently
included.  J?rg wants to exclude a rpath that is currently being
incorrectly included.  The detection you're proposing would not
discover the lib32 entry that is causing J?rg's problem.

As I requested in your MR [1] it will be more appropriate to discuss
your rpath-inclusion use case in a separate issue.

Thanks,
-Brad

[1] https://gitlab.kitware.com/cmake/cmake/merge_requests/207#note_189880


From michele.portolan at grenoble-inp.fr  Mon Feb 27 17:00:05 2017
From: michele.portolan at grenoble-inp.fr (Michele Portolan)
Date: Mon, 27 Feb 2017 23:00:05 +0100
Subject: [CMake] ExternalProject_add not buing launched
Message-ID: <c205e743-4e36-950c-d74f-4a3bdac01e9e@grenoble-inp.fr>

Hello,

I am trying to set my Cmake project to build the "xmlrpc-c" library, 
which is built using autotools. I was somewhat able to set it up 
following this example: 
http://mirkokiefer.com/blog/2013/03/cmake-by-example/

My resulting CMakeList is the following:

ExternalProject_Add( project_xmlprc
   SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/xmlrpc-c"
   PREFIX "${CMAKE_CURRENT_SOURCE_DIR}/xmlrpc-c"
   CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/xmlrpc-c/configure 
--prefix=${CMAKE_CURRENT_BINARY_DIR}/xmlrpc-c/
   BUILD_COMMAND make
   INSTALL_COMMAND make install
   BUILD_IN_SOURCE 1
)

ExternalProject_Get_Property(project_xmlprc install_dir)


add_library(xmlprc SHARED IMPORTED)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc++.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_packetsocket.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_client.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_client++.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_server++.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_server_abyss++.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_util.so)
set_property(TARGET xmlprc PROPERTY IMPORTED_LOCATION 
${install_dir}/lib/libxmlrpc_util++.so)
add_dependencies(xmlprc project_xmlprc)

It sort of works, meaning I can see the library being built in 
${CMAKE_CURRENT_BINARY_DIR}/xmlrpc-c/.

My problem is that the build is launched only the first time! If I 
delete the ${CMAKE_CURRENT_BINARY_DIR} and re-launch cmake, the 
ExternalProjet is not rebuilt. To have a rebuild, I have to do this 
strange workaround:

   - modify "BUILD_IN_SOURCE" to 0

  - run cmake+make. I get an error as xmlrpc only support in-source build

  - put "BUILD_IN_SOURCE"back to 1

  - run cmake+make. This time it works.


Looks like it is some issue in the source tree remaining dirty, but even 
running a "make distclean" does not change anything, I need to do the 
workaround.

Any idea of where the problem lies?

Thanks,


Michele




From mingw.android at gmail.com  Mon Feb 27 20:11:37 2017
From: mingw.android at gmail.com (Ray Donnelly)
Date: Tue, 28 Feb 2017 01:11:37 +0000
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <ffe2ceb8-eed0-475d-41a8-53097c9b1250@kitware.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <CAOYw7duMwgS1-8n-kPqU9zdycQu4AXEbQ5zXNtP4bWAtXvBojQ@mail.gmail.com>
 <ffe2ceb8-eed0-475d-41a8-53097c9b1250@kitware.com>
Message-ID: <CAOYw7duN8zdK1+P=zEp0nH3kZ7cF26miNQa1-cRAGuyZrB5k1A@mail.gmail.com>

On Mon, Feb 27, 2017 at 9:39 PM, Brad King <brad.king at kitware.com> wrote:
> On 02/27/2017 03:54 PM, Ray Donnelly wrote:
>> This is why my PR asks the linker that the compiler will use for the
>> actual list of implicit link dirs. I'm sorry I've not had time to
>> write up a clear explanation yet.
>
> IIUC your case is the opposite of that under discussion in the rest
> of this thread.  You want to include a rpath that is not currently
> included.  J?rg wants to exclude a rpath that is currently being
> incorrectly included.  The detection you're proposing would not
> discover the lib32 entry that is causing J?rg's problem.
>

Not really, my PR is about ensuring that CMake's idea of implicit dirs
isn't mismatched with the linker's actual implicit dirs by actually
asking the linker. AFAICT, it fixes J?rg's problem too. I say that
because as stated:

> CMake passes the host rpath to the linker

CMake does this because it isn't *asking* the linker, it's making
assumptions instead (and adding some predefined values like
`/usr/lib32`). If we just ask the linker instead then everything
should work just fine (I am ignore linkers that cannot tell us here
like Apple's ld64. I'm not sure how to tackle that one yet).

> As I requested in your MR [1] it will be more appropriate to discuss
> your rpath-inclusion use case in a separate issue.
>
> Thanks,
> -Brad
>
> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/207#note_189880
>

From joerg.krause at embedded.rocks  Tue Feb 28 05:25:40 2017
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Tue, 28 Feb 2017 11:25:40 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <2b76e315-88ed-ef14-456d-8eb63331643a@kitware.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <2b76e315-88ed-ef14-456d-8eb63331643a@kitware.com>
Message-ID: <1488277540.8626.1.camel@embedded.rocks>

On Mon, 2017-02-27 at 16:33 -0500, Brad King wrote:
> On 02/27/2017 03:50 PM, J?rg Krause wrote:
> > The problem is...
> 
> Thanks.??I've opened an issue for this here:
> 
> ?https://gitlab.kitware.com/cmake/cmake/issues/16682

Great!

> > > These are set on by default in `Modules/Platform/UnixPaths.cmake`
> > > but
> > > disabled on Debian by `Modules/Platform/Linux.cmake` except when
> > > cross compiling.??If a toolchain file specifies CMAKE_SYSTEM_NAME
> > > such that a custom `Platform/MySystem.cmake` file is loaded then
> > > the latter can set them as needed for the target platform.
> > 
> > Thanks for the hint. We are discussing this setting as a
> > workaround.
> 
> It sounds like this target platform does not want the lib32/lib64
> suffixes to be searched so this would be an appropriate setting
> for the projects to use regardless of what is done about this in
> upstream CMake.??That will also fix it for using CMake 3.7.

Buildroot does not have any problems with searching for libraries in
lib32. It does have a problem with having a host rpath used for linking
with libraries.

So, turning of the search for lib32 is really just a workaround to get
rid of the host rpath.

>From my understanding, there are some possibilities to fix this issue:
1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is enabled,
and only search in lib32 in case the target is not found in lib.
2) Make sure, in case lib32 is a symlink, to follow the symlink.
3) Make sure, in case lib32 is a symlink to lib and is not included in
the linker search paths, to add it to the implicit runtime search
paths.

Any thoughts?

J?rg

From brad.king at kitware.com  Tue Feb 28 08:22:47 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 28 Feb 2017 08:22:47 -0500
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <1488277540.8626.1.camel@embedded.rocks>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <2b76e315-88ed-ef14-456d-8eb63331643a@kitware.com>
 <1488277540.8626.1.camel@embedded.rocks>
Message-ID: <c8bb525c-0179-7524-980e-d50092795405@kitware.com>

On 02/28/2017 05:25 AM, J?rg Krause wrote:
> Buildroot does not have any problems with searching for libraries in
> lib32. It does have a problem with having a host rpath used for linking
> with libraries.

>From your description we are not adding a host rpath.  It's coming from
/sysroot/usr/lib32 which is converted to /usr/lib32 by stripping the
sysroot.  If you were to run the binary purely in the target environment
then it would find the library in the target's /usr/lib32.  It is not
clear to my how the binary is being run on the host, but doing so uses
the host's /usr/lib32 because the binary was built for the target.

> From my understanding, there are some possibilities to fix this issue:
> 1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is enabled,
> and only search in lib32 in case the target is not found in lib.

The purpose of that features is so on a 64-bit system with 64-bit libs
in `lib` and 32-bit libs in `lib32` that we find the latter when the
target architecture is 32 bit.

> 2) Make sure, in case lib32 is a symlink, to follow the symlink.

I was thinking the same thing.  The lib => lib32 search path conversion
should just be skipped if lib32 is a symlink back to lib.

> 3) Make sure, in case lib32 is a symlink to lib and is not included in
> the linker search paths, to add it to the implicit runtime search
> paths.

Yes, the issue I filed is about handling symlinks when comparing rpath
entries to the list of implicit directories.

I encourage you to sign up on gitlab.kitware.com to join discussion in
that issue.

Thanks,
-Brad

From brad.king at kitware.com  Tue Feb 28 08:23:50 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 28 Feb 2017 08:23:50 -0500
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <CAOYw7duN8zdK1+P=zEp0nH3kZ7cF26miNQa1-cRAGuyZrB5k1A@mail.gmail.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <CAOYw7duMwgS1-8n-kPqU9zdycQu4AXEbQ5zXNtP4bWAtXvBojQ@mail.gmail.com>
 <ffe2ceb8-eed0-475d-41a8-53097c9b1250@kitware.com>
 <CAOYw7duN8zdK1+P=zEp0nH3kZ7cF26miNQa1-cRAGuyZrB5k1A@mail.gmail.com>
Message-ID: <e4bc0fda-8c61-2ed7-35e8-221455c45f18@kitware.com>

On 02/27/2017 08:11 PM, Ray Donnelly wrote:
>> CMake passes the host rpath to the linker
> 
> CMake does this because it isn't *asking* the linker, it's making
> assumptions instead (and adding some predefined values like
> `/usr/lib32`). If we just ask the linker instead then everything
> should work just fine (I am ignore linkers that cannot tell us here
> like Apple's ld64. I'm not sure how to tackle that one yet).

The /usr/lib32 path is not coming from any assumption or from guessing
about the linker's rpath.  It is appearing because we add to the rpath
directories in which shared libraries appear that we include in our link.
When find_library discovers /usr/lib32/libfoo.so, and we link to that
library, then we add /usr/lib32 to the rpath if it is not in the implicit
list.  If we were to ask the linker what its rpath is it would say
"/usr/lib" and then we would say "/usr/lib32 != /usr/lib" and add it
anyway.  J?rg's problem is about this lack of symlink recognition, and
that is the issue I filed.

-Brad

From mark.stijnman at gmail.com  Tue Feb 28 12:39:30 2017
From: mark.stijnman at gmail.com (Mark Stijnman)
Date: Tue, 28 Feb 2017 18:39:30 +0100
Subject: [CMake] Custom transitive list-valued properties
Message-ID: <CAOzitBL+VNfTqG+DsChTbp-eWXhebxfO3v+gu7_XrzPpreSQuw@mail.gmail.com>

Hi,



Is there a way to declare a target property to be transitive and accumulate
into a list? Similar to how COMPILE_DEFINITIONS works, but for custom
properties? I know about COMPATIBLE_INTERFACE_STRING etc, which create a
transitive property, but the values don't accumulate into a list.


As a minimal example, I would like the below code to generate
properties.txt with contents like ?C;B;A? (I don?t really care about the
order), instead of just "C", which it currently generates. Can I do this
somehow? Thanks,


regards Mark


cmake_minimum_required(VERSION 3.7)

project(proptest)



# insert something like ?add_transitive_property(MYPROP)? here?



add_library(lib1 INTERFACE)

set_property(TARGET lib1 PROPERTY INTERFACE_MYPROP "A")



add_library(lib2 STATIC lib2.cpp)

set_property(TARGET lib2 PROPERTY INTERFACE_MYPROP "B")

target_link_libraries(lib2 lib1)



add_executable(proptest main.cpp)

target_link_libraries(proptest lib2)

set_property(TARGET proptest PROPERTY MYPROP "C")



file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/properties.txt

  CONTENT "$<TARGET_PROPERTY:proptest,MYPROP>")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170228/07618a58/attachment.html>

From jan.hegewald at awi.de  Tue Feb 28 12:57:00 2017
From: jan.hegewald at awi.de (=?utf-8?B?8J+QiyBKYW4gSGVnZXdhbGQ=?=)
Date: Tue, 28 Feb 2017 18:57:00 +0100
Subject: [CMake] cmake generated Xcode projects are excluded from Time
	Machine
Message-ID: <F8FC9AFC-F1A9-4FCC-B3EC-4F183E7B61DA@awi.de>

Dear cmakers,

I just found a rather disturbing fact on my Mac which leads to entire Xcode projects and everything stored next to them to be excluded from the Time Machine backup:

?  ~ cmake --version
cmake version 3.7.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
?  ~ mkdir yadda  
?  ~ xattr yadda  
?  ~ cd yadda
?  yadda cmake ../foo -G Xcode
...
?  yadda xattr .       

Now open the generated .xcodeproj in Xcode and cmd-B (Build).

?  yadda xattr .
com.apple.XcodeGenerated
com.apple.metadata:com_apple_backup_excludeItem

Because of the com_apple_backup_excludeItem, the entire yadda directory will be excluded from Time Machine backups.
I often tweak the Xcode project as I work with it, change compiler settings, add targets etc. I definitely want this to be in my backup.
What do you think?


Regards,
Jan Hegewald, Climate Sciences, awi.de




From joerg.krause at embedded.rocks  Tue Feb 28 14:41:22 2017
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Tue, 28 Feb 2017 20:41:22 +0100
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <c8bb525c-0179-7524-980e-d50092795405@kitware.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <2b76e315-88ed-ef14-456d-8eb63331643a@kitware.com>
 <1488277540.8626.1.camel@embedded.rocks>
 <c8bb525c-0179-7524-980e-d50092795405@kitware.com>
Message-ID: <1488310882.5877.0.camel@embedded.rocks>

On Tue, 2017-02-28 at 08:22 -0500, Brad King wrote:
> On 02/28/2017 05:25 AM, J?rg Krause wrote:
> > Buildroot does not have any problems with searching for libraries
> > in
> > lib32. It does have a problem with having a host rpath used for
> > linking
> > with libraries.
> 
> From your description we are not adding a host rpath.??It's coming
> from
> /sysroot/usr/lib32 which is converted to /usr/lib32 by stripping the
> sysroot.??If you were to run the binary purely in the target
> environment
> then it would find the library in the target's /usr/lib32.??It is not
> clear to my how the binary is being run on the host, but doing so
> uses
> the host's /usr/lib32 because the binary was built for the target.
> 
> > From my understanding, there are some possibilities to fix this
> > issue:
> > 1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is
> > enabled,
> > and only search in lib32 in case the target is not found in lib.
> 
> The purpose of that features is so on a 64-bit system with 64-bit
> libs
> in `lib` and 32-bit libs in `lib32` that we find the latter when the
> target architecture is 32 bit.
> 
> > 2) Make sure, in case lib32 is a symlink, to follow the symlink.
> 
> I was thinking the same thing.??The lib => lib32 search path
> conversion
> should just be skipped if lib32 is a symlink back to lib.
> 
> > 3) Make sure, in case lib32 is a symlink to lib and is not included
> > in
> > the linker search paths, to add it to the implicit runtime search
> > paths.
> 
> Yes, the issue I filed is about handling symlinks when comparing
> rpath
> entries to the list of implicit directories.
> 
> I encourage you to sign up on gitlab.kitware.com to join discussion
> in
> that issue.

I move the discussion to the gitlab issue: https://gitlab.kitware.com/c
make/cmake/issues/16682

J?rg

From brad.king at kitware.com  Tue Feb 28 15:08:18 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 28 Feb 2017 15:08:18 -0500
Subject: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
In-Reply-To: <c8bb525c-0179-7524-980e-d50092795405@kitware.com>
References: <1486332234.12820.4.camel@embedded.rocks>
 <1486416174.4950.5.camel@embedded.rocks>
 <1486422966.4950.7.camel@embedded.rocks>
 <CAOYw7dt3LqO=pVo9gcx_B9ZVnLZZrx6vCqVVS4F44o+ouWk7ew@mail.gmail.com>
 <505d554ea8e02c05ed472cce7c4e1e4f@embedded.rocks>
 <CAOYw7duLh_0eXggODqfr=pFoYhZrqLKN9k+UmUcAwX6T-iTL3A@mail.gmail.com>
 <afdf67fb-d427-f057-3acf-3299668dc3f9@kitware.com>
 <1488228608.14030.7.camel@embedded.rocks>
 <2b76e315-88ed-ef14-456d-8eb63331643a@kitware.com>
 <1488277540.8626.1.camel@embedded.rocks>
 <c8bb525c-0179-7524-980e-d50092795405@kitware.com>
Message-ID: <c4e5006a-6e23-014c-9ab3-715578b0acf6@kitware.com>

On 02/28/2017 08:22 AM, Brad King wrote:
>> 2) Make sure, in case lib32 is a symlink, to follow the symlink.
> 
> I was thinking the same thing.  The lib => lib32 search path conversion
> should just be skipped if lib32 is a symlink back to lib.

For reference, I opened an issue for this part of the work [1].

-Brad


[1] https://gitlab.kitware.com/cmake/cmake/issues/16687