From Gilles.Khouzam at microsoft.com  Mon Feb  1 09:47:57 2016
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Mon, 1 Feb 2016 14:47:57 +0000
Subject: [CMake] Is there any way to use clang-cl with MSBuild
	on	Windows?
In-Reply-To: <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>,
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
Message-ID: <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>

Hi Yi-Long


Clang-Cl requires a few changes in order to work properly,


I've prototyped the support for Clang-Cl on our CMake fork with the plan to integrate the support once we've got good confirmation and work through some of the design issues.


You can find the code on https://github.com/microsoft/cmake/tree/feature/clang_3_7


You can also find an installer here: https://github.com/Microsoft/CMake/releases


The easiest way to set Clang as the compiler is to use the -T parameter such as

cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 ...


But I've also added a new variable VS_PLATFORM_TOOLSET_OVERRIDE that you can use to change the toolset for a specific target (there are scenarios where you need CL and Clang targeting different projects in your solution).


Thanks


~Gilles

________________________________
From: CMake <cmake-bounces at cmake.org> on behalf of Yi-Hong Lyu <b95705030 at ntu.edu.tw>
Sent: Sunday, January 31, 2016 10:47:58 AM
To: Nicholas Braden
Cc: cmake at cmake.org
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Bill,

If I generate the ALL_BUILD.vcxproj for MSVC 19.0.23506.0 as usual, I can use command "msbuild ALL_BUILD.vcxproj /p:cltoolexe=clang-cl" to build the project using clang-cl. However it might include wrong directory like C:\\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt during building when I build library libcxx. Is there any way to overwrite variables such as ExcludePath, IncludePath, UniversalCRT_IncludePath and VC_IncludePath?

Hello Nicholas,

Which value should I put for -T parameter?

BTW, is CMAKE_TOOLCHAIN_FILE able to used in this situation?

Thanks

2016-01-30 8:33 GMT+08:00 Nicholas Braden <nicholas11braden at gmail.com<mailto:nicholas11braden at gmail.com>>:
Have you tried setting the toolset? The -T parameter can set the
toolset. This sets the platform toolset property that you would
normally set in Visual Studio. if Visual Studio lets you select the
llvm platform toolset, so will CMake.

On Fri, Jan 29, 2016 at 12:04 PM, Yi-Hong Lyu <b95705030 at ntu.edu.tw<mailto:b95705030 at ntu.edu.tw>> wrote:
> Hello everyone,
>
> I am a newbie of CMake. I would like to use clang-cl with MSBuild on
> Windows. However it always use MSVC 19.0.23506.0 as the identified compiler
> even I defined CMAKE_C_COMPILER / CMAKE_CXX_COMPILER /
> CMAKE_C_COMPILER_FORCED / CMAKE_CXX_COMPILER_FORCED:
>
> $ cmake -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl
> -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER_FORCED=ON ..\src\
> -- Building for: Visual Studio 14 2015
> -- The CXX compiler identification is MSVC 19.0.23506.0
> -- The C compiler identification is MSVC 19.0.23506.0
> -- Configuring for standalone build.
> -- Found PythonInterp: C:/Python34/python.exe (found version "3.4.4")
> -- Sphinx disabled.
> .
> .
> .
>
> PS. The environment PATH is already set to clang-cl.
>
> I am wondering whether there is any option that I can force MSBuild use
> clang-cl instead.
>
> Thanks,
> Yi-Hong
>
> --
>
> Powered by www.kitware.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.kitware.com&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XRBUVuD5E6oZzVuMZKnLIkpZvNpoUcAQxsxk%2b%2f3d2%2fg%3d>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.cmake.org%2fWiki%2fCMake_FAQ&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B5qRHx0tZ06282JI80v3vXtLe5dOEFMirfMf2cjuMPc%3d>
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2fsupport.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nDxHnhnazcXg%2bWMTDqB21ZDzd%2bzHRP6GYMzXbUh23%2bw%3d>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2fconsulting.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zBgz7xNVTHlQt5Z8qD4%2bZbjHdHgUinxJucxqCNkVlb8%3d>
> CMake Training Courses: http://cmake.org/cmake/help/training.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2ftraining.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UuaSFCyTEAVLjHDdMEQJE4S9rQo8eCPKePrByhfFiyc%3d>
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.kitware.com%2fopensource%2fopensource.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HL6JxxlNw6g74hoGamgZ%2bIMv4zW2d%2b5nj1So4W8jZqU%3d>
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fpublic.kitware.com%2fmailman%2flistinfo%2fcmake&data=01%7c01%7cgilles.khouzam%40microsoft.com%7ce012a32391a44c18fbd108d32a6f1dea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DsvpZHs%2bX%2fiEKMUAFifMucqlb67eDv1sac4LCBIm%2fPI%3d>

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

From gjasny at googlemail.com  Mon Feb  1 15:03:05 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Mon, 1 Feb 2016 21:03:05 +0100
Subject: [CMake] Using ccache with Xcode generator
In-Reply-To: <CACQP5Ucjbt6V2BATxvu1wkcABCit1hXB+=vtK=Xgy6CtddA2LQ@mail.gmail.com>
References: <CACQP5Ucjbt6V2BATxvu1wkcABCit1hXB+=vtK=Xgy6CtddA2LQ@mail.gmail.com>
Message-ID: <56AFB9F9.2020506@googlemail.com>

Hello,

On 01/02/16 04:52, Craig Scott wrote:
> After a bit of experimenting, it seems that getting ccache working with the
> Xcode generator isn't so straightforward. For Ninja and Unix Makefiles, the
> RULE_LAUNCH_COMPILE global property nicely gives us the behaviour we want,
> but this doesn't work for Xcode. Under the constraint that we can't modify
> the build machines (meaning we can't assume ccache symlinks have been set
> up for the clang compiler set), is there a way to coax CMake to use ccache
> with Xcode? I know I could write a wrapper script to explicitly invoke
> ccache, but this seems like something CMake should be able to do without
> having to resort to that. Any suggestions?

I guess you will have to modify the SDK within Xcode to be able to
override the compiler for the SDK.

As far as I remember Bullseye has the same problem to solve:
http://www.bullseye.com/help/tool-xcode.html
Maybe you can have a look there.

Thanks,
Gregor

From s.v.savenko at gmail.com  Tue Feb  2 07:01:17 2016
From: s.v.savenko at gmail.com (Slava)
Date: Tue, 2 Feb 2016 13:01:17 +0100
Subject: [CMake] linking boost libraries built inside the project on mac os
Message-ID: <CAKM_90wriE9LUrXid4y17dqE9pwPc1xrzBTVZTC=Gi3z=kYmFA@mail.gmail.com>

I failed to reproduce it with a toy project, so please bear with me...
I compile and install boost at config time (by generating the helper cmake
file with external project and running cmake on it).
It is found by standard findBoost afterwards and linked against
Boost_UNIT_TEST_FRAMEWORK_LIBRARY.
All is fine till here. Now project is built, but trying to run the
resulting binary on mac throws me:

dyld: Library not loaded: libboost_unit_test_framework.dylib
  Referenced from: /blablabla/util/./test
  Reason: image not found
Trace/BPT trap: 5

On linux everything works well.
The similar project with a toy library compiled and linked instead of boost
works fine on mac too.

cmake 3.2,3.4. linux, macos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160202/f6981798/attachment.html>

From ggarra13 at gmail.com  Tue Feb  2 09:48:00 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Tue, 2 Feb 2016 11:48:00 -0300
Subject: [CMake] linking boost libraries built inside the project on mac
 os
In-Reply-To: <CAKM_90wriE9LUrXid4y17dqE9pwPc1xrzBTVZTC=Gi3z=kYmFA@mail.gmail.com>
References: <CAKM_90wriE9LUrXid4y17dqE9pwPc1xrzBTVZTC=Gi3z=kYmFA@mail.gmail.com>
Message-ID: <56B0C1A0.9050405@gmail.com>



El 02/02/16 a las 09:01, Slava escribi?:
> I failed to reproduce it with a toy project, so please bear with me...
> I compile and install boost at config time (by generating the helper 
> cmake file with external project and running cmake on it).
> It is found by standard findBoost afterwards and linked against 
> Boost_UNIT_TEST_FRAMEWORK_LIBRARY.
> All is fine till here. Now project is built, but trying to run the 
> resulting binary on mac throws me:
>
> dyld: Library not loaded: libboost_unit_test_framework.dylib
>   Referenced from: /blablabla/util/./test
>   Reason: image not found
> Trace/BPT trap: 5?
That just means that the dynamic library libboost_unit_test_framework is 
not installed in any system directory.
You can install it some system dir or use DYLD_FALLBACK_LIBRARY_PATH to 
specify the directory where it resides.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From s.v.savenko at gmail.com  Tue Feb  2 10:54:40 2016
From: s.v.savenko at gmail.com (Slava)
Date: Tue, 2 Feb 2016 16:54:40 +0100
Subject: [CMake] linking boost libraries built inside the project on mac
	os
In-Reply-To: <56B0C1A0.9050405@gmail.com>
References: <CAKM_90wriE9LUrXid4y17dqE9pwPc1xrzBTVZTC=Gi3z=kYmFA@mail.gmail.com>
 <56B0C1A0.9050405@gmail.com>
Message-ID: <CAKM_90yXqjs6VErjqbu8+xXYpYaAK7QrZYXEFsnOp4DHsPN20g@mail.gmail.com>

I found the relevant discussion on stackoverflow
http://stackoverflow.com/questions/33665781/dependencies-on-boost-library-dont-have-full-path
. You can mark my question is [solved]. Thank you.

On Tue, Feb 2, 2016 at 3:48 PM, Gonzalo <ggarra13 at gmail.com> wrote:

>
>
> El 02/02/16 a las 09:01, Slava escribi?:
>
>> I failed to reproduce it with a toy project, so please bear with me...
>> I compile and install boost at config time (by generating the helper
>> cmake file with external project and running cmake on it).
>> It is found by standard findBoost afterwards and linked against
>> Boost_UNIT_TEST_FRAMEWORK_LIBRARY.
>> All is fine till here. Now project is built, but trying to run the
>> resulting binary on mac throws me:
>>
>> dyld: Library not loaded: libboost_unit_test_framework.dylib
>>   Referenced from: /blablabla/util/./test
>>   Reason: image not found
>> Trace/BPT trap: 5?
>>
> That just means that the dynamic library libboost_unit_test_framework is
> not installed in any system directory.
> You can install it some system dir or use DYLD_FALLBACK_LIBRARY_PATH to
> specify the directory where it resides.
>
> --
> Gonzalo Garramu?o
> ggarra13 at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160202/2a55451e/attachment.html>

From ahelten at tenable.com  Tue Feb  2 12:53:47 2016
From: ahelten at tenable.com (Andrew Helten)
Date: Tue, 2 Feb 2016 11:53:47 -0600
Subject: [CMake] CPack RPM generator not using CPACK_RPM_<component>_XXX
	variables
Message-ID: <CAMTTBtZGb4caUbck2DtZSEWhzsXaqibBPyUyXoPF=dyQZwLgAA@mail.gmail.com>

I have the CPack RPM component packager partly working in that it creates
separate RPMs for my two components (soon to be more, but two for now).
However, the RPMs are not quite right because the packager completely
ignores all of my CPACK_RPM_<component>_XXX variables, such
as, CPACK_RPM_<component>_PACKAGE_PREFIX. The debug output from CPack
doesn't provide an answer. Here is a small example snippet of my
CMakeLists.txt for component "blah1" and "blah2":


set(CPACK_GENERATOR "RPM")
set(CPACK_RPM_BLAH1_USER_BINARY_SPECFILE
"${CMAKE_CURRENT_SOURCE_DIR}/install/SPECS/blah1.spec.in")
set(CPACK_RPM_BLAH1_PACKAGE_PREFIX "${CMAKE_INSTALL_PREFIX}/blah1")
set(CPACK_RPM_BLAH2_PACKAGE_PREFIX "${CMAKE_INSTALL_PREFIX}/blah2")
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_COMPONENTS_ALL blah1 blah2)
include(CPack)

What I want this to do is install blah1 in something like /opt/blah1 and
install blah2 in /opt/blah2 and use a custom binary spec for component
blah1. It does none of these things and instead puts both blah1 and blah2
in CPACK_PACKAGING_INSTALL_PREFIX and uses a GENERATED binary spec file for
both blah1 and blah2.

Thanks for any help,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160202/04eb20e2/attachment.html>

From domen.vrankar at gmail.com  Tue Feb  2 15:51:31 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 2 Feb 2016 21:51:31 +0100
Subject: [CMake] CPack RPM generator not using CPACK_RPM_<component>_XXX
	variables
In-Reply-To: <CAMTTBtZGb4caUbck2DtZSEWhzsXaqibBPyUyXoPF=dyQZwLgAA@mail.gmail.com>
References: <CAMTTBtZGb4caUbck2DtZSEWhzsXaqibBPyUyXoPF=dyQZwLgAA@mail.gmail.com>
Message-ID: <CAKgx6B+n30dfS8JV=6F3hMOfxZHyo0_FfP0iQOJfC5AcLgcE9w@mail.gmail.com>

> set(CPACK_GENERATOR "RPM")
> set(CPACK_RPM_BLAH1_USER_BINARY_SPECFILE
> "${CMAKE_CURRENT_SOURCE_DIR}/install/SPECS/blah1.spec.in")
> set(CPACK_RPM_BLAH1_PACKAGE_PREFIX "${CMAKE_INSTALL_PREFIX}/blah1")
> set(CPACK_RPM_BLAH2_PACKAGE_PREFIX "${CMAKE_INSTALL_PREFIX}/blah2")
> set(CPACK_RPM_COMPONENT_INSTALL ON)
> set(CPACK_COMPONENTS_ALL blah1 blah2)
> include(CPack)
>
> What I want this to do is install blah1 in something like /opt/blah1 and
> install blah2 in /opt/blah2 and use a custom binary spec for component
> blah1. It does none of these things and instead puts both blah1 and blah2 in
> CPACK_PACKAGING_INSTALL_PREFIX and uses a GENERATED binary spec file for
> both blah1 and blah2.

This can be done but not all of those features came in at the same
time so you should check the documentation for the version of
CMake/CPack you are using.

Also for historical reasons there is a difference between CPack
variables and CPackRPM specific variables: with CPACK_* variables the
component part should be in upper case as in your example while with
CPACK_RPM_* variables the component part should be the same as the
name of the component (for e.g. in your case
CPACK_RPM_blah1_PACKAGE_PREFIX).

Also instead of using CPACK_RPM_*_PACKAGE_PREFIX variables you might
also want to take a look at CPACK_RPM_RELOCATION_PATHS that can be
used in combination with GNUInstallDirs.cmake script that comes with
CMake.

e.g.
include(GNUInstallDirs)
set(CPACK_RPM_RELOCATION_PATHS "${CMAKE_INSTALL_INCLUDEDIR}"
  "${CMAKE_INSTALL_LIBDIR}" "${CMAKE_INSTALL_BINDIR}")

This way each rpm package can have more than one install prefix location.

Regards,
Domen

From robert.maynard at kitware.com  Tue Feb  2 16:56:27 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 2 Feb 2016 16:56:27 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing!
Message-ID: <CAFzjYVr12C-1n+zpBxj2hzApWdGZdTFDSwghAr=02futiUSPPA@mail.gmail.com>

I am proud to announce the first CMake 3.5 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

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

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

Some of the more significant features of CMake 3.5 are:

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC
  now provide imported targets.

* The "FindOpenMP" module learned to support Clang.

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

Deprecated and Removed Features:

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.



CMake 3.5 Release Notes
***********************

Changes made since CMake 3.4 include the following.


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


GUI
---

* The "cmake-gui(1)" gained options to control warnings about
  deprecated functionality.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* The "cmake-gui(1)" gained a Regular Expression Explorer which may
  be used to create and evaluate regular expressions in real-time. The
  explorer window is available via the "Tools" menu.


Command-Line
------------

* The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and
  suppress the deprecated warnings output by default.

* The suppression of developer warnings as errors can now be
  controlled with the new "-Werror=dev" and "-Wno-error=dev"
  "cmake(1)" options.

* The "cmake(1)" "-E" command-line tools "copy",
  "copy_if_different", "copy_directory", and "make_directory" learned
  to support multiple input files or directories.


Commands
--------

* The "cmake_parse_arguments()" command is now implemented natively.
  The "CMakeParseArguments" module remains as an empty placeholder for
  compatibility.

* The "install(DIRECTORY)" command learned to support "generator
  expressions" in the list of directories.


Variables
---------

* The "CMAKE_ERROR_DEPRECATED" variable can now be set using the
  "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options.

* The "CMAKE_WARN_DEPRECATED" variable can now be set using the
  "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options.


Properties
----------

* The "VS_GLOBAL_<variable>" target property is now implemented for
  VS 2010 and above.  Previously it worked only in VS 2008 and below.


Modules
-------

* The "ExternalProject" module learned a new "GIT_REMOTE_NAME"
  option to control the "git clone --origin" value.

* The "FindBoost" module now provides imported targets such as
  "Boost::boost" and "Boost::filesystem".

* The "FindFLEX" module "FLEX_TARGET" macro learned a new
  "DEFINES_FILE" option to specify a custom output header to be
  generated.

* The "FindGTest" module now provides imported targets.

* The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is
  enabled, now sets "GTK2_LIBRARIES" to contain the list of imported
  targets instead of the paths to the libraries.  Moreover it now sets
  a new "GTK2_TARGETS" variable containing all the targets imported.

* The "FindOpenMP" module learned to support Clang.

* The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT"
  option to search for libraries using the MSVC static runtime.

* The "FindPNG" module now provides imported targets.

* The "FindTIFF" module now provides imported targets.

* A "FindXalanC" module was introduced to find the Apache Xalan-C++
  XSL transform processing library.

* The "FindXercesC" module now provides imported targets.


Platforms
---------

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.


CPack
-----

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

* The "CPackDeb" module learned to set the optional config file
  "Source" field using a monolithic or per-component variable. See
  "CPACK_DEBIAN_PACKAGE_SOURCE".

* The "CPackDeb" module learned to set Package, Section and Priority
  control fields per-component. See variables
  "CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION" and
  "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY".

* The "CPack DragNDrop generator" learned to add multi-lingual SLAs
  to a DMG which is presented to the user when they try to mount the
  DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR"
  variables for details.

* The "CPackNSIS" module learned new variables to add bitmaps to the
  installer.  See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and
  "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables.

* The "CPackRPM" module learned to set Name and Group control fields
  per-component. See "CPACK_RPM_<component>_PACKAGE_NAME" and
  "CPACK_RPM_<component>_PACKAGE_GROUP".


Other
-----

* Warnings about deprecated functionality are now enabled by
  default. They may be suppressed with "-Wno-deprecated" or by setting
  the "CMAKE_WARN_DEPRECATED" variable to false.


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

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.


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

* The "Visual Studio 14 2015" generator learned to map the
  "/debug:fastlink" linker flag to the ".vcxproj" file property.

* The "FindGTK2" module now configures the "GTK2::sigc++" imported
  target to enable c++11 on its dependents when using sigc++ 2.5.1 or
  higher.

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

From roman.wueger at gmx.at  Wed Feb  3 00:42:57 2016
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Wed, 3 Feb 2016 06:42:57 +0100
Subject: [CMake] CPack and PackageMaker
In-Reply-To: <9A894BB6-8BC9-4092-8052-B83C022EB97D@gmx.at>
References: <000f4242.47dd4f8b0abb6704@dirac.se>
 <9A894BB6-8BC9-4092-8052-B83C022EB97D@gmx.at>
Message-ID: <03F3149A-D9C4-47A8-85D0-FFE0B8BB2443@gmx.at>

@Brad, @Clinton: Could we add this feature into CMake 3.5.0, because on newer Mac OS systems the package maker is already deprecated and for those we could use the productbuild instead.

Thanks in advance

Best Regards
Roman 

> Am 22.12.2015 um 07:56 schrieb Roman W?ger <roman.wueger at gmx.at>:
> 
> Is there anything I can do to support?
> 
> Best regards 
> 
>> Am 11.12.2015 um 20:17 schrieb robert.bielik <robert.bielik at dirac.se>:
>> 
>> Dear Clint,
>>  
>> Thank you! Will certainly start with that as a base :)
>>  
>> Regards 
>> /R
>>  
>> ------ Ursprungligt meddelande------
>> Fr?n:
>> Datum: fre, 11 dec 2015 20:12
>> Till: Robert Bielik;
>> Kopia: Attila Krasznahorkay;cmake;
>> ?mne:Re: [CMake] CPack and PackageMaker
>>  
>> If you are interested, attached is some code I started a couple years ago but never finished, nor did I do much testing.
>> Perhaps that'll help, or maybe you'll find a better way.
>> 
>> Clint
>> 
>> ----- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bielik at dirac.se wrote:
>> 
>> > Dear Attila,
>> > 
>> > Ok, been struggling getting an installation package to work with the
>> > pkgbuild/productbild tools, so I think I got the gist of what needs to
>> > be done, at least to get something going :)
>> > 
>> > Regards
>> > /R
>> > 
>> > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay:
>> >> Hi Robert,
>> >>
>> >> I'm afraid that the sad situation is that nobody has done this yet, or is
>> >> working on it at the moment.
>> >>
>> >> I'm absolutely sure that if you can help with this by any amount, that will be
>> >> most welcome by the CMake developers. It will certainly be most welcome by me,
>> >> as I've been disappointed by the lack of this support as well. (But
>> >> unfortunately can't spare the time to help out in writing this CPack
>> >> generator.)
>> >>
>> >> Cheers,
>> >>               Attila
>> >>
>> >>> On 11 Dec 2015, at 17:44, Robert Bielik  wrote:
>> >>>
>> >>> Really ? No one ? :)
>> >>>
>> >>> So it's ok to go ahead and start create a new one ? ;)
>> >>>
>> >>> Rgds,
>> >>> /R
>> >>>
>> >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik:
>> >>>> Mac OSX:
>> >>>>
>> >>>> Since PackageMaker has been deprecated by Apple, the new tools to use are
>> >>>> pkgbuild [1] and productbuild [2].
>> >>>>
>> >>>> Simple question: Is there any work being done by the CMake community on a new OS
>> >>>> X CPack backend to support the above tools ?
>> >>>>
>> >>>> Regards
>> >>>> /Robert
>> >>>> [1]
>> >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
>> >>>> [2]
>> >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html
>> >>>>
>> >>> --
>> >>>
>> >>> Powered by www.kitware.com
>> >>>
>> >>> Please keep messages on-topic and check the CMake FAQ at:
>> >>> http://www.cmake.org/Wiki/CMake_FAQ
>> >>>
>> >>> Kitware offers various services to support the CMake community. For more
>> >>> information on each offering, please visit:
>> >>>
>> >>> CMake Support: http://cmake.org/cmake/help/support.html
>> >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >>>
>> >>> Visit other Kitware open-source projects at
>> >>> http://www.kitware.com/opensource/opensource.html
>> >>>
>> >>> Follow this link to subscribe/unsubscribe:
>> >>> http://public.kitware.com/mailman/listinfo/cmake
>> > 
>> > --
>> > 
>> > Powered by www.kitware.com
>> > 
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> > 
>> > Kitware offers various services to support the CMake community. For more
>> > information on each offering, please visit:
>> > 
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/cmake/help/training.html
>> > 
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> > 
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/cmake
>> -- 
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160203/728b54f0/attachment-0001.html>

From sstallion at gmail.com  Wed Feb  3 10:54:49 2016
From: sstallion at gmail.com (Steven Stallion)
Date: Wed, 3 Feb 2016 09:54:49 -0600
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
 <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
Message-ID: <CAGGHmKF4Dsu_EVTknXP6QO19b28wyZdBJO_wqbnu9F5M3QpXTA@mail.gmail.com>

A selfish request: would it be possible to slip this into the 3.5
release? This is something that I (and the company I work for) are
very interested in, and I would like to avoid pulling a fork into our
workstream.

Cheers,

Steve

On Mon, Feb 1, 2016 at 8:47 AM, Gilles Khouzam
<Gilles.Khouzam at microsoft.com> wrote:
> Hi Yi-Long
>
>
> Clang-Cl requires a few changes in order to work properly,
>
>
> I've prototyped the support for Clang-Cl on our CMake fork with the plan to
> integrate the support once we've got good confirmation and work through some
> of the design issues.
>
>
> You can find the code on
> https://github.com/microsoft/cmake/tree/feature/clang_3_7
>
>
> You can also find an installer here:
> https://github.com/Microsoft/CMake/releases
>
>
> The easiest way to set Clang as the compiler is to use the -T parameter such
> as
>
> cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 ...
>
>
> But I've also added a new variable VS_PLATFORM_TOOLSET_OVERRIDE that you can
> use to change the toolset for a specific target (there are scenarios where
> you need CL and Clang targeting different projects in your solution).
>
>
> Thanks
>
>
> ~Gilles
>
> ________________________________
> From: CMake <cmake-bounces at cmake.org> on behalf of Yi-Hong Lyu
> <b95705030 at ntu.edu.tw>
> Sent: Sunday, January 31, 2016 10:47:58 AM
> To: Nicholas Braden
> Cc: cmake at cmake.org
> Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on
> Windows?
>
> Hello Bill,
>
> If I generate the ALL_BUILD.vcxproj for MSVC 19.0.23506.0 as usual, I can
> use command "msbuild ALL_BUILD.vcxproj /p:cltoolexe=clang-cl" to build the
> project using clang-cl. However it might include wrong directory like
> C:\\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt during
> building when I build library libcxx. Is there any way to overwrite
> variables such as ExcludePath, IncludePath, UniversalCRT_IncludePath and
> VC_IncludePath?
>
> Hello Nicholas,
>
> Which value should I put for -T parameter?
>
> BTW, is CMAKE_TOOLCHAIN_FILE able to used in this situation?
>
> Thanks
>
> 2016-01-30 8:33 GMT+08:00 Nicholas Braden <nicholas11braden at gmail.com>:
>>
>> Have you tried setting the toolset? The -T parameter can set the
>> toolset. This sets the platform toolset property that you would
>> normally set in Visual Studio. if Visual Studio lets you select the
>> llvm platform toolset, so will CMake.
>>
>> On Fri, Jan 29, 2016 at 12:04 PM, Yi-Hong Lyu <b95705030 at ntu.edu.tw>
>> wrote:
>> > Hello everyone,
>> >
>> > I am a newbie of CMake. I would like to use clang-cl with MSBuild on
>> > Windows. However it always use MSVC 19.0.23506.0 as the identified
>> > compiler
>> > even I defined CMAKE_C_COMPILER / CMAKE_CXX_COMPILER /
>> > CMAKE_C_COMPILER_FORCED / CMAKE_CXX_COMPILER_FORCED:
>> >
>> > $ cmake -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl
>> > -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER_FORCED=ON ..\src\
>> > -- Building for: Visual Studio 14 2015
>> > -- The CXX compiler identification is MSVC 19.0.23506.0
>> > -- The C compiler identification is MSVC 19.0.23506.0
>> > -- Configuring for standalone build.
>> > -- Found PythonInterp: C:/Python34/python.exe (found version "3.4.4")
>> > -- Sphinx disabled.
>> > .
>> > .
>> > .
>> >
>> > PS. The environment PATH is already set to clang-cl.
>> >
>> > I am wondering whether there is any option that I can force MSBuild use
>> > clang-cl instead.
>> >
>> > Thanks,
>> > Yi-Hong
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake community. For more
>> > information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/cmake
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From kgt at lanl.gov  Wed Feb  3 11:19:53 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Wed, 3 Feb 2016 16:19:53 +0000
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
Message-ID: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>

I downloaded cmake 3.5.0-rc1 to try it out.

The Windows installation doesn?t appear to provide all the required dependencies. ?cmake-gui? will not launch and provides the error ?Qt5Widgets.dll is missing form your computer.? Do I need to install a specific Qt runtime before installing cmake 3.5? The command line ?cmake? will run through the configuration of my projects, but it does not generate any VS solution files.

On RHEL 6.7, I extracted the prebuilt x86_64 binaries from the downloaded .tar.gz file.  At the end of the configuration process, cmake issues a segmentation fault and no Makefiles are generated.  Additionally, cmake-gui uses a bad font (all text is displayed as boxes).

Is anyone else encountering these issues with 3.5.0-rc1?

-kt

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

From robert.maynard at kitware.com  Wed Feb  3 12:11:56 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 3 Feb 2016 12:11:56 -0500
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
In-Reply-To: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <CAFzjYVoFAhs_zfcYgqSibq7psj6bS8Mn+66DF0vNony1t=ro=w@mail.gmail.com>

Hi,

I have been able to replicate the problem with the Windows installer
not properly installing the Qt libraries. I have tested the Linux
x86_64 binaries on a Ubuntu 12.04 machine and everything works, but I
will locate a RHEL machine and see if I can replicate your issue.

On Wed, Feb 3, 2016 at 11:19 AM, Thompson, KT <kgt at lanl.gov> wrote:
> I downloaded cmake 3.5.0-rc1 to try it out.
>
>
>
> The Windows installation doesn?t appear to provide all the required
> dependencies. ?cmake-gui? will not launch and provides the error
> ?Qt5Widgets.dll is missing form your computer.? Do I need to install a
> specific Qt runtime before installing cmake 3.5? The command line ?cmake?
> will run through the configuration of my projects, but it does not generate
> any VS solution files.
>
>
>
> On RHEL 6.7, I extracted the prebuilt x86_64 binaries from the downloaded
> .tar.gz file.  At the end of the configuration process, cmake issues a
> segmentation fault and no Makefiles are generated.  Additionally, cmake-gui
> uses a bad font (all text is displayed as boxes).
>
>
>
> Is anyone else encountering these issues with 3.5.0-rc1?
>
>
>
> -kt
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 robert.maynard at kitware.com  Wed Feb  3 12:35:59 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 3 Feb 2016 12:35:59 -0500
Subject: [CMake] CPack and PackageMaker
In-Reply-To: <03F3149A-D9C4-47A8-85D0-FFE0B8BB2443@gmx.at>
References: <000f4242.47dd4f8b0abb6704@dirac.se>
 <9A894BB6-8BC9-4092-8052-B83C022EB97D@gmx.at>
 <03F3149A-D9C4-47A8-85D0-FFE0B8BB2443@gmx.at>
Message-ID: <CAFzjYVp+moeeJ4=+AJHWZcyAjgvVS+hoLbQ9gKH2JOJn1_ELXw@mail.gmail.com>

The window for new CMake 3.5 features is closed now that we have
started the release cycle.

On Wed, Feb 3, 2016 at 12:42 AM, Roman W?ger <roman.wueger at gmx.at> wrote:
> @Brad, @Clinton: Could we add this feature into CMake 3.5.0, because on
> newer Mac OS systems the package maker is already deprecated and for those
> we could use the productbuild instead.
>
> Thanks in advance
>
> Best Regards
> Roman
>
> Am 22.12.2015 um 07:56 schrieb Roman W?ger <roman.wueger at gmx.at>:
>
> Is there anything I can do to support?
>
> Best regards
>
> Am 11.12.2015 um 20:17 schrieb robert.bielik <robert.bielik at dirac.se>:
>
> Dear Clint,
>
>
>
> Thank you! Will certainly start with that as a base :)
>
>
>
> Regards
>
> /R
>
>
>
> ------ Ursprungligt meddelande------
>
> Fr?n:
>
> Datum: fre, 11 dec 2015 20:12
>
> Till: Robert Bielik;
>
> Kopia: Attila Krasznahorkay;cmake;
>
> ?mne:Re: [CMake] CPack and PackageMaker
>
>
>
> If you are interested, attached is some code I started a couple years ago
> but never finished, nor did I do much testing.
> Perhaps that'll help, or maybe you'll find a better way.
>
> Clint
>
> ----- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bielik at dirac.se
> wrote:
>
>> Dear Attila,
>>
>> Ok, been struggling getting an installation package to work with the
>> pkgbuild/productbild tools, so I think I got the gist of what needs to
>> be done, at least to get something going :)
>>
>> Regards
>> /R
>>
>> Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay:
>>> Hi Robert,
>>>
>>> I'm afraid that the sad situation is that nobody has done this yet, or is
>>> working on it at the moment.
>>>
>>> I'm absolutely sure that if you can help with this by any amount, that
>>> will be
>>> most welcome by the CMake developers. It will certainly be most welcome
>>> by me,
>>> as I've been disappointed by the lack of this support as well. (But
>>> unfortunately can't spare the time to help out in writing this CPack
>>> generator.)
>>>
>>> Cheers,
>>>               Attila
>>>
>>>> On 11 Dec 2015, at 17:44, Robert Bielik  wrote:
>>>>
>>>> Really ? No one ? :)
>>>>
>>>> So it's ok to go ahead and start create a new one ? ;)
>>>>
>>>> Rgds,
>>>> /R
>>>>
>>>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik:
>>>>> Mac OSX:
>>>>>
>>>>> Since PackageMaker has been deprecated by Apple, the new tools to use
>>>>> are
>>>>> pkgbuild [1] and productbuild [2].
>>>>>
>>>>> Simple question: Is there any work being done by the CMake community on
>>>>> a new OS
>>>>> X CPack backend to support the above tools ?
>>>>>
>>>>> Regards
>>>>> /Robert
>>>>> [1]
>>>>>
>>>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
>>>>> [2]
>>>>>
>>>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html
>>>>>
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more
>>>> information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/cmake
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From arankin at robarts.ca  Wed Feb  3 12:45:08 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Wed, 3 Feb 2016 17:45:08 +0000
Subject: [CMake] xyz_LIBRARIES
Message-ID: <ec7e58739d8947a7b299a51c574ccf36@dag2.robarts.ca>

Hello all,

I am trying to sort out a project with multiple layers of dependencies and I am trying to figure out the "right" way of configuring things.

First easy question: Should a value xyz_LIBRARIES contain target names, or library file locations?

Second question: Should a FindXYZ.cmake file add imported targets, or should a USE_xyz variable be created for later inclusion? (what if the project does not export its targets?)

Third question: How's your day going today?

Cheers,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160203/6d28f296/attachment.html>

From brad.king at kitware.com  Wed Feb  3 13:36:29 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 3 Feb 2016 13:36:29 -0500
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
In-Reply-To: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <56B248AD.5060900@kitware.com>

On 02/03/2016 11:19 AM, Thompson, KT wrote:
> The Windows installation doesn?t appear to provide all the
> required dependencies. ?cmake-gui? will not launch and provides
> the error ?Qt5Widgets.dll is missing form your computer.?

Ugh, after months of working correctly on the nightly binary builds
something happened to go wrong on the packaging machine specifically
for this release build due to an environment change.  I've fixed it
and replaced the binary on the download site for the Windows build.
Please download and try again.

-Brad

From brad.king at kitware.com  Wed Feb  3 13:41:57 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 3 Feb 2016 13:41:57 -0500
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
In-Reply-To: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <56B249F5.6010702@kitware.com>

On 02/03/2016 11:19 AM, Thompson, KT wrote:
> On RHEL 6.7, I extracted the prebuilt x86_64 binaries from the
> downloaded .tar.gz file.  At the end of the configuration process,
> cmake issues a segmentation fault and no Makefiles are generated.

What project are you configuring?

Can you provide a CMakeLists.txt file that reproduces this crash?

Thanks,
-Brad


From kgt at lanl.gov  Wed Feb  3 13:59:58 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Wed, 3 Feb 2016 18:59:58 +0000
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
In-Reply-To: <56B249F5.6010702@kitware.com>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
 <56B249F5.6010702@kitware.com>
Message-ID: <2392ba91bd7f4189ac16d8d657a3d60a@EXG13-P-MBX09.win.lanl.gov>

I'm working on a reproducer.  For now, all I can say is that it looks like the segmentation fault occurs on this command:

install( EXPORT foo-targets
  DESTINATION foo
  EXPORT_LINK_INTERFACE_LIBRARIES )

-kt

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, February 03, 2016 11:42 AM
To: Thompson, KT <kgt at lanl.gov>
Cc: cmake at cmake.org
Subject: Re: [CMake] CMake 3.5.0-rc1 install is missing dependencies

On 02/03/2016 11:19 AM, Thompson, KT wrote:
> On RHEL 6.7, I extracted the prebuilt x86_64 binaries from the
> downloaded .tar.gz file.  At the end of the configuration process,
> cmake issues a segmentation fault and no Makefiles are generated.

What project are you configuring?

Can you provide a CMakeLists.txt file that reproduces this crash?

Thanks,
-Brad


From andrew.bell.ia at gmail.com  Wed Feb  3 14:08:42 2016
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Wed, 3 Feb 2016 13:08:42 -0600
Subject: [CMake] Finding Packages Installed in Non-Standard Locations
Message-ID: <CACJ51z1nXsAf0gMd-QvRRyyf=wNggA6jaSDio209KmcyW3fZog@mail.gmail.com>

If my package is installed to a non-standard location, my
<PROJECT>Config.cmake file is currently also installed to the non-standard
location and can't be found by dependent projects.

I see that there's export(PACKAGE <PROJECT>), but this creates an entry in
the registry for the build location of the PROJECT rather than the
installed location.

Is there some way I can install target files to a non-standard location but
be sure that <PROJECT>Config.cmake can be found without explicitly
installing it into something like /usr/lib/cmake/PROJECT?

Thanks,

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160203/7cfa2f4d/attachment.html>

From b95705030 at ntu.edu.tw  Wed Feb  3 14:10:44 2016
From: b95705030 at ntu.edu.tw (Yi-Hong Lyu)
Date: Thu, 4 Feb 2016 03:10:44 +0800
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
 <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
Message-ID: <CAH1oQ8ouBkgcaGO_O8=8zJkAsgrJ0DLi39OAQm1_F7FqsR9s6g@mail.gmail.com>

Hello Gilles,

Thanks for you mail. It is really useful to me but I encounter an error. My
use case is to use clang-cl with my own target instead of x86/x64 target.
Therefore I don't want to include any headers of VS x86/x64 and use any
library of VS x86/x64:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7
-DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl ..\src\

CMake Error at CMakeLists.txt:17 (project):
  Could not find an appropriate version of the Windows 10 SDK installed
on this machine

-- Configuring incomplete, errors occurred!
See also "E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeOutput.log".

I don't want to use Windows 10 SDK during compilation. Is the feature you
implemented suitable for my special use case?

Thanks for your help,
Yi-Hong

2016-02-01 22:47 GMT+08:00 Gilles Khouzam <Gilles.Khouzam at microsoft.com>:

> Hi Yi-Long
>
>
> Clang-Cl requires a few changes in order to work properly,
>
>
> I've prototyped the support for Clang-Cl on our CMake fork with the plan
> to integrate the support once we've got good confirmation and work through
> some of the design issues.
>
>
> You can find the code on
> https://github.com/microsoft/cmake/tree/feature/clang_3_7
>
>
> You can also find an installer here:
> https://github.com/Microsoft/CMake/releases
>
>
> The easiest way to set Clang as the compiler is to use the -T parameter
> such as
>
> cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 ...
>
>
> But I've also added a new variable VS_PLATFORM_TOOLSET_OVERRIDE that you
> can use to change the toolset for a specific target (there are scenarios
> where you need CL and Clang targeting different projects in your solution).
>
>
> Thanks
>
>
> ~Gilles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/8d2f9d7d/attachment.html>

From ahelten at tenable.com  Wed Feb  3 14:22:32 2016
From: ahelten at tenable.com (Andrew Helten)
Date: Wed, 3 Feb 2016 13:22:32 -0600
Subject: [CMake] CPack RPM generator not using CPACK_RPM_<component>_XXX
	variables
In-Reply-To: <CAKgx6B+n30dfS8JV=6F3hMOfxZHyo0_FfP0iQOJfC5AcLgcE9w@mail.gmail.com>
References: <CAMTTBtZGb4caUbck2DtZSEWhzsXaqibBPyUyXoPF=dyQZwLgAA@mail.gmail.com>
 <CAKgx6B+n30dfS8JV=6F3hMOfxZHyo0_FfP0iQOJfC5AcLgcE9w@mail.gmail.com>
Message-ID: <CAMTTBtZ+8a+3ic-9PEgBvZHyEefA=dnkCO8Jdr2LN34Lw3Mkog@mail.gmail.com>

Thanks Domen! The use of original-case for <component> in
CPACK_RPM_<component>_XXXX was indeed the problem. I never did get the
CPACK_RPM_*_PACKAGE_PREFIX variable to work but I'm using a different
(probably more correct) approach that gets me what I wanted.

Can this use of mixed case-sensitive/all-upper-case can be clarified in the
documentation for CPACK_ and CPAC_RPM_ component variables?

Thanks,
Andy

On Tue, Feb 2, 2016 at 2:51 PM, Domen Vrankar <domen.vrankar at gmail.com>
wrote:

> > set(CPACK_GENERATOR "RPM")
> > set(CPACK_RPM_BLAH1_USER_BINARY_SPECFILE
> > "${CMAKE_CURRENT_SOURCE_DIR}/install/SPECS/blah1.spec.in")
> > set(CPACK_RPM_BLAH1_PACKAGE_PREFIX "${CMAKE_INSTALL_PREFIX}/blah1")
> > set(CPACK_RPM_BLAH2_PACKAGE_PREFIX "${CMAKE_INSTALL_PREFIX}/blah2")
> > set(CPACK_RPM_COMPONENT_INSTALL ON)
> > set(CPACK_COMPONENTS_ALL blah1 blah2)
> > include(CPack)
> >
> > What I want this to do is install blah1 in something like /opt/blah1 and
> > install blah2 in /opt/blah2 and use a custom binary spec for component
> > blah1. It does none of these things and instead puts both blah1 and
> blah2 in
> > CPACK_PACKAGING_INSTALL_PREFIX and uses a GENERATED binary spec file for
> > both blah1 and blah2.
>
> This can be done but not all of those features came in at the same
> time so you should check the documentation for the version of
> CMake/CPack you are using.
>
> Also for historical reasons there is a difference between CPack
> variables and CPackRPM specific variables: with CPACK_* variables the
> component part should be in upper case as in your example while with
> CPACK_RPM_* variables the component part should be the same as the
> name of the component (for e.g. in your case
> CPACK_RPM_blah1_PACKAGE_PREFIX).
>
> Also instead of using CPACK_RPM_*_PACKAGE_PREFIX variables you might
> also want to take a look at CPACK_RPM_RELOCATION_PATHS that can be
> used in combination with GNUInstallDirs.cmake script that comes with
> CMake.
>
> e.g.
> include(GNUInstallDirs)
> set(CPACK_RPM_RELOCATION_PATHS "${CMAKE_INSTALL_INCLUDEDIR}"
>   "${CMAKE_INSTALL_LIBDIR}" "${CMAKE_INSTALL_BINDIR}")
>
> This way each rpm package can have more than one install prefix location.
>
> Regards,
> Domen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160203/f1863983/attachment.html>

From b95705030 at ntu.edu.tw  Wed Feb  3 14:46:20 2016
From: b95705030 at ntu.edu.tw (Yi-Hong Lyu)
Date: Thu, 4 Feb 2016 03:46:20 +0800
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CY1PR0301MB07135C24DF007670D631C48C98D00@CY1PR0301MB0713.namprd03.prod.outlook.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
 <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CAH1oQ8ouBkgcaGO_O8=8zJkAsgrJ0DLi39OAQm1_F7FqsR9s6g@mail.gmail.com>
 <CY1PR0301MB07135C24DF007670D631C48C98D00@CY1PR0301MB0713.namprd03.prod.outlook.com>
Message-ID: <CAH1oQ8oQHo0KS74NuowvPXtNz0GvMFsGYyRLJNLKQgSvpfvgjQ@mail.gmail.com>

Hello Gilles,

Here it is:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7
-DLLVM_PATH="E:\\llvm" -DCMAKE_SYSTEM_VERSION=8.1
 -DCMAKE_C_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe"
-DCMAKE_CXX_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" ..\src\
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- broken
CMake Error at E:/CMake/clang_3_7/Modules/CMakeTestCXXCompiler.cmake:54
(message):
  The C++ compiler "E:\e2tools\ext-tools\llvm\clang-cl.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeTmp

  Run Build Command:"C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe"
  "cmTC_00a23.vcxproj" "/p:Configuration=Debug"
"/p:VisualStudioVersion=14.0"

  Microsoft (R) Build Engine version 14.0.24720.0

  C:\Program Files

(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5):
  error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset =
  'v140_clang_3_7') cannot be found.  To build using the v140_clang_3_7
build
  tools, please install v140_clang_3_7 build tools.  Alternatively, you may
  upgrade to the current Visual Studio tools by selecting the Project menu
or
  right-click the solution, and then selecting "Retarget solution".

[E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

    C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5):
error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset =
'v140_clang_3_7') cannot be found. To build using the v140_clang_3_7 build
tools, please install v140_clang_3_7 build tools.  Alternatively, you may
upgrade to the current Visual Studio tools by selecting the Project menu or
right-click the solution, and then selecting "Retarget solution".
[E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

      0 warning
      1 error

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

-- Configuring incomplete, errors occurred!

PS. Part of the messages in Chinese are removed, please tell me if you need
it as well

Thanks for your help,
Yi-Hong

2016-02-04 3:25 GMT+08:00 Gilles Khouzam <Gilles.Khouzam at microsoft.com>:

> Hi Yi-Hong,
>
>
>
> Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your
> parameters?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/2e36c142/attachment.html>

From Gilles.Khouzam at microsoft.com  Wed Feb  3 14:25:39 2016
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Wed, 3 Feb 2016 19:25:39 +0000
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CAH1oQ8ouBkgcaGO_O8=8zJkAsgrJ0DLi39OAQm1_F7FqsR9s6g@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
 <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CAH1oQ8ouBkgcaGO_O8=8zJkAsgrJ0DLi39OAQm1_F7FqsR9s6g@mail.gmail.com>
Message-ID: <CY1PR0301MB07135C24DF007670D631C48C98D00@CY1PR0301MB0713.namprd03.prod.outlook.com>

Hi Yi-Hong,

Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your parameters?

From: Yi-Hong Lyu [mailto:b95705030 at ntu.edu.tw]
Sent: Wednesday, February 3, 2016 11:11
To: Gilles Khouzam <Gilles.Khouzam at microsoft.com>
Cc: Nicholas Braden <nicholas11braden at gmail.com>; cmake at cmake.org
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Gilles,

Thanks for you mail. It is really useful to me but I encounter an error. My use case is to use clang-cl with my own target instead of x86/x64 target. Therefore I don't want to include any headers of VS x86/x64 and use any library of VS x86/x64:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl ..\src\

CMake Error at CMakeLists.txt:17 (project):
  Could not find an appropriate version of the Windows 10 SDK installed on this machine

-- Configuring incomplete, errors occurred!
See also "E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeOutput.log".

I don't want to use Windows 10 SDK during compilation. Is the feature you implemented suitable for my special use case?

Thanks for your help,
Yi-Hong

2016-02-01 22:47 GMT+08:00 Gilles Khouzam <Gilles.Khouzam at microsoft.com<mailto:Gilles.Khouzam at microsoft.com>>:

Hi Yi-Long



Clang-Cl requires a few changes in order to work properly,



I've prototyped the support for Clang-Cl on our CMake fork with the plan to integrate the support once we've got good confirmation and work through some of the design issues.



You can find the code on https://github.com/microsoft/cmake/tree/feature/clang_3_7



You can also find an installer here: https://github.com/Microsoft/CMake/releases



The easiest way to set Clang as the compiler is to use the -T parameter such as

cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 ...



But I've also added a new variable VS_PLATFORM_TOOLSET_OVERRIDE that you can use to change the toolset for a specific target (there are scenarios where you need CL and Clang targeting different projects in your solution).



Thanks


~Gilles

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

From a.neundorf-work at gmx.net  Wed Feb  3 16:09:08 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Wed, 03 Feb 2016 22:09:08 +0100
Subject: [CMake] Finding Packages Installed in Non-Standard Locations
In-Reply-To: <CACJ51z1nXsAf0gMd-QvRRyyf=wNggA6jaSDio209KmcyW3fZog@mail.gmail.com>
References: <CACJ51z1nXsAf0gMd-QvRRyyf=wNggA6jaSDio209KmcyW3fZog@mail.gmail.com>
Message-ID: <1636697.SWgUrIaTyF@tuxedo.neundorf.net>

On Wednesday, February 03, 2016 13:08:42 Andrew Bell wrote:
> If my package is installed to a non-standard location, my
> <PROJECT>Config.cmake file is currently also installed to the non-standard
> location and can't be found by dependent projects.
> 
> I see that there's export(PACKAGE <PROJECT>), but this creates an entry in
> the registry for the build location of the PROJECT rather than the
> installed location.
> 
> Is there some way I can install target files to a non-standard location but
> be sure that <PROJECT>Config.cmake can be found without explicitly
> installing it into something like /usr/lib/cmake/PROJECT?

you can set the CMAKE_PREFIX_PATH environment variable.

Alex


From audiofanatic at gmail.com  Wed Feb  3 16:26:26 2016
From: audiofanatic at gmail.com (Craig Scott)
Date: Thu, 4 Feb 2016 08:26:26 +1100
Subject: [CMake] xyz_LIBRARIES
In-Reply-To: <ec7e58739d8947a7b299a51c574ccf36@dag2.robarts.ca>
References: <ec7e58739d8947a7b299a51c574ccf36@dag2.robarts.ca>
Message-ID: <CACQP5UfwqjDFwrHRv57_tsVxNPy5vMVetMc2bz4r21MTyX1=uw@mail.gmail.com>

On 4 February 2016 at 04:45, Adam Rankin <arankin at robarts.ca> wrote:

> Hello all,
>
>
>
> I am trying to sort out a project with multiple layers of dependencies and
> I am trying to figure out the ?right? way of configuring things.
>
>
>
> First easy question: Should a value xyz_LIBRARIES contain target names, or
> library file locations?
>

Preferably target names, assuming you mean imported targets (see answer to
next question).



>  Second question: Should a FindXYZ.cmake file add imported targets, or
> should a USE_xyz variable be created for later inclusion? (what if the
> project does not export its targets?)
>

Imported targets will be better for end users/developers. An imported
target can provide not just the library file location, it can also provide
other dependencies such as dependent libraries that also must be linked,
header search paths, etc. Furthermore, with an imported target you can
explicitly control what other targets are affected by these dependencies
simply by linking against your imported target. If you chose the USE_xyz
variable + include approach, then the include file will typically end up
calling  link_libraries(), link_directories() and/or include_directories()
commands and making those things apply to all targets defined thereafter,
which used to be the norm but is no longer necessary with all the
target_xxx() commands added in more recent versions of CMake (well, 2.8.11
or later).



>  Third question: How?s your day going today?
>

Ask me again after the coffee kicks in. :P


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

From konstantin at podsvirov.pro  Wed Feb  3 16:28:10 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Thu, 04 Feb 2016 00:28:10 +0300
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
In-Reply-To: <56B248AD.5060900@kitware.com>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
 <56B248AD.5060900@kitware.com>
Message-ID: <2143941454534890@web21j.yandex.ru>

Meet the fresh update online installers (CMake3.5.3.5.20160203):

http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe

and

http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe

If you have used them previously, then just update via "CMake Maintenance Tool".

These installers were collected and razvernut using AppVeyor:

https://ci.appveyor.com/project/podsvirov/cmake/build/3.5-26

03.02.2016, 21:36, "Brad King" <brad.king at kitware.com>:
> On 02/03/2016 11:19 AM, Thompson, KT wrote:
>> The Windows installation doesn't appear to provide all the
>> required dependencies. ?cmake-gui? will not launch and provides
>> the error ?Qt5Widgets.dll is missing form your computer.?
>
> Ugh, after months of working correctly on the nightly binary builds
> something happened to go wrong on the packaging machine specifically
> for this release build due to an environment change. I've fixed it
> and replaced the binary on the download site for the Windows build.
> Please download and try again.
>
> -Brad

I tried the installer:

https://cmake.org/files/v3.5/cmake-3.5.0-rc1-win32-x86.msi

He asked me to install CMake on your way:

C:\Program Files (x86)\Canon\Easy-WebPrint EX\

:-) (something and somewhere went wrong...)

I changed to:

C:\Program Files (x86)\CMake\

And installed as usual.

In the Start menu I have a folder of CMake (although the old NSIS installer would create a folder CMake 3.5.0-rc1)

I then used just installed cmake to create installers based on IFW generator.

I built these offline installers:

http://ifw.podsvirov.pro/cmake/files/v3.5/cmake-3.5.0-rc1-win32-x86.exe

and

http://ifw.podsvirov.pro/cmake/files/v3.5/cmake-3.5.0-rc1-win64-x64.exe

In all cases I was using MSVC2013 and Qt5.5.1 for cmake-gui.
For me everything works fine.

I ask all those interested. To test the results and to share lessons learned.

Together we will make CMake better!!!

Regards,
Konstantin Podsvirov

From Gilles.Khouzam at microsoft.com  Wed Feb  3 17:16:37 2016
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Wed, 3 Feb 2016 22:16:37 +0000
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CAH1oQ8oQHo0KS74NuowvPXtNz0GvMFsGYyRLJNLKQgSvpfvgjQ@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
 <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CAH1oQ8ouBkgcaGO_O8=8zJkAsgrJ0DLi39OAQm1_F7FqsR9s6g@mail.gmail.com>
 <CY1PR0301MB07135C24DF007670D631C48C98D00@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CAH1oQ8oQHo0KS74NuowvPXtNz0GvMFsGYyRLJNLKQgSvpfvgjQ@mail.gmail.com>
Message-ID: <CY1PR0301MB07139E594B1F485AE27EB6B098D00@CY1PR0301MB0713.namprd03.prod.outlook.com>

Hi Yi-Hong,

I think that this is an issue that was recently fix in CMake which is not in our fork. I?ll look at pulling in this change in our branch.

From: Yi-Hong Lyu [mailto:b95705030 at ntu.edu.tw]
Sent: Wednesday, February 3, 2016 11:46
To: Gilles Khouzam <Gilles.Khouzam at microsoft.com>
Cc: Nicholas Braden <nicholas11braden at gmail.com>; cmake at cmake.org
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Gilles,

Here it is:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 -DLLVM_PATH="E:\\llvm" -DCMAKE_SYSTEM_VERSION=8.1  -DCMAKE_C_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" -DCMAKE_CXX_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" ..\src\
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- broken
CMake Error at E:/CMake/clang_3_7/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "E:\e2tools\ext-tools\llvm\clang-cl.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeTmp

  Run Build Command:"C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe"
  "cmTC_00a23.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=14.0"

  Microsoft (R) Build Engine version 14.0.24720.0

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5):
  error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset =
  'v140_clang_3_7') cannot be found.  To build using the v140_clang_3_7 build
  tools, please install v140_clang_3_7 build tools.  Alternatively, you may
  upgrade to the current Visual Studio tools by selecting the Project menu or
  right-click the solution, and then selecting "Retarget solution".
  [E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5): error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset = 'v140_clang_3_7') cannot be found. To build using the v140_clang_3_7 build tools, please install v140_clang_3_7 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

      0 warning
      1 error

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

-- Configuring incomplete, errors occurred!

PS. Part of the messages in Chinese are removed, please tell me if you need it as well

Thanks for your help,
Yi-Hong

2016-02-04 3:25 GMT+08:00 Gilles Khouzam <Gilles.Khouzam at microsoft.com<mailto:Gilles.Khouzam at microsoft.com>>:
Hi Yi-Hong,

Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your parameters?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160203/5298ac7c/attachment-0001.html>

From arankin at robarts.ca  Wed Feb  3 18:02:17 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Wed, 3 Feb 2016 23:02:17 +0000
Subject: [CMake] xyz_LIBRARIES
In-Reply-To: <CACQP5UfwqjDFwrHRv57_tsVxNPy5vMVetMc2bz4r21MTyX1=uw@mail.gmail.com>
References: <ec7e58739d8947a7b299a51c574ccf36@dag2.robarts.ca>
 <CACQP5UfwqjDFwrHRv57_tsVxNPy5vMVetMc2bz4r21MTyX1=uw@mail.gmail.com>
Message-ID: <1f9b8d1018fe43dbafe14e245a5f411f@dag2.robarts.ca>

Ok, that makes sense to me. What I?m seeing though, is that find modules and xyzConfig files for some software packages do not make a variable available that contains just target names. Xyz_LIBRARIES contains full path file locations.

This is my immediate frustration with leptonica for example. The config file it creates does not output a list of targets, and even if it did, it doesn?t dynamically build the list of targets depending on what dependencies it finds (libpng, libjpeg, etc?)

I think I will fork and rewrite the leptonica cmake file to properly expose target names.

Thanks,
Adam

From: Craig Scott [mailto:audiofanatic at gmail.com]
Sent: Wednesday, February 03, 2016 4:26 PM
To: Adam Rankin <arankin at robarts.ca>
Cc: cmake at cmake.org
Subject: Re: [CMake] xyz_LIBRARIES



On 4 February 2016 at 04:45, Adam Rankin <arankin at robarts.ca<mailto:arankin at robarts.ca>> wrote:
Hello all,

I am trying to sort out a project with multiple layers of dependencies and I am trying to figure out the ?right? way of configuring things.

First easy question: Should a value xyz_LIBRARIES contain target names, or library file locations?

Preferably target names, assuming you mean imported targets (see answer to next question).


 Second question: Should a FindXYZ.cmake file add imported targets, or should a USE_xyz variable be created for later inclusion? (what if the project does not export its targets?)

Imported targets will be better for end users/developers. An imported target can provide not just the library file location, it can also provide other dependencies such as dependent libraries that also must be linked, header search paths, etc. Furthermore, with an imported target you can explicitly control what other targets are affected by these dependencies simply by linking against your imported target. If you chose the USE_xyz variable + include approach, then the include file will typically end up calling  link_libraries(), link_directories() and/or include_directories() commands and making those things apply to all targets defined thereafter, which used to be the norm but is no longer necessary with all the target_xxx() commands added in more recent versions of CMake (well, 2.8.11 or later).


 Third question: How?s your day going today?

Ask me again after the coffee kicks in. :P


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

From Gilles.Khouzam at microsoft.com  Thu Feb  4 00:53:47 2016
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Thu, 4 Feb 2016 05:53:47 +0000
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
 <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>
 <CY1PR0301MB0713D560B5A3CDDF8950B0C598DE0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CAH1oQ8ouBkgcaGO_O8=8zJkAsgrJ0DLi39OAQm1_F7FqsR9s6g@mail.gmail.com>
 <CY1PR0301MB07135C24DF007670D631C48C98D00@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CAH1oQ8oQHo0KS74NuowvPXtNz0GvMFsGYyRLJNLKQgSvpfvgjQ@mail.gmail.com> 
Message-ID: <BY2PR0301MB070938D383103CE38D9F5DC898D10@BY2PR0301MB0709.namprd03.prod.outlook.com>

Hi Yi-Hong,

I?ve updated our branch to include the fix to not require the Windows 10 SDK. But I think that I misunderstood what you had meant by Clang-CL.

The support I added was for Clang with the Microsoft CodeGen engine which is included in Visual Studio 2015 Update 1, what?s where the v140_clang_3_7 is specified.

You can try the LLVM-vs2013 toolset and that might work (looking at http://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf). Can you create a sample project in VS and look at the toolset selection and select the one you want and specify that as the toolset for CMake?

From: Gilles Khouzam
Sent: Wednesday, February 3, 2016 14:17
To: 'Yi-Hong Lyu' <b95705030 at ntu.edu.tw>
Cc: Nicholas Braden <nicholas11braden at gmail.com>; cmake at cmake.org
Subject: RE: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hi Yi-Hong,

I think that this is an issue that was recently fix in CMake which is not in our fork. I?ll look at pulling in this change in our branch.

From: Yi-Hong Lyu [mailto:b95705030 at ntu.edu.tw]
Sent: Wednesday, February 3, 2016 11:46
To: Gilles Khouzam <Gilles.Khouzam at microsoft.com<mailto:Gilles.Khouzam at microsoft.com>>
Cc: Nicholas Braden <nicholas11braden at gmail.com<mailto:nicholas11braden at gmail.com>>; cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Gilles,

Here it is:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 -DLLVM_PATH="E:\\llvm" -DCMAKE_SYSTEM_VERSION=8.1  -DCMAKE_C_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" -DCMAKE_CXX_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" ..\src\
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- broken
CMake Error at E:/CMake/clang_3_7/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "E:\e2tools\ext-tools\llvm\clang-cl.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeTmp

  Run Build Command:"C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe"
  "cmTC_00a23.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=14.0"

  Microsoft (R) Build Engine version 14.0.24720.0

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5):
  error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset =
  'v140_clang_3_7') cannot be found.  To build using the v140_clang_3_7 build
  tools, please install v140_clang_3_7 build tools.  Alternatively, you may
  upgrade to the current Visual Studio tools by selecting the Project menu or
  right-click the solution, and then selecting "Retarget solution".
  [E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5): error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset = 'v140_clang_3_7') cannot be found. To build using the v140_clang_3_7 build tools, please install v140_clang_3_7 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

      0 warning
      1 error

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

-- Configuring incomplete, errors occurred!

PS. Part of the messages in Chinese are removed, please tell me if you need it as well

Thanks for your help,
Yi-Hong

2016-02-04 3:25 GMT+08:00 Gilles Khouzam <Gilles.Khouzam at microsoft.com<mailto:Gilles.Khouzam at microsoft.com>>:
Hi Yi-Hong,

Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your parameters?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/5a6eaaaa/attachment-0001.html>

From petr.kmoch at gmail.com  Thu Feb  4 02:04:46 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 4 Feb 2016 08:04:46 +0100
Subject: [CMake] Execute command after project generation
In-Reply-To: <56ABB9EA.6080401@gmail.com>
References: <56ABB9EA.6080401@gmail.com>
Message-ID: <CAKohaZe0Uzd-o4CqJMNRKcGh85CawRTQ2jQG0Aap-kDe3xbe7Q@mail.gmail.com>

Hi Nicolas.

Last time I asked for something like that, it was rejected:
http://public.kitware.com/Bug/view.php?id=13020

But maybe the stance could change on that? After all, I don't think CMake
would want to cater for every possible postprocessing anyone needs. Perhaps
it could be considered if a big warning "May not be forward compatible" was
attached to it?

Petr

On Fri, Jan 29, 2016 at 8:13 PM, Nicolas Schneider <nioncode at gmail.com>
wrote:

> Is it possible to execute commands after the generation step of the
> project files?
>
> I want to set custom properties in the generated Visual Studio project,
> because it should be built as a driver, which requires a few extra steps.
> These changes should be done automatically by CMake (or a script run
> after project generation) to be in sync between all developers.
>
> I also tried just setting the properties with something like: cmake
> --build . -- /p:FilesToPackage="a;b;c"
>
> But it seems like CMake does not pass the command as raw string, because
> msbuild complains about non-existing property, like it does when called
> directly without quotes: msbuild project /p:FilesToPackage=a;b;c
> which would treat 'b' as a property key instead of part of the value for
> FilesToPackage.
>
> The only workaround, currently, is to use:
> cmake ..
> modifyProjects.py
> cmake --build .
>
> However, I assume this does not work correctly if CMake regenerates the
> project files because of changes in CMakeLists (because
> modifyProjects.py will not be called automatically by CMake), correct?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160204/b56b32d9/attachment.html>

From petr.kmoch at gmail.com  Thu Feb  4 02:49:12 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 4 Feb 2016 08:49:12 +0100
Subject: [CMake] Help for a cmake newbie
In-Reply-To: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
References: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
Message-ID: <CAKohaZfZE0Yqu7sBX24gpztT+4X+Da7Do0WgVh11Z3AACkm=8A@mail.gmail.com>

Hi Vadtec.

*The* standard CMake way of dealing with building your dependencies is the
ExternalProject module (
https://cmake.org/cmake/help/latest/module/ExternalProject.html ). It's a
huge beast, but I belive there are some examples and tutorials available
out there.

The gist is: you create a top-level, "superbuild" CMakeLists.txt file which
will contain only the uses of ExternalProject_Add, one for each dependency,
and *one for you own project as well.* The dependencies can be downloaded,
patched, builtt, installed, etc., depending on the parameters you pass to
ExternalProject_Add. They do not have to be CMake-based; when they are not,
simply provide an empty (or otherwise project-specific) CONFIGURE_COMMAND
argument.

When CMake is run on the superbuild, it generates a buildsystem such that
building it downloads, builds, installs, etc. the external projects. All of
this happens at build time, not at CMake time.

This way, you have full control over which dependencies you build in what
order, where they get installed etc. Of course, in your case with
dependency sources shipped, you don't need a download step (or perhaps
maybe just to unpack them).

Once you've successfully built the superbuild once, all the dependencies
are ready, and your own project (which you've set up as just another
external project) is configured and all its dependencies are in locations
which you've specified. Now you switch into the binary directory
corresponding to your project and no longer need to work in the superbuild
- each external project is self-contained in that it can be used directly
as well, without having to go through the superbuild.

On a very symbolic level, an external project setup can look something like
this:

root/CMakeLists.txt:
project(SuperBuild)
include(ExternalProject)

ExternalProject_Add(
  LibraryWeNeed
  PREFIX deps/LibraryWeNeed
  DOWNLOAD_COMMAND somehow_unpack
${CMAKE_CURRENT_SOURCE_DIR}/deps/LibraryWeNeed.tgz --into
${CMAKE_CURRENT_BINARY_DIR}/deps/LibraryWeNeed
  BUILD_COMMAND make whatever
  ...
)

ExternalProject_Add(
  MyProjectItself
  PREFIX mybuild
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src
  DEPENDS LibraryWeNeed
  CMAKE_GENERATOR ${CMAKE_GENERATOR}  # use the same generator as the
superbuild
  CMAKE_CACHE_ARGS
-DLibraryWeNeed_ROOT:PATH=${CMAKE_CURRENT_BINARY_DIR}/deps/LibraryWeNeed
  ...
)


src/CMakeLists.txt:
project(MyProject)
find_package(LibraryWeNeed PATHS ${LibraryWeNeed_ROOT})  # the root path
was passed in by the superbuild
...


To work with this, you would then do:

cd build
cmake ../root  # generates superbuild
make  # builds superbuild
cd mybuild  # go into MyProject's binary dir
make  # builds MyProject


Once more, this is all very symbolic. Please refer to documentation,
tutorials etc. to achieve the behaviour you need.

Petr



On Sun, Jan 31, 2016 at 3:42 AM, vadtec <vadtec at vadtec.net> wrote:

> Let me start by saying I consider my self a cmake newbie. I've made simple
> makefiles and simple cmake files, but anything more complicated has to this
> point eluded me. Not for a lack of trying, searching, researching, trail,
> and a great deal of error: I simply have not been able to achieve the
> things I'm after. If the sort of questions I'm asking have been answered
> elsewhere (as I'm sure they have), I apologize for asking them again. That
> being said, I realize I'm going to be asking some questions that my
> Google-Fu has failed me in answering. Forgive me my failings, but I'm at my
> witts end.
>
>
> I have a project that I'm building on Linux that has a server component
> and a client component that also needs to run on Windows. It uses several
> libraries that I want to version lock so I run into fewer issues with cross
> compiling and feature creep.
>
> The project is laid out like this:
>
> /home
>     mydir/
>         project/
>             build/
>             bundle/
>             deps/
>                 curl-7.43.0/
>                 libiconv-1.14/
>                 libpng-1.6.18/
>                 libssh2-1.6.0/
>                 openssl-1.0.2d/
>                 sqlite/
>                 tinycthread/
>                 zlib-1.2.8/
>             include/
>                 client/
>                     client.h
>                 common/
>                     config.h
>                     common_funcs.h
>                 server/
>                     server.h
>             src/
>                 client/
>                     client.c
>                 common/
>                     common_funcs.c
>                 server/
>                     server.c
>
> curl, libiconv, libpng, libssh2, and zlib are the libs I want to build and
> use both on Linux and Windows. I know all of those are available on Linux
> and I could use the system installed versions, but I want to use the same
> vesions on Windows as well. The server is only built on Linux, while the
> client needs to be built for Linux and Windows. All the libs, headers, etc
> go into the build directory, and the final "make install" puts everything
> into the bundle directory, so it can be packaged for distribution.
>
> The client needs the curl, libiconv, libpng, libssh2, openssl, and zlib
> libraries. tinycthread is compiled directly into the client, so that's not
> an issue.
>
> The server needs the curl, libiconv, libssh2, openssl, and zlib libraries.
> tinycthread and sqlie are compiled directly into the server, so that's not
> an issue.
>
> Ideally, I'd like my cmake file to build the deps that need to be built,
> build the server and client for Linux, and finally build the client for
> Windows. Yes, all from the same cmake file. I realize this will probably
> have to be done with multiple cmake files or a bash script, but that's ok.
>
> I think building the libs can be done with custom commands or targets, but
> I haven't been able to figure out how. I haven't been able to get cmake to
> use only my versions of the libs I've compiled. Some of the libs are being
> found from the system wide versions, some are coming from my directory.
>
> My main problem is getting cmake to use only my locally installed/compiled
> copies of the libs. I need those libs to live along side the binaries, and
> using the versions I compile is important.
>
> Rather than provide the CMakeLists.txt I've been using, I'd like it if
> someone could provide an example file that would compile the above
> libraries (all of which use autoconf or custom compile scripts) and the
> client and server for Linux and Windows. I'm 100% certain I am not doing
> things correctly when it comes to the layout of the CMakeLists.txt, so I'd
> like to see something fresh from someone with much more experience in build
> script creation.
>
> Any help is greatly appreciated.
>
> ------------------------------
> Vadtec
> vadtec at vadtec.net
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/e927fa8c/attachment-0001.html>

From domen.vrankar at gmail.com  Thu Feb  4 03:19:34 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 4 Feb 2016 09:19:34 +0100
Subject: [CMake] CPack RPM generator not using CPACK_RPM_<component>_XXX
	variables
In-Reply-To: <CAMTTBtZ+8a+3ic-9PEgBvZHyEefA=dnkCO8Jdr2LN34Lw3Mkog@mail.gmail.com>
References: <CAMTTBtZGb4caUbck2DtZSEWhzsXaqibBPyUyXoPF=dyQZwLgAA@mail.gmail.com>
 <CAKgx6B+n30dfS8JV=6F3hMOfxZHyo0_FfP0iQOJfC5AcLgcE9w@mail.gmail.com>
 <CAMTTBtZ+8a+3ic-9PEgBvZHyEefA=dnkCO8Jdr2LN34Lw3Mkog@mail.gmail.com>
Message-ID: <CAKgx6B+u6s1Ro0MXjPGgWHCAbeFNspxoxGet8m6hWVD98hJS2g@mail.gmail.com>

> Can this use of mixed case-sensitive/all-upper-case can be clarified in the
> documentation for CPACK_ and CPAC_RPM_ component variables?

I was certain that this was already documented... I'll document it and
also change CPackRPM so that it will support both original version of
component name and upper cased version so there will be less
confusion.

Thanks,
Domen

From csiga.biga at aol.com  Thu Feb  4 09:33:25 2016
From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=)
Date: Thu, 4 Feb 2016 15:33:25 +0100
Subject: [CMake] CTest integration in Visual Studio TestExplorer
In-Reply-To: <8459a300caa94947a53f9d35608174bc@DE013815.schaeffler.com>
References: <8459a300caa94947a53f9d35608174bc@DE013815.schaeffler.com>
Message-ID: <mailman.6.1454596437.8417.cmake@cmake.org>


Hi Michael,

first of all, let me congratulate you on the integration. Great stuff and much apreciated.

I gave your add-in a spin, however it fails to find my unit tests. I set the output directory globally in the top-level CMakeLists.txt file as


set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})

inside my unit-tests? file I have entries such as

# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})

?

# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )


I have configured my build to use VS2015 Win64 platform. Because the default is to look for x86 targets, I changed the default test platform to be x64 within VS, but it still won?t find my tests. Could you give some directions what might I be doing wrong?

Cheers,
M?t?


Felad?: Stuermer, Michael SP/HZA-ZSEP
Elk?ldve: 2016. janu?r 22., p?ntek 12:37
C?mzett: cmake at cmake.org
T?rgy: [CMake] CTest integration in Visual Studio TestExplorer

Hello everyone,

picking up the line from Tobias from around a year ago I changed a few things in the ctest unittest adapter. It now works for both Visual Studio 2013 and 2015. 2012 is supported in general but I didn't try it (means: I can install it). Merging and pull request for original version will follow (as soon as there is time), but I would be really happy if some developers from the community could comment on the current state and give some feedback.

I tested it so far with the CMake build and tests and discovering and executing the whole lot of 400+ tests runs well so far. Let me know what could/should be improved.

You can download the latest version of the extension here:

https://github.com/micst/CTestTestAdapter/blob/micst/CTestTestAdapter.vsix

Check the sources on github here:

https://github.com/micst/CTestTestAdapter

best regards,
Michael


-----Original Message-----
From: Tobias Becker [mailto:becker.tobi at gmail.com] 
Sent: Saturday, November 22, 2014 11:35 PM
Subject: [CMake] CTest integration in Visual Studio TestExplorer

So I tried my luck with creating an extension for Visual Studio that allows you to use the Test Explorer to discover and run your CTests.  You can download it in the visual studio gallery. Read about it on http://thetoeb.de/2014/11/22/ctest-integration-visualstudio/ .

I'd be happy if anyone wanted to give me feedback or contribute on https://github.com/toeb/CTestTestAdapter ;)

Sorry for the shameless plug (but hey - its free)


Kind Regards,

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

-- 

Powered by www.kitware.com

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

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

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

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

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

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

From kgt at lanl.gov  Thu Feb  4 11:00:27 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Thu, 4 Feb 2016 16:00:27 +0000
Subject: [CMake] CMake 3.5.0-rc1 install is missing dependencies
In-Reply-To: <2392ba91bd7f4189ac16d8d657a3d60a@EXG13-P-MBX09.win.lanl.gov>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
 <56B249F5.6010702@kitware.com>
 <2392ba91bd7f4189ac16d8d657a3d60a@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <d41db6eefc06472a83598eeaebcafc49@EXG13-P-MBX09.win.lanl.gov>

BTW - I am seeing the segmentation fault at the same location on 3 different systems:

SUSE Linux Enterprise Server 11 (x86_64)
CentOS Linux release 7.1.1503 (Core)
Red Hat Enterprise Linux Workstation release 6.7 (Santiago)

My project is not open source and I cannot distribute our source code.

I recompiled cmake-3.5.0-rc1 from sources with debug symbols and ran under a debugger. I located this failure:

Thread 1 stopped in cmPolicies::PolicyMap::Get with signal SIGSEGV ?(Segmentation fault)?.
Reason/Origin: address not mapped to object ?(attempt to access invalid address)?

The call stack is:

#17 main (ac=2, av=0x110b4f0) at .../cmake-3.5.0-rc1/Source/cmakemain.cxx:190 (at 0x000000000066e580)
#16 do_cmake (ac=2, av=0x110b4f0) at .../cmake-3.5.0-rc1/Source/cmakemain.cxx:330 (at 0x000000000066f67b)
#15 cmake::Run (this=0x7fffffffa700, args=std::vector of length 2, capacity 2 = {...}, noconfigure=false) at .../cmake-3.5.0-rc1/Source/cmake.cxx:1731 (at 0x00000000007a15e9)
#14 cmake::Configure (this=0x7fffffffa700) at .../cmake-3.5.0-rc1/Source/cmake.cxx:1356 (at 0x00000000007a210f)
#13 cmake::ActualConfigure (this=0x7fffffffa700) at .../cmake-3.5.0-rc1/Source/cmake.cxx:1573 (at 0x00000000007a3a93)
#12 cmGlobalUnixMakefileGenerator3::Configure (this=0x1119b50) at .../cmake-3.5.0-rc1/Source/cmGlobalUnixMakefileGenerator3.cxx:129 (at 0x0000000000a308ce)
#11 cmGlobalGenerator::Configure (this=0x1119b50) at .../cmake-3.5.0-rc1/Source/cmGlobalGenerator.cxx:1148 (at 0x0000000000a026aa)
#10 cmMakefile::Configure (this=0x111af40) at .../cmake-3.5.0-rc1/Source/cmMakefile.cxx:1665 (at 0x00000000006d6beb)
#9 cmMakefile::ReadListFile (this=0x111af40, listFile=..., filenametoread="/users/kellyt/draco/CMakeLists.txt") at .../cmake-3.5.0-rc1/Source/cmMakefile.cxx:569 (at 0x00000000006e831c)
#8 cmMakefile::ExecuteCommand (this=0x111af40, lff=..., status=...) at .../cmake-3.5.0-rc1/Source/cmMakefile.cxx:263 (at 0x00000000006e0799)
#7 cmCommand::InvokeInitialPass (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}, status=...) at .../cmake-3.5.0-rc1/Source/cmCommand.h:68 (at 0x000000000085a466)
#6 cmInstallCommand::InitialPass (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}) at .../cmake-3.5.0-rc1/Source/cmInstallCommand.cxx:103 (at 0x000000000089ac4a)
#5 cmInstallCommand::HandleExportMode (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}) at .../cmake-3.5.0-rc1/Source/cmInstallCommand.cxx:1379 (at 0x00000000008a802a)
#4 cmTarget::GetPolicyStatusCMP0022 (this=0x0) at .../cmake-3.5.0-rc1/Source/cmTarget.h:90 (at 0x00000000008c5636)
#3 cmPolicies::PolicyMap::Get (this=0xf0, id=cmPolicies::CMP0022) at .../cmake-3.5.0-rc1/Source/cmPolicies.cxx:367 (at 0x0000000000729156)
#2 std::bitset<198ul>::operator[] (this=0xf0, __position=66) at .../include/c++/4.4.7/bitset:1009 (at 0x00000000007296e7)
#1 std::bitset<198ul>::_Unchecked_test (this=0xf0, __pos=66) at .../include/c++/4.4.7/bitset:904 (at 0x0000000000729663)
#0 std::_Base_bitset<4ul>::_M_getword (this=0xf0, __pos=66) at .../include/c++/4.4.7/bitset:107 (at 0x00000000007295e4)

In cmInstallCommand.cxx, line 1376

cmTarget* tgt = this->Makefile->FindTarget(te->TargetName);

is setting tgt to a NULL pointer (0x0) that is dereferenced in the next line (stack location #5)

tgt->GetPolicyStatusCMP0022()

This is causing the segfault.

-kt

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Thompson, KT
Sent: Wednesday, February 03, 2016 12:00 PM
To: Brad King <brad.king at kitware.com>
Cc: cmake at cmake.orgputt
Subject: Re: [CMake] CMake 3.5.0-rc1 install is missing dependencies

I'm working on a reproducer.  For now, all I can say is that it looks like the segmentation fault occurs on this command:

install( EXPORT foo-targets
  DESTINATION foo
  EXPORT_LINK_INTERFACE_LIBRARIES )

-kt

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, February 03, 2016 11:42 AM
To: Thompson, KT <kgt at lanl.gov>
Cc: cmake at cmake.org
Subject: Re: [CMake] CMake 3.5.0-rc1 install is missing dependencies

On 02/03/2016 11:19 AM, Thompson, KT wrote:
> On RHEL 6.7, I extracted the prebuilt x86_64 binaries from the
> downloaded .tar.gz file.  At the end of the configuration process,
> cmake issues a segmentation fault and no Makefiles are generated.

What project are you configuring?

Can you provide a CMakeLists.txt file that reproduces this crash?

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

From boxerab at gmail.com  Thu Feb  4 11:42:02 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Thu, 4 Feb 2016 11:42:02 -0500
Subject: [CMake] undefined reference to 'pthread_create'
Message-ID: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>

Hello,
I have a cmake project that uses C++11 threads.
I have added the lines

set (CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)


CMAKE version is 3.2.2, running on Ubuntu.

When I try to build, I get the error

undefined reference to `pthread_create`

Any ideas on how to fix this?

Thanks!
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/9ef7dd94/attachment-0001.html>

From csiga.biga at aol.com  Thu Feb  4 11:51:17 2016
From: csiga.biga at aol.com (=?utf-8?Q?M=C3=A1t=C3=A9_Ferenc_Nagy-Egri?=)
Date: Thu, 4 Feb 2016 17:51:17 +0100
Subject: [CMake] CTest integration in Visual Studio TestExplorer
In-Reply-To: <b71f3d52631c4dba8b0754f0b85b52aa@DE013666.schaeffler.com>
References: <8459a300caa94947a53f9d35608174bc@DE013815.schaeffler.com>
 <20160204143400.43CBBE4CA4@public.kitware.com>
 <b71f3d52631c4dba8b0754f0b85b52aa@DE013666.schaeffler.com>
Message-ID: <mailman.7.1454604681.8417.cmake@cmake.org>

Indeed, both RUN_TESTS and the CTest files exist, I have even found a file created by the add-in which seems to hold correct target names.

Recompiling will take some time, but will try to help with it.

----- Eredeti ?zenet -----
Felad?: "Stuermer, Michael  SP/HZA-ZSEP" <michael.stuermer at schaeffler.com>
Feladva: ?2016.?02.?04. 16:27
C?mzett: "Nagy-Egri M?t? Ferenc" <csiga.biga at aol.com>; "cmake at cmake.org" <cmake at cmake.org>
T?rgy: RE: CTest integration in Visual Studio TestExplorer

Hi M?t?,
 
thanks for trying the extension!
 
Some questions before going more into details:
-          do you have a CTestTestfile.cmake in your build root i.e. where the.sln file is you have opened with Visual Studio?
-          do you have a RUN_TESTS target/project in your visual studio solution? It could be in the ?CMakePredefinedTargets? folder?
 
The basic concept of test discovery for the plugin is, to look for a CTestTestfile.cmake file in the same folder where the .sln file is. From there all CTestTestfile.cmake files are searched recursively and all tests which are defined by add_test() within the files are added to the test list.
 
There are some debug logging lines in the plugin, but I deactivated them for now. Unfortunately there is no option-page where you can switch the logging on/off (should move that to the top of the feature list). You could get the sources from github, enable logging, build your custom version and see what message you get.
 
The changes would be in ?CTestExecutor.cs? (line 27) and ?CTestDiscoverer.cs? (line 29). Change the line
 
public bool EnableLogging { get; set; } = false;
 
to
 
public bool EnableLogging { get; set; } = true;
 
further comments inline.
 
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake
Sent: Thursday, February 04, 2016 3:33 PM
To: cmake at cmake.org
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer
 
 
Hi Michael,
 
first of all, let me congratulate you on the integration. Great stuff and much apreciated.
 
I gave your add-in a spin, however it fails to find my unit tests. I set the output directory globally in the top-level CMakeLists.txt file as
 
 
set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})
 
[>] this should be perfectly OK, ctest should take care for itself where to find the binaries to execute when testing.
 
inside my unit-tests? file I have entries such as
 
# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})
 
?
 
# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )
 
[>] what do you mean by ?unit-test file?? Is it just another CMakeLists.txt or cmake script in your cmake script tree? or is this some script you run using ctest? I am not familiar with the ctest scripting options and I am pretty sure this is not supported by the extension right now. It is mainly thought to provide the tests which are executed by the RUN_TESTS target within the test explorer and allow more comfortable separate test running from within VS.
 
I have configured my build to use VS2015 Win64 platform. Because the default is to look for x86 targets, I changed the default test platform to be x64 within VS, but it still won?t find my tests. Could you give some directions what might I be doing wrong?
 
[>] AFAIK you don?t have to switch any

[Az eredeti ?zenetnek csak egy r?sze van beillesztve.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/c784e02a/attachment.html>

From rpelapur at archlinux.info  Thu Feb  4 11:53:37 2016
From: rpelapur at archlinux.info (rpelapur at archlinux.info)
Date: Thu, 4 Feb 2016 10:53:37 -0600
Subject: [CMake] undefined reference to 'pthread_create'
In-Reply-To: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
References: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
Message-ID: <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>

I believe that doesn't have anything to do with C11 flags. You are just missing the link to the pthread library. I could be wrong.

Try and add this to your cmake file:
find_package (Threads) 
target_link_libraries (myexecutable/lib ${CMAKE_THREAD_LIBS_INIT})


Sent from my iPhone

> On Feb 4, 2016, at 10:42 AM, Aaron Boxer <boxerab at gmail.com> wrote:
> 
> Hello,
> I have a cmake project that uses C++11 threads.
> I have added the lines 
> 
> set (CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> 
> 
> CMAKE version is 3.2.2, running on Ubuntu.
> 
> When I try to build, I get the error
> 
> undefined reference to `pthread_create`
> 
> Any ideas on how to fix this?
> 
> Thanks!
> Aaron
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160204/1ad97865/attachment.html>

From d3ck0r at gmail.com  Thu Feb  4 12:03:28 2016
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 4 Feb 2016 09:03:28 -0800
Subject: [CMake] MinGW Error having sh.exe
Message-ID: <CAA2GJqUE5U4PmFcApa+dm9QsJJcUyPybc-zUAGnNmO_v5kfNtw@mail.gmail.com>

When using -G "MinGW Makefiles" I keep getting an error

---------------------------

CMake Error at C:/General/tools/unix/cmake/share/cmake-3.5/Modules/CMakeMinGWFindMake.cmake:22
(message):
  sh.exe was found in your PATH, here:

  C:/Program Files/Git/bin/sh.exe

  For MinGW make to work correctly sh.exe must NOT be in your path.

  Run cmake from a shell that does not have sh.exe in your PATH.

  If you want to use a UNIX shell, then use MSYS Makefiles.

Call Stack (most recent call first):
  CMakeLists.txt:8 (project)


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

-------------------------

if I just re-run the cmake It completes fine and even compiles correctly.

It's getting sh because GIT uses it... and it's not something I can
really bypass, and I sometimes do NEED git in my path.

if I just edit the CmakeMinGWFIndMake.cmake file and comment out the
mesage box and make program override it also works just fine.

once upon a time ... maybe a decade ago sh.exe in the path caused
erorrs... but this sin't such an issue anymore. ( Since Mingw32-make
ignores -j # option?)

---------
if(CMAKE_SH)

  #message(FATAL_ERROR "sh.exe was found in your PATH,
here:\n${CMAKE_SH}\nFor MinGW make to work correctly sh.exe must NOT
be in your path.\nRun cmake from a shell that does not have sh.exe in
your PATH.\nIf you want to use a UNIX shell, then use MSYS
Makefiles.\n")

  #set(CMAKE_MAKE_PROGRAM NOTFOUND)

endif()
-------------

From michael.stuermer at schaeffler.com  Thu Feb  4 10:27:16 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Thu, 4 Feb 2016 15:27:16 +0000
Subject: [CMake] CTest integration in Visual Studio TestExplorer
In-Reply-To: <20160204143400.43CBBE4CA4@public.kitware.com>
References: <8459a300caa94947a53f9d35608174bc@DE013815.schaeffler.com>
 <20160204143400.43CBBE4CA4@public.kitware.com>
Message-ID: <b71f3d52631c4dba8b0754f0b85b52aa@DE013666.schaeffler.com>

Hi M?t?,

thanks for trying the extension!

Some questions before going more into details:

-          do you have a CTestTestfile.cmake in your build root i.e. where the.sln file is you have opened with Visual Studio?

-          do you have a RUN_TESTS target/project in your visual studio solution? It could be in the ?CMakePredefinedTargets? folder?

The basic concept of test discovery for the plugin is, to look for a CTestTestfile.cmake file in the same folder where the .sln file is. From there all CTestTestfile.cmake files are searched recursively and all tests which are defined by add_test() within the files are added to the test list.

There are some debug logging lines in the plugin, but I deactivated them for now. Unfortunately there is no option-page where you can switch the logging on/off (should move that to the top of the feature list). You could get the sources from github, enable logging, build your custom version and see what message you get.

The changes would be in ?CTestExecutor.cs? (line 27) and ?CTestDiscoverer.cs? (line 29). Change the line

public bool EnableLogging { get; set; } = false;

to

public bool EnableLogging { get; set; } = true;

further comments inline.

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake
Sent: Thursday, February 04, 2016 3:33 PM
To: cmake at cmake.org
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer


Hi Michael,

first of all, let me congratulate you on the integration. Great stuff and much apreciated.

I gave your add-in a spin, however it fails to find my unit tests. I set the output directory globally in the top-level CMakeLists.txt file as


set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})

[>] this should be perfectly OK, ctest should take care for itself where to find the binaries to execute when testing.

inside my unit-tests? file I have entries such as

# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})

?

# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )

[>] what do you mean by ?unit-test file?? Is it just another CMakeLists.txt or cmake script in your cmake script tree? or is this some script you run using ctest? I am not familiar with the ctest scripting options and I am pretty sure this is not supported by the extension right now. It is mainly thought to provide the tests which are executed by the RUN_TESTS target within the test explorer and allow more comfortable separate test running from within VS.

I have configured my build to use VS2015 Win64 platform. Because the default is to look for x86 targets, I changed the default test platform to be x64 within VS, but it still won?t find my tests. Could you give some directions what might I be doing wrong?

[>] AFAIK you don?t have to switch anything here to discover ctest tests. The tests are discovered from the CTestTestfile.cmake files, there is no checking for platform or bitness done.


Cheers,
M?t?


Felad?: Stuermer, Michael SP/HZA-ZSEP<mailto:michael.stuermer at schaeffler.com>
Elk?ldve: 2016. janu?r 22., p?ntek 12:37
C?mzett: cmake at cmake.org<mailto:cmake at cmake.org>
T?rgy: [CMake] CTest integration in Visual Studio TestExplorer

Hello everyone,

picking up the line from Tobias from around a year ago I changed a few things in the ctest unittest adapter. It now works for both Visual Studio 2013 and 2015. 2012 is supported in general but I didn't try it (means: I can install it). Merging and pull request for original version will follow (as soon as there is time), but I would be really happy if some developers from the community could comment on the current state and give some feedback.

I tested it so far with the CMake build and tests and discovering and executing the whole lot of 400+ tests runs well so far. Let me know what could/should be improved.

You can download the latest version of the extension here:

https://github.com/micst/CTestTestAdapter/blob/micst/CTestTestAdapter.vsix

Check the sources on github here:

https://github.com/micst/CTestTestAdapter

best regards,
Michael


-----Original Message-----
From: Tobias Becker [mailto:becker.tobi at gmail.com]
Sent: Saturday, November 22, 2014 11:35 PM
Subject: [CMake] CTest integration in Visual Studio TestExplorer

So I tried my luck with creating an extension for Visual Studio that allows you to use the Test Explorer to discover and run your CTests.  You can download it in the visual studio gallery. Read about it on http://thetoeb.de/2014/11/22/ctest-integration-visualstudio/ .

I'd be happy if anyone wanted to give me feedback or contribute on https://github.com/toeb/CTestTestAdapter ;)

Sorry for the shameless plug (but hey - its free)


Kind Regards,

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

--

Powered by www.kitware.com<http://www.kitware.com>

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

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

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

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

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

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

From d3ck0r at gmail.com  Thu Feb  4 12:05:54 2016
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 4 Feb 2016 09:05:54 -0800
Subject: [CMake] undefined reference to 'pthread_create'
In-Reply-To: <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
References: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
 <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
Message-ID: <CAA2GJqX386gYc8w91tONETRWcktQ2gpJ21YreRk3Jwzcx_BLvA@mail.gmail.com>

Probably didn't previously need pthreads until you updated to use
C++11 features which brings in pthreads in the deadstart code...


On Thu, Feb 4, 2016 at 8:53 AM, rpelapur at archlinux.info
<rpelapur at archlinux.info> wrote:
> I believe that doesn't have anything to do with C11 flags. You are just
> missing the link to the pthread library. I could be wrong.
>
> Try and add this to your cmake file:
>
> find_package (Threads)
>
> target_link_libraries (myexecutable/lib ${CMAKE_THREAD_LIBS_INIT})
>
>
>
> Sent from my iPhone
>
> On Feb 4, 2016, at 10:42 AM, Aaron Boxer <boxerab at gmail.com> wrote:
>
> Hello,
> I have a cmake project that uses C++11 threads.
> I have added the lines
>
> set (CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
>
> CMAKE version is 3.2.2, running on Ubuntu.
>
> When I try to build, I get the error
>
> undefined reference to `pthread_create`
>
> Any ideas on how to fix this?
>
> Thanks!
> Aaron
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From boxerab at gmail.com  Thu Feb  4 12:55:50 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Thu, 4 Feb 2016 12:55:50 -0500
Subject: [CMake] undefined reference to 'pthread_create'
In-Reply-To: <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
References: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
 <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
Message-ID: <CAK8GPyDjghpjgZHNzF=UTH7sUH2-4kXv4DWOHTH6VZJzq23-1g@mail.gmail.com>

Thanks. So, even though threading is part of the standard, I still need to
link to pthreads library ?

On Thu, Feb 4, 2016 at 11:53 AM, rpelapur at archlinux.info <
rpelapur at archlinux.info> wrote:

> I believe that doesn't have anything to do with C11 flags. You are just
> missing the link to the pthread library. I could be wrong.
>
> Try and add this to your cmake file:
>
> find_package (Threads)
>
> target_link_libraries (myexecutable/lib ${CMAKE_THREAD_LIBS_INIT})
>
>
>
> Sent from my iPhone
>
> On Feb 4, 2016, at 10:42 AM, Aaron Boxer <boxerab at gmail.com> wrote:
>
> Hello,
> I have a cmake project that uses C++11 threads.
> I have added the lines
>
> set (CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
>
> CMAKE version is 3.2.2, running on Ubuntu.
>
> When I try to build, I get the error
>
> undefined reference to `pthread_create`
>
> Any ideas on how to fix this?
>
> Thanks!
> Aaron
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160204/92890a8c/attachment.html>

From brad.king at kitware.com  Thu Feb  4 12:57:13 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 4 Feb 2016 12:57:13 -0500
Subject: [CMake] CMake 3.5.0-rc1 crash (was: CMake 3.5.0-rc1 install is
 missing dependencies)
In-Reply-To: <d41db6eefc06472a83598eeaebcafc49@EXG13-P-MBX09.win.lanl.gov>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
 <56B249F5.6010702@kitware.com>
 <2392ba91bd7f4189ac16d8d657a3d60a@EXG13-P-MBX09.win.lanl.gov>
 <d41db6eefc06472a83598eeaebcafc49@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <56B390F9.9020608@kitware.com>

On 02/04/2016 11:00 AM, Thompson, KT wrote:
> #6 cmInstallCommand::InitialPass (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}) at .../cmake-3.5.0-rc1/Source/cmInstallCommand.cxx:103 (at 0x000000000089ac4a)
> #5 cmInstallCommand::HandleExportMode (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}) at .../cmake-3.5.0-rc1/Source/cmInstallCommand.cxx:1379 (at 0x00000000008a802a)
> #4 cmTarget::GetPolicyStatusCMP0022 (this=0x0) at .../cmake-3.5.0-rc1/Source/cmTarget.h:90 (at 0x00000000008c5636)
[snip]
> In cmInstallCommand.cxx, line 1376
> 
> cmTarget* tgt = this->Makefile->FindTarget(te->TargetName);
> 
> is setting tgt to a NULL pointer (0x0) that is dereferenced in the next line

Thanks!  From that I was able to narrow it to a simple test case:

------------------------------------------------------------------------------
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo C)
add_subdirectory(A)
add_library(B SHARED empty.c)
install(TARGETS B DESTINATION lib EXPORT FooTargets)
install(EXPORT FooTargets DESTINATION lib/cmake/foo EXPORT_LINK_INTERFACE_LIBRARIES)

$ cat A/CMakeLists.txt
add_library(A SHARED ../empty.c)
install(TARGETS A DESTINATION lib EXPORT FooTargets)

$ mkdir b ; cd b
$ cmake --version
cmake version 3.5.0-rc1

$ cmake ..
...
Segmentation fault
------------------------------------------------------------------------------

This was likely caused by this change:

 cmExportSet: Store a cmGeneratorTarget.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=381e7afd#patch6

Here is a fix and a test case:

 install(EXPORT): Fix crash on target in another directory
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290fb8b9

I've queued this for merge to 'release' for inclusion in 3.5.0-rc2.

Thanks,
-Brad

From d3ck0r at gmail.com  Thu Feb  4 13:05:39 2016
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 4 Feb 2016 10:05:39 -0800
Subject: [CMake] undefined reference to 'pthread_create'
In-Reply-To: <CAK8GPyDjghpjgZHNzF=UTH7sUH2-4kXv4DWOHTH6VZJzq23-1g@mail.gmail.com>
References: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
 <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
 <CAK8GPyDjghpjgZHNzF=UTH7sUH2-4kXv4DWOHTH6VZJzq23-1g@mail.gmail.com>
Message-ID: <CAA2GJqUY9PqtGnxRCYmhx=u4OYXBcm2+AK8OOSA=-6mFfR91JQ@mail.gmail.com>

On Thu, Feb 4, 2016 at 9:55 AM, Aaron Boxer <boxerab at gmail.com> wrote:
> Thanks. So, even though threading is part of the standard, I still need to
> link to pthreads library ?

Yes; sounds more like an issue for GCC :)   I mean you don't have to
tell it to link against c library or c++ runtime libraries... and it
IS pthread specific so it's not like there's going to be some
alternative provider for such services.

using MinGW under linux to get a windows output it links automatically
to a 'winpthreads.dll' which then becomes a runtime requirement... so
it's not impossible for the compiler suite to do.


>
> On Thu, Feb 4, 2016 at 11:53 AM, rpelapur at archlinux.info
> <rpelapur at archlinux.info> wrote:
>>
>> I believe that doesn't have anything to do with C11 flags. You are just
>> missing the link to the pthread library. I could be wrong.
>>
>> Try and add this to your cmake file:
>>
>> find_package (Threads)
>>
>> target_link_libraries (myexecutable/lib ${CMAKE_THREAD_LIBS_INIT})
>>
>>
>>
>> Sent from my iPhone
>>
>> On Feb 4, 2016, at 10:42 AM, Aaron Boxer <boxerab at gmail.com> wrote:
>>
>> Hello,
>> I have a cmake project that uses C++11 threads.
>> I have added the lines
>>
>> set (CMAKE_CXX_STANDARD 14)
>> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>>
>>
>> CMAKE version is 3.2.2, running on Ubuntu.
>>
>> When I try to build, I get the error
>>
>> undefined reference to `pthread_create`
>>
>> Any ideas on how to fix this?
>>
>> Thanks!
>> Aaron
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From kgt at lanl.gov  Thu Feb  4 13:38:21 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Thu, 4 Feb 2016 18:38:21 +0000
Subject: [CMake] CMake 3.5.0-rc1 crash (was: CMake 3.5.0-rc1 install is
 missing dependencies)
In-Reply-To: <56B390F9.9020608@kitware.com>
References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov>
 <56B249F5.6010702@kitware.com>
 <2392ba91bd7f4189ac16d8d657a3d60a@EXG13-P-MBX09.win.lanl.gov>
 <d41db6eefc06472a83598eeaebcafc49@EXG13-P-MBX09.win.lanl.gov>
 <56B390F9.9020608@kitware.com>
Message-ID: <d5a10736b34c465bb88f9790fdb550f3@EXG13-P-MBX09.win.lanl.gov>

Your patch fixes the problem I was seeing.

Thank you,

-kt

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Thursday, February 04, 2016 10:57 AM
To: Thompson, KT <kgt at lanl.gov>
Cc: cmake at cmake.org; Stephen Kelly <steveire at gmail.com>
Subject: Re: [CMake] CMake 3.5.0-rc1 crash (was: CMake 3.5.0-rc1 install is missing dependencies)

On 02/04/2016 11:00 AM, Thompson, KT wrote:
> #6 cmInstallCommand::InitialPass (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}) at .../cmake-3.5.0-rc1/Source/cmInstallCommand.cxx:103 (at 0x000000000089ac4a)
> #5 cmInstallCommand::HandleExportMode (this=0x1417360, args=std::vector of length 5, capacity 5 = {...}) at .../cmake-3.5.0-rc1/Source/cmInstallCommand.cxx:1379 (at 0x00000000008a802a)
> #4 cmTarget::GetPolicyStatusCMP0022 (this=0x0) at .../cmake-3.5.0-rc1/Source/cmTarget.h:90 (at 0x00000000008c5636)
[snip]
> In cmInstallCommand.cxx, line 1376
> 
> cmTarget* tgt = this->Makefile->FindTarget(te->TargetName);
> 
> is setting tgt to a NULL pointer (0x0) that is dereferenced in the next line

Thanks!  From that I was able to narrow it to a simple test case:

------------------------------------------------------------------------------
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo C)
add_subdirectory(A)
add_library(B SHARED empty.c)
install(TARGETS B DESTINATION lib EXPORT FooTargets)
install(EXPORT FooTargets DESTINATION lib/cmake/foo EXPORT_LINK_INTERFACE_LIBRARIES)

$ cat A/CMakeLists.txt
add_library(A SHARED ../empty.c)
install(TARGETS A DESTINATION lib EXPORT FooTargets)

$ mkdir b ; cd b
$ cmake --version
cmake version 3.5.0-rc1

$ cmake ..
...
Segmentation fault
------------------------------------------------------------------------------

This was likely caused by this change:

 cmExportSet: Store a cmGeneratorTarget.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=381e7afd#patch6

Here is a fix and a test case:

 install(EXPORT): Fix crash on target in another directory
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290fb8b9

I've queued this for merge to 'release' for inclusion in 3.5.0-rc2.

Thanks,
-Brad

From boxerab at gmail.com  Thu Feb  4 14:57:49 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Thu, 4 Feb 2016 14:57:49 -0500
Subject: [CMake] undefined reference to 'pthread_create'
In-Reply-To: <CAA2GJqUY9PqtGnxRCYmhx=u4OYXBcm2+AK8OOSA=-6mFfR91JQ@mail.gmail.com>
References: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
 <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
 <CAK8GPyDjghpjgZHNzF=UTH7sUH2-4kXv4DWOHTH6VZJzq23-1g@mail.gmail.com>
 <CAA2GJqUY9PqtGnxRCYmhx=u4OYXBcm2+AK8OOSA=-6mFfR91JQ@mail.gmail.com>
Message-ID: <CAK8GPyAddt1790aQSo-_dPdyHgm4kRhFJ9hOdRGeQNRNdeiLGQ@mail.gmail.com>

Thanks, guys!!!! This is working now.

Cheers,
Aaron

On Thu, Feb 4, 2016 at 1:05 PM, J Decker <d3ck0r at gmail.com> wrote:

> On Thu, Feb 4, 2016 at 9:55 AM, Aaron Boxer <boxerab at gmail.com> wrote:
> > Thanks. So, even though threading is part of the standard, I still need
> to
> > link to pthreads library ?
>
> Yes; sounds more like an issue for GCC :)   I mean you don't have to
> tell it to link against c library or c++ runtime libraries... and it
> IS pthread specific so it's not like there's going to be some
> alternative provider for such services.
>
> using MinGW under linux to get a windows output it links automatically
> to a 'winpthreads.dll' which then becomes a runtime requirement... so
> it's not impossible for the compiler suite to do.
>
>
> >
> > On Thu, Feb 4, 2016 at 11:53 AM, rpelapur at archlinux.info
> > <rpelapur at archlinux.info> wrote:
> >>
> >> I believe that doesn't have anything to do with C11 flags. You are just
> >> missing the link to the pthread library. I could be wrong.
> >>
> >> Try and add this to your cmake file:
> >>
> >> find_package (Threads)
> >>
> >> target_link_libraries (myexecutable/lib ${CMAKE_THREAD_LIBS_INIT})
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On Feb 4, 2016, at 10:42 AM, Aaron Boxer <boxerab at gmail.com> wrote:
> >>
> >> Hello,
> >> I have a cmake project that uses C++11 threads.
> >> I have added the lines
> >>
> >> set (CMAKE_CXX_STANDARD 14)
> >> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> >>
> >>
> >> CMAKE version is 3.2.2, running on Ubuntu.
> >>
> >> When I try to build, I get the error
> >>
> >> undefined reference to `pthread_create`
> >>
> >> Any ideas on how to fix this?
> >>
> >> Thanks!
> >> Aaron
> >>
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> >> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For more
> >> information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/cmake
> >
> >
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/38b164b8/attachment.html>

From kgt at lanl.gov  Thu Feb  4 16:00:42 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Thu, 4 Feb 2016 21:00:42 +0000
Subject: [CMake] cmake 3.5.0-rc1 Error copying Fortran module
Message-ID: <fb5a5e9f00f24ac9a6d3957b7d66d420@EXG13-P-MBX09.win.lanl.gov>

In my mixed C++/Fortran Makefile-based project, I am encountering the following error with RC1 of CMake-3.5.0:

Entering directory `/projects/foo/build/d'
/var/tmp/cmake-install/bin/cmake -E cmake_copy_f90_mod myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel
Error copying Fortran module "myf90file".  Tried "MYF90FILE.mod" and "myf90file.mod".

If I run ?make VERBOSE=1? with CMake-3.4.3, I see the following command:

cmake -E cmake_copy_f90_mod src/dir1/dir2/myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel

but with CMake-3.5.0-rc1, I have this command (notice that no path is provided for the filename (argument 3)):

cmake -E cmake_copy_f90_mod myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel

This looks like another bug in RC1

-kt

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

From eike at sf-mail.de  Thu Feb  4 15:58:33 2016
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Thu, 04 Feb 2016 21:58:33 +0100
Subject: [CMake] undefined reference to 'pthread_create'
In-Reply-To: <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
References: <CAK8GPyCLzZ02pOwsowMXgBxhZaaMr80dL_WUvDPKVyhJ2b1Hew@mail.gmail.com>
 <B47125EB-9593-48F4-95A9-EAC41CE0C6D1@archlinux.info>
Message-ID: <6255478.scC2KPkZ7x@caliban.sf-tec.de>

Am Donnerstag, 4. Februar 2016, 10:53:37 schrieb rpelapur at archlinux.info:
> I believe that doesn't have anything to do with C11 flags. You are just
> missing the link to the pthread library. I could be wrong.
> 
> Try and add this to your cmake file:
> find_package (Threads)

First:

> set(THREADS_PREFER_PTHREAD_FLAG TRUE)

Always set this if you don't need to be backwards compatible to some obscure 
old CMake code.

If you _need_ threads:

> find_package (Threads REQUIRED)

If it is not required, but optional, check THREADS_FOUND afterwards.

If you can require a CMake >= 3.1:

> target_link_libraries(mything Threads::Threads)

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/20160204/9ec340d1/attachment.sig>

From michael.stuermer at schaeffler.com  Fri Feb  5 02:12:52 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Fri, 5 Feb 2016 07:12:52 +0000
Subject: [CMake] CTest integration in Visual Studio TestExplorer
In-Reply-To: <20160204165122.92C05E4852@public.kitware.com>
References: <8459a300caa94947a53f9d35608174bc@DE013815.schaeffler.com>
 <20160204143400.43CBBE4CA4@public.kitware.com>
 <b71f3d52631c4dba8b0754f0b85b52aa@DE013666.schaeffler.com>
 <20160204165122.92C05E4852@public.kitware.com>
Message-ID: <df0363218e8a42f29199b74252e29a15@DE013666.schaeffler.com>

If you have a (example) CMake project which shows your error just let me know. I can have a quick look at it.

If you rebuild the ctest adapter with logging enabled, you should not have to recompile everything. Uninstalling the current and installing the recompiled vs extension should be enough. Once reloading your solution you should see some logging messages in the ?Test? and in the ?CTestAdapter? output window.

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of M?t? Ferenc Nagy-Egri via CMake
Sent: Thursday, February 04, 2016 5:51 PM
To: cmake at cmake.org
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer

Indeed, both RUN_TESTS and the CTest files exist, I have even found a file created by the add-in which seems to hold correct target names.

Recompiling will take some time, but will try to help with it.
________________________________
Felad?: Stuermer, Michael  SP/HZA-ZSEP<mailto:michael.stuermer at schaeffler.com>
Feladva: ?2016.?02.?04. 16:27
C?mzett: Nagy-Egri M?t? Ferenc<mailto:csiga.biga at aol.com>; cmake at cmake.org<mailto:cmake at cmake.org>
T?rgy: RE: CTest integration in Visual Studio TestExplorer
Hi M?t?,

thanks for trying the extension!

Some questions before going more into details:

-          do you have a CTestTestfile.cmake in your build root i.e. where the.sln file is you have opened with Visual Studio?

-          do you have a RUN_TESTS target/project in your visual studio solution? It could be in the ?CMakePredefinedTargets? folder?

The basic concept of test discovery for the plugin is, to look for a CTestTestfile.cmake file in the same folder where the .sln file is. From there all CTestTestfile.cmake files are searched recursively and all tests which are defined by add_test() within the files are added to the test list.

There are some debug logging lines in the plugin, but I deactivated them for now. Unfortunately there is no option-page where you can switch the logging on/off (should move that to the top of the feature list). You could get the sources from github, enable logging, build your custom version and see what message you get.

The changes would be in ?CTestExecutor.cs? (line 27) and ?CTestDiscoverer.cs? (line 29). Change the line

public bool EnableLogging { get; set; } = false;

to

public bool EnableLogging { get; set; } = true;

further comments inline.

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake
Sent: Thursday, February 04, 2016 3:33 PM
To: cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer


Hi Michael,

first of all, let me congratulate you on the integration. Great stuff and much apreciated.

I gave your add-in a spin, however it fails to find my unit tests. I set the output directory globally in the top-level CMakeLists.txt file as


set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})

[>] this should be perfectly OK, ctest should take care for itself where to find the binaries to execute when testing.

inside my unit-tests? file I have entries such as

# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})

?

# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )

[>] what do you mean by ?unit-test file?? Is it just another CMakeLists.txt or cmake script in your cmake script tree? or is this some script you run using ctest? I am not familiar with the ctest scripting options and I am pretty sure this is not supported by the extension right now. It is mainly thought to provide the tests which are executed by the RUN_TESTS target within the test explorer and allow more comfortable separate test running from within VS.

I have configured my build to use VS2015 Win64 platform. Because the default is to look for x86 targets, I changed the default test platform to be x64 within VS, but it still won?t find my tests. Could you give some directions what might I be doing wrong?

[>] AFAIK you don?t have to switch any

[Az eredeti ?zenetnek csak egy r?sze van beillesztve.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160205/5e60d947/attachment-0001.html>

From jan.hegewald at awi.de  Fri Feb  5 05:36:34 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Fri, 5 Feb 2016 11:36:34 +0100
Subject: [CMake] compiler independent compiler flags
Message-ID: <9ADDEE8B-BB2B-4311-841A-04DE5D02218E@awi.de>

Dear all,
do you know a best practice on how to specify compiler flags without knowing in advance which compiler will be used?
Its about Fortran projects, where I e.g. want to explicitly enable the preprocessor, or make all default real values 8 byte wide. This could be done as such:
if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")
  set(CMAKE_Fortran_FLAGS "-fpp -r8")
elseif(${CMAKE_Fortran_COMPILER_ID} STREQUAL "GNU")
  set(CMAKE_Fortran_FLAGS "-cpp -fdefault-real-8")
endif()

Cmake has the cmake-compile-features and I though maybe some similar mechanism exists for above mentioned compiler switches. So I could say
target_compile_features(mylib PRIVATE f_preprocessor f_real_8)

Thanks for sharing your advise,
Jan



From brad.king at kitware.com  Fri Feb  5 09:31:33 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 5 Feb 2016 09:31:33 -0500
Subject: [CMake] cmake 3.5.0-rc1 Error copying Fortran module
In-Reply-To: <fb5a5e9f00f24ac9a6d3957b7d66d420@EXG13-P-MBX09.win.lanl.gov>
References: <fb5a5e9f00f24ac9a6d3957b7d66d420@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <56B4B245.3040903@kitware.com>

On 02/04/2016 04:00 PM, Thompson, KT wrote:
> If I run ?make VERBOSE=1? with CMake-3.4.3, I see the following command:
> 
> cmake -E cmake_copy_f90_mod src/dir1/dir2/myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel
> 
> but with CMake-3.5.0-rc1, I have this command (notice that no path is
> provided for the filename (argument 3)):
> 
> cmake -E cmake_copy_f90_mod myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel

Thanks.  Here is a fix and a new test case:

 Fix dependency scanning configuration in subdirectories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5eb21b6

I've queued this for merge to 'release' for inclusion in 3.5.0-rc2.

-Brad


From kgt at lanl.gov  Fri Feb  5 11:16:23 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Fri, 5 Feb 2016 16:16:23 +0000
Subject: [CMake] cmake 3.5.0-rc1 Error copying Fortran module
In-Reply-To: <56B4B245.3040903@kitware.com>
References: <fb5a5e9f00f24ac9a6d3957b7d66d420@EXG13-P-MBX09.win.lanl.gov>
 <56B4B245.3040903@kitware.com>
Message-ID: <c888a5459a434b34bc67e9770c39a364@EXG13-P-MBX09.win.lanl.gov>

Brad,

I want to confirm that your patch below fixed the issue that I reported.

Thank you!

-kt

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Friday, February 05, 2016 7:32 AM
To: Thompson, KT <kgt at lanl.gov>
Cc: cmake at cmake.org; Stephen Kelly <steveire at gmail.com>
Subject: Re: [CMake] cmake 3.5.0-rc1 Error copying Fortran module

On 02/04/2016 04:00 PM, Thompson, KT wrote:
> If I run ?make VERBOSE=1? with CMake-3.4.3, I see the following command:
> 
> cmake -E cmake_copy_f90_mod src/dir1/dir2/myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel
> 
> but with CMake-3.5.0-rc1, I have this command (notice that no path is
> provided for the filename (argument 3)):
> 
> cmake -E cmake_copy_f90_mod myf90file src/dir1/dir2/CMakeFiles/Lib_FC_f90sub.dir/myf90file.mod.stamp Intel

Thanks.  Here is a fix and a new test case:

 Fix dependency scanning configuration in subdirectories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5eb21b6

I've queued this for merge to 'release' for inclusion in 3.5.0-rc2.

-Brad


From vadtec at vadtec.net  Fri Feb  5 13:57:13 2016
From: vadtec at vadtec.net (vadtec)
Date: Fri, 05 Feb 2016 12:57:13 -0600
Subject: [CMake] Help for a cmake newbie
In-Reply-To: <CAKohaZfZE0Yqu7sBX24gpztT+4X+Da7Do0WgVh11Z3AACkm=8A@mail.gmail.com>
References: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
 <CAKohaZfZE0Yqu7sBX24gpztT+4X+Da7Do0WgVh11Z3AACkm=8A@mail.gmail.com>
Message-ID: <152b2cb98f3.bf822b4d14626.8878679839894593298@vadtec.net>

Petr,

Thanks for the info. I'm working on getting the builds to work exactly like I want for both native *nix and cross-compile Windows builds, so it's a learning process. I do appreciate your info.

Vadtecvadtec at vadtec.net



---- On Thu, 04 Feb 2016 01:49:12 -0600 Petr Kmoch &lt;petr.kmoch at gmail.com&gt; wrote ---- 

Hi Vadtec.


*The* standard CMake way of dealing with building your dependencies is the ExternalProject module ( https://cmake.org/cmake/help/latest/module/ExternalProject.html ). It's a huge beast, but I belive there are some examples and tutorials available out there.


The gist is: you create a top-level, "superbuild" CMakeLists.txt file which will contain only the uses of ExternalProject_Add, one for each dependency, and *one for you own project as well.* The dependencies can be downloaded, patched, builtt, installed, etc., depending on the parameters you pass to ExternalProject_Add. They do not have to be CMake-based; when they are not, simply provide an empty (or otherwise project-specific) CONFIGURE_COMMAND argument.


When CMake is run on the superbuild, it generates a buildsystem such that building it downloads, builds, installs, etc. the external projects. All of this happens at build time, not at CMake time.


This way, you have full control over which dependencies you build in what order, where they get installed etc. Of course, in your case with dependency sources shipped, you don't need a download step (or perhaps maybe just to unpack them).


Once you've successfully built the superbuild once, all the dependencies are ready, and your own project (which you've set up as just another external project) is configured and all its dependencies are in locations which you've specified. Now you switch into the binary directory corresponding to your project and no longer need to work in the superbuild - each external project is self-contained in that it can be used directly as well, without having to go through the superbuild.


On a very symbolic level, an external project setup can look something like this:


root/CMakeLists.txt:

project(SuperBuild)

include(ExternalProject)


ExternalProject_Add(
  LibraryWeNeed
  PREFIX deps/LibraryWeNeed

  DOWNLOAD_COMMAND somehow_unpack ${CMAKE_CURRENT_SOURCE_DIR}/deps/LibraryWeNeed.tgz --into ${CMAKE_CURRENT_BINARY_DIR}/deps/LibraryWeNeed

  BUILD_COMMAND make whatever
  ...
)


ExternalProject_Add(

  MyProjectItself

  PREFIX mybuild

  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src

  DEPENDS LibraryWeNeed

  CMAKE_GENERATOR ${CMAKE_GENERATOR}  # use the same generator as the superbuild

  CMAKE_CACHE_ARGS -DLibraryWeNeed_ROOT:PATH=${CMAKE_CURRENT_BINARY_DIR}/deps/LibraryWeNeed
  ...
)



src/CMakeLists.txt:

project(MyProject)

find_package(LibraryWeNeed PATHS ${LibraryWeNeed_ROOT})  # the root path was passed in by the superbuild

...



To work with this, you would then do:


cd build

cmake ../root  # generates superbuild

make  # builds superbuild

cd mybuild  # go into MyProject's binary dir

make  # builds MyProject



Once more, this is all very symbolic. Please refer to documentation, tutorials etc. to achieve the behaviour you need.


Petr








On Sun, Jan 31, 2016 at 3:42 AM, vadtec &lt;vadtec at vadtec.net&gt; wrote:
Let me start by saying I consider my self a cmake newbie. I've made simple makefiles and simple cmake files, but anything more complicated has to this point eluded me. Not for a lack of trying, searching, researching, trail, and a great deal of error: I simply have not been able to achieve the things I'm after. If the sort of questions I'm asking have been answered elsewhere (as I'm sure they have), I apologize for asking them again. That being said, I realize I'm going to be asking some questions that my Google-Fu has failed me in answering. Forgive me my failings, but I'm at my witts end.




I have a project that I'm building on Linux that has a server component and a client component that also needs to run on Windows. It uses several libraries that I want to version lock so I run into fewer issues with cross compiling and feature creep.


The project is laid out like this:


/home
    mydir/
        project/
            build/
            bundle/
            deps/
                curl-7.43.0/
                libiconv-1.14/
                libpng-1.6.18/
                libssh2-1.6.0/
                openssl-1.0.2d/
                sqlite/
                tinycthread/
                zlib-1.2.8/
            include/
                client/
                    client.h
                common/
                    config.h
                    common_funcs.h
                server/
                    server.h
            src/
                client/
                    client.c
                common/
                    common_funcs.c
                server/
                    server.c


curl, libiconv, libpng, libssh2, and zlib are the libs I want to build and use both on Linux and Windows. I know all of those are available on Linux and I could use the system installed versions, but I want to use the same vesions on Windows as well. The server is only built on Linux, while the client needs to be built for Linux and Windows. All the libs, headers, etc go into the build directory, and the final "make install" puts everything into the bundle directory, so it can be packaged for distribution.


The client needs the curl, libiconv, libpng, libssh2, openssl, and zlib libraries. tinycthread is compiled directly into the client, so that's not an issue.


The server needs the curl, libiconv, libssh2, openssl, and zlib libraries. tinycthread and sqlie are compiled directly into the server, so that's not an issue.


Ideally, I'd like my cmake file to build the deps that need to be built, build the server and client for Linux, and finally build the client for Windows. Yes, all from the same cmake file. I realize this will probably have to be done with multiple cmake files or a bash script, but that's ok.


I think building the libs can be done with custom commands or targets, but I haven't been able to figure out how. I haven't been able to get cmake to use only my versions of the libs I've compiled. Some of the libs are being found from the system wide versions, some are coming from my directory.


My main problem is getting cmake to use only my locally installed/compiled copies of the libs. I need those libs to live along side the binaries, and using the versions I compile is important.


Rather than provide the CMakeLists.txt I've been using, I'd like it if someone could provide an example file that would compile the above libraries (all of which use autoconf or custom compile scripts) and the client and server for Linux and Windows. I'm 100% certain I am not doing things correctly when it comes to the layout of the CMakeLists.txt, so I'd like to see something fresh from someone with much more experience in build script creation.


Any help is greatly appreciated.

Vadtecvadtec at vadtec.net




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



 




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

From daviddoria at gmail.com  Fri Feb  5 14:58:17 2016
From: daviddoria at gmail.com (David Doria)
Date: Fri, 5 Feb 2016 13:58:17 -0600
Subject: [CMake] Running TEST_P from GTest with CMake
Message-ID: <CABDpjTkqMDOKrXF+pozW4dJWS_9Tq+t9uasMhyqrgbDnHFQoZQ@mail.gmail.com>

I have been successfully using CMake's GTEST_ADD_TESTS to run GTest
TEST and TEST_F blocks defined in a source file. However, I now need
to pass some arguments (filenames that I want CMake to produce
including things like ${CMAKE_SOURCE_DIR}) to the GTests, and it seems
like the way to do this is with INSTANTIATE_TEST_CASE_P that calls
TEST_P blocks with a list of parameters. It seems like GTEST_ADD_TESTS
does not handle this. Does anyone know how to do something like this
through CMake?

Thanks,

David

From jamesbigler at gmail.com  Fri Feb  5 16:15:32 2016
From: jamesbigler at gmail.com (James Bigler)
Date: Fri, 05 Feb 2016 21:15:32 +0000
Subject: [CMake] get_filename_component(var "" ABSOLUTE)
Message-ID: <CA+77nZATDj4uzCsm4T6mV6ARefRta+VP+HiFq6yOOwewP=rj6g@mail.gmail.com>

If I specify an empty value for filename, I get the behavior of relative
path, and var turns into CMAKE_CURRENT_SOURCE_DIR.  It seems like if I put
an empty file I should get back an empty output.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160205/874caa77/attachment.html>

From gjasny at googlemail.com  Sat Feb  6 05:49:07 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Sat, 6 Feb 2016 11:49:07 +0100
Subject: [CMake] Drop support for older Xcode versions?
Message-ID: <56B5CFA3.5090107@googlemail.com>

Hello,

I'd like to get your feedback on deprecating or dropping support for
older Xcode versions. During changes on the Xcode generator it gets
harder and harder to test against old and very old Xcode versions like 3
and 4.

Are there still users around for these versions of Xcode?

PS: I'm talking here about the Xcode generator which creates Xcode
projects, not the Makefile or Ninja generator.

Thanks,
Gregor

From ewmailing at gmail.com  Sat Feb  6 18:46:35 2016
From: ewmailing at gmail.com (Eric Wing)
Date: Sat, 6 Feb 2016 15:46:35 -0800
Subject: [CMake] [cmake-developers] Drop support for older Xcode
	versions?
In-Reply-To: <56B5CFA3.5090107@googlemail.com>
References: <56B5CFA3.5090107@googlemail.com>
Message-ID: <CA+Q62MDBB+SGJjyVEmciWJAPvGsJMHx9ED7+GOSQ7mO==h7v=A@mail.gmail.com>

On 2/6/16, Gregor Jasny via cmake-developers <cmake-developers at cmake.org> wrote:
> Hello,
>
> I'd like to get your feedback on deprecating or dropping support for
> older Xcode versions. During changes on the Xcode generator it gets
> harder and harder to test against old and very old Xcode versions like 3
> and 4.
>
> Are there still users around for these versions of Xcode?
>
> PS: I'm talking here about the Xcode generator which creates Xcode
> projects, not the Makefile or Ninja generator.
>
> Thanks,
> Gregor
> --
>

I personally am not using them. My more serious problem is that the
Xcode projects being generated now are not keeping up with modern
Xcode and the features that need to be accessible/set. The reality of
Apple development is you must be on the latest stable Xcode if you
need to ship apps on the Mac or iOS Store, otherwise Apple can reject
your app. Their design philosophy, regardless if you agree with it or
not, is to build with the latest and build against backwards
compatibility deployment targets, not build with the oldest and pray
it will work with future changes that couldn't be predicted at the
time. Their platform, their rules.

So I'm all in favor of dropping legacy platforms if it means
ultimately helping make the Xcode generator work better for modern
Xcode. General rule of thumb for Apple development is support the
latest and -1 version. If you can do more, fine, but don't compromise
the recent stuff in order to achieve distant backwards compatibility.

-Eric

From vadtec at vadtec.net  Sun Feb  7 00:47:06 2016
From: vadtec at vadtec.net (vadtec)
Date: Sat, 06 Feb 2016 23:47:06 -0600
Subject: [CMake] ExternalProject question
Message-ID: <152ba44f207.124ba66cc39510.7778235151162135921@vadtec.net>

I'm using ExternalProject to build external dependencies. curl provides a cmake build process, but I cannot figure out how to pass options such as:

--disable-manual --disable-shared --without-librtmp --without-libidn --without-winidn --without-winssl --disable-ldap --disable-ldaps --enable-ipv6 --enable-threaded-resolver --enable-cookies --enable-static


to the build process. The only way I've found to get it to work is to use a custom CONFIGURE_COMMAND and related steps. I would prefer to use the cmake build process.


This is what I have that works:


ExternalProject_Add(
    CURL
    DEPENDS OPENSSL ZLIB OPENSSH
    SOURCE_DIR ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
    PREFIX ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
    DOWNLOAD_COMMAND tar xvjf ${PROJECT_BINARY_DIR}/deps/curl-7.43.0.tar.bz2
    DOWNLOAD_DIR ${PROJECT_BINARY_DIR}/deps/
    CONFIGURE_COMMAND cd ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/ &amp;&amp; ./configure --prefix=${PROJECT_BINARY_DIR}/deps/binary/linux/ --disable-manual --disable-shared --without-librtmp --without-libidn --without-winidn --without-winssl --disable-ldap --disable-ldaps --enable-ipv6 --enable-threaded-resolver --enable-cookies --enable-static
    BUILD_COMMAND cd ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/ &amp;&amp; make
    INSTALL_COMMAND ""
)



I want to use this, so that cmake can do its thing while still giving me the specific variant of curl I want:


ExternalProject_Add(
    CURL
    DEPENDS OPENSSL ZLIB OPENSSH
    SOURCE_DIR ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
    PREFIX ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
    DOWNLOAD_COMMAND tar xvjf ${PROJECT_BINARY_DIR}/deps/curl-7.43.0.tar.bz2
    DOWNLOAD_DIR ${PROJECT_BINARY_DIR}/deps/
    CMAKE_ARGS
        -DCMAKE_INSTALL_PREFIX=${PROJECT_BINARY_DIR}/deps/binary/linux/
        -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}
        -DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}
        -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
        -DCMAKE_MOUDLE_PATH=${MAKE_MOUDLE_PATH}
    INSTALL_COMMAND ""
)


Vadtecvadtec at vadtec.net




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

From mike.jackson at bluequartz.net  Sun Feb  7 13:54:25 2016
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Sun, 07 Feb 2016 13:54:25 -0500
Subject: [CMake] [cmake-developers] Drop support for older Xcode
	versions?
In-Reply-To: <CA+Q62MDBB+SGJjyVEmciWJAPvGsJMHx9ED7+GOSQ7mO==h7v=A@mail.gmail.com>
References: <56B5CFA3.5090107@googlemail.com>
 <CA+Q62MDBB+SGJjyVEmciWJAPvGsJMHx9ED7+GOSQ7mO==h7v=A@mail.gmail.com>
Message-ID: <56B792E1.9070004@bluequartz.net>

What is the oldest version of OS X that CMake actually runs on? I guess 
I would support the last version of Xcode that actually ran on that 
platform. In reality this is probably 10.6.8? But At the next major 
update of CMake (3.5 or 3.6) I would actually draw a line in the sand 
and pump that up to OS X 10.9, 10.8 at the absolute minimum. I think 
that is Xcode 6?

Just my thoughts.

Mike Jackson

> Eric Wing <mailto:ewmailing at gmail.com>
> February 6, 2016 at 6:46 PMvia Postbox 
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
> I personally am not using them. My more serious problem is that the
> Xcode projects being generated now are not keeping up with modern
> Xcode and the features that need to be accessible/set. The reality of
> Apple development is you must be on the latest stable Xcode if you
> need to ship apps on the Mac or iOS Store, otherwise Apple can reject
> your app. Their design philosophy, regardless if you agree with it or
> not, is to build with the latest and build against backwards
> compatibility deployment targets, not build with the oldest and pray
> it will work with future changes that couldn't be predicted at the
> time. Their platform, their rules.
>
> So I'm all in favor of dropping legacy platforms if it means
> ultimately helping make the Xcode generator work better for modern
> Xcode. General rule of thumb for Apple development is support the
> latest and -1 version. If you can do more, fine, but don't compromise
> the recent stuff in order to achieve distant backwards compatibility.
>
> -Eric
> Gregor Jasny via CMake <mailto:cmake at cmake.org>
> February 6, 2016 at 5:49 AMvia Postbox 
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
> Hello,
>
> I'd like to get your feedback on deprecating or dropping support for
> older Xcode versions. During changes on the Xcode generator it gets
> harder and harder to test against old and very old Xcode versions like 3
> and 4.
>
> Are there still users around for these versions of Xcode?
>
> PS: I'm talking here about the Xcode generator which creates Xcode
> projects, not the Makefile or Ninja generator.
>
> Thanks,
> Gregor

-- 
Michael A. Jackson                     400 S. Pioneer Blvd
Owner, President                       Springboro, Ohio 45066
BlueQuartz Software, LLC               EMail: mike.jackson at bluequartz.net
Voice: 937-806-1165                    Web: http://www.bluequartz.net
Fax: 
937-746-0783<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160207/27c63128/attachment.html>

From nicholas11braden at gmail.com  Sun Feb  7 14:10:30 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Sun, 7 Feb 2016 13:10:30 -0600
Subject: [CMake] ExternalProject question
In-Reply-To: <152ba44f207.124ba66cc39510.7778235151162135921@vadtec.net>
References: <152ba44f207.124ba66cc39510.7778235151162135921@vadtec.net>
Message-ID: <CAHk1PgF4wTmQqAngfLumKXfSMsryGAmTnFgohqRP9XVHWqenPw@mail.gmail.com>

You will need to look at their building documentation to find how to
set those preferences when building with CMake.

On Sat, Feb 6, 2016 at 11:47 PM, vadtec <vadtec at vadtec.net> wrote:
> I'm using ExternalProject to build external dependencies. curl provides a
> cmake build process, but I cannot figure out how to pass options such as:
>
> --disable-manual --disable-shared --without-librtmp --without-libidn
> --without-winidn --without-winssl --disable-ldap --disable-ldaps
> --enable-ipv6 --enable-threaded-resolver --enable-cookies --enable-static
>
> to the build process. The only way I've found to get it to work is to use a
> custom CONFIGURE_COMMAND and related steps. I would prefer to use the cmake
> build process.
>
> This is what I have that works:
>
> ExternalProject_Add(
>     CURL
>     DEPENDS OPENSSL ZLIB OPENSSH
>     SOURCE_DIR ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
>     PREFIX ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
>     DOWNLOAD_COMMAND tar xvjf ${PROJECT_BINARY_DIR}/deps/curl-7.43.0.tar.bz2
>     DOWNLOAD_DIR ${PROJECT_BINARY_DIR}/deps/
>     CONFIGURE_COMMAND cd ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/ &&
> ./configure --prefix=${PROJECT_BINARY_DIR}/deps/binary/linux/
> --disable-manual --disable-shared --without-librtmp --without-libidn
> --without-winidn --without-winssl --disable-ldap --disable-ldaps
> --enable-ipv6 --enable-threaded-resolver --enable-cookies --enable-static
>     BUILD_COMMAND cd ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/ && make
>     INSTALL_COMMAND ""
> )
>
> I want to use this, so that cmake can do its thing while still giving me the
> specific variant of curl I want:
>
> ExternalProject_Add(
>     CURL
>     DEPENDS OPENSSL ZLIB OPENSSH
>     SOURCE_DIR ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
>     PREFIX ${PROJECT_BINARY_DIR}/deps/curl-7.43.0/
>     DOWNLOAD_COMMAND tar xvjf ${PROJECT_BINARY_DIR}/deps/curl-7.43.0.tar.bz2
>     DOWNLOAD_DIR ${PROJECT_BINARY_DIR}/deps/
>     CMAKE_ARGS
>         -DCMAKE_INSTALL_PREFIX=${PROJECT_BINARY_DIR}/deps/binary/linux/
>         -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}
>         -DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}
>         -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
>         -DCMAKE_MOUDLE_PATH=${MAKE_MOUDLE_PATH}
>     INSTALL_COMMAND ""
> )
>
> ________________________________
> Vadtec
> vadtec at vadtec.net
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From orcein at gmail.com  Sun Feb  7 20:10:28 2016
From: orcein at gmail.com (B. Scott Harper)
Date: Mon, 8 Feb 2016 10:10:28 +0900
Subject: [CMake] Find correct boost among peers
Message-ID: <CANhzt0FKzvhzWTiYy8kLgq-UP1xvNH3Ftyi8Ag4qsi515Bh+7w@mail.gmail.com>

I have several versions of boost downloaded on my machine inside a
"thirdparty" directory. Different projects rely on various versions.

I am trying to find a later version than the first version in that
collection. I have gotten the closest by using a file(GLOB ...) as follows:

file(GLOB BOOST_ROOT ${THIRD_PARTY_DIR}/boost_*)
find_package(Boost
  1.60.0
  REQUIRED)

...but if I have any versions of Boost earlier than 1.60.0 in this case, it
will find only the first directory, recognize that it's too early, and bail
out without trying any other directories.

When I print out the results of the GLOB action using message(STATUS "Boost
root: " ${BOOST_ROOT}), I don't see any delimiters in the string, and I
wonder if this it causing the problem? Is this expected beahiour or am I
using this incorrectly?

Cheers,
-- Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160208/0c185519/attachment.html>

From petr.kmoch at gmail.com  Mon Feb  8 03:46:00 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 8 Feb 2016 09:46:00 +0100
Subject: [CMake] Find correct boost among peers
In-Reply-To: <CANhzt0FKzvhzWTiYy8kLgq-UP1xvNH3Ftyi8Ag4qsi515Bh+7w@mail.gmail.com>
References: <CANhzt0FKzvhzWTiYy8kLgq-UP1xvNH3Ftyi8Ag4qsi515Bh+7w@mail.gmail.com>
Message-ID: <CAKohaZcDRMpGtBZyy4v9PXWD5Aowf3Z4CjV0W8PFLQYe5mnXVw@mail.gmail.com>

Hi Scott.

Regarding the delimiters: you'd see them if you included the dereference in
the quotes: "Boost root: ${BOOST_ROOT}". When outside quotes, the
delimiters are effectively swallowed up by message().

Regarding the main issue: I could be wrong, but from a quick glance at the
FindBoost.cmake module, it seems to me that it doesn't expect BOOST_ROOT to
contain more than one path. If it doesn't work for you without these hints,
you will maybe need to pass them in a different form. I cannot suggest one,
though; I am not versed enough in the FindBoost module.

Petr

On Mon, Feb 8, 2016 at 2:10 AM, B. Scott Harper <orcein at gmail.com> wrote:

> I have several versions of boost downloaded on my machine inside a
> "thirdparty" directory. Different projects rely on various versions.
>
> I am trying to find a later version than the first version in that
> collection. I have gotten the closest by using a file(GLOB ...) as follows:
>
> file(GLOB BOOST_ROOT ${THIRD_PARTY_DIR}/boost_*)
> find_package(Boost
>   1.60.0
>   REQUIRED)
>
> ...but if I have any versions of Boost earlier than 1.60.0 in this case,
> it will find only the first directory, recognize that it's too early, and
> bail out without trying any other directories.
>
> When I print out the results of the GLOB action using message(STATUS
> "Boost root: " ${BOOST_ROOT}), I don't see any delimiters in the string,
> and I wonder if this it causing the problem? Is this expected beahiour or
> am I using this incorrectly?
>
> Cheers,
> -- Scott
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160208/43d3e1b7/attachment-0001.html>

From laasunde at hotmail.com  Mon Feb  8 04:02:54 2016
From: laasunde at hotmail.com (Lars)
Date: Mon, 8 Feb 2016 10:02:54 +0100
Subject: [CMake] cmake env - no command given
Message-ID: <DUB128-W877630E4579CFF66ED41A8CAD50@phx.gbl>

Hello,
 
Using Windows 7 SP1 and cmake 3.3.0
 
The first command below works (starts calc) when execute in cmd shell. The second command produces the error message "cmake -E env: no command given". Is this a bug in cmake?
 
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E env "PATH=C:\temp" calc
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E env "PATH=C:\temp\" calc
 
 
regards, Lars
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160208/a056f976/attachment.html>

From petr.kmoch at gmail.com  Mon Feb  8 04:14:12 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 8 Feb 2016 10:14:12 +0100
Subject: [CMake] cmake env - no command given
In-Reply-To: <DUB128-W877630E4579CFF66ED41A8CAD50@phx.gbl>
References: <DUB128-W877630E4579CFF66ED41A8CAD50@phx.gbl>
Message-ID: <CAKohaZfCYQ65A3tvoHw_-sb-DxCR6U-JeUCeb8RJoRGyOqtYVw@mail.gmail.com>

Hi Lars.

No, that's a "bug" in your command-line. In cmd, the caret ^ is used as a
general escape character for escaping spaces, pipes etc. But to escape
quotes, a backslash \ is used (yes, the escaping rules in cmd are weird).
So the backslash preceding the quote is taken by cmd to be an escape
character, and the quote becomes a literal quote character instead of
terminating the argument. You're left without a closing quote, which cmd
apparently auto-fill, so you end up passing the string `PATH=C:\temp" calc`
as one argument, and no other argument.

If you need the backslash before the quote, you need to double it:

"C:\Program Files (x86)\CMake\bin\cmake.exe" -E env "PATH=C:\temp\\" calc

Petr

On Mon, Feb 8, 2016 at 10:02 AM, Lars <laasunde at hotmail.com> wrote:

> Hello,
>
> Using Windows 7 SP1 and cmake 3.3.0
>
> The first command below works (starts calc) when execute in cmd shell. The
> second command produces the error message "cmake -E env: no command given".
> Is this a bug in cmake?
>
> "C:\Program Files (x86)\CMake\bin\cmake.exe" -E env "PATH=C:\temp" calc
> "C:\Program Files (x86)\CMake\bin\cmake.exe" -E env "PATH=C:\temp\" calc
>
>
> regards, Lars
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160208/4513320d/attachment.html>

From pip010 at gmail.com  Mon Feb  8 05:48:26 2016
From: pip010 at gmail.com (Petar Petrov)
Date: Mon, 8 Feb 2016 11:48:26 +0100
Subject: [CMake] Qt5 + cmake = SLOW moc.exe
Message-ID: <CAFr3Oa=9Xziv=jvmwngGgXeB-jLs3yMZMCFXJoumGGX6kfVw6g@mail.gmail.com>

hello cmake community, just re-pasting what I've already posted on Qt
forums:



I'am experiencing some abysmal compilation time when it comes to building a
relatively small Qt5 app in windows.

The problem resembles alot the reported here issue :
http://lists.qt-project.org/pipermail/interest/2015-January/014812.html

In case one uses cmake+qt5 to build on windows and have additional projects
(in my case VTK/ITK/Boost)
moc.exe will go first over all visible to cmake paths, some windows ones,
then finally in C:/Qt to find its headers.
So for generating one cpp file from moc.exe I end up with a few million IO
operations! ine can use procmon.exe to inspect moc.exe on windows.
Rebuilding from scratch takes ages compared to what takes <5min before
switching to Qt :((((

MOC cannot go in parallel (pre-processor!!!)

at that point I'm faced with a few options to explore, however I expect
something of official HOW-TO on cmake+qt integration.

It might be a Qt5 or/and Cmake issue, hard to tell, since I'm not expert in
either.

Can someone with more inside take a look please !?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160208/aad0afb4/attachment.html>

From vleschuk at gmail.com  Mon Feb  8 07:56:16 2016
From: vleschuk at gmail.com (Victor Leschuk)
Date: Mon, 8 Feb 2016 15:56:16 +0300
Subject: [CMake] Question on usage of cmake on Windows with clang
Message-ID: <56B89070.9000207@gmail.com>

Hello, I am trying to use clang with cmake on Windows.

I have compiled LLVM+clang using Visual Studio 2015. And now I am facing 
problems with building cmake projects using this clang. It looks like 
cmake is trying to pass wrong options to linker.

Here simple test project:

$ cat CMakeLists.txt
project(test_proj)
add_executable(test
         test.cpp
)

$ cat test.cpp
#include <cstdio>

int main() {
         printf("Hi there\n");
}

I am trying to build it using the following command:

$ cmake .. -G "Ninja" -DCMAKE_C_COMPILER=clang 
-DCMAKE_CXX_COMPILER=clang -DCMAKE_C_COMPILER_ID=Clang 
-DCMAKE_CXX_COMPILER_ID=Clang

And it fails with the error:

   Run Build Command:"C:/ninja/ninja.exe" "cmTC_a2e93"

   [1/2] Building C object CMakeFiles\cmTC_a2e93.dir\testCCompiler.c.obj

   [2/2] Linking C executable cmTC_a2e93.exe

   FAILED: cmd.exe /C "cd .  && C:\Users\del\work\llvm\bin\clang.exe
   CMakeFiles\cmTC_a2e93.dir\testCCompiler.c.obj -o cmTC_a2e93.exe
   -Wl,--out-implib,libcmTC_a2e93.dll.a
   -Wl,--major-image-version,0,--minor-image-version,0 && cd ."

   LINK : warning LNK4044: unrecognized option '/-out-implib'; ignored

   LINK : warning LNK4044: unrecognized option '/-major-image-version';
   ignored

   LINK : warning LNK4044: unrecognized option '/-minor-image-version';
   ignored

   LINK : fatal error LNK1181: cannot open input file 'libcmTC_a2e93.dll.a'

   clang.exe: error: linker command failed with exit code 1181 (use -v 
to see
   invocation)

   ninja: build stopped: subcommand failed.

Here are the details on environment:

os: Windows 7 (64bit)

$ clang --version
clang version 3.9.0
Target: i686-pc-windows-msvc
Thread model: posix

$ cmake --version
cmake version 3.5.0-rc1

It would be great if someone could point me to what am I doing wrong?

Thanks in advance!

-- 
Best Regards,
Victor


From cristian.adam at gmail.com  Mon Feb  8 08:06:22 2016
From: cristian.adam at gmail.com (Cristian Adam)
Date: Mon, 8 Feb 2016 14:06:22 +0100
Subject: [CMake] Question on usage of cmake on Windows with clang
In-Reply-To: <56B89070.9000207@gmail.com>
References: <56B89070.9000207@gmail.com>
Message-ID: <CA+u+m-KE-P+bQB0cBymLiQdJeAv96+=PJXBeUJkJNFvBmrzA_Q@mail.gmail.com>

On Mon, Feb 8, 2016 at 1:56 PM, Victor Leschuk <vleschuk at gmail.com> wrote:

> Hello, I am trying to use clang with cmake on Windows.
>
> I have compiled LLVM+clang using Visual Studio 2015. And now I am facing
> problems with building cmake projects using this clang. It looks like cmake
> is trying to pass wrong options to linker.
>
> os: Windows 7 (64bit)
>
> $ clang --version
> clang version 3.9.0
> Target: i686-pc-windows-msvc
> Thread model: posix
>
> $ cmake --version
> cmake version 3.5.0-rc1
>
> It would be great if someone could point me to what am I doing wrong?
>
> Thanks in advance!
>

Did you build also libc++? Which CRT does clang 3.9.0 use on Windows?

Clang officially offers the clang-cl driver, which is a Visual C++ cl.exe
replacement.

The following works with Clang 3.7.0 and Visual C++ 2013 (should also work
with Clang 3.9 and Visual C++ 2015):

1. Open Visual C++ command prompt window
2. Set INCLUDE and PATH to the clang-cl
    set PATH=C:\Program Files (x86)\LLVM\msbuild-bin\;%PATH%
    set INCLUDE=C:\Program Files
(x86)\LLVM\lib\clang\3.7.0\include\;%INCLUDE%
3. cmake -G "Ninja" will pick clang-cl and should build and link just fine.

HTH,
Cristian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160208/26e3a0ce/attachment.html>

From Matthew.Johnson1 at med.ge.com  Mon Feb  8 08:09:43 2016
From: Matthew.Johnson1 at med.ge.com (Johnson, Matt (GE Healthcare))
Date: Mon, 8 Feb 2016 13:09:43 +0000
Subject: [CMake] Find correct boost among peers
Message-ID: <BE73B6714FF4E843992984FDF5B6EA022745B461@CINURCNA05.e2k.ad.ge.com>

Scott,

Rather than having the versions fight one another in BOOST_ROOT, you might consider modifying the CMAKE_PREFIX_PATH to include the versions of boost you have - find_package will search there first (you might be able with just giving it the parent of the boost version).  If you set the version and EXACT in the find_package call,  each project should be able to find its version.

You may also want to look at Boost_NO_SYSTEM_PATHS to ensure the FindBoost module isn't hunting around in  places you don't intend.
 
mj

> Date: Mon, 8 Feb 2016 09:46:00 +0100
> From: Petr Kmoch <petr.kmoch at gmail.com>
> To: "B. Scott Harper" <orcein at gmail.com>
> Cc: "cmake at cmake.org" <cmake at cmake.org>
> Subject: Re: [CMake] Find correct boost among peers
> Message-ID:
> 	<CAKohaZcDRMpGtBZyy4v9PXWD5Aowf3Z4CjV0W8PFLQYe5mnXVw
> @mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Scott.
> 
> Regarding the delimiters: you'd see them if you included the dereference in
> the quotes: "Boost root: ${BOOST_ROOT}". When outside quotes, the
> delimiters are effectively swallowed up by message().
> 
> Regarding the main issue: I could be wrong, but from a quick glance at the
> FindBoost.cmake module, it seems to me that it doesn't expect
> BOOST_ROOT to contain more than one path. If it doesn't work for you
> without these hints, you will maybe need to pass them in a different form. I
> cannot suggest one, though; I am not versed enough in the FindBoost
> module.
> 
> Petr
> 
> On Mon, Feb 8, 2016 at 2:10 AM, B. Scott Harper <orcein at gmail.com> wrote:
> 
> > I have several versions of boost downloaded on my machine inside a
> > "thirdparty" directory. Different projects rely on various versions.
> >
> > I am trying to find a later version than the first version in that
> > collection. I have gotten the closest by using a file(GLOB ...) as follows:
> >
> > file(GLOB BOOST_ROOT ${THIRD_PARTY_DIR}/boost_*)
> find_package(Boost
> >   1.60.0
> >   REQUIRED)
> >
> > ...but if I have any versions of Boost earlier than 1.60.0 in this
> > case, it will find only the first directory, recognize that it's too
> > early, and bail out without trying any other directories.
> >
> > When I print out the results of the GLOB action using message(STATUS
> > "Boost root: " ${BOOST_ROOT}), I don't see any delimiters in the
> > string, and I wonder if this it causing the problem? Is this expected
> > beahiour or am I using this incorrectly?
> >
> > Cheers,
> > -- Scott
> >

From sean at rogue-research.com  Mon Feb  8 10:21:21 2016
From: sean at rogue-research.com (Sean McBride)
Date: Mon, 8 Feb 2016 10:21:21 -0500
Subject: [CMake] [cmake-developers] Drop support for older Xcode
	versions?
In-Reply-To: <56B5CFA3.5090107@googlemail.com>
References: <56B5CFA3.5090107@googlemail.com>
Message-ID: <20160208152121.1630645796@mail.rogue-research.com>

On Sat, 6 Feb 2016 11:49:07 +0100, Gregor Jasny via cmake-developers said:

>I'd like to get your feedback on deprecating or dropping support for
>older Xcode versions. During changes on the Xcode generator it gets
>harder and harder to test against old and very old Xcode versions like 3
>and 4.
>
>Are there still users around for these versions of Xcode?

Wikipedia has a nice table of Xcode & OS X:

<https://en.wikipedia.org/wiki/Xcode#Version_comparison_table>

The problem with supporting only current - 1 as Eric suggests is that also excludes older versions of OS X, see the 'min OS X to run' column.

What's the oldest version of Xcode that CMake currently supports?

Personally, I think supporting Xcode 5.0+ would be reasonable at this point.  It was released about 2.5 years ago and can run on OS X 10.8.

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From brad.king at kitware.com  Mon Feb  8 10:31:17 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 8 Feb 2016 10:31:17 -0500
Subject: [CMake] [cmake-developers] Drop support for older Xcode
	versions?
In-Reply-To: <20160208152121.1630645796@mail.rogue-research.com>
References: <56B5CFA3.5090107@googlemail.com>
 <20160208152121.1630645796@mail.rogue-research.com>
Message-ID: <56B8B4C5.9090806@kitware.com>

On 02/07/2016 01:54 PM, Michael Jackson wrote:
>> What is the oldest version of OS X that CMake actually runs on?
>> I guess I would support the last version of Xcode that actually
>> ran on that platform. In reality this is probably 10.6.8?
[snip]
On 02/08/2016 10:21 AM, Sean McBride wrote:
> What's the oldest version of Xcode that CMake currently supports?

We still have nightly testing on OS X 10.4 with Xcode 2.5.  It was
in support of the i386/ppc universal release binary but that was
dropped as of CMake 3.4.  Now it is really only "just in case" and
because the machine running the tests has not died yet.  I'm not
opposed to dropping Xcode generator support for it since anyone
with such an old machine can always use the makefile generator.

Sean, it looks like you are still running nightly tests on OS X
10.6 with Xcode 4.2:

  https://open.cdash.org/viewNotes.php?buildid=4226138

and OS X 10.5 with Xcode 3.1:

  https://open.cdash.org/viewNotes.php?buildid=4226202

but perhaps do not need the actual Xcode IDE generator to work.

> Personally, I think supporting Xcode 5.0+ would be reasonable at this point.
> It was released about 2.5 years ago and can run on OS X 10.8.

Given Apple's encouragement of developers to always update I think
that would be reasonable for the Xcode IDE generator.  Xcode older
than 6 or so will not even run on OS X 10.11.  Let's give this
thread a while to see if anyone else has feedback.

Thanks,
-Brad


From brad.king at kitware.com  Mon Feb  8 10:31:21 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 8 Feb 2016 10:31:21 -0500
Subject: [CMake] [cmake-developers] Drop support for older Xcode
	versions?
In-Reply-To: <20160208152121.1630645796@mail.rogue-research.com>
References: <56B5CFA3.5090107@googlemail.com>
 <20160208152121.1630645796@mail.rogue-research.com>
Message-ID: <56B8B4C9.1070502@kitware.com>

On 02/07/2016 01:54 PM, Michael Jackson wrote:
>> What is the oldest version of OS X that CMake actually runs on?
>> I guess I would support the last version of Xcode that actually
>> ran on that platform. In reality this is probably 10.6.8?
[snip]
On 02/08/2016 10:21 AM, Sean McBride wrote:
> What's the oldest version of Xcode that CMake currently supports?

We still have nightly testing on OS X 10.4 with Xcode 2.5.  It was
in support of the i386/ppc universal release binary but that was
dropped as of CMake 3.4.  Now it is really only "just in case" and
because the machine running the tests has not died yet.  I'm not
opposed to dropping Xcode generator support for it since anyone
with such an old machine can always use the makefile generator.

Sean, it looks like you are still running nightly tests on OS X
10.6 with Xcode 4.2:

  https://open.cdash.org/viewNotes.php?buildid=4226138

and OS X 10.5 with Xcode 3.1:

  https://open.cdash.org/viewNotes.php?buildid=4226202

but perhaps do not need the actual Xcode IDE generator to work.

> Personally, I think supporting Xcode 5.0+ would be reasonable at this point.
> It was released about 2.5 years ago and can run on OS X 10.8.

Given Apple's encouragement of developers to always update I think
that would be reasonable for the Xcode IDE generator.  Xcode older
than 6 or so will not even run on OS X 10.11.  Let's give this
thread a while to see if anyone else has feedback.

Thanks,
-Brad


From sean at rogue-research.com  Mon Feb  8 10:48:30 2016
From: sean at rogue-research.com (Sean McBride)
Date: Mon, 8 Feb 2016 10:48:30 -0500
Subject: [CMake] [cmake-developers] Drop support for older Xcode
	versions?
In-Reply-To: <56B8B4C5.9090806@kitware.com>
References: <56B5CFA3.5090107@googlemail.com>
 <20160208152121.1630645796@mail.rogue-research.com>
 <56B8B4C5.9090806@kitware.com>
Message-ID: <20160208154830.1125542189@mail.rogue-research.com>

On Mon, 8 Feb 2016 10:31:17 -0500, Brad King said:

>Sean, it looks like you are still running nightly tests on OS X
>10.6 with Xcode 4.2:
>
>  https://open.cdash.org/viewNotes.php?buildid=4226138
>
>and OS X 10.5 with Xcode 3.1:
>
>  https://open.cdash.org/viewNotes.php?buildid=4226202

Yeah, mostly because those machines haven't died either. :)  If/when it's decided to drop those Xcodes, I'll switch those builds to makefile generator.

>Given Apple's encouragement of developers to always update...

They certainly do, as Eric described.  However, just like everyone else, Apple often ships regressions in Xcode and it's sometimes vital to be able to use older versions.  Similarly, if you want to deploy an app to an older OS, it's very useful to be able to build-run-debug on that OS, and since the newest Xcodes only run on the newest OSes, one needs an older Xcode to test/debug on older OSes.

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From alain.miniussi at oca.eu  Mon Feb  8 12:43:41 2016
From: alain.miniussi at oca.eu (Alain Miniussi)
Date: Mon, 8 Feb 2016 18:43:41 +0100
Subject: [CMake] CMAKE_MODULE_PATH ignored
Message-ID: <56B8D3CD.7010004@oca.eu>


Hi,

I am trying to fix FindHDF5.cmake (support for HDF5_ROOT is broken, only environment variable is supported and it will be eventually probably ignored in find_program).

To that end, I'd like to copy it in my source tree and use that version instead of the one in /usr/shared/cmake.

According to the documentation, all I have to do is to indicate the search directory for the FindXXX.cmak files through CMAKE_MODULE_PATH.

 From the cmake --trace:

/../trunk/CMakeLists.txt(49):  message(status  CMAKE_MODULE_PATH: ${CMAKE_MODULE_PATH} )
## This is the correct PATH, containing the FindHDF5.cmake file
status CMAKE_MODULE_PATH: /scratch/alainm/view/seiscope/codes/3D_Acoustic/FFWI/trunk/tools/build/
## Next line:
/.../trunk/CMakeLists.txt(50):  find_package(HDF5 COMPONENTS CXX Fortran )
## Wrong path selected:
/usr/share/cmake/Modules/FindHDF5.cmake(63):  include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake )

How do I tell cmake I want *my* path to be selected ?

Thanks
  
-- 
---
Alain

From alain.miniussi at oca.eu  Mon Feb  8 13:35:44 2016
From: alain.miniussi at oca.eu (Alain Miniussi)
Date: Mon, 8 Feb 2016 19:35:44 +0100
Subject: [CMake] CMAKE_MODULE_PATH ignored
In-Reply-To: <56B8D3CD.7010004@oca.eu>
References: <56B8D3CD.7010004@oca.eu>
Message-ID: <56B8E000.60205@oca.eu>

On 08/02/2016 18:43, Alain Miniussi wrote:
>
> Hi,
>
> I am trying to fix FindHDF5.cmake (support for HDF5_ROOT is broken, only environment variable is supported and it will be eventually probably ignored in find_program).
>
> To that end, I'd like to copy it in my source tree and use that version instead of the one in /usr/shared/cmake.
>
> According to the documentation, all I have to do is to indicate the search directory for the FindXXX.cmak files through CMAKE_MODULE_PATH.
>
>  From the cmake --trace:
>
> /../trunk/CMakeLists.txt(49):  message(status  CMAKE_MODULE_PATH: ${CMAKE_MODULE_PATH} )
> ## This is the correct PATH, containing the FindHDF5.cmake file
> status CMAKE_MODULE_PATH: /scratch/alainm/view/seiscope/codes/3D_Acoustic/FFWI/trunk/tools/build/
> ## Next line:
> /.../trunk/CMakeLists.txt(50):  find_package(HDF5 COMPONENTS CXX Fortran )
> ## Wrong path selected:
> /usr/share/cmake/Modules/FindHDF5.cmake(63):  include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake )
>
> How do I tell cmake I want *my* path to be selected ?
>
> Thanks
>

Renaming FindHDF5.cmake in FindH5.cmake (or whatever is not present in the global cmake install) helps, but then I also need to replicate all dependencies (FindPackageMessage.cmake, SelectLibraryConfigurations.cmake...), shouldn't cmake look in the /usr/shar/cmake/... for those ?

Thanks

Alain


From micha.hergarden at gmail.com  Mon Feb  8 14:22:17 2016
From: micha.hergarden at gmail.com (Micha Hergarden)
Date: Mon, 8 Feb 2016 20:22:17 +0100
Subject: [CMake] CMAKE_MODULE_PATH ignored
In-Reply-To: <56B8E000.60205@oca.eu>
References: <56B8D3CD.7010004@oca.eu> <56B8E000.60205@oca.eu>
Message-ID: <56B8EAE9.8030405@gmail.com>

On 08/02/16 19:35, Alain Miniussi wrote:
> On 08/02/2016 18:43, Alain Miniussi wrote:
>>
>> Hi,
>>
>> I am trying to fix FindHDF5.cmake (support for HDF5_ROOT is broken,
>> only environment variable is supported and it will be eventually
>> probably ignored in find_program).
>>
>> To that end, I'd like to copy it in my source tree and use that
>> version instead of the one in /usr/shared/cmake.
>>
>> According to the documentation, all I have to do is to indicate the
>> search directory for the FindXXX.cmak files through CMAKE_MODULE_PATH.
>>
>>  From the cmake --trace:
>>
>> /../trunk/CMakeLists.txt(49):  message(status  CMAKE_MODULE_PATH:
>> ${CMAKE_MODULE_PATH} )
>> ## This is the correct PATH, containing the FindHDF5.cmake file
>> status CMAKE_MODULE_PATH:
>> /scratch/alainm/view/seiscope/codes/3D_Acoustic/FFWI/trunk/tools/build/
>> ## Next line:
>> /.../trunk/CMakeLists.txt(50):  find_package(HDF5 COMPONENTS CXX
>> Fortran )
>> ## Wrong path selected:
>> /usr/share/cmake/Modules/FindHDF5.cmake(63): 
>> include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake )
>>
>> How do I tell cmake I want *my* path to be selected ?
>>
>> Thanks
>>
>
> Renaming FindHDF5.cmake in FindH5.cmake (or whatever is not present in
> the global cmake install) helps, but then I also need to replicate all
> dependencies (FindPackageMessage.cmake,
> SelectLibraryConfigurations.cmake...), shouldn't cmake look in the
> /usr/shar/cmake/... for those ?
>
> Thanks
>
> Alain
>
How do you set CMAKE_MODULE_PATH exactly? I used to have a modified
module in my source archive and prepend that dir to the variable:
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
${CMAKE_MODULE_PATH})

Regards,
Micha

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

From ahelten at tenable.com  Mon Feb  8 17:04:10 2016
From: ahelten at tenable.com (Andrew Helten)
Date: Mon, 8 Feb 2016 16:04:10 -0600
Subject: [CMake] Variables substituted in CPack RPM component user binary
	specfile
Message-ID: <CAMTTBtaNxZ0mcy3i1Ywmvwk4NAWJb16=Zhszbjh8-PGF0mUV9A@mail.gmail.com>

Specifying a user binary specfile for CPack RPM packages is done like this:

set(CPACK_RPM_blah_USER_BINARY_SPECFILE blah.spec.in)

The documentation says the "specified file will be processed by
configure_file( @ONLY)." However, exactly which variables are available for
substitution? Is there a list somewhere? It appears to be only CPACK_XXX
variables but I'm wondering why there is such a limitation and if it is
possible to change or circumvent this limitation? For now I'm stuck doing
something nasty (and not component-specific) like add "%define" variables
using CPACK_RPM_SPEC_MORE_DEFINE.

Thanks,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160208/1b935be6/attachment.html>

From domen.vrankar at gmail.com  Mon Feb  8 18:02:15 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 9 Feb 2016 00:02:15 +0100
Subject: [CMake] Variables substituted in CPack RPM component user
	binary specfile
In-Reply-To: <CAMTTBtaNxZ0mcy3i1Ywmvwk4NAWJb16=Zhszbjh8-PGF0mUV9A@mail.gmail.com>
References: <CAMTTBtaNxZ0mcy3i1Ywmvwk4NAWJb16=Zhszbjh8-PGF0mUV9A@mail.gmail.com>
Message-ID: <CAKgx6BKTFWwwgixLvWzbZyFvyai-n56AN10W-aQhv+Jmopq9TA@mail.gmail.com>

> Specifying a user binary specfile for CPack RPM packages is done like this:
>
> set(CPACK_RPM_blah_USER_BINARY_SPECFILE blah.spec.in)
>
> The documentation says the "specified file will be processed by
> configure_file( @ONLY)." However, exactly which variables are available for
> substitution? Is there a list somewhere? It appears to be only CPACK_XXX
> variables but I'm wondering why there is such a limitation and if it is
> possible to change or circumvent this limitation? For now I'm stuck doing
> something nasty (and not component-specific) like add "%define" variables
> using CPACK_RPM_SPEC_MORE_DEFINE.

CPACK_RPM_SPEC_MORE_DEFINE is intended to use in combination with
default spec file template to add rpm specific commands that are not
supported by CPackRPM so if you will be using your custom spec file
then there is no need to use this variable.

In case you are tempted to inject some optional blocks or something
like that I'd suggest that you write all that logic in CMake list or
scripts and use the result to set CPACK_ and CPACK_RPM_ variables
instead of trying to inject custom rpm options into spec file (do that
only if options are known only to your local rpm installation and it's
macros).

By default CPackRPM supports variables listed here:
https://cmake.org/cmake/help/v3.4/module/CPackRPM.html

Note that the content of those variables is transformed in
Modules/CPackRPM.cmake and those transformations populate variables in
default or custom spec file.
Also note that with each release of CMake CPackRPM gets new
features/variables so read the documentation for the version of
CPackRPM that you are using/targeting.



Regarding using your custom spec file (in case you still need some
custom feature that is not supported directly by CPackRPM):

By default spec file template from Modules/CPackRPM.cmake is used so
you could use it as base for your custom spec file.
Note that most variables in default spec file differ from those that
are publicly available since the public variables are transformed in
the script before their value is used. The reason for those variables
not being documented is that they are not part of public interface and
may change from one version of CPackRPM to another (mostly they don't
as we try to preserve compatibility but sometimes it is inevitable)
and it is up to the custom spec file provider to provide a spec file
compatible with the version of CPackRPM being used.

Since you are using your custom spec file you can extend it with
custom variables prefixed with CPACK_.
e.g. setting CPACK_MY_CUSTOM_RPM_VARIABLE:

set(CPACK_MY_CUSTOM_RPM_VARIABLE "some rpm specific commands")

will populate location with placeholder @CPACK_MY_CUSTOM_RPM_VARIABLE@
in your custom spec file.

CPACK_ prefix is mandatory as only those variables are transfered from
CMake to CPack. I'd suggest CPACK_CUSTOMRPM_ variable prefix, or
something in that direction, so that your custom variables won't
conflict with any CPack supported variables.




If missing feature is something that could be useful to others please
file a bug report here:
https://cmake.org/Bug

Thanks,
Domen

From doublef.mobile at gmail.com  Tue Feb  9 03:16:51 2016
From: doublef.mobile at gmail.com (Sergey Zakharchenko)
Date: Tue, 9 Feb 2016 11:16:51 +0300
Subject: [CMake] [nitpick] Incorrect FILE(COPY) error message
Message-ID: <CADYCxoNMbE64eATJnaG_Ss6Nj3HEtWf=EW=khiH-a8sKnUu3bQ@mail.gmail.com>

Hello,

The FILE(COPY) command displays an incorrect error message when its
argyument is empty:

$ cat >x.cmake
FILE(COPY "" DESTINATION ".")

$ cmake -P x.cmake
CMake Error at x.cmake:1 (FILE):
  file INSTALL encountered an empty string input file name.

INSTALL should obviously be COPY. This happens with at least CMake
3.0.1 and 3.4.1.

Best regards,

-- 
DoubleF

P.S. I gave up on the FILE(UPLOAD) custom TLS certificate issue I
reported previously.

From gerhard.pobinger at gmx.at  Tue Feb  9 07:36:03 2016
From: gerhard.pobinger at gmx.at (Gerhard Pobinger)
Date: Tue, 9 Feb 2016 12:36:03 +0000 (UTC)
Subject: [CMake] =?utf-8?q?how_to_map_configurations_from_include=5Fextern?=
	=?utf-8?q?al=5Fmsproject=28=29_=3F?=
Message-ID: <loom.20160209T132505-754@post.gmane.org>

I'm trying to include legacy Visual Studio projects into a cmake generated
solution like this:

project(Crypto)

include_external_msproject(${PROJECT_NAME}_vcproj
   "${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}_vs90.vcproj"
)

# add_dependencies(${PROJECT_NAME}_vcproj
# )

add_library(${PROJECT_NAME} INTERFACE)

target_link_libraries(${PROJECT_NAME} INTERFACE
   debug ${LIB_PATH_DEBUG}/${PROJECT_NAME}.lib 
   optimized ${LIB_PATH_RELEASE}/${PROJECT_NAME}.lib
)

add_dependencies(${PROJECT_NAME}
   ${PROJECT_NAME}_vcproj
)

This works only as long as the vcproj-files contain a configuration named
'release' and 'debug', but when they don't it seems there is no way to map
the existing configuration names (as also requested in
https://cmake.org/pipermail/cmake/2010-April/036388.html). I tried the
proposed way with imported targets, but I didn't succeed.

How can I map a configuration of an external ms-project (e.g.
'release_shared') into a configuration (e.g. 'release') of the
cmake-generated solution? The problem is that simply adding a configuration
named 'release' works, of course, but then I'd have to change the external
vcproj...





From post at hendrik-sattler.de  Tue Feb  9 07:46:51 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Tue, 09 Feb 2016 13:46:51 +0100
Subject: [CMake] how to map configurations from
	include_external_msproject() ?
In-Reply-To: <loom.20160209T132505-754@post.gmane.org>
References: <loom.20160209T132505-754@post.gmane.org>
Message-ID: <574D7287-B185-4BA5-BCFF-FD116399BBD6@hendrik-sattler.de>

Hi,

Am 9. Februar 2016 13:36:03 MEZ, schrieb Gerhard Pobinger <gerhard.pobinger at gmx.at>:
>I'm trying to include legacy Visual Studio projects into a cmake
>generated
>solution like this:
>
>project(Crypto)
>
>include_external_msproject(${PROJECT_NAME}_vcproj
>   "${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}_vs90.vcproj"
>)
>
># add_dependencies(${PROJECT_NAME}_vcproj
># )
>
>add_library(${PROJECT_NAME} INTERFACE)
>
>target_link_libraries(${PROJECT_NAME} INTERFACE
>   debug ${LIB_PATH_DEBUG}/${PROJECT_NAME}.lib 
>   optimized ${LIB_PATH_RELEASE}/${PROJECT_NAME}.lib
>)
>
>add_dependencies(${PROJECT_NAME}
>   ${PROJECT_NAME}_vcproj
>)
>
>This works only as long as the vcproj-files contain a configuration
>named
>'release' and 'debug', but when they don't it seems there is no way to
>map
>the existing configuration names (as also requested in
>https://cmake.org/pipermail/cmake/2010-April/036388.html). I tried the
>proposed way with imported targets, but I didn't succeed.
>
>How can I map a configuration of an external ms-project (e.g.
>'release_shared') into a configuration (e.g. 'release') of the
>cmake-generated solution? The problem is that simply adding a
>configuration
>named 'release' works, of course, but then I'd have to change the
>external
>vcproj...

...and additionally this might be impossible/very hard for e.g. qmake autogenerated vcprojx files.

HS


From attila.krasznahorkay at gmail.com  Tue Feb  9 08:12:51 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Tue, 9 Feb 2016 14:12:51 +0100
Subject: [CMake] CMAKE_MODULE_PATH ignored
In-Reply-To: <56B8EAE9.8030405@gmail.com>
References: <56B8D3CD.7010004@oca.eu> <56B8E000.60205@oca.eu>
 <56B8EAE9.8030405@gmail.com>
Message-ID: <2F4B683C-EE27-4BC3-8979-3E22D07EA9C7@gmail.com>

Hi,

I myself use statements like:

list( INSERT CMAKE_MODULE_PATH 0 ${CMAKE_SOURCE_DIR}/modules )

at the beginning of my main CMakeLists.txt file, and it works exactly as one would expect. I also override some CMake provided modules like this.

Cheers,
        Attila

> On 08 Feb 2016, at 20:22, Micha Hergarden <micha.hergarden at gmail.com> wrote:
> 
> On 08/02/16 19:35, Alain Miniussi wrote:
>> On 08/02/2016 18:43, Alain Miniussi wrote:
>>> 
>>> Hi,
>>> 
>>> I am trying to fix FindHDF5.cmake (support for HDF5_ROOT is broken,
>>> only environment variable is supported and it will be eventually
>>> probably ignored in find_program).
>>> 
>>> To that end, I'd like to copy it in my source tree and use that
>>> version instead of the one in /usr/shared/cmake.
>>> 
>>> According to the documentation, all I have to do is to indicate the
>>> search directory for the FindXXX.cmak files through CMAKE_MODULE_PATH.
>>> 
>>> From the cmake --trace:
>>> 
>>> /../trunk/CMakeLists.txt(49):  message(status  CMAKE_MODULE_PATH:
>>> ${CMAKE_MODULE_PATH} )
>>> ## This is the correct PATH, containing the FindHDF5.cmake file
>>> status CMAKE_MODULE_PATH:
>>> /scratch/alainm/view/seiscope/codes/3D_Acoustic/FFWI/trunk/tools/build/
>>> ## Next line:
>>> /.../trunk/CMakeLists.txt(50):  find_package(HDF5 COMPONENTS CXX
>>> Fortran )
>>> ## Wrong path selected:
>>> /usr/share/cmake/Modules/FindHDF5.cmake(63): 
>>> include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake )
>>> 
>>> How do I tell cmake I want *my* path to be selected ?
>>> 
>>> Thanks
>>> 
>> 
>> Renaming FindHDF5.cmake in FindH5.cmake (or whatever is not present in
>> the global cmake install) helps, but then I also need to replicate all
>> dependencies (FindPackageMessage.cmake,
>> SelectLibraryConfigurations.cmake...), shouldn't cmake look in the
>> /usr/shar/cmake/... for those ?
>> 
>> Thanks
>> 
>> Alain
>> 
> How do you set CMAKE_MODULE_PATH exactly? I used to have a modified
> module in my source archive and prepend that dir to the variable:
> set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
> ${CMAKE_MODULE_PATH})
> 
> Regards,
> Micha
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 tibogens at gmail.com  Tue Feb  9 09:10:00 2016
From: tibogens at gmail.com (Thibault Genessay)
Date: Tue, 9 Feb 2016 15:10:00 +0100
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
Message-ID: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>

Hi,

I'm a long time user of CMake (and huge fan of it) but newly registered on
this list, so please forgive me if I have missed something regarding the
new 3.5 series.

I use CMake with the GCC ARM Embedded compiler (
https://launchpad.net/gcc-arm-embedded) to cross-compile my project
(Windows host, STM32 target, MinGW binutils). Like many users (all?) I had
to create a toolchain file because CMake doesn't support this
compiler/setup out of the box. I have taken inspiration from the many
Google hits and had a working setup until 3.5. This setup relied on the
CMAKE_FORCE_<lang>_COMPILER macros.

I installed 3.5 and the build broke, CMake complaining that this macro was
deprecated and should not be used because of the many improvements on the
compiler detection side. OK, so I removed the offending lines, simply
setting the CMAKE_C_COMPILER variable to the compiler's executable ... and
suddenly I remember why I did use this FORCE hack in the first place: CMake
tells me my compiler is broken because it cannot compile a test program
(undefined symbol: _exit). This is somehow correct, as I compile for bare
metal and I am providing the _exit function in my code. This is a
misunderstanding the CMAKE_FORCE_C_COMPILER works around by simply saying
"believe me, this compiler works".

Now I am left without many options: I can't use the FORCE hack, and I can't
convince CMake my compiler is OK. I am very open to redesign my toolchain
file, or use a stock one from CMake, or whatever this takes, but I simply
do not know how to proceed. Actually, I feel my current toolchain file,
although functional, is not "clean" but never had enough time to do it. Now
that it's a blocking issue, I do have time :)

I rolled back to 3.4 and things work so I'm safe for now. But I would be
very glad if somebody knew more about this specific problem, or this
compiler, or toolchain file writing in general. I would love to write a
"stock" toolchain file for this compiler but I simply do not know enough
(nor I can find enough up-to-date documentation).

Thanks for reading,
Cheers

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

From chuck.atkins at kitware.com  Tue Feb  9 11:22:00 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Tue, 9 Feb 2016 11:22:00 -0500
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
Message-ID: <CAOXZzG4K0NF=+1RuyKotLMu0e2SRWZWYrxWsegPgV3Zwkgb_hw@mail.gmail.com>

Hi Thibault,

Can you post your toolchain file?

- Chuck

On Tue, Feb 9, 2016 at 9:10 AM, Thibault Genessay <tibogens at gmail.com>
wrote:

> Hi,
>
> I'm a long time user of CMake (and huge fan of it) but newly registered on
> this list, so please forgive me if I have missed something regarding the
> new 3.5 series.
>
> I use CMake with the GCC ARM Embedded compiler (
> https://launchpad.net/gcc-arm-embedded) to cross-compile my project
> (Windows host, STM32 target, MinGW binutils). Like many users (all?) I had
> to create a toolchain file because CMake doesn't support this
> compiler/setup out of the box. I have taken inspiration from the many
> Google hits and had a working setup until 3.5. This setup relied on the
> CMAKE_FORCE_<lang>_COMPILER macros.
>
> I installed 3.5 and the build broke, CMake complaining that this macro was
> deprecated and should not be used because of the many improvements on the
> compiler detection side. OK, so I removed the offending lines, simply
> setting the CMAKE_C_COMPILER variable to the compiler's executable ... and
> suddenly I remember why I did use this FORCE hack in the first place: CMake
> tells me my compiler is broken because it cannot compile a test program
> (undefined symbol: _exit). This is somehow correct, as I compile for bare
> metal and I am providing the _exit function in my code. This is a
> misunderstanding the CMAKE_FORCE_C_COMPILER works around by simply saying
> "believe me, this compiler works".
>
> Now I am left without many options: I can't use the FORCE hack, and I
> can't convince CMake my compiler is OK. I am very open to redesign my
> toolchain file, or use a stock one from CMake, or whatever this takes, but
> I simply do not know how to proceed. Actually, I feel my current toolchain
> file, although functional, is not "clean" but never had enough time to do
> it. Now that it's a blocking issue, I do have time :)
>
> I rolled back to 3.4 and things work so I'm safe for now. But I would be
> very glad if somebody knew more about this specific problem, or this
> compiler, or toolchain file writing in general. I would love to write a
> "stock" toolchain file for this compiler but I simply do not know enough
> (nor I can find enough up-to-date documentation).
>
> Thanks for reading,
> Cheers
>
> Thibault
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160209/2ab01a60/attachment.html>

From brad.king at kitware.com  Tue Feb  9 12:02:12 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 9 Feb 2016 12:02:12 -0500
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
Message-ID: <56BA1B94.5000407@kitware.com>

Hi Thibault,

Thanks for trying the release candidate!

On 02/09/2016 09:10 AM, Thibault Genessay wrote:
> I installed 3.5 and the build broke

While CMakeForceCompiler is deprecated we think it should still work
in most cases where it worked before, just with a warning.  What
actually breaks?

> CMake complaining that this macro was deprecated and should
> not be used because of the many improvements on the compiler
> detection side.

For reference, the discussion that led to this decision was here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500

Basically CMake now needs to detect a lot more from the compiler than
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
We need to make the compiler detection work for everyone.

> why I did use this FORCE hack in the first place: CMake tells me
> my compiler is broken because it cannot compile a test program
> (undefined symbol: _exit). This is somehow correct, as I compile
> for bare metal and I am providing the _exit function in my code.

Does CMake at least detect the compiler id and version correctly?
Is it then only the test for working compiler that fails?  Is there
something from the toolchain we can query to decide whether it can
link an executable without an extra spec file?

Thanks,
-Brad


From omnijack at gmail.com  Tue Feb  9 12:56:51 2016
From: omnijack at gmail.com (Jack Stalnaker)
Date: Tue, 9 Feb 2016 11:56:51 -0600
Subject: [CMake] ifort: command line remark #10148: option 'i_dynamic' not
	supported
Message-ID: <CAOGUJ6FyACV-dD77PWP0qz9t+xbqpmjUkeJ2k_OpVitweaaq-A@mail.gmail.com>

Hi,

I am using cmake 2.8.12.2, and I'm getting this warning when I attempt to
link a fortran program or library.

ifort: command line remark #10148: option 'i_dynamic' not supported


I cannot find very much about this error searching the web. What does this
mean?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160209/168c12ca/attachment.html>

From jonathan.bohren at gmail.com  Tue Feb  9 13:04:23 2016
From: jonathan.bohren at gmail.com (Jonathan Bohren)
Date: Tue, 09 Feb 2016 18:04:23 +0000
Subject: [CMake] Precedence of SYSTEM and non-SYSTEM include directories
Message-ID: <CADy-PFibyf1CMz5_Vueba1vx+J5saeJkNDe8Ae1ChhHQny1UrA@mail.gmail.com>

I ran into a problem recently where a project I was building set a SYSTEM
include directory which was already a non-SYSTEM include directory imported
from a dependency. When this happened, CMake dropped the non-SYSTEM
directory in favor of the SYSTEM one, causing my build to fail.

Should this be the correct behavior? According to GCC [1], it gives
precedence to non-SYSTEM include directories, and specifying both for the
same path produces a warning. With CMake, if both are specified, it ignores
the non-SYSTEM include and fails silently. Should CMake be dropping one of
the options at all?

I've created a minimal example here:
http://github.com/jbohren/isystem

Thanks!
-j

[1] https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
> All directories named by -isystem are searched after all directories
named by -I, no matter what their order was on the command line. If the
same directory is named by both -I and -isystem, the -I option is ignored.
GCC provides an informative message when this occurs if -v is used.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160209/45c441b0/attachment.html>

From vania.joloboff at inria.fr  Wed Feb 10 03:49:35 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Wed, 10 Feb 2016 09:49:35 +0100
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <56BA1B94.5000407@kitware.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <56BA1B94.5000407@kitware.com>
Message-ID: <56BAF99F.9080603@inria.fr>

Hi

We have not yet moved to 3.5 but seeing this discussion, I am wondering
what we will have to do. In our project, we have several C and C++ cross 
compilers and we want to compare them on selected benchmarks. We also 
want to compare different compile options and different linking options. 
We know for sure these cross compilers are working properly
and our technique today is roughly

CMakeForceCompiler(A)
compile benchmarks with A (and various options)
CMakeForceCCompiler(B)
compile benchmarks with B
CMakeForceCompiler(C)
compile benchmarks with C

Next, we run all the benchmarks and compare the results.

How am I supposed to do that if CMakeForceCompiler() is deprecated ?

Vania



On 02/09/2016 06:02 PM, Brad King wrote:
> Hi Thibault,
>
> Thanks for trying the release candidate!
>
> On 02/09/2016 09:10 AM, Thibault Genessay wrote:
>> I installed 3.5 and the build broke
>
> While CMakeForceCompiler is deprecated we think it should still work
> in most cases where it worked before, just with a warning.  What
> actually breaks?
>
>> CMake complaining that this macro was deprecated and should
>> not be used because of the many improvements on the compiler
>> detection side.
>
> For reference, the discussion that led to this decision was here:
>
>   http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500
>
> Basically CMake now needs to detect a lot more from the compiler than
> we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
> We need to make the compiler detection work for everyone.
>
>> why I did use this FORCE hack in the first place: CMake tells me
>> my compiler is broken because it cannot compile a test program
>> (undefined symbol: _exit). This is somehow correct, as I compile
>> for bare metal and I am providing the _exit function in my code.
>
> Does CMake at least detect the compiler id and version correctly?
> Is it then only the test for working compiler that fails?  Is there
> something from the toolchain we can query to decide whether it can
> link an executable without an extra spec file?
>
> Thanks,
> -Brad
>


From brad.king at kitware.com  Wed Feb 10 09:12:17 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 10 Feb 2016 09:12:17 -0500
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <56BAF99F.9080603@inria.fr>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <56BA1B94.5000407@kitware.com> <56BAF99F.9080603@inria.fr>
Message-ID: <56BB4541.3000609@kitware.com>

On 02/10/2016 03:49 AM, Vania Joloboff wrote:
> We have not yet moved to 3.5 but seeing this discussion, I am wondering
> what we will have to do. In our project, we have several C and C++ cross 
> compilers and we want to compare them on selected benchmarks. We also 
> want to compare different compile options and different linking options. 
> We know for sure these cross compilers are working properly
> and our technique today is roughly
> 
> CMakeForceCompiler(A)
> compile benchmarks with A (and various options)
> CMakeForceCCompiler(B)
> compile benchmarks with B
> CMakeForceCompiler(C)
> compile benchmarks with C
> 
> Next, we run all the benchmarks and compare the results.
> 
> How am I supposed to do that if CMakeForceCompiler() is deprecated ?

CMakeForceCompiler was meant for use in toolchain files.  We do
not support switching compilers within a single CMakeLists.txt file
nor multiple toolchains in a single CMake run.

Can you post a more complete example of what you're trying to do?
It sounds like your sequence should be scripted externally and run
CMake multiple times with separate build trees.

-Brad


From tibogens at gmail.com  Wed Feb 10 09:28:43 2016
From: tibogens at gmail.com (Thibault Genessay)
Date: Wed, 10 Feb 2016 15:28:43 +0100
Subject: [CMake] Fwd:  Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <CAD-t5VXK=1x6F_TC-z7eoGZfM3=k03eOf3iAxZks2C5XKN9xBg@mail.gmail.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <CAOXZzG4K0NF=+1RuyKotLMu0e2SRWZWYrxWsegPgV3Zwkgb_hw@mail.gmail.com>
 <CAD-t5VXK=1x6F_TC-z7eoGZfM3=k03eOf3iAxZks2C5XKN9xBg@mail.gmail.com>
Message-ID: <CAD-t5VVXgwb48GWEQAx0YdghovO9eH0jQCopkMKOZ=-B+9pjiA@mail.gmail.com>

[Note: this was erroneously sent off-list to Chuck only, sorry for the
noise]

Hi Chuck,

I can't really post my toolchain file for two reasons: 1) it contains
proprietary stuff and 2) I am ashamed of it.

OK, here you go. I just renamed whatever was proprietary. Please don't
shoot me, I promise my code and the other CMakeLists are better than that
:) When I read it again, I don't understand why I have implemented this
"flags reset" feature, and don't know if it actually works - but the rest
does. Anyway:

# Frobnicator 2
#
# Cross-compilation toolchain definition file using GNU Tools for ARM
Embedded Processors
# https://launchpad.net/gcc-arm-embedded
#
# This toolchain file assumes that the executable 'arm-none-eabi-gcc.exe'
is in the path.
# As you can see, it also assumes that you are running Windows. If not,
then please modify
# this file to make it smarter.
#
# It was written according to the CMake wiki page dedicated to this topic:
# http://www.vtk.org/Wiki/CMake_Cross_Compiling
# (especially important is the CMAKE_FORCE_C_COMPILER stuff, required
because
# the compiler is not able to spit out code without flags, breaking CMake's
# detection system otherwise)
#
# Copyright (c) 2015 Initrode SA

include(CMakeForceCompiler)

set(_should_set_flags FALSE)

if (NOT CMAKE_SYSTEM_NAME)

    set(CMAKE_SYSTEM_NAME Generic)
    set(CMAKE_SYSTEM_VERSION "frob2-r1")
    set(CMAKE_SYSTEM_PROCESSOR cortex-m3)

    CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc.exe GNU)
    CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++.exe GNU)

    # To find the location of the toolchain, invoke the compiler asking for
the
    # path to libc.a. This path is then stripped off of the lib/libc.a part
- this
    # hopefully points to the root of the toolchain.
    execute_process(
        COMMAND ${CMAKE_C_COMPILER} -print-file-name=libc.a
        OUTPUT_VARIABLE _path_to_toolchain
        OUTPUT_STRIP_TRAILING_WHITESPACE
    )
    # Get rid of the filename
    get_filename_component(_path_to_toolchain
        "${_path_to_toolchain}" PATH
    )
    # Get rid of the trailing lib/ (or whatever the dir is)
    get_filename_component(_path_to_toolchain
        "${_path_to_toolchain}/.." REALPATH
    )
    set(INITRODE_CROSSCOMPILE_TOOLCHAIN ${_path_to_toolchain} CACHE PATH
"Path to the cross compiler toolchain")

    set(_should_set_flags TRUE)
endif()

if (NOT _banner_already_printed)
    message(STATUS "Cross-compiling using the gcc-arm-embedded toolchain")
    message(STATUS "          Toolchain location: ${_path_to_toolchain}")
    message(STATUS "              C/C++ compiler: ${CMAKE_C_COMPILER}")
    message(STATUS "Frobnicator hardware version: ${CMAKE_SYSTEM_VERSION}")
    message(STATUS "                 MCU variant:
${CMAKE_SYSTEM_PROCESSOR}")
    set(_banner_already_printed TRUE)
endif ()

set(CMAKE_FIND_ROOT_PATH ${INITRODE_CROSSCOMPILE_TOOLCHAIN})

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(_flags_reset_mode "")

# This should only be used on the command line (i.e. cmake
-DINITRODE_RESET_C_CXX_FLAGS=1)
# and never put in the cache, otherwise changes in the GUI would be erased
at each cmake
# run (which is annoying behaviour to say the least)
if (INITRODE_RESET_C_CXX_FLAGS)
    set(_should_set_flags TRUE)
    set(_flags_reset_mode "FORCE")
endif ()

if (_should_set_flags)

    # Generic flags
    set(_flags "-fno-common -ffunction-sections -fdata-sections -Wall")

    # CPU-specific flags
    # These could go into a separate file but since we have no other
hardware target
    # for the time being, it is kept here.
    set(_flags "${_flags} -mcpu=cortex-m3 -march=armv7-m -mthumb
-msoft-float")

    set(CMAKE_C_FLAGS "${_flags}" CACHE STRING "Flags used by the C
compiler during all build types." ${_flags_reset_mode})

    # C++ flags
    set(_cppflags "${_flags} -fno-rtti -fno-exceptions -std=c++11")
    set(CMAKE_CXX_FLAGS "${_cppflags}" CACHE STRING "Flags used by the C++
compiler during all build types." ${_flags_reset_mode})

    # Debugging flags
    set(CMAKE_C_FLAGS_DEBUG "-g -D_DEBUG" CACHE STRING "Flags used by the C
compiler during debug builds.")
    set(CMAKE_CXX_FLAGS_DEBUG "-g -D_DEBUG" CACHE STRING "Flags used by the
C++ compiler during debug builds.")
    set(CMAKE_ASM_FLAGS_DEBUG "-g -D_DEBUG" CACHE STRING "Flags used by the
assembler during debug builds.")

    # These are actually set by each target independently, until I manage
to understand
    # what is generic (i.e. specific to the toolchain) and what is
target-specific.
    ##set(CMAKE_EXE_LINKER_FLAGS "-lc -lm -lgcc" CACHE STRING "Flags used
by the linker.")
endif ()



Cheers,
Thibault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160210/90eeb03e/attachment-0001.html>

From tibogens at gmail.com  Wed Feb 10 09:30:48 2016
From: tibogens at gmail.com (Thibault Genessay)
Date: Wed, 10 Feb 2016 15:30:48 +0100
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <56BA1B94.5000407@kitware.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <56BA1B94.5000407@kitware.com>
Message-ID: <CAD-t5VU_dquqkof4Ry85DsoqCJ7DAgDWADOGnxKP7sVim=qEqw@mail.gmail.com>

[Note: this was erroneously sent off-list to Brad only, sorry for the noise]

Hi Brad,


On Tue, Feb 9, 2016 at 6:02 PM, Brad King <brad.king at kitware.com> wrote:

> Thanks for trying the release candidate!
>

Well, the download page is a bit nasty as when you click "download the
latest release 3.4.1" you are shown the generic download page with 3.5-rc1
at the top :)


> While CMakeForceCompiler is deprecated we think it should still work
> in most cases where it worked before, just with a warning.  What
> actually breaks?
>

I might just be my own stupidity. I downloaded 3.5 this morning and tried
again. I get all the warnings, but the build, in fact, succeeds. It must
have been something else that broke and I simply overlooked the actual
reason, seeing these red deprecation warnings everywhere. As it's often the
case, a night of sleep away from the keyboard is the best way to solve
issues. So the warnings are indeed still there, but the build finishes
(didn't test the firmware but I guess it's ok).


> For reference, the discussion that led to this decision was here:
>
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500
>

Thanks for the pointer, I had not found this thread when searching for
explanations.


> Basically CMake now needs to detect a lot more from the compiler than
> we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
> We need to make the compiler detection work for everyone.
>

This is a very noble objective, and I am ready to help you make this
happen. However, I expect things will be tricky for cross compilations, as
the toolchains are exotic mixes of compilers (perhaps proprietary and
seldom used) and binutils (e.g. I've tried Cygwin and MinGW - while I favor
the latter, some find the former usable ... not me).

> why I did use this FORCE hack in the first place: CMake tells me
> > my compiler is broken because it cannot compile a test program
> > (undefined symbol: _exit). This is somehow correct, as I compile
> > for bare metal and I am providing the _exit function in my code.
>
> Does CMake at least detect the compiler id and version correctly?
> Is it then only the test for working compiler that fails?  Is there
> something from the toolchain we can query to decide whether it can
> link an executable without an extra spec file?
>

In the toolchain file I posted to Chuck, I replaced the
CMAKE_FORCE_<foo>_COMPILER by set(CMAKE_<foo>_COMPILER):

    #CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc.exe GNU)
    #CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++.exe GNU)
    set(CMAKE_C_COMPILER arm-none-eabi-gcc.exe)
    set(CMAKE_FORCE_CXX_COMPILER arm-none-eabi-g++.exe)

and tried again. I get the same error that I had yesterday. Before I post
the output, and after having reviewed my toolchain file, I now think it's
clearly a bug in it: I don't define the linker flags, so the thing cannot
link. Easy enough. However, I don't know how to solve this as I don't want
to use the fully featured newlibc (rdimon.specs IIRC) but only the nano
variant (nano.specs, and this one doesn't have _exit and other very low
level syscalls). So if I provided generic linker flags, maybe the compiler
could be detected, but then I wouldn't be able to build my firmware with
the appropriate libc (not even considering I have different linker scripts
for different binaries - for R&D tests on different hardware,
production,etc.)

So, here's what I get:

Creating build directory 'c:\dev\frob2_build_cmake3.5'
-- Cross-compiling using the gcc-arm-embedded toolchain
--        Toolchain location:
C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/arm-none-eabi
--            C/C++ compiler: arm-none-eabi-gcc.exe
--     Frob hardware version: frob2-r1
--               MCU variant: cortex-m3
-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is unknown
-- Found Eclipse version 4.3 (Kepler)
-- Check for working C compiler:
C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe
-- Check for working C compiler:
C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe
-- broken
CMake Error at
C:/dev/local/cmake-3.5.0-rc1-win32-x86/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61
(message):
  The C compiler

"C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe"
  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp



  Run Build Command:"C:/MinGW/bin/mingw32-make.exe" "cmTC_331cb/fast"

  C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTC_331cb.dir\build.make
  CMakeFiles/cmTC_331cb.dir/build

  mingw32-make.exe[1]: Entering directory
  'C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp'

  Building C object CMakeFiles/cmTC_331cb.dir/testCCompiler.c.obj



C:\dev\local\gcc-arm-none-eabi-4_9-2015q3-20150921-win32\bin\arm-none-eabi-gcc.exe
  -fno-common -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m3
  -march=armv7-m -mthumb -msoft-float -o
  CMakeFiles\cmTC_331cb.dir\testCCompiler.c.obj -c
  C:\dev\frob2_build_cmake3.5\CMakeFiles\CMakeTmp\testCCompiler.c

  Linking C executable cmTC_331cb

  C:\dev\local\cmake-3.5.0-rc1-win32-x86\bin\cmake.exe -E cmake_link_script
  CMakeFiles\cmTC_331cb.dir\link.txt --verbose=1



C:\dev\local\gcc-arm-none-eabi-4_9-2015q3-20150921-win32\bin\arm-none-eabi-gcc.exe
  -fno-common -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m3
  -march=armv7-m -mthumb -msoft-float
  CMakeFiles/cmTC_331cb.dir/testCCompiler.c.obj -o cmTC_331cb



c:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-exit.o):
  In function `exit':

  exit.c:(.text.exit+0x16): undefined reference to `_exit'

  collect2.exe: error: ld returned 1 exit status

  CMakeFiles\cmTC_331cb.dir\build.make:96: recipe for target 'cmTC_331cb'
  failed

  mingw32-make.exe[1]: *** [cmTC_331cb] Error 1

  mingw32-make.exe[1]: Leaving directory
  'C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp'

  Makefile:125: recipe for target 'cmTC_331cb/fast' failed

  mingw32-make.exe: *** [cmTC_331cb/fast] Error 2



  CMake will not be able to correctly generate this project.


I hope I am being clear, but this is my first cross-compilation project so
I had a hard time setting things up in the beginning.
Thanks,

Thibault

On Tue, Feb 9, 2016 at 6:02 PM, Brad King <brad.king at kitware.com> wrote:

> Hi Thibault,
>
> Thanks for trying the release candidate!
>
> On 02/09/2016 09:10 AM, Thibault Genessay wrote:
> > I installed 3.5 and the build broke
>
> While CMakeForceCompiler is deprecated we think it should still work
> in most cases where it worked before, just with a warning.  What
> actually breaks?
>
> > CMake complaining that this macro was deprecated and should
> > not be used because of the many improvements on the compiler
> > detection side.
>
> For reference, the discussion that led to this decision was here:
>
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500
>
> Basically CMake now needs to detect a lot more from the compiler than
> we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
> We need to make the compiler detection work for everyone.
>
> > why I did use this FORCE hack in the first place: CMake tells me
> > my compiler is broken because it cannot compile a test program
> > (undefined symbol: _exit). This is somehow correct, as I compile
> > for bare metal and I am providing the _exit function in my code.
>
> Does CMake at least detect the compiler id and version correctly?
> Is it then only the test for working compiler that fails?  Is there
> something from the toolchain we can query to decide whether it can
> link an executable without an extra spec file?
>
> Thanks,
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160210/defdf200/attachment.html>

From brad.king at kitware.com  Wed Feb 10 09:46:22 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 10 Feb 2016 09:46:22 -0500
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <CAD-t5VU_dquqkof4Ry85DsoqCJ7DAgDWADOGnxKP7sVim=qEqw@mail.gmail.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <56BA1B94.5000407@kitware.com>
 <CAD-t5VU_dquqkof4Ry85DsoqCJ7DAgDWADOGnxKP7sVim=qEqw@mail.gmail.com>
Message-ID: <56BB4D3E.6000408@kitware.com>

On 02/10/2016 09:30 AM, Thibault Genessay wrote:
>> While CMakeForceCompiler is deprecated we think it should still work
>> in most cases where it worked before, just with a warning.  What
>> actually breaks?
> 
> I downloaded 3.5 this morning and tried again. I get all the warnings,
> but the build, in fact, succeeds. It must have been something else that
> broke and I simply overlooked the actual reason

Good.  Thanks for testing and confirming.

>> Basically CMake now needs to detect a lot more from the compiler than
>> we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
>> We need to make the compiler detection work for everyone.
> 
> This is a very noble objective, and I am ready to help you make this happen.

Great!

>     set(CMAKE_C_COMPILER arm-none-eabi-gcc.exe)
>     set(CMAKE_FORCE_CXX_COMPILER arm-none-eabi-g++.exe)

The second line should set CMAKE_CXX_COMPILER.

> I don't define the linker flags, so the thing cannot link.

Yes, I think this is the root of the problem.  Instead of "forcing"
CMake to skip checks that involve linking we should have toolchain
files provide enough information to allow linking (or at least
explicitly tell CMake not to link during try_compile as a fallback
solution).  See more below.

> -- The C compiler identification is GNU 4.9.3

Good.

> -- The CXX compiler identification is unknown

Please check CMakeFiles/CMakeError.log to see why it was not able
to identify the C++ compiler.  Maybe the above toolchain file typo
is responsible.

> -- Check for working C compiler: C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe -- broken

Okay, this is what we need to get working.  CMake wants to be able
to run a try_compile for the toolchain.  CMakeForceCompiler was just
skipping CMake's early check for that and so could only help for
projects not using try_compile for anything.

> I don't want to use the fully featured newlibc (rdimon.specs IIRC)
> but only the nano variant (nano.specs, and this one doesn't have
> _exit and other very low level syscalls). So if I provided generic
> linker flags, maybe the compiler could be detected, but then I
> wouldn't be able to build my firmware with the appropriate libc

For linking the actual binaries during your build you must have some
linker scripts.  Perhaps we should provide a way for the toolchain
file to specify a linker script to use for try_compile checks.  That
would then be used during the check for a working compiler, ABI check,
and later try_compile checks to allow them to work as normal but still
represent the real target platform.  Might that work for this use case?

Thanks,
-Brad


From omnijack at gmail.com  Wed Feb 10 13:24:50 2016
From: omnijack at gmail.com (Jack Stalnaker)
Date: Wed, 10 Feb 2016 12:24:50 -0600
Subject: [CMake] FindMPI uses wrong fortran include path
Message-ID: <CAOGUJ6E2iEne+dpyPzTmqXVP24-MGipdQR5k0RMdPUL86DHc9w@mail.gmail.com>

Hi,

If I call FindMPI, it successfully finds Intel MPI, including all the
proper include paths etc. However, when I compile MPI code, I get an error
message saying that the mod file (called by "use mpi" in the code) was not
compiled by this compiler. The problem appears to be that the Intel
compiler suite installed both gfortran and ifort versions of the mod files
in different include directories like this:

INTELROOT/
    linux/mpi/intel64/include/gfortran/mpi.mod
    linux/mpi/intel64/include/mpi.mod

where the first mod is the gfortran mod, and the second is the intel mod.
Following the call to FindMPI(), the variable MPI_Fortran_INCLUDE_PATH
contains both, with the gfortran directory first. If I do this:

include_directories(${MPI_Fortran_INCLUDE_PATH})

I get the failure I mentioned, presumably because the compiler tries to use
the gfortran mod first.

So is there a way to tell the build system to ignore the gfortran mod? I
cannot assume that the order or contents of MPI_Fortran_INCLUDE_PATH.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160210/569cf7b2/attachment.html>

From jack.stalnaker at gmail.com  Wed Feb 10 15:19:10 2016
From: jack.stalnaker at gmail.com (Jack Stalnaker)
Date: Wed, 10 Feb 2016 14:19:10 -0600
Subject: [CMake] FindMPI uses wrong fortran include path
In-Reply-To: <CAOGUJ6E2iEne+dpyPzTmqXVP24-MGipdQR5k0RMdPUL86DHc9w@mail.gmail.com>
References: <CAOGUJ6E2iEne+dpyPzTmqXVP24-MGipdQR5k0RMdPUL86DHc9w@mail.gmail.com>
Message-ID: <CAOGUJ6EfegHMAM94FghKK7oVo5X+pkStryhfPKmFenVHf7W9Nw@mail.gmail.com>

This seems to be the same issue discussed here:
https://cmake.org/pipermail/cmake-developers/2014-December/023831.html

which refers to a bug marked fixed here:

http://www.cmake.org/Bug/view.php?id=15182


However, I'm still getting the issue in 3.5.0-rc1



On Wed, Feb 10, 2016 at 12:24 PM, Jack Stalnaker <omnijack at gmail.com> wrote:

> Hi,
>
> If I call FindMPI, it successfully finds Intel MPI, including all the
> proper include paths etc. However, when I compile MPI code, I get an error
> message saying that the mod file (called by "use mpi" in the code) was not
> compiled by this compiler. The problem appears to be that the Intel
> compiler suite installed both gfortran and ifort versions of the mod files
> in different include directories like this:
>
> INTELROOT/
>     linux/mpi/intel64/include/gfortran/mpi.mod
>     linux/mpi/intel64/include/mpi.mod
>
> where the first mod is the gfortran mod, and the second is the intel mod.
> Following the call to FindMPI(), the variable MPI_Fortran_INCLUDE_PATH
> contains both, with the gfortran directory first. If I do this:
>
> include_directories(${MPI_Fortran_INCLUDE_PATH})
>
> I get the failure I mentioned, presumably because the compiler tries to
> use the gfortran mod first.
>
> So is there a way to tell the build system to ignore the gfortran mod? I
> cannot assume that the order or contents of MPI_Fortran_INCLUDE_PATH.
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160210/9f43dfce/attachment.html>

From robert.maynard at kitware.com  Wed Feb 10 15:40:00 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 10 Feb 2016 15:40:00 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.5.0-rc2 now ready for testing!
Message-ID: <CAFzjYVpv64_4nYke6ESYJQ5o-Ky81-tkE42JoXsZkZecAY7pGg@mail.gmail.com>

I am proud to announce the second CMake 3.5 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

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

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

Some of the more significant features of CMake 3.5 are:

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC
  now provide imported targets.

* The "FindOpenMP" module learned to support Clang.

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

Deprecated and Removed Features:

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.



CMake 3.5 Release Notes
***********************

Changes made since CMake 3.4 include the following.


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


GUI
---

* The "cmake-gui(1)" gained options to control warnings about
  deprecated functionality.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* The "cmake-gui(1)" gained a Regular Expression Explorer which may
  be used to create and evaluate regular expressions in real-time. The
  explorer window is available via the "Tools" menu.


Command-Line
------------

* The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and
  suppress the deprecated warnings output by default.

* The suppression of developer warnings as errors can now be
  controlled with the new "-Werror=dev" and "-Wno-error=dev"
  "cmake(1)" options.

* The "cmake(1)" "-E" command-line tools "copy",
  "copy_if_different", "copy_directory", and "make_directory" learned
  to support multiple input files or directories.


Commands
--------

* The "cmake_parse_arguments()" command is now implemented natively.
  The "CMakeParseArguments" module remains as an empty placeholder for
  compatibility.

* The "install(DIRECTORY)" command learned to support "generator
  expressions" in the list of directories.


Variables
---------

* The "CMAKE_ERROR_DEPRECATED" variable can now be set using the
  "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options.

* The "CMAKE_WARN_DEPRECATED" variable can now be set using the
  "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options.


Properties
----------

* The "VS_GLOBAL_<variable>" target property is now implemented for
  VS 2010 and above.  Previously it worked only in VS 2008 and below.


Modules
-------

* The "ExternalProject" module learned a new "GIT_REMOTE_NAME"
  option to control the "git clone --origin" value.

* The "FindBoost" module now provides imported targets such as
  "Boost::boost" and "Boost::filesystem".

* The "FindFLEX" module "FLEX_TARGET" macro learned a new
  "DEFINES_FILE" option to specify a custom output header to be
  generated.

* The "FindGTest" module now provides imported targets.

* The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is
  enabled, now sets "GTK2_LIBRARIES" to contain the list of imported
  targets instead of the paths to the libraries.  Moreover it now sets
  a new "GTK2_TARGETS" variable containing all the targets imported.

* The "FindOpenMP" module learned to support Clang.

* The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT"
  option to search for libraries using the MSVC static runtime.

* The "FindPNG" module now provides imported targets.

* The "FindTIFF" module now provides imported targets.

* A "FindXalanC" module was introduced to find the Apache Xalan-C++
  XSL transform processing library.

* The "FindXercesC" module now provides imported targets.


Platforms
---------

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.


CPack
-----

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

* The "CPackDeb" module learned to set the optional config file
  "Source" field using a monolithic or per-component variable. See
  "CPACK_DEBIAN_PACKAGE_SOURCE".

* The "CPackDeb" module learned to set Package, Section and Priority
  control fields per-component. See variables
  "CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION" and
  "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY".

* The "CPack DragNDrop generator" learned to add multi-lingual SLAs
  to a DMG which is presented to the user when they try to mount the
  DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR"
  variables for details.

* The "CPackNSIS" module learned new variables to add bitmaps to the
  installer.  See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and
  "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables.

* The "CPackRPM" module learned to set Name and Group control fields
  per-component. See "CPACK_RPM_<component>_PACKAGE_NAME" and
  "CPACK_RPM_<component>_PACKAGE_GROUP".


Other
-----

* Warnings about deprecated functionality are now enabled by
  default. They may be suppressed with "-Wno-deprecated" or by setting
  the "CMAKE_WARN_DEPRECATED" variable to false.


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

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.


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

* The "Visual Studio 14 2015" generator learned to map the
  "/debug:fastlink" linker flag to the ".vcxproj" file property.

* The "FindGTK2" module now configures the "GTK2::sigc++" imported
  target to enable c++11 on its dependents when using sigc++ 2.5.1 or
  higher.

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

----------------------------------------------------------------------------
Changes made since CMake 3.5.0-rc1:

Brad King (10):
      Fix dependency scanning configuration in subdirectories
      Tests: Use newer policy settings in RunCMake.install test
      install(EXPORT): Fix crash on target in another directory
      ExternalProject: Be compatible with projects setting CMAKE_CFG_INTDIR
      Install ccmake.1 and cmake-gui.1 conditionally with their tools (#15957)
      Tests: Avoid OS X 10.5 limitation warning in RunCMake.install test
      Fix internal target lookup performance regression
      Improve internal generator target structure lookup
      cmCurl: Fix compilation with system curl versions prior to 7.21.5
      CMake 3.5.0-rc2

Horst Kronstorfer (1):
      Help: Fix command specification for cmake_minimum_required

Nils Gladitz (1):
      CMake: Prevent WiX installations over existing NSIS installations

Orion Poplawski (1):
      Tests: Extend ctest_submit host lookup failure matching (#15958)

Paul Wilkinson (1):
      Help: Fix mistake in cmake-buildsystem(7) example

From daniel.wirtz at simtech.uni-stuttgart.de  Wed Feb 10 17:01:09 2016
From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz)
Date: Thu, 11 Feb 2016 11:01:09 +1300
Subject: [CMake] FindMPI uses wrong fortran include path
In-Reply-To: <CAOGUJ6EfegHMAM94FghKK7oVo5X+pkStryhfPKmFenVHf7W9Nw@mail.gmail.com>
References: <CAOGUJ6E2iEne+dpyPzTmqXVP24-MGipdQR5k0RMdPUL86DHc9w@mail.gmail.com>
 <CAOGUJ6EfegHMAM94FghKK7oVo5X+pkStryhfPKmFenVHf7W9Nw@mail.gmail.com>
Message-ID: <56BBB325.60404@simtech.uni-stuttgart.de>

Hey,

at a rough read i think i had the same sort of issue.
For us, the FindMPI detected "MPI_Fortran_INCLUDE_PATH" correctly - 
however, what did matter in our case
was the order those paths have been used in CMake.

as example:
target_include_directories(yourtarget ${MPI_C_INCLUDE_PATH} 
${MPI_Fortran_INCLUDE_PATH})
instead of
target_include_directories(yourtarget ${MPI_Fortran_INCLUDE_PATH} 
${MPI_C_INCLUDE_PATH})
makes all the difference in our case.
so check if there are maybe even dependent libraries that have the C/CXX 
include path set first etc.

maybe this helps :-)


On 11.02.2016 09:19, Jack Stalnaker wrote:
> This seems to be the same issue discussed here:
> https://cmake.org/pipermail/cmake-developers/2014-December/023831.html
>
> which refers to a bug marked fixed here:
> http://www.cmake.org/Bug/view.php?id=15182
> However, I'm still getting the issue in 3.5.0-rc1
>
> On Wed, Feb 10, 2016 at 12:24 PM, Jack Stalnaker <omnijack at gmail.com 
> <mailto:omnijack at gmail.com>> wrote:
>
>     Hi,
>
>     If I call FindMPI, it successfully finds Intel MPI, including all
>     the proper include paths etc. However, when I compile MPI code, I
>     get an error message saying that the mod file (called by "use mpi"
>     in the code) was not compiled by this compiler. The problem
>     appears to be that the Intel compiler suite installed both
>     gfortran and ifort versions of the mod files in different include
>     directories like this:
>
>     INTELROOT/
>         linux/mpi/intel64/include/gfortran/mpi.mod
>         linux/mpi/intel64/include/mpi.mod
>
>     where the first mod is the gfortran mod, and the second is the
>     intel mod. Following the call to FindMPI(), the variable
>     MPI_Fortran_INCLUDE_PATH contains both, with the gfortran
>     directory first. If I do this:
>
>     include_directories(${MPI_Fortran_INCLUDE_PATH})
>
>     I get the failure I mentioned, presumably because the compiler
>     tries to use the gfortran mod first.
>
>     So is there a way to tell the build system to ignore the gfortran
>     mod? I cannot assume that the order or contents of
>     MPI_Fortran_INCLUDE_PATH.
>
>     Thanks
>
>
>
>

-- 
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a, D-70569 Stuttgart
+49 (711) 685-60044

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

From vania.joloboff at inria.fr  Thu Feb 11 03:44:43 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 11 Feb 2016 09:44:43 +0100
Subject: [CMake] how to mix C and C++ modules and link them in a particular
	way ?
In-Reply-To: <56BBB325.60404@simtech.uni-stuttgart.de>
References: <CAOGUJ6E2iEne+dpyPzTmqXVP24-MGipdQR5k0RMdPUL86DHc9w@mail.gmail.com>
 <CAOGUJ6EfegHMAM94FghKK7oVo5X+pkStryhfPKmFenVHf7W9Nw@mail.gmail.com>
 <56BBB325.60404@simtech.uni-stuttgart.de>
Message-ID: <56BC49FB.4050800@inria.fr>

Hi

I have say mod1.cc and mod2.cc that are C++ files
plus mod3.c and mod4.c that are C files
and I need to link them with a specific linker and link
command.
I want to compile them and after that link them
with specific linker command.
I do not want to use the toolchain linker.

I thought the following would work

add_library(Cxxcode OBJECT mod1.cc mod2.cc)
add_library(Ccode OBJECT mod3.c mod4.c)
add_custom_target(prog
  COMMAND "${MY_LINKER} $<TARGET_OBJECTS:Ccode> <TARGET_OBJECTS:Cxxcode> 
  ${MY_LINK_OPTIONS} -o prog"
  COMMENT "Linking mix C++ and C"
  )

But I get error
The evaluation of the TARGET_OBJECTS generator expression is only 
suitable for consumption by CMake.

So how can I do this ?



From irwin at beluga.phys.uvic.ca  Thu Feb 11 03:43:30 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 11 Feb 2016 00:43:30 -0800 (PST)
Subject: [CMake] [ANNOUNCE] CMake 3.5.0-rc2 now ready for testing!
In-Reply-To: <CAFzjYVpv64_4nYke6ESYJQ5o-Ky81-tkE42JoXsZkZecAY7pGg@mail.gmail.com>
References: <CAFzjYVpv64_4nYke6ESYJQ5o-Ky81-tkE42JoXsZkZecAY7pGg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1602102326040.10681@enira.zlyna.ubzr>

On 2016-02-10 15:40-0500 Robert Maynard wrote:

> I am proud to announce the second CMake 3.5 release candidate.

Thanks, CMake developers!

You usually get complaints here from me and other users so I thought I
would send along a success story as well for a software project
(PLplot) that has been using CMake for a decade now.

On my Debian Jessie platform, I just ran a one-hour comprehensive
suite of configurations, builds and tests (one-fourth with ctest in
the build tree, 3-fourths with a largely equivalent set of custom test
commands and targets I have implemented over the years for our
CMake-configured build tree, our installed examples tree using a
CMake-based build system for that, and our installed examples tree
using a traditional (pkg-config + Makefile) build system for that) of
the PLplot core libraries, our plot device drivers, and our standard
set of 33 examples written in the ~10 computer languages that we
support.  I used CMake 3.5.0-rc2 (built by me using the bootstrap
method) to configure this comprhensive set of tests, and the same
version of CTest to run the ctest part of the tests, and everything
passed with flying colors just like it did for the same comprehensive
test of PLplot using cmake versions 3.3.2 and 3.4.3.

In sum, the latest 3.3 and 3.4 releases (i.e., 3.3.2 and 3.4.3) have
been rock solid for my comprehensive Linux tests of PLplot, and it
appears 3.5.0 is already looking similarly good from the PLplot
perspective.

N.B. our build system in the Linux case still uses
cmake_minimum_required(VERSION 3.0.2) to enable users of modern
versions of Linux stable platforms such as Debian stable (a.k.a
jessie) to build PLplot using the system CMake version (3.0.2 for the
Debian stable) rather than having to build their own modern version of
CMake in order to build PLplot.  So the above tests of much more
modern CMake versions were all done for cmake_policy(VERSION 3.0.2).
But I will likely change that to 3.4.3 within a year or so, i.e., when
most stable versions of modern Linux distributions will likely be
released that provide that much more modern version of CMake.

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 nikita.barawade at einfochips.com  Thu Feb 11 04:34:59 2016
From: nikita.barawade at einfochips.com (Nikita Barawade)
Date: Thu, 11 Feb 2016 09:34:59 +0000
Subject: [CMake] Build for x86 architecture through CMake
Message-ID: <PS1PR02MB14019ECA21589545E24BF74186D30@PS1PR02MB1401.apcprd02.prod.outlook.com>



Hi,

My project needs visual studio solution for x86 architecture.
I am using windows 10 with VS2015.

When tried to build using CMake command , there is only option for selecting Win64 or ARM  but no option for x86.
After searching a bit came to know that to build for x86 arch ,I need to use  "NMake Makefiles " .



Regards,
Nikita
************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *************************************************************************************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160211/f0372d9f/attachment.html>

From petr.kmoch at gmail.com  Thu Feb 11 04:51:25 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 11 Feb 2016 10:51:25 +0100
Subject: [CMake] Build for x86 architecture through CMake
In-Reply-To: <PS1PR02MB14019ECA21589545E24BF74186D30@PS1PR02MB1401.apcprd02.prod.outlook.com>
References: <PS1PR02MB14019ECA21589545E24BF74186D30@PS1PR02MB1401.apcprd02.prod.outlook.com>
Message-ID: <CAKohaZdzXpioy6Yk0NObKX0msqGjkkOPfKv4x+YhYZs74ZnFQw@mail.gmail.com>

Hi Nikita,

x86 is the default. If you use a plain -G "Visual Studio 14 2015" generator
without any architecture, it will generate for x86.

Petr

On Thu, Feb 11, 2016 at 10:34 AM, Nikita Barawade <
nikita.barawade at einfochips.com> wrote:

>
>
> Hi,
>
> My project needs visual studio solution for x86 architecture.
> I am using windows 10 with VS2015.
>
> When tried to build using CMake command , there is only option for
> selecting Win64 or ARM  but no option for x86.
> After searching a bit came to know that to build for x86 arch ,I need to
> use  "NMake Makefiles " .
>
>
>
> Regards,
> Nikita
> *************************************************************************************************************************************************************
> eInfochips Business Disclaimer: This e-mail message and all attachments
> transmitted with it are intended solely for the use of the addressee and
> may contain legally privileged and confidential information. If the reader
> of this message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution, copying, or other use
> of this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any views
> expressed in this message are those of the individual sender unless
> otherwise stated. Company has taken enough precautions to prevent the
> spread of viruses. However the company accepts no liability for any damage
> caused by any virus transmitted by this email.
> *************************************************************************************************************************************************************
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160211/554db558/attachment-0001.html>

From ron.arts at gmail.com  Thu Feb 11 07:11:29 2016
From: ron.arts at gmail.com (Ron)
Date: Thu, 11 Feb 2016 13:11:29 +0100
Subject: [CMake] Incorporating cmake dir into configure.ac,
 but it depends on a autconf-managed in-tree library
Message-ID: <CAOAL9USmLJUz8Lq=n62qj8HpEZpbw70KgvhKY2+bym08zTW4Yw@mail.gmail.com>

Hi,

I am working on a project that requires libevent and libevhtp.
The latter is cmake managed, my project and libevent are autoconf managed.

(Note that libevhtp depends on libevent, both depend on openssl, which I
rely
on the system to provide.)

The problem is that I run cmake during the configure step, but during that
time libevent has not been built yet, so libevhtp complains about not
finding
the libevent library.

I have to use in-tree libevent and libevhtp due to features I need, and
libevhtp
not being distributed by the linux distro I use.

What is the best way to approach this?

Thanks,
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160211/78bf1161/attachment.html>

From kristianonline28 at gmail.com  Thu Feb 11 17:56:54 2016
From: kristianonline28 at gmail.com (Kristian)
Date: Thu, 11 Feb 2016 23:56:54 +0100
Subject: [CMake] CMake and BZip2
Message-ID: <CAO5HUhPxg4f4hX1W0Vcv0R8FdSWjrKzV2nNCiXUPFU+MSufazQ@mail.gmail.com>

Hey,

I have a small C++ file, which uses some functions of the library
bzip2. On a Debian derivate, I have installed needed packages with

 * sudo apt-get install bzip2 libzip2 libbz2-dev

Here is my CMakeLists.txt:

=============================

project(bzip2Example)
cmake_minimum_required(VERSION 2.8)

find_package(BZip2)
include_directories(${BZIP2_INCLUDE_DIR})
target_link_libraries(${BZIP2_LIBRARIES})

set(BZIP2_EX_SRC main.cpp)

add_executable(${PROJECT_NAME} ${BZIP2_EX_SRC})

=============================

Then I type in: cmake . && make

This is the output of the make command:
=============================
main.cpp: In function ?int main(int, char**)?:
main.cpp:8:21: warning: deprecated conversion from string constant to
?char*? [-Wwrite-strings]
  char *sourceFile = "test.txt";
                     ^
main.cpp:9:21: warning: deprecated conversion from string constant to
?char*? [-Wwrite-strings]
  char *targetFile = "test.bz2";
                     ^
Linking CXX executable bzip2Ex
CMakeFiles/bzip2Ex.dir/main.cpp.o: In Funktion `main':
main.cpp:(.text+0x15c): Nicht definierter Verweis auf `BZ2_bzWriteOpen'
main.cpp:(.text+0x193): Nicht definierter Verweis auf `BZ2_bzWrite'
main.cpp:(.text+0x1db): Nicht definierter Verweis auf `BZ2_bzWriteClose'
main.cpp:(.text+0x267): Nicht definierter Verweis auf `BZ2_bzWriteClose'
collect2: error: ld returned 1 exit status
make[2]: *** [bzip2Ex] Fehler 1
make[1]: *** [CMakeFiles/bzip2Ex.dir/all] Fehler 2
make: *** [all] Fehler 2

=============================

Why there is the error?

From eike at sf-mail.de  Thu Feb 11 18:44:44 2016
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Fri, 12 Feb 2016 00:44:44 +0100
Subject: [CMake] CMake and BZip2
In-Reply-To: <CAO5HUhPxg4f4hX1W0Vcv0R8FdSWjrKzV2nNCiXUPFU+MSufazQ@mail.gmail.com>
References: <CAO5HUhPxg4f4hX1W0Vcv0R8FdSWjrKzV2nNCiXUPFU+MSufazQ@mail.gmail.com>
Message-ID: <1473554.1eX8Y9UvgD@caliban.sf-tec.de>

Am Donnerstag, 11. Februar 2016, 23:56:54 schrieb Kristian:
> Hey,
> 
> I have a small C++ file, which uses some functions of the library
> bzip2. On a Debian derivate, I have installed needed packages with
> 
>  * sudo apt-get install bzip2 libzip2 libbz2-dev
> 
> Here is my CMakeLists.txt:
> 
> =============================
> 
> project(bzip2Example)
> cmake_minimum_required(VERSION 2.8)
> 
> find_package(BZip2)
> include_directories(${BZIP2_INCLUDE_DIR})
> target_link_libraries(${BZIP2_LIBRARIES})
> 
> set(BZIP2_EX_SRC main.cpp)
> 
> add_executable(${PROJECT_NAME} ${BZIP2_EX_SRC})
> 
> =============================
> 
> Then I type in: cmake . && make
> 
> This is the output of the make command:
> =============================
> main.cpp: In function ?int main(int, char**)?:
> main.cpp:8:21: warning: deprecated conversion from string constant to
> ?char*? [-Wwrite-strings]
>   char *sourceFile = "test.txt";
>                      ^
> main.cpp:9:21: warning: deprecated conversion from string constant to
> ?char*? [-Wwrite-strings]
>   char *targetFile = "test.bz2";
>                      ^
> Linking CXX executable bzip2Ex
> CMakeFiles/bzip2Ex.dir/main.cpp.o: In Funktion `main':
> main.cpp:(.text+0x15c): Nicht definierter Verweis auf `BZ2_bzWriteOpen'
> main.cpp:(.text+0x193): Nicht definierter Verweis auf `BZ2_bzWrite'
> main.cpp:(.text+0x1db): Nicht definierter Verweis auf `BZ2_bzWriteClose'
> main.cpp:(.text+0x267): Nicht definierter Verweis auf `BZ2_bzWriteClose'
> collect2: error: ld returned 1 exit status
> make[2]: *** [bzip2Ex] Fehler 1
> make[1]: *** [CMakeFiles/bzip2Ex.dir/all] Fehler 2
> make: *** [all] Fehler 2
> 
> =============================
> 
> Why there is the error?

You aren't using target_link_libraries right. You need to do:

 target_link_libraries(${PROJECT_NAME} ${BZIP2_LIBRARIES})

HTH

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/20160212/e20e0139/attachment.sig>

From d3ck0r at gmail.com  Thu Feb 11 22:02:00 2016
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 11 Feb 2016 19:02:00 -0800
Subject: [CMake] Windows Whole Program Optimization options
Message-ID: <CAA2GJqUAokz4qxJvFRZ9V0YOn-gn0D0R989NO4zfQDt8U7mL6A@mail.gmail.com>

By default Cmake generates project files with no
<WholeProgramOptimization> set in uhmm...these sections...

  <PropertyGroup
Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|Win32'"
Label="Configuration">
    <ConfigurationType>DynamicLibrary</ConfigurationType>
    <UseOfMfc>false</UseOfMfc>
    <CharacterSet>MultiByte</CharacterSet>
    <PlatformToolset>v140</PlatformToolset>
  </PropertyGroup>


Default for VS14 is - when creating a new project includes
    <WholeProgramOptimization>true</WholeProgramOptimization>



nothing defaults to 'No Whole Program Optimization'
    <WholeProgramOptimization>true equates to 'Use Link Time Code Generation'

There's also guided profile optimization options... but probably less
important for automated builds like cmake produces.

I bring this up because in release mode, with No Whole Program
Optimization there's a bug in the compiler that optimizes away certain
code.  This makes several of my projects fail.  In late december they
confirmed it, but have as of yet not seen any updates to fix said
issue.  Plus, having the optimization option able to be set would be a
bonus anyway since it makes programs smaller.  (Yes, it's kind of
silly that not having optimization doesn't work, one would think that
the optimize option would remove it)

Any thoughts on how this might be specified in cmake?

From mdick at testo.de  Fri Feb 12 02:31:00 2016
From: mdick at testo.de (mdick at testo.de)
Date: Fri, 12 Feb 2016 00:31:00 -0700 (MST)
Subject: [CMake] CMake and TI-cgt compiler problem
Message-ID: <1455262260100-7592779.post@n2.nabble.com>

Hello all together!

Currently I am trying to get the ti-cgt 5.2.5 compiler working with CMake.
Therefore, I use the blinky sample project from TivaWare. 

To keep it simple in a first try, I added all the original flags from the
code composer project into a toolchain file:
#include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic)

set(COMPILER_PATH "C:/git/saveris/toolchains/")	# TODO
set(TI_CGT_PATH "${COMPILER_PATH}/arm-ti-cgt-5.2.5")

# specify the cross compiler
SET(CMAKE_C_COMPILER   ${TI_CGT_PATH}/bin/armcl.exe)
SET(CMAKE_CXX_COMPILER ${CMAKE_C_COMPILER})
SET(CMAKE_ASM_COMPILER ${TI_CGT_PATH}/bin/armasm.exe)
#ENABLE_LANGUAGE(ASM)

# skip compiler tests
set(CMAKE_ASM_COMPILER_WORKS 1) 
set(CMAKE_C_COMPILER_WORKS   1) 
set(CMAKE_CXX_COMPILER_WORKS 1) 
set(CMAKE_DETERMINE_ASM_ABI_COMPILED 1) 
set(CMAKE_DETERMINE_C_ABI_COMPILED   1) 
set(CMAKE_DETERMINE_CXX_ABI_COMPILED 1) 

# Add the default include and lib directories for tool chain
include_directories(${TI_CGT_PATH}/include)
link_directories(${TI_CGT_PATH}lib)

# set target environment
set(CMAKE_FIND_ROOT_PATH ${TI_CGT_PATH})

set(PLATFORM_CONFIG_C_FLAGS "-mv7M4 --code_state=16
--float_support=FPv4SPD16 --abi=eabi -me -O2 -g
--include_path=C:/TI/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/include
--include_path=C:/TI/TivaWare_C_Series-2.1.0.12573 --gcc --define=ccs=ccs
--define=PART_TM4C1294NCPDT --diag_warning=225 --display_error_number
--diag_wrap=off --gen_func_subsections=on --ual" CACHE STRING "platform
config c flags")

# combine flags to C and C++ flags
SET(CMAKE_C_FLAGS "${PLATFORM_CONFIG_C_FLAGS} ${CMAKE_C_FLAGS}" CACHE STRING
"platform config c flags")
SET(CMAKE_CXX_FLAGS "${PLATFORM_CONFIG_CXX_FLAGS} ${CMAKE_CXX_FLAGS}" CACHE
STRING "platform config c flags")

SET(CMAKE_EXE_LINKER_FLAGS "-mv7M4 --code_state=16 --float_support=FPv4SPD16
--abi=eabi -me -O2 -g --define=ccs=\"ccs\" --define=PART_TM4C1294NCPDT
--diag_warning=225 --display_error_number --diag_wrap=off
--gen_func_subsections=on --ual -z --stack_size=256 -mblinky_ccs.map
--heap_size=0 -iC:/TI/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/lib
-iC:/TI/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/include --reread_libs
--warn_sections --display_error_number --diag_wrap=off
--xml_link_info=blinky_linkInfo.xml --rom_model" CACHE STRING "platform
config linker exe files")

Then, when I run CMake and try to build it with make, I get this error:

<Linking>
>> WARNING: invalid linker option --code_state=16 (ignored)
>> WARNING: invalid linker option --float_support=FPv4SPD16 (ignored)
>> WARNING: the --abi=eabi option must be specified before the -z; option
>> ignored
warning: Case insensitivity of options has been deprecated; O must be
written
   as o in future releases
>> WARNING: invalid linker option --gen_func_subsections=on (ignored)
>> WARNING: invalid linker option --ual (ignored)
warning: Option -o is an alias of linker option --output_file. The specified
   argument of 2 is also a valid argument for the compiler option
--opt_level
   (-o). If the intent is to specify the optimization level, the option
should
   be specified before the --run_linker(-z) option. As specified, the output
   file of the linker will be 2
warning #10247-D: creating output section ".text" without a SECTIONS
   specification
warning #10247-D: creating output section ".data" without a SECTIONS
   specification
warning #10247-D: creating output section ".cinit" without a SECTIONS
   specification

 undefined        first referenced
  symbol              in file
 ---------        ----------------
 --define=ccs=ccs

error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "2" not built

>> Compilation failure
jom:
C:\git\saveris\build\none\debug\app/ethernet2cloud/CMakeFiles/ethernet2cloud.dir/build.make
[bin\ethernet2cloud] Error 1
jom: C:\git\saveris\build\none\debug\CMakeFiles/Makefile2
[app\ethernet2cloud\CMakeFiles\ethernet2cloud.dir\all] Error 2
jom: C:\git\saveris\build\none\debug\Makefile [all] Error 2


I found out, that in the build.make file, there are some additional flags
added to the call of the compiler. ?mv7M4? should be the first flag. When I
remove the from CMake added flags in between ?armcl.exe? and ?mv7M4?, the
errors disappear:

cd C:/git/saveris/build/none/debug/app/ethernet2cloud &&
C:/git/saveris/toolchains/arm-ti-cgt-5.2.5/bin/armcl.exe --run_linker
--output_file=../../bin/ethernet2cloud
--map_file=../../bin/ethernet2cloud.map
--search_path=C:/git/saveris/toolchains/arm-ti-cgt-5.2.5lib -mv7M4
--code_state=16 --float_support=FPv4SPD16 --abi=eabi -me -O2 -g
--define=ccs="ccs" --define=PART_TM4C1294NCPDT --diag_warning=225
--display_error_number --diag_wrap=off --gen_func_subsections=on --ual -z
--stack_size=256 -mblinky_ccs.map --heap_size=0
-iC:/TI/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/lib
-iC:/TI/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/include --reread_libs
--warn_sections --display_error_number --diag_wrap=off
--xml_link_info=blinky_linkInfo.xml --rom_model $(ethernet2cloud_OBJECTS)
$(ethernet2cloud_EXTERNAL_OBJECTS)

As a comparison, the flags when I use gcc:
cd C:/git/saveris/build/none/debug/app/ethernet2cloud &&
C:/git/saveris/toolchains/arm-none-eabi-gcc-4.8/bin/arm-none-eabi-gcc.exe
-O0 -fprofile-arcs -ftest-coverage -g -gdwarf-2 -lgcov --coverage
$(ethernet2cloud_OBJECTS) $(ethernet2cloud_EXTERNAL_OBJECTS) -o
../../bin/ethernet2cloud


My question is now: What does CMake do exactly? The flags added to the
compiler are compiler specifiv (?). But where does CMake know from, what it
has to do? If it would know the TI compiler, then I would guess it should
add the correct flags.

Has anyone over done similar experiences?

Thank you all for you answers




--
View this message in context: http://cmake.3232098.n2.nabble.com/CMake-and-TI-cgt-compiler-problem-tp7592779.html
Sent from the CMake mailing list archive at Nabble.com.

From Tomas.Kukosa at ixperta.com  Fri Feb 12 08:24:32 2016
From: Tomas.Kukosa at ixperta.com (=?utf-8?B?S3Vrb3NhIFRvbcOhxaE=?=)
Date: Fri, 12 Feb 2016 13:24:32 +0000
Subject: [CMake] Generator expression $<TARGET_OBJECTS:objLib> in
 add_custom_command()
Message-ID: <56BDDD0F.90004@ixperta.com>

Hi,

would it be possible and useful to support the TARGET_OBJECTS also in 
the add_custom_command() context (COMMAND and DEPENDS options)?

What I need is to build list of objects and than process them by custom 
command.

Best regards,
   Tomas

From omnijack at gmail.com  Fri Feb 12 09:00:52 2016
From: omnijack at gmail.com (Jack Stalnaker)
Date: Fri, 12 Feb 2016 08:00:52 -0600
Subject: [CMake] FindMPI prefer mpirun over mpiexec
Message-ID: <CAOGUJ6HODDpFO_nhHwDUA8DvCuOVkaB_p+HMhS3_xep1pF4Eow@mail.gmail.com>

Hi,

Is there a way to make FindMPI prefer the name 'mpirun' over 'mpiexec'?
They have different meanings to Intel's MPI. By default, FindMPI locates
mpiexec, which runs the MPD based MPI. I'd rather use mpirun. FindMPI knows
mpirun, but in FindMPI.cmake, it looks like mpirun is searched after
mpiexec. Is there a simple solution for this?

--Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160212/80c2a205/attachment.html>

From zbergquist99 at gmail.com  Fri Feb 12 10:51:12 2016
From: zbergquist99 at gmail.com (Zac Bergquist)
Date: Fri, 12 Feb 2016 10:51:12 -0500
Subject: [CMake] CPack with ExternalProjects
Message-ID: <CACfVOFuBEwVF0ADAzzvPxp7F5RWNkZoPkMPe522b-c5oqnf2yg@mail.gmail.com>

Hello,

I have a CMake project that uses CPack to generate a tgz file.  When I
build it and run CPack, it produces project-X.Y.Z in the build directory
(where X, Y, and Z are ${CPACK_PACKAGE_VERSION_MAJOR}/minor/patch).

I recently decided to add a new "super project" that builds both my project
and a few other external projects.  In a new top-level CMakeLists.txt file
I have:

project(super)
cmake_minimum_required(VERSION 3.1)

# build my project
ExternalProject_Add(my_project
   SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/my_project
   BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/my_project
   BUILD_COMMAND ${CMAKE_COMMAND} --build .
   INSTALL_COMMAND ${CMAKE_CPACK_COMMAND})

# Build another custom target
add_custom_target(custom ALL
   WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/custom
   COMMAND make
)

The super project, works well.  It does build both my original project (via
external project) and another item by invoking make with add_custom_target.

I would like to generate a tgz file that contains both the output of my
custom target and the output of running CPack on my external project, but
can't figure out how to do so.  I've tried to use CPack again (one level
higher) or just forego CPack and manually create a tar file, but both
approaches led to new challenges.  Is there some way to generate a new
package containing the output of an external project?

Thanks for any help,
Zac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160212/e1681f4b/attachment-0001.html>

From carlos.osuna at env.ethz.ch  Sun Feb 14 13:33:07 2016
From: carlos.osuna at env.ethz.ch (Osuna Escamilla  Carlos)
Date: Sun, 14 Feb 2016 18:33:07 +0000
Subject: [CMake] isystem include of system library header with CUDA
Message-ID: <6BB4BB61B67A7C4B90A3A7BE26B21B9D38C32EC9@MBX215.d.ethz.ch>

Hi everybody

with cmake I have always used the SYSTEM keyword for the include_directories to include system libraries:

include_directories( SYSTEM ${Boost_INCLUDE_DIRS} )

in order to pass system include directories with compiler with -isystem.
The problem I have is that this does not seem to work with CUDA.

In FindCUDA.cmake, it seems that -I is hardcoded

  if(CUDA_NVCC_INCLUDE_DIRECTORIES)
    foreach(dir ${CUDA_NVCC_INCLUDE_DIRECTORIES})
      list(APPEND CUDA_NVCC_INCLUDE_ARGS -I${dir})
    endforeach()
  endif()

So the question is am I right? Or am I assuming something wrong?
If yes, it would be extremely useful if we could use the same mechanism to pass -isystem to nvcc, to avoid all the warnings from system libraries.

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

From david.vowles at adelaide.edu.au  Sun Feb 14 22:23:08 2016
From: david.vowles at adelaide.edu.au (David Vowles)
Date: Mon, 15 Feb 2016 13:53:08 +1030
Subject: [CMake]  Real arithmetic in CMake
Message-ID: <56C1449C.4060308@adelaide.edu.au>

Does CMake provide facilities to perform real arithmetic?

My attempts using the MATH command fail - for example:

math(EXPR R "5.2")

yields the error:

math cannot parse the expression: "5.2": syntax error, unexpected
exp_NUMBER, expecting $end (3)

----------------------------------------------------------------------------

Has any thought been given to or are there plans by the CMake developers 
to implement their program in a modern scripting language like Python or 
Perl? This would have many advantages including providing a fully 
fledged regular expression language, comprehensive math functions, a 
comprehensive suite of data-structures, etc. Such scripting languages 
have implementations on many platforms.

Many thanks,
David.



From falk.tristram at cognex.com  Mon Feb 15 02:44:02 2016
From: falk.tristram at cognex.com (Tristram, Falk)
Date: Mon, 15 Feb 2016 07:44:02 +0000
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
Message-ID: <9a374021998949f7b1aeb4a068f2e36d@eupaexcp1.europe.pc.cognex.com>

Hi,

this is a nasty problem, preventing suitable compiler detection.
I can confirm it with older versions of CMake, e.g. 3.2.x. Did not recognize it has been fixed in the meanwhile.
If anyone has a suitable solution or patched CMake version, I could help testing it.

Regards,
Falk

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Thibault Genessay
Sent: Dienstag, 9. Februar 2016 15:10
To: cmake at cmake.org
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

Hi,

I'm a long time user of CMake (and huge fan of it) but newly registered on this list, so please forgive me if I have missed something regarding the new 3.5 series.
I use CMake with the GCC ARM Embedded compiler (https://launchpad.net/gcc-arm-embedded<https://urldefense.proofpoint.com/v2/url?u=https-3A__launchpad.net_gcc-2Darm-2Dembedded&d=CwMFaQ&c=VCWpAYkS3z1bOCIxc-BPGZarCq9MRCAVxZJE051VqH8&r=Ee2S2RR_IcVA2riuzsDuYo9W0-YuR65ZmnX9oJ70u5c&m=Ly4Lf_QNoPZw7NLyJgPtadlPnK3hYtbHWzoTFvG3t2k&s=YFTH4j_hy43hY-cPXn1-edRIyxes7EcC5rXO6mAT-Eo&e=>) to cross-compile my project (Windows host, STM32 target, MinGW binutils). Like many users (all?) I had to create a toolchain file because CMake doesn't support this compiler/setup out of the box. I have taken inspiration from the many Google hits and had a working setup until 3.5. This setup relied on the CMAKE_FORCE_<lang>_COMPILER macros.
I installed 3.5 and the build broke, CMake complaining that this macro was deprecated and should not be used because of the many improvements on the compiler detection side. OK, so I removed the offending lines, simply setting the CMAKE_C_COMPILER variable to the compiler's executable ... and suddenly I remember why I did use this FORCE hack in the first place: CMake tells me my compiler is broken because it cannot compile a test program (undefined symbol: _exit). This is somehow correct, as I compile for bare metal and I am providing the _exit function in my code. This is a misunderstanding the CMAKE_FORCE_C_COMPILER works around by simply saying "believe me, this compiler works".
Now I am left without many options: I can't use the FORCE hack, and I can't convince CMake my compiler is OK. I am very open to redesign my toolchain file, or use a stock one from CMake, or whatever this takes, but I simply do not know how to proceed. Actually, I feel my current toolchain file, although functional, is not "clean" but never had enough time to do it. Now that it's a blocking issue, I do have time :)
I rolled back to 3.4 and things work so I'm safe for now. But I would be very glad if somebody knew more about this specific problem, or this compiler, or toolchain file writing in general. I would love to write a "stock" toolchain file for this compiler but I simply do not know enough (nor I can find enough up-to-date documentation).
Thanks for reading,
Cheers
Thibault



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

From gerhard.pobinger at gmx.at  Mon Feb 15 06:08:31 2016
From: gerhard.pobinger at gmx.at (Gerhard Pobinger)
Date: Mon, 15 Feb 2016 11:08:31 +0000 (UTC)
Subject: [CMake]
	=?utf-8?q?how_to_map_configurations_from=09include=5Fexte?=
	=?utf-8?b?cm5hbF9tc3Byb2plY3QoKSA/?=
References: <loom.20160209T132505-754@post.gmane.org>
 <574D7287-B185-4BA5-BCFF-FD116399BBD6@hendrik-sattler.de>
Message-ID: <loom.20160215T115053-657@post.gmane.org>

Hendrik Sattler <post at ...> writes:

> >How can I map a configuration of an external ms-project (e.g.
> >'release_shared') into a configuration (e.g. 'release') of the
> >cmake-generated solution? The problem is that simply adding a
> >configuration
> >named 'release' works, of course, but then I'd have to change the
> >external
> >vcproj...
> 
> ...and additionally this might be impossible/very hard for e.g. qmake
autogenerated vcprojx files.

Does anyone have any input on this issue? If it's not yet possible to do
this, I think this would be a good feature. 

It might 

(a) facilitate the migration from an old vcproj-project base to cmake, and 
(b) help including external projects (that are not under developer's own
control) into cmake builds.

So, any workarounds welcome!



From James.Crosby at arm.com  Mon Feb 15 12:47:24 2016
From: James.Crosby at arm.com (James Crosby)
Date: Mon, 15 Feb 2016 17:47:24 +0000
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <56BB4D3E.6000408@kitware.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <56BA1B94.5000407@kitware.com>
 <CAD-t5VU_dquqkof4Ry85DsoqCJ7DAgDWADOGnxKP7sVim=qEqw@mail.gmail.com>
 <56BB4D3E.6000408@kitware.com>
Message-ID: <CBA97FBC-E730-4E86-B50D-5AB94B61AB14@arm.com>

Hi Brad,

For context, I'm the maintainer of yotta (github: ARMmbed/yotta), a
module system primarily for cross-compiled embedded software, which
uses CMake for the build.

> Basically CMake now needs to detect a lot more from the compiler than
> we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
> We need to make the compiler detection work for everyone.

I'm worried that built-in compiler detection might not be possible across
the variety of cross-compilers used. In some cases, for example, the
existence of a particular compiler, or a modified version of it, might be
a secret outside of the company using it.

> For linking the actual binaries during your build you must have some
> linker scripts.  Perhaps we should provide a way for the toolchain
> file to specify a linker script to use for try_compile checks.  That
> would then be used during the check for a working compiler, ABI check,
> and later try_compile checks to allow them to work as normal but still
> represent the real target platform.  Might that work for this use case?

This could work, but it may be necessary to specify arbitrary flags, and
the format of the link command not just a link script to get a link step to
succeed.

Since the link script that people are actually using to build their program
might contain assertions about the things being linked, or reference
symbols which need to have been defined, it would need to be possible
to use a different link script at this point than in the actual
CMAKE_<LANG>_LINK_X commands.

Using a dummy link command to check that linking works seems to
undermine the purpose of checking in the first place, which suggests
that perhaps it should still be possible to skip the check?

Best regards,
James





IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


From Eric.Erhardt at microsoft.com  Mon Feb 15 23:23:24 2016
From: Eric.Erhardt at microsoft.com (Eric Erhardt)
Date: Tue, 16 Feb 2016 04:23:24 +0000
Subject: [CMake] How does cmake "discover" Visual Studio C++ compilers?
Message-ID: <CY1PR0301MB1530E8A2EEE1C78917723F2A8EAD0@CY1PR0301MB1530.namprd03.prod.outlook.com>

I am trying to get our continuous integration system working in a Windows Docker container.

We use CMake along with the Visual C++ compilers shipped with VS 2015.

I have installed cmake-3.4.3-win32-x86 on the windows container, and also VS 2015 community with just the '/InstallSelectableItems', 'NativeLanguageSupport_VC', so just the C++ tools are installed.

However, when I run cmake -G "Visual Studio 14 2015 Win64", I first get:

The C compiler identification is unknown
The CXX compiler identification is unknown


But then I try running it again, and then the compiler is picked up.

I know the recommendation is "run cmake in a VS developer command prompt", but I'm in a Docker container, so I can't pick my command prompt.

I've tried running vcvarsall.bat in the container during the build before calling cmake -G, but it doesn't fix the issue.

So my question is:  exactly what does cmake look for to pick up the VS compilers?  Does "cl.exe" need to be on the PATH?  Does a certain environment variable need to be set?  Or a registry setting?

Thanks in advance,
Eric Erhardt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160216/c3f72fbc/attachment.html>

From d3ck0r at gmail.com  Tue Feb 16 02:43:40 2016
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 15 Feb 2016 23:43:40 -0800
Subject: [CMake] How does cmake "discover" Visual Studio C++ compilers?
In-Reply-To: <CY1PR0301MB1530E8A2EEE1C78917723F2A8EAD0@CY1PR0301MB1530.namprd03.prod.outlook.com>
References: <CY1PR0301MB1530E8A2EEE1C78917723F2A8EAD0@CY1PR0301MB1530.namprd03.prod.outlook.com>
Message-ID: <CAA2GJqWXHTsvD_enoog-ZRq5snnDBQtXsaiUWxN9sj+XozNFsg@mail.gmail.com>

Is a registry setting...

6.0, 7.0, 7.1, 8.0, 9.0, 10.0,......
HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\InstallDir

HKLM\SOFTWARE\Wow6432Node\Microsoft\VCExpress\12.0\Setup\VC
HKLM\SOFTWARE\Wow6432Node\Microsoft\VCExpress\14.0\Setup\VC

On Mon, Feb 15, 2016 at 8:23 PM, Eric Erhardt
<Eric.Erhardt at microsoft.com> wrote:
> I am trying to get our continuous integration system working in a Windows
> Docker container.
>
>
>
> We use CMake along with the Visual C++ compilers shipped with VS 2015.
>
>
>
> I have installed cmake-3.4.3-win32-x86 on the windows container, and also VS
> 2015 community with just the '/InstallSelectableItems',
> 'NativeLanguageSupport_VC', so just the C++ tools are installed.
>
>
>
> However, when I run cmake -G "Visual Studio 14 2015 Win64", I first get:
>
>
>
> The C compiler identification is unknown
>
> The CXX compiler identification is unknown
>
>
>
>
>
> But then I try running it again, and then the compiler is picked up.
>
>
>
> I know the recommendation is ?run cmake in a VS developer command prompt?,
> but I?m in a Docker container, so I can?t pick my command prompt.
>
>
>
> I?ve tried running vcvarsall.bat in the container during the build before
> calling cmake -G, but it doesn?t fix the issue.
>
>
>
> So my question is:  exactly what does cmake look for to pick up the VS
> compilers?  Does ?cl.exe? need to be on the PATH?  Does a certain
> environment variable need to be set?  Or a registry setting?
>
>
>
> Thanks in advance,
>
> Eric Erhardt
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 elfring at users.sourceforge.net  Tue Feb 16 08:32:49 2016
From: elfring at users.sourceforge.net (SF Markus Elfring)
Date: Tue, 16 Feb 2016 14:32:49 +0100
Subject: [CMake] Collaboration of superbuilds with bundled software
Message-ID: <56C32501.20108@users.sourceforge.net>

Hello,

A variant of the software generation process is described as "superbuild".

Example:
https://cmake.org/Wiki/ParaView/Superbuild

This article mentions the version "2.8.8" as a software dependency for the
tool "CMake". It refers also to the article "Building External Projects with
CMake 2.8" which mentions the version number "2.6.4".
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html

How far can the support for this build approach be also achieved
by older revisions?


I guess that there is some software evolution involved around a command
like "ExternalProject_Add".
https://cmake.org/cmake/help/v3.4/module/ExternalProject.html

* Does this command need to download anything at the beginning?

* Will such a command also work if a needed software component is stored
  together with files in a repository for the main project?

* Would you like to switch between a loadable variant and the bundled revision
  by a configuration option?


Are there any more software development challenges to consider as further
clarification requests might indicate?

* 2015-04-05:
  http://stackoverflow.com/questions/29460893/using-cmake-with-externalproject-add

* 2013-07-03:
  http://stackoverflow.com/questions/17446981/cmake-externalproject-add-and-findpackage

Regards,
Markus

From nioncode at gmail.com  Tue Feb 16 17:24:57 2016
From: nioncode at gmail.com (Nicolas Schneider)
Date: Tue, 16 Feb 2016 23:24:57 +0100
Subject: [CMake] Compiler detection fails for custom Visual Studio Toolset
Message-ID: <56C3A1B9.3080401@gmail.com>

I'm trying to build a Windows Driver with CMake, which requires using
the 'WindowsUserModeDriver10.0' PlatformToolset.

Trying to use this Toolset with CMake fails:
cmake -T "WindowsUserModeDriver10.0" ..
>   ClCompile:
> 
>     C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /IcmTC_b2982.dir\Debug\ /Zi /W3 /WX /Od /Ob0 /O
> y- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _X86_=1 /D i386=1 /D STD_CALL /D WIN32_LEAN_AND_MEAN=1
> /D _WIN32_WINNT=0x0A00 /D WINVER=0x0A00 /D WINNT=1 /D NTDDI_VERSION=0x0A000001 /D _MBCS /D UMDF_VERSION_MAJOR=2 /D UMDF_
> VERSION_MINOR=15 /D UMDF_USING_NTSTATUS /D _UNICODE /D UNICODE /GF /Gm- /RTC1 /MDd /Zp8 /GS /Gy /fp:precise /Zc:wchar_t-
>  /Zc:forScope /Zc:inline /GR- /Fo"cmTC_b2982.dir\Debug\\" /Fd"cmTC_b2982.dir\Debug\vc140.pdb" /Gz /TC /wd4603 /wd4627 /w
> d4986 /wd4987 /wd4996 /FI"C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\shared\warning.h" /analyze- /error
> Report:queue /d1import_no_registry /d2AllowCompatibleILVersions /d2Zi+ "C:\vagrant\WindowsDriver\cmake-bug\build\CMakeFi
> les\CMakeTmp\testCCompiler.c"
>     Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86
>     Copyright (C) Microsoft Corporation.  All rights reserved.
> 
>     cl /c /IcmTC_b2982.dir\Debug\ /Zi /W3 /WX /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /
> D _X86_=1 /D i386=1 /D STD_CALL /D WIN32_LEAN_AND_MEAN=1 /D _WIN32_WINNT=0x0A00 /D WINVER=0x0A00 /D WINNT=1 /D NTDDI_VER
> SION=0x0A000001 /D _MBCS /D UMDF_VERSION_MAJOR=2 /D UMDF_VERSION_MINOR=15 /D UMDF_USING_NTSTATUS /D _UNICODE /D UNICODE
> /GF /Gm- /RTC1 /MDd /Zp8 /GS /Gy /fp:precise /Zc:wchar_t- /Zc:forScope /Zc:inline /GR- /Fo"cmTC_b2982.dir\Debug\\" /Fd"c
> mTC_b2982.dir\Debug\vc140.pdb" /Gz /TC /wd4603 /wd4627 /wd4986 /wd4987 /wd4996 /FI"C:\Program Files (x86)\Windows Kits\1
> 0\Include\10.0.10586.0\shared\warning.h" /analyze- /errorReport:queue /d1import_no_registry /d2AllowCompatibleILVersions
>  /d2Zi+ "C:\vagrant\WindowsDriver\cmake-bug\build\CMakeFiles\CMakeTmp\testCCompiler.c"
> 
>     testCCompiler.c
> 
> 
>   C:\vagrant\WindowsDriver\cmake-bug\build\CMakeFiles\CMakeTmp\testCCompiler.c(11):
>   error C2220: warning treated as error - no 'object' file generated
>   [C:\vagrant\WindowsDriver\cmake-bug\build\CMakeFiles\CMakeTmp\cmTC_b2982.vcxproj]
> 
> 
> 
>   C:\vagrant\WindowsDriver\cmake-bug\build\CMakeFiles\CMakeTmp\testCCompiler.c(11):
>   warning C4007: 'main': must be '__cdecl'
>   [C:\vagrant\WindowsDriver\cmake-bug\build\CMakeFiles\CMakeTmp\cmTC_b2982.vcxproj]

The main function of testCCompiler.c must be changed to __cdecl in order
to pass the compilation test.

To bypass this issue, I currently do use: `cmake -T
"WindowsUserModeDriver10.0" -DCMAKE_C_COMPILER_WORKS=1
-DCMAKE_CXX_COMPILER_WORKS=1 ..`

which I rather would not.
Also, incremental linking must be disabled even for Debug Builds,
otherwise the build fails. So after configuring, I compile with `cmake
--build . -- /p:LinkIncremental=false`

It would be great if incremental build could be disabled for Windows
Driver Toolsets directly in the vcxproj so that other developers can
build from the Visual Studio Gui without issues.

Any thoughts on that?

From csiga.biga at aol.com  Wed Feb 17 05:23:20 2016
From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=)
Date: Wed, 17 Feb 2016 11:23:20 +0100
Subject: [CMake] compiler independent compiler flags
In-Reply-To: <9ADDEE8B-BB2B-4311-841A-04DE5D02218E@awi.de>
References: <9ADDEE8B-BB2B-4311-841A-04DE5D02218E@awi.de>
Message-ID: <mailman.8.1455704605.8417.cmake@cmake.org>

Hi Jan,

Unfortunately, I cannot help you in this regard, though I am surprised how little attention this question gained. I too feel that CMake could do better both in this regard. While ABI detection is very well done, BUILD_TYPE seems to be the only compiler agnostic option available. I do not know how to set warning levels for eg. in a compiler agnostic manner. Aside from this, there are dozens of other options that are common to all C++ compilers and it would rock if I need not look up the exact params for all of them.

Sorry I could not help, but I do feel the struggle.

Cheers,
M?t?

Felad?: ? Jan Hegewald
Elk?ldve: 2016. febru?r 5., p?ntek 11:36
C?mzett: cmake at cmake.org
T?rgy: [CMake] compiler independent compiler flags

Dear all,
do you know a best practice on how to specify compiler flags without knowing in advance which compiler will be used?
Its about Fortran projects, where I e.g. want to explicitly enable the preprocessor, or make all default real values 8 byte wide. This could be done as such:
if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")
  set(CMAKE_Fortran_FLAGS "-fpp -r8")
elseif(${CMAKE_Fortran_COMPILER_ID} STREQUAL "GNU")
  set(CMAKE_Fortran_FLAGS "-cpp -fdefault-real-8")
endif()

Cmake has the cmake-compile-features and I though maybe some similar mechanism exists for above mentioned compiler switches. So I could say
target_compile_features(mylib PRIVATE f_preprocessor f_real_8)

Thanks for sharing your advise,
Jan


-- 

Powered by www.kitware.com

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

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

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

From petr.kmoch at gmail.com  Wed Feb 17 06:11:55 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 17 Feb 2016 12:11:55 +0100
Subject: [CMake] compiler independent compiler flags
In-Reply-To: <20160217102326.027BAE569E@public.kitware.com>
References: <9ADDEE8B-BB2B-4311-841A-04DE5D02218E@awi.de>
 <20160217102326.027BAE569E@public.kitware.com>
Message-ID: <CAKohaZeXW1fPgPG17YMcpDjZ-H+UxseA5eDiSoRderdox7VqEA@mail.gmail.com>

Hi.

There is certainly room for providing more, but BUILD_TYPE is not the only
option settable in a compiler-agnostic way. There are target properties:

C_STANDARD
CXX_STANDARD
INCLUDE_DIRECTORIES
INTERPROCEDURAL_OPTIMIZATION
POSITION_INDEPENDENT_CODE
WIN32_EXECUTABLE

and maybe more (I do not claim the list above to be exhaustive).

Petr

On Wed, Feb 17, 2016 at 11:23 AM, Nagy-Egri M?t? Ferenc <cmake at cmake.org>
wrote:

> Hi Jan,
>
>
>
> Unfortunately, I cannot help you in this regard, though I am surprised how
> little attention this question gained. I too feel that CMake could do
> better both in this regard. While ABI detection is very well done,
> BUILD_TYPE seems to be the only compiler agnostic option available. I do
> not know how to set warning levels for eg. in a compiler agnostic manner.
> Aside from this, there are dozens of other options that are common to all
> C++ compilers and it would rock if I need not look up the exact params for
> all of them.
>
>
>
> Sorry I could not help, but I do feel the struggle.
>
>
>
> Cheers,
>
> M?t?
>
>
>
> *Felad?: *? Jan Hegewald <jan.hegewald at awi.de>
> *Elk?ldve: *2016. febru?r 5., p?ntek 11:36
> *C?mzett: *cmake at cmake.org
> *T?rgy: *[CMake] compiler independent compiler flags
>
>
>
> Dear all,
>
> do you know a best practice on how to specify compiler flags without
> knowing in advance which compiler will be used?
>
> Its about Fortran projects, where I e.g. want to explicitly enable the
> preprocessor, or make all default real values 8 byte wide. This could be
> done as such:
>
> if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")
>
>   set(CMAKE_Fortran_FLAGS "-fpp -r8")
>
> elseif(${CMAKE_Fortran_COMPILER_ID} STREQUAL "GNU")
>
>   set(CMAKE_Fortran_FLAGS "-cpp -fdefault-real-8")
>
> endif()
>
>
>
> Cmake has the cmake-compile-features and I though maybe some similar
> mechanism exists for above mentioned compiler switches. So I could say
>
> target_compile_features(mylib PRIVATE f_preprocessor f_real_8)
>
>
>
> Thanks for sharing your advise,
>
> Jan
>
>
>
>
>
> --
>
>
>
> Powered by www.kitware.com
>
>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
>
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
>
>
> CMake Support: http://cmake.org/cmake/help/support.html
>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
>
>
> Follow this link to subscribe/unsubscribe:
>
> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160217/82eb7b98/attachment.html>

From jan.hegewald at awi.de  Wed Feb 17 07:45:19 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Wed, 17 Feb 2016 13:45:19 +0100
Subject: [CMake] compiler wrappers and linking libraries
Message-ID: <A130D1AB-B402-4662-92FF-E4619AE2DC84@awi.de>

Dear all,
on a system with a cray compiler environment cmake fails to find a blas capable library via

	find_package(BLAS) 

The compilers on this system are wrappers which already link the local blas libraries (from the cray-libsci library). I guess this is why a call to

	check_fortran_function_exists(sgemm HAS_BLAS)
or
	check_function_exists(cblas_sgemm HAS_BLAS)

actually succeeds. (sgemm is a symbol from BLAS)

So the code requires blas functionality, but I can not just call find_package(BLAS) and then add the BLAS_LIBRARIES to the targets linker flags as on other platforms.
Do you think we should refine the FindBLAS.cmake to actually detect if blas is already be found by the compiler/linker and then set BLAS_FOUND to true and BLAS_LIBRARIES to an empty list?

Thanks for any thoughts about this,
Jan 

From jan.hegewald at awi.de  Wed Feb 17 07:47:55 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Wed, 17 Feb 2016 13:47:55 +0100
Subject: [CMake] compiler independent compiler flags
In-Reply-To: <20160217102326.54570E56A1@public.kitware.com>
References: <9ADDEE8B-BB2B-4311-841A-04DE5D02218E@awi.de>
 <20160217102326.54570E56A1@public.kitware.com>
Message-ID: <63583D0F-6C3D-4E22-85EA-335001D6DD6D@awi.de>


> On 17.02.2016, at 11:23, Nagy-Egri M?t? Ferenc via CMake <cmake at cmake.org> wrote:
> 
> Sorry I could not help, but I do feel the struggle.

LOL, yes. Struggle might be the right term.

Best,
Jan

From brad.king at kitware.com  Wed Feb 17 09:40:57 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 17 Feb 2016 09:40:57 -0500
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
In-Reply-To: <CBA97FBC-E730-4E86-B50D-5AB94B61AB14@arm.com>
References: <CAD-t5VV-ksNqxbHcDP6V-45OrS1xZ+ZWXACtfsm2NoR=EQGsvQ@mail.gmail.com>
 <56BA1B94.5000407@kitware.com>
 <CAD-t5VU_dquqkof4Ry85DsoqCJ7DAgDWADOGnxKP7sVim=qEqw@mail.gmail.com>
 <56BB4D3E.6000408@kitware.com> <CBA97FBC-E730-4E86-B50D-5AB94B61AB14@arm.com>
Message-ID: <56C48679.1020902@kitware.com>

On 02/15/2016 12:47 PM, James Crosby wrote:
> Using a dummy link command to check that linking works seems to
> undermine the purpose of checking in the first place, which suggests
> that perhaps it should still be possible to skip the check?

For reference, this discussion has moved to the cmake-developer list:

 Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
 https://cmake.org/pipermail/cmake-developers/2016-February/027818.html

-Brad


From ruslan_baratov at yahoo.com  Wed Feb 17 12:11:04 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Thu, 18 Feb 2016 00:11:04 +0700
Subject: [CMake] compiler independent compiler flags
In-Reply-To: <20160217102325.77689E569B@public.kitware.com>
References: <9ADDEE8B-BB2B-4311-841A-04DE5D02218E@awi.de>
 <20160217102325.77689E569B@public.kitware.com>
Message-ID: <56C4A9A8.6070908@yahoo.com>

On 17-Feb-16 17:23, Nagy-Egri M?t? Ferenc via CMake wrote:
>
> Unfortunately, I cannot help you in this regard, though I am surprised 
> how little attention this question gained. I too feel that CMake could 
> do better both in this regard. While ABI detection is very well done, 
> BUILD_TYPE seems to be the only compiler agnostic option available.
>
...

> I do not know how to set warning levels for eg. in a compiler agnostic 
> manner
>
Just for your information: 
http://stackoverflow.com/questions/2368811/how-to-set-warning-level-in-cmake/24379666#24379666

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160218/1595cad2/attachment.html>

From a.neundorf-work at gmx.net  Wed Feb 17 16:04:24 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Wed, 17 Feb 2016 22:04:24 +0100
Subject: [CMake] Incorporating cmake dir into configure.ac,
	but it depends on a autconf-managed in-tree library
In-Reply-To: <CAOAL9USmLJUz8Lq=n62qj8HpEZpbw70KgvhKY2+bym08zTW4Yw@mail.gmail.com>
References: <CAOAL9USmLJUz8Lq=n62qj8HpEZpbw70KgvhKY2+bym08zTW4Yw@mail.gmail.com>
Message-ID: <1811638.ZBsaHd6kDO@tuxedo.neundorf.net>

On Thursday, February 11, 2016 13:11:29 Ron wrote:
> Hi,
> 
> I am working on a project that requires libevent and libevhtp.
> The latter is cmake managed, my project and libevent are autoconf managed.
> 
> (Note that libevhtp depends on libevent, both depend on openssl, which I
> rely
> on the system to provide.)
> 
> The problem is that I run cmake during the configure step, but during that
> time libevent has not been built yet, so libevhtp complains about not
> finding
> the libevent library.
> 
> I have to use in-tree libevent and libevhtp due to features I need, and
> libevhtp
> not being distributed by the linux distro I use.
> 
> What is the best way to approach this?

you should have a look how libevhtp searches for libevent.
If it does a bunch of find_library()/find_path() calls, those set cmake cacge 
variables, but only if they are not set yet.
So if you know where libevent will put its stuff, you can preset those cmake 
cache variables (e.g. using cmake -D ...)

Alex


From sam.habiel at gmail.com  Thu Feb 18 03:44:35 2016
From: sam.habiel at gmail.com (Sam Habiel)
Date: Thu, 18 Feb 2016 00:44:35 -0800
Subject: [CMake] Can't get CMake to use an import library generated from a
	MODULE target
Message-ID: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>

Rather than email one of the folks at Kitware, I decided to join the
CMake mailing list... Hello all for those who remember me.

I apologize for the long email.

A few of us have been trying to port GT.M
(https://www.fisglobal.com/Solutions/Services/Database-Engine) to
Cygwin, 1. to get it running on Windows 2. as an exercise to prepare
for harder ports, the Raspberry Pi being the holy grail here. That's
the background.

The problem we are having is familiar to many; but not initially to
me. See the heading "Shared libraries with Windows/MinGW" in this
article: http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.

CMakeLists.txt:
https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt

The error:
[ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
In function `gc_load_gtmshr_symbols':
/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined
reference to `gtm_malloc'
/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined
reference to `gtm_free'
collect2: error: ld returned 1 exit status
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe
for target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
CMakeFiles/Makefile2:891: recipe for target
'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
-shared -Wl,--enable-auto-import -o
plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
-lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a

What is missing is that there needs to be either a link to
cyggtmshr.dll, or a way for CMake to know to generate a
libgtmshr_import.lib and add it to the link command.

So here is what I tried:
1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
If I do that, it doesn't seem to generate the import library; but it
sure does generate an export header, which I don't need. Here it is:
include(GenerateExportHeader)
generate_export_header(libgtmshr
    BASE_NAME libgtmshr
    EXPORT_MACRO_NAME libgtmshr_EXPORTS
    EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
    STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)

2. Explicitly adding a libgtmshr as a dependency on line
https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
but only for Cygwin. I get this error message:
CMake Error at CMakeLists.txt:542 (target_link_libraries):
  Target "libgtmshr" of type MODULE_LIBRARY may not be linked into another
  target.  One may link only to STATIC or SHARED libraries, or to executables
  with the ENABLE_EXPORTS property set.

The GT.M developer familiar with CMake suggested me to use LINK_FLAGS
and have CMake use the file by us hardcoding it in; which I am okay
doing, but I thought I would check to see if there is an alternative
way of doing this.

I also tried the suggestions here:
"https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/"
to no avail.

Last, but not least:

sam at horus ~/fis-gtm-cygwin
$ cmake --version
cmake version 3.4.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

sam at horus ~/fis-gtm-cygwin
$ uname -a
CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network

From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de  Thu Feb 18 03:46:49 2016
From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian)
Date: Thu, 18 Feb 2016 08:46:49 +0000
Subject: [CMake] Can't get CMake to use an import library generated from
 a	MODULE target
In-Reply-To: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
References: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
Message-ID: <8D981219EEA621479C112DA9BDC39A8E46F9C66F@EXMBS1.ad.igd.fraunhofer.de>

Why are you trying to link a MODULE? The add_library should be changed to SHARED not MODULE.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de


-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Sam Habiel
Sent: Thursday, February 18, 2016 09:45
To: cmake at cmake.org
Subject: [CMake] Can't get CMake to use an import library generated from a MODULE target

Rather than email one of the folks at Kitware, I decided to join the CMake mailing list... Hello all for those who remember me.

I apologize for the long email.

A few of us have been trying to port GT.M
(https://www.fisglobal.com/Solutions/Services/Database-Engine) to Cygwin, 1. to get it running on Windows 2. as an exercise to prepare for harder ports, the Raspberry Pi being the holy grail here. That's the background.

The problem we are having is familiar to many; but not initially to me. See the heading "Shared libraries with Windows/MinGW" in this
article: http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.

CMakeLists.txt:
https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt

The error:
[ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
In function `gc_load_gtmshr_symbols':
/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined reference to `gtm_malloc'
/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined reference to `gtm_free'
collect2: error: ld returned 1 exit status
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe for target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
CMakeFiles/Makefile2:891: recipe for target 'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG -shared -Wl,--enable-auto-import -o plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
-lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a

What is missing is that there needs to be either a link to cyggtmshr.dll, or a way for CMake to know to generate a libgtmshr_import.lib and add it to the link command.

So here is what I tried:
1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
If I do that, it doesn't seem to generate the import library; but it sure does generate an export header, which I don't need. Here it is:
include(GenerateExportHeader)
generate_export_header(libgtmshr
    BASE_NAME libgtmshr
    EXPORT_MACRO_NAME libgtmshr_EXPORTS
    EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
    STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)

2. Explicitly adding a libgtmshr as a dependency on line https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
but only for Cygwin. I get this error message:
CMake Error at CMakeLists.txt:542 (target_link_libraries):
  Target "libgtmshr" of type MODULE_LIBRARY may not be linked into another
  target.  One may link only to STATIC or SHARED libraries, or to executables
  with the ENABLE_EXPORTS property set.

The GT.M developer familiar with CMake suggested me to use LINK_FLAGS and have CMake use the file by us hardcoding it in; which I am okay doing, but I thought I would check to see if there is an alternative way of doing this.

I also tried the suggestions here:
"https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/"
to no avail.

Last, but not least:

sam at horus ~/fis-gtm-cygwin
$ cmake --version
cmake version 3.4.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

sam at horus ~/fis-gtm-cygwin
$ uname -a
CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

--
Sam Habiel, Pharm.D.
VISTA Expertise Network
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 sam.habiel at gmail.com  Thu Feb 18 03:59:11 2016
From: sam.habiel at gmail.com (Sam Habiel)
Date: Thu, 18 Feb 2016 00:59:11 -0800
Subject: [CMake] Can't get CMake to use an import library generated from
	a MODULE target
In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E46F9C66F@EXMBS1.ad.igd.fraunhofer.de>
References: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E46F9C66F@EXMBS1.ad.igd.fraunhofer.de>
Message-ID: <CABHT961CruFko_kCUtap4DT+gRwKM0G2MfiDgSf1qYdgnga9jg@mail.gmail.com>

https://cmake.org/cmake/help/v3.0/command/add_library.html

The module library (libgtmshr) is dlopened from the main exe. It's not
supposed to be linked, except for Cygwin.

On Thursday, February 18, 2016, Mueller-Roemer, Johannes Sebastian <
Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:

> Why are you trying to link a MODULE? The add_library should be changed to
> SHARED not MODULE.
>
> --
> Johannes S. Mueller-Roemer, MSc
> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>
> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
> johannes.mueller-roemer at igd.fraunhofer.de <javascript:;>  |
> www.igd.fraunhofer.de
>
>
> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org <javascript:;>] On Behalf Of
> Sam Habiel
> Sent: Thursday, February 18, 2016 09:45
> To: cmake at cmake.org <javascript:;>
> Subject: [CMake] Can't get CMake to use an import library generated from a
> MODULE target
>
> Rather than email one of the folks at Kitware, I decided to join the CMake
> mailing list... Hello all for those who remember me.
>
> I apologize for the long email.
>
> A few of us have been trying to port GT.M
> (https://www.fisglobal.com/Solutions/Services/Database-Engine) to Cygwin,
> 1. to get it running on Windows 2. as an exercise to prepare for harder
> ports, the Raspberry Pi being the holy grail here. That's the background.
>
> The problem we are having is familiar to many; but not initially to me.
> See the heading "Shared libraries with Windows/MinGW" in this
> article:
> http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/
> .
>
> CMakeLists.txt:
> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>
> The error:
> [ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
> In function `gc_load_gtmshr_symbols':
> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined reference
> to `gtm_malloc'
> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined reference
> to `gtm_free'
> collect2: error: ld returned 1 exit status
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe for
> target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
> make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
> CMakeFiles/Makefile2:891: recipe for target
> 'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
> make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
> Makefile:116: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
> /usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
> -Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG -shared
> -Wl,--enable-auto-import -o plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
> -Wl,--major-image-version,0,--minor-image-version,0
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
> -lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>
> What is missing is that there needs to be either a link to cyggtmshr.dll,
> or a way for CMake to know to generate a libgtmshr_import.lib and add it to
> the link command.
>
> So here is what I tried:
> 1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
> If I do that, it doesn't seem to generate the import library; but it sure
> does generate an export header, which I don't need. Here it is:
> include(GenerateExportHeader)
> generate_export_header(libgtmshr
>     BASE_NAME libgtmshr
>     EXPORT_MACRO_NAME libgtmshr_EXPORTS
>     EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>     STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>
> 2. Explicitly adding a libgtmshr as a dependency on line
> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
> but only for Cygwin. I get this error message:
> CMake Error at CMakeLists.txt:542 (target_link_libraries):
>   Target "libgtmshr" of type MODULE_LIBRARY may not be linked into another
>   target.  One may link only to STATIC or SHARED libraries, or to
> executables
>   with the ENABLE_EXPORTS property set.
>
> The GT.M developer familiar with CMake suggested me to use LINK_FLAGS and
> have CMake use the file by us hardcoding it in; which I am okay doing, but
> I thought I would check to see if there is an alternative way of doing this.
>
> I also tried the suggestions here:
> "
> https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/
> "
> to no avail.
>
> Last, but not least:
>
> sam at horus ~/fis-gtm-cygwin
> $ cmake --version
> cmake version 3.4.3
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>
> sam at horus ~/fis-gtm-cygwin
> $ uname -a
> CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin
>
> --
> Sam Habiel, Pharm.D.
> VISTA Expertise Network
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
>


-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160218/d0431752/attachment-0001.html>

From petr.kmoch at gmail.com  Thu Feb 18 04:04:42 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 18 Feb 2016 10:04:42 +0100
Subject: [CMake] Can't get CMake to use an import library generated from
 a MODULE target
In-Reply-To: <CABHT961CruFko_kCUtap4DT+gRwKM0G2MfiDgSf1qYdgnga9jg@mail.gmail.com>
References: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E46F9C66F@EXMBS1.ad.igd.fraunhofer.de>
 <CABHT961CruFko_kCUtap4DT+gRwKM0G2MfiDgSf1qYdgnga9jg@mail.gmail.com>
Message-ID: <CAKohaZd4_=YJM5+ycO-D1mrp36ZY6+KKjGxWMd-Bm7cZLs0rQg@mail.gmail.com>

Then I would suggest something like

if(CYGWIN)
  set(libType SHARED)
else()
  set(libType MODULE)
endif()

add_library(TheProblematicOne ${libType} ...)

Petr

On Thu, Feb 18, 2016 at 9:59 AM, Sam Habiel <sam.habiel at gmail.com> wrote:

> https://cmake.org/cmake/help/v3.0/command/add_library.html
>
> The module library (libgtmshr) is dlopened from the main exe. It's not
> supposed to be linked, except for Cygwin.
>
>
> On Thursday, February 18, 2016, Mueller-Roemer, Johannes Sebastian <
> Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>
>> Why are you trying to link a MODULE? The add_library should be changed to
>> SHARED not MODULE.
>>
>> --
>> Johannes S. Mueller-Roemer, MSc
>> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>>
>> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>> johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de
>>
>>
>> -----Original Message-----
>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Sam Habiel
>> Sent: Thursday, February 18, 2016 09:45
>> To: cmake at cmake.org
>> Subject: [CMake] Can't get CMake to use an import library generated from
>> a MODULE target
>>
>> Rather than email one of the folks at Kitware, I decided to join the
>> CMake mailing list... Hello all for those who remember me.
>>
>> I apologize for the long email.
>>
>> A few of us have been trying to port GT.M
>> (https://www.fisglobal.com/Solutions/Services/Database-Engine) to
>> Cygwin, 1. to get it running on Windows 2. as an exercise to prepare for
>> harder ports, the Raspberry Pi being the holy grail here. That's the
>> background.
>>
>> The problem we are having is familiar to many; but not initially to me.
>> See the heading "Shared libraries with Windows/MinGW" in this
>> article:
>> http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/
>> .
>>
>> CMakeLists.txt:
>> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>>
>> The error:
>> [ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
>> In function `gc_load_gtmshr_symbols':
>> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined reference
>> to `gtm_malloc'
>> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined reference
>> to `gtm_free'
>> collect2: error: ld returned 1 exit status
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe for
>> target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
>> make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
>> CMakeFiles/Makefile2:891: recipe for target
>> 'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
>> make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
>> Makefile:116: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>> Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
>> /usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
>> -Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG -shared
>> -Wl,--enable-auto-import -o plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>> -Wl,--major-image-version,0,--minor-image-version,0
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
>>
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
>>
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
>> -lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>>
>> What is missing is that there needs to be either a link to cyggtmshr.dll,
>> or a way for CMake to know to generate a libgtmshr_import.lib and add it to
>> the link command.
>>
>> So here is what I tried:
>> 1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
>> If I do that, it doesn't seem to generate the import library; but it sure
>> does generate an export header, which I don't need. Here it is:
>> include(GenerateExportHeader)
>> generate_export_header(libgtmshr
>>     BASE_NAME libgtmshr
>>     EXPORT_MACRO_NAME libgtmshr_EXPORTS
>>     EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>>     STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>>
>> 2. Explicitly adding a libgtmshr as a dependency on line
>> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
>> but only for Cygwin. I get this error message:
>> CMake Error at CMakeLists.txt:542 (target_link_libraries):
>>   Target "libgtmshr" of type MODULE_LIBRARY may not be linked into another
>>   target.  One may link only to STATIC or SHARED libraries, or to
>> executables
>>   with the ENABLE_EXPORTS property set.
>>
>> The GT.M developer familiar with CMake suggested me to use LINK_FLAGS and
>> have CMake use the file by us hardcoding it in; which I am okay doing, but
>> I thought I would check to see if there is an alternative way of doing this.
>>
>> I also tried the suggestions here:
>> "
>> https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/
>> "
>> to no avail.
>>
>> Last, but not least:
>>
>> sam at horus ~/fis-gtm-cygwin
>> $ cmake --version
>> cmake version 3.4.3
>>
>> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>>
>> sam at horus ~/fis-gtm-cygwin
>> $ uname -a
>> CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin
>>
>> --
>> Sam Habiel, Pharm.D.
>> VISTA Expertise Network
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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
>>
>
>
> --
> Sam Habiel, Pharm.D.
> VISTA Expertise Network
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160218/6ba752ab/attachment.html>

From post at hendrik-sattler.de  Thu Feb 18 06:54:26 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Thu, 18 Feb 2016 12:54:26 +0100
Subject: [CMake] Can't get CMake to use an import library generated from
	a	MODULE target
In-Reply-To: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
References: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
Message-ID: <04E7BB51-8195-40E7-ACA5-6A71F2873772@hendrik-sattler.de>



Am 18. Februar 2016 09:44:35 MEZ, schrieb Sam Habiel <sam.habiel at gmail.com>:
>Rather than email one of the folks at Kitware, I decided to join the
>CMake mailing list... Hello all for those who remember me.
>
>I apologize for the long email.
>
>A few of us have been trying to port GT.M
>(https://www.fisglobal.com/Solutions/Services/Database-Engine) to
>Cygwin, 1. to get it running on Windows 2. as an exercise to prepare
>for harder ports, the Raspberry Pi being the holy grail here. That's
>the background.

And then you try Cygwin? That's about as close to Rasberry Pi on Linux as bare Windows itself. Especially your problem from below is only caused by Windows.

>The problem we are having is familiar to many; but not initially to
>me. See the heading "Shared libraries with Windows/MinGW" in this
>article:
>http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.
>
>CMakeLists.txt:
>https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>
>The error:
>[ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
>In function `gc_load_gtmshr_symbols':
>/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined
>reference to `gtm_malloc'
>/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined
>reference to `gtm_free'
>collect2: error: ld returned 1 exit status
>CMakeFiles

Looking at these locations, it is clear that you store a reference to a function, there. The reference cannot be resolved but for a Windows DLL all references must be resolved at link time.

/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe
>for target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
>make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
>CMakeFiles/Makefile2:891: recipe for target
>'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
>make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error
>2
>Makefile:116: recipe for target 'all' failed
>make: *** [all] Error 2
>
>Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
>/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
>-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
>-shared -Wl,--enable-auto-import -o
>plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>-Wl,--major-image-version,0,--minor-image-version,0
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
>-lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>
>What is missing is that there needs to be either a link to
>cyggtmshr.dll, or a way for CMake to know to generate a
>libgtmshr_import.lib and add it to the link command.
 
Or don't use a direct reference in the code but use the module that provides those functions at runtime like you designed it to. You can use local wrapper functions to do so.

>So here is what I tried:
>1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
>If I do that, it doesn't seem to generate the import library; but it
>sure does generate an export header, which I don't need. Here it is:
>include(GenerateExportHeader)
>generate_export_header(libgtmshr
>    BASE_NAME libgtmshr
>    EXPORT_MACRO_NAME libgtmshr_EXPORTS
>    EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>    STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>
>2. Explicitly adding a libgtmshr as a dependency on line
>https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
>but only for Cygwin. I get this error message:
>CMake Error at CMakeLists.txt:542 (target_link_libraries):
>Target "libgtmshr" of type MODULE_LIBRARY may not be linked into
>another
>target.  One may link only to STATIC or SHARED libraries, or to
>executables
>  with the ENABLE_EXPORTS property set.
>
>The GT.M developer familiar with CMake suggested me to use LINK_FLAGS
>and have CMake use the file by us hardcoding it in; which I am okay
>doing, but I thought I would check to see if there is an alternative
>way of doing this.
>
>I also tried the suggestions here:
>"https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/"
>to no avail.
>
>Last, but not least:
>
>sam at horus ~/fis-gtm-cygwin
>$ cmake --version
>cmake version 3.4.3
>
>CMake suite maintained and supported by Kitware (kitware.com/cmake).
>
>sam at horus ~/fis-gtm-cygwin
>$ uname -a
>CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin


From robert.maynard at kitware.com  Thu Feb 18 16:01:30 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 18 Feb 2016 16:01:30 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.5.0-rc3 is now ready!
Message-ID: <CAFzjYVpmPN1VrTZgFG_SuNSHkAL35Y0SaOpbZ8hOwzRBW5Q5iQ@mail.gmail.com>

I am proud to announce the third CMake 3.5 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

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

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

Some of the more significant features of CMake 3.5 are:

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC
  now provide imported targets.

* The "FindOpenMP" module learned to support Clang.

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

Deprecated and Removed Features:

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.

* The "Xcode" generator was fixed to escape backslashes in strings
  consistently with other generators.  Projects that previously worked
  around the inconsistecy with an extra level of backslashes
  conditioned on the Xcode generator must be updated to remove the
  workaround for CMake 3.5 and greater.


CMake 3.5 Release Notes
***********************

Changes made since CMake 3.4 include the following.


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


GUI
---

* The "cmake-gui(1)" gained options to control warnings about
  deprecated functionality.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* The "cmake-gui(1)" gained a Regular Expression Explorer which may
  be used to create and evaluate regular expressions in real-time. The
  explorer window is available via the "Tools" menu.


Command-Line
------------

* The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and
  suppress the deprecated warnings output by default.

* The suppression of developer warnings as errors can now be
  controlled with the new "-Werror=dev" and "-Wno-error=dev"
  "cmake(1)" options.

* The "cmake(1)" "-E" command-line tools "copy",
  "copy_if_different", "copy_directory", and "make_directory" learned
  to support multiple input files or directories.


Commands
--------

* The "cmake_parse_arguments()" command is now implemented natively.
  The "CMakeParseArguments" module remains as an empty placeholder for
  compatibility.

* The "install(DIRECTORY)" command learned to support "generator
  expressions" in the list of directories.


Variables
---------

* The "CMAKE_ERROR_DEPRECATED" variable can now be set using the
  "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options.

* The "CMAKE_WARN_DEPRECATED" variable can now be set using the
  "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options.


Properties
----------

* The "VS_GLOBAL_<variable>" target property is now implemented for
  VS 2010 and above.  Previously it worked only in VS 2008 and below.


Modules
-------

* The "ExternalProject" module learned a new "GIT_REMOTE_NAME"
  option to control the "git clone --origin" value.

* The "FindBoost" module now provides imported targets such as
  "Boost::boost" and "Boost::filesystem".

* The "FindFLEX" module "FLEX_TARGET" macro learned a new
  "DEFINES_FILE" option to specify a custom output header to be
  generated.

* The "FindGTest" module now provides imported targets.

* The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is
  enabled, now sets "GTK2_LIBRARIES" to contain the list of imported
  targets instead of the paths to the libraries.  Moreover it now sets
  a new "GTK2_TARGETS" variable containing all the targets imported.

* The "FindOpenMP" module learned to support Clang.

* The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT"
  option to search for libraries using the MSVC static runtime.

* The "FindPNG" module now provides imported targets.

* The "FindTIFF" module now provides imported targets.

* A "FindXalanC" module was introduced to find the Apache Xalan-C++
  XSL transform processing library.

* The "FindXercesC" module now provides imported targets.


Platforms
---------

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.


CPack
-----

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

* The "CPackDeb" module learned to set the optional config file
  "Source" field using a monolithic or per-component variable. See
  "CPACK_DEBIAN_PACKAGE_SOURCE".

* The "CPackDeb" module learned to set Package, Section and Priority
  control fields per-component. See variables
  "CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION" and
  "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY".

* The "CPack DragNDrop generator" learned to add multi-lingual SLAs
  to a DMG which is presented to the user when they try to mount the
  DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR"
  variables for details.

* The "CPackNSIS" module learned new variables to add bitmaps to the
  installer.  See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and
  "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables.

* The "CPackRPM" module learned to set Name and Group control fields
  per-component. See "CPACK_RPM_<component>_PACKAGE_NAME" and
  "CPACK_RPM_<component>_PACKAGE_GROUP".


Other
-----

* Warnings about deprecated functionality are now enabled by
  default. They may be suppressed with "-Wno-deprecated" or by setting
  the "CMAKE_WARN_DEPRECATED" variable to false.


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

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.

* The "Xcode" generator was fixed to escape backslashes in strings
  consistently with other generators.  Projects that previously worked
  around the inconsistecy with an extra level of backslashes
  conditioned on the Xcode generator must be updated to remove the
  workaround for CMake 3.5 and greater.

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

* The "Visual Studio 14 2015" generator learned to map the
  "/debug:fastlink" linker flag to the ".vcxproj" file property.

* The "FindGTK2" module now configures the "GTK2::sigc++" imported
  target to enable c++11 on its dependents when using sigc++ 2.5.1 or
  higher.

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

----------------------------------------------------------------------------
Changes made since CMake 3.5.0-rc2:

Brad King (7):
      Help: Add release note about Xcode escaping fix (#15969)
      cmake-gui: Fix cmState initialization when changing generators (#15959)
      CMakeForceCompiler: De-deprecate until more use cases have alternatives
      Help: Clarify install(TARGETS) INCLUDES DESTINATION option
      Fix export of STATIC library PRIVATE non-target dependencies
      FindCUDA: Fix regression under Visual Studio generators
      CMake 3.5.0-rc3

Dimitar Yordanov (1):
      cmake_parse_arguments: Restore ;-list argument flattening

From ewmailing at gmail.com  Thu Feb 18 17:38:13 2016
From: ewmailing at gmail.com (Eric Wing)
Date: Thu, 18 Feb 2016 14:38:13 -0800
Subject: [CMake] Video glimpse of how I'm using CMake with Swift (and CMake
	in general)
Message-ID: <CA+Q62MDHtaSg=Qg9LrrGgv9bh9SJxAwdZwTfeybfHQzGF-t57w@mail.gmail.com>

I thought some of you might find this video I made interesting. It is
a teaser video for a new 2D cross-platform game SDK I've been working
on. It makes aggressive use of CMake for the build system.

https://youtu.be/w8ftI9mpGdY

The video goes by fast since is a time-lapse style. But hopefully the
gist comes through.

This video is using the Swift support put in for Xcode last year, and
the experimental stuff I've been adding for Makefiles. (Still work to
be done.)

I also use CMake to integrate all the resource and dynamic library
management so you can actually just hit Run and things work as you
expect. (This is different than what most(?) people are doing today.)

There is a Quick Introduction 3 part video from the website that shows
stuff in more detail if you want more.

Also, some feedback I've already been getting from testers... The
number one trip up is the ALL_BUILD target which always has to be
changed to the real application target in order for the Build/Run
button to work. This trips up everybody. And if you don't, the result
and error message in Visual Studio is confusing. Xcode isn't much
better.

Thanks,
Eric

From sam.habiel at gmail.com  Fri Feb 19 04:10:55 2016
From: sam.habiel at gmail.com (Sam Habiel)
Date: Fri, 19 Feb 2016 01:10:55 -0800
Subject: [CMake] Can't get CMake to use an import library generated from
 a MODULE target
In-Reply-To: <CAKohaZd4_=YJM5+ycO-D1mrp36ZY6+KKjGxWMd-Bm7cZLs0rQg@mail.gmail.com>
References: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E46F9C66F@EXMBS1.ad.igd.fraunhofer.de>
 <CABHT961CruFko_kCUtap4DT+gRwKM0G2MfiDgSf1qYdgnga9jg@mail.gmail.com>
 <CAKohaZd4_=YJM5+ycO-D1mrp36ZY6+KKjGxWMd-Bm7cZLs0rQg@mail.gmail.com>
Message-ID: <CABHT9609VeBz1kfK6kYn-CVZnFAjt6W77U=UqGfBNDp_BdaRkA@mail.gmail.com>

Thank you all for your help. I ran a quick experiment to see what's what:

MODULE:
[ 91%] Linking C shared module cyggtmshr.dll
/usr/local/bin/cmake.exe -E cmake_link_script
CMakeFiles/libgtmshr.dir/link.txt --verbose=1
/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
-Wl,-u,gtm_ci -Wl,-u,gtm_filename_to_id
-Wl,--version-script,"/home/sam/fis-gtm-cygwin/gtmshr_symbols.export"
-Wl,--out-implib=libgtmshr.lib -shared -Wl,--enable-auto-import -o
cyggtmshr.dll -Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/libgtmshr.dir/sr_unix/gtm_main.c.o libmumps.a
libgnpclient.a libcmisockettcp.a -lncurses -lm -ldl -lc -lpthread -lrt

SHARED:
[ 91%] Linking C shared library cyggtmshr.dll
/usr/local/bin/cmake.exe -E cmake_link_script
CMakeFiles/libgtmshr.dir/link.txt --verbose=1
/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
-Wl,-u,gtm_ci -Wl,-u,gtm_filename_to_id
-Wl,--version-script,"/home/sam/fis-gtm-cygwin/gtmshr_symbols.export"
-Wl,--out-implib=libgtmshr.lib -shared -Wl,--enable-auto-import -o
cyggtmshr.dll -Wl,--out-implib,libgtmshr.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/libgtmshr.dir/sr_unix/gtm_main.c.o libmumps.a
libgnpclient.a libcmisockettcp.a -lncurses -lm -ldl -lc -lpthread -lrt

If you look carefully, you will see the they are identical, except
that shared exports an Import Library libgtmshr.dll.a. The solution to
my problems!
The other --out-implib=libgtmshr.lib is hardcoded by myself.

On Thu, Feb 18, 2016 at 1:04 AM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
> Then I would suggest something like
>
> if(CYGWIN)
>   set(libType SHARED)
> else()
>   set(libType MODULE)
> endif()
>
> add_library(TheProblematicOne ${libType} ...)
>
> Petr
>
> On Thu, Feb 18, 2016 at 9:59 AM, Sam Habiel <sam.habiel at gmail.com> wrote:
>>
>> https://cmake.org/cmake/help/v3.0/command/add_library.html
>>
>> The module library (libgtmshr) is dlopened from the main exe. It's not
>> supposed to be linked, except for Cygwin.
>>
>>
>> On Thursday, February 18, 2016, Mueller-Roemer, Johannes Sebastian
>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>>>
>>> Why are you trying to link a MODULE? The add_library should be changed to
>>> SHARED not MODULE.
>>>
>>> --
>>> Johannes S. Mueller-Roemer, MSc
>>> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>>>
>>> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
>>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>>> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>>> johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de
>>>
>>>
>>> -----Original Message-----
>>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Sam Habiel
>>> Sent: Thursday, February 18, 2016 09:45
>>> To: cmake at cmake.org
>>> Subject: [CMake] Can't get CMake to use an import library generated from
>>> a MODULE target
>>>
>>> Rather than email one of the folks at Kitware, I decided to join the
>>> CMake mailing list... Hello all for those who remember me.
>>>
>>> I apologize for the long email.
>>>
>>> A few of us have been trying to port GT.M
>>> (https://www.fisglobal.com/Solutions/Services/Database-Engine) to Cygwin,
>>> 1. to get it running on Windows 2. as an exercise to prepare for harder
>>> ports, the Raspberry Pi being the holy grail here. That's the background.
>>>
>>> The problem we are having is familiar to many; but not initially to me.
>>> See the heading "Shared libraries with Windows/MinGW" in this
>>> article:
>>> http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.
>>>
>>> CMakeLists.txt:
>>> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>>>
>>> The error:
>>> [ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
>>> In function `gc_load_gtmshr_symbols':
>>> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined reference
>>> to `gtm_malloc'
>>> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined reference
>>> to `gtm_free'
>>> collect2: error: ld returned 1 exit status
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe for
>>> target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
>>> make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
>>> CMakeFiles/Makefile2:891: recipe for target
>>> 'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
>>> make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
>>> Makefile:116: recipe for target 'all' failed
>>> make: *** [all] Error 2
>>>
>>> Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
>>> /usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
>>> -Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG -shared
>>> -Wl,--enable-auto-import -o plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>>> -Wl,--major-image-version,0,--minor-image-version,0
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
>>>
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
>>>
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
>>>
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
>>> -lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>>>
>>> What is missing is that there needs to be either a link to cyggtmshr.dll,
>>> or a way for CMake to know to generate a libgtmshr_import.lib and add it to
>>> the link command.
>>>
>>> So here is what I tried:
>>> 1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
>>> If I do that, it doesn't seem to generate the import library; but it sure
>>> does generate an export header, which I don't need. Here it is:
>>> include(GenerateExportHeader)
>>> generate_export_header(libgtmshr
>>>     BASE_NAME libgtmshr
>>>     EXPORT_MACRO_NAME libgtmshr_EXPORTS
>>>     EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>>>     STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>>>
>>> 2. Explicitly adding a libgtmshr as a dependency on line
>>> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
>>> but only for Cygwin. I get this error message:
>>> CMake Error at CMakeLists.txt:542 (target_link_libraries):
>>>   Target "libgtmshr" of type MODULE_LIBRARY may not be linked into
>>> another
>>>   target.  One may link only to STATIC or SHARED libraries, or to
>>> executables
>>>   with the ENABLE_EXPORTS property set.
>>>
>>> The GT.M developer familiar with CMake suggested me to use LINK_FLAGS and
>>> have CMake use the file by us hardcoding it in; which I am okay doing, but I
>>> thought I would check to see if there is an alternative way of doing this.
>>>
>>> I also tried the suggestions here:
>>>
>>> "https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/"
>>> to no avail.
>>>
>>> Last, but not least:
>>>
>>> sam at horus ~/fis-gtm-cygwin
>>> $ cmake --version
>>> cmake version 3.4.3
>>>
>>> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>>>
>>> sam at horus ~/fis-gtm-cygwin
>>> $ uname -a
>>> CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin
>>>
>>> --
>>> Sam Habiel, Pharm.D.
>>> VISTA Expertise Network
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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
>>
>>
>>
>> --
>> Sam Habiel, Pharm.D.
>> VISTA Expertise Network
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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
>
>



-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network

From sam.habiel at gmail.com  Fri Feb 19 04:49:28 2016
From: sam.habiel at gmail.com (Sam Habiel)
Date: Fri, 19 Feb 2016 01:49:28 -0800
Subject: [CMake] Can't get CMake to use an import library generated from
 a MODULE target
In-Reply-To: <CABHT9609VeBz1kfK6kYn-CVZnFAjt6W77U=UqGfBNDp_BdaRkA@mail.gmail.com>
References: <CABHT962yk7b3r8pYpZ0Y53r=ZUPn_+OZ=HSd8PwbVsgEWXhXRw@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E46F9C66F@EXMBS1.ad.igd.fraunhofer.de>
 <CABHT961CruFko_kCUtap4DT+gRwKM0G2MfiDgSf1qYdgnga9jg@mail.gmail.com>
 <CAKohaZd4_=YJM5+ycO-D1mrp36ZY6+KKjGxWMd-Bm7cZLs0rQg@mail.gmail.com>
 <CABHT9609VeBz1kfK6kYn-CVZnFAjt6W77U=UqGfBNDp_BdaRkA@mail.gmail.com>
Message-ID: <CABHT961emgmxEeNcFaFpRF5nv3UOi7N6SHnj-SJiCvN1_VcmTQ@mail.gmail.com>

Thank you all for your help. These are the changes. Finally I put this
problem to rest.

https://github.com/shabiel/fis-gtm/commit/ec64cc772ecea734b27f685941cbcfa888ba786b

On Fri, Feb 19, 2016 at 1:10 AM, Sam Habiel <sam.habiel at gmail.com> wrote:
> Thank you all for your help. I ran a quick experiment to see what's what:
>
> MODULE:
> [ 91%] Linking C shared module cyggtmshr.dll
> /usr/local/bin/cmake.exe -E cmake_link_script
> CMakeFiles/libgtmshr.dir/link.txt --verbose=1
> /usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
> -Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
> -Wl,-u,gtm_ci -Wl,-u,gtm_filename_to_id
> -Wl,--version-script,"/home/sam/fis-gtm-cygwin/gtmshr_symbols.export"
> -Wl,--out-implib=libgtmshr.lib -shared -Wl,--enable-auto-import -o
> cyggtmshr.dll -Wl,--major-image-version,0,--minor-image-version,0
> CMakeFiles/libgtmshr.dir/sr_unix/gtm_main.c.o libmumps.a
> libgnpclient.a libcmisockettcp.a -lncurses -lm -ldl -lc -lpthread -lrt
>
> SHARED:
> [ 91%] Linking C shared library cyggtmshr.dll
> /usr/local/bin/cmake.exe -E cmake_link_script
> CMakeFiles/libgtmshr.dir/link.txt --verbose=1
> /usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
> -Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
> -Wl,-u,gtm_ci -Wl,-u,gtm_filename_to_id
> -Wl,--version-script,"/home/sam/fis-gtm-cygwin/gtmshr_symbols.export"
> -Wl,--out-implib=libgtmshr.lib -shared -Wl,--enable-auto-import -o
> cyggtmshr.dll -Wl,--out-implib,libgtmshr.dll.a
> -Wl,--major-image-version,0,--minor-image-version,0
> CMakeFiles/libgtmshr.dir/sr_unix/gtm_main.c.o libmumps.a
> libgnpclient.a libcmisockettcp.a -lncurses -lm -ldl -lc -lpthread -lrt
>
> If you look carefully, you will see the they are identical, except
> that shared exports an Import Library libgtmshr.dll.a. The solution to
> my problems!
> The other --out-implib=libgtmshr.lib is hardcoded by myself.
>
> On Thu, Feb 18, 2016 at 1:04 AM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
>> Then I would suggest something like
>>
>> if(CYGWIN)
>>   set(libType SHARED)
>> else()
>>   set(libType MODULE)
>> endif()
>>
>> add_library(TheProblematicOne ${libType} ...)
>>
>> Petr
>>
>> On Thu, Feb 18, 2016 at 9:59 AM, Sam Habiel <sam.habiel at gmail.com> wrote:
>>>
>>> https://cmake.org/cmake/help/v3.0/command/add_library.html
>>>
>>> The module library (libgtmshr) is dlopened from the main exe. It's not
>>> supposed to be linked, except for Cygwin.
>>>
>>>
>>> On Thursday, February 18, 2016, Mueller-Roemer, Johannes Sebastian
>>> <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>>>>
>>>> Why are you trying to link a MODULE? The add_library should be changed to
>>>> SHARED not MODULE.
>>>>
>>>> --
>>>> Johannes S. Mueller-Roemer, MSc
>>>> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>>>>
>>>> Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
>>>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>>>> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>>>> johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Sam Habiel
>>>> Sent: Thursday, February 18, 2016 09:45
>>>> To: cmake at cmake.org
>>>> Subject: [CMake] Can't get CMake to use an import library generated from
>>>> a MODULE target
>>>>
>>>> Rather than email one of the folks at Kitware, I decided to join the
>>>> CMake mailing list... Hello all for those who remember me.
>>>>
>>>> I apologize for the long email.
>>>>
>>>> A few of us have been trying to port GT.M
>>>> (https://www.fisglobal.com/Solutions/Services/Database-Engine) to Cygwin,
>>>> 1. to get it running on Windows 2. as an exercise to prepare for harder
>>>> ports, the Raspberry Pi being the holy grail here. That's the background.
>>>>
>>>> The problem we are having is familiar to many; but not initially to me.
>>>> See the heading "Shared libraries with Windows/MinGW" in this
>>>> article:
>>>> http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.
>>>>
>>>> CMakeLists.txt:
>>>> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>>>>
>>>> The error:
>>>> [ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
>>>> In function `gc_load_gtmshr_symbols':
>>>> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined reference
>>>> to `gtm_malloc'
>>>> /home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined reference
>>>> to `gtm_free'
>>>> collect2: error: ld returned 1 exit status
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe for
>>>> target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
>>>> make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
>>>> CMakeFiles/Makefile2:891: recipe for target
>>>> 'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
>>>> make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
>>>> Makefile:116: recipe for target 'all' failed
>>>> make: *** [all] Error 2
>>>>
>>>> Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
>>>> /usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
>>>> -Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG -shared
>>>> -Wl,--enable-auto-import -o plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>>>> -Wl,--major-image-version,0,--minor-image-version,0
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
>>>>
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
>>>>
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
>>>>
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
>>>> CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
>>>> -lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>>>>
>>>> What is missing is that there needs to be either a link to cyggtmshr.dll,
>>>> or a way for CMake to know to generate a libgtmshr_import.lib and add it to
>>>> the link command.
>>>>
>>>> So here is what I tried:
>>>> 1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
>>>> If I do that, it doesn't seem to generate the import library; but it sure
>>>> does generate an export header, which I don't need. Here it is:
>>>> include(GenerateExportHeader)
>>>> generate_export_header(libgtmshr
>>>>     BASE_NAME libgtmshr
>>>>     EXPORT_MACRO_NAME libgtmshr_EXPORTS
>>>>     EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>>>>     STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>>>>
>>>> 2. Explicitly adding a libgtmshr as a dependency on line
>>>> https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
>>>> but only for Cygwin. I get this error message:
>>>> CMake Error at CMakeLists.txt:542 (target_link_libraries):
>>>>   Target "libgtmshr" of type MODULE_LIBRARY may not be linked into
>>>> another
>>>>   target.  One may link only to STATIC or SHARED libraries, or to
>>>> executables
>>>>   with the ENABLE_EXPORTS property set.
>>>>
>>>> The GT.M developer familiar with CMake suggested me to use LINK_FLAGS and
>>>> have CMake use the file by us hardcoding it in; which I am okay doing, but I
>>>> thought I would check to see if there is an alternative way of doing this.
>>>>
>>>> I also tried the suggestions here:
>>>>
>>>> "https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/"
>>>> to no avail.
>>>>
>>>> Last, but not least:
>>>>
>>>> sam at horus ~/fis-gtm-cygwin
>>>> $ cmake --version
>>>> cmake version 3.4.3
>>>>
>>>> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>>>>
>>>> sam at horus ~/fis-gtm-cygwin
>>>> $ uname -a
>>>> CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin
>>>>
>>>> --
>>>> Sam Habiel, Pharm.D.
>>>> VISTA Expertise Network
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more
>>>> information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/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
>>>
>>>
>>>
>>> --
>>> Sam Habiel, Pharm.D.
>>> VISTA Expertise Network
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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
>>
>>
>
>
>
> --
> Sam Habiel, Pharm.D.
> VISTA Expertise Network



-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network

From carl.poirier.2 at gmail.com  Fri Feb 19 09:07:20 2016
From: carl.poirier.2 at gmail.com (Carl Poirier)
Date: Fri, 19 Feb 2016 09:07:20 -0500
Subject: [CMake] PDB_NAME with DEBUG_POSTFIX
Message-ID: <CAB7XPHm9KtHH+Q9jmXsMfga-EstNTtPDhPQW_4d2Xv2fY3PF1w@mail.gmail.com>

Hi folks,

I have a question here regarding the use of the DEBUG_POSTFIX. When I set
it as well as the property OUTPUT_NAME, the former is correctly applied to
the latter. Now when I try to do so with a library, the DEBUG_POSTFIX does
not get applied to the PDB filename. Here are the relevant lines of my
CMakeLists.txt:

# Set the resulting filenames
set_target_properties(${PrjName1} PROPERTIES COMPILE_PDB_NAME mylib)
set_target_properties(${PrjName1} PROPERTIES OUTPUT_NAME mylib)

# Add "D" postfix for the debug build
set_target_properties(${PrjName1} PROPERTIES DEBUG_POSTFIX "D")

So is there a reason why it works (or doesn't) that way? The best
workaround I have now is set the names on a per-configuration basis.

Regards,

Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160219/3957e3fe/attachment.html>

From bob at summerwill.net  Fri Feb 19 17:04:40 2016
From: bob at summerwill.net (Bob Summerwill)
Date: Fri, 19 Feb 2016 14:04:40 -0800
Subject: [CMake] Possible Windows regression in CMake 3.5?
Message-ID: <CAFTheUFoWgq3uLnzx=Ab7BUNPgH5EPyE9kHX9D94yJuduKo9eg@mail.gmail.com>

Does this issue look familiar to anybody:

    https://github.com/ethereum/webthree-umbrella/issues/235

Windows Windows 8.1 with VS12.  Works with CMake 3.4.   Broken with CMake
3.5.

There isn't much to go on in the log file the OP attached:

https://github.com/ethereum/webthree-umbrella/files/134182/CMakeError.txt

But the crux appears to be:

"D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\cmTC_5b2cf.vcxproj"
(destinazione predefinita) (1) ->

(destinazione: ClCompile) ->

  D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\CheckIncludeFile.c(1):
fatal error C1083: Cannot open include file: 'pthread.h': No such file or
directory
[D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\cmTC_5b2cf.vcxproj]


  D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\CheckSymbolExists.c(8):
error C2065: 'CL_VERSION_2_0' : undeclared identifier
[D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\cmTC_ab7a5.vcxproj]



    Avvisi: 0

    Errori: 1



Tempo trascorso 00:00:00.29


File D:/webthree-umbrella/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include
<D:/webthree-umbrella/webthree-helpers/extdep/install/windows/x64/include/CL/cl.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef CL_VERSION_2_0
  return ((int*)(&CL_VERSION_2_0))[argc];
#else
  (void)argc;
  return 0;
#endif
}


-- 
bob at summerwill.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160219/7e20d336/attachment.html>

From bob at summerwill.net  Fri Feb 19 17:48:02 2016
From: bob at summerwill.net (Bob Summerwill)
Date: Fri, 19 Feb 2016 14:48:02 -0800
Subject: [CMake] Possible Windows regression in CMake 3.5?
In-Reply-To: <CAFTheUFoWgq3uLnzx=Ab7BUNPgH5EPyE9kHX9D94yJuduKo9eg@mail.gmail.com>
References: <CAFTheUFoWgq3uLnzx=Ab7BUNPgH5EPyE9kHX9D94yJuduKo9eg@mail.gmail.com>
Message-ID: <CAFTheUFRsWgKe7NrAQr4b1twwLKxLeA5zBks=hUOvX9ZSoFNog@mail.gmail.com>

Sorry - wrong log file:

     https://github.com/ethereum/webthree-umbrella/files/136058/console.txt

And the actual crux of the failure is failing to find ONLY boost atomic
library, when it is actually present, and works just fine on CMake 3.4.3.
 Were there changes to the Boost-related functions in CMake 3.5?


CMake Error at C:/Program Files
(x86)/CMake/share/cmake-3.5/Modules/FindBoost.cm
ake:1647 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.55.0

  Boost include path:
  D:/webthree-umbrella/webthree-helpers/extdep/install/win
dows/x64/include


  Could not find the following static Boost libraries:

          boost_atomic

  Some (but not all) of the required Boost libraries were found.  You may
  need to install these additional Boost libraries.  Alternatively, set
  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
  to the location of Boost.

On Fri, Feb 19, 2016 at 2:04 PM, Bob Summerwill <bob at summerwill.net> wrote:

> Does this issue look familiar to anybody:
>
>     https://github.com/ethereum/webthree-umbrella/issues/235
>
> Windows Windows 8.1 with VS12.  Works with CMake 3.4.   Broken with CMake
> 3.5.
>
> There isn't much to go on in the log file the OP attached:
>
> https://github.com/ethereum/webthree-umbrella/files/134182/CMakeError.txt
>
> But the crux appears to be:
>
> "D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\cmTC_5b2cf.vcxproj"
> (destinazione predefinita) (1) ->
>
> (destinazione: ClCompile) ->
>
>   D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\CheckIncludeFile.c(1):
> fatal error C1083: Cannot open include file: 'pthread.h': No such file or
> directory
> [D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\cmTC_5b2cf.vcxproj]
>
>
>   D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\CheckSymbolExists.c(8):
> error C2065: 'CL_VERSION_2_0' : undeclared identifier
> [D:\webthree-umbrella\build\CMakeFiles\CMakeTmp\cmTC_ab7a5.vcxproj]
>
>
>
>     Avvisi: 0
>
>     Errori: 1
>
>
>
> Tempo trascorso 00:00:00.29
>
>
> File D:/webthree-umbrella/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
> /* */
> #include
> <D:/webthree-umbrella/webthree-helpers/extdep/install/windows/x64/include/CL/cl.h>
>
> int main(int argc, char** argv)
> {
>   (void)argv;
> #ifndef CL_VERSION_2_0
>   return ((int*)(&CL_VERSION_2_0))[argc];
> #else
>   (void)argc;
>   return 0;
> #endif
> }
>
>
> --
> bob at summerwill.net
>
>


-- 
bob at summerwill.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160219/c72e7bdb/attachment.html>

From bruce.r.stephens at gmail.com  Sat Feb 20 13:49:20 2016
From: bruce.r.stephens at gmail.com (Bruce Stephens)
Date: Sat, 20 Feb 2016 18:49:20 +0000
Subject: [CMake] shared library versioning on OS X
Message-ID: <CAMqww3T1+w2-91TE8Dt9Uxf_jFomV-sZ8=RmXypwsMRuYCAwqQ@mail.gmail.com>

By the looks of it setting the SOVERSION when generating a SHARED library
creates the symbolic link, but it doesn't seem to use the -current_version
or -compatibility_version flags when linking.

Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and
CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages)
but those don't seem to be used.

Is that deliberate?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160220/6343160b/attachment.html>

From bruce.r.stephens at gmail.com  Sat Feb 20 14:17:12 2016
From: bruce.r.stephens at gmail.com (Bruce Stephens)
Date: Sat, 20 Feb 2016 19:17:12 +0000
Subject: [CMake] shared library versioning on OS X
In-Reply-To: <57f0748c-83c1-49d2-9365-8b6304af491c@email.android.com>
References: <CAMqww3T1+w2-91TE8Dt9Uxf_jFomV-sZ8=RmXypwsMRuYCAwqQ@mail.gmail.com>
 <57f0748c-83c1-49d2-9365-8b6304af491c@email.android.com>
Message-ID: <CAMqww3TUwMEgFqinNnqCPheDududNVfxK5NXX+pX9a4aeHnSRA@mail.gmail.com>

Ah, yes. That looks like exactly the bug, thanks.

So it's a straight bug in the ninja generator, not something deliberate
that I was just failing to understand. And with the Unix Makefile generator
the compatibility version is set (presumably the current version would be
set if I used VERSION).

On Sat, Feb 20, 2016 at 6:59 PM, <clinton at elemtech.com> wrote:

> Perhaps this bug report fits what you are seeing.  Are you seeing this
> limitation in the ninja generator?
>
> https://cmake.org/Bug/view.php?id=14140
>
> Clint
>
> On Feb 20, 2016 11:49 AM, Bruce Stephens <bruce.r.stephens at gmail.com>
> wrote:
> >
> > By the looks of it setting the SOVERSION when generating a SHARED
> library creates the symbolic link, but it doesn't seem to use the
> -current_version or -compatibility_version flags when linking.
> >
> > Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and
> CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages)
> but those don't seem to be used.
> >
> > Is that deliberate?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160220/50c13d8a/attachment.html>

From clinton at elemtech.com  Sat Feb 20 13:59:20 2016
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Sat, 20 Feb 2016 11:59:20 -0700
Subject: [CMake] shared library versioning on OS X
In-Reply-To: <CAMqww3T1+w2-91TE8Dt9Uxf_jFomV-sZ8=RmXypwsMRuYCAwqQ@mail.gmail.com>
Message-ID: <57f0748c-83c1-49d2-9365-8b6304af491c@email.android.com>

Perhaps this bug report fits what you are seeing.  Are you seeing this limitation in the ninja generator?

https://cmake.org/Bug/view.php?id=14140

Clint

On Feb 20, 2016 11:49 AM, Bruce Stephens <bruce.r.stephens at gmail.com> wrote:
>
> By the looks of it setting the SOVERSION when generating a SHARED library creates the symbolic link, but it doesn't seem to use the -current_version or -compatibility_version flags when linking.
>
> Those flags are set as variables?CMAKE_C_OSX_CURRENT_VERSION_FLAG and CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages) but those don't seem to be used.
>
> Is that deliberate?
>

From bruce.r.stephens at gmail.com  Sat Feb 20 15:15:59 2016
From: bruce.r.stephens at gmail.com (Bruce Stephens)
Date: Sat, 20 Feb 2016 20:15:59 +0000
Subject: [CMake] shared library versioning on OS X
In-Reply-To: <CAMqww3TUwMEgFqinNnqCPheDududNVfxK5NXX+pX9a4aeHnSRA@mail.gmail.com>
References: <CAMqww3T1+w2-91TE8Dt9Uxf_jFomV-sZ8=RmXypwsMRuYCAwqQ@mail.gmail.com>
 <57f0748c-83c1-49d2-9365-8b6304af491c@email.android.com>
 <CAMqww3TUwMEgFqinNnqCPheDududNVfxK5NXX+pX9a4aeHnSRA@mail.gmail.com>
Message-ID: <CAMqww3RWtNYLxvTgXhenYgWXW4vdEU5ECnnFdeSLAtEVym=1Nw@mail.gmail.com>

In case anyone cares, I think https://github.com/brucestephens/CMake
contains a quick fix.

On Sat, Feb 20, 2016 at 7:17 PM, Bruce Stephens <bruce.r.stephens at gmail.com>
wrote:

> Ah, yes. That looks like exactly the bug, thanks.
>
> So it's a straight bug in the ninja generator, not something deliberate
> that I was just failing to understand. And with the Unix Makefile generator
> the compatibility version is set (presumably the current version would be
> set if I used VERSION).
>
> On Sat, Feb 20, 2016 at 6:59 PM, <clinton at elemtech.com> wrote:
>
>> Perhaps this bug report fits what you are seeing.  Are you seeing this
>> limitation in the ninja generator?
>>
>> https://cmake.org/Bug/view.php?id=14140
>>
>> Clint
>>
>> On Feb 20, 2016 11:49 AM, Bruce Stephens <bruce.r.stephens at gmail.com>
>> wrote:
>> >
>> > By the looks of it setting the SOVERSION when generating a SHARED
>> library creates the symbolic link, but it doesn't seem to use the
>> -current_version or -compatibility_version flags when linking.
>> >
>> > Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and
>> CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages)
>> but those don't seem to be used.
>> >
>> > Is that deliberate?
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160220/ffc66950/attachment.html>

From golubdr at gmail.com  Sun Feb 21 12:49:00 2016
From: golubdr at gmail.com (David Golub)
Date: Sun, 21 Feb 2016 12:49:00 -0500
Subject: [CMake] CMake Tools for Visual Studio 1.4 Released!
Message-ID: <00c801d16cd0$258bc790$70a356b0$@gmail.com>

I'm pleased to announce that I've release version 1.4 of my Visual Studio
extension for CMake, which provides syntax highlighting and IntelliSense.
This release adds support for Visual Studio 2015 and CMake 3.4.  It is
available from the project web site at http://cmaketools.codeplex.com.
Enjoy!

 

David Golub

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

From gerry.fan at gmail.com  Sun Feb 21 23:45:27 2016
From: gerry.fan at gmail.com (Gerry Fan)
Date: Sun, 21 Feb 2016 20:45:27 -0800
Subject: [CMake] CMake 3.5-CMAKE_BINARY_DIR is set to ${CMAKE_SOURCE_DIR}
	when calling add_subdirectory?
References: <mailman.8.1456040205.3364.cmake@cmake.org>
Message-ID: <E651B938-C261-42D0-95A5-0647DBE24A15@gmail.com>

before calling add_subdirectory, set up 2 variables like:
  set(CMAKE_SOURCE_DIR /Users/test/proj/fplbase)
  set(CMAKE_BINARY_DIR  /Users/test/proj/fplbase/build)
  add_subdirectory(${sdl_dir} ?/Users/test/proj/fplbase/obj?)
  
In module ${dl_dir}?s CMakeLists.txt, at the beginning, it has:
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
  message(FATAL_ERROR "Prevented in-tree built. Please create a build directory outside of the SDL source code and call cmake from there?)
endif()

Somehow the above error is always triggered, does not matter what I set CMAKE_BINARY_DIR to. when printing out CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR, CMAKE_BINARY_DIR is set to the same path as CMAKE_SOURCE_DIR ( /Users/test/proj/fplbase ) in module ${dl_dir}

this only  happens with CMake 3.5-RCx, not happening with previous make versions ( 3.4, 3.3 ). 

seems this checkin began to have it:
commit c4e1bc6ed24d57ef3136756802aa575642927ff1
Merge: f9cc671 0aef6f2
    Merge branch ?release


Is this a bug?

thank you

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

From attila.krasznahorkay at gmail.com  Mon Feb 22 05:17:13 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Mon, 22 Feb 2016 11:17:13 +0100
Subject: [CMake] CMake 3.5-CMAKE_BINARY_DIR is set to
	${CMAKE_SOURCE_DIR} when calling add_subdirectory?
In-Reply-To: <E651B938-C261-42D0-95A5-0647DBE24A15@gmail.com>
References: <mailman.8.1456040205.3364.cmake@cmake.org>
 <E651B938-C261-42D0-95A5-0647DBE24A15@gmail.com>
Message-ID: <43ADDEA4-B2D8-446A-8059-50811608FA9A@gmail.com>

Hi Gerry,

Setting these variables by hand sounds quite dangerous. I'm not sure how much this is meant to be supported.

There is a much more "native" way of doing this. You could do:

add_subdirectory( ${source_dir} ${binary_dir} )

, where "source_dir" would be the source directory relative to ${CMAKE_SOURCE_DIR}, and "binary_dir" could be any absolute path of your choice. You could for instance set it to:

set( binary_dir "${CMAKE_BINARY_DIR}/${source_dir}/build" )

Although all in all, this directory organisation of yours seems pretty "forced". :-/

Cheers,
              Attila

P.S. When calling add_subdirectory like this, ${CMAKE_CURRENT_BINARY_DIR} is definitely set correctly in the subdirectory. But ${CMAKE_BINARY_DIR} will still be the one that CMake sets automatically. You should really not be trying to modify this latter value.

> On 22 Feb 2016, at 05:45, Gerry Fan <gerry.fan at gmail.com> wrote:
> 
> before calling add_subdirectory, set up 2 variables like:
>   set(CMAKE_SOURCE_DIR /Users/test/proj/fplbase)
>   set(CMAKE_BINARY_DIR  /Users/test/proj/fplbase/build)
>   add_subdirectory(${sdl_dir} ?/Users/test/proj/fplbase/obj?)
>   
> In module ${dl_dir}?s CMakeLists.txt, at the beginning, it has:
> if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
>   message(FATAL_ERROR "Prevented in-tree built. Please create a build directory outside of the SDL source code and call cmake from there?)
> endif()
> 
> Somehow the above error is always triggered, does not matter what I set CMAKE_BINARY_DIR to. when printing out CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR, CMAKE_BINARY_DIR is set to the same path as CMAKE_SOURCE_DIR ( /Users/test/proj/fplbase ) in module ${dl_dir}
> 
> this only  happens with CMake 3.5-RCx, not happening with previous make versions ( 3.4, 3.3 ). 
> 
> seems this checkin began to have it:
> commit c4e1bc6ed24d57ef3136756802aa575642927ff1
> Merge: f9cc671 0aef6f2
>     Merge branch ?release
> 
> 
> Is this a bug?
> 
> thank you
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 victorsv at gmail.com  Mon Feb 22 12:19:08 2016
From: victorsv at gmail.com (victor sv)
Date: Mon, 22 Feb 2016 18:19:08 +0100
Subject: [CMake] How to know the MPI Fortran compiler vendor
Message-ID: <CA+Wz_FziyHSAe3TzuMLT=1gSPr_c+eBAwt2DtqDGS2e4HtzTkw@mail.gmail.com>

Hi all,

we need to force some compilation flags for a library compiled with the
MPI_Fortran_COMPILER provided by find_pakage.

With the CMAKE_Fortran_COMPILER we can ask for the compiler vendor checking
the CMAKE_Fortran_COMPILER_ID variable.

There is a way to do the same with MPI_Fortran_COMPILER?

Best regards,
V?ctor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160222/219f613f/attachment.html>

From steveire at gmail.com  Mon Feb 22 16:31:30 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 22 Feb 2016 22:31:30 +0100
Subject: [CMake] CMake 3.5-CMAKE_BINARY_DIR is set to
	${CMAKE_SOURCE_DIR} when calling add_subdirectory?
References: <mailman.8.1456040205.3364.cmake@cmake.org>
 <E651B938-C261-42D0-95A5-0647DBE24A15@gmail.com>
 <43ADDEA4-B2D8-446A-8059-50811608FA9A@gmail.com>
Message-ID: <nafuni$m56$2@ger.gmane.org>

Attila Krasznahorkay wrote:

> Setting these variables by hand sounds quite dangerous. I'm not sure how
> much this is meant to be supported.
> 

This is definitely UB.



From victorsv at gmail.com  Tue Feb 23 05:56:17 2016
From: victorsv at gmail.com (victor sv)
Date: Tue, 23 Feb 2016 11:56:17 +0100
Subject: [CMake] CheckFortranSourceCompiles alternative for cmake 2.8.12
Message-ID: <CA+Wz_FyeY7HqHc9+rrmTDco79hPC9PDJ3+k76QqW=7a+cz31DA@mail.gmail.com>

Hi all,

I've seen that in CMake 3.0 appeared the nice CheckFortranSourceCompiles
feature.

Currently, common SO's like Ubuntu 14 includes CMake 2.8.12.2, but not
CMake 3.0 or higher. I would like to check if a very small Fortran test
program compiles using CMake 2.8.12.2, is this possible? how can i do that?

Best regards,
V?ctor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160223/2f5b62df/attachment.html>

From petr.kmoch at gmail.com  Tue Feb 23 06:31:45 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 23 Feb 2016 12:31:45 +0100
Subject: [CMake] CheckFortranSourceCompiles alternative for cmake 2.8.12
In-Reply-To: <CA+Wz_FyeY7HqHc9+rrmTDco79hPC9PDJ3+k76QqW=7a+cz31DA@mail.gmail.com>
References: <CA+Wz_FyeY7HqHc9+rrmTDco79hPC9PDJ3+k76QqW=7a+cz31DA@mail.gmail.com>
Message-ID: <CAKohaZfFShz0rM57-GnCptu3ubPggdhGqE2iTryh0QayZG_OaQ@mail.gmail.com>

Hi Victor,

have a look at the try_compile() command (
https://cmake.org/cmake/help/v2.8.12/cmake.html#command:try_compile ),
especially the second signature (the one which takes SOURCES).

Petr

On Tue, Feb 23, 2016 at 11:56 AM, victor sv <victorsv at gmail.com> wrote:

> Hi all,
>
> I've seen that in CMake 3.0 appeared the nice CheckFortranSourceCompiles
> feature.
>
> Currently, common SO's like Ubuntu 14 includes CMake 2.8.12.2, but not
> CMake 3.0 or higher. I would like to check if a very small Fortran test
> program compiles using CMake 2.8.12.2, is this possible? how can i do that?
>
> Best regards,
> V?ctor.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160223/edddfdca/attachment.html>

From victorsv at gmail.com  Tue Feb 23 06:46:41 2016
From: victorsv at gmail.com (victor sv)
Date: Tue, 23 Feb 2016 12:46:41 +0100
Subject: [CMake] CheckFortranSourceCompiles alternative for cmake 2.8.12
In-Reply-To: <CAKohaZfFShz0rM57-GnCptu3ubPggdhGqE2iTryh0QayZG_OaQ@mail.gmail.com>
References: <CA+Wz_FyeY7HqHc9+rrmTDco79hPC9PDJ3+k76QqW=7a+cz31DA@mail.gmail.com>
 <CAKohaZfFShz0rM57-GnCptu3ubPggdhGqE2iTryh0QayZG_OaQ@mail.gmail.com>
Message-ID: <CA+Wz_FxLHrxwwfXEJbUoWfFuusj3jxcpuSNtkOXNy1hCjapo5Q@mail.gmail.com>

Thanks Pter!

Is the solution I was looking for. Great, it works as expected! :)


2016-02-23 12:31 GMT+01:00 Petr Kmoch <petr.kmoch at gmail.com>:

> Hi Victor,
>
> have a look at the try_compile() command (
> https://cmake.org/cmake/help/v2.8.12/cmake.html#command:try_compile ),
> especially the second signature (the one which takes SOURCES).
>
> Petr
>
> On Tue, Feb 23, 2016 at 11:56 AM, victor sv <victorsv at gmail.com> wrote:
>
>> Hi all,
>>
>> I've seen that in CMake 3.0 appeared the nice CheckFortranSourceCompiles
>> feature.
>>
>> Currently, common SO's like Ubuntu 14 includes CMake 2.8.12.2, but not
>> CMake 3.0 or higher. I would like to check if a very small Fortran test
>> program compiles using CMake 2.8.12.2, is this possible? how can i do that?
>>
>> Best regards,
>> V?ctor.
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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/20160223/23ad4f44/attachment.html>

From victorsv at gmail.com  Tue Feb 23 11:34:49 2016
From: victorsv at gmail.com (victor sv)
Date: Tue, 23 Feb 2016 17:34:49 +0100
Subject: [CMake] CheckFortranSourceCompiles alternative for cmake 2.8.12
In-Reply-To: <CA+Wz_FxLHrxwwfXEJbUoWfFuusj3jxcpuSNtkOXNy1hCjapo5Q@mail.gmail.com>
References: <CA+Wz_FyeY7HqHc9+rrmTDco79hPC9PDJ3+k76QqW=7a+cz31DA@mail.gmail.com>
 <CAKohaZfFShz0rM57-GnCptu3ubPggdhGqE2iTryh0QayZG_OaQ@mail.gmail.com>
 <CA+Wz_FxLHrxwwfXEJbUoWfFuusj3jxcpuSNtkOXNy1hCjapo5Q@mail.gmail.com>
Message-ID: <CA+Wz_Fx6yWV8XDXuUReRE0n6PkGMbvBRuMJ-c-nBsgz5HwY_Qw@mail.gmail.com>

HI again,

I'm using TRY_COMPILE in a MPI Fortran project with CMake 2.8.11 to check
if the mpi.mod file is compatible with the current Fortran compiler.

The CMake code snippet is as follows:

...
    FIND_PATH(MPI_MOD_FOUND mpi.mod  PATHS ${MPI_Fortran_INCLUDE_PATH})
    IF(MPI_MOD_FOUND)
        TRY_COMPILE(FORTRAN_COMPILER_MATCH_MPI_MOD
                    ${PROJECT_BINARY_DIR}
                    ${SERIAL_TESTS_PATH}/try_compile_mpi_mod.f90
                    CMAKE_FLAGS

"-DINCLUDE_DIRECTORIES:STRING=${MPI_Fortran_INCLUDE_PATH}"
                        "-DLINK_LIBRARIES:STRING=${MPI_Fortran_LIBRARIES}")
...

And the Fortan code of try_compile_mpi_mod.f90 is:

program test
use mpi
end program

this is the best choice to ensure the compatibility of current Fortran
compiler and the Fortran compiler used to compile the linked MPI library?

Thanks in advance.

Best regards,
V?ctor



2016-02-23 12:46 GMT+01:00 victor sv <victorsv at gmail.com>:

> Thanks Pter!
>
> Is the solution I was looking for. Great, it works as expected! :)
>
>
> 2016-02-23 12:31 GMT+01:00 Petr Kmoch <petr.kmoch at gmail.com>:
>
>> Hi Victor,
>>
>> have a look at the try_compile() command (
>> https://cmake.org/cmake/help/v2.8.12/cmake.html#command:try_compile ),
>> especially the second signature (the one which takes SOURCES).
>>
>> Petr
>>
>> On Tue, Feb 23, 2016 at 11:56 AM, victor sv <victorsv at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I've seen that in CMake 3.0 appeared the nice CheckFortranSourceCompiles
>>> feature.
>>>
>>> Currently, common SO's like Ubuntu 14 includes CMake 2.8.12.2, but not
>>> CMake 3.0 or higher. I would like to check if a very small Fortran test
>>> program compiles using CMake 2.8.12.2, is this possible? how can i do that?
>>>
>>> Best regards,
>>> V?ctor.
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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/20160223/19d6f762/attachment-0001.html>

From a.neundorf-work at gmx.net  Tue Feb 23 16:49:41 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Tue, 23 Feb 2016 22:49:41 +0100
Subject: [CMake] Code::blocks: parallel build from IDE
In-Reply-To: <3211808.HRXAgpu4YV@tuxedo.neundorf.net>
References: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>
 <CAFzH18i1Yd1j4W+RCyS41thQCN9nJLGEta_FT8v8FVc0ca6fcg@mail.gmail.com>
 <3211808.HRXAgpu4YV@tuxedo.neundorf.net>
Message-ID: <3746871.NgjzmaLb0O@tuxedo.neundorf.net>

On Sunday, January 17, 2016 14:01:59 Alexander Neundorf wrote:
> On Sunday, January 17, 2016 13:45:34 Dimitri Kaparis wrote:
> > On Sat, Jan 9, 2016 at 9:16 PM, Alexander Neundorf
> > <a.neundorf-work at gmx.net>> 
> > wrote:
> > > On Saturday, January 09, 2016 12:27:48 Dimitri Kaparis wrote:
> > > > Greetings,
> > > > 
> > > > I'm using the "CodeBlocks - Unix Makefiles" generator under linux to
> > > 
> > > create
> > > 
> > > > a build tree for my project consisting of multiple executables and
> > > > libraries.
> > > > From the command line, I could use make -jN switch from the root of
> > > > the
> > > > build tree to invoke a full build in parallel, but I see no way of
> > > > doing
> > > > that from the Code Blocks IDE.
> > > 
> > > Oops, sorry, that's not implemented for C::B.
> > > 
> > > Alex
> > 
> > Any plans on it,
> 
> yes, but not commited yet.

it's in next now.
CMake now tries to figure out the number of CPUs, and sets the (new) cache 
variable CMAKE_CODEBLOCKS_MAKE_ARGUMENTS to "-jN".
If you don't like the result, you can set it to something else.

Alex



From George.Ryan at geospectrum.ca  Wed Feb 24 09:09:47 2016
From: George.Ryan at geospectrum.ca (George Ryan)
Date: Wed, 24 Feb 2016 14:09:47 +0000
Subject: [CMake] Calling a Python Testing Script from CMake/CTest
Message-ID: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>

Hi,

I am having difficulty getting a python script to run a C++ subprocess
on Window 7 using VS2013. On Linux, the following code works fine, but
on Windows, from the command line I get the following output:

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Running tests...
Test project C:/work/s/sandbox/ctestpy/b
    Start 1: sample_test
1/1 Test #1: sample_test ......................***Not Run   0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.06 sec

The following tests FAILED:
          1 - sample_test (BAD_COMMAND)
Errors while running CTest
NMAKE : fatal error U1077: 'echo' : return code '0x8'
Stop.

No matter what options I supply to ctest, I can't seem to get any
additional insight. I am assuming that for some reason the
WORKING_DIRECTORY isn't being obeyed on Windows?

If I run the python script manually from the command prompt, it works
fine. The python executable is in my $PATH.On Linux I am using CMake
3.3.1, and on Windows I have CMake 3.2.3.

----

sample.cpp

int main()
{
  return 0;
}

--------------

sample_test.py

#!/usr/bin/env python
import sys
import subprocess

sample = subprocess.Popen("./sample")
sample.wait()
if sample.returncode != 0:
    sys.exit(1)
else:
    sys.exit(0)
~
------------------------

CMakeLists.txt

cmake_minimum_required(VERSION 3.0)
project(sampleprg)

enable_testing()

add_executable( sample sample.cpp )

add_test(NAME sample_test
         COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
         WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )





From post at hendrik-sattler.de  Wed Feb 24 09:41:27 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 24 Feb 2016 15:41:27 +0100
Subject: [CMake] Calling a Python Testing Script from CMake/CTest
In-Reply-To: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
References: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
Message-ID: <B3333BA8-4B7E-4E8C-AD4B-9C33C4ED23C4@hendrik-sattler.de>



Am 24. Februar 2016 15:09:47 MEZ, schrieb George Ryan <George.Ryan at geospectrum.ca>:
>Hi,
>
>I am having difficulty getting a python script to run a C++ subprocess
>on Window 7 using VS2013. On Linux, the following code works fine, but
>on Windows, from the command line I get the following output:
>
>Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
>Copyright (C) Microsoft Corporation.  All rights reserved.
>
>Running tests...
>Test project C:/work/s/sandbox/ctestpy/b
>    Start 1: sample_test
>1/1 Test #1: sample_test ......................***Not Run   0.00 sec
>
>0% tests passed, 1 tests failed out of 1
>
>Total Test time (real) =   0.06 sec
>
>The following tests FAILED:
>          1 - sample_test (BAD_COMMAND)
>Errors while running CTest
>NMAKE : fatal error U1077: 'echo' : return code '0x8'
>Stop.
>
>No matter what options I supply to ctest, I can't seem to get any
>additional insight. I am assuming that for some reason the
>WORKING_DIRECTORY isn't being obeyed on Windows?
>
>If I run the python script manually from the command prompt, it works
>fine. The python executable is in my $PATH.On Linux I am using CMake
>3.3.1, and on Windows I have CMake 3.2.3.
>
>----
>
>sample.cpp
>
>int main()
>{
>  return 0;
>}
>
>--------------
>
>sample_test.py
>
>#!/usr/bin/env python
>import sys
>import subprocess
>
>sample = subprocess.Popen("./sample")
>sample.wait()
>if sample.returncode != 0:
>    sys.exit(1)
>else:
>    sys.exit(0)
>~
>------------------------
>
>CMakeLists.txt
>
>cmake_minimum_required(VERSION 3.0)
>project(sampleprg)
>
>enable_testing()
>
>add_executable( sample sample.cpp )
>
>add_test(NAME sample_test
>         COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
>         WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )

You have to manuall call python with the script as argument. Shebang lines don't work on Windows.

HS



From George.Ryan at geospectrum.ca  Wed Feb 24 09:45:16 2016
From: George.Ryan at geospectrum.ca (George Ryan)
Date: Wed, 24 Feb 2016 14:45:16 +0000
Subject: [CMake] Calling a Python Testing Script from CMake/CTest
References: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
 <B3333BA8-4B7E-4E8C-AD4B-9C33C4ED23C4@hendrik-sattler.de>
Message-ID: <DEB25E01010D304BAA1B84C9D644A929E4A42E@GEOSPECTRUM-SRV.geospectrum.local>

Am 24. Februar 2016 15:09:47 MEZ, schrieb George Ryan
<George.Ryan at geospectrum.ca>:
>> Hi,
>>
>> I am having difficulty getting a python script to run a C++ subprocess
>> on Window 7 using VS2013. On Linux, the following code works fine, but
>> on Windows, from the command line I get the following output:
>>
>> Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Running tests...
>> Test project C:/work/s/sandbox/ctestpy/b
>>    Start 1: sample_test
>> 1/1 Test #1: sample_test ......................***Not Run   0.00 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) =   0.06 sec
>>
>> The following tests FAILED:
>>          1 - sample_test (BAD_COMMAND)
>> Errors while running CTest
>> NMAKE : fatal error U1077: 'echo' : return code '0x8'
>> Stop.
>>
>> No matter what options I supply to ctest, I can't seem to get any
>> additional insight. I am assuming that for some reason the
>> WORKING_DIRECTORY isn't being obeyed on Windows?
>>
>> If I run the python script manually from the command prompt, it works
>> fine. The python executable is in my $PATH.On Linux I am using CMake
>> 3.3.1, and on Windows I have CMake 3.2.3.
>>
>> ----
>>
>> sample.cpp
>>
>> int main()
>> {
>>  return 0;
>> }
>>
>> --------------
>>
>> sample_test.py
>>
>> #!/usr/bin/env python
>> import sys
>> import subprocess
>>
>> sample = subprocess.Popen("./sample")
>> sample.wait()
>> if sample.returncode != 0:
>>    sys.exit(1)
>> else:
>>    sys.exit(0)
>> ~
>> ------------------------
>>
>> CMakeLists.txt
>>
>> cmake_minimum_required(VERSION 3.0)
>> project(sampleprg)
>>
>> enable_testing()
>>
>> add_executable( sample sample.cpp )
>>
>> add_test(NAME sample_test
>>         COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
>>         WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )
> You have to manuall call python with the script as argument. Shebang lines don't work on Windows.
>
> HS
Do you mean the shebangs don't work from within CMake? Because I
certainly can simply call the python script from the command line
without using "python simple_test.py" and it works fine.


From mkeeler at tenable.com  Wed Feb 24 09:50:53 2016
From: mkeeler at tenable.com (Matthew Keeler)
Date: Wed, 24 Feb 2016 09:50:53 -0500
Subject: [CMake] Calling a Python Testing Script from CMake/CTest
In-Reply-To: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
References: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
Message-ID: <etPan.56cdc34d.32ee9e4a.ac3a@wireless-tns3477l.keeler.lan>

My guess is that the command prompt is seeing the .py extension and automatically invoking the python interpreter for you. On other platforms it looks for the #!/usr/bin/env python which won?t work on windows.What you should do is use the FindPythonInterp cmake module to find your python executable and specify the interpreter to execute in your add test line.?https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html

Something like the following should work (I have not tested so the syntax might need some slight tweaks).

include(FindPythonInterp)
add_test(NAME sample_test COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )

--?
Matthew Keeler
On February 24, 2016 at 09:15:10, George Ryan (george.ryan at geospectrum.ca) wrote:

Hi,  

I am having difficulty getting a python script to run a C++ subprocess  
on Window 7 using VS2013. On Linux, the following code works fine, but  
on Windows, from the command line I get the following output:  

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1  
Copyright (C) Microsoft Corporation. All rights reserved.  

Running tests...  
Test project C:/work/s/sandbox/ctestpy/b  
Start 1: sample_test  
1/1 Test #1: sample_test ......................***Not Run 0.00 sec  

0% tests passed, 1 tests failed out of 1  

Total Test time (real) = 0.06 sec  

The following tests FAILED:  
1 - sample_test (BAD_COMMAND)  
Errors while running CTest  
NMAKE : fatal error U1077: 'echo' : return code '0x8'  
Stop.  

No matter what options I supply to ctest, I can't seem to get any  
additional insight. I am assuming that for some reason the  
WORKING_DIRECTORY isn't being obeyed on Windows?  

If I run the python script manually from the command prompt, it works  
fine. The python executable is in my $PATH.On Linux I am using CMake  
3.3.1, and on Windows I have CMake 3.2.3.  

----  

sample.cpp  

int main()  
{  
return 0;  
}  

--------------  

sample_test.py  

#!/usr/bin/env python  
import sys  
import subprocess  

sample = subprocess.Popen("./sample")  
sample.wait()  
if sample.returncode != 0:  
sys.exit(1)  
else:  
sys.exit(0)  
~  
------------------------  

CMakeLists.txt  

cmake_minimum_required(VERSION 3.0)  
project(sampleprg)  

enable_testing()  

add_executable( sample sample.cpp )  

add_test(NAME sample_test  
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py  
WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )  




--  

Powered by www.kitware.com  

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

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

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

From George.Ryan at geospectrum.ca  Wed Feb 24 10:10:49 2016
From: George.Ryan at geospectrum.ca (George Ryan)
Date: Wed, 24 Feb 2016 15:10:49 +0000
Subject: [CMake] Calling a Python Testing Script from CMake/CTest
References: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
 <etPan.56cdc34d.32ee9e4a.ac3a@wireless-tns3477l.keeler.lan>
Message-ID: <DEB25E01010D304BAA1B84C9D644A929E4A45F@GEOSPECTRUM-SRV.geospectrum.local>

Thanks, Matthew. That worked.

I had tried something similar using find(PythonInterp REQUIRED), but that didn't work. The include() worked perfectly!

Thanks!
George


On 02/24/2016 10:51 AM, Matthew Keeler wrote:
My guess is that the command prompt is seeing the .py extension and automatically invoking the python interpreter for you. On other platforms it looks for the #!/usr/bin/env python which won?t work on windows.What you should do is use the FindPythonInterp cmake module to find your python executable and specify the interpreter to execute in your add test line. https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html

Something like the following should work (I have not tested so the syntax might need some slight tweaks).

include(FindPythonInterp)
add_test(NAME sample_test COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )

--
Matthew Keeler

On February 24, 2016 at 09:15:10, George Ryan (george.ryan at geospectrum.ca<mailto:george.ryan at geospectrum.ca>) wrote:

Hi,

I am having difficulty getting a python script to run a C++ subprocess
on Window 7 using VS2013. On Linux, the following code works fine, but
on Windows, from the command line I get the following output:

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.

Running tests...
Test project C:/work/s/sandbox/ctestpy/b
Start 1: sample_test
1/1 Test #1: sample_test ......................***Not Run 0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 0.06 sec

The following tests FAILED:
1 - sample_test (BAD_COMMAND)
Errors while running CTest
NMAKE : fatal error U1077: 'echo' : return code '0x8'
Stop.

No matter what options I supply to ctest, I can't seem to get any
additional insight. I am assuming that for some reason the
WORKING_DIRECTORY isn't being obeyed on Windows?

If I run the python script manually from the command prompt, it works
fine. The python executable is in my $PATH.On Linux I am using CMake
3.3.1, and on Windows I have CMake 3.2.3.

----

sample.cpp

int main()
{
return 0;
}

--------------

sample_test.py

#!/usr/bin/env python
import sys
import subprocess

sample = subprocess.Popen("./sample")
sample.wait()
if sample.returncode != 0:
sys.exit(1)
else:
sys.exit(0)
~
------------------------

CMakeLists.txt

cmake_minimum_required(VERSION 3.0)
project(sampleprg)

enable_testing()

add_executable( sample sample.cpp )

add_test(NAME sample_test
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )




--

Powered by www.kitware.com<http://www.kitware.com>

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

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

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

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

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


--
Senior Software Architect
GeoSpectrum Technologies Inc.
Dartmouth, Nova Scotia, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160224/dab5e5b4/attachment-0001.html>

From gjasny at googlemail.com  Wed Feb 24 11:34:39 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Wed, 24 Feb 2016 17:34:39 +0100
Subject: [CMake] [ANNOUNCE] CMake 3.5.0-rc3 is now ready!
In-Reply-To: <CAFzjYVpmPN1VrTZgFG_SuNSHkAL35Y0SaOpbZ8hOwzRBW5Q5iQ@mail.gmail.com>
References: <CAFzjYVpmPN1VrTZgFG_SuNSHkAL35Y0SaOpbZ8hOwzRBW5Q5iQ@mail.gmail.com>
Message-ID: <56CDDB9F.5060105@googlemail.com>

Hello,

I discovered that the Visual Studio 2015 Generator does not work with 
v120 toolsets (#15986) and consider that major issue.

As far as I see this is related to the debug information setting from 
#15894.

Thanks,
Gregor

From orion at cora.nwra.com  Wed Feb 24 14:10:36 2016
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 24 Feb 2016 12:10:36 -0700
Subject: [CMake] Immutable variables?
Message-ID: <56CE002C.6060507@cora.nwra.com>

I ran across a project that set CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR.  This is a
really bad idea, but apparently used to work for their use case.  With cmake
3.5 this no longer works, but was somewhat hard to track down.

I'm wondering if is makes to be able to mark cmake generated variables as
immutable and error out if they are attempted to be set.  Thoughts?

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                   http://www.nwra.com

From post at hendrik-sattler.de  Wed Feb 24 14:55:33 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 24 Feb 2016 20:55:33 +0100
Subject: [CMake] Calling a Python Testing Script from CMake/CTest
In-Reply-To: <DEB25E01010D304BAA1B84C9D644A929E4A45F@GEOSPECTRUM-SRV.geospectrum.local>
References: <DEB25E01010D304BAA1B84C9D644A929E4A194@GEOSPECTRUM-SRV.geospectrum.local>
 <etPan.56cdc34d.32ee9e4a.ac3a@wireless-tns3477l.keeler.lan>
 <DEB25E01010D304BAA1B84C9D644A929E4A45F@GEOSPECTRUM-SRV.geospectrum.local>
Message-ID: <175540F4-9C3C-419A-96A1-0027BB97838B@hendrik-sattler.de>

It actually should be used using find_package()

HS


Am 24. Februar 2016 16:10:49 MEZ, schrieb George Ryan <George.Ryan at geospectrum.ca>:
>Thanks, Matthew. That worked.
>
>I had tried something similar using find(PythonInterp REQUIRED), but
>that didn't work. The include() worked perfectly!
>
>Thanks!
>George
>
>
>On 02/24/2016 10:51 AM, Matthew Keeler wrote:
>My guess is that the command prompt is seeing the .py extension and
>automatically invoking the python interpreter for you. On other
>platforms it looks for the #!/usr/bin/env python which won?t work on
>windows.What you should do is use the FindPythonInterp cmake module to
>find your python executable and specify the interpreter to execute in
>your add test line.
>https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html
>
>Something like the following should work (I have not tested so the
>syntax might need some slight tweaks).
>
>include(FindPythonInterp)
>add_test(NAME sample_test COMMAND ${PYTHON_EXECUTABLE}
>${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py WORKING_DIRECTORY
>${EXECUTABLE_OUTPUT_PATH} )
>
>--
>Matthew Keeler
>
>On February 24, 2016 at 09:15:10, George Ryan
>(george.ryan at geospectrum.ca<mailto:george.ryan at geospectrum.ca>) wrote:
>
>Hi,
>
>I am having difficulty getting a python script to run a C++ subprocess
>on Window 7 using VS2013. On Linux, the following code works fine, but
>on Windows, from the command line I get the following output:
>
>Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
>Copyright (C) Microsoft Corporation. All rights reserved.
>
>Running tests...
>Test project C:/work/s/sandbox/ctestpy/b
>Start 1: sample_test
>1/1 Test #1: sample_test ......................***Not Run 0.00 sec
>
>0% tests passed, 1 tests failed out of 1
>
>Total Test time (real) = 0.06 sec
>
>The following tests FAILED:
>1 - sample_test (BAD_COMMAND)
>Errors while running CTest
>NMAKE : fatal error U1077: 'echo' : return code '0x8'
>Stop.
>
>No matter what options I supply to ctest, I can't seem to get any
>additional insight. I am assuming that for some reason the
>WORKING_DIRECTORY isn't being obeyed on Windows?
>
>If I run the python script manually from the command prompt, it works
>fine. The python executable is in my $PATH.On Linux I am using CMake
>3.3.1, and on Windows I have CMake 3.2.3.
>
>----
>
>sample.cpp
>
>int main()
>{
>return 0;
>}
>
>--------------
>
>sample_test.py
>
>#!/usr/bin/env python
>import sys
>import subprocess
>
>sample = subprocess.Popen("./sample")
>sample.wait()
>if sample.returncode != 0:
>sys.exit(1)
>else:
>sys.exit(0)
>~
>------------------------
>
>CMakeLists.txt
>
>cmake_minimum_required(VERSION 3.0)
>project(sampleprg)
>
>enable_testing()
>
>add_executable( sample sample.cpp )
>
>add_test(NAME sample_test
>COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
>WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )
>
>
>
>
>--
>
>Powered by www.kitware.com<http://www.kitware.com>
>
>Please keep messages on-topic and check the CMake FAQ at:
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For
>more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
>
>
>--
>Senior Software Architect
>GeoSpectrum Technologies Inc.
>Dartmouth, Nova Scotia, Canada
>
>
>------------------------------------------------------------------------
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at:
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For
>more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/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/20160224/37e6e62f/attachment.html>

From Kent.Knox at amd.com  Thu Feb 25 01:04:32 2016
From: Kent.Knox at amd.com (Knox, Kent)
Date: Thu, 25 Feb 2016 06:04:32 +0000
Subject: [CMake] ExternalProject_Add with flexible install commands
Message-ID: <DM3PR12MB0874CAD7205B2F44476AC128F5A50@DM3PR12MB0874.namprd12.prod.outlook.com>

I am having a problem passing parameters as a variable into ExternalProject_Add(). I seem to be fighting syntax, i've tried many different variants with the set() statement


#######################

# Default behavior is to NOT install library, empty quotes should disable install
set( libxxx_inst_comm INSTALL_COMMAND "\"\"" )

# Build the library as an external project
  ExternalProject_Add( libxxx
    SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
    ${libxxx_inst_comm}
  )
#######################

I get this message, which appears to be within ExternalProject_add() using add_custom_command.  Is there a way around this?


CMake Error at /opt/homebrew-cask/Caskroom/cmake/3.2.2/CMake.app/Contents/share/cmake-3.2/Modules/ExternalProject.cmake:1487 (add_custom_command):

  COMMAND may not contain literal quotes:


    ""

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

From petr.kmoch at gmail.com  Thu Feb 25 03:46:23 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 25 Feb 2016 09:46:23 +0100
Subject: [CMake] ExternalProject_Add with flexible install commands
In-Reply-To: <DM3PR12MB0874CAD7205B2F44476AC128F5A50@DM3PR12MB0874.namprd12.prod.outlook.com>
References: <DM3PR12MB0874CAD7205B2F44476AC128F5A50@DM3PR12MB0874.namprd12.prod.outlook.com>
Message-ID: <CAKohaZex4OCHCcAm+y6g9P=XwBrv1KBMvaHoPg+pfLxxjKzWbw@mail.gmail.com>

Hi Kent,

I believe it's not "empty quotes" that disables the install command, it's
the empty string. So you should not escape the quotes:

#######################
# Default behavior is to NOT install library, empty quotes should disable
install
set( libxxx_inst_comm INSTALL_COMMAND "" )

# Build the library as an external project
  ExternalProject_Add( libxxx
    SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
    ${libxxx_inst_comm}
  )
#######################

Petr


On Thu, Feb 25, 2016 at 7:04 AM, Knox, Kent <Kent.Knox at amd.com> wrote:

> I am having a problem passing parameters as a variable into
> ExternalProject_Add(). I seem to be fighting syntax, i've tried many
> different variants with the set() statement
>
>
> #######################
>
> # Default behavior is to NOT install library, empty quotes should disable
> install
> set( libxxx_inst_comm INSTALL_COMMAND "\"\"" )
>
> # Build the library as an external project
>   ExternalProject_Add( libxxx
>     SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
>     ${libxxx_inst_comm}
>   )
> #######################
>
> I get this message, which appears to be within ExternalProject_add()
> using add_custom_command.  Is there a way around this?
>
> CMake Error at
> /opt/homebrew-cask/Caskroom/cmake/3.2.2/CMake.app/Contents/share/cmake-3.2/Modules/ExternalProject.cmake:1487
> (add_custom_command):
>
>   COMMAND may not contain literal quotes:
>
>
>     ""
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160225/5265fd9b/attachment-0001.html>

From ruslan_baratov at yahoo.com  Thu Feb 25 09:58:38 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Thu, 25 Feb 2016 21:58:38 +0700
Subject: [CMake] file(SHA1) vs string(SHA1) consistency
Message-ID: <56CF169E.8040801@yahoo.com>

Hi,

Following code produce same SHA1 on Linux:

    cmake_minimum_required(VERSION 3.0)

    set(test_string "a\nb")
    set(test_file "test.file")

    string(SHA1 sha1_string "${test_string}")

    file(WRITE "${test_file}" "${test_string}")
    file(SHA1 "${test_file}" sha1_file)

    message("sha1:")
    message("  ${sha1_file}")
    message("  ${sha1_string}")

result:

    sha1:
       fcd127ffa1016069006ad91f3f361248f9bdf272
       fcd127ffa1016069006ad91f3f361248f9bdf272

but not same SHA1 on Windows:

    sha1:
       ec6cb5b8c69f8b476a380c9b6e38e18c2733ae7b
       fcd127ffa1016069006ad91f3f361248f9bdf272

I think this is because of DOS end of lines. Two thoughts:
* file(SHA1) and string(SHA1) should be the same on same input string
* since CMake is a cross-platform tool I think it make sense that 
command `file(WRITE "..." "a\nb")` produce identical files on all platforms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160225/2b943d0e/attachment.html>

From vania.joloboff at inria.fr  Thu Feb 25 10:13:50 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 25 Feb 2016 16:13:50 +0100
Subject: [CMake] cmake documentation incomplete
In-Reply-To: <56CE002C.6060507@cora.nwra.com>
References: <56CE002C.6060507@cora.nwra.com>
Message-ID: <56CF1A2E.3040702@inria.fr>

Hi,

The cmake documentation says there are two alternatives
to start cmake

cmake [<options>] (<path-to-source> | <path-to-existing-build>)

But it does not explain nowhere the difference between the two...
Does the path-to-existing-build retrieve itself the source dir
and start like if it were invoked with path-to-source
from path-to-existing-build working directory ?

Vania


From nicholas11braden at gmail.com  Thu Feb 25 10:16:11 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Thu, 25 Feb 2016 09:16:11 -0600
Subject: [CMake] cmake documentation incomplete
In-Reply-To: <56CF1A2E.3040702@inria.fr>
References: <56CE002C.6060507@cora.nwra.com>
	<56CF1A2E.3040702@inria.fr>
Message-ID: <CAHk1PgFmOX1KEzeAM1Og9aZcVrX_F0q7f3HXe43DCz5j1GcrRA@mail.gmail.com>

Yes, an existing build saves all the information it needs in the build
cache. Once you have created a build, you never need to specify the
source directory again.

On Thu, Feb 25, 2016 at 9:13 AM, Vania Joloboff <vania.joloboff at inria.fr> wrote:
> Hi,
>
> The cmake documentation says there are two alternatives
> to start cmake
>
> cmake [<options>] (<path-to-source> | <path-to-existing-build>)
>
> But it does not explain nowhere the difference between the two...
> Does the path-to-existing-build retrieve itself the source dir
> and start like if it were invoked with path-to-source
> from path-to-existing-build working directory ?
>
> Vania
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 vania.joloboff at inria.fr  Thu Feb 25 10:37:28 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 25 Feb 2016 16:37:28 +0100
Subject: [CMake] cmake documentation incomplete
In-Reply-To: <CAHk1PgFmOX1KEzeAM1Og9aZcVrX_F0q7f3HXe43DCz5j1GcrRA@mail.gmail.com>
References: <56CE002C.6060507@cora.nwra.com> <56CF1A2E.3040702@inria.fr>
 <CAHk1PgFmOX1KEzeAM1Og9aZcVrX_F0q7f3HXe43DCz5j1GcrRA@mail.gmail.com>
Message-ID: <56CF1FB8.7030003@inria.fr>

Thanks Nicholas,

Then if I run cmake from a shell script in working directory pwd
(and I do not want to cd)
can I tell cmake the first time to take the source
in path-to-source and do the build in path-to-build ?

I have read there is an undocumented option -B to do this ?

Vania


On 02/25/2016 04:16 PM, Nicholas Braden wrote:
> Yes, an existing build saves all the information it needs in the build
> cache. Once you have created a build, you never need to specify the
> source directory again.
>
> On Thu, Feb 25, 2016 at 9:13 AM, Vania Joloboff <vania.joloboff at inria.fr> wrote:
>> Hi,
>>
>> The cmake documentation says there are two alternatives
>> to start cmake
>>
>> cmake [<options>] (<path-to-source> | <path-to-existing-build>)
>>
>> But it does not explain nowhere the difference between the two...
>> Does the path-to-existing-build retrieve itself the source dir
>> and start like if it were invoked with path-to-source
>> from path-to-existing-build working directory ?
>>
>> Vania
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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 nicholas11braden at gmail.com  Thu Feb 25 10:43:28 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Thu, 25 Feb 2016 09:43:28 -0600
Subject: [CMake] cmake documentation incomplete
In-Reply-To: <56CF1FB8.7030003@inria.fr>
References: <56CE002C.6060507@cora.nwra.com> <56CF1A2E.3040702@inria.fr>
 <CAHk1PgFmOX1KEzeAM1Og9aZcVrX_F0q7f3HXe43DCz5j1GcrRA@mail.gmail.com>
 <56CF1FB8.7030003@inria.fr>
Message-ID: <CAHk1PgGzbgbi2vWU5QGEfokgcTS=9k1PiNZGr8yQHchS3Y37JQ@mail.gmail.com>

I don't know about -B, but you can take advantage of the tool mode like this:

cmake -E chdir path/to/build cmake [options] path/to/source

Effectively you can use the chdir tool to spawn CMake with the working
directory you want it to have.

On Thu, Feb 25, 2016 at 9:37 AM, Vania Joloboff <vania.joloboff at inria.fr> wrote:
> Thanks Nicholas,
>
> Then if I run cmake from a shell script in working directory pwd
> (and I do not want to cd)
> can I tell cmake the first time to take the source
> in path-to-source and do the build in path-to-build ?
>
> I have read there is an undocumented option -B to do this ?
>
> Vania
>
>
> On 02/25/2016 04:16 PM, Nicholas Braden wrote:
>>
>> Yes, an existing build saves all the information it needs in the build
>> cache. Once you have created a build, you never need to specify the
>> source directory again.
>>
>> On Thu, Feb 25, 2016 at 9:13 AM, Vania Joloboff <vania.joloboff at inria.fr>
>> wrote:
>>>
>>> Hi,
>>>
>>> The cmake documentation says there are two alternatives
>>> to start cmake
>>>
>>> cmake [<options>] (<path-to-source> | <path-to-existing-build>)
>>>
>>> But it does not explain nowhere the difference between the two...
>>> Does the path-to-existing-build retrieve itself the source dir
>>> and start like if it were invoked with path-to-source
>>> from path-to-existing-build working directory ?
>>>
>>> Vania
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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 Kent.Knox at amd.com  Thu Feb 25 11:03:59 2016
From: Kent.Knox at amd.com (Knox, Kent)
Date: Thu, 25 Feb 2016 16:03:59 +0000
Subject: [CMake] ExternalProject_Add with flexible install commands
In-Reply-To: <CAKohaZex4OCHCcAm+y6g9P=XwBrv1KBMvaHoPg+pfLxxjKzWbw@mail.gmail.com>
References: <DM3PR12MB0874CAD7205B2F44476AC128F5A50@DM3PR12MB0874.namprd12.prod.outlook.com>,
 <CAKohaZex4OCHCcAm+y6g9P=XwBrv1KBMvaHoPg+pfLxxjKzWbw@mail.gmail.com>
Message-ID: <DM3PR12MB0874BA95598A58F67BFE9DBBF5A60@DM3PR12MB0874.namprd12.prod.outlook.com>

Hi Petr~

Thanks for your reply.


These set statements do not appear to work.  Either the command 'installs' the dependency, or an error pops up.


set( rocblas_INSTALL_COMMAND INSTALL_COMMAND "" )
--> this installs the dependency

set( rocblas_INSTALL_COMMAND INSTALL_COMMAND " " )
--> /bin/sh: 1:  : not found

set( rocblas_INSTALL_COMMAND INSTALL_COMMAND """" )
--> CMake Warning (dev) in CMakeLists.txt
--> Argument not separated from preceding token by whitespace.

Kent

________________________________
From: Petr Kmoch <petr.kmoch at gmail.com>
Sent: Thursday, February 25, 2016 2:46 AM
To: Knox, Kent
Cc: cmake at cmake.org
Subject: Re: [CMake] ExternalProject_Add with flexible install commands

Hi Kent,

I believe it's not "empty quotes" that disables the install command, it's the empty string. So you should not escape the quotes:


#######################

# Default behavior is to NOT install library, empty quotes should disable install
set( libxxx_inst_comm INSTALL_COMMAND "" )

# Build the library as an external project
  ExternalProject_Add( libxxx
    SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
    ${libxxx_inst_comm}
  )
#######################

Petr

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

From DLRdave at aol.com  Thu Feb 25 11:57:02 2016
From: DLRdave at aol.com (David Cole)
Date: Thu, 25 Feb 2016 11:57:02 -0500
Subject: [CMake] ExternalProject_Add with flexible install commands
In-Reply-To: <DM3PR12MB0874BA95598A58F67BFE9DBBF5A60@DM3PR12MB0874.namprd12.prod.outlook.com>
References: <DM3PR12MB0874CAD7205B2F44476AC128F5A50@DM3PR12MB0874.namprd12.prod.outlook.com>
 <CAKohaZex4OCHCcAm+y6g9P=XwBrv1KBMvaHoPg+pfLxxjKzWbw@mail.gmail.com>
 <DM3PR12MB0874BA95598A58F67BFE9DBBF5A60@DM3PR12MB0874.namprd12.prod.outlook.com>
Message-ID: <CAKME8fGm7bnHOyD8s+KS_bBxUrr7WuTqPmmiJX2QW1Odpwgx+g@mail.gmail.com>

Do you need to do it indirectly through a variable like this?

If you just use:
  INSTALL_COMMAND ""

directly in the ExternalProject_Add call, it will work.

If you really need to do it indirectly, there's probably a way, but it
will also probably be more confusing for people reading the code in
the future. Not sure it's worth that trade-off. You could always
"cheat" and execute a no-op command for the install step rather than
"skipping" it. i.e. INSTALL_COMMAND ${CMAKE_COMMAND} -E echo
NoInstallStep ...


HTH,
David C.




On Thu, Feb 25, 2016 at 11:03 AM, Knox, Kent <Kent.Knox at amd.com> wrote:
> Hi Petr~
>
> Thanks for your reply.
>
>
> These set statements do not appear to work.  Either the command 'installs'
> the dependency, or an error pops up.
>
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND "" )
> --> this installs the dependency
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND " " )
> --> /bin/sh: 1:  : not found
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND """" )
> --> CMake Warning (dev) in CMakeLists.txt
> --> Argument not separated from preceding token by whitespace.
>
> Kent
>
> ________________________________
> From: Petr Kmoch <petr.kmoch at gmail.com>
> Sent: Thursday, February 25, 2016 2:46 AM
> To: Knox, Kent
> Cc: cmake at cmake.org
> Subject: Re: [CMake] ExternalProject_Add with flexible install commands
>
> Hi Kent,
>
> I believe it's not "empty quotes" that disables the install command, it's
> the empty string. So you should not escape the quotes:
>
> #######################
>
> # Default behavior is to NOT install library, empty quotes should disable
> install
> set( libxxx_inst_comm INSTALL_COMMAND "" )
>
> # Build the library as an external project
>   ExternalProject_Add( libxxx
>     SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
>     ${libxxx_inst_comm}
>   )
> #######################
>
> Petr
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 Kent.Knox at amd.com  Thu Feb 25 14:25:02 2016
From: Kent.Knox at amd.com (Knox, Kent)
Date: Thu, 25 Feb 2016 19:25:02 +0000
Subject: [CMake] ExternalProject_Add with flexible install commands
In-Reply-To: <CAKME8fGm7bnHOyD8s+KS_bBxUrr7WuTqPmmiJX2QW1Odpwgx+g@mail.gmail.com>
References: <DM3PR12MB0874CAD7205B2F44476AC128F5A50@DM3PR12MB0874.namprd12.prod.outlook.com>
 <CAKohaZex4OCHCcAm+y6g9P=XwBrv1KBMvaHoPg+pfLxxjKzWbw@mail.gmail.com>
 <DM3PR12MB0874BA95598A58F67BFE9DBBF5A60@DM3PR12MB0874.namprd12.prod.outlook.com>,
 <CAKME8fGm7bnHOyD8s+KS_bBxUrr7WuTqPmmiJX2QW1Odpwgx+g@mail.gmail.com>
Message-ID: <DM3PR12MB087442CD90FC94C9C3CADDBEF5A60@DM3PR12MB0874.namprd12.prod.outlook.com>

I don't need to use indirection, but the reason I decided to try was to simplify my code.  I could either wrap the ExternalProject_Add() call in a branch/switch or a single set() call.  

I am using your 'hack' thusly:
set( libxxx_inst_comm INSTALL_COMMAND ${CMAKE_COMMAND} -E echo_append )

and it's working great for me.  I have no problem documenting what i'm doing in my code.

Thank you for your input!

K
________________________________________
From: David Cole <DLRdave at aol.com>
Sent: Thursday, February 25, 2016 10:57 AM
To: Knox, Kent
Cc: Petr Kmoch; cmake at cmake.org
Subject: Re: [CMake] ExternalProject_Add with flexible install commands

Do you need to do it indirectly through a variable like this?

If you just use:
  INSTALL_COMMAND ""

directly in the ExternalProject_Add call, it will work.

If you really need to do it indirectly, there's probably a way, but it
will also probably be more confusing for people reading the code in
the future. Not sure it's worth that trade-off. You could always
"cheat" and execute a no-op command for the install step rather than
"skipping" it. i.e. INSTALL_COMMAND ${CMAKE_COMMAND} -E echo
NoInstallStep ...


HTH,
David C.




On Thu, Feb 25, 2016 at 11:03 AM, Knox, Kent <Kent.Knox at amd.com> wrote:
> Hi Petr~
>
> Thanks for your reply.
>
>
> These set statements do not appear to work.  Either the command 'installs'
> the dependency, or an error pops up.
>
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND "" )
> --> this installs the dependency
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND " " )
> --> /bin/sh: 1:  : not found
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND """" )
> --> CMake Warning (dev) in CMakeLists.txt
> --> Argument not separated from preceding token by whitespace.
>
> Kent
>
> ________________________________
> From: Petr Kmoch <petr.kmoch at gmail.com>
> Sent: Thursday, February 25, 2016 2:46 AM
> To: Knox, Kent
> Cc: cmake at cmake.org
> Subject: Re: [CMake] ExternalProject_Add with flexible install commands
>
> Hi Kent,
>
> I believe it's not "empty quotes" that disables the install command, it's
> the empty string. So you should not escape the quotes:
>
> #######################
>
> # Default behavior is to NOT install library, empty quotes should disable
> install
> set( libxxx_inst_comm INSTALL_COMMAND "" )
>
> # Build the library as an external project
>   ExternalProject_Add( libxxx
>     SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
>     ${libxxx_inst_comm}
>   )
> #######################
>
> Petr
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 athundt at gmail.com  Thu Feb 25 18:00:04 2016
From: athundt at gmail.com (Andrew Hundt)
Date: Thu, 25 Feb 2016 18:00:04 -0500
Subject: [CMake] check_cxx_compiler_flag fails silently for complex compiler
	paths
Message-ID: <CAMCxpGszHHpp_8XkwcYUZba9_c0ry6vdyUJOsSzwdLO-26B75Q@mail.gmail.com>

I believe check_cxx_compiler_flags is failing due to a long/complicated
compiler path.

Specifically my compiler is set to:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++

CMake version: 3.4.3

Full trace output in gist where you can see lines warning of regex failure:
https://gist.github.com/ahundt/88ce65bcc3c268acdd94


Here is the code snippet that fails:

include(CheckCXXCompilerFlag)
> check_cxx_compiler_flag(-std=c++11 COMPILER_SUPPORTS_CXX11)
> check_cxx_compiler_flag(-std=c++0x COMPILER_SUPPORTS_CXX0X)
> message(STATUS <<<<<<<<COMPILER_SUPPORTS_CXX11:${COMPILER_SUPPORTS_CXX11})


The above STATUS printout will be as if nothing was done that would set the
variable COMPILER_SUPPORTS_CXX11. In other words it is empty.

Here is the end of the trace:

> /usr/local/Cellar/cmake/3.4.3/share/cmake/Modules/CheckCXXCompilerFlag.cmake(62):
>  set(CMAKE_REQUIRED_DEFINITIONS ${{SAFE_CMAKE_REQUIRED_DEFINITIONS}} )
> /Users/athundt/source/costar_ws/src/iai_kinect2/kinect2_registration/CMakeLists.txt(14):
>  message(STATUS
> <<<<<<<<COMPILER_SUPPORTS_CXX11:${{COMPILER_SUPPORTS_CXX11}} )
> -- <<<<<<<<COMPILER_SUPPORTS_CXX11:
> /Users/athundt/source/costar_ws/src/iai_kinect2/kinect2_registration/CMakeLists.txt(15):
>  IF(COMPILER_SUPPORTS_CXX11 )
> /Users/athundt/source/costar_ws/src/iai_kinect2/kinect2_registration/CMakeLists.txt(17):
>  ELSEIF(COMPILER_SUPPORTS_CXX0X )
> /Users/athundt/source/costar_ws/src/iai_kinect2/kinect2_registration/CMakeLists.txt(19):
>  ELSE()
> /Users/athundt/source/costar_ws/src/iai_kinect2/kinect2_registration/CMakeLists.txt(20):
>  MESSAGE(FATAL_ERROR The compiler ${{CMAKE_CXX_COMPILER}} has no C++11
> support. Please use a different C++ compiler. )
> CMake Error at CMakeLists.txt:20 (MESSAGE):
>   The compiler
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>   has no C++11 support.  Please use a different C++ compiler.
>
> -- Configuring incomplete, errors occurred!



Cheers!
Andrew Hundt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160225/069cb539/attachment.html>

From cedric.doucet at inria.fr  Fri Feb 26 09:37:41 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Fri, 26 Feb 2016 15:37:41 +0100 (CET)
Subject: [CMake] Install from a source directory with ExternalProject
In-Reply-To: <132124429.8967161.1456497412247.JavaMail.zimbra@inria.fr>
Message-ID: <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>


Hello, 

I would like to know if it's possible to download and install an external project from a source directory instead of a tarball. 
I tried to do it with ExternalProject_Add function but it tries to uncompress source files and then fails. 

C?dric 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160226/4410af4f/attachment.html>

From nicholas11braden at gmail.com  Fri Feb 26 09:40:26 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Fri, 26 Feb 2016 08:40:26 -0600
Subject: [CMake] Install from a source directory with ExternalProject
In-Reply-To: <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>
References: <132124429.8967161.1456497412247.JavaMail.zimbra@inria.fr>
 <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>
Message-ID: <CAHk1PgHAgt1UuHuM4Mcr6aHVXeyd0n5E184zb8qLbBmG8DiN9A@mail.gmail.com>

I'm not sure how you would download a directory without it being in
some sort of archive. If you just want to use an existing directory,
use the SOURCE_DIR option instead.

On Fri, Feb 26, 2016 at 8:37 AM, Cedric Doucet <cedric.doucet at inria.fr> wrote:
>
> Hello,
>
> I would like to know if it's possible to download and install an external
> project from a source directory instead of a tarball.
> I tried to do it with ExternalProject_Add function but it tries to
> uncompress source files and then fails.
>
> C?dric
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 cedric.doucet at inria.fr  Fri Feb 26 09:45:02 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Fri, 26 Feb 2016 15:45:02 +0100 (CET)
Subject: [CMake] Install from a source directory with ExternalProject
In-Reply-To: <CAHk1PgHAgt1UuHuM4Mcr6aHVXeyd0n5E184zb8qLbBmG8DiN9A@mail.gmail.com>
References: <132124429.8967161.1456497412247.JavaMail.zimbra@inria.fr>
 <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>
 <CAHk1PgHAgt1UuHuM4Mcr6aHVXeyd0n5E184zb8qLbBmG8DiN9A@mail.gmail.com>
Message-ID: <1156096331.8970796.1456497902006.JavaMail.zimbra@inria.fr>


Hello Nicholas,

thank you for your answer.
Actually, it's not my own directory and I have no choice.
I want to download source files from there :
http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/c++/
I know how to do it with FILE(DOWNLOAD ...) but I would like to know if there is a way to do it with ExternalProject_Add.

C?dric



----- Mail original -----
> De: "Nicholas Braden" <nicholas11braden at gmail.com>
> ?: "Cedric Doucet" <cedric.doucet at inria.fr>
> Cc: cmake at cmake.org
> Envoy?: Vendredi 26 F?vrier 2016 15:40:26
> Objet: Re: [CMake] Install from a source directory with ExternalProject
> 
> I'm not sure how you would download a directory without it being in
> some sort of archive. If you just want to use an existing directory,
> use the SOURCE_DIR option instead.
> 
> On Fri, Feb 26, 2016 at 8:37 AM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
> >
> > Hello,
> >
> > I would like to know if it's possible to download and install an external
> > project from a source directory instead of a tarball.
> > I tried to do it with ExternalProject_Add function but it tries to
> > uncompress source files and then fails.
> >
> > C?dric
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/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 nicholas11braden at gmail.com  Fri Feb 26 09:56:02 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Fri, 26 Feb 2016 08:56:02 -0600
Subject: [CMake] Install from a source directory with ExternalProject
In-Reply-To: <1156096331.8970796.1456497902006.JavaMail.zimbra@inria.fr>
References: <132124429.8967161.1456497412247.JavaMail.zimbra@inria.fr>
 <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>
 <CAHk1PgHAgt1UuHuM4Mcr6aHVXeyd0n5E184zb8qLbBmG8DiN9A@mail.gmail.com>
 <1156096331.8970796.1456497902006.JavaMail.zimbra@inria.fr>
Message-ID: <CAHk1PgEmfObZcN4OC0UcS6BnwcKcWDR54HJfa+xfMi+GFxeZAA@mail.gmail.com>

Hmm, if it were available as an FTP share you may have been able to
use a command line program via DOWNLOAD_COMMAND, but in this case I
think you really only have two options:

A. Write a small portable program compiled as part of your project,
with its task being to download that directory. Make sure the external
project DEPENDS on it and use it as the DOWNLOAD_COMMAND.

B. If the directory in question does not change often, you can
probably get away with just maintaining several file(DOWNLOAD)
statements.

Someone else may know better than me; there may be something I
overlooked. But for now, this is all I can think of.

On Fri, Feb 26, 2016 at 8:45 AM, Cedric Doucet <cedric.doucet at inria.fr> wrote:
>
> Hello Nicholas,
>
> thank you for your answer.
> Actually, it's not my own directory and I have no choice.
> I want to download source files from there :
> http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/c++/
> I know how to do it with FILE(DOWNLOAD ...) but I would like to know if there is a way to do it with ExternalProject_Add.
>
> C?dric
>
>
>
> ----- Mail original -----
>> De: "Nicholas Braden" <nicholas11braden at gmail.com>
>> ?: "Cedric Doucet" <cedric.doucet at inria.fr>
>> Cc: cmake at cmake.org
>> Envoy?: Vendredi 26 F?vrier 2016 15:40:26
>> Objet: Re: [CMake] Install from a source directory with ExternalProject
>>
>> I'm not sure how you would download a directory without it being in
>> some sort of archive. If you just want to use an existing directory,
>> use the SOURCE_DIR option instead.
>>
>> On Fri, Feb 26, 2016 at 8:37 AM, Cedric Doucet <cedric.doucet at inria.fr>
>> wrote:
>> >
>> > Hello,
>> >
>> > I would like to know if it's possible to download and install an external
>> > project from a source directory instead of a tarball.
>> > I tried to do it with ExternalProject_Add function but it tries to
>> > uncompress source files and then fails.
>> >
>> > C?dric
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake community. For more
>> > information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/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 cedric.doucet at inria.fr  Fri Feb 26 10:10:07 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Fri, 26 Feb 2016 16:10:07 +0100 (CET)
Subject: [CMake] Install from a source directory with ExternalProject
In-Reply-To: <CAHk1PgEmfObZcN4OC0UcS6BnwcKcWDR54HJfa+xfMi+GFxeZAA@mail.gmail.com>
References: <132124429.8967161.1456497412247.JavaMail.zimbra@inria.fr>
 <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>
 <CAHk1PgHAgt1UuHuM4Mcr6aHVXeyd0n5E184zb8qLbBmG8DiN9A@mail.gmail.com>
 <1156096331.8970796.1456497902006.JavaMail.zimbra@inria.fr>
 <CAHk1PgEmfObZcN4OC0UcS6BnwcKcWDR54HJfa+xfMi+GFxeZAA@mail.gmail.com>
Message-ID: <234513101.8979774.1456499407774.JavaMail.zimbra@inria.fr>


Thank you very much Nicholas!
For the moment, option B sounds better for me. :)

I think it could be helpful to be able to disable the uncompression step of ExternalProject_Add, 
or to control it with a variable named UNCOMPRESSION_COMMAND or something similar.

Cheers,

C?dric




----- Mail original -----
> De: "Nicholas Braden" <nicholas11braden at gmail.com>
> ?: "Cedric Doucet" <cedric.doucet at inria.fr>
> Cc: cmake at cmake.org
> Envoy?: Vendredi 26 F?vrier 2016 15:56:02
> Objet: Re: [CMake] Install from a source directory with ExternalProject
> 
> Hmm, if it were available as an FTP share you may have been able to
> use a command line program via DOWNLOAD_COMMAND, but in this case I
> think you really only have two options:
> 
> A. Write a small portable program compiled as part of your project,
> with its task being to download that directory. Make sure the external
> project DEPENDS on it and use it as the DOWNLOAD_COMMAND.
> 
> B. If the directory in question does not change often, you can
> probably get away with just maintaining several file(DOWNLOAD)
> statements.
> 
> Someone else may know better than me; there may be something I
> overlooked. But for now, this is all I can think of.
> 
> On Fri, Feb 26, 2016 at 8:45 AM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
> >
> > Hello Nicholas,
> >
> > thank you for your answer.
> > Actually, it's not my own directory and I have no choice.
> > I want to download source files from there :
> > http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/c++/
> > I know how to do it with FILE(DOWNLOAD ...) but I would like to know if
> > there is a way to do it with ExternalProject_Add.
> >
> > C?dric
> >
> >
> >
> > ----- Mail original -----
> >> De: "Nicholas Braden" <nicholas11braden at gmail.com>
> >> ?: "Cedric Doucet" <cedric.doucet at inria.fr>
> >> Cc: cmake at cmake.org
> >> Envoy?: Vendredi 26 F?vrier 2016 15:40:26
> >> Objet: Re: [CMake] Install from a source directory with ExternalProject
> >>
> >> I'm not sure how you would download a directory without it being in
> >> some sort of archive. If you just want to use an existing directory,
> >> use the SOURCE_DIR option instead.
> >>
> >> On Fri, Feb 26, 2016 at 8:37 AM, Cedric Doucet <cedric.doucet at inria.fr>
> >> wrote:
> >> >
> >> > Hello,
> >> >
> >> > I would like to know if it's possible to download and install an
> >> > external
> >> > project from a source directory instead of a tarball.
> >> > I tried to do it with ExternalProject_Add function but it tries to
> >> > uncompress source files and then fails.
> >> >
> >> > C?dric
> >> >
> >> > --
> >> >
> >> > Powered by www.kitware.com
> >> >
> >> > Please keep messages on-topic and check the CMake FAQ at:
> >> > http://www.cmake.org/Wiki/CMake_FAQ
> >> >
> >> > Kitware offers various services to support the CMake community. For more
> >> > information on each offering, please visit:
> >> >
> >> > CMake Support: http://cmake.org/cmake/help/support.html
> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> > CMake Training Courses: http://cmake.org/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 nicholas11braden at gmail.com  Fri Feb 26 10:18:15 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Fri, 26 Feb 2016 09:18:15 -0600
Subject: [CMake] Install from a source directory with ExternalProject
In-Reply-To: <234513101.8979774.1456499407774.JavaMail.zimbra@inria.fr>
References: <132124429.8967161.1456497412247.JavaMail.zimbra@inria.fr>
 <1303056210.8967552.1456497461532.JavaMail.zimbra@inria.fr>
 <CAHk1PgHAgt1UuHuM4Mcr6aHVXeyd0n5E184zb8qLbBmG8DiN9A@mail.gmail.com>
 <1156096331.8970796.1456497902006.JavaMail.zimbra@inria.fr>
 <CAHk1PgEmfObZcN4OC0UcS6BnwcKcWDR54HJfa+xfMi+GFxeZAA@mail.gmail.com>
 <234513101.8979774.1456499407774.JavaMail.zimbra@inria.fr>
Message-ID: <CAHk1PgEjjr7HDZ=PHoa=OEcrroFAEMsayjWSM8GqY3Of7u134Q@mail.gmail.com>

For reference, the issue isn't uncompression, it's that the link you
provided is an HTML document generated by the web server to list the
files in that directory for humans and not machines :)

On Fri, Feb 26, 2016 at 9:10 AM, Cedric Doucet <cedric.doucet at inria.fr> wrote:
>
> Thank you very much Nicholas!
> For the moment, option B sounds better for me. :)
>
> I think it could be helpful to be able to disable the uncompression step of ExternalProject_Add,
> or to control it with a variable named UNCOMPRESSION_COMMAND or something similar.
>
> Cheers,
>
> C?dric
>
>
>
>
> ----- Mail original -----
>> De: "Nicholas Braden" <nicholas11braden at gmail.com>
>> ?: "Cedric Doucet" <cedric.doucet at inria.fr>
>> Cc: cmake at cmake.org
>> Envoy?: Vendredi 26 F?vrier 2016 15:56:02
>> Objet: Re: [CMake] Install from a source directory with ExternalProject
>>
>> Hmm, if it were available as an FTP share you may have been able to
>> use a command line program via DOWNLOAD_COMMAND, but in this case I
>> think you really only have two options:
>>
>> A. Write a small portable program compiled as part of your project,
>> with its task being to download that directory. Make sure the external
>> project DEPENDS on it and use it as the DOWNLOAD_COMMAND.
>>
>> B. If the directory in question does not change often, you can
>> probably get away with just maintaining several file(DOWNLOAD)
>> statements.
>>
>> Someone else may know better than me; there may be something I
>> overlooked. But for now, this is all I can think of.
>>
>> On Fri, Feb 26, 2016 at 8:45 AM, Cedric Doucet <cedric.doucet at inria.fr>
>> wrote:
>> >
>> > Hello Nicholas,
>> >
>> > thank you for your answer.
>> > Actually, it's not my own directory and I have no choice.
>> > I want to download source files from there :
>> > http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/c++/
>> > I know how to do it with FILE(DOWNLOAD ...) but I would like to know if
>> > there is a way to do it with ExternalProject_Add.
>> >
>> > C?dric
>> >
>> >
>> >
>> > ----- Mail original -----
>> >> De: "Nicholas Braden" <nicholas11braden at gmail.com>
>> >> ?: "Cedric Doucet" <cedric.doucet at inria.fr>
>> >> Cc: cmake at cmake.org
>> >> Envoy?: Vendredi 26 F?vrier 2016 15:40:26
>> >> Objet: Re: [CMake] Install from a source directory with ExternalProject
>> >>
>> >> I'm not sure how you would download a directory without it being in
>> >> some sort of archive. If you just want to use an existing directory,
>> >> use the SOURCE_DIR option instead.
>> >>
>> >> On Fri, Feb 26, 2016 at 8:37 AM, Cedric Doucet <cedric.doucet at inria.fr>
>> >> wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > I would like to know if it's possible to download and install an
>> >> > external
>> >> > project from a source directory instead of a tarball.
>> >> > I tried to do it with ExternalProject_Add function but it tries to
>> >> > uncompress source files and then fails.
>> >> >
>> >> > C?dric
>> >> >
>> >> > --
>> >> >
>> >> > Powered by www.kitware.com
>> >> >
>> >> > Please keep messages on-topic and check the CMake FAQ at:
>> >> > http://www.cmake.org/Wiki/CMake_FAQ
>> >> >
>> >> > Kitware offers various services to support the CMake community. For more
>> >> > information on each offering, please visit:
>> >> >
>> >> > CMake Support: http://cmake.org/cmake/help/support.html
>> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >> > CMake Training Courses: http://cmake.org/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 neil.n.carlson at gmail.com  Fri Feb 26 11:35:56 2016
From: neil.n.carlson at gmail.com (Neil Carlson)
Date: Fri, 26 Feb 2016 09:35:56 -0700
Subject: [CMake] Link library file name with version suffix
Message-ID: <CABkMBNJUbmbW66EVviZqt=ioXoHKTVigHs1kxMiFv1=WnhERKQ@mail.gmail.com>

cmake is generating a library link line that looks like:

/.../nagfor  -PIC -Wl,-shared -Wl,-Xlinker,-soname,-Xlinker,libnetcdff.so.6
-o libnetcdff.so.6.1.1 [...]   /.../libnetcdf.so.11.0.0  /.../libhdf5_hl.so
...

My issue is with the "11.0.0" suffix on the libnetcdf.so library.  This
particular compiler rejects that argument because it doesn't recognize the
".0" file suffix.

In this case there is a find_package(netCDF) that has found the installed
cmake configuration file netCDFConfig.cmake, which sets netCDF_LIBRARIES
to simply "netcdf" (not a full path).  Then there is a target_link_libraries
command for the target I'm building that references ${netCDF_LIBRARIES}.
So behind the scenes the simple "netcdf" is being turned into that full path
with version number appended.  Is this the intended behavior, or are the
netCDF developers not installing proper cmake configuration files for their
library?   I really don't want that version suffix there.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160226/6729d5b1/attachment.html>

From gjasny at googlemail.com  Fri Feb 26 14:57:06 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Fri, 26 Feb 2016 20:57:06 +0100
Subject: [CMake] check_cxx_compiler_flag fails silently for complex
 compiler paths
In-Reply-To: <CAMCxpGszHHpp_8XkwcYUZba9_c0ry6vdyUJOsSzwdLO-26B75Q@mail.gmail.com>
References: <CAMCxpGszHHpp_8XkwcYUZba9_c0ry6vdyUJOsSzwdLO-26B75Q@mail.gmail.com>
Message-ID: <56D0AE12.6020906@googlemail.com>

Hello,

On 26/02/16 00:00, Andrew Hundt wrote:
> I believe check_cxx_compiler_flags is failing due to a long/complicated
> compiler path.
> 
> Specifically my compiler is set to:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> 
> CMake version: 3.4.3
> 
> Full trace output in gist where you can see lines warning of regex failure:
> https://gist.github.com/ahundt/88ce65bcc3c268acdd94
> 
> 
> Here is the code snippet that fails:
> 
> include(CheckCXXCompilerFlag)
>> check_cxx_compiler_flag(-std=c++11 COMPILER_SUPPORTS_CXX11)
>> check_cxx_compiler_flag(-std=c++0x COMPILER_SUPPORTS_CXX0X)
>> message(STATUS <<<<<<<<COMPILER_SUPPORTS_CXX11:${COMPILER_SUPPORTS_CXX11})

The problem is not compiler path related but related to the additional
warnings that are enabled:

https://github.com/code-iai/iai_kinect2/blob/master/kinect2_calibration/CMakeLists.txt#L4

> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DBT_USE_DOUBLE_PRECISION -Wall")
> # Unused warnings
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wuninitialized -Winit-self -Wunused-function -Wunused-label -Wunused-variable -Wunused-but-set-variable -Wunused-but-set-parameter")
> # Additional warnings
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Warray-bounds -Wtype-limits -Wreturn-type -Wsequence-point -Wparentheses -Wmissing-braces -Wchar-subscripts -Wswitch -Wwrite-strings -Wenum-compare -Wempty-body -Wlogical-op")

Those cause clang to emit a warning about unknown warnings:

>  clang -c -DBT_USE_DOUBLE_PRECISION -Wall -Wuninitialized -Winit-self -Wunused-function -Wunused-label -Wunused-variable -Wunused-but-set-variable -Wunused-but-set-parameter -Warray-bounds -Wtype-limits -Wreturn-type -Wsequence-point -Wparentheses -Wmissing-braces -Wchar-subscripts -Wswitch -Wwrite-strings -Wenum-compare -Wempty-body foo.cpp
> warning: unknown warning option '-Wunused-but-set-variable'; did you mean
>       '-Wunused-const-variable'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wunused-but-set-parameter'; did you mean
>       '-Wunused-parameter'? [-Wunknown-warning-option]
> 2 warnings generated.

Those warnings are interpreted by check_cxx_compiler_flag as failure
(this is the regex you observed [1]) which leads to a negative setting
of the variable.

I see three possible solutions:

1) Move the check before touching the CMAKE_CXX_FLAGS.
2) Require a more modern CMake (3.3) and set
  CMAKE_CXX_STANDARD to 11
  CMAKE_CXX_STANDARD_REQUIRED to TRUE
3) Use modern CMake with target compile features:
  https://cmake.org/cmake/help/v3.3/manual/cmake-compile-features.7.html

Thanks,
Gregor

[1]
https://github.com/Kitware/CMake/blob/master/Modules/CMakeCheckCompilerFlagCommonPatterns.cmake#L25



From athundt at gmail.com  Fri Feb 26 15:01:57 2016
From: athundt at gmail.com (Andrew Hundt)
Date: Fri, 26 Feb 2016 15:01:57 -0500
Subject: [CMake] check_cxx_compiler_flag fails silently for complex
 compiler paths
In-Reply-To: <56D0AE12.6020906@googlemail.com>
References: <CAMCxpGszHHpp_8XkwcYUZba9_c0ry6vdyUJOsSzwdLO-26B75Q@mail.gmail.com>
 <56D0AE12.6020906@googlemail.com>
Message-ID: <CAMCxpGvLtGs3H-uhwxJ+y-TwD771mkFH3HO-Zra2y1sxZJvxsw@mail.gmail.com>

Thanks for the explanation of how to solve the problem, that?s very helpful
I?ll give it a try.

Shouldn?t the variable be set to something like ?FALSE? even if reporting
incorrectly when left blank? I appreciate the workaround but I believe
there is still a bug that would need to be addressed. Is this the right
place to report bugs or is it mainly for questions?

Thanks again!


Cheers!
Andrew Hundt

On Fri, Feb 26, 2016 at 2:57 PM, Gregor Jasny <gjasny at googlemail.com> wrote:

> Hello,
>
> On 26/02/16 00:00, Andrew Hundt wrote:
> > I believe check_cxx_compiler_flags is failing due to a long/complicated
> > compiler path.
> >
> > Specifically my compiler is set to:
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> >
> > CMake version: 3.4.3
> >
> > Full trace output in gist where you can see lines warning of regex
> failure:
> > https://gist.github.com/ahundt/88ce65bcc3c268acdd94
> >
> >
> > Here is the code snippet that fails:
> >
> > include(CheckCXXCompilerFlag)
> >> check_cxx_compiler_flag(-std=c++11 COMPILER_SUPPORTS_CXX11)
> >> check_cxx_compiler_flag(-std=c++0x COMPILER_SUPPORTS_CXX0X)
> >> message(STATUS
> <<<<<<<<COMPILER_SUPPORTS_CXX11:${COMPILER_SUPPORTS_CXX11})
>
> The problem is not compiler path related but related to the additional
> warnings that are enabled:
>
>
> https://github.com/code-iai/iai_kinect2/blob/master/kinect2_calibration/CMakeLists.txt#L4
>
> > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DBT_USE_DOUBLE_PRECISION -Wall")
> > # Unused warnings
> > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wuninitialized -Winit-self
> -Wunused-function -Wunused-label -Wunused-variable
> -Wunused-but-set-variable -Wunused-but-set-parameter")
> > # Additional warnings
> > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Warray-bounds -Wtype-limits
> -Wreturn-type -Wsequence-point -Wparentheses -Wmissing-braces
> -Wchar-subscripts -Wswitch -Wwrite-strings -Wenum-compare -Wempty-body
> -Wlogical-op")
>
> Those cause clang to emit a warning about unknown warnings:
>
> >  clang -c -DBT_USE_DOUBLE_PRECISION -Wall -Wuninitialized -Winit-self
> -Wunused-function -Wunused-label -Wunused-variable
> -Wunused-but-set-variable -Wunused-but-set-parameter -Warray-bounds
> -Wtype-limits -Wreturn-type -Wsequence-point -Wparentheses -Wmissing-braces
> -Wchar-subscripts -Wswitch -Wwrite-strings -Wenum-compare -Wempty-body
> foo.cpp
> > warning: unknown warning option '-Wunused-but-set-variable'; did you mean
> >       '-Wunused-const-variable'? [-Wunknown-warning-option]
> > warning: unknown warning option '-Wunused-but-set-parameter'; did you
> mean
> >       '-Wunused-parameter'? [-Wunknown-warning-option]
> > 2 warnings generated.
>
> Those warnings are interpreted by check_cxx_compiler_flag as failure
> (this is the regex you observed [1]) which leads to a negative setting
> of the variable.
>
> I see three possible solutions:
>
> 1) Move the check before touching the CMAKE_CXX_FLAGS.
> 2) Require a more modern CMake (3.3) and set
>   CMAKE_CXX_STANDARD to 11
>   CMAKE_CXX_STANDARD_REQUIRED to TRUE
> 3) Use modern CMake with target compile features:
>   https://cmake.org/cmake/help/v3.3/manual/cmake-compile-features.7.html
>
> Thanks,
> Gregor
>
> [1]
>
> https://github.com/Kitware/CMake/blob/master/Modules/CMakeCheckCompilerFlagCommonPatterns.cmake#L25
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160226/c1836434/attachment.html>

From pchakraborty at gmail.com  Fri Feb 26 15:42:17 2016
From: pchakraborty at gmail.com (P Chakraborty)
Date: Fri, 26 Feb 2016 14:42:17 -0600
Subject: [CMake] MSMPI (v6) and cmake 3.4.3
Message-ID: <CABgAZCBXQD+FkkRhZu8GGGviUXK9dbmn+jTn8iG7DhXTWj-6Sg@mail.gmail.com>

Hi,

I have a Fortran project that needs to link to Microsft's MPI libraries -
msmpi.lib and msmpifec.lib but the MPI_Fortran_LIBRARIES variable returned
by FindMPI listst just the first one. As a result, my CMakeLists.txt looks
like

cmake_minimum_required(VERSION 2.8)

project(ExampleMPI Fortran)

find_package(MPI REQUIRED)

include_directories(${MPI_Fortran_INCLUDE_PATH})
include_directories(${MPI_Fortran_INCLUDE_PATH}/x64) # mpifptr.h

add_executable(exmpi test.f90)
# MS MPI requires two libraries to be linked - msmpi.lib and msmpifec.lib
# Currently, cmake only returns the location of msmpi.lib in
# MPI_Fortran_LIBRARIES. So, we need to manually add msmpifec.lib
get_filename_component(mpi_lib_dir ${MPI_Fortran_LIBRARIES} DIRECTORY)
target_link_libraries(ssmpi ${MPI_Fortran_LIBRARIES}
${mpi_lib_dir}/msmpifec.lib)

Shouldn't the locations of both those libraries be included in
MPI_Fortran_LIBRARIES?

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

From tiagomacarios at gmail.com  Fri Feb 26 16:40:40 2016
From: tiagomacarios at gmail.com (Tiago Macarios)
Date: Fri, 26 Feb 2016 13:40:40 -0800
Subject: [CMake] cpack generator variable
Message-ID: <CAKLVFYEiTzS1V-0xipHUXYticaY_s_gUNQYYErsfB4ch5vbEjQ@mail.gmail.com>

Hi All,

I have a cmake project which one of the install targets is a collection of
files. This files change depending on the configuration (Release,
Debug...). I would like to be able to install the files like so:

install(DIRECTORY $<TARGET_FILE_DIR:tgt>
    DESTINATION bin
    COMPONENT files)

>From the docs I see that cmake does not support that. Generator variables
do not apply to DIRECTORY. So I was wondering if there is a way to either
save the directory information somewhere and pass it to cpack afterwards.

So I guess the question is how to pass a variable from cmake to cpack?

Best,
Tiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160226/e6a7ad6f/attachment.html>

From doublef.mobile at gmail.com  Sat Feb 27 01:57:16 2016
From: doublef.mobile at gmail.com (Sergey Zakharchenko)
Date: Sat, 27 Feb 2016 09:57:16 +0300
Subject: [CMake] file(SHA1) vs string(SHA1) consistency
In-Reply-To: <56CF169E.8040801@yahoo.com>
References: <56CF169E.8040801@yahoo.com>
Message-ID: <CADYCxoMqv__SuDGg5upg4LeH3i_u45d4F2F30eAvbctADebenQ@mail.gmail.com>

Hello,

2016-02-25 17:58 GMT+03:00 Ruslan Baratov via CMake <cmake at cmake.org>:
> * since CMake is a cross-platform tool I think it make sense that command
> `file(WRITE "..." "a\nb")` produce identical files on all platforms

Seconded; READ and WRITE could at least have a BINARY flag that does
it so that I don't have to reimplement 'cat' for each platform...

Best regards,

-- 
DoubleF

From kristianonline28 at gmail.com  Sun Feb 28 15:57:51 2016
From: kristianonline28 at gmail.com (Kristian)
Date: Sun, 28 Feb 2016 21:57:51 +0100
Subject: [CMake] A function and its arguments
Message-ID: <CAO5HUhNyPH40FoYR-bLeyJEM4dmet8+OrY2eiPJvPt-HCB0ELQ@mail.gmail.com>

Hey,

I have a question. I have read the article about functions:
https://cmake.org/cmake/help/v3.0/command/function.html

I tried to write myself a very simple function (nothing special)

************************************

function(test_me add1 add2)
        message("test_me")
        message(" -> " ${add1})
        message(" -> " ${add2})
        message(" -> Number of arguments: " ${ARGC})
        message(" -> All arguments: " ${ARGV})
        message(" -> 0. argument: " ${ARGV0})
        message(" -> 1. argument: " ${ARGV1})
        message(" -> 2. argument: " ${ARGV2})
        message(" -> Unexpected arguments: " ${ARGN})
endfunction(test_me)

************************************

But when calling the function with

************************************
test_me("1" "2" "3")
************************************

or

************************************
test_me(1 2 3)
************************************

Then I get this output:

************************************
test_me
 -> 1
 -> 2
 -> Number of arguments: 3
 -> All arguments: 123
 -> 0. argument: 1
 -> 1. argument: 2
 -> 2. argument: 3
 -> Unexpected arguments: 3

************************************

I would expect, that the line "All arguments" would look like "All
arguments: 1 2 3", and not "All arguments: 123".

What is the thought behind this behaviour?

From nilsgladitz at gmail.com  Sun Feb 28 16:12:32 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Sun, 28 Feb 2016 22:12:32 +0100
Subject: [CMake] A function and its arguments
In-Reply-To: <CAO5HUhNyPH40FoYR-bLeyJEM4dmet8+OrY2eiPJvPt-HCB0ELQ@mail.gmail.com>
References: <CAO5HUhNyPH40FoYR-bLeyJEM4dmet8+OrY2eiPJvPt-HCB0ELQ@mail.gmail.com>
Message-ID: <56D362C0.50902@gmail.com>

On 28.02.2016 21:57, Kristian wrote:
> [...]
>
> ************************************
> test_me(1 2 3)
> ************************************
>
> Then I get this output:
>
> ************************************
> test_me
>   -> 1
>   -> 2
>   -> Number of arguments: 3
>   -> All arguments: 123
>   -> 0. argument: 1
>   -> 1. argument: 2
>   -> 2. argument: 3
>   -> Unexpected arguments: 3
>
> ************************************
>
> I would expect, that the line "All arguments" would look like "All
> arguments: 1 2 3", and not "All arguments: 123".
>
> What is the thought behind this behaviour?

This is due to how you call message() which concatenates its arguments.

Instead try e.g.
     message(" -> All arguments: ${ARGV}")

Which should output " -> All arguments: 1;2;3" (CMake's internal list 
separator is semicolon).

Nils


From kristianonline28 at gmail.com  Sun Feb 28 17:17:56 2016
From: kristianonline28 at gmail.com (Kristian)
Date: Sun, 28 Feb 2016 23:17:56 +0100
Subject: [CMake] A function and its arguments
In-Reply-To: <56D362C0.50902@gmail.com>
References: <CAO5HUhNyPH40FoYR-bLeyJEM4dmet8+OrY2eiPJvPt-HCB0ELQ@mail.gmail.com>
 <56D362C0.50902@gmail.com>
Message-ID: <CAO5HUhNfuTv6e0nMevVxz0KxLDPExdYwHPB7hFqpukB+e-x3hw@mail.gmail.com>

You were right. Thank you!

2016-02-28 22:12 GMT+01:00 Nils Gladitz <nilsgladitz at gmail.com>:
> On 28.02.2016 21:57, Kristian wrote:
>>
>> [...]
>>
>> ************************************
>> test_me(1 2 3)
>> ************************************
>>
>> Then I get this output:
>>
>> ************************************
>> test_me
>>   -> 1
>>   -> 2
>>   -> Number of arguments: 3
>>   -> All arguments: 123
>>   -> 0. argument: 1
>>   -> 1. argument: 2
>>   -> 2. argument: 3
>>   -> Unexpected arguments: 3
>>
>> ************************************
>>
>> I would expect, that the line "All arguments" would look like "All
>> arguments: 1 2 3", and not "All arguments: 123".
>>
>> What is the thought behind this behaviour?
>
>
> This is due to how you call message() which concatenates its arguments.
>
> Instead try e.g.
>     message(" -> All arguments: ${ARGV}")
>
> Which should output " -> All arguments: 1;2;3" (CMake's internal list
> separator is semicolon).
>
> Nils
>

From petr.kmoch at gmail.com  Mon Feb 29 02:31:20 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 29 Feb 2016 08:31:20 +0100
Subject: [CMake] cpack generator variable
In-Reply-To: <CAKLVFYEiTzS1V-0xipHUXYticaY_s_gUNQYYErsfB4ch5vbEjQ@mail.gmail.com>
References: <CAKLVFYEiTzS1V-0xipHUXYticaY_s_gUNQYYErsfB4ch5vbEjQ@mail.gmail.com>
Message-ID: <CAKohaZe6Ej6Jco4BPEY5Q-eZzuekrGUbkBZYAP+Gpdvr=VmQbg@mail.gmail.com>

Hi Tiago.

If you happen to know the directory for each configuration at CMake
configure time, you could do this:

install(DIRECTORY path/to/Debug/dir
  DESTINATION bin
  CONFIGURATIONS Debug
  COMPONENT files
)

install(DIRECTORY path/to/Release/dir
  DESTINATION bin
  CONFIGURATIONS Release
  COMPONENT files
)

# ...etc

Petr


On Fri, Feb 26, 2016 at 10:40 PM, Tiago Macarios <tiagomacarios at gmail.com>
wrote:

> Hi All,
>
> I have a cmake project which one of the install targets is a collection of
> files. This files change depending on the configuration (Release,
> Debug...). I would like to be able to install the files like so:
>
> install(DIRECTORY $<TARGET_FILE_DIR:tgt>
>     DESTINATION bin
>     COMPONENT files)
>
> From the docs I see that cmake does not support that. Generator variables
> do not apply to DIRECTORY. So I was wondering if there is a way to either
> save the directory information somewhere and pass it to cpack afterwards.
>
> So I guess the question is how to pass a variable from cmake to cpack?
>
> Best,
> Tiago
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160229/6491e33c/attachment.html>

From jan.hegewald at awi.de  Mon Feb 29 09:11:31 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Mon, 29 Feb 2016 15:11:31 +0100
Subject: [CMake] empty list evaluates to false?
Message-ID: <306957BB-574B-41A9-941D-047ED7324673@awi.de>

Hi cmakers,
can I create an empty list which evaluates to true? The way I tried they evaluate to false:

set(BLAS_LIBRARIES "") # trying to create an empty list
if(BLAS_LIBRARIES)
	# not called
endif()

Cheers,
Jan

From petr.kmoch at gmail.com  Mon Feb 29 09:27:01 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 29 Feb 2016 15:27:01 +0100
Subject: [CMake] empty list evaluates to false?
In-Reply-To: <306957BB-574B-41A9-941D-047ED7324673@awi.de>
References: <306957BB-574B-41A9-941D-047ED7324673@awi.de>
Message-ID: <CAKohaZdRW24wwS7JgbJFfeSMciGdBid5O5o43nRraKSi=VLKaQ@mail.gmail.com>

Hi Jan.

No, that's not possible. Internally, CMake does not differentiate between
"list" and "string" in any way. An empty list and an empty string are
indistinguishable. A non-empty string containing N semi-colons is
indistinguishable from a list containing N+1 elements.

Quantum mechanics has wave-particle dualism, CMake has string-list dualism
:-)

Petr

On Mon, Feb 29, 2016 at 3:11 PM, ? Jan Hegewald <jan.hegewald at awi.de>
wrote:

> Hi cmakers,
> can I create an empty list which evaluates to true? The way I tried they
> evaluate to false:
>
> set(BLAS_LIBRARIES "") # trying to create an empty list
> if(BLAS_LIBRARIES)
>         # not called
> endif()
>
> Cheers,
> Jan
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160229/b598e36f/attachment.html>

From jan.hegewald at awi.de  Mon Feb 29 09:34:20 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Mon, 29 Feb 2016 15:34:20 +0100
Subject: [CMake] empty list evaluates to false?
In-Reply-To: <CAKohaZdRW24wwS7JgbJFfeSMciGdBid5O5o43nRraKSi=VLKaQ@mail.gmail.com>
References: <306957BB-574B-41A9-941D-047ED7324673@awi.de>
 <CAKohaZdRW24wwS7JgbJFfeSMciGdBid5O5o43nRraKSi=VLKaQ@mail.gmail.com>
Message-ID: <0138ABF2-9DAE-45CC-B539-5DA6DB9D10EC@awi.de>

Hi Petr,

> On 29.02.2016, at 15:27, Petr Kmoch <petr.kmoch at gmail.com> wrote:
> 
> Hi Jan.
> 
> No, that's not possible. Internally, CMake does not differentiate between "list" and "string" in any way.

OK, thanks for the clarification.

Best,
Jan

From patrick.boettcher at posteo.de  Mon Feb 29 09:34:53 2016
From: patrick.boettcher at posteo.de (Patrick Boettcher)
Date: Mon, 29 Feb 2016 15:34:53 +0100
Subject: [CMake] Good practice: using INTERFACE-libraries in FindABC.cmake?
Message-ID: <20160229153453.35850c1b@lappi3.vsora>

Hi list,

I came across the INTERFACE-type of libraries when writing a
FindModule.cmake-file for custom libraries installed by my
project.

Here is what I'm doing after having found the libraries and the
determined the paths: LIB1 is the library and LIB1_INCLUDE_DIRS its
include-dirs:

  add_library(name INTERFACE)

  target_link_libraries(name INTERFACE ${LIB1})

  if(FFTW3_FOUND)
  	target_include_directories(name INTERFACE
  		{$FFTW3_INCLUDE_DIRS})
  	target_link_libraries(name INTERFACE ${FFTW3_LIBRARIES} )
  endif()

  target_include_directories(name INTERFACE ${LIB1_INCLUDE_DIRS})

  # need c++11 compile options for if-name
  set_property(TARGET name PROPERTY
		INTERFACE_COMPILE_FEATURES cxx_range_for)

This makes that in the CMakeLists.txt which includes my package-file a
user needing libname for his executable does:

  add_executable(main main.cpp)
  target_link_libraries(main name)

This will 

1) set C++11 flags for compilation
2) set the right include-pathes
3) link with the right libraries as per my order

Awesome. But is this a good practice? Are there any pitfalls?

Thank you for your help in advance.

best regards,
--
Patrick.

From michael.stuermer at schaeffler.com  Mon Feb 29 09:40:17 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Mon, 29 Feb 2016 14:40:17 +0000
Subject: [CMake] empty list evaluates to false?
In-Reply-To: <306957BB-574B-41A9-941D-047ED7324673@awi.de>
References: <306957BB-574B-41A9-941D-047ED7324673@awi.de>
Message-ID: <005de3d7bbda405fbfb8a5714f86e3b4@DE013666.schaeffler.com>

You can check for existence of a variable and you can invert the result of the evaluation:

if(DEFINED <varname>)
	# called if variable exists, never mind if it's empty or not
endif()

if(NOT DEFINED <varname>)
	# called if variable is not defined
endif()

if(NOT <varname>)
	# called if variable is empty/false/off
endif()

I think it should be possible to get the expected behavior this way...

best regards,
Michael

> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of ?? Jan
> Hegewald
> Sent: Monday, February 29, 2016 3:12 PM
> To: cmake at cmake.org
> Subject: [CMake] empty list evaluates to false?
> 
> Hi cmakers,
> can I create an empty list which evaluates to true? The way I tried they
> evaluate to false:
> 
> set(BLAS_LIBRARIES "") # trying to create an empty list
> if(BLAS_LIBRARIES)
> 	# not called
> endif()
> 
> Cheers,
> Jan
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 nilsgladitz at gmail.com  Mon Feb 29 09:43:11 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Mon, 29 Feb 2016 15:43:11 +0100
Subject: [CMake] Good practice: using INTERFACE-libraries in
 FindABC.cmake?
In-Reply-To: <20160229153453.35850c1b@lappi3.vsora>
References: <20160229153453.35850c1b@lappi3.vsora>
Message-ID: <56D458FF.3090406@gmail.com>

On 02/29/2016 03:34 PM, Patrick Boettcher wrote:
> Hi list,
>
> I came across the INTERFACE-type of libraries when writing a
> FindModule.cmake-file for custom libraries installed by my
> project.
>
> Here is what I'm doing after having found the libraries and the
> determined the paths: LIB1 is the library and LIB1_INCLUDE_DIRS its
> include-dirs:
>
>    add_library(name INTERFACE)
>
>    target_link_libraries(name INTERFACE ${LIB1})
>
>    if(FFTW3_FOUND)
>    	target_include_directories(name INTERFACE
>    		{$FFTW3_INCLUDE_DIRS})
>    	target_link_libraries(name INTERFACE ${FFTW3_LIBRARIES} )
>    endif()
>
>    target_include_directories(name INTERFACE ${LIB1_INCLUDE_DIRS})
>
>    # need c++11 compile options for if-name
>    set_property(TARGET name PROPERTY
> 		INTERFACE_COMPILE_FEATURES cxx_range_for)
>
> This makes that in the CMakeLists.txt which includes my package-file a
> user needing libname for his executable does:
>
>    add_executable(main main.cpp)
>    target_link_libraries(main name)
>
> This will
>
> 1) set C++11 flags for compilation
> 2) set the right include-pathes
> 3) link with the right libraries as per my order
>
> Awesome. But is this a good practice? Are there any pitfalls?

This sounds like a use case for IMPORTED rather than INTERFACE libraries.
INTERFACE libraries can be IMPORTED as well but are not intended for 
pre-build linkable libraries (which you seem to have).

This documents how to create find modules with IMPORTED targets:
https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#find-modules

Nils

From lectem at gmail.com  Mon Feb 29 10:06:15 2016
From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=)
Date: Mon, 29 Feb 2016 15:06:15 +0000
Subject: [CMake] Good practice: using INTERFACE-libraries in
	FindABC.cmake?
In-Reply-To: <56D458FF.3090406@gmail.com>
References: <20160229153453.35850c1b@lappi3.vsora> <56D458FF.3090406@gmail.com>
Message-ID: <CACzuyg6A63B0CNyQPEjVnVSHu+YzsTdYwYNeH_gFwdshXtrrwQ@mail.gmail.com>

Speaking of imported targets, I'm wondering why alias imported targets
aren't added to all default FindXXX.cmake scripts. This would help provide
better examples, and have the community use better cmakelists.txt and
hopefully reduce the bad usages of include_directories and such

Le lun. 29 f?vr. 2016 09:43, Nils Gladitz <nilsgladitz at gmail.com> a ?crit :

> On 02/29/2016 03:34 PM, Patrick Boettcher wrote:
> > Hi list,
> >
> > I came across the INTERFACE-type of libraries when writing a
> > FindModule.cmake-file for custom libraries installed by my
> > project.
> >
> > Here is what I'm doing after having found the libraries and the
> > determined the paths: LIB1 is the library and LIB1_INCLUDE_DIRS its
> > include-dirs:
> >
> >    add_library(name INTERFACE)
> >
> >    target_link_libraries(name INTERFACE ${LIB1})
> >
> >    if(FFTW3_FOUND)
> >       target_include_directories(name INTERFACE
> >               {$FFTW3_INCLUDE_DIRS})
> >       target_link_libraries(name INTERFACE ${FFTW3_LIBRARIES} )
> >    endif()
> >
> >    target_include_directories(name INTERFACE ${LIB1_INCLUDE_DIRS})
> >
> >    # need c++11 compile options for if-name
> >    set_property(TARGET name PROPERTY
> >               INTERFACE_COMPILE_FEATURES cxx_range_for)
> >
> > This makes that in the CMakeLists.txt which includes my package-file a
> > user needing libname for his executable does:
> >
> >    add_executable(main main.cpp)
> >    target_link_libraries(main name)
> >
> > This will
> >
> > 1) set C++11 flags for compilation
> > 2) set the right include-pathes
> > 3) link with the right libraries as per my order
> >
> > Awesome. But is this a good practice? Are there any pitfalls?
>
> This sounds like a use case for IMPORTED rather than INTERFACE libraries.
> INTERFACE libraries can be IMPORTED as well but are not intended for
> pre-build linkable libraries (which you seem to have).
>
> This documents how to create find modules with IMPORTED targets:
>
> https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#find-modules
>
> Nils
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160229/b02cd1c0/attachment.html>

From nilsgladitz at gmail.com  Mon Feb 29 10:15:02 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Mon, 29 Feb 2016 16:15:02 +0100
Subject: [CMake] Good practice: using INTERFACE-libraries in
 FindABC.cmake?
In-Reply-To: <CACzuyg6A63B0CNyQPEjVnVSHu+YzsTdYwYNeH_gFwdshXtrrwQ@mail.gmail.com>
References: <20160229153453.35850c1b@lappi3.vsora> <56D458FF.3090406@gmail.com>
 <CACzuyg6A63B0CNyQPEjVnVSHu+YzsTdYwYNeH_gFwdshXtrrwQ@mail.gmail.com>
Message-ID: <56D46076.5080408@gmail.com>

On 02/29/2016 04:06 PM, Cl?ment Gregoire wrote:
>
> Speaking of imported targets, I'm wondering why alias imported targets 
> aren't added to all default FindXXX.cmake scripts. This would help 
> provide better examples, and have the community use better 
> cmakelists.txt and hopefully reduce the bad usages of 
> include_directories and such
>

I assume you don't mean alias as in "ALIAS" targets ...

Many of the Find*.cmake modules included with CMake do provide imported 
targets now.
e.g. according to grep:
     FindIce.cmake
     FindPNG.cmake
     FindGLUT.cmake
     FindXalanC.cmake
     FindOpenSSL.cmake
     FindThreads.cmake
     FindQt4.cmake
     FindXercesC.cmake
     FindTIFF.cmake
     FindGTK2.cmake
     FindZLIB.cmake
     FindGTest.cmake
     FindGSL.cmake
     FindBoost.cmake
     FindGLEW.cmake

For the rest there probably is just a lack of maintainers ... patches 
are probably welcome.

Nils

From jan.hegewald at awi.de  Mon Feb 29 10:24:00 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Mon, 29 Feb 2016 16:24:00 +0100
Subject: [CMake] COMPILER_LOADED vs ENABLED_LANGUAGES
Message-ID: <95086A25-F9A5-4C59-83B0-1F56810E9682@awi.de>

Hi all,
I stumbled upon a problem where a find module did tests via "check_function_exists". It first checks if C is enabled via the ENABLED_LANGUAGES.
Now this does not seem to be reliable, as the project language is not C, but C is enables by a project included via add_subdirectory. Now ENABLED_LANGUAGES does contain C, but CMAKE_C_COMPILER_LOADED is false. This leads to an error from when calling check_function_exists is invoked.^1

Is this intended behaviour?
When to use ENABLED_LANGUAGES and when to use CMAKE_<lang>_COMPILER_LOADED?

Best,
Jan


1) CMake.app/Contents/share/cmake-3.4/Modules/CheckFunctionExists.cmake:67

From steveire at gmail.com  Mon Feb 29 15:20:59 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 29 Feb 2016 21:20:59 +0100
Subject: [CMake] Good practice: using INTERFACE-libraries in
	FindABC.cmake?
References: <20160229153453.35850c1b@lappi3.vsora>
Message-ID: <nb297c$3qc$1@ger.gmane.org>

Patrick Boettcher wrote:

> I came across the INTERFACE-type of libraries when writing a
> FindModule.cmake-file for custom libraries installed by my
> project.

You don't provide FindModules for your CMake-built libraries. 

See

 https://cmake.org/cmake/help/v3.4/manual/cmake-packages.7.html

Thanks,

Steve.