From jsvanbethlehem at gmail.com  Fri Jan  1 05:00:23 2016
From: jsvanbethlehem at gmail.com (Jakob van Bethlehem)
Date: Fri, 1 Jan 2016 11:00:23 +0100
Subject: [CMake] Cannot set FOLDER property to an interface
	(header-only) target
In-Reply-To: <CAOU91OMf8+0wZAwS-RPEgst+SXq=B02nDwT_DoqEbp7gBXscFg@mail.gmail.com>
References: <CAOU91OMf8+0wZAwS-RPEgst+SXq=B02nDwT_DoqEbp7gBXscFg@mail.gmail.com>
Message-ID: <23B5E737-711F-4AC8-AC85-96A678D423A4@gmail.com>

Hej Jo?l,

The command you?re looking for is ?source_group?, see https://cmake.org/cmake/help/v3.0/command/source_group.html <https://cmake.org/cmake/help/v3.0/command/source_group.html>

Sincerely,
Jakob


> On 30 Dec 2015, at 20:52, Klaim - Jo?l Lamotte <mjklaim at gmail.com> wrote:
> 
> The following CMake script:
> 
>     cmake_minimum_required(VERSION 3.4)
>     
>     add_library( mylib INTERFACE )
>     set_property( TARGET mylib PROPERTY FOLDER /some/dir )
> 
> 
> Will trigger this error on configuration:
> 
>     CMake Error at CMakeLists.txt:4 (set_property):
>       INTERFACE_LIBRARY targets may only have whitelisted properties.  The
>       property "FOLDER" is not allowed.
> 
> 
> This prevent any interface library to be organized in Visual Studio virtual folders.
> Unfortunately it also mean that header-only targets can't be organized.
> 
> I have no idea how this should be solved. Should the property just be white-listed?
> Or should a better have a another specific library mode for header-only targets?
> 
> Is there any workaround?
> 
> Jo?l Lamotte
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160101/9b4bd28d/attachment.html>

From gjasny at googlemail.com  Fri Jan  1 13:14:09 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Fri, 1 Jan 2016 19:14:09 +0100
Subject: [CMake] Add support for cross compiling to VxWorks
In-Reply-To: <6C486AB80682E24095E3E77A408D68F2F60DB12B@ALA-MBA.corp.ad.wrs.com>
References: <6C486AB80682E24095E3E77A408D68F2F60DB12B@ALA-MBA.corp.ad.wrs.com>
Message-ID: <5686C1F1.8030301@googlemail.com>

Hello,

please have a look at some other toolchain file like the BlackBerry one:
> https://github.com/blackberry/OGRE/blob/master/src/CMake/toolchain/blackberry.toolchain.cmake

On 30/12/15 21:38, Kuhl, Brian wrote:
> I'm trying to add support for VxWorks to CMake. 
> My current dilemma is that the Compiler ID link test is failing because my library link path isn't being used, and libraries aren't being found. 
> I've set the library path in all the obvious places ( or so I thought,) what setting am I missing?

I guess you should set these variables:

> # Find the Target environment 
> set( CMAKE_FIND_ROOT_PATH "${CMAKE_SOURCE_DIR}" "${BLACKBERRY_TARGET_ROOT}"  "${CMAKE_INSTALL_PREFIX}" "${CMAKE_INSTALL_PREFIX}/share" )

> # Search for libraries and includes in the ndk toolchain
> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )

Hope that helps,
Gregor

From brian.kuhl at windriver.com  Fri Jan  1 23:14:24 2016
From: brian.kuhl at windriver.com (Kuhl, Brian)
Date: Sat, 2 Jan 2016 04:14:24 +0000
Subject: [CMake] Add support for cross compiling to VxWorks
In-Reply-To: <5686C1F1.8030301@googlemail.com>
References: <6C486AB80682E24095E3E77A408D68F2F60DB12B@ALA-MBA.corp.ad.wrs.com>
 <5686C1F1.8030301@googlemail.com>
Message-ID: <6C486AB80682E24095E3E77A408D68F2F60DBB15@ALA-MBA.corp.ad.wrs.com>

Adding the library path to CMAKE_FIND_ROOT_PATH  did not help :(

SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/root C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/libcommon  C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/libcommon/PIC )


-----Original Message-----
From: Gregor Jasny [mailto:gjasny at googlemail.com] 
Sent: January-01-16 10:14 AM
To: Kuhl, Brian; cmake at cmake.org
Subject: Re: [CMake] Add support for cross compiling to VxWorks

Hello,

please have a look at some other toolchain file like the BlackBerry one:
> https://github.com/blackberry/OGRE/blob/master/src/CMake/toolchain/blackberry.toolchain.cmake

On 30/12/15 21:38, Kuhl, Brian wrote:
> I'm trying to add support for VxWorks to CMake. 
> My current dilemma is that the Compiler ID link test is failing because my library link path isn't being used, and libraries aren't being found. 
> I've set the library path in all the obvious places ( or so I thought,) what setting am I missing?

I guess you should set these variables:

> # Find the Target environment 
> set( CMAKE_FIND_ROOT_PATH "${CMAKE_SOURCE_DIR}" "${BLACKBERRY_TARGET_ROOT}"  "${CMAKE_INSTALL_PREFIX}" "${CMAKE_INSTALL_PREFIX}/share" )

> # Search for libraries and includes in the ndk toolchain
> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )

Hope that helps,
Gregor

From mjklaim at gmail.com  Sat Jan  2 07:10:02 2016
From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=)
Date: Sat, 2 Jan 2016 13:10:02 +0100
Subject: [CMake] Cannot set FOLDER property to an interface
	(header-only) target
In-Reply-To: <5685557A.1090600@gmail.com>
References: <CAOU91OMf8+0wZAwS-RPEgst+SXq=B02nDwT_DoqEbp7gBXscFg@mail.gmail.com>
 <CAKME8fFcuOrNqJHSBkWL1FWjc1naW_6ROuiOQdieGATezw=wtg@mail.gmail.com>
 <5685557A.1090600@gmail.com>
Message-ID: <CAOU91OPqmpyK+kz91xuhzakrfxfOdmr8Sw1_+1+n2DseRb+j1A@mail.gmail.com>

On 31 December 2015 at 17:19, Nils Gladitz <nilsgladitz at gmail.com> wrote:

> On 31.12.2015 14:19, David Cole via CMake wrote:
>
>> I can't think of a reason why we would not whitelist the FOLDER
>> property... Unless somebody else chimes in with one, perhaps you could
>> submit a proposed patch to whitelist it?
>>
>
> As far as I remember INTERFACE libraries don't generate visual studio
> projects.
> Without generated projects there is nothing to be organized by the FOLDER
> property.
>
> Nils
>


Indeed, that's another issue I just discovered and it's a problem too for
me. I was looking for a solution for header-only libraries
so that I can see them in my solution (and other convenience). Without
being exposed in Visual Studio, interface
targets are not very useful (except for configuration composition I guess).
Looks like there is not many good solutions for header-only libraries to be
visible in the VS solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160102/a986e7ed/attachment.html>

From mjklaim at gmail.com  Sat Jan  2 07:12:18 2016
From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=)
Date: Sat, 2 Jan 2016 13:12:18 +0100
Subject: [CMake] Cannot set FOLDER property to an interface
	(header-only) target
In-Reply-To: <23B5E737-711F-4AC8-AC85-96A678D423A4@gmail.com>
References: <CAOU91OMf8+0wZAwS-RPEgst+SXq=B02nDwT_DoqEbp7gBXscFg@mail.gmail.com>
 <23B5E737-711F-4AC8-AC85-96A678D423A4@gmail.com>
Message-ID: <CAOU91OPTwN6znU-odvZ8bUWWmySGDTekg7YOhsjCc5vUACJiJg@mail.gmail.com>

On 1 January 2016 at 11:00, Jakob van Bethlehem <jsvanbethlehem at gmail.com>
wrote:

> Hej Jo?l,
>
> The command you?re looking for is ?source_group?, see
> https://cmake.org/cmake/help/v3.0/command/source_group.html
>
>
I use this already but it works only with source files, not with targets.
With targets you need to set the FOLDER property.


> Sincerely,
> Jakob
>
>
> On 30 Dec 2015, at 20:52, Klaim - Jo?l Lamotte <mjklaim at gmail.com> wrote:
>
> The following CMake script:
>
>     cmake_minimum_required(VERSION 3.4)
>
>     add_library( mylib INTERFACE )
>     set_property( TARGET mylib PROPERTY FOLDER /some/dir )
>
>
> Will trigger this error on configuration:
>
>     CMake Error at CMakeLists.txt:4 (set_property):
>       INTERFACE_LIBRARY targets may only have whitelisted properties.  The
>       property "FOLDER" is not allowed.
>
>
> This prevent any interface library to be organized in Visual Studio
> virtual folders.
> Unfortunately it also mean that header-only targets can't be organized.
>
> I have no idea how this should be solved. Should the property just be
> white-listed?
> Or should a better have a another specific library mode for header-only
> targets?
>
> Is there any workaround?
>
> Jo?l Lamotte
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160102/b9eac585/attachment.html>

From gurenchan at gmail.com  Sat Jan  2 16:23:27 2016
From: gurenchan at gmail.com (Owen Hogarth II)
Date: Sun, 3 Jan 2016 05:23:27 +0800
Subject: [CMake] debugging symbols in project
Message-ID: <CALM2mEk32gHsPBdjs3i5ZauDiLnP3q7aVBXJ84Hj_eACkZazKQ@mail.gmail.com>

I have a simple cmake project that I am trying to test with gdb but I am
having trouble. GDB is reporting now debugging symbols.

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(core_e)


SET(CMAKE_MACOSX_RPATH 1)

set(CMAKE_C_FLAGS "-g -Wall")

FIND_PACKAGE(OpenGL REQUIRED)

SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/core_e.h)
SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/core_e.c)
SET(TARGET_LIBS glfw ${OPENGL_LIBRARIES})
SET(TARGET_INC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/headers" )

ADD_LIBRARY(core_e SHARED ${SRC_FILES} ${HEADER_FILES})
TARGET_LINK_LIBRARIES(core_en\ ${TARGET_LIBS})
TARGET_INCLUDE_DIRECTORIES(core_e PUBLIC ${TARGET_INC_DIR})
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160103/306e60df/attachment.html>

From rainer.poisel at gmail.com  Sat Jan  2 16:28:14 2016
From: rainer.poisel at gmail.com (Rainer Poisel)
Date: Sat, 2 Jan 2016 21:28:14 +0000
Subject: [CMake] debugging symbols in project
In-Reply-To: <CALM2mEk32gHsPBdjs3i5ZauDiLnP3q7aVBXJ84Hj_eACkZazKQ@mail.gmail.com>
References: <CALM2mEk32gHsPBdjs3i5ZauDiLnP3q7aVBXJ84Hj_eACkZazKQ@mail.gmail.com>
Message-ID: <CADpFnzzK5=MpfzgW0uPxDdruFXZi6haOFG6akeBRZMkBps9tLA@mail.gmail.com>

Owen,

sorry, I replied directly to you instead of replying to this mailing list.

Have you tried passing "-DCMAKE_BUILD_TYPE=Debug" to CMake when invoking it?

It is also possible to set this option when using "cmake-gui".

Many regards,
  Rainer


On Sat, Jan 2, 2016 at 9:23 PM, Owen Hogarth II <gurenchan at gmail.com> wrote:
> I have a simple cmake project that I am trying to test with gdb but I am
> having trouble. GDB is reporting now debugging symbols.
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(core_e)
>
>
> SET(CMAKE_MACOSX_RPATH 1)
>
> set(CMAKE_C_FLAGS "-g -Wall")
>
> FIND_PACKAGE(OpenGL REQUIRED)
>
> SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/core_e.h)
> SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/core_e.c)
> SET(TARGET_LIBS glfw ${OPENGL_LIBRARIES})
> SET(TARGET_INC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/headers" )
>
> ADD_LIBRARY(core_e SHARED ${SRC_FILES} ${HEADER_FILES})
> TARGET_LINK_LIBRARIES(core_en\ ${TARGET_LIBS})
> TARGET_INCLUDE_DIRECTORIES(core_e PUBLIC ${TARGET_INC_DIR})
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 gurenchan at gmail.com  Sat Jan  2 16:36:43 2016
From: gurenchan at gmail.com (Owen Hogarth II)
Date: Sun, 3 Jan 2016 05:36:43 +0800
Subject: [CMake] debugging symbols in project
In-Reply-To: <CADpFnzzK5=MpfzgW0uPxDdruFXZi6haOFG6akeBRZMkBps9tLA@mail.gmail.com>
References: <CALM2mEk32gHsPBdjs3i5ZauDiLnP3q7aVBXJ84Hj_eACkZazKQ@mail.gmail.com>
 <CADpFnzzK5=MpfzgW0uPxDdruFXZi6haOFG6akeBRZMkBps9tLA@mail.gmail.com>
Message-ID: <CALM2mEmjB-nZ7GE=DxmR8CXhssuty5i8KJxs-fVPKfFKnbyKfA@mail.gmail.com>

wow, that was a silly mistake, my builds are automated and I removed that
line somewhere along the line.

Thanks!

On Sun, Jan 3, 2016 at 5:28 AM, Rainer Poisel <rainer.poisel at gmail.com>
wrote:

> Owen,
>
> sorry, I replied directly to you instead of replying to this mailing list.
>
> Have you tried passing "-DCMAKE_BUILD_TYPE=Debug" to CMake when invoking
> it?
>
> It is also possible to set this option when using "cmake-gui".
>
> Many regards,
>   Rainer
>
>
> On Sat, Jan 2, 2016 at 9:23 PM, Owen Hogarth II <gurenchan at gmail.com>
> wrote:
> > I have a simple cmake project that I am trying to test with gdb but I am
> > having trouble. GDB is reporting now debugging symbols.
> >
> > CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> > PROJECT(core_e)
> >
> >
> > SET(CMAKE_MACOSX_RPATH 1)
> >
> > set(CMAKE_C_FLAGS "-g -Wall")
> >
> > FIND_PACKAGE(OpenGL REQUIRED)
> >
> > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/core_e.h)
> > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/core_e.c)
> > SET(TARGET_LIBS glfw ${OPENGL_LIBRARIES})
> > SET(TARGET_INC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/headers" )
> >
> > ADD_LIBRARY(core_e SHARED ${SRC_FILES} ${HEADER_FILES})
> > TARGET_LINK_LIBRARIES(core_en\ ${TARGET_LIBS})
> > TARGET_INCLUDE_DIRECTORIES(core_e PUBLIC ${TARGET_INC_DIR})
> >
> >
> >
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/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/20160103/cb1e8d04/attachment.html>

From jsvanbethlehem at gmail.com  Sun Jan  3 04:18:48 2016
From: jsvanbethlehem at gmail.com (Jakob van Bethlehem)
Date: Sun, 3 Jan 2016 10:18:48 +0100
Subject: [CMake] Cannot set FOLDER property to an interface
	(header-only) target
In-Reply-To: <CAOU91OPTwN6znU-odvZ8bUWWmySGDTekg7YOhsjCc5vUACJiJg@mail.gmail.com>
References: <CAOU91OMf8+0wZAwS-RPEgst+SXq=B02nDwT_DoqEbp7gBXscFg@mail.gmail.com>
 <23B5E737-711F-4AC8-AC85-96A678D423A4@gmail.com>
 <CAOU91OPTwN6znU-odvZ8bUWWmySGDTekg7YOhsjCc5vUACJiJg@mail.gmail.com>
Message-ID: <ADA34D04-069E-454B-A11A-115576F1E4A0@gmail.com>

Hej,

Just re-read your question to make sure I understood, because I thought in the project I currently work in we had those targets, but not the problems. So I checked and realised we actually gotten rid of those INTERFACE libraries, because we encountered all kinds of trouble, amongst which one is the problem you refer to. Another problem for instance, is that INTERFACE link dependencies don?t get transferred like with normal libraries. Extremely annoying, so we decided the ?academical? use of an INTERFACE library wasn?t (nearly) worth the effort.

Not a resolution to your problem though ??

Sincerely, Jakob


> On 02 Jan 2016, at 13:12, Klaim - Jo?l Lamotte <mjklaim at gmail.com> wrote:
> 
> 
> 
> On 1 January 2016 at 11:00, Jakob van Bethlehem <jsvanbethlehem at gmail.com <mailto:jsvanbethlehem at gmail.com>> wrote:
> Hej Jo?l,
> 
> The command you?re looking for is ?source_group?, see https://cmake.org/cmake/help/v3.0/command/source_group.html <https://cmake.org/cmake/help/v3.0/command/source_group.html>
> 
> 
> I use this already but it works only with source files, not with targets. With targets you need to set the FOLDER property.
>  
> Sincerely,
> Jakob
> 
> 
>> On 30 Dec 2015, at 20:52, Klaim - Jo?l Lamotte <mjklaim at gmail.com <mailto:mjklaim at gmail.com>> wrote:
>> 
>> The following CMake script:
>> 
>>     cmake_minimum_required(VERSION 3.4)
>>     
>>     add_library( mylib INTERFACE )
>>     set_property( TARGET mylib PROPERTY FOLDER /some/dir )
>> 
>> 
>> Will trigger this error on configuration:
>> 
>>     CMake Error at CMakeLists.txt:4 (set_property):
>>       INTERFACE_LIBRARY targets may only have whitelisted properties.  The
>>       property "FOLDER" is not allowed.
>> 
>> 
>> This prevent any interface library to be organized in Visual Studio virtual folders.
>> Unfortunately it also mean that header-only targets can't be organized.
>> 
>> I have no idea how this should be solved. Should the property just be white-listed?
>> Or should a better have a another specific library mode for header-only targets?
>> 
>> Is there any workaround?
>> 
>> Jo?l Lamotte
>> 
>> -- 
>> 
>> Powered by www.kitware.com <http://www.kitware.com/>
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ <http://www.cmake.org/Wiki/CMake_FAQ>
>> 
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html <http://cmake.org/cmake/help/support.html>
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
>> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake <http://public.kitware.com/mailman/listinfo/cmake>
> 
> --
> 
> Powered by www.kitware.com <http://www.kitware.com/>
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ <http://www.cmake.org/Wiki/CMake_FAQ>
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html <http://cmake.org/cmake/help/support.html>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake <http://public.kitware.com/mailman/listinfo/cmake>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160103/843c93cd/attachment-0001.html>

From mjklaim at gmail.com  Sun Jan  3 10:24:40 2016
From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=)
Date: Sun, 3 Jan 2016 16:24:40 +0100
Subject: [CMake] Cannot set FOLDER property to an interface
	(header-only) target
In-Reply-To: <ADA34D04-069E-454B-A11A-115576F1E4A0@gmail.com>
References: <CAOU91OMf8+0wZAwS-RPEgst+SXq=B02nDwT_DoqEbp7gBXscFg@mail.gmail.com>
 <23B5E737-711F-4AC8-AC85-96A678D423A4@gmail.com>
 <CAOU91OPTwN6znU-odvZ8bUWWmySGDTekg7YOhsjCc5vUACJiJg@mail.gmail.com>
 <ADA34D04-069E-454B-A11A-115576F1E4A0@gmail.com>
Message-ID: <CAOU91OOAKnMTPDfR6KPsxvGz5X6SPUj6ZKDCYXSg6HgbRj14vw@mail.gmail.com>

On 3 January 2016 at 10:18, Jakob van Bethlehem <jsvanbethlehem at gmail.com>
wrote:

> Hej,
>
> Just re-read your question to make sure I understood, because I thought in
> the project I currently work in we had those targets, but not the problems.
> So I checked and realised we actually gotten rid of those INTERFACE
> libraries, because we encountered all kinds of trouble, amongst which one
> is the problem you refer to. Another problem for instance, is that
> INTERFACE link dependencies don?t get transferred like with normal
> libraries. Extremely annoying, so we decided the ?academical? use of an
> INTERFACE library wasn?t (nearly) worth the effort.
>
> Not a resolution to your problem though ??
>
>
I reached the same conclusion, but then I wonder what solution did you end
up using for header-only libraries?
Before trying interfaces I had these static libraries with one cpp which
was generated by a leak detection tool, therefore without
leak detection activated the libraries don't generate anything and can't be
linked to.
Adding a custom cpp for static header-only libraries is a bit sad but looks
like a simple way to do it.


> Sincerely, Jakob
>
>
> On 02 Jan 2016, at 13:12, Klaim - Jo?l Lamotte <mjklaim at gmail.com> wrote:
>
>
>
> On 1 January 2016 at 11:00, Jakob van Bethlehem <jsvanbethlehem at gmail.com>
>  wrote:
>
>> Hej Jo?l,
>>
>> The command you?re looking for is ?source_group?, see
>> https://cmake.org/cmake/help/v3.0/command/source_group.html
>>
>>
> I use this already but it works only with source files, not with targets.
> With targets you need to set the FOLDER property.
>
>
>> Sincerely,
>> Jakob
>>
>>
>> On 30 Dec 2015, at 20:52, Klaim - Jo?l Lamotte <mjklaim at gmail.com> wrote:
>>
>> The following CMake script:
>>
>>     cmake_minimum_required(VERSION 3.4)
>>
>>     add_library( mylib INTERFACE )
>>     set_property( TARGET mylib PROPERTY FOLDER /some/dir )
>>
>>
>> Will trigger this error on configuration:
>>
>>     CMake Error at CMakeLists.txt:4 (set_property):
>>       INTERFACE_LIBRARY targets may only have whitelisted properties.
>> The
>>       property "FOLDER" is not allowed.
>>
>>
>> This prevent any interface library to be organized in Visual Studio
>> virtual folders.
>> Unfortunately it also mean that header-only targets can't be organized.
>>
>> I have no idea how this should be solved. Should the property just be
>> white-listed?
>> Or should a better have a another specific library mode for header-only
>> targets?
>>
>> Is there any workaround?
>>
>> Jo?l Lamotte
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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/20160103/0eb4ebf3/attachment.html>

From golubdr at gmail.com  Sun Jan  3 21:58:59 2016
From: golubdr at gmail.com (David Golub)
Date: Sun, 3 Jan 2016 21:58:59 -0500
Subject: [CMake] CMake Tools for Visual Studio 1.4 RC1 Available
Message-ID: <01bc01d1469b$dc8a2050$959e60f0$@gmail.com>

I've made available the first release candidate of CMake Tools for Visual
Studio 1.4, which adds support for Visual Studio 2015 and CMake 3.4..  As
usual, it's 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/20160103/43015a03/attachment.html>

From billchurch76 at gmail.com  Sun Jan  3 23:05:17 2016
From: billchurch76 at gmail.com (Bill Church)
Date: Sun, 3 Jan 2016 23:05:17 -0500
Subject: [CMake] Error generating using "NMake Makefiles JOM"
Message-ID: <CANL8fcBFBKW4rgvt6vbUbbqGq4DJjZ=fa2rBVBz7thvWPnTyew@mail.gmail.com>

I've used this option successfully for a while, but with an older version
of CMake (3.x, unsure which one exactly).  Recently had to do a full
wipe/reinstall of my machine, so I pulled down the latest CMake 3.4.1, but
when I go to generate my project I get the following error:

CMake Error: Generator: execution of make failed. Make command was: "jom"
"/NOLOGO" "cmTC_4f467\fast"

I'm also now using the latest version of Jom, which is 1.1.0.  Any help
resolving this issue would be much appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160103/a728f0de/attachment.html>

From gregoryvv at packz.com  Mon Jan  4 08:52:51 2016
From: gregoryvv at packz.com (Gregory Van Vooren)
Date: Mon, 4 Jan 2016 14:52:51 +0100
Subject: [CMake] fixup bundle vs Qy 5.5.1 and rpaths
In-Reply-To: <1293958247.75789219.1450451753534.JavaMail.zimbra@elemtech.com>
References: <618056F1-CFFF-45F6-BC8D-757EF24F0104@packz.com>
 <1293958247.75789219.1450451753534.JavaMail.zimbra@elemtech.com>
Message-ID: <2D9F41DE-29EC-4B68-9DAB-A5BE5D154255@packz.com>

That solved my problem indeed. Thank you very much (and happy new year).

Kind regards,

Greg.

> On 18 Dec 2015, at 16:15, clinton at elemtech.com wrote:
> 
> 
> It appears you need to add the directory(ies) in the Qt installation containing the Qt libraries to your DIRS.
> 
> set( DIRS 
>  ${APP}/Contents/plugins/platforms
>  ${QT_BINARY_DIR}
>  ${QT_LIBRARY_DIR}
> )
> 
> I think it should have been that way, even with Qt 5.3.
> 
> Clint
> 
> ----- On Dec 18, 2015, at 6:12 AM, Gregory Van Vooren <gregoryvv at packz.com> wrote:
> 
> I have a project containing several applications (which are sub projects), each of which links against some Qt libraries which are built as dylibs, but are not part of the project. Qt libraries and headers are found using find-package which is working perfectly.
> 
> I?m currently trying to switch from Qt 5.3.1 to Qt 5.5.1, but am experiencing problems with fixup_bundle on OS X (everything else seems to work fine).
> As far as I?ve gathered Qt has introduced support for rpaths between those two version and this seems to be the cause of my problems.
> 
> Building a single application works and said application starts up correctly, but building the install target will give me the following output:
> 
> -- fixup_bundle: preparing...
> -- 
> warning: cannot resolve item 'libQt5Core_debug.5.dylib'
> 
>   possible problems:
>     need more directories?
>     need to use InstallRequiredSystemLibraries?
>     run in install tree instead of build tree?
> 
> -- warning: gp_resolved_file_type non-absolute file 'libQt5Core_debug.5.dylib' returning type 'other' -- possibly incorrect
> -- 
> warning: cannot resolve item 'libQt5Core_debug.5.dylib'
> 
>   possible problems:
>     need more directories?
>     need to use InstallRequiredSystemLibraries?
>     run in install tree instead of build tree?
> 
> warning: target 'libQt5Core_debug.5.dylib' is not absolute...
> warning: target 'libQt5Core_debug.5.dylib' does not exist...
> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 (message):
>   
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
>   failed: 1
> 
>   error:
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
>   can't open file: libQt5Core_debug.5.dylib (No such file or directory)
> 
> Call Stack (most recent call first):
>   /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 (get_prerequisites)
>   /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:555 (get_prerequisites)
>   /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:804 (get_bundle_keys)
>   someApplication/someApplication/cmake_install.cmake:115 (fixup_bundle)
> 
> 
> I?ll try to provide sufficient yet minimal information to pinpoint the root cause of the problem.
> In my top CMakeLists.txt I have the following:
> 
> set (
> 		QT_REQUIRED_PACKAGES
> 			Core
> 			Gui
> 			Widgets
> )
> 
> set( QT_ROOT_PATH "/usr/local/Qt-5.5.1" )
> set( QT_REQUIRED_PACKAGES ${QT_REQUIRED_PACKAGES} MacExtras )
> 
> set( 
> 	QT_PLUGINS_DIR
> 		"${QT_ROOT_PATH}/plugins"
> )
> 
> set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "${QT_ROOT_PATH}/bin/" )
> 
> FOREACH(QT_PACKAGE ${QT_REQUIRED_PACKAGES})
> 	set( QT_PACKAGE_WITH_PREFIX "Qt5${QT_PACKAGE}" )
> 	set( "${QT_PACKAGE_WITH_PREFIX}_DIR" "${QT_ROOT_PATH}/lib/cmake/${QT_PACKAGE_WITH_PREFIX}" )
> 	find_package( "${QT_PACKAGE_WITH_PREFIX}" REQUIRED )
> 	include_directories( ${${QT_PACKAGE_WITH_PREFIX}_INCLUDE_DIRS} )
> 
> 	set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_DEBUG "DEBUG")
> 	set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_RELEASE "RELEASE")
> 	set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO "RELEASE")
> ENDFOREACH(QT_PACKAGE)
> 
> add_definitions( ${QT_DEFINITIONS} )
> set( CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR} )
> 
> set( CMAKE_MACOSX_RPATH ?" )
> 
> set_property( GLOBAL PROPERTY USE_FOLDERS ON )
> 
> add_subdirectory( someApplication )
> 
> 
> 
> 
> in the someApplication CMakeLists.txt I have the following:
> 
> set(
> 	someApplication_Qt_LIBRARIES
> 		${Qt5Core_LIBRARIES} 
> 		${Qt5Widgets_LIBRARIES} 
> )
> set_target_properties( someApplication PROPERTIES INSTALL_RPATH "${QT_ROOT_PATH}/lib" )
> foreach( OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES} )
>     install( TARGETS someApplication DESTINATION bin/${OUTPUTCONFIG} CONFIGURATIONS ${OUTPUTCONFIG} )
> endforeach()
> 	
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/ )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf "${QT_PLUGINS_DIR}/platforms/libqcocoa_debug.dylib" ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/  )
> 	
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/ )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf "${QT_PLUGINS_DIR}/platforms/libqcocoa.dylib" ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/  )
> 		
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p `dirname $<TARGET_FILE: someApplication >`/../plugins )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/$<$<CONFIG:Debug>:Debug>$<$<NOT:$<CONFIG:Debug>>:Release>/plugins/ `dirname $<TARGET_FILE: someApplication >`/../plugins/  )
> 
> add_custom_command( TARGET someApplication POST_BUILD COMMAND chmod -R +w `dirname $<TARGET_FILE: someApplication >` )
> 
> set( APP "${CMAKE_INSTALL_PREFIX}/bin/\${CMAKE_INSTALL_CONFIG_NAME}/someApplication.app" )
> 	
> set( DIRS 
> 	${APP}/Contents/plugins/platforms
> )
> 	
> install( CODE "
> 	file( WRITE \"${APP}/Contents/Resources/qt.conf\" \"[Paths]\\nPlugins <smb://nPlugins> = plugins\\n\" )
> 	" COMPONENT Runtime
> )
> 		
> foreach( DYNAMIC_LIBRARY ${someApplication_DYNAMIC_LIBRARIES} )
> 	add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf $<TARGET_FILE:${DYNAMIC_LIBRARY}> `dirname $<TARGET_FILE: someApplication >` )
> endforeach()
> 
> install( CODE "
> 	file( GLOB_RECURSE QT_PLATFORM_PLUGINS \"${APP}/Contents/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX}\" )
> 	include( BundleUtilities )
> 	fixup_bundle( \"${APP}\"   \"\${QT_PLATFORM_PLUGINS}\"   \"${DIRS}\" )
> 	" COMPONENT Runtime
> )
> 
> 
> Any help is greatly appreciated.
> 
> Kind regards,
> 
> Greg.
> 
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160104/cec70d70/attachment-0001.html>

From attila.krasznahorkay at gmail.com  Mon Jan  4 09:26:55 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Mon, 4 Jan 2016 15:26:55 +0100
Subject: [CMake] Get target name from command line for IF statement
In-Reply-To: <CA+qGvKzTnHUsiV0Jm2wHjCE=Es+UoPKjNc0uxv7XZ9pdmEK7OQ@mail.gmail.com>
References: <CA+qGvKzTnHUsiV0Jm2wHjCE=Es+UoPKjNc0uxv7XZ9pdmEK7OQ@mail.gmail.com>
Message-ID: <E9FA39E2-F33B-4A3E-9CA8-0A57EEB60F45@gmail.com>

Hi Yann,

I have no idea what LINKER_SCATTER_FILE does, but...

if( TARGET <bla> )

is a check that will evaluate to true if a target named <bla> *exists*. In this configuration neither "target_1" or "target_2" exist at the point when you run this check. So LINKER_SCATTER_FILE will always be set to "file_2".

I think you're mixing what happens when configuring your build, and when actually executing it. In this setup you seem to always want to build both target_1 and target_2. So you'll need to set some property on these targets to assign the different "scatter files" to them. (I have absolutely no idea what a "scatter file" is supposed to be...)

Could you elaborate on what you're really trying to do?

Cheers,
            Attila

> On 30 Dec 2015, at 11:29, yann suisini <yannsuisini at gmail.com> wrote:
> 
> Hi,
> 
> I have a cmake file with 2 targets defined inside.
> For each target I have to specify a different scatter file for my linker
> 
> so I want to use :
> if (TARGET target_1)
> 	SET (LINKER_SCATTER_FILE file_1)
> else ()
> 	SET (LINKER_SCATTER_FILE file_2)
> endif ()
> 
> add_executable(target_1 ${srcs_target_1})
> add_executable(target_2 ${srcs_target_2})
> 
> 
> But if I'm calling cmake from my IDE to build my target using the --target command line option
> does it set the TARGET variable ? If not the case how I can link the targer name from the command line to my IF statement ?
> 
> Regards,
> 
> Yann.
> 
> 
> 
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 tom.kacvinsky at vectorcast.com  Mon Jan  4 11:34:24 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Mon, 4 Jan 2016 11:34:24 -0500
Subject: [CMake] Error generating using "NMake Makefiles JOM"
In-Reply-To: <CANL8fcBFBKW4rgvt6vbUbbqGq4DJjZ=fa2rBVBz7thvWPnTyew@mail.gmail.com>
References: <CANL8fcBFBKW4rgvt6vbUbbqGq4DJjZ=fa2rBVBz7thvWPnTyew@mail.gmail.com>
Message-ID: <CAAEKttwN_OZ15R4=LQXgqQ1pWcnEk=3FeWLK7b_PYvT-3CmMyw@mail.gmail.com>

On Sun, Jan 3, 2016 at 11:05 PM, Bill Church <billchurch76 at gmail.com> wrote:

> I've used this option successfully for a while, but with an older version
> of CMake (3.x, unsure which one exactly).  Recently had to do a full
> wipe/reinstall of my machine, so I pulled down the latest CMake 3.4.1, but
> when I go to generate my project I get the following error:
>
> CMake Error: Generator: execution of make failed. Make command was: "jom"
> "/NOLOGO" "cmTC_4f467\fast"
>
> I'm also now using the latest version of Jom, which is 1.1.0.  Any help
> resolving this issue would be much appreciated.
>
>
Is jom in your path?  I have seen this before and sure enough, jom was no
tin my path.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160104/59a7da29/attachment.html>

From mike.jackson at bluequartz.net  Mon Jan  4 12:13:37 2016
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 4 Jan 2016 12:13:37 -0500
Subject: [CMake] Using "Fixup_Bundle" on a single library?
Message-ID: <2FCAD977-C6C9-457F-83AB-20D25DB947C1@bluequartz.net>

During our packaging process one of our support libraries is getting missed for various reasons (severe edge case). Is it possible to use the ?Fixup_bundle? CMake function with a single library? Or add that single library as an additional library that needs to be adjusted?

Thanks
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net


From billchurch76 at gmail.com  Mon Jan  4 17:08:51 2016
From: billchurch76 at gmail.com (Bill Church)
Date: Mon, 4 Jan 2016 17:08:51 -0500
Subject: [CMake] Error generating using "NMake Makefiles JOM"
In-Reply-To: <CAAEKttwN_OZ15R4=LQXgqQ1pWcnEk=3FeWLK7b_PYvT-3CmMyw@mail.gmail.com>
References: <CANL8fcBFBKW4rgvt6vbUbbqGq4DJjZ=fa2rBVBz7thvWPnTyew@mail.gmail.com>
 <CAAEKttwN_OZ15R4=LQXgqQ1pWcnEk=3FeWLK7b_PYvT-3CmMyw@mail.gmail.com>
Message-ID: <CANL8fcDz2Z4y-xLOGfNOSQ3UMgBFk_gRW3ek2qQoGBJnj7heTw@mail.gmail.com>

Yes, jom is in the path.  However, someone very brilliant in the IT
department made it such that the system PATH and user PATH equaled the same
strings, causing my overall PATH to be way too long for Windows' liking.
So the jom part of the path was being truncated out.  I wouldn't have
thought of that, but noticed it when I doubled checked based on your
feedback.  Thanks Tom.  It's all working lovely now.


On Mon, Jan 4, 2016 at 11:34 AM, Tom Kacvinsky <tom.kacvinsky at vectorcast.com
> wrote:

>
>
> On Sun, Jan 3, 2016 at 11:05 PM, Bill Church <billchurch76 at gmail.com>
> wrote:
>
>> I've used this option successfully for a while, but with an older version
>> of CMake (3.x, unsure which one exactly).  Recently had to do a full
>> wipe/reinstall of my machine, so I pulled down the latest CMake 3.4.1, but
>> when I go to generate my project I get the following error:
>>
>> CMake Error: Generator: execution of make failed. Make command was: "jom"
>> "/NOLOGO" "cmTC_4f467\fast"
>>
>> I'm also now using the latest version of Jom, which is 1.1.0.  Any help
>> resolving this issue would be much appreciated.
>>
>>
> Is jom in your path?  I have seen this before and sure enough, jom was no
> tin my path.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160104/5a9ffc90/attachment.html>

From acgtyrant at gmail.com  Tue Jan  5 02:11:43 2016
From: acgtyrant at gmail.com (Isaac Ge)
Date: Tue, 5 Jan 2016 15:11:43 +0800
Subject: [CMake] I can not set CMAKE_BUILD_TYPE in CMakeList.txt
Message-ID: <CAFUKwMmjWmUpQENiT=BAUQ=AFxyEz7XiUWS+9gDR9=ChA5_CQw@mail.gmail.com>

Hi anyone, I find the `set(CMAKE_BUILD_TYPE RelWithDebInfo)` in
CMakeList.txt does not work, because the actual build type show by ccmake
is empty. So I have to enter the correct build type in ccmake or add
command argument `-D CMAKE_BUILD_TYPE=RelWithDebInfo` while cmake.

Any idea? Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160105/15276c35/attachment.html>

From attila.krasznahorkay at gmail.com  Tue Jan  5 02:55:30 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Tue, 5 Jan 2016 08:55:30 +0100
Subject: [CMake] I can not set CMAKE_BUILD_TYPE in CMakeList.txt
In-Reply-To: <CAFUKwMmjWmUpQENiT=BAUQ=AFxyEz7XiUWS+9gDR9=ChA5_CQw@mail.gmail.com>
References: <CAFUKwMmjWmUpQENiT=BAUQ=AFxyEz7XiUWS+9gDR9=ChA5_CQw@mail.gmail.com>
Message-ID: <AED9B0E3-29B4-4EC1-BC11-24AF28EF93B6@gmail.com>

Hi Isaac,

ccmake will only allow you to modify cache variables. When you call

set( CMAKE_BUILD_TYPE RelWithDebInfo )

, this creates a local variable in your CMakeLists.txt file. This way it should *always* override whatever you set on the command line, or as a cache variable.

If you want to set the default value to RelWithDebInfo, but allow the user to override it either with ccmake or a command line argument, you should do something like:

set( CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Build type" )

At least I think it should work like this...

Cheers,
              Attila

> On 05 Jan 2016, at 08:11, Isaac Ge <acgtyrant at gmail.com> wrote:
> 
> Hi anyone, I find the `set(CMAKE_BUILD_TYPE RelWithDebInfo)` in CMakeList.txt does not work, because the actual build type show by ccmake is empty. So I have to enter the correct build type in ccmake or add command argument `-D CMAKE_BUILD_TYPE=RelWithDebInfo` while cmake.
> 
> Any idea? 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 chrspx at gmail.com  Tue Jan  5 06:55:03 2016
From: chrspx at gmail.com (Charles Prado)
Date: Tue, 05 Jan 2016 11:55:03 +0000
Subject: [CMake] Fwd: Linking external code that uses different library
	version
In-Reply-To: <CANj_zzTDUDm2QHmA_gsZFfZRLXpOGyu7jsvFarmA9yKWhE6u3Q@mail.gmail.com>
References: <CANj_zzTDUDm2QHmA_gsZFfZRLXpOGyu7jsvFarmA9yKWhE6u3Q@mail.gmail.com>
Message-ID: <CANj_zzRt+62xvODjYdXgMEciG+9T5NZaA9PxS34EAU9_X1wazw@mail.gmail.com>

Hello everyone.

I'm trying to build my project, which have this code as dependency:
https://github.com/kylemcdonald/FaceTracker .

The project Is using the library OpenCV (version 3.1.0), but I need to
compile FaceTracker code using OpenCV version 2.4.0. CMake provides any
option that can help me with this?

Here is my CMakeLists.txt file:

cmake_minimum_required(VERSION 2.8)
project( Neuromarketing-RF )
find_package( Boost 1.58.0 REQUIRED COMPONENTS filesystem system )
include_directories( ${Boost_INCLUDE_DIRS} include src/external )
find_package( OpenCV REQUIRED )
file(GLOB FACETRACKER_HEADERS
"external/FaceTracker/include/FaceTracker/*.h")
file(GLOB FACETRACKER_SRC "external/FaceTracker/src/*/*.cc")
file(GLOB SOURCES "src/*cpp")
add_executable( Neuromarketing-RF ${SOURCES} ${FACETRACKER_SRC} )
target_link_libraries( Neuromarketing-RF ${OpenCV_LIBS} ${Boost_LIBRARIES} )
target_compile_features( Neuromarketing-RF PRIVATE cxx_range_for )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160105/da6ea142/attachment.html>

From rozelak at volny.cz  Wed Jan  6 06:14:23 2016
From: rozelak at volny.cz (rozelak at volny.cz)
Date: Wed, 06 Jan 2016 12:14:23 +0100
Subject: [CMake] =?utf-8?q?get=5Fprerequisites=28=29_-_fails_with_No_such_?=
	=?utf-8?q?file_or_directory?=
Message-ID: <20160106121423.E1BABDD3@volny.cz>

Hallo.I try to use get_prerequisites() and it seems that it is called before the target is created. The CMake code snipped is as follows:    set(SRC_FILES ....)    # Make lib    add_library(          OUTPUT SHARED ${SRCS_FILES})    target_link_libraries(OUTPUT ${PROJECT_LIBRARIES})    target_link_libraries(OUTPUT ${PYTHON_LIBRARIES})    # Install    install(TARGETS       OUTPUT   RUNTIME DESTINATION ./ COMPONENT Runtime                                   LIBRARY DESTINATION ./ COMPONENT Runtime)    # ---    include(GetPrerequisites)    string(TOUPPER ${CMAKE_BUILD_TYPE} CONFIG)    get_target_property(LOC OUTPUT LOCATION_${CONFIG})    ##    message("---> location = ${LOC}")    ##    get_prerequisites(${LOC} PREREQS 0 0 "" "")    ##    message("---> prerequisites: ${PREREQS}")    foreach(D ${PREREQS})            message("    ---> ${D}")    endforeach()    ###but it seems that get_prerequisites() is called before the target is created (the sources are compiled and library is link
 ed). It results in the following error messages.Under Linux:    -- The C compiler identification is GNU 4.8.3    -- The CXX compiler identification is GNU 4.8.3    -- Check for working C compiler: /usr/bin/cc    -- Check for working C compiler: /usr/bin/cc -- works    -- Detecting C compiler ABI info    -- Detecting C compiler ABI info - done    -- Check for working CXX compiler: /usr/bin/c++    -- Check for working CXX compiler: /usr/bin/c++ -- works    -- Detecting CXX compiler ABI info    -- Detecting CXX compiler ABI info - done    ...    CMake Warning (dev) at CMakeLists.txt:171 (get_target_property):      Policy CMP0026 is not set: Disallow use of the LOCATION target property.      Run "cmake --help-policy CMP0026" for policy details.  Use the cmake_policy      command to set the policy and suppress this warning.      The LOCATION property should not be read from target      "SpeechTechTTS_Python".  Use the target name directly with      add_custom_command, or use the 
 generator expression $<TARGET_FILE>, as      appropriate.    This warning is for project developers.  Use -Wno-dev to suppress it.    ---> location = /tmp/smazat_2/SpeechTechTTS_Python.so    warning: target '/tmp/smazat_2/SpeechTechTTS_Python.so' does not exist...    ldd: /tmp/smazat_2/SpeechTechTTS_Python.so: No such file or directory    ---> prerequisites:    -- Configuring done    -- Generating doneUnder windows:    -- The C compiler identification is MSVC 18.0.40629.0    -- The CXX compiler identification is MSVC 18.0.40629.0    -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe    -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe -- works    -- Detecting C compiler ABI info    -- Detecting C compiler ABI info - done    -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe    -- Check for working CXX compiler: C:/Program Files (x
 86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe -- works    -- Detecting CXX compiler ABI info    -- Detecting CXX compiler ABI info - done    -- Detecting CXX compile features    -- Detecting CXX compile features - done    ...    CMake Warning (dev) at CMakeLists.txt:171 (get_target_property):      Policy CMP0026 is not set: Disallow use of the LOCATION target property.      Run "cmake --help-policy CMP0026" for policy details.  Use the cmake_policy      command to set the policy and suppress this warning.      The LOCATION property should not be read from target      "SpeechTechTTS_Python".  Use the target name directly with      add_custom_command, or use the generator expression $<TARGET_FILE>, as      appropriate.    This warning is for project developers.  Use -Wno-dev to suppress it.    ---> location = T:/smazat/SpeechTechTTS_Python.dll    warning: target 'T:/smazat/SpeechTechTTS_Python.dll' does not exist...    CMake Error at C:/Program Files (x86)/CMake/share/cmake-3
 .4/Modules/GetPrerequisites.cmake:798 (message):      C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/dumpbin.exe      failed: 1181    -- Configuring incomplete, errors occurred!    See also "T:/smazat/CMakeFiles/CMakeOutput.log".      Microsoft (R) COFF/PE Dumper Version 12.00.40629.0      Copyright (C) Microsoft Corporation.  All rights reserved.      Dump of file T:/smazat/SpeechTechTTS_Python.dll      LINK : fatal error LNK1181: cannot open input file      'T:/smazat/SpeechTechTTS_Python.dll'    Call Stack (most recent call first):      CMakeLists.txt:174 (get_prerequisites)When get_prerequisites() is not called, the build works correctly. So, did I do anything wrong?Thank you very much. Best regards,Dan T.P.S. I use cmake 3.0.2 under Linux and 3.4.0-rc2 on windows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160106/a1f44ce6/attachment.html>

From gabriel.archacki.hare at gmail.com  Wed Jan  6 10:02:22 2016
From: gabriel.archacki.hare at gmail.com (Gabriel Archacki Hare)
Date: Wed, 6 Jan 2016 07:02:22 -0800
Subject: [CMake] How can I control / debug linking arguments?
Message-ID: <34400570-03A2-412B-B46B-87D263002568@gmail.com>

I am trying to set up a cross-compile using FindCUDA to the TegraK1 architecture, which limits me to CUDA 6.5. Specifically, I have a subdirectory TestCUDA that compiles (using separable compilation) to a library libTestCUDA.a, which is then linked with code that is compiled using c++11 (which is not available in CUDA 6.5).

I can compile this by manually issuing build commands. And, I have set up the scripts so that in both OS X and Ubuntu compiling to the respective systems (not a cross-compile) works. However, when I try to cross compile, in the final linking stage 64 bit libraries are referenced, resulting in failure.

[100%] Linking CXX executable Test
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/Test.dir/link.txt --verbose=1
/usr/bin/arm-linux-gnueabihf-g++   -std=c++11 -O3 -DNDEBUG   CMakeFiles/Test.dir/Test.cxx.o  -o Test /home/ghare/Documents/autowiring-build-tegrak1/lib/libAutowiring.a TestCUDA/libTestCUDA.a /usr/local/cuda-6.5/targets/armv7-linux-gnueabihf/lib/libcudart_static.a -lpthread /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/x86_64-linux-gnu/libdl.so 
/usr/lib/x86_64-linux-gnu/librt.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status

However, the following command successfully completes the compiling:
arm-linux-gnueabihf-g++ -mfloat-abi=hard -o Test  CMakeFiles/Test.dir/Test.cxx.o /home/ghare/Documents/autowiring-build-tegrak1/lib/libAutowiring.a TestCUDA/libTestCUDA.a -Xlinker --dynamic-linker=/lib/ld-linux-armhf.so.3 -L/usr/local/cuda-6.5/bin/../targets/armv7-linux-gnueabihf/lib/stubs -L/usr/local/cuda-6.5/bin/../targets/armv7-linux-gnueabihf/lib -lcudadevrt -lcudart_static -lrt -lpthread -ldl

All I need to do to have a complete cross-compile setup is to modify the linking?

-Gabriel


P. S. In case it will help, verbose output from the linking state follows:
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.2-16ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabihf/include/c++/4.8.2 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) 
COMPILER_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/
LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-O3' '-D' 'NDEBUG' '-o' 'Test' '-shared-libgcc' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
 /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=gnu --as-needed -m armelf_linux_eabi -z relro -o Test /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/crt1.o /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/crti.o /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/crtbegin.o -L/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8 -L/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib CMakeFiles/Test.dir/Test.cxx.o /home/ghare/Documents/autowiring-build-tegrak1/lib/libAutowiring.a TestCUDA/libTestCUDA.a /usr/local/cuda-6.5/targets/armv7-linux-gnueabihf/lib/libcudart_static.a -lpthread /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/x86_64-linux-gnu/libdl.so -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/x86_64-linux-gnu/librt.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status

From bill.hoffman at kitware.com  Wed Jan  6 12:39:56 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Wed, 6 Jan 2016 12:39:56 -0500
Subject: [CMake] get_prerequisites() - fails with No such file or
 directory
In-Reply-To: <20160106121423.E1BABDD3@volny.cz>
References: <20160106121423.E1BABDD3@volny.cz>
Message-ID: <568D516C.8000703@kitware.com>

On 1/6/2016 6:14 AM, rozelak at volny.cz wrote:
> When get_prerequisites() is not called, the build works correctly. So, did I do anything wrong?
  get_prerequisites needs to be called at install time and not CMake time.

Look at install(CODE "")

-Bill


From rozelak at volny.cz  Thu Jan  7 04:17:09 2016
From: rozelak at volny.cz (rozelak at volny.cz)
Date: Thu, 07 Jan 2016 10:17:09 +0100
Subject: [CMake]
	=?utf-8?q?get=5Fprerequisites=28=29_-_fails_with_No_such_?=
	=?utf-8?q?file_or_directory?=
In-Reply-To: <568D516C.8000703@kitware.com>
References: <20160106121423.E1BABDD3@volny.cz> <568D516C.8000703@kitware.com>
Message-ID: <20160107101709.F6D7EAF1@volny.cz>

>> When get_prerequisites() is not called, the build works correctly. So, did I do anything wrong?
> get_prerequisites needs to be called at install time and not CMake time.
>
>Look at install(CODE "")
>
>-Bill
?
Hello Bill,thank you for your answer. I guessed that this is the problem, but I didn't know about install(CODE ...) directive. Thank you!So, now I have used:      install(CODE "include(GetPrerequisites)                    get_prerequisites(${LOC} PREREQS 0 0 \"\" \"\")                    message(\"---> prerequisites: ${PREREQS} for ${LOC}\")                    foreach(D in ${PREREQS})                            message(\"     >>> ${D}\")                    endforeach()                    "       )ans it stopped to report the error - seems to work for the first look. However, there are no dependencies listed (at least under windows, where I need it primarily):    Install the project...    echo >nul && "C:\Program Files (x86)\CMake\bin\cmake.exe" -P cmake_install.cmake    -- Install configuration: "Release"    -- Installing: t:/smazat/x86_32_windows/./SpeechTechTTS_Python.dll    ---> prerequisites:  for T:/smazat/SpeechTechTTS_Python.dll        >>>Manual invocation of 'dumpbin 
 /dependents SpeechTechTTS_Python.dll' returns:    Microsoft (R) COFF/PE Dumper Version 12.00.40629.0    Copyright (C) Microsoft Corporation.  All rights reserved.    Dump of file SpeechTechTTS_Python.dll    File Type: DLL    Image has the following dependencies:        expat.dll        python27.dll        KERNEL32.dll    Summary        7000 .data        6E000 .rdata        7000 .reloc        1000 .rsrc        7E000 .text        2000 _RDATAWhy none of dependent DLL are listed, even when exclude_system option is set to 0?Thank you again,Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160107/d4f83bd8/attachment.html>

From rozelak at volny.cz  Thu Jan  7 05:52:19 2016
From: rozelak at volny.cz (rozelak at volny.cz)
Date: Thu, 07 Jan 2016 11:52:19 +0100
Subject: [CMake]
	=?utf-8?q?get=5Fprerequisites=28=29_-_fails_with_No_such_?=
	=?utf-8?q?file_or_directory?=
Message-ID: <20160107115219.AA3E1163@volny.cz>

Sorry po re-posting, the formatting in the previous message was badly corupted ... :-(
?
______________________ P?vodn? zpr?va: ________________________
> Od: <rozelak at volny.cz>
> Komu: <cmake at cmake.org>
> Datum: 07.01.2016 10:25
> P?edm?t: Re: [CMake]get_prerequisites() - fails with No such file or directory
>
>> When get_prerequisites() is not called, the build works correctly. So, did I do anything wrong?
> get_prerequisites needs to be called at install time and not CMake time.
>
>Look at install(CODE "")
>
>-Bill
?
?
Hello Bill,thank you for your answer. I guessed that this is the problem, but I didn't know about install(CODE ...) directive. Thank you!So, now I have used:      install(CODE "include(GetPrerequisites)                    get_prerequisites(${LOC} PREREQS 0 0 \"\" \"\")                    message(\"---> prerequisites: ${PREREQS} for ${LOC}\")                    foreach(D in ${PREREQS})                            message(\"     >>> ${D}\")                    endforeach()                    "       )as it stopped to report the error - seems to work for the first look. However, there are no dependencies listed (at least under windows, where I need it primarily):    Install the project...    echo >nul && "C:\Program Files (x86)\CMake\bin\cmake.exe" -P cmake_install.cmake    -- Install configuration: "Release"    -- Installing: t:/smazat/x86_32_windows/./SpeechTechTTS_Python.dll    ---> prerequisites:  for T:/smazat/SpeechTechTTS_Python.dll        >>>Manual invocation of 'dumpbin /
 dependents SpeechTechTTS_Python.dll' returns:    Microsoft (R) COFF/PE Dumper Version 12.00.40629.0    Copyright (C) Microsoft Corporation.  All rights reserved.    Dump of file SpeechTechTTS_Python.dll    File Type: DLL    Image has the following dependencies:        expat.dll        python27.dll        KERNEL32.dll    Summary        7000 .data        6E000 .rdata        7000 .reloc        1000 .rsrc        7E000 .text        2000 _RDATAWhy none of dependent DLL are listed, even when exclude_system option is set to 0?Thank you again,Dan?

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

From mohammedrashadkm at gmail.com  Thu Jan  7 08:51:18 2016
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Thu, 7 Jan 2016 14:51:18 +0100
Subject: [CMake] adding parts of build log to dashboard.
Message-ID: <CANNqv9dyGmtri37ZxKmCe61TriivUO7uc-g+ovqE0770sfnFFA@mail.gmail.com>

Hello,

How can I include part of my build log to cdash output. Currently cdash
pickup build errors and warnings.

In the build summary, if there is no build log attached. I think this is
intentional given the size of build log for some projects.

What I would like to know is , if there is way I can put some logs into
build summary page via some special cmake settings. I don't may be setting
a cmake var ?

My situation is I have a set of add_custom_targets that I used to make
packages. they produce various ouputs such as processing abc.dll, creating
zip archive, adding files to archive etc..

Is there a way I can include them into the build summary ?



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

From attila.krasznahorkay at gmail.com  Thu Jan  7 11:17:17 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Thu, 7 Jan 2016 17:17:17 +0100
Subject: [CMake] adding parts of build log to dashboard.
In-Reply-To: <CANNqv9dyGmtri37ZxKmCe61TriivUO7uc-g+ovqE0770sfnFFA@mail.gmail.com>
References: <CANNqv9dyGmtri37ZxKmCe61TriivUO7uc-g+ovqE0770sfnFFA@mail.gmail.com>
Message-ID: <C2FA55F8-11D2-431C-AE0C-C3E19111D28F@gmail.com>

Hi Rashad,

It may not be the perfect way of doing it, but I attach build log files as "notes". With something like:

set( CTEST_NOTES_FILES ${CTEST_BINARY_DIRECTORY}/BuildLogs/log1.log ... )
ctest_submit( PARTS Build Notes )

(I actually do something rather more complicated. I split the build into sub-projects, which are built in parallel, producing subproject-specific build logs in parallel. In the end I upload all the build results one by one for each of the sub-projects. I can send you my NightlyBuild.cmake file if you're interested...)

Cheers,
            Attila

> On 07 Jan 2016, at 14:51, Rashad Kanavath <mohammedrashadkm at gmail.com> wrote:
> 
> Hello,
> 
> How can I include part of my build log to cdash output. Currently cdash pickup build errors and warnings. 
> 
> In the build summary, if there is no build log attached. I think this is intentional given the size of build log for some projects.
> 
> What I would like to know is , if there is way I can put some logs into build summary page via some special cmake settings. I don't may be setting a cmake var ?
> 
> My situation is I have a set of add_custom_targets that I used to make packages. they produce various ouputs such as processing abc.dll, creating zip archive, adding files to archive etc..
> 
> Is there a way I can include them into the build summary ?
> 
> 
> 
> -- 
> Regards,
>    Rashad
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 clinton at elemtech.com  Thu Jan  7 11:21:41 2016
From: clinton at elemtech.com (Clinton Stimpson)
Date: Thu, 07 Jan 2016 09:21:41 -0700
Subject: [CMake] adding parts of build log to dashboard.
In-Reply-To: <CANNqv9dyGmtri37ZxKmCe61TriivUO7uc-g+ovqE0770sfnFFA@mail.gmail.com>
References: <CANNqv9dyGmtri37ZxKmCe61TriivUO7uc-g+ovqE0770sfnFFA@mail.gmail.com>
Message-ID: <2803721.KSblf2r5Ia@stryke>

On Thursday, January 07, 2016 02:51:18 PM Rashad Kanavath wrote:
> Hello,
> 
> How can I include part of my build log to cdash output. Currently cdash
> pickup build errors and warnings.
> 
> In the build summary, if there is no build log attached. I think this is
> intentional given the size of build log for some projects.
> 
> What I would like to know is , if there is way I can put some logs into
> build summary page via some special cmake settings. I don't may be setting
> a cmake var ?
> 
> My situation is I have a set of add_custom_targets that I used to make
> packages. they produce various ouputs such as processing abc.dll, creating
> zip archive, adding files to archive etc..
> 
> Is there a way I can include them into the build summary ?

I don't know how to add them to the build summary.

What I do for packages is make a test for them, using add_test().
There are settings to control how much test output you get on cdash.

Clint

From attila.krasznahorkay at gmail.com  Thu Jan  7 13:00:07 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Thu, 7 Jan 2016 19:00:07 +0100
Subject: [CMake] Finding out in a CMake script whether it's being run by
	CPack or CMake
Message-ID: <94230CF2-F879-48B8-8A2E-118322A0FCBF@gmail.com>

Dear All,

I have a maybe unusual problem.

In my code I have an installation rule like the following:

      install( CODE "execute_process( COMMAND ${CMAKE_COMMAND}
                        -E create_symlink ../src/${pkgDir}/${dir}
                        ${CMAKE_INSTALL_INCDIR}/${dir}
                        WORKING_DIRECTORY ${CMAKE_INSTALL_INCDIR} )" )

Where CMAKE_INSTALL_INCDIR is set to ${DESTDIR}/${CMAKE_INSTALL_PREFIX}/include upstream.

This worked fine so far. But now we want to start building RPM packages from this code. For which we had to set

set( CPACK_SET_DESTDIR FALSE )

in a CPack installation script. As far as I understand from the description of this variable (https://cmake.org/cmake/help/v3.0/variable/CPACK_SET_DESTDIR.html), in this setup I should set CMAKE_INSTALL_INCDIR to ${CPACK_PACKAGING_INSTALL_PREFIX}/install instead.

But how can I determine in this install rule that CPack is running the show now. I can't just look for CPACK_SET_DESTDIR to be set. As in a normal build it's also not set, and I still need to rely on ${DESTDIR} and ${CMAKE_INSTALL_PREFIX}. I'm sure that there is a reasonably simple way to test for this, but I just couldn't find it. :-(

Cheers,
            Attila

From brad.king at kitware.com  Thu Jan  7 13:35:01 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 7 Jan 2016 13:35:01 -0500
Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var
In-Reply-To: <56659267.3030208@kitware.com>
References: <CAHHAsmZg2A4nTnnsfwJpktJeTqQdH4hiZ9x-SXdzpCN4xJhJ7g@mail.gmail.com>
 <56606F7B.4090609@kitware.com>
 <CAPB8=n87_AXHKrNhC=tjRNGeQyPmeZyUDne-xAmZkhuXTvAVZQ@mail.gmail.com>
 <CAHHAsmbN+jKB_sWZ-Udb4CtmhdTeGLKU_o0MW4ub5FT1Fhmm2Q@mail.gmail.com>
 <56659267.3030208@kitware.com>
Message-ID: <568EAFD5.7010401@kitware.com>

On 12/07/2015 09:06 AM, Brad King wrote:
> Yes.  We will look at addressing this for the 3.5 release now that we
> understand the cause.

We've switched to using the WiX generator to produce a .msi installer
instead:

 Utilities/Release: Switch to .msi builder for Windows binary
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=083312a8

This avoids the issue altogether.

-Brad


From a.neundorf-work at gmx.net  Thu Jan  7 16:59:18 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Thu, 07 Jan 2016 22:59:18 +0100
Subject: [CMake] Creating relocatable export files
In-Reply-To: <CAHk1PgGN-Pn1EQgMgTmmg3jGmRrUghDvpUZ0625q0XHjA3gRjA@mail.gmail.com>
References: <564720A7.8000206@codelibre.net>
 <CAHk1PgGN-Pn1EQgMgTmmg3jGmRrUghDvpUZ0625q0XHjA3gRjA@mail.gmail.com>
Message-ID: <4106495.E3dypD0Xtv@tuxedo.neundorf.net>

On Saturday, November 14, 2015 12:19:11 Nicholas Braden wrote:
> Instead of using FOO_INCLUDE_DIR, I believe you should use
> target_include_directories() with the INTERFACE or PUBLIC options -
> this will export the include directories properly and they will be
> used when someone target_link_library()s your exported target.
> https://cmake.org/cmake/help/latest/command/target_include_directories.html?
> highlight=INTERFACE
> 
> There seems to be a section in the documentation on making sure your
> packages are relocatable:
> https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-re
> locatable-packages
> 
> See also:
> https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html

this is from before the fancy target-include-directories-propagation 
functionality was added, it shouldn't be necessary anymore.

Alex


From rainer.poisel at gmail.com  Thu Jan  7 17:28:21 2016
From: rainer.poisel at gmail.com (Rainer Poisel)
Date: Thu, 7 Jan 2016 22:28:21 +0000
Subject: [CMake] Imported libraries and cyclic dependencies
Message-ID: <CADpFnzxcy0F7oSGgAw57uUhFq7w8TPwW8W09Swxt1hWHijAZ-A@mail.gmail.com>

Hi,

I am having troubles with linking a bunch of imported libraries that
have cyclic dependencies.

This is what I am doing:

8<=======================
find_library(ESP8266_SDK_LIB_MAIN main ${ESP8266_SDK_BASE}/lib)
add_library(esp8266_main UNKNOWN IMPORTED)
set_property(TARGET esp8266_main PROPERTY IMPORTED_LOCATION
"${ESP8266_SDK_LIB_MAIN}")

find_library(ESP8266_SDK_LIB_PHY phy ${ESP8266_SDK_BASE}/lib)
add_library(esp8266_phy UNKNOWN IMPORTED)
set_property(TARGET esp8266_phy PROPERTY IMPORTED_LOCATION
"${ESP8266_SDK_LIB_PHY}")

find_library(ESP8266_SDK_LIB_PP pp ${ESP8266_SDK_BASE}/lib)
add_library(esp8266_pp UNKNOWN IMPORTED)
set_property(TARGET esp8266_pp PROPERTY IMPORTED_LOCATION
"${ESP8266_SDK_LIB_PP}")

find_library(ESP8266_SDK_LIB_LWIP lwip ${ESP8266_SDK_BASE}/lib)
add_library(esp8266_lwip UNKNOWN IMPORTED)
set_property(TARGET esp8266_lwip PROPERTY IMPORTED_LOCATION
"${ESP8266_SDK_LIB_LWIP}")

target_link_libraries(ESP8266_SDK INTERFACE
    gcc
    esp8266_lwip
    esp8266_main
    esp8266_phy
    esp8266_pp
)

target_link_libraries(esp8266_main INTERFACE
    esp8266_lwip
    esp8266_pp
    esp8266_phy
)
8<=======================

The given example is not complete. However, I hope it is sufficient to
give you an idea of what I want to achieve: I would like to specify
the dependencies between imported libraries. Subsequently I want to
make the linker call mention my libraries several times in order to
make the linker resolve all dependency cycles (multiplicity).

This is the corresponding error message:

8<=======================
CMake Error at external/esp8266-cmake/sdk/nonos-1.4.0.cmake:111
(target_link_libraries):
Cannot specify link libraries for target "esp8266_main" which is not built
by this project.
8<=======================

As a workaround I added the -Wl,--start-group (referred to as
BUILD_LINK_PREFIX) and the -Wl,--end-group (referred to as
BUILD_LINK_SUFFIX) arguments (yes, it is a GCC) directly to the
invocation of target_link_libraries() of my executable which has been
defined by add_executable() beforehand. But I think that this is just
a botch-up.

Here is an example of the complete code (using the before-mentioned workaround):
  * https://github.com/rpoisel/esp8266-mqtt
  * https://github.com/rpoisel/esp8266-cmake/blob/master/main/CMakeLists.txt

Thanks for any suggestions in advance,
  Rainer

From iosif.neitzke+cmake at gmail.com  Thu Jan  7 21:18:05 2016
From: iosif.neitzke+cmake at gmail.com (iosif neitzke)
Date: Thu, 7 Jan 2016 20:18:05 -0600
Subject: [CMake] Imported libraries and cyclic dependencies
In-Reply-To: <CADpFnzxcy0F7oSGgAw57uUhFq7w8TPwW8W09Swxt1hWHijAZ-A@mail.gmail.com>
References: <CADpFnzxcy0F7oSGgAw57uUhFq7w8TPwW8W09Swxt1hWHijAZ-A@mail.gmail.com>
Message-ID: <a22ddc25-8e07-e9c4-8cc8-a835fc33d672@gmail.com>

Which version of CMake are you using?

On 01/07/2016 04:28 PM, Rainer Poisel wrote:
> Hi,
>
> I am having troubles with linking a bunch of imported libraries that
> have cyclic dependencies.
>
> This is what I am doing:
>
> 8<=======================
> find_library(ESP8266_SDK_LIB_MAIN main ${ESP8266_SDK_BASE}/lib)
> add_library(esp8266_main UNKNOWN IMPORTED)
> set_property(TARGET esp8266_main PROPERTY IMPORTED_LOCATION
> "${ESP8266_SDK_LIB_MAIN}")
>
> find_library(ESP8266_SDK_LIB_PHY phy ${ESP8266_SDK_BASE}/lib)
> add_library(esp8266_phy UNKNOWN IMPORTED)
> set_property(TARGET esp8266_phy PROPERTY IMPORTED_LOCATION
> "${ESP8266_SDK_LIB_PHY}")
>
> find_library(ESP8266_SDK_LIB_PP pp ${ESP8266_SDK_BASE}/lib)
> add_library(esp8266_pp UNKNOWN IMPORTED)
> set_property(TARGET esp8266_pp PROPERTY IMPORTED_LOCATION
> "${ESP8266_SDK_LIB_PP}")
>
> find_library(ESP8266_SDK_LIB_LWIP lwip ${ESP8266_SDK_BASE}/lib)
> add_library(esp8266_lwip UNKNOWN IMPORTED)
> set_property(TARGET esp8266_lwip PROPERTY IMPORTED_LOCATION
> "${ESP8266_SDK_LIB_LWIP}")
>
> target_link_libraries(ESP8266_SDK INTERFACE
>     gcc
>     esp8266_lwip
>     esp8266_main
>     esp8266_phy
>     esp8266_pp
> )
>
> target_link_libraries(esp8266_main INTERFACE
>     esp8266_lwip
>     esp8266_pp
>     esp8266_phy
> )
> 8<=======================
>
> The given example is not complete. However, I hope it is sufficient to
> give you an idea of what I want to achieve: I would like to specify
> the dependencies between imported libraries. Subsequently I want to
> make the linker call mention my libraries several times in order to
> make the linker resolve all dependency cycles (multiplicity).
>
> This is the corresponding error message:
>
> 8<=======================
> CMake Error at external/esp8266-cmake/sdk/nonos-1.4.0.cmake:111
> (target_link_libraries):
> Cannot specify link libraries for target "esp8266_main" which is not built
> by this project.
> 8<=======================
>
> As a workaround I added the -Wl,--start-group (referred to as
> BUILD_LINK_PREFIX) and the -Wl,--end-group (referred to as
> BUILD_LINK_SUFFIX) arguments (yes, it is a GCC) directly to the
> invocation of target_link_libraries() of my executable which has been
> defined by add_executable() beforehand. But I think that this is just
> a botch-up.
>
> Here is an example of the complete code (using the before-mentioned workaround):
>   * https://github.com/rpoisel/esp8266-mqtt
>   * https://github.com/rpoisel/esp8266-cmake/blob/master/main/CMakeLists.txt
>
> Thanks for any suggestions in advance,
>   Rainer
>

From rainer.poisel at gmail.com  Fri Jan  8 01:26:28 2016
From: rainer.poisel at gmail.com (Rainer Poisel)
Date: Fri, 8 Jan 2016 06:26:28 +0000
Subject: [CMake] Imported libraries and cyclic dependencies
In-Reply-To: <a22ddc25-8e07-e9c4-8cc8-a835fc33d672@gmail.com>
References: <CADpFnzxcy0F7oSGgAw57uUhFq7w8TPwW8W09Swxt1hWHijAZ-A@mail.gmail.com>
 <a22ddc25-8e07-e9c4-8cc8-a835fc33d672@gmail.com>
Message-ID: <CADpFnzzGyLDVn42fBv6f-e7yM4tWmRo_C-KqbAeja-bpcTyMEA@mail.gmail.com>

Hello,

I am using CMake 3.4.1.

Best regards,
  Rainer


On Fri, Jan 8, 2016 at 2:18 AM, iosif neitzke
<iosif.neitzke+cmake at gmail.com> wrote:
> Which version of CMake are you using?
>
>
> On 01/07/2016 04:28 PM, Rainer Poisel wrote:
>>
>> Hi,
>>
>> I am having troubles with linking a bunch of imported libraries that
>> have cyclic dependencies.
>>
>> This is what I am doing:
>>
>> 8<=======================
>> find_library(ESP8266_SDK_LIB_MAIN main ${ESP8266_SDK_BASE}/lib)
>> add_library(esp8266_main UNKNOWN IMPORTED)
>> set_property(TARGET esp8266_main PROPERTY IMPORTED_LOCATION
>> "${ESP8266_SDK_LIB_MAIN}")
>>
>> find_library(ESP8266_SDK_LIB_PHY phy ${ESP8266_SDK_BASE}/lib)
>> add_library(esp8266_phy UNKNOWN IMPORTED)
>> set_property(TARGET esp8266_phy PROPERTY IMPORTED_LOCATION
>> "${ESP8266_SDK_LIB_PHY}")
>>
>> find_library(ESP8266_SDK_LIB_PP pp ${ESP8266_SDK_BASE}/lib)
>> add_library(esp8266_pp UNKNOWN IMPORTED)
>> set_property(TARGET esp8266_pp PROPERTY IMPORTED_LOCATION
>> "${ESP8266_SDK_LIB_PP}")
>>
>> find_library(ESP8266_SDK_LIB_LWIP lwip ${ESP8266_SDK_BASE}/lib)
>> add_library(esp8266_lwip UNKNOWN IMPORTED)
>> set_property(TARGET esp8266_lwip PROPERTY IMPORTED_LOCATION
>> "${ESP8266_SDK_LIB_LWIP}")
>>
>> target_link_libraries(ESP8266_SDK INTERFACE
>>     gcc
>>     esp8266_lwip
>>     esp8266_main
>>     esp8266_phy
>>     esp8266_pp
>> )
>>
>> target_link_libraries(esp8266_main INTERFACE
>>     esp8266_lwip
>>     esp8266_pp
>>     esp8266_phy
>> )
>> 8<=======================
>>
>> The given example is not complete. However, I hope it is sufficient to
>> give you an idea of what I want to achieve: I would like to specify
>> the dependencies between imported libraries. Subsequently I want to
>> make the linker call mention my libraries several times in order to
>> make the linker resolve all dependency cycles (multiplicity).
>>
>> This is the corresponding error message:
>>
>> 8<=======================
>> CMake Error at external/esp8266-cmake/sdk/nonos-1.4.0.cmake:111
>> (target_link_libraries):
>> Cannot specify link libraries for target "esp8266_main" which is not built
>> by this project.
>> 8<=======================
>>
>> As a workaround I added the -Wl,--start-group (referred to as
>> BUILD_LINK_PREFIX) and the -Wl,--end-group (referred to as
>> BUILD_LINK_SUFFIX) arguments (yes, it is a GCC) directly to the
>> invocation of target_link_libraries() of my executable which has been
>> defined by add_executable() beforehand. But I think that this is just
>> a botch-up.
>>
>> Here is an example of the complete code (using the before-mentioned
>> workaround):
>>   * https://github.com/rpoisel/esp8266-mqtt
>>   *
>> https://github.com/rpoisel/esp8266-cmake/blob/master/main/CMakeLists.txt
>>
>> Thanks for any suggestions in advance,
>>   Rainer
>>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From yves.frederix+cmake at gmail.com  Fri Jan  8 05:22:13 2016
From: yves.frederix+cmake at gmail.com (Yves Frederix)
Date: Fri, 8 Jan 2016 11:22:13 +0100
Subject: [CMake] Why does INTERFACE type targets only support whitelisted
	properties?
Message-ID: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>

Hi all,

Motivated by my own struggles with targets of type INTERFACE and a
recent post on this list, I was wondering what is the rationale behind
allowing only a whitelisted set of properties on targets of this type.
I understand that one of the use cases for INTERFACE libraries is to
have a way to work with header-only libraries in a more or less
standard way. Yes, the current implementation is far from optimal on
more than one aspect, but I never understood the reason for the
whitelisting (also google didn't make me any wiser). What am I
missing? Wouldn't INTERFACE targets be easier to use without these
restrictions (or alternatively by switching to blacklisting of some
properties to protect a user from having wrong expectations)?

Thanks!
Yves

From nilsgladitz at gmail.com  Fri Jan  8 06:21:27 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 8 Jan 2016 12:21:27 +0100
Subject: [CMake] Why does INTERFACE type targets only support
 whitelisted properties?
In-Reply-To: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
Message-ID: <568F9BB7.7090604@gmail.com>

On 01/08/2016 11:22 AM, Yves Frederix wrote:
> Hi all,
>
> Motivated by my own struggles with targets of type INTERFACE and a
> recent post on this list, I was wondering what is the rationale behind
> allowing only a whitelisted set of properties on targets of this type.
> I understand that one of the use cases for INTERFACE libraries is to
> have a way to work with header-only libraries in a more or less
> standard way. Yes, the current implementation is far from optimal on
> more than one aspect, but I never understood the reason for the
> whitelisting (also google didn't make me any wiser). What am I
> missing? Wouldn't INTERFACE targets be easier to use without these
> restrictions (or alternatively by switching to blacklisting of some
> properties to protect a user from having wrong expectations)?

It might help the discussion if you could elaborate what use cases you 
have in mind for non-whitelisted properties.

Assuming you mean the recent discussion on the FOLDER property:
   The FOLDER property would have no effect on interface targets even if 
the property were whitelisted.
   Interface targets don't have project files so there is nothing to be 
sorted into a folder either.

As for whitelisting vs blacklisting:
   The whitelist is significantly shorter and easier to maintain (when 
new properties are added) than an equivalent blacklist.

Nils



From yves.frederix+cmake at gmail.com  Fri Jan  8 07:07:18 2016
From: yves.frederix+cmake at gmail.com (Yves Frederix)
Date: Fri, 8 Jan 2016 13:07:18 +0100
Subject: [CMake] Why does INTERFACE type targets only support
	whitelisted properties?
In-Reply-To: <568F9BB7.7090604@gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
Message-ID: <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>

> It might help the discussion if you could elaborate what use cases you have
> in mind for non-whitelisted properties.

I deliberately did not mention my particular use case from the start
simply because I am interested in the reasoning behind the limitation,
not directly in how I can work around a particular instance ;)
However, since you asked, in this case I was trying to access the
SOURCE_DIR property of an INTERFACE target. This property is in fact
defined on the target, but I cannot access it due to the whitelisting
being enforced by get_property.

> Assuming you mean the recent discussion on the FOLDER property:
>   The FOLDER property would have no effect on interface targets even if the
> property were whitelisted.
>   Interface targets don't have project files so there is nothing to be
> sorted into a folder either.

This was indeed the discussion I was referring to. One could discuss
whether or not interface targets should have project files and/or
source files associated to them (as one would expect of a header-only
library), but I am trying not to go there at this point. Being able to
get/set any property without CMake exiting with an error could be seen
independent of this I think.

>
> As for whitelisting vs blacklisting:
>   The whitelist is significantly shorter and easier to maintain (when new
> properties are added) than an equivalent blacklist.

I cannot really judge this statement (what properties should really
need to be blacklisted? All standard CMake target properties?)
In any case, if blacklisting were used, it would allow a developer to
assign custom target properties (for the sake of argument, let's
assume that in some more complex projects one could make good use of
them) without having to give this custom property a name that starts
with INTERFACE_.


Yves

From nilsgladitz at gmail.com  Fri Jan  8 08:02:16 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 8 Jan 2016 14:02:16 +0100
Subject: [CMake] Why does INTERFACE type targets only support
 whitelisted properties?
In-Reply-To: <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
Message-ID: <568FB358.9060005@gmail.com>

On 01/08/2016 01:07 PM, Yves Frederix wrote:
>> It might help the discussion if you could elaborate what use cases you have
>> in mind for non-whitelisted properties.
> I deliberately did not mention my particular use case from the start
> simply because I am interested in the reasoning behind the limitation,
> not directly in how I can work around a particular instance ;)
> However, since you asked, in this case I was trying to access the
> SOURCE_DIR property of an INTERFACE target. This property is in fact
> defined on the target, but I cannot access it due to the whitelisting
> being enforced by get_property.

Still at the very least this might be an argument to whitelist SOURCE_DIR.

An argument for the whitelist diagnostics might be that it reduces 
reports from users which try to set build properties that do not have 
any effect in context of interface targets.
A user might e.g. think that a specific property should work because 
CMake did not issue any diagnostics and open an issue.
The diagnostic implies that this behavior is by design.

It also prevents users from using existing properties which currently 
don't have semantics for INTERFACE targets but might be implemented in 
the future (potentially with different semantics than expected by the user).

>
>> Assuming you mean the recent discussion on the FOLDER property:
>>    The FOLDER property would have no effect on interface targets even if the
>> property were whitelisted.
>>    Interface targets don't have project files so there is nothing to be
>> sorted into a folder either.
> This was indeed the discussion I was referring to. One could discuss
> whether or not interface targets should have project files and/or
> source files associated to them (as one would expect of a header-only
> library), but I am trying not to go there at this point. Being able to
> get/set any property without CMake exiting with an error could be seen
> independent of this I think.

I would also see this as an independent issue.
If there were projects and sources for interface targets that would be 
an argument to whitelist e.g. FOLDER not an argument to allow all 
properties.

>
>> As for whitelisting vs blacklisting:
>>    The whitelist is significantly shorter and easier to maintain (when new
>> properties are added) than an equivalent blacklist.
> I cannot really judge this statement (what properties should really
> need to be blacklisted? All standard CMake target properties?)

To start with all CMake target properties that aren't currently on the 
whitelist.


> In any case, if blacklisting were used, it would allow a developer to
> assign custom target properties (for the sake of argument, let's
> assume that in some more complex projects one could make good use of
> them) without having to give this custom property a name that starts
> with INTERFACE_.

I think allowing custom (non cmake defined) properties might be a valid 
argument.
These could perhaps also be supported through e.g. user extension of the 
whitelist.

I don't think anything should be changed however unless there are actual 
use cases that aren't supported by the current implementation.

Nils

From yves.frederix+cmake at gmail.com  Fri Jan  8 08:50:02 2016
From: yves.frederix+cmake at gmail.com (Yves Frederix)
Date: Fri, 8 Jan 2016 14:50:02 +0100
Subject: [CMake] Why does INTERFACE type targets only support
	whitelisted properties?
In-Reply-To: <568FB358.9060005@gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
 <568FB358.9060005@gmail.com>
Message-ID: <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>

<snip>
> Still at the very least this might be an argument to whitelist SOURCE_DIR.
>
> An argument for the whitelist diagnostics might be that it reduces reports
> from users which try to set build properties that do not have any effect in
> context of interface targets.

You are explicitly mentioning 'setting' of a property. IMHO there is a
big difference between setting and getting a property. If
white/blacklisting is enforced during setting only, wouldn't this be
sufficient? This would make it possible to simply access all
properties that are automatically assigned to the target (which I
assume implies that by definition they should make sense?). A
non-acceptable property could not have been set and would hence not be
found, making it possible to check for its existence in the "standard"
way.

> A user might e.g. think that a specific property should work because CMake
> did not issue any diagnostics and open an issue.
> The diagnostic implies that this behavior is by design.
>
> It also prevents users from using existing properties which currently don't
> have semantics for INTERFACE targets but might be implemented in the future
> (potentially with different semantics than expected by the user).

Ok, this somehow contradicts my above assumption and is somewhat
surprising. Wouldn't it make sense to simply not set these properties
in the first place if they have incorrect semantics? This way,
get_property would not need to care about them and it would anyhow not
stop their correct implementation in the future.

>
>>
>>> Assuming you mean the recent discussion on the FOLDER property:
>>>    The FOLDER property would have no effect on interface targets even if
>>> the
>>> property were whitelisted.
>>>    Interface targets don't have project files so there is nothing to be
>>> sorted into a folder either.
>>
>> This was indeed the discussion I was referring to. One could discuss
>> whether or not interface targets should have project files and/or
>> source files associated to them (as one would expect of a header-only
>> library), but I am trying not to go there at this point. Being able to
>> get/set any property without CMake exiting with an error could be seen
>> independent of this I think.
>
>
> I would also see this as an independent issue.
> If there were projects and sources for interface targets that would be an
> argument to whitelist e.g. FOLDER not an argument to allow all properties.
>
>>
>>> As for whitelisting vs blacklisting:
>>>    The whitelist is significantly shorter and easier to maintain (when
>>> new
>>> properties are added) than an equivalent blacklist.
>>
>> I cannot really judge this statement (what properties should really
>> need to be blacklisted? All standard CMake target properties?)
>
>
> To start with all CMake target properties that aren't currently on the
> whitelist.
>
>
>> In any case, if blacklisting were used, it would allow a developer to
>> assign custom target properties (for the sake of argument, let's
>> assume that in some more complex projects one could make good use of
>> them) without having to give this custom property a name that starts
>> with INTERFACE_.
>
>
> I think allowing custom (non cmake defined) properties might be a valid
> argument.
> These could perhaps also be supported through e.g. user extension of the
> whitelist.

I like this idea. With this in place, one would not need to wait for a
new CMake release if a valid property were missing from the whitelist
or if one wanted to use custom properties.

>
> I don't think anything should be changed however unless there are actual use
> cases that aren't supported by the current implementation.

Does this mean that you would have doubts about patches that:
 - provide a way for the user to extend the whitelist?
 - remove the need for whitelisting in get_property by making CMake
only automatically assign sensible target properties?

Of course the first would provide the solution for my use cases and
the second would be more like a nice-to-have ;)

Regards,
Yves

From nilsgladitz at gmail.com  Fri Jan  8 09:12:17 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 8 Jan 2016 15:12:17 +0100
Subject: [CMake] Why does INTERFACE type targets only support
 whitelisted properties?
In-Reply-To: <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
 <568FB358.9060005@gmail.com>
 <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>
Message-ID: <568FC3C1.50803@gmail.com>



On 01/08/2016 02:50 PM, Yves Frederix wrote:
> You are explicitly mentioning 'setting' of a property. IMHO there is a
> big difference between setting and getting a property. If
> white/blacklisting is enforced during setting only, wouldn't this be
> sufficient? This would make it possible to simply access all
> properties that are automatically assigned to the target (which I
> assume implies that by definition they should make sense?). A
> non-acceptable property could not have been set and would hence not be
> found, making it possible to check for its existence in the "standard"
> way.

The same argument might hold for getting of properties.
E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties 
now but was implemented in the future.

>> A user might e.g. think that a specific property should work because CMake
>> did not issue any diagnostics and open an issue.
>> The diagnostic implies that this behavior is by design.
>>
>> It also prevents users from using existing properties which currently don't
>> have semantics for INTERFACE targets but might be implemented in the future
>> (potentially with different semantics than expected by the user).
> Ok, this somehow contradicts my above assumption and is somewhat
> surprising. Wouldn't it make sense to simply not set these properties
> in the first place if they have incorrect semantics? This way,
> get_property would not need to care about them and it would anyhow not
> stop their correct implementation in the future.

I meant existing as in defined for regular build targets not as in 
actually set for interface targets.
get_property() would return an empty string for those if they weren't 
whitelisted and one might argue that this could suffice.
On the other hand users often assume that they get a valid value and 
don't actually check.

>>
>> I think allowing custom (non cmake defined) properties might be a valid
>> argument.
>> These could perhaps also be supported through e.g. user extension of the
>> whitelist.
> I like this idea. With this in place, one would not need to wait for a
> new CMake release if a valid property were missing from the whitelist
> or if one wanted to use custom properties.
>
>> I don't think anything should be changed however unless there are actual use
>> cases that aren't supported by the current implementation.
> Does this mean that you would have doubts about patches that:
>   - provide a way for the user to extend the whitelist?
>   - remove the need for whitelisting in get_property by making CMake
> only automatically assign sensible target properties?

The issue is less that CMake assigns these properties (I don't know of 
any such case but I haven't checked) and more that users might just 
expect them to be set (which does not provide a diagnostic).

Personally I would not object to either approach as long as there are 
actual use cases.
Without use cases such changes would be by definition useless.

Nils

From gabriel.archacki.hare at gmail.com  Fri Jan  8 14:15:18 2016
From: gabriel.archacki.hare at gmail.com (Gabriel Archacki Hare)
Date: Fri, 8 Jan 2016 14:15:18 -0500
Subject: [CMake] How can I control / debug linking arguments (Separable
	Cross-compile of CUDA 6.5 for ARMv7 linked with -std=c++11)?
In-Reply-To: <34400570-03A2-412B-B46B-87D263002568@gmail.com>
References: <34400570-03A2-412B-B46B-87D263002568@gmail.com>
Message-ID: <50C323B3-D9F0-4766-BDCB-42FF4BC062DF@gmail.com>

Since I figured out how to get the separable cross-compile to a library working I thought I would share.

To answer the ?How can I use X to do Y? question (http://www.catb.org/~esr/faqs/smart-questions.html#idp42280576):
The FindCUDA package defines the CUDA_LIBRARIES list, which includes the problematic 64bit libraries.

The next step is to read through the FindCUDA source code. (The WRONG place to look is the GitHub repo for FindCUDA? the right place is the FindCUDA module that is installed.) In the source, it turns out that 2 variables are set that are not documented (https://cmake.org/cmake/help/v3.4/module/FindCUDA.html) whose state can be printed out. These are:
CUDA_rt_LIBRARY
CUDA_dl_LIBRARY
These variables in turn are set using find_library (https://cmake.org/cmake/help/v3.3/command/find_library.html) whose behavior is determined by variables including:
CMAKE_LIBRARY_ARCHITECTURE
CMAKE_PREFIX_PATH
The problem I had encountered was due to having CMAKE_LIBRARY_ARCHITECTURE = x86_64-linux-gnu, and CMAKE_PREFIX_PATH empty.

For my particular setup (Ubuntu 14.04 with cuda-cross-armhf installed) the I needed to change the above settings to have CMAKE_LIBRARY_ARCHITECTURE empty and CMAKE_PREFIX_PATH = /usr/arm-linux-gnueabihf.

P.S. In the course of trying to solve this I stumbled on a thread that seemed to me to be exactly the same issue and was NOT: (http://stackoverflow.com/questions/7476625/set-global-gcc-default-search-paths). Hopefully anyone reading this will avoid that particular rabbit hole (or identify it as their actual issue).


> On 6 Jan, 2016, at 10:02 AM, Gabriel Archacki Hare <Gabriel.Archacki.Hare at gmail.com> wrote:
> 
> I am trying to set up a cross-compile using FindCUDA to the TegraK1 architecture, which limits me to CUDA 6.5. Specifically, I have a subdirectory TestCUDA that compiles (using separable compilation) to a library libTestCUDA.a, which is then linked with code that is compiled using c++11 (which is not available in CUDA 6.5).
> 
> I can compile this by manually issuing build commands. And, I have set up the scripts so that in both OS X and Ubuntu compiling to the respective systems (not a cross-compile) works. However, when I try to cross compile, in the final linking stage 64 bit libraries are referenced, resulting in failure.
> 
> [100%] Linking CXX executable Test
> /usr/local/bin/cmake -E cmake_link_script CMakeFiles/Test.dir/link.txt --verbose=1
> /usr/bin/arm-linux-gnueabihf-g++   -std=c++11 -O3 -DNDEBUG   CMakeFiles/Test.dir/Test.cxx.o  -o Test /home/ghare/Documents/autowiring-build-tegrak1/lib/libAutowiring.a TestCUDA/libTestCUDA.a /usr/local/cuda-6.5/targets/armv7-linux-gnueabihf/lib/libcudart_static.a -lpthread /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/x86_64-linux-gnu/libdl.so 
> /usr/lib/x86_64-linux-gnu/librt.so: file not recognized: File format not recognized
> collect2: error: ld returned 1 exit status
> 
> However, the following command successfully completes the compiling:
> arm-linux-gnueabihf-g++ -mfloat-abi=hard -o Test  CMakeFiles/Test.dir/Test.cxx.o /home/ghare/Documents/autowiring-build-tegrak1/lib/libAutowiring.a TestCUDA/libTestCUDA.a -Xlinker --dynamic-linker=/lib/ld-linux-armhf.so.3 -L/usr/local/cuda-6.5/bin/../targets/armv7-linux-gnueabihf/lib/stubs -L/usr/local/cuda-6.5/bin/../targets/armv7-linux-gnueabihf/lib -lcudadevrt -lcudart_static -lrt -lpthread -ldl
> 
> All I need to do to have a complete cross-compile setup is to modify the linking?
> 
> -Gabriel
> 
> 
> P. S. In case it will help, verbose output from the linking state follows:
> Using built-in specs.
> COLLECT_GCC=/usr/bin/arm-linux-gnueabihf-g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/lto-wrapper
> Target: arm-linux-gnueabihf
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.2-16ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabihf/include/c++/4.8.2 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
> Thread model: posix
> gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) 
> COMPILER_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/
> LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-O3' '-D' 'NDEBUG' '-o' 'Test' '-shared-libgcc' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=gnu --as-needed -m armelf_linux_eabi -z relro -o Test /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/crt1.o /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/crti.o /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/crtbegin.o -L/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8 -L/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib CMakeFiles/Test.dir/Test.cxx.o /home/ghare/Documents/autowiring-build-tegrak1/lib/libAutowiring.a TestCUDA/libTestCUDA.a /usr/local/cuda-6.5/targets/armv7-linux-gnueabihf/lib/libcudart_static.a -lpthread /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/x86_64-linux-gnu/libdl.so -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
> /usr/lib/x86_64-linux-gnu/librt.so: file not recognized: File format not recognized
> collect2: error: ld returned 1 exit status


From kim.topley at streamingedge.com  Fri Jan  8 14:31:36 2016
From: kim.topley at streamingedge.com (Kim Topley)
Date: Fri, 8 Jan 2016 14:31:36 -0500
Subject: [CMake] CMake External Project always being rebuilt
Message-ID: <CAG7TyHCptcr-c69=skVOvpw5FJv-f47rkqoyk2HDvMhqHaJvnQ@mail.gmail.com>

I am using an external project to download and build a third-party library
from GitHub. This works fine, except that every time, I run make, the
configure and build parts of the external project run, even though nothing
has changed. Here is the relevant CMake code:

=================================
include(ExternalProject)

set(JEMALLOC_PREFIX_DIR ${CMAKE_BINARY_DIR}/Jemalloc)
set(JEMALLOC_SRC_DIR ${JEMALLOC_PREFIX_DIR}/src/Jemalloc)
set(JEMALLOC_INSTALL_DIR ${JEMALLOC_PREFIX_DIR}/install)

ExternalProject_Add(Jemalloc
        GIT_REPOSITORY      https://github.com/jemalloc/jemalloc.git
        GIT_TAG             master
        PREFIX              ${JEMALLOC_PREFIX_DIR}
        CONFIGURE_COMMAND   echo Configuring jemalloc
                            && cd ${JEMALLOC_SRC_DIR}
                            && ./autogen.sh && ./configure
--prefix=${JEMALLOC_INSTALL_DIR} --with-jemalloc-prefix=je_ --enable-prof
        BUILD_COMMAND       echo Building jemalloc && cd ${JEMALLOC_SRC_DIR}
                            && make install_lib_static install_include
        INSTALL_COMMAND     ""
)

# Create libjemalloc and libjemalloc-pic targets to be used as
# dependencies
add_library(libjemalloc STATIC IMPORTED GLOBAL)
add_library(libjemalloc-pic STATIC IMPORTED GLOBAL)

set_target_properties(libjemalloc PROPERTIES
        "IMPORTED_LOCATION" "${JEMALLOC_INSTALL_DIR}/lib/libjemalloc.a")
set_target_properties(libjemalloc-pic PROPERTIES
        "IMPORTED_LOCATION" "${JEMALLOC_INSTALL_DIR}/lib/libjemalloc-pic.a")

# Make the targets depend on the external project download.
add_dependencies(libjemalloc Jemalloc)
add_dependencies(libjemalloc-pic Jemalloc)

# Export the include directory path.
set(JEMALLOC_INCLUDE_DIR ${JEMALLOC_INSTALL_DIR}/include)

=================================


When I run this for the first time, the library code is pulled from Git and
built. The second time around, I see this:

[ 13%] Performing update step for 'Jemalloc'
Current branch master is up to date.
[ 18%] Performing configure step for 'Jemalloc'
Configuring jemalloc
autoconf
./configure --enable-autogen

I really don't want anything to be rebuilt if there are no changes in the
source repository. What am I doing wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160108/f0b330e7/attachment.html>

From rpf2116 at columbia.edu  Fri Jan  8 22:16:23 2016
From: rpf2116 at columbia.edu (Elizabeth Fischer)
Date: Fri, 8 Jan 2016 22:16:23 -0500
Subject: [CMake] CMAKE_INSTALL_RPATH_USE_LINK_PATH is broken?
Message-ID: <CAC_jL3yJFX4tkK3RRYFjn_meezjLzEPs=4ji-veBe6C-PZSG5A@mail.gmail.com>

Hello,

I'm using cmake 3.4.1.  I'm trying to compile libraries & executables with
an RPATH.  To that end, I use the following settings:


SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)


I then link in a lot of libraries.  However, ONLY ONE of the libraries gets
picked up to be used in the RPATH sent to the linker.  I can manually set
CMAKE_INSTALL_RPATH (that works).  But CMAKE_INSTALL_RPATH_USE_LINK_PATH
seems to be broken.

Interestingly, the one library it's willing to auto-generate an RPATH for
is the same library, whether it comes first or last in the link command
line.  The link command generated by CMake is shown below; it's clear that
many libraries are being linked in, but only one rpath is being generated.

HELP!!!!?
--- Elizabeth

[ 30%] Linking CXX executable test_array

cd /Users/rpfische/git/spsparse/build/test &&
/Users/rpfische/macports/mpgompi-4.9.3/bin/cmake -E cmake_link_script
CMakeFiles/test_array.dir/link.txt --verbose=1

/Users/rpfische/macports/mpgompi-4.9.3/bin/g++   -g -Wl,-search_paths_first
-Wl,-headerpad_max_install_names
CMakeFiles/test_array.dir/test_array.cpp.o  -o test_array
/Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest.a
/Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest_main.a
/Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib
/Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib
/Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib
../slib/libspsparse.dylib
/Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib
/Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib
/Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib -Wl,-rpath
,/Users/rpfische/eb/software/ibmisc/devel/lib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160108/b9924a49/attachment.html>

From rjvbertin at gmail.com  Sat Jan  9 05:13:20 2016
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Sat, 09 Jan 2016 11:13:20 +0100
Subject: [CMake] Make CMAKE_EXPORT_COMPILE_COMMANDS not default?
Message-ID: <4647792.glc2tCC2tL@patux>

Hello,

Sorry for reviving an old thread (https://cmake.org/pipermail/cmake/2013-December/056517.html) but it seems to have died without a proper answer, at least one that I could find.

I'd like to offer an additional reason why CMAKE_EXPORT_COMPILE_COMMANDS would be beneficial if on by default, one that apparently didn't come up.
IDEs like KDevelop and QtCreator use this option to know the layout/contents of a project. They will add it to the cmake invocation when you create a new build directory for said project. However, they can also be pointed to an already existing build directory, in which case it'd be preferable if they didn't have to run cmake again (neither IDE has the option to run cmake under the kind of strictly controlled environment that might be required to configure it "just right").

Regards,
Ren?


From kaparis.dimitri at gmail.com  Sat Jan  9 05:27:48 2016
From: kaparis.dimitri at gmail.com (Dimitri Kaparis)
Date: Sat, 9 Jan 2016 12:27:48 +0200
Subject: [CMake] Code::blocks: parallel build from IDE
Message-ID: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>

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.

In the "Project build options" window, under "Make commands" tab, there is
a box to specify a "Build project/target" command, where I can add -j
switch to make. But that box is only editable for individual executable and
library subprojects, while for virtual CMake-generated targets, such as
"all", it is disabled.

Any ideas?

Regards,
Dimitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160109/fe8876b8/attachment-0001.html>

From a.neundorf-work at gmx.net  Sat Jan  9 14:16:27 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Sat, 09 Jan 2016 20:16:27 +0100
Subject: [CMake] Code::blocks: parallel build from IDE
In-Reply-To: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>
References: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>
Message-ID: <6790985.K0psM2NUZv@tuxedo.neundorf.net>

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


From konstantin at podsvirov.pro  Sat Jan  9 15:15:24 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Sat, 09 Jan 2016 23:15:24 +0300
Subject: [CMake] [Re]  How to select components by default using CPack ?
Message-ID: <2875411452370524@web29j.yandex.ru>

Hi David!

I found your letter here:

http://public.kitware.com/pipermail/cmake/2015-December/062188.html

Earlier I was not subscribed to the CMake Users.

I see that you try to use IFW generator.

Can offer you the following variant of the script:

cmake_minimum_required(VERSION 3.2)
project(test)

set(CPACK_PACKAGE_NAME Hello)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Hello world using IFW")
set(CPACK_PACKAGE_VERSION "1.0.0")
set(CPACK_GENERATOR "IFW")
set(CPACK_COMPONENTS_GROUPING "IGNORE")

set(PLUGINS one two)

foreach (plugin ${PLUGINS})
 install(
 FILES ${plugin}.js
 COMPONENT plugin_${plugin}
 DESTINATION plugins
 )

 list(APPEND CPACK_COMPONENTS_ALL plugin_${plugin})
endforeach ()

include(CPack)
include(CPackIFW)

cpack_add_component_group(plugins)

foreach (plugin ${PLUGINS})
 cpack_add_component(
 plugin_${plugin}
 DISPLAY_NAME "${plugin}"
 DESCRIPTION "Install ${plugin}.js"
 GROUP plugins
 )
endforeach ()

(not tested, but should work :-)

In this embodiment do not need to create a dummy group.
Also all the plugins are selected by default. If you want you can
to indicate return putting in DISABLED when the component is added.

If you have more questions, ask. I'll try to answer.

--
Regards,
Konstantin Podsvirov

From burlen.loring at gmail.com  Sat Jan  9 20:23:41 2016
From: burlen.loring at gmail.com (Burlen Loring)
Date: Sat, 9 Jan 2016 17:23:41 -0800
Subject: [CMake] empty string and cmake_parse_arguments
Message-ID: <5691B29D.1040906@gmail.com>

Is it possible to pass "" (an empty string) through 
cmake_parse_arguments?  I'm using cmake 3.4.0.

I found much discussion of a patch to do this in a thread on the cmake 
developer list. however, cmake_parse_arguments still eats the "", and I 
am finding no official documentation about it.

Burlen

From cristian.adam at gmail.com  Mon Jan 11 06:42:06 2016
From: cristian.adam at gmail.com (Cristian Adam)
Date: Mon, 11 Jan 2016 11:42:06 +0000 (UTC)
Subject: [CMake] CMake based package manager
References: <53A84A03.9040500@yahoo.com>
Message-ID: <loom.20160111T123849-813@post.gmane.org>

Ruslan Baratov via CMake <cmake at ...> writes:

> 
> Hi,
> 
> I'm developing a project that is a kind of wrapper of 
> ExternalProject_Add and
> allow it to be more reusable. User interface is quite simple.
> 
> For anybody interested, here is a github project:
> 
> * https://github.com/ruslo/hunter

Recently posted on reddit: 
https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
e_manager_for_c/

Any thoughts of including such a project in CMake? 

Cheers,
Cristian.



From nicholas11braden at gmail.com  Mon Jan 11 08:33:28 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Mon, 11 Jan 2016 07:33:28 -0600
Subject: [CMake] CMake based package manager
In-Reply-To: <loom.20160111T123849-813@post.gmane.org>
References: <53A84A03.9040500@yahoo.com>
 <loom.20160111T123849-813@post.gmane.org>
Message-ID: <CAHk1PgGB5W+7xax5SHXom-6-+iTNDSNOYS-i2FfFybDznXYp6g@mail.gmail.com>

Doesn't biicode already fill this role? Biicode seems to work well
enough for me, anyway.

On Mon, Jan 11, 2016 at 5:42 AM, Cristian Adam <cristian.adam at gmail.com> wrote:
> Ruslan Baratov via CMake <cmake at ...> writes:
>
>>
>> Hi,
>>
>> I'm developing a project that is a kind of wrapper of
>> ExternalProject_Add and
>> allow it to be more reusable. User interface is quite simple.
>>
>> For anybody interested, here is a github project:
>>
>> * https://github.com/ruslo/hunter
>
> Recently posted on reddit:
> https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
> e_manager_for_c/
>
> Any thoughts of including such a project in CMake?
>
> Cheers,
> Cristian.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 cristian.adam at gmail.com  Mon Jan 11 08:40:15 2016
From: cristian.adam at gmail.com (Cristian Adam)
Date: Mon, 11 Jan 2016 14:40:15 +0100
Subject: [CMake] CMake based package manager
In-Reply-To: <CAHk1PgGB5W+7xax5SHXom-6-+iTNDSNOYS-i2FfFybDznXYp6g@mail.gmail.com>
References: <53A84A03.9040500@yahoo.com>
 <loom.20160111T123849-813@post.gmane.org>
 <CAHk1PgGB5W+7xax5SHXom-6-+iTNDSNOYS-i2FfFybDznXYp6g@mail.gmail.com>
Message-ID: <CA+u+m-+rBsGGbgLVNMQ13JKnpf8+cCMOVqaUDhkNzvYo6WTzog@mail.gmail.com>

On Mon, Jan 11, 2016 at 2:33 PM, Nicholas Braden <nicholas11braden at gmail.com
> wrote:

> Doesn't biicode already fill this role? Biicode seems to work well
> enough for me, anyway.
>
>
Biicode is dead.

There is a comparison with biicode here:
https://github.com/ruslo/hunter/issues/54

Having only CMake as a dependency is awesome!

I have tried once to reuse biicode's OpenSSL CMake files, I failed. So I
ended up
using perl and whatever OpenSSL needed to compile.

On the other hand hunter has only CMake as dependency, which means that its
CMake scripts are very portable.

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160111/0287a650/attachment.html>

From ruslan_baratov at yahoo.com  Mon Jan 11 08:49:36 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Mon, 11 Jan 2016 20:49:36 +0700
Subject: [CMake] CMake based package manager
In-Reply-To: <loom.20160111T123849-813@post.gmane.org>
References: <53A84A03.9040500@yahoo.com>
 <loom.20160111T123849-813@post.gmane.org>
Message-ID: <5693B2F0.3030105@yahoo.com>

On 11-Jan-16 18:42, Cristian Adam wrote:
> Ruslan Baratov via CMake <cmake at ...> writes:
>
>> Hi,
>>
>> I'm developing a project that is a kind of wrapper of
>> ExternalProject_Add and
>> allow it to be more reusable. User interface is quite simple.
>>
>> For anybody interested, here is a github project:
>>
>> * https://github.com/ruslo/hunter
> Recently posted on reddit:
> https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
> e_manager_for_c/
>
> Any thoughts of including such a project in CMake?
Just for your information there is no need to include all this project, 
the entry point to everything is HunterGate.cmake module (500 lines of 
CMake code): 
https://github.com/hunter-packages/gate/blob/master/cmake/HunterGate.cmake

I will be happy to add it to CMake's standard modules so users can avoid 
one copy/paste step, if CMake's team is interested.

Ruslo

From Alan.Burlison at oracle.com  Mon Jan 11 09:42:00 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 11 Jan 2016 14:42:00 +0000
Subject: [CMake] CMake incorrectly passes linker flags to ar
Message-ID: <5693BF38.4070206@oracle.com>

I've just moved from CMake 2.8.6 to 3.3.2 and creation of static 
libraries is now failing. I've localised the problem as far as the 
generated link.txt linker script. With 2.8 it begins with:

/usr/bin/ar cr target/usr/local/lib/libhadoop.a

with 3.3.2 it begins with:

/usr/bin/ar cq target/usr/local/lib/libhadoop.a -m64

The "-m64" flag is used to tell the compiler/linker to create 64-bit 
executables and is set via the following CMake variables:

CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS

However "-m64" is not a valid "ar" flag. I haven't been able to find 
exactly how the linker flags are transmogrified into ar flags but I did 
find the following in Modules/CMakeCXXInformation.cmake:

if(NOT DEFINED CMAKE_CXX_ARCHIVE_CREATE)
   set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> cq <TARGET> <LINK_FLAGS> 
<OBJECTS>")
endif()

But I'm struggling to understand when passing in linker flags to ar 
*ever* makes sense, at least on *nix platforms. And that code seems to 
be the same in 2.8.6 and 3.3.2 so it doesn't explain why the incorrect 
flags to ar have appeared in 3.3.2.

This looks like a bug to me...

-- 
Alan Burlison
--

From brad.king at kitware.com  Mon Jan 11 10:26:56 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 11 Jan 2016 10:26:56 -0500
Subject: [CMake] CMake incorrectly passes linker flags to ar
In-Reply-To: <5693BF38.4070206@oracle.com>
References: <5693BF38.4070206@oracle.com>
Message-ID: <5693C9C0.109@kitware.com>

On 01/11/2016 09:42 AM, Alan Burlison wrote:
> The "-m64" flag is used to tell the compiler/linker to create 64-bit 
> executables and is set via the following CMake variables:
> 
> CMAKE_EXE_LINKER_FLAGS
> CMAKE_SHARED_LINKER_FLAGS
> CMAKE_STATIC_LINKER_FLAGS

What is adding -m64 to CMAKE_STATIC_LINKER_FLAGS?  That value is indeed
meant to be used to pass flags to "ar" because CMake (for historical
reasons) abuses the term "linker" to refer to the archiver used for a
static library.

>    set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> cq <TARGET> <LINK_FLAGS> <OBJECTS>")
> 
> But I'm struggling to understand when passing in linker flags to ar 
> *ever* makes sense, at least on *nix platforms.

The name "LINK_FLAGS" is used as a placeholder there to share the
implementation with similar substitutions done in actual link line
generation.  See above about the naming.

The question here is what changed between 2.8.6 and 3.3.2 that causes
-m64 to start showing up in CMAKE_STATIC_LINKER_FLAGS.

-Brad


From Alan.Burlison at oracle.com  Mon Jan 11 10:49:13 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 11 Jan 2016 15:49:13 +0000
Subject: [CMake] CMake incorrectly passes linker flags to ar
In-Reply-To: <5693C9C0.109@kitware.com>
References: <5693BF38.4070206@oracle.com> <5693C9C0.109@kitware.com>
Message-ID: <5693CEF9.6080406@oracle.com>

On 11/01/2016 15:26, Brad King wrote:

> What is adding -m64 to CMAKE_STATIC_LINKER_FLAGS?  That value is indeed
> meant to be used to pass flags to "ar" because CMake (for historical
> reasons) abuses the term "linker" to refer to the archiver used for a
> static library.

That's been added by in a CMakeLists.txt via an include of a common 
cmake script for setting up the per-platform compilation flags.

https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/HadoopCommon.cmake

elseif(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
     # Solaris flags. 64-bit compilation is mandatory, and is checked 
earlier.
     hadoop_add_compiler_flags("-m64 -D__EXTENSIONS__ 
-D_POSIX_PTHREAD_SEMANTICS -D_XOPEN_SOURCE=500")
     hadoop_add_linker_flags("-m64")

which calls:

# Add flags to all the CMake compiler variables
macro(hadoop_add_compiler_flags FLAGS)
     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${FLAGS}")
     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${FLAGS}")
endmacro()

# Add flags to all the CMake linker variables
macro(hadoop_add_linker_flags FLAGS)
     set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${FLAGS}")
     set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${FLAGS}")
     set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} ${FLAGS}")
endmacro()

So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and 
CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are 
CMAKE_STATIC_LINKER_FLAGS only ever used with ar?

>> But I'm struggling to understand when passing in linker flags to ar
>> *ever* makes sense, at least on *nix platforms.
>
> The name "LINK_FLAGS" is used as a placeholder there to share the
> implementation with similar substitutions done in actual link line
> generation.  See above about the naming.
>
> The question here is what changed between 2.8.6 and 3.3.2 that causes
> -m64 to start showing up in CMAKE_STATIC_LINKER_FLAGS.

Yes indeed, if I'd been able to figure that out I think I'd have been 
able to figure out how to change the CMake macros to get round the problem.

It's not the only problem I have hit with CMake's Solaris support, see 
for example 
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/HadoopCommon.cmake#L194

# CMAKE_SYSTEM_PROCESSOR is set to the output of 'uname -p', which on 
Solaris is
# the 'lowest' ISA supported, i.e. 'i386' or 'sparc'. However in order 
for the
# standard CMake modules to look in the right places it needs to reflect 
the required
# compilation mode, i.e. 64 bit. We therefore force it to either 'amd64' 
or 'sparcv9'.

There seems to be an assumption baked into CMake that if the underlying 
OS is *nix and is 32-bit then all executables that run on it are 32 bit 
and if it is 64-bit then all the executables are 64-bit as well, so 
looking at 'uname -p' is sufficient to determine the type of executables 
that should be produced. Unfortunately that's not correct for either 
Solaris or Linux.

Thanks,

-- 
Alan Burlison
--

From brad.king at kitware.com  Mon Jan 11 11:13:11 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 11 Jan 2016 11:13:11 -0500
Subject: [CMake] CMake incorrectly passes linker flags to ar
In-Reply-To: <5693CEF9.6080406@oracle.com>
References: <5693BF38.4070206@oracle.com> <5693C9C0.109@kitware.com>
 <5693CEF9.6080406@oracle.com>
Message-ID: <5693D497.9090209@kitware.com>

On 01/11/2016 10:49 AM, Alan Burlison wrote:
> So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and 
> CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are 
> CMAKE_STATIC_LINKER_FLAGS only ever used with ar?

Yes and yes.  Actually adding -m64 to CMAKE_{C,CXX}_FLAGS may be
enough because IIRC CMake uses those when invoking the C or C++
compiler front-end for linking a shared library or executable.

> There seems to be an assumption baked into CMake that if the underlying 
> OS is *nix and is 32-bit then all executables that run on it are 32 bit 
> and if it is 64-bit then all the executables are 64-bit as well, so 
> looking at 'uname -p' is sufficient to determine the type of executables 
> that should be produced. Unfortunately that's not correct for either 
> Solaris or Linux.

Very few decisions are actually made based on CMAKE_SYSTEM_PROCESSOR.
Most platform tuning is done based on the compiler id detection results
which uses the actual toolchain.  For example, CMAKE_SIZEOF_VOID_P is
set to the data pointer size detected from the toolchain target.

If you're not adding -m64 to the CMAKE_{C,CXX}_FLAGS until after the
top-level project() command enables the C and CXX languages then it is
too late for those flags to affect the detected target architecture.

-Brad


From Alan.Burlison at oracle.com  Mon Jan 11 11:53:53 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 11 Jan 2016 16:53:53 +0000
Subject: [CMake] CMake incorrectly passes linker flags to ar
In-Reply-To: <5693D497.9090209@kitware.com>
References: <5693BF38.4070206@oracle.com> <5693C9C0.109@kitware.com>
 <5693CEF9.6080406@oracle.com> <5693D497.9090209@kitware.com>
Message-ID: <5693DE21.30402@oracle.com>

On 11/01/2016 16:13, Brad King wrote:

> On 01/11/2016 10:49 AM, Alan Burlison wrote:
>> So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and
>> CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are
>> CMAKE_STATIC_LINKER_FLAGS only ever used with ar?
>
> Yes and yes.  Actually adding -m64 to CMAKE_{C,CXX}_FLAGS may be
> enough because IIRC CMake uses those when invoking the C or C++
> compiler front-end for linking a shared library or executable.

Thanks, I've removed -m64 from CMAKE_STATIC_LINKER_FLAGS and with 3.3.2 
on Solaris it fixes the problem, I'll ring the changes on the other 
platforms and with 2.8.6 and make sure it still works elsewhere.

>> There seems to be an assumption baked into CMake that if the underlying
>> OS is *nix and is 32-bit then all executables that run on it are 32 bit
>> and if it is 64-bit then all the executables are 64-bit as well, so
>> looking at 'uname -p' is sufficient to determine the type of executables
>> that should be produced. Unfortunately that's not correct for either
>> Solaris or Linux.
>
> Very few decisions are actually made based on CMAKE_SYSTEM_PROCESSOR.
> Most platform tuning is done based on the compiler id detection results
> which uses the actual toolchain.  For example, CMAKE_SIZEOF_VOID_P is
> set to the data pointer size detected from the toolchain target.

ISTR part of the issue at least was in the bowels of the CMake FindJNI 
module, that makes extensive use of CMAKE_SYSTEM_PROCESSOR.

> If you're not adding -m64 to the CMAKE_{C,CXX}_FLAGS until after the
> top-level project() command enables the C and CXX languages then it is
> too late for those flags to affect the detected target architecture.

The Hadoop CMakeLists.txt files don't use a PROJECT() command. The CMake 
docs say if you don't do so then an implicit PROJECT() is added that 
selects the C & C++ languages, is that done before processing any other 
commands in CMakeLists.txt? If so then from what you say it seems 
setting CMAKE_{C,CXX}_FLAGS wouldn't have any effect, which is probably 
why it has been done via CMAKE_EXE_LINKER_FLAGS etc.

-- 
Alan Burlison
--

From brad.king at kitware.com  Mon Jan 11 12:48:39 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 11 Jan 2016 12:48:39 -0500
Subject: [CMake] CMake incorrectly passes linker flags to ar
In-Reply-To: <5693DE21.30402@oracle.com>
References: <5693BF38.4070206@oracle.com> <5693C9C0.109@kitware.com>
 <5693CEF9.6080406@oracle.com> <5693D497.9090209@kitware.com>
 <5693DE21.30402@oracle.com>
Message-ID: <5693EAF7.4060008@kitware.com>

On 01/11/2016 11:53 AM, Alan Burlison wrote:
> ISTR part of the issue at least was in the bowels of the CMake FindJNI 
> module, that makes extensive use of CMAKE_SYSTEM_PROCESSOR.

That is not representative of CMake in general.  If there is a better
way for FindJNI to get the information it needs then it would be great
to have needed changes contributed.

> The Hadoop CMakeLists.txt files don't use a PROJECT() command. The CMake 
> docs say if you don't do so then an implicit PROJECT() is added that 
> selects the C & C++ languages, is that done before processing any other 
> commands in CMakeLists.txt?

Yes, the implicit project() call is inserted on line zero of the top-level
CMakeLists.txt file.  This feature is meant to help people get started
with hello-world projects and is not meant for use by mature projects.
The top-level CMakeLists.txt file of a "real" project should start with

 cmake_minimum_required(VERSION ...)
 project(MyProject)

Flags affecting the target architecture are typically expected to be
provided by the user calling CMake, not by project code, and so will
be set before languages are enabled by this project() command.

-Brad


From mike.jackson at bluequartz.net  Mon Jan 11 12:58:09 2016
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 11 Jan 2016 12:58:09 -0500
Subject: [CMake] FORTRAN name mangling
Message-ID: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>

I am trying to integrate a FORTRAN library into our C++ project. I have
used the following in our CMakeLists.txt file:

include(CMakeAddFortranSubdirectory)

cmake_add_fortran_subdirectory(src
  NO_EXTERNAL_INSTALL
  PROJECT EMSoftLib  # project name in toplevel CMakeLists.txt in lapack
  LIBRARIES EMSoftLib # target libraries created
  LINK_LIBRARIES blas lapack # link interface libraries
  LINK_LIBS EMSoftLib blas lapack
)

include(FortranCInterface)
FortranCInterface_HEADER(EMsoftLib_Mangling.h MACRO_NAMESPACE "EMSOFTLIB_")

So far so good.

In the FORTRAN code we have the following declaration for a subroutine we
want to use from the "C" side of things:

subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e,
mLPNH, mLPSH) bind(c, name='SingleEBSDPattern')

In order to access that function we created the following header file:


#include "EMsoftLib_Mangling.h"
#ifdef __cplusplus
extern "C" {
#endif
void EMSOFTLIB_GLOBAL(SingleEBSDPattern, SINGLEEBSDPATTERN)
(size_t* ipar, float* fpar, float* EBSDpattern,
float* quats, float* accum_e, float* mLPNH, float* mLPSH);
#ifdef __cplusplus
}
#endif

and we call the function from our C code like the following:


SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

When we compile we get the following linker error:

MintDevVM:Build mdg$ make
[ 40%] Built target EMSoftLib
Scanning dependencies of target SingleEBSDPattern
[ 41%] Building CXX object
src/CMakeFiles/SingleEBSDPattern.dir/SingleEBSDPattern.cpp.o
[ 42%] Linking CXX executable ../Bin/SingleEBSDPattern
Undefined symbols for architecture x86_64:
  "_SingleEBSDPattern_", referenced from:
      _main in SingleEBSDPattern.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [Bin/SingleEBSDPattern] Error 1
make[1]: *** [src/CMakeFiles/SingleEBSDPattern.dir/all] Error 2
make: *** [all] Error 2

We can not seem to find any good examples of trying this sort of C->FORTRAN
interfacing with CMake besides http://www.kitware.com/blog/home/post/231

We are using gfortran 5.3 on OS X 10.10.5 with Xcode 7.2 tools.

Any insights would be most appreciated.

__________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160111/ec563400/attachment.html>

From bill at classdesign.com  Mon Jan 11 13:11:42 2016
From: bill at classdesign.com (Bill Somerville)
Date: Mon, 11 Jan 2016 18:11:42 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
Message-ID: <5693F05E.6060305@classdesign.com>

On 11/01/2016 17:58, Michael Jackson wrote:
> subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e, 
> mLPNH, mLPSH) bind(c, name='SingleEBSDPattern')
>
Surely if you use bind(C) you need do no more than extern "C" the 
declaration when compiling C++. I thought bind(C) meant mangle the 
external name in the same way that a C module would.

We use the FortranCInterface module for old Fortran procedures that are 
not using ISO_C_BINDING and bind(C), for them we add the symbols to the 
FortranCInterface_HEADER() command and use the generated macros to 
reference the symbols in C/C++.

We also execute FortranCInterface_VERIFY(CXX QUIET) before the 
FortranCInterface_HEADERS() command.

It all works OK but we only use gcc/g++/Clang/Clang++/gfortran compilers.

Regards
Bill Somerville.

From bill at classdesign.com  Mon Jan 11 13:13:09 2016
From: bill at classdesign.com (Bill Somerville)
Date: Mon, 11 Jan 2016 18:13:09 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
Message-ID: <5693F0B5.2020602@classdesign.com>

On 11/01/2016 17:58, Michael Jackson wrote:
> and we call the function from our C code like the following:
>
>
> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>
You need to use the macros here too.

Regards
Bill Somerville.

From mike.jackson at bluequartz.net  Mon Jan 11 13:48:29 2016
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 11 Jan 2016 13:48:29 -0500
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <5693F0B5.2020602@classdesign.com>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
 <5693F0B5.2020602@classdesign.com>
Message-ID: <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>

Actually, 
  If we just use the following:

SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

and the same declaration in a .h file then we can link and execute just fine. My question now would be:

Do other FORTRAN compilers support this ?bind(C)? thing, such as Intel Fortran? If so then I can really NOT worry about figuring out the mangling that is needed and just declare the functions in a C style header like normal. No macros needed.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net

> On Jan 11, 2016, at 1:13 PM, Bill Somerville <bill at classdesign.com> wrote:
> 
> On 11/01/2016 17:58, Michael Jackson wrote:
>> and we call the function from our C code like the following:
>> 
>> 
>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>> 
> You need to use the macros here too.
> 
> Regards
> Bill Somerville.
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 bill at classdesign.com  Mon Jan 11 14:04:01 2016
From: bill at classdesign.com (Bill Somerville)
Date: Mon, 11 Jan 2016 19:04:01 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
 <5693F0B5.2020602@classdesign.com>
 <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>
Message-ID: <5693FCA1.6090402@classdesign.com>

On 11/01/2016 18:48, Michael Jackson wrote:
> Do other FORTRAN compilers support this ?bind(C)? thing
I can only vouch for gfortran but yes that is the idea.

Regards
Bill Somerville.

From mike.jackson at bluequartz.net  Mon Jan 11 14:10:55 2016
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 11 Jan 2016 14:10:55 -0500
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <0a254ee1cd7a42918cba79fbda477054@EXG13-P-MBX09.win.lanl.gov>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
 <5693F0B5.2020602@classdesign.com>
 <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>
 <0a254ee1cd7a42918cba79fbda477054@EXG13-P-MBX09.win.lanl.gov>
Message-ID: <072965F2-D6EF-483B-B742-DC5401D73E14@bluequartz.net>

So if I require Fortran 2003 for our fortran codes then this whole ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to actually worry about it at all for our project. Just have to keep the C header consistent with the FORTRAN functions, but that part is on our devs.

--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net

> On Jan 11, 2016, at 2:06 PM, Thompson, KT <kgt at lanl.gov> wrote:
> 
> "bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims to support this standard should work for you.
> 
> I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also use the Portland Group (12+) and IBM Fortran (v14) compilers this way.
> 
> -kt
> 
> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Michael Jackson
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville <bill at classdesign.com>
> Cc: cmake at cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
> 
> Actually, 
>  If we just use the following:
> 
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
> 
> and the same declaration in a .h file then we can link and execute just fine. My question now would be:
> 
> Do other FORTRAN compilers support this ?bind(C)? thing, such as Intel Fortran? If so then I can really NOT worry about figuring out the mangling that is needed and just declare the functions in a C style header like normal. No macros needed.
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jackson at bluequartz.net
> 
>> On Jan 11, 2016, at 1:13 PM, Bill Somerville <bill at classdesign.com> wrote:
>> 
>> On 11/01/2016 17:58, Michael Jackson wrote:
>>> and we call the function from our C code like the following:
>>> 
>>> 
>>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>>> 
>> You need to use the macros here too.
>> 
>> Regards
>> Bill Somerville.
>> -- 
>> 


From kgt at lanl.gov  Mon Jan 11 14:06:48 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Mon, 11 Jan 2016 19:06:48 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
 <5693F0B5.2020602@classdesign.com>
 <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>
Message-ID: <0a254ee1cd7a42918cba79fbda477054@EXG13-P-MBX09.win.lanl.gov>

"bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims to support this standard should work for you.

I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also use the Portland Group (12+) and IBM Fortran (v14) compilers this way.

-kt

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Michael Jackson
Sent: Monday, January 11, 2016 11:48 AM
To: Bill Somerville <bill at classdesign.com>
Cc: cmake at cmake.org
Subject: Re: [CMake] FORTRAN name mangling

Actually, 
  If we just use the following:

SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

and the same declaration in a .h file then we can link and execute just fine. My question now would be:

Do other FORTRAN compilers support this ?bind(C)? thing, such as Intel Fortran? If so then I can really NOT worry about figuring out the mangling that is needed and just declare the functions in a C style header like normal. No macros needed.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net

> On Jan 11, 2016, at 1:13 PM, Bill Somerville <bill at classdesign.com> wrote:
> 
> On 11/01/2016 17:58, Michael Jackson wrote:
>> and we call the function from our C code like the following:
>> 
>> 
>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>> 
> You need to use the macros here too.
> 
> Regards
> Bill Somerville.
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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  Mon Jan 11 14:24:00 2016
From: kgt at lanl.gov (Thompson, KT)
Date: Mon, 11 Jan 2016 19:24:00 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <072965F2-D6EF-483B-B742-DC5401D73E14@bluequartz.net>
References: <CAEqXkzeZvYy+G4G4QVKuKReXg1yOmzASzWuGyQNGtpvHGXaHWA@mail.gmail.com>
 <5693F0B5.2020602@classdesign.com>
 <78EB5943-8E36-4898-90C3-DA0B73496D73@bluequartz.net>
 <0a254ee1cd7a42918cba79fbda477054@EXG13-P-MBX09.win.lanl.gov>
 <072965F2-D6EF-483B-B742-DC5401D73E14@bluequartz.net>
Message-ID: <424e1cfab9464a95ae3f0693daccb622@EXG13-P-MBX09.win.lanl.gov>

Michael,

You should always test your toolchain first.  Compilers are often buggy or may not fully support a language feature.  But yes, requiring F2003 should address your concern.

-kt

-----Original Message-----
From: Michael Jackson [mailto:mike.jackson at bluequartz.net] 
Sent: Monday, January 11, 2016 12:11 PM
To: Thompson, KT <kgt at lanl.gov>
Cc: cmake at cmake.org
Subject: Re: [CMake] FORTRAN name mangling

So if I require Fortran 2003 for our fortran codes then this whole ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to actually worry about it at all for our project. Just have to keep the C header consistent with the FORTRAN functions, but that part is on our devs.

--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net

> On Jan 11, 2016, at 2:06 PM, Thompson, KT <kgt at lanl.gov> wrote:
> 
> "bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims to support this standard should work for you.
> 
> I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also use the Portland Group (12+) and IBM Fortran (v14) compilers this way.
> 
> -kt
> 
> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Michael Jackson
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville <bill at classdesign.com>
> Cc: cmake at cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
> 
> Actually, 
>  If we just use the following:
> 
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
> 
> and the same declaration in a .h file then we can link and execute just fine. My question now would be:
> 
> Do other FORTRAN compilers support this ?bind(C)? thing, such as Intel Fortran? If so then I can really NOT worry about figuring out the mangling that is needed and just declare the functions in a C style header like normal. No macros needed.
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jackson at bluequartz.net
> 
>> On Jan 11, 2016, at 1:13 PM, Bill Somerville <bill at classdesign.com> wrote:
>> 
>> On 11/01/2016 17:58, Michael Jackson wrote:
>>> and we call the function from our C code like the following:
>>> 
>>> 
>>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>>> 
>> You need to use the macros here too.
>> 
>> Regards
>> Bill Somerville.
>> -- 
>> 


From nicholas11braden at gmail.com  Mon Jan 11 14:26:26 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Mon, 11 Jan 2016 13:26:26 -0600
Subject: [CMake] CMake based package manager
In-Reply-To: <CA+u+m-+rBsGGbgLVNMQ13JKnpf8+cCMOVqaUDhkNzvYo6WTzog@mail.gmail.com>
References: <53A84A03.9040500@yahoo.com>
 <loom.20160111T123849-813@post.gmane.org>
 <CAHk1PgGB5W+7xax5SHXom-6-+iTNDSNOYS-i2FfFybDznXYp6g@mail.gmail.com>
 <CA+u+m-+rBsGGbgLVNMQ13JKnpf8+cCMOVqaUDhkNzvYo6WTzog@mail.gmail.com>
Message-ID: <CAHk1PgFLQs5pJ2FTccGQ+kefGf6HfKbAK=+8NUuYFDHi8CckKg@mail.gmail.com>

Hh, sorry, I should have found that myself! This definitely looks
interesting, and I agree that not requiring an external program like
Biicode is a good idea. Thanks for sharing this, I will try it out
when I have time :)

On Mon, Jan 11, 2016 at 7:40 AM, Cristian Adam <cristian.adam at gmail.com> wrote:
> On Mon, Jan 11, 2016 at 2:33 PM, Nicholas Braden
> <nicholas11braden at gmail.com> wrote:
>>
>> Doesn't biicode already fill this role? Biicode seems to work well
>> enough for me, anyway.
>>
>
> Biicode is dead.
>
> There is a comparison with biicode here:
> https://github.com/ruslo/hunter/issues/54
>
> Having only CMake as a dependency is awesome!
>
> I have tried once to reuse biicode's OpenSSL CMake files, I failed. So I
> ended up
> using perl and whatever OpenSSL needed to compile.
>
> On the other hand hunter has only CMake as dependency, which means that its
> CMake scripts are very portable.
>
> Cheers,
> Cristian.
>
>

From zbeekman at gmail.com  Mon Jan 11 14:31:25 2016
From: zbeekman at gmail.com (Zaak Beekman)
Date: Mon, 11 Jan 2016 19:31:25 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <mailman.1103.1452539460.8420.cmake@cmake.org>
References: <mailman.1103.1452539460.8420.cmake@cmake.org>
Message-ID: <CAAbnBwbz1e5UAC-BTDwqyASsu5r6ZfhHPH4H4492Gw6s4Kyjvw@mail.gmail.com>

> So if I require Fortran 2003 for our fortran codes then this whole
> ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to
> actually worry about it at all for our project. Just have to keep the C
> header consistent with the FORTRAN functions, but that part is on our devs.
>

Exactly, that is the whole point of the standardized `ISO_C_BINDING` module
and C interop being added to the Fortran 2003 standard. No more ugly guess
work, hackery, etc.

AFAIK, there is pretty good support for this among compiler vendors, so
long as you have a recent release. I know for sure GCC's gfortran and
Intel's ifort support this very well. I'm pretty sure PGI, Cray and IBM
support it too. I have never used NAG, so I withhold comment there, but I'd
be surprised if they had yet to add this to their compiler. The demand for
C interop is really high, and almost all of these companies make companion
C compilers, so, in my experience, they have been relatively quick to
implement these features, while some other Fortran 2003 and later features
have languished. (I'm looking at you, parameterized derived types...)

Happy hacking!

P.S. Unless you want to sound like an old geezer, it's spelled Fortran
these days, not FORTRAN. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160111/082d9c2f/attachment.html>

From bill.hoffman at kitware.com  Mon Jan 11 14:36:47 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 11 Jan 2016 14:36:47 -0500
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <CAAbnBwbz1e5UAC-BTDwqyASsu5r6ZfhHPH4H4492Gw6s4Kyjvw@mail.gmail.com>
References: <mailman.1103.1452539460.8420.cmake@cmake.org>
 <CAAbnBwbz1e5UAC-BTDwqyASsu5r6ZfhHPH4H4492Gw6s4Kyjvw@mail.gmail.com>
Message-ID: <5694044F.3010108@kitware.com>

On 1/11/2016 2:31 PM, Zaak Beekman wrote:
> Happy hacking!
FYI:
There is a longer version of that blog found here:
http://www.netlib.org/lapack/lawnspdf/lawn270.pdf
bind(c) sounds like a good idea if your compilers support it.

-Bill


From damian at sourceryinstitute.org  Mon Jan 11 14:57:56 2016
From: damian at sourceryinstitute.org (Damian Rouson)
Date: Mon, 11 Jan 2016 11:57:56 -0800
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <CAAbnBwbz1e5UAC-BTDwqyASsu5r6ZfhHPH4H4492Gw6s4Kyjvw@mail.gmail.com>
References: <mailman.1103.1452539460.8420.cmake@cmake.org>
 <CAAbnBwbz1e5UAC-BTDwqyASsu5r6ZfhHPH4H4492Gw6s4Kyjvw@mail.gmail.com>
Message-ID: <391D088C-2FEC-48B0-95E0-AB13D86CC8D5@sourceryinstitute.org>


> On Jan 11, 2016, at 11:31 AM, Zaak Beekman <zbeekman at gmail.com> wrote:
> 
> 
> So if I require Fortran 2003 for our fortran codes then this whole ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to actually worry about it at all for our project. Just have to keep the C header consistent with the FORTRAN functions, but that part is on our devs.
> 
> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module and C interop being added to the Fortran 2003 standard. No more ugly guess work, hackery, etc.
> 
> AFAIK, there is pretty good support for this among compiler vendors, so long as you have a recent release.

Even as far back as about five years ago, all 10 compilers surveyed by Ian Chivers and Jane Sleightholme supported C interoperability.  And now there are at least four compilers that even support the _additional_ C interoperability features in the draft Fortran 2015 standard: the IBM, Cray, Intel, and GNU compilers.  C interoperability appears to be one of the first things every compiler team tackles from a new standard.

Anyone with access to ACM Fortran Forum will benefit from consulting the standards-support survey that Ian and Jane have published in almost every issue for roughly a decade or so.  Standards support in  Fortran compilers is not quite where it needs to be, but it?s much better than it was even just a couple of years ago. Great strides have been taken.

> I know for sure GCC's gfortran and Intel's ifort support this very well. I'm pretty sure PGI, Cray and IBM support it too. I have never used NAG, so I withhold comment there, but I'd be surprised if they had yet to add this to their compiler. The demand for C interop is really high, and almost all of these companies make companion C compilers, so, in my experience, they have been relatively quick to implement these features, while some other Fortran 2003 and later features have languished. (I'm looking at you, parameterized derived types?)

PDT is one of the few Fortran 2003 features for which support is still a bit limited, but it is supported by at lest four compilers: IBM, Cray, Intel, and Portland Group, all of which are fully Fortran 2003 compliant.  I would bet that NAG will have it soon and GNU will likely have it in their development branch sometime later this year.  A developer has already put a great deal of work into scoping out the effort.  PDTs are a monster to implement in a compiler.

> 
> P.S. Unless you want to sound like an old geezer, it's spelled Fortran these days, not FORTRAN. ;-)

And the standard has spelled it in mixed case at least since Fortran 90 so, in addition to being dated, spelling FORTRAN in all-caps is non-standard. 

:D

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

From Alan.Burlison at oracle.com  Mon Jan 11 16:21:28 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 11 Jan 2016 21:21:28 +0000
Subject: [CMake] CMake incorrectly passes linker flags to ar
In-Reply-To: <5693EAF7.4060008@kitware.com>
References: <5693BF38.4070206@oracle.com> <5693C9C0.109@kitware.com>
 <5693CEF9.6080406@oracle.com> <5693D497.9090209@kitware.com>
 <5693DE21.30402@oracle.com> <5693EAF7.4060008@kitware.com>
Message-ID: <56941CD8.4040401@oracle.com>

On 11/01/2016 17:48, Brad King wrote:

> That is not representative of CMake in general.  If there is a better
> way for FindJNI to get the information it needs then it would be great
> to have needed changes contributed.

The Hadoop CMake infrastructure contains pretty much a complete rewrite 
of the JNI detection code for Linux, on other platforms it seems to be 
possible to get away with just tweaking things slightly before calling 
the standard CMake JNI module. The problem of course is all the 
cross-platform testing any wholesale rewrite would entail...

>> The Hadoop CMakeLists.txt files don't use a PROJECT() command. The CMake
>> docs say if you don't do so then an implicit PROJECT() is added that
>> selects the C & C++ languages, is that done before processing any other
>> commands in CMakeLists.txt?
>
> Yes, the implicit project() call is inserted on line zero of the top-level
> CMakeLists.txt file.  This feature is meant to help people get started
> with hello-world projects and is not meant for use by mature projects.
> The top-level CMakeLists.txt file of a "real" project should start with
>
>   cmake_minimum_required(VERSION ...)
>   project(MyProject)
>
> Flags affecting the target architecture are typically expected to be
> provided by the user calling CMake, not by project code, and so will
> be set before languages are enabled by this project() command.

That's not the way CMake is used for building Hadoop, CMake is called by 
Ant and/or Maven, users don't call CMake directly. I suspect that's not 
too uncommon, when CMake is used to build just the native components of 
a larger platform-independent system.

-- 
Alan Burlison
--

From taylor at braun-jones.org  Mon Jan 11 16:47:03 2016
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Mon, 11 Jan 2016 16:47:03 -0500
Subject: [CMake] Why does INTERFACE type targets only support
	whitelisted properties?
In-Reply-To: <568FC3C1.50803@gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
 <568FB358.9060005@gmail.com>
 <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>
 <568FC3C1.50803@gmail.com>
Message-ID: <CAKfKJYvAKEdwXGkad6+eJiYbBkOw0GkCvenAiRm076kZ01Wv9w@mail.gmail.com>

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz <nilsgladitz at gmail.com> wrote:

>
>
> On 01/08/2016 02:50 PM, Yves Frederix wrote:
>
>> You are explicitly mentioning 'setting' of a property. IMHO there is a
>> big difference between setting and getting a property. If
>> white/blacklisting is enforced during setting only, wouldn't this be
>> sufficient? This would make it possible to simply access all
>> properties that are automatically assigned to the target (which I
>> assume implies that by definition they should make sense?). A
>> non-acceptable property could not have been set and would hence not be
>> found, making it possible to check for its existence in the "standard"
>> way.
>>
>
> The same argument might hold for getting of properties.
> E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties
> now but was implemented in the future.
>
> A user might e.g. think that a specific property should work because CMake
>>> did not issue any diagnostics and open an issue.
>>> The diagnostic implies that this behavior is by design.
>>>
>>> It also prevents users from using existing properties which currently
>>> don't
>>> have semantics for INTERFACE targets but might be implemented in the
>>> future
>>> (potentially with different semantics than expected by the user).
>>>
>> Ok, this somehow contradicts my above assumption and is somewhat
>> surprising. Wouldn't it make sense to simply not set these properties
>> in the first place if they have incorrect semantics? This way,
>> get_property would not need to care about them and it would anyhow not
>> stop their correct implementation in the future.
>>
>
> I meant existing as in defined for regular build targets not as in
> actually set for interface targets.
> get_property() would return an empty string for those if they weren't
> whitelisted and one might argue that this could suffice.
> On the other hand users often assume that they get a valid value and don't
> actually check.
>
>
>>> I think allowing custom (non cmake defined) properties might be a valid
>>> argument.
>>> These could perhaps also be supported through e.g. user extension of the
>>> whitelist.
>>>
>> I like this idea. With this in place, one would not need to wait for a
>> new CMake release if a valid property were missing from the whitelist
>> or if one wanted to use custom properties.
>>
>> I don't think anything should be changed however unless there are actual
>>> use
>>> cases that aren't supported by the current implementation.
>>>
>> Does this mean that you would have doubts about patches that:
>>   - provide a way for the user to extend the whitelist?
>>   - remove the need for whitelisting in get_property by making CMake
>> only automatically assign sensible target properties?
>>
>
> The issue is less that CMake assigns these properties (I don't know of any
> such case but I haven't checked) and more that users might just expect them
> to be set (which does not provide a diagnostic).
>
> Personally I would not object to either approach as long as there are
> actual use cases.
> Without use cases such changes would be by definition useless.


I have another INTERFACE property use case that is not whitelisted, but
should be: VERSION

Consider library project Foo that uses a header-only project Bar. In
FooConfig.cmake, it is a important to ensure any projects using Foo also
use the exact same version of Bar that Foo was originally built with
(Failure to do so can lead to subtle, hard-to-find bugs like violation of
the one definition rule). Assuming project Bar creates an imported target
"Bar" with a VERSION property set like:

  set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Then project Foo should be able to have something like:

== CMakeLists.txt ==
...
get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)

== FooConfig.cmake.in ==
...
find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

But, alas, this is not currently possible. I'm ambivalent about whether
INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
but at least this VERSION property seems valid to allow.

Taylor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160111/4fa4474a/attachment.html>

From steveire at gmail.com  Mon Jan 11 17:16:49 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 11 Jan 2016 23:16:49 +0100
Subject: [CMake] Why does INTERFACE type targets only support
	whitelisted properties?
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
 <568FB358.9060005@gmail.com>
 <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>
 <568FC3C1.50803@gmail.com>
 <CAKfKJYvAKEdwXGkad6+eJiYbBkOw0GkCvenAiRm076kZ01Wv9w@mail.gmail.com>
Message-ID: <n719kh$kvu$1@ger.gmane.org>

Taylor Braun-Jones wrote:

> Consider library project Foo that uses a header-only project Bar. In
> FooConfig.cmake, it is a important to ensure any projects using Foo also
> use the exact same version of Bar that Foo was originally built with

COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use 
case. 

You would populate an INTERFACE_ property on the INTERFACE target, which is 
whitelisted already:

 https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties

 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813

Thanks,

Steve.



From david at zemon.name  Mon Jan 11 19:15:21 2016
From: david at zemon.name (David Zemon)
Date: Tue, 12 Jan 2016 00:15:21 +0000
Subject: [CMake] Determine Verbosity in Custom Language Scripts
Message-ID: <CAGs=--RtHc1YAOKpEWkgX=ct0kCjX8wab92hhSW4CY5juDQ0KQ@mail.gmail.com>

I've defined a custom language for my project which is simply a wrapper
around GCC. The "compiler" for this language is a CMake script which
invokes g++ followed by objcopy. I would like to use CMake's standard
verbosity system - either VERBOSE=1 for Unix Makefiles or -v or Ninja
(maybe there are others too?) but I don't know how. I was previously doing
something like

```
if (ENV{VERBOSE})
  message("g++ ${SOURCE}")
endif ()
execute_process(COMMAND g++ ${SOURCE})
```

but Ninja doesn't set an environment variable. Is it possible do this?

Thank you,
David Zemon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160112/fb89b2a5/attachment.html>

From Arjen.Markus at deltares.nl  Tue Jan 12 03:04:01 2016
From: Arjen.Markus at deltares.nl (Arjen Markus)
Date: Tue, 12 Jan 2016 08:04:01 +0000
Subject: [CMake] FORTRAN name mangling
In-Reply-To: <391D088C-2FEC-48B0-95E0-AB13D86CC8D5@sourceryinstitute.org>
References: <mailman.1103.1452539460.8420.cmake@cmake.org>
 <CAAbnBwbz1e5UAC-BTDwqyASsu5r6ZfhHPH4H4492Gw6s4Kyjvw@mail.gmail.com>
 <391D088C-2FEC-48B0-95E0-AB13D86CC8D5@sourceryinstitute.org>
Message-ID: <8CF085736108634681FD03EC36E6A0724C20BD6D@V-EXC-C02.DIRECTORY.INTRA>

> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module and C interop being added to the Fortran 2003 standard. No more ugly guess work, hackery, etc.

> AFAIK, there is pretty good support for this among compiler vendors, so long as you have a recent release.

> Even as far back as about five years ago, all 10 compilers surveyed by Ian Chivers and Jane Sleightholme supported C interoperability.  And now there are at least four compilers that even support the _additional_ C interoperability features in the draft Fortran 2015 standard: the IBM, Cray, Intel, and GNU compilers.  C interoperability appears to be one of the first things every compiler team tackles from a new standard.

> Anyone with access to ACM Fortran Forum will benefit from consulting the standards-support survey that Ian and Jane have published in almost every issue for roughly a decade or so.  Standards support in  Fortran compilers is not quite where it needs to be, but it's much better than it was even just a couple of years ago. Great strides have been taken.

Just to chime in here, in the PLplot project (plplot.sf.net) we are currently reimplementing the Fortran interface to the plotting routines that have been implemented in C. The previous version took advantage of all Fortran 90/95 features, such as function overloading and assumed-shape arrays to avoid the extra arguments needed to tell the plotting routines how many elements there are. This required quite a lot of C code, as the naming conventions/name mangling had to be handled on the C side.

The new set-up however uses the ISO_C_BINDING features to the fullest extent. The benefits of this new set-up are plenty:

- We can support single and double precision versions of the routines in one library, whereas before we had to rely on the Fortran programs using the same precision as the C library. This could have been done with just the Fortran 90/95 features too - just a matter of progressive insight.

- Almost all C code has been eliminated as matching the names of the routines can now be done on the Fortran side. The advantage of that is that the Fortran compiler is completely responsible for this, rather than a set of confusing C macros the details of which depend on the Fortran compiler.

Of course, this means that you have to have the ability to adjust the Fortran code, but for a given library, you could simply write a Fortran interface layer that uses the ISO_C_BINDING features instead of a C one.

Regards,

Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

From mohammedrashadkm at gmail.com  Tue Jan 12 05:21:06 2016
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Tue, 12 Jan 2016 11:21:06 +0100
Subject: [CMake] Update/Set _expectedTargets inside exports-release.cmake.
Message-ID: <CANNqv9e+p6fYOFfkm0Y-Fxphx8QLR6hiLzyhF1ry9kFFLi8fJQ@mail.gmail.com>

Hello all,

Is it possible to update or set the "_expectedTargets" cmake variable
inside the exports.cmake or exports-release.cmake file

I know this file is autogenerated and it generates all so files and use
cmake add_library IMPROTED option etc..

I have an issue with this method.

Lets say, I have 3 so files(libCore, libCommon, libGui)  in Project1

when i have the export() call inside the root cmakelists of project1., I
get all three inside my export file.

Here is part from Project1Exports.cmake file.

# Loop over all imported files and verify that they actually exist
foreach(target ${_IMPORT_CHECK_TARGETS} )
  foreach(file ${_IMPORT_CHECK_FILES_FOR_${target}} )
    if(NOT EXISTS "${file}" )
      message(FATAL_ERROR "The imported target \"${target}\" references the
file
   \"${file}\"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   \"${CMAKE_CURRENT_LIST_FILE}\"
but not all the files it references.
")
    endif()
  endforeach()
  unset(_IMPORT_CHECK_FILES_FOR_${target})
endforeach()
unset(_IMPORT_CHECK_TARGETS)


Now if I do find_package(project1 REQUIRED COMPONENTS libCore)

which will find the Project1Config.cmake and that include the
Project1Exports.cmake

Now if I have only installed one or two component cmake will fail with
below message.
"The imported target \"${target}\" references the file
   \"${file}\"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   \"${CMAKE_CURRENT_LIST_FILE}\"
but not all the files it references.
"

I am having this when I build packages for debian where I split components
into separate packages project1-core, project1-gui etc..

The only option so far is to do an in-place sed and change FATAL_ERROR to
STATUS. But I would prefer a cmake solution.

I propose to have:

foreach(target ${_IMPORT_CHECK_TARGETS} )
  foreach(file ${_IMPORT_CHECK_FILES_FOR_${target}} )
    if(NOT EXISTS "${file}" )

##add a check to see if the target is listed in the components argument of
##find_package. If there is no components specified, the it must check all
targets like now.

      message(FATAL_ERROR "The imported target \"${target}\" references the
file
   \"${file}\"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   \"${CMAKE_CURRENT_LIST_FILE}\"
but not all the files it references.
")
    endif()
  endforeach()
  unset(_IMPORT_CHECK_FILES_FOR_${target})
endforeach()
unset(_IMPORT_CHECK_TARGETS)



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

From magnus at therning.org  Tue Jan 12 05:45:37 2016
From: magnus at therning.org (Magnus Therning)
Date: Tue, 12 Jan 2016 11:45:37 +0100
Subject: [CMake] C standard and order of arguments
Message-ID: <87egdnt6su.fsf@sobel.cipherstone.com>


I'm trying to turn on a bit more warnings in a C project but I'm running
into an ordering issue.

I have

#+BEGIN_SRC cmake
set(CMAKE_C_STANDARD 11)
set(CMAKE_C_FLAGS "-Wall -Wextra -Werror")
#+END_SRC

and I want to add ~-Wpedantic~. However if I do then I get a lot of warnings
(that are turned into errors) about breaking C99. In particular:

#+BEGIN_QUOTE
ISO C99 requires at least one argument for the "..." in a variadic macro [-Werror]
#+END_QUOTE

This apparently comes from ~-std=gnu11~ (the result of setting
~CMAKE_C_STANDARD~) appearing /after/ the other flags. If I change my
~CMakeLists.txt~ to instead contain

#+BEGIN_SRC cmake
set(CMAKE_C_FLAGS "-std=gnu11 -Wall -Wextra -Wpedantic -Werror")
#+END_SRC

Then I don't get those C99-related warnings. Is there some way to get
~CMAKE_C_STANDARD~ to put ~-std=gnu11~ /before/ the other flags?

/M

--
Magnus Therning              OpenPGP: 0x927912051716CE39
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

LeBlanc's law: Later equals never.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160112/df1e4f6d/attachment.sig>

From tom.kacvinsky at vectorcast.com  Tue Jan 12 09:58:14 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Tue, 12 Jan 2016 09:58:14 -0500
Subject: [CMake] How to get generated dependencies
Message-ID: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>

Is there a way of invoking cmake to get the list of non-system header
dependencies, like invoking gcc with -MMD?  I need to find out the
list of non-system header dependencies and I know cmake has a way of
doing this, I just need to know if there is command I can put in the
CMakeLists.txt file to get this information...

Thanks,

Tom

From steveire at gmail.com  Tue Jan 12 14:58:55 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 12 Jan 2016 20:58:55 +0100
Subject: [CMake] Update/Set _expectedTargets inside
	exports-release.cmake.
References: <CANNqv9e+p6fYOFfkm0Y-Fxphx8QLR6hiLzyhF1ry9kFFLi8fJQ@mail.gmail.com>
Message-ID: <n73ltv$82c$1@ger.gmane.org>

Rashad Kanavath wrote:

> I am having this when I build packages for debian where I split components
> into separate packages project1-core, project1-gui etc..

I think you need to patch the buildsystems of the software you are packaging 
so that they support that kind of split by exporting to a different export-
set per split component.

ie:

install(TARGETS project1-core EXPORT CoreExports ...)
install(TARGETS project1-gui EXPORT GuiExports ...)
install(TARGETS project1-network EXPORT NetworkExports ...)

and put conditional includes for the resulting files in the 
Project1Config.cmake file.

Thanks,

Steve.



From vania.joloboff at inria.fr  Wed Jan 13 09:25:19 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Wed, 13 Jan 2016 15:25:19 +0100
Subject: [CMake] test endian ness
Message-ID: <56965E4F.1040603@inria.fr>

Hi

I am familiar with autoconf and trying to migrate our project to cmake.
Thus newbie. I am running cmake 3.2.2 on Linux Mint 17

I have seen in the documentation the macro
https://cmake.org/cmake/help/v3.2/module/TestBigEndian.html?highlight=endian#module:TestBigEndian

which seems very convenient for our purpose.
I have added to my CMakeLists.txt

TEST_BIG_ENDIAN(HOST_IS_BIG_ENDIAN)

But when I run
 > cmake -G "Unix Makefiles"

I get

CMake Error at CMakeLists.txt:11 (TEST_BIG_ENDIAN):
   Unknown CMake command "TEST_BIG_ENDIAN".

What am I missing ?

Thanks for clues...



From marc.chevrier at sap.com  Wed Jan 13 09:39:01 2016
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Wed, 13 Jan 2016 14:39:01 +0000
Subject: [CMake] test endian ness
In-Reply-To: <56965E4F.1040603@inria.fr>
References: <56965E4F.1040603@inria.fr>
Message-ID: <3AF68F36-DF68-4C41-8C22-B82B3F081FBB@sap.com>


Hi,

May be to include the module before using it:

include (TestBigEndian)




On 13/01/16 15:25, "CMake on behalf of Vania Joloboff" <cmake-bounces at cmake.org on behalf of vania.joloboff at inria.fr> wrote:

>Hi
>
>I am familiar with autoconf and trying to migrate our project to cmake.
>Thus newbie. I am running cmake 3.2.2 on Linux Mint 17
>
>I have seen in the documentation the macro
>https://cmake.org/cmake/help/v3.2/module/TestBigEndian.html?highlight=endian#module:TestBigEndian
>
>which seems very convenient for our purpose.
>I have added to my CMakeLists.txt
>
>TEST_BIG_ENDIAN(HOST_IS_BIG_ENDIAN)
>
>But when I run
> > cmake -G "Unix Makefiles"
>
>I get
>
>CMake Error at CMakeLists.txt:11 (TEST_BIG_ENDIAN):
>   Unknown CMake command "TEST_BIG_ENDIAN".
>
>What am I missing ?
>
>Thanks for clues...
>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/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 ben.boeckel at kitware.com  Wed Jan 13 10:54:11 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 13 Jan 2016 10:54:11 -0500
Subject: [CMake] [cmake-developers] Why does INTERFACE type targets only
 support whitelisted properties?
In-Reply-To: <CAKfKJYvAKEdwXGkad6+eJiYbBkOw0GkCvenAiRm076kZ01Wv9w@mail.gmail.com>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
 <568FB358.9060005@gmail.com>
 <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>
 <568FC3C1.50803@gmail.com>
 <CAKfKJYvAKEdwXGkad6+eJiYbBkOw0GkCvenAiRm076kZ01Wv9w@mail.gmail.com>
Message-ID: <20160113155411.GA30728@megas.kitware.com>

On Mon, Jan 11, 2016 at 16:47:03 -0500, Taylor Braun-Jones wrote:
> I have another INTERFACE property use case that is not whitelisted, but
> should be: VERSION

VERSION is a special property for libraries. Particularly the name for
the file with the actual content of the library (the SOVERSION and name
of the library being symlinks to it):

    https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html

INTERFACE targets have no need for this property.

> Consider library project Foo that uses a header-only project Bar. In
> FooConfig.cmake, it is a important to ensure any projects using Foo also
> use the exact same version of Bar that Foo was originally built with
> (Failure to do so can lead to subtle, hard-to-find bugs like violation of
> the one definition rule). Assuming project Bar creates an imported target
> "Bar" with a VERSION property set like:
> 
>   set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Also, this property is not a list (probably?), so APPEND isn't really
correct. It indicates that the value here should be (list-)appended to
the existing value.

> Then project Foo should be able to have something like:
> 
> == CMakeLists.txt ==
> ...
> get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
> configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)
> 
> == FooConfig.cmake.in ==
> ...
> find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

find_package(Foo) should set a Foo_VERSION variable (if known):

    https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-version-file

> But, alas, this is not currently possible. I'm ambivalent about whether
> INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
> but at least this VERSION property seems valid to allow.

Currently, they are whitelisted, but I think any property not understood
by CMake directly (i.e., user-set properties) would probably be fine.

--Ben

From tom.kacvinsky at vectorcast.com  Wed Jan 13 13:26:53 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Wed, 13 Jan 2016 13:26:53 -0500
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
Message-ID: <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>

On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
<tom.kacvinsky at vectorcast.com> wrote:
> Is there a way of invoking cmake to get the list of non-system header
> dependencies, like invoking gcc with -MMD?  I need to find out the
> list of non-system header dependencies and I know cmake has a way of
> doing this, I just need to know if there is command I can put in the
> CMakeLists.txt file to get this information...

Is there any way of accessing the generated dependencies?  I know
there is a generation phase, but I don't think I can access the files
being generated during the generation process is.  Is there a way of
doing what I want?  All I need is a list of include included headers
(excluding system ones) for a given C++ file.

From d3ck0r at gmail.com  Wed Jan 13 14:09:12 2016
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 13 Jan 2016 11:09:12 -0800
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
Message-ID: <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>

The short answer is 'no'.

On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
<tom.kacvinsky at vectorcast.com> wrote:
> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
> <tom.kacvinsky at vectorcast.com> wrote:
>> Is there a way of invoking cmake to get the list of non-system header
>> dependencies, like invoking gcc with -MMD?  I need to find out the
>> list of non-system header dependencies and I know cmake has a way of
>> doing this, I just need to know if there is command I can put in the
>> CMakeLists.txt file to get this information...
>
> Is there any way of accessing the generated dependencies?  I know
> there is a generation phase, but I don't think I can access the files
> being generated during the generation process is.  Is there a way of
> doing what I want?  All I need is a list of include included headers
> (excluding system ones) for a given C++ file.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 tom.kacvinsky at vectorcast.com  Wed Jan 13 14:20:00 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Wed, 13 Jan 2016 14:20:00 -0500
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
Message-ID: <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>

On Wed, Jan 13, 2016 at 2:09 PM, J Decker <d3ck0r at gmail.com> wrote:

> The short answer is 'no'.

I see depends.internal was generated with the gcc (in my case) option
-MD (or perhaps -MDD).  Ss cmake knows how to do this.  Question: is
this at build time or Makefile generation time?  If the latter, it
would be nice if this could be exposed to the user

> On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
> <tom.kacvinsky at vectorcast.com> wrote:
>> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
>> <tom.kacvinsky at vectorcast.com> wrote:
>>> Is there a way of invoking cmake to get the list of non-system header
>>> dependencies, like invoking gcc with -MMD?  I need to find out the
>>> list of non-system header dependencies and I know cmake has a way of
>>> doing this, I just need to know if there is command I can put in the
>>> CMakeLists.txt file to get this information...
>>
>> Is there any way of accessing the generated dependencies?  I know
>> there is a generation phase, but I don't think I can access the files
>> being generated during the generation process is.  Is there a way of
>> doing what I want?  All I need is a list of include included headers
>> (excluding system ones) for a given C++ file.

From j.s4403 at gmail.com  Wed Jan 13 14:31:54 2016
From: j.s4403 at gmail.com (j s)
Date: Wed, 13 Jan 2016 13:31:54 -0600
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
Message-ID: <5696A62A.6030202@gmail.com>

 From what I remember from the mailing list a long time ago, CMake has 
its own dependency generator independent of the CPP.

On 1/13/16 1:20 PM, Tom Kacvinsky wrote:
> On Wed, Jan 13, 2016 at 2:09 PM, J Decker <d3ck0r at gmail.com> wrote:
>
>> The short answer is 'no'.
> I see depends.internal was generated with the gcc (in my case) option
> -MD (or perhaps -MDD).  Ss cmake knows how to do this.  Question: is
> this at build time or Makefile generation time?  If the latter, it
> would be nice if this could be exposed to the user
>
>> On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
>> <tom.kacvinsky at vectorcast.com> wrote:
>>> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>> Is there a way of invoking cmake to get the list of non-system header
>>>> dependencies, like invoking gcc with -MMD?  I need to find out the
>>>> list of non-system header dependencies and I know cmake has a way of
>>>> doing this, I just need to know if there is command I can put in the
>>>> CMakeLists.txt file to get this information...
>>> Is there any way of accessing the generated dependencies?  I know
>>> there is a generation phase, but I don't think I can access the files
>>> being generated during the generation process is.  Is there a way of
>>> doing what I want?  All I need is a list of include included headers
>>> (excluding system ones) for a given C++ file.


From d3ck0r at gmail.com  Wed Jan 13 14:39:19 2016
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 13 Jan 2016 11:39:19 -0800
Subject: [CMake] How to get generated dependencies
In-Reply-To: <5696A62A.6030202@gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
Message-ID: <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>

On Wed, Jan 13, 2016 at 11:31 AM, j s <j.s4403 at gmail.com> wrote:
> From what I remember from the mailing list a long time ago, CMake has its
> own dependency generator independent of the CPP.
>
it does; but not for all generators
>
> On 1/13/16 1:20 PM, Tom Kacvinsky wrote:
>>
>> On Wed, Jan 13, 2016 at 2:09 PM, J Decker <d3ck0r at gmail.com> wrote:
>>
>>> The short answer is 'no'.
>>
>> I see depends.internal was generated with the gcc (in my case) option
>> -MD (or perhaps -MDD).  Ss cmake knows how to do this.  Question: is
>> this at build time or Makefile generation time?  If the latter, it
>> would be nice if this could be exposed to the user
>>
>>> On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>
>>>> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>
>>>>> Is there a way of invoking cmake to get the list of non-system header
>>>>> dependencies, like invoking gcc with -MMD?  I need to find out the
>>>>> list of non-system header dependencies and I know cmake has a way of
>>>>> doing this, I just need to know if there is command I can put in the
>>>>> CMakeLists.txt file to get this information...
>>>>
>>>> Is there any way of accessing the generated dependencies?  I know
>>>> there is a generation phase, but I don't think I can access the files
>>>> being generated during the generation process is.  Is there a way of
>>>> doing what I want?  All I need is a list of include included headers
>>>> (excluding system ones) for a given C++ file.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 tom.kacvinsky at vectorcast.com  Wed Jan 13 14:59:13 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Wed, 13 Jan 2016 14:59:13 -0500
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
Message-ID: <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>

I suppose what I could do is get the target properties for the
compiler flags (will this include compiler defines and include
directories?), add -MDD -c (using gcc, so those are the options I
want) to the compiler flags and make a custom command to generate the
file, then post process it to get the list of includes.  But the
question I have is how do I generate a list from a text file? In the
end I need a list of header files I can include in a development kit I
am creating.

On Wed, Jan 13, 2016 at 2:39 PM, J Decker <d3ck0r at gmail.com> wrote:
> On Wed, Jan 13, 2016 at 11:31 AM, j s <j.s4403 at gmail.com> wrote:
>> From what I remember from the mailing list a long time ago, CMake has its
>> own dependency generator independent of the CPP.
>>
> it does; but not for all generators
>>
>> On 1/13/16 1:20 PM, Tom Kacvinsky wrote:
>>>
>>> On Wed, Jan 13, 2016 at 2:09 PM, J Decker <d3ck0r at gmail.com> wrote:
>>>
>>>> The short answer is 'no'.
>>>
>>> I see depends.internal was generated with the gcc (in my case) option
>>> -MD (or perhaps -MDD).  Ss cmake knows how to do this.  Question: is
>>> this at build time or Makefile generation time?  If the latter, it
>>> would be nice if this could be exposed to the user
>>>
>>>> On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>
>>>>> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
>>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>>
>>>>>> Is there a way of invoking cmake to get the list of non-system header
>>>>>> dependencies, like invoking gcc with -MMD?  I need to find out the
>>>>>> list of non-system header dependencies and I know cmake has a way of
>>>>>> doing this, I just need to know if there is command I can put in the
>>>>>> CMakeLists.txt file to get this information...
>>>>>
>>>>> Is there any way of accessing the generated dependencies?  I know
>>>>> there is a generation phase, but I don't think I can access the files
>>>>> being generated during the generation process is.  Is there a way of
>>>>> doing what I want?  All I need is a list of include included headers
>>>>> (excluding system ones) for a given C++ file.
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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 tom.kacvinsky at vectorcast.com  Wed Jan 13 15:00:45 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Wed, 13 Jan 2016 15:00:45 -0500
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
Message-ID: <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>

Should have read the docs before I asked that last question:
file(STRINGS ...) is what I want

On Wed, Jan 13, 2016 at 2:59 PM, Tom Kacvinsky
<tom.kacvinsky at vectorcast.com> wrote:
> I suppose what I could do is get the target properties for the
> compiler flags (will this include compiler defines and include
> directories?), add -MDD -c (using gcc, so those are the options I
> want) to the compiler flags and make a custom command to generate the
> file, then post process it to get the list of includes.  But the
> question I have is how do I generate a list from a text file? In the
> end I need a list of header files I can include in a development kit I
> am creating.
>
> On Wed, Jan 13, 2016 at 2:39 PM, J Decker <d3ck0r at gmail.com> wrote:
>> On Wed, Jan 13, 2016 at 11:31 AM, j s <j.s4403 at gmail.com> wrote:
>>> From what I remember from the mailing list a long time ago, CMake has its
>>> own dependency generator independent of the CPP.
>>>
>> it does; but not for all generators
>>>
>>> On 1/13/16 1:20 PM, Tom Kacvinsky wrote:
>>>>
>>>> On Wed, Jan 13, 2016 at 2:09 PM, J Decker <d3ck0r at gmail.com> wrote:
>>>>
>>>>> The short answer is 'no'.
>>>>
>>>> I see depends.internal was generated with the gcc (in my case) option
>>>> -MD (or perhaps -MDD).  Ss cmake knows how to do this.  Question: is
>>>> this at build time or Makefile generation time?  If the latter, it
>>>> would be nice if this could be exposed to the user
>>>>
>>>>> On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
>>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>>
>>>>>> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
>>>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>>>
>>>>>>> Is there a way of invoking cmake to get the list of non-system header
>>>>>>> dependencies, like invoking gcc with -MMD?  I need to find out the
>>>>>>> list of non-system header dependencies and I know cmake has a way of
>>>>>>> doing this, I just need to know if there is command I can put in the
>>>>>>> CMakeLists.txt file to get this information...
>>>>>>
>>>>>> Is there any way of accessing the generated dependencies?  I know
>>>>>> there is a generation phase, but I don't think I can access the files
>>>>>> being generated during the generation process is.  Is there a way of
>>>>>> doing what I want?  All I need is a list of include included headers
>>>>>> (excluding system ones) for a given C++ file.
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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 d3ck0r at gmail.com  Wed Jan 13 15:24:12 2016
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 13 Jan 2016 12:24:12 -0800
Subject: [CMake] How to get generated dependencies
In-Reply-To: <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
 <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
Message-ID: <CAA2GJqXVx6A_idR0fPLbg=kqutALOwjkN-5tHPbc38xkCAKc=Q@mail.gmail.com>

Or reorganize your project so your includes aren't all scattered and
just INSTALL(DIRECTORY include )


On Wed, Jan 13, 2016 at 12:00 PM, Tom Kacvinsky
<tom.kacvinsky at vectorcast.com> wrote:
> Should have read the docs before I asked that last question:
> file(STRINGS ...) is what I want
>
> On Wed, Jan 13, 2016 at 2:59 PM, Tom Kacvinsky
> <tom.kacvinsky at vectorcast.com> wrote:
>> I suppose what I could do is get the target properties for the
>> compiler flags (will this include compiler defines and include
>> directories?), add -MDD -c (using gcc, so those are the options I
>> want) to the compiler flags and make a custom command to generate the
>> file, then post process it to get the list of includes.  But the
>> question I have is how do I generate a list from a text file? In the
>> end I need a list of header files I can include in a development kit I
>> am creating.
>>
>> On Wed, Jan 13, 2016 at 2:39 PM, J Decker <d3ck0r at gmail.com> wrote:
>>> On Wed, Jan 13, 2016 at 11:31 AM, j s <j.s4403 at gmail.com> wrote:
>>>> From what I remember from the mailing list a long time ago, CMake has its
>>>> own dependency generator independent of the CPP.
>>>>
>>> it does; but not for all generators
>>>>
>>>> On 1/13/16 1:20 PM, Tom Kacvinsky wrote:
>>>>>
>>>>> On Wed, Jan 13, 2016 at 2:09 PM, J Decker <d3ck0r at gmail.com> wrote:
>>>>>
>>>>>> The short answer is 'no'.
>>>>>
>>>>> I see depends.internal was generated with the gcc (in my case) option
>>>>> -MD (or perhaps -MDD).  Ss cmake knows how to do this.  Question: is
>>>>> this at build time or Makefile generation time?  If the latter, it
>>>>> would be nice if this could be exposed to the user
>>>>>
>>>>>> On Wed, Jan 13, 2016 at 10:26 AM, Tom Kacvinsky
>>>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>>>
>>>>>>> On Tue, Jan 12, 2016 at 9:58 AM, Tom Kacvinsky
>>>>>>> <tom.kacvinsky at vectorcast.com> wrote:
>>>>>>>>
>>>>>>>> Is there a way of invoking cmake to get the list of non-system header
>>>>>>>> dependencies, like invoking gcc with -MMD?  I need to find out the
>>>>>>>> list of non-system header dependencies and I know cmake has a way of
>>>>>>>> doing this, I just need to know if there is command I can put in the
>>>>>>>> CMakeLists.txt file to get this information...
>>>>>>>
>>>>>>> Is there any way of accessing the generated dependencies?  I know
>>>>>>> there is a generation phase, but I don't think I can access the files
>>>>>>> being generated during the generation process is.  Is there a way of
>>>>>>> doing what I want?  All I need is a list of include included headers
>>>>>>> (excluding system ones) for a given C++ file.
>>>>
>>>>
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more
>>>> information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/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 clinton at elemtech.com  Wed Jan 13 22:52:44 2016
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Wed, 13 Jan 2016 20:52:44 -0700
Subject: [CMake] CMAKE_INSTALL_RPATH_USE_LINK_PATH is broken?
In-Reply-To: <CAC_jL3yJFX4tkK3RRYFjn_meezjLzEPs=4ji-veBe6C-PZSG5A@mail.gmail.com>
Message-ID: <62e82656-8138-4137-aef5-5c77cb0902a8@email.android.com>


On Jan 8, 2016 8:16 PM, Elizabeth Fischer <rpf2116 at columbia.edu> wrote:
>
> Hello,
>
> I'm using cmake 3.4.1.? I'm trying to compile libraries & executables with an RPATH.? To that end, I use the following settings:
>>
>>
>> SET(CMAKE_SKIP_BUILD_RPATH ?FALSE)
>> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
>> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>
>
> I then link in a lot of libraries.? However, ONLY ONE of the libraries gets picked up to be used in the RPATH sent to the linker.? I can manually set CMAKE_INSTALL_RPATH (that works).? But CMAKE_INSTALL_RPATH_USE_LINK_PATH seems to be broken.
>
> Interestingly, the one library it's willing to auto-generate an RPATH for is the same library, whether it comes first or last in the link command line.? The link command generated by CMake is shown below; it's clear that many libraries are being linked in, but only one rpath is being generated.


Did you check that the libraries you are linking against have an install name starting with @rpath?

For example, 
otool -D /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib

CMake will only consider adding an rpath for a library if the install name starts with @rpath.

Clint

>
> HELP!!!!?
> --- Elizabeth
>
>> [ 30%] Linking CXX executable test_array
>>
>> cd /Users/rpfische/git/spsparse/build/test && /Users/rpfische/macports/mpgompi-4.9.3/bin/cmake -E cmake_link_script CMakeFiles/test_array.dir/link.txt --verbose=1
>>
>> /Users/rpfische/macports/mpgompi-4.9.3/bin/g++ ? -g -Wl,-search_paths_first -Wl,-headerpad_max_install_names? CMakeFiles/test_array.dir/test_array.cpp.o? -o test_array? /Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest.a /Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest_main.a /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib /Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib /Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib ../slib/libspsparse.dylib /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib /Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib /Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib -Wl,-rpath,/Users/rpfische/eb/software/ibmisc/devel/lib?

From gurenchan at gmail.com  Thu Jan 14 02:25:02 2016
From: gurenchan at gmail.com (Owen Hogarth II)
Date: Thu, 14 Jan 2016 15:25:02 +0800
Subject: [CMake] using macros
Message-ID: <CALM2mE=Mwwh9O4t17dGq5_gxtiLH=8FvRpYjYO+wuUoK7DqM-w@mail.gmail.com>

I am trying to use a macro to enable c99 in some of my cmake modules.

In the top level cmake file I add this macro

macro(use_c99)
  if (CMAKE_VERSION VERSION_LESS "3.1")
    if (CMAKE_C_COMPILER_ID STREQUAL "GNU")
      set (CMAKE_C_FLAGS "--std=gnu99 ${CMAKE_C_FLAGS}")
    endif ()
  else ()
    set (CMAKE_C_STANDARD 99)
  endif ()
endmacro(use_c99)

then in another CMakeLists.txt file I add
use_c99()

but I get this error:

CMake Error at source/internal_src/cube/CMakeLists.txt:1 (use_c
99):
  Unknown CMake command "use_c99".

why am I unable to use the macro? My main cmake is using 3.0.2 from debian
repository.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160114/8076e319/attachment.html>

From mohammedrashadkm at gmail.com  Thu Jan 14 03:20:20 2016
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Thu, 14 Jan 2016 09:20:20 +0100
Subject: [CMake] Update/Set _expectedTargets inside
	exports-release.cmake.
In-Reply-To: <n73ltv$82c$1@ger.gmane.org>
References: <CANNqv9e+p6fYOFfkm0Y-Fxphx8QLR6hiLzyhF1ry9kFFLi8fJQ@mail.gmail.com>
 <n73ltv$82c$1@ger.gmane.org>
Message-ID: <CANNqv9frekRv+zNSKuo6ZMRqQa=MvK9wzf9ipF1cJfdeWwwq7g@mail.gmail.com>

Hello Stephen,

On Tue, Jan 12, 2016 at 8:58 PM, Stephen Kelly <steveire at gmail.com> wrote:

> Rashad Kanavath wrote:
>
> > I am having this when I build packages for debian where I split
> components
> > into separate packages project1-core, project1-gui etc..
>
> I think you need to patch the buildsystems of the software you are
> packaging
> so that they support that kind of split by exporting to a different export-
> set per split component.
>
> ie:
>
> install(TARGETS project1-core EXPORT CoreExports ...)
> install(TARGETS project1-gui EXPORT GuiExports ...)
> install(TARGETS project1-network EXPORT NetworkExports ...)
>

Thanks for your reply. I will check with upstream if this is possible to
have such a modification.

If there is some cmake way without modifying upstream I would prefer that.


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



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

From petr.kmoch at gmail.com  Thu Jan 14 04:21:20 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 14 Jan 2016 10:21:20 +0100
Subject: [CMake] using macros
In-Reply-To: <CALM2mE=Mwwh9O4t17dGq5_gxtiLH=8FvRpYjYO+wuUoK7DqM-w@mail.gmail.com>
References: <CALM2mE=Mwwh9O4t17dGq5_gxtiLH=8FvRpYjYO+wuUoK7DqM-w@mail.gmail.com>
Message-ID: <CAKohaZeoK9CmR4gdiQiECgS2h+7kXUUGPUWMLUp4JsLOq2U4tA@mail.gmail.com>

Hi Owen.

As a sanity check, the definition of the macro in the toplevel CMakeList
comes *before* the add_subdirectory() command for the one which errors out,
right?

Petr

On Thu, Jan 14, 2016 at 8:25 AM, Owen Hogarth II <gurenchan at gmail.com>
wrote:

> I am trying to use a macro to enable c99 in some of my cmake modules.
>
> In the top level cmake file I add this macro
>
> macro(use_c99)
>   if (CMAKE_VERSION VERSION_LESS "3.1")
>     if (CMAKE_C_COMPILER_ID STREQUAL "GNU")
>       set (CMAKE_C_FLAGS "--std=gnu99 ${CMAKE_C_FLAGS}")
>     endif ()
>   else ()
>     set (CMAKE_C_STANDARD 99)
>   endif ()
> endmacro(use_c99)
>
> then in another CMakeLists.txt file I add
> use_c99()
>
> but I get this error:
>
> CMake Error at source/internal_src/cube/CMakeLists.txt:1 (use_c
> 99):
>   Unknown CMake command "use_c99".
>
> why am I unable to use the macro? My main cmake is using 3.0.2 from debian
> repository.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160114/6928d5b5/attachment-0001.html>

From vania.joloboff at inria.fr  Thu Jan 14 04:28:40 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 14 Jan 2016 10:28:40 +0100
Subject: [CMake] find_library
In-Reply-To: <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
 <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
Message-ID: <56976A48.9090200@inria.fr>

I am running cmake 3.2.2 on Linux 64 bits

I run cmake with

  cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/

In my CMakeLists.txt,

If I put

  find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
               PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)

it works.

If I put
  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
               PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)

which I think should be identical, I get error
CMake Error at CMakeLists.txt:28 (message):
   ERROR: SYSC_LIB-NOTFOUND

Can anyone explain the difference and why the second does not work ?

btw

find_library(SYSC_LIB NAMES systemc foobar PATHS "${SYSTEMC_PATH}"
                PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)

  also works
and
     find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
       PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64
       NO_DEFAULT_PATH)
also fails

At least it is consistent :-(

Thanx


From marc.chevrier at sap.com  Thu Jan 14 04:32:02 2016
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Thu, 14 Jan 2016 09:32:02 +0000
Subject: [CMake] find_library
In-Reply-To: <56976A48.9090200@inria.fr>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
 <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
 <56976A48.9090200@inria.fr>
Message-ID: <1494708D-4051-4934-9EDB-D47715BD8B00@sap.com>

Defining a variable using -D option does not put this one in the environment (i.e. system environment) so using ENV will fails...




On 14/01/16 10:28, "CMake on behalf of Vania Joloboff" <cmake-bounces at cmake.org on behalf of vania.joloboff at inria.fr> wrote:

>I am running cmake 3.2.2 on Linux 64 bits
>
>I run cmake with
>
>  cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/
>
>In my CMakeLists.txt,
>
>If I put
>
>  find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
>               PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>it works.
>
>If I put
>  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>               PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>which I think should be identical, I get error
>CMake Error at CMakeLists.txt:28 (message):
>   ERROR: SYSC_LIB-NOTFOUND
>
>Can anyone explain the difference and why the second does not work ?
>
>btw
>
>find_library(SYSC_LIB NAMES systemc foobar PATHS "${SYSTEMC_PATH}"
>                PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>  also works
>and
>     find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>       PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64
>       NO_DEFAULT_PATH)
>also fails
>
>At least it is consistent :-(
>
>Thanx
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/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 doublef.mobile at gmail.com  Thu Jan 14 07:06:19 2016
From: doublef.mobile at gmail.com (Sergey Zakharchenko)
Date: Thu, 14 Jan 2016 15:06:19 +0300
Subject: [CMake] Fwd: FILE(UPLOAD) doesn't seem to respect custom CA
 settings while DOWNLOAD does
In-Reply-To: <CADYCxoOQ57OpyUO+PeUx0yB-isBVzoZgcMqNuvzkwcFHVY8mSw@mail.gmail.com>
References: <CADYCxoOQ57OpyUO+PeUx0yB-isBVzoZgcMqNuvzkwcFHVY8mSw@mail.gmail.com>
Message-ID: <CADYCxoM5Btx3CLqnAG4ESJLW0f4MtVmArMiEs-N=UmSxMNqS4Q@mail.gmail.com>

Hello,

I'm trying to get CMake to talk to an SSL server using a self-signed
certificate. It works just fine with downloads. The certificate path
appears in the LOG:

successfully set certificate verify locations:
  CAfile: /path/to/my/certificate.pem
  CApath: /etc/ssl/certs

and the TLS handshake succeeds. However, it doesn't seem to work with
UPLOAD (note CAfile is 'none'):

successfully set certificate verify locations:
  CAfile: none
  CApath: /etc/ssl/certs
SSLv3, TLS handshake, Client hello (1):
[512 bytes data]
SSLv3, TLS handshake, Server hello (2):
[66 bytes data]
SSLv3, TLS handshake, CERT (11):
[5986 bytes data]
SSLv3, TLS alert, Server hello (2):
[2 bytes data]
SSL certificate problem: self signed certificate in certificate chain

Neither setting CMAKE_TLS_CAINFO to point to the certificate, nor
adding a TLS_CAINFO argument work. Is there anything I'm missing?

I'm using CMake version 3.4.1.

Best regards,

--
DoubleF

From vania.joloboff at inria.fr  Thu Jan 14 11:44:22 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 14 Jan 2016 17:44:22 +0100
Subject: [CMake] finding if feature is supported by host
In-Reply-To: <56976A48.9090200@inria.fr>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
 <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
 <56976A48.9090200@inria.fr>
Message-ID: <5697D066.2010100@inria.fr>

Hi

I can find if an include file exists with CHECK_INCLUDE_FILE
But I want to know if a particular feature is supported
in our case we need to know if the mmap call exists
and whether it supports the MAP_ANONYMOUS feature
With autoconf, I can use AC_TRY_COMPILE to try compiling
a program using the feature.
Is there some equivalent in cmake ?

Or I have to build my own TRY_COMPILE command to check if a feature
is supported by a particular function call ?

Thanks



From petr.kmoch at gmail.com  Thu Jan 14 11:53:06 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 14 Jan 2016 17:53:06 +0100
Subject: [CMake] finding if feature is supported by host
In-Reply-To: <5697D066.2010100@inria.fr>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
 <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
 <56976A48.9090200@inria.fr> <5697D066.2010100@inria.fr>
Message-ID: <CAKohaZcVoNc8z2=kp-JvKDMVzr7qw81QTuH6HkLQfEJdYXwr5A@mail.gmail.com>

Hi Vania.

A quick look a CMake docs will show you CMake's try_compile() command:
https://cmake.org/cmake/help/latest/command/try_compile.html
(There is also a try_run(), if required).

I believe that's precisely what you want.

Petr

On Thu, Jan 14, 2016 at 5:44 PM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> Hi
>
> I can find if an include file exists with CHECK_INCLUDE_FILE
> But I want to know if a particular feature is supported
> in our case we need to know if the mmap call exists
> and whether it supports the MAP_ANONYMOUS feature
> With autoconf, I can use AC_TRY_COMPILE to try compiling
> a program using the feature.
> Is there some equivalent in cmake ?
>
> Or I have to build my own TRY_COMPILE command to check if a feature
> is supported by a particular function call ?
>
> Thanks
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160114/7d061692/attachment.html>

From chuck.atkins at kitware.com  Thu Jan 14 12:47:36 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 14 Jan 2016 12:47:36 -0500
Subject: [CMake] find_library
In-Reply-To: <56976A48.9090200@inria.fr>
References: <CAAEKttz+c-9Pdch_du03STPGfF=FoKfQTrLAsj=56dKYXDOTsQ@mail.gmail.com>
 <CAAEKttx0GiSa86a7dRwUWiCa-p48v_fqseuZS39QCroBdT+GGA@mail.gmail.com>
 <CAA2GJqVMPg7sBpBYA9v7waAiWe26B0Xm6_hkJ+DYW951pbphMA@mail.gmail.com>
 <CAAEKttzVFCLwMDnPnYZz=7d8-i6wwFcwS2B0x1uPhitXfyEoJw@mail.gmail.com>
 <5696A62A.6030202@gmail.com>
 <CAA2GJqVQzrCVZY7LNx1NwyBVx75=fnMLL4NmGxQjui6z16i6aw@mail.gmail.com>
 <CAAEKttxoKRs8_ww4Xz_3oHOFDR-1PECAi19St-3XWM_tbO99Hw@mail.gmail.com>
 <CAAEKttysxRzwmLyOVQ3_1t7V7u4Bcm0YXeEM3JyhdX7MyRbtYQ@mail.gmail.com>
 <56976A48.9090200@inria.fr>
Message-ID: <CAOXZzG7u65XWh1aReDbRv0hZjX_C=xpfLympd58npjNK3eUVgw@mail.gmail.com>

Hi Vania,

 find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
>               PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>

In this first call, SYSTEMC_PATH is being dereferenced as a CMake
variable.  This works because in your invocation of CMake:

cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/
>

You define the CMake variable with -D on the command line

 However, in your second call

>  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>               PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>

the PATHS ENV SYSTEMC_PATH arguments specify that SYSTEMC_PATH be
dereferenced as an environment variable, not a CMake variable.  This is
equivalent to PATHS "$ENV{SYSTEMC_PATH}"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160114/8fb40a4c/attachment.html>

From morris at maynidea.com  Thu Jan 14 15:02:55 2016
From: morris at maynidea.com (mozzis)
Date: Thu, 14 Jan 2016 13:02:55 -0700 (MST)
Subject: [CMake] Changing the  the current generator in CMake GUI
In-Reply-To: <lposk5$2iv$1@ger.gmane.org>
References: <lposk5$2iv$1@ger.gmane.org>
Message-ID: <1452801775327-7592486.post@n2.nabble.com>

I was able to edit CMakeCache.txt and CPackConfig.cmake (with CMake GUI
closed)
 I changed 
  CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 Win64 
to
  CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010

and then in general looked for the string "64" and made appropriate changes.
I then started CMake GUI, noted that the "Current Generator" was to my
liking, and did Configure and Generate steps again.

All in all, doesn't seem that it would be too hard for CMake devs to
implement a function to do this, but IMO Cmake is a mistake anyway, I only
use it when forced (e.g., OpenCV.) CMake butchers MS Visual Studio project
files, and makes it much harder to maintain projects that use it. Which I
guess is kind of the opposite of the intended effect. More intelligent use
of existing macros for both make and MSVS would go a long way to making it
useful.



--
View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592486.html
Sent from the CMake mailing list archive at Nabble.com.

From nicholas11braden at gmail.com  Thu Jan 14 15:57:22 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Thu, 14 Jan 2016 14:57:22 -0600
Subject: [CMake] How do I create targets first and add sources later?
Message-ID: <CAHk1PgFNh9VhEyWMujYJhdKisOUyUuiO11nGLcujgobGGvQbow@mail.gmail.com>

I often find it more convenient to call add_library() and
add_executable() first, apply properties to them etc., and then later
add the sources to them with target_sources() (usually in other CMake
files via add_subdirectory). Obviously, all my targets will eventually
have sources added.

However, CMake completely errors out as soon as it sees me creating a
target with no sources - it doesn't even care that I am adding sources
to it later. Example:
"You have called ADD_LIBRARY for library mylib without any source
files. This typically indicates a problem with your CMakeLists.txt
file"

I have been working around this by adding a dummy source file or
adding one of the sources ahead of time, but this is somewhat
inconvenient.

Is there a better way to do this? Alternatively, could CMake be
changed to allow creating a target that initially has no sources as
long as it eventually has sources added to it?

Note: I am familiar with the approach of gathering a list of source
files before creating the target, but this is really inconvenient to
do across multiple files in multiple directories. It is easier to call
target_sources() instead.

From bill.hoffman at kitware.com  Thu Jan 14 16:17:37 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Thu, 14 Jan 2016 16:17:37 -0500
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <1452801775327-7592486.post@n2.nabble.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com>
Message-ID: <56981071.4020802@kitware.com>

On 1/14/2016 3:02 PM, mozzis wrote:
> I was able to edit CMakeCache.txt and CPackConfig.cmake (with CMake GUI
> closed)
>   I changed
>    CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 Win64
> to
>    CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010
>
> and then in general looked for the string "64" and made appropriate changes.
> I then started CMake GUI, noted that the "Current Generator" was to my
> liking, and did Configure and Generate steps again.
You can not change the generator.  It is better to remove the entire 
build tree.  Out of source builds are a best practice with CMake.  Once 
a build tree has been configured with one compiler, it must be 
completely removed to change to a new compiler.  You are changing from 
32 bit to 64 bit, this means that all the try-compile stuff needs to be 
re-run as the answers are likely to be different.
>
> All in all, doesn't seem that it would be too hard for CMake devs to
> implement a function to do this, but IMO Cmake is a mistake anyway, I only
> use it when forced (e.g., OpenCV.) CMake butchers MS Visual Studio project
> files, and makes it much harder to maintain projects that use it. Which I
> guess is kind of the opposite of the intended effect. More intelligent use
> of existing macros for both make and MSVS would go a long way to making it
> useful.
Thanks for the praise...  :)   CMake creates VS projects that should 
work to build the project that is the goal. I don't understand about 
make and MSVS, CMake can create makefiles or ninja files if that is what 
you are talking about.

-Bill

From biddisco at cscs.ch  Thu Jan 14 16:51:23 2016
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Thu, 14 Jan 2016 21:51:23 +0000
Subject: [CMake] cdash/ctest question
Message-ID: <D2BDD6E9.973FC%biddisco@cscs.ch>

Apologies for posting a cdash question question to the cmake list?

CDash plots the run-time of tests, which is very useful indeed, but it would be even more useful if one could output a performance related ?time? from a test where a specific feature was being benchmarked and one could see how it changes over a period of days/weeks/months as changes to code are being made.
The time would be specific to the tested code and not include startup and other uninteresting overheads (such as when the filesystem is misbehaving and the test starts slowly).

Does such a feature exist in ctest/cdash at all?

Thanks

JB

--
John Biddiscombe,                        email:biddisco @.at.@ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82

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

From chadvernon at gmail.com  Thu Jan 14 17:07:23 2016
From: chadvernon at gmail.com (Chad Vernon)
Date: Thu, 14 Jan 2016 14:07:23 -0800
Subject: [CMake] Create both Windows UWP project and old Win32 console
 project in same solution.
Message-ID: <CAFi_QyxTGRF=zSH12+_nGEBR7fwga1S8qJE0qLx7mv2Qgfi3VQ@mail.gmail.com>

Hello,

Is there a way to create both a Windows UWP project and an old Win32
console project in same solution?  I have a toolchain file that sets
CMAKE_SYSTEM_NAME to WindowsStore in order to create the UWP project, but
then any other add_executable call will also create a Windows 10 project.

I want to add a Native C++ Unit Test project to the solution but it always
ends up as a Windows 10 project.  I tried setting CMAKE_SYSTEM_NAME for the
specific project, but it did not do anything.

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

From a.neundorf-work at gmx.net  Thu Jan 14 17:17:13 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Thu, 14 Jan 2016 23:17:13 +0100
Subject: [CMake] cdash/ctest question
In-Reply-To: <D2BDD6E9.973FC%biddisco@cscs.ch>
References: <D2BDD6E9.973FC%biddisco@cscs.ch>
Message-ID: <8703684.uaWUrAkQri@tuxedo.neundorf.net>

On Thursday, January 14, 2016 21:51:23 Biddiscombe, John A. wrote:
> Apologies for posting a cdash question question to the cmake list?
> 
> CDash plots the run-time of tests, which is very useful indeed, but it would
> be even more useful if one could output a performance related ?time? from a
> test where a specific feature was being benchmarked and one could see how
> it changes over a period of days/weeks/months as changes to code are being
> made.
> The time would be specific to the tested code and not include
> startup and other uninteresting overheads (such as when the filesystem is
> misbehaving and the test starts slowly). 
> Does such a feature exist in ctest/cdash at all?

yes, we do exactly that.

You have to generate <DartMeasurement> tags in the stdoutof the test
<DartMeasurement name="Simple" type="numeric/integer">42</DartMeasurement>
<DartMeasurement name="ExecutionTime" 
type="numeric/double">1.23456</DartMeasurement>

and then in cdash you can configure the tests-overview page to display certain 
such measurements by name, and on the tests page you can also display graphs 
for such named measurements.

Alex



From jamesbigler at gmail.com  Fri Jan 15 00:46:19 2016
From: jamesbigler at gmail.com (James Bigler)
Date: Fri, 15 Jan 2016 05:46:19 +0000
Subject: [CMake] Interesting behavior of MAIN_DEPENDENCY in makefiles
Message-ID: <CA+77nZDksxGfKs8_oJEv_KCGKK4PoHzLR3=U9dz28rzYNZhecQ@mail.gmail.com>

Say you have a simple cpp file:

cat > test.cpp
int main() { return 0; }

Then you have this as your CMakeLists.txt file:

set(input_file test.cpp)
set(generated_file
${CMAKE_CURRENT_BINARY_DIR}/${input_file}.blah${CMAKE_CXX_OUTPUT_EXTENSION})
add_custom_command(
  OUTPUT ${generated_file}
  COMMAND c++ -c ${CMAKE_CURRENT_SOURCE_DIR}/${input_file} -o
${generated_file}
  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${input_file}
  #DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${input_file}
  COMMENT "Building ${generated_file} using custom command."
  )
add_executable(test_b ${generated_file} ${input_file})
#add_executable(test_b ${generated_file} )
set_target_properties(test_b PROPERTIES LINKER_LANGUAGE CXX)

add_executable(test_cxx test.cpp)

If I put test.cpp as the MAIN_DEPENDENCY then add_executable(test_cxx
test.cpp) fails to compile an object file to link in.

If I change MAIN_DEPENDENCY to DEPENDS, then the add_executable(test_b
${generated_file} ${input_file}) will end up compiling test.cpp into an
object file twice (when it only did it once before).

Can anyone explain why this is so?  It seems like weird behavior.

Thanks,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160115/8ed671b1/attachment.html>

From jackie at sdiwc.info  Fri Jan 15 01:38:25 2016
From: jackie at sdiwc.info (Jackie Blanco)
Date: Thu, 14 Jan 2016 23:38:25 -0700
Subject: [CMake] Last Call for Papers: GCIRE2016 - Philippines
Message-ID: <2b2c025e4e5f5d0a22ffbf5bd732475c@sdiwc.info>

The Second International Conference on Green Computing, Intelligent and 
Renewable Energies (GCIRE2016)

University of Perpetual Help System DALTA
Las Pi?as-Manila, Philippines
February 24-26, 2016

http://sdiwc.net/conferences/gcire2016/
gcire16 at sdiwc.net
=======================================
The event will be held over three days with presentations delivered by 
researchers from the international community, including presentations 
from keynote speakers and state-of-the-art lectures. All registered 
papers will be included in the SDIWC Digital Library and in one of the 
following special issues:

- International Journal of Cyber-Security and Digital Forensics (IJCSDF)
- International Journal of Digital Information and Wireless 
Communications (IJDIWC)
- International Journal of New Computer Architectures and their 
Applications (IJNCAA)
- International Journal of E-Learning and Educational Technologies in 
the Digital Media (IJEETDM)

SUBMISSION GUIDELINES:

- Researchers are encouraged to submit their work electronically as pdf 
format without author(s) name.
- Full paper must be submitted (abstracts are not acceptable).
- Submitted paper should not exceed 15 pages, including illustrations 
and must be without page numbers.
- Paper submission link: 
http://sdiwc.net/conferences/gcire2016/paper-submission/

IMPORTANT DATES:

Submission Deadline:	January 24, 2016
Acceptance Notification:2-3 weeks from the submission date or Feb. 3, 
2016
Camera Ready Deadline:	February 14, 2016
Registration Deadline:	February  14, 2016
Conference Dates:	February  24 - 26, 2016

From thomas.lehmann at adtech.com  Fri Jan 15 03:05:21 2016
From: thomas.lehmann at adtech.com (Thomas Lehmann)
Date: Fri, 15 Jan 2016 09:05:21 +0100
Subject: [CMake] How to on multiple RPM packages
Message-ID: <CAEdhodzcoGz_GmWkdk=NxbXX8YAGp_q-0U4qrA=R5Bej-Gq+Hg@mail.gmail.com>

Hi,

We are currently looking forward to migrate to CMake and
we are struggling a bit with cpack.

The first project we migrate provides a executable binary but also
a library and its headers.

I do not find an example on how to provide separate RPM's
for them; one for the binary and one for the headers+library.
The required results (rough example):

- foo-1.2.3.4-1.x86_64.rpm
- libfoo-1.2.3.4-1.x86.64.rpm

Anybody who can help us with this?

Regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160115/4becbcde/attachment.html>

From eric.noulard at gmail.com  Fri Jan 15 05:36:02 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 15 Jan 2016 11:36:02 +0100
Subject: [CMake] How to on multiple RPM packages
In-Reply-To: <CAEdhodzcoGz_GmWkdk=NxbXX8YAGp_q-0U4qrA=R5Bej-Gq+Hg@mail.gmail.com>
References: <CAEdhodzcoGz_GmWkdk=NxbXX8YAGp_q-0U4qrA=R5Bej-Gq+Hg@mail.gmail.com>
Message-ID: <CAPASGLqf_t7_B1DsNiqfiUYsuxAnZrjywOm7kT70zTigyYKGtQ@mail.gmail.com>

Hi Thomas,

CPack RPM may generate several packages at once if you define COMPONENTS in
your project.

The behavior of CPackRPM w.r.t. COMPONENT packaging depends on

Some CPack COMPONENT generic variables, namelly:
CPACK_RPM_COMPONENT_INSTALL --> this one must be set to ON
CPACK_COMPONENTS_* variables
see: https://cmake.org/cmake/help/v3.4/module/CPackComponent.html

The bunch of RPM specific variables
CPACK_RPM_<component>_* variables
see  https://cmake.org/cmake/help/v3.4/module/CPackRPM.html

More references (some may be outdated) there:
https://cmake.org/Wiki/CMake:Component_Install_With_CPack
https://cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
http://cmake.3232098.n2.nabble.com/CPack-RPM-with-COMPONENTS-packaging-td7583729.html

2016-01-15 9:05 GMT+01:00 Thomas Lehmann <thomas.lehmann at adtech.com>:
>
> Hi,
>
> We are currently looking forward to migrate to CMake and
> we are struggling a bit with cpack.
>
> The first project we migrate provides a executable binary but also
> a library and its headers.
>
> I do not find an example on how to provide separate RPM's
> for them; one for the binary and one for the headers+library.
> The required results (rough example):
>
> - foo-1.2.3.4-1.x86_64.rpm
> - libfoo-1.2.3.4-1.x86.64.rpm
>
> Anybody who can help us with this?
>
> Regards,
> Thomas
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake




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

From domen.vrankar at gmail.com  Fri Jan 15 06:28:59 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 15 Jan 2016 12:28:59 +0100
Subject: [CMake] How to on multiple RPM packages
In-Reply-To: <CAEdhodwkkP7z-PTSNUwAz+7X0D0n3TiQezi1=ZbNgrtnxSa--Q@mail.gmail.com>
References: <CAEdhodzcoGz_GmWkdk=NxbXX8YAGp_q-0U4qrA=R5Bej-Gq+Hg@mail.gmail.com>
 <CAKgx6BJp1++ewMb3u_2d9JUv5gxQ+Dg-v3cxn3Jf3rNofN5RbA@mail.gmail.com>
 <CAEdhodwkkP7z-PTSNUwAz+7X0D0n3TiQezi1=ZbNgrtnxSa--Q@mail.gmail.com>
Message-ID: <CAKgx6BLgNygkBdtiWK8REJjD4kntWAHAw5iEggDo5Ww6==RrXw@mail.gmail.com>

Hm I've accidentally dropped cmake mailing list when replying
before... Sorry about that.

> Im using "bin" and "devel" as component names. I tried next with upper and
> lower case in the properties but no difference.
> it's about what you see in the RPM header using "rpm -qlip name.rpm" ...

Component name changing patch was already applied in git and will be
available in next CMake release.
Until then you could patch your CPackRPM.cmake file (comes with CMake
installation) with this patch:

https://cmake.org/gitweb?p=cmake.git;a=commit;h=c926efa


> a) Also it is documented .... CPACK_RPM_DEVEL_PACKAGE_DESCRIPTION has no
> effect I always get "This is an installer created using CPack
> (https://cmake.org). No additional installation instructions provided."
> b) Same for summary. I always get "NGSelector built using CMake"

It's possible that you are using an older version of CPack that
doesn't support this per component feature. This was introduced in
CPack version 3.2. Before only non component versions of description
of summary were supported.

> c) I cannot specify different groups like "Application" and "Library"?
Fix is the same patch as for name.


> d) Can I get rid of the "-bin" in the RPM file name?
Not at the moment... There are pending bug reports for this. You could
however use above patch to change package name and rename the file
name manually after generation.

Regards,
Domen

From domen.vrankar at gmail.com  Fri Jan 15 06:31:23 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 15 Jan 2016 12:31:23 +0100
Subject: [CMake] How to on multiple RPM packages
In-Reply-To: <CAEdhodzcoGz_GmWkdk=NxbXX8YAGp_q-0U4qrA=R5Bej-Gq+Hg@mail.gmail.com>
References: <CAEdhodzcoGz_GmWkdk=NxbXX8YAGp_q-0U4qrA=R5Bej-Gq+Hg@mail.gmail.com>
Message-ID: <CAKgx6B++j0cdmE_cOGK=SjxLRQkdK7OkdMfnxkVhgpqZ=57u0Q@mail.gmail.com>

I've accidentally dropped the mailing list in reply:

> I do not find an example on how to provide separate RPM's
> for them; one for the binary and one for the headers+library.
> The required results (rough example):
>
> - foo-1.2.3.4-1.x86_64.rpm
> - libfoo-1.2.3.4-1.x86.64.rpm

You have to provide COMPONENT and name in install commands:
install(TARGETS prog DESTINATION foo COMPONENT binary)
install(FILES someheader.hpp DESTINATION foo COMPONENT headersandlibs)

set that you wish to package components:
set(CPACK_RPM_COMPONENT_INSTALL "ON")

and enable RPM packaging generator:
set(CPACK_GENERATOR "RPM")

You can also set other per component properties to be used by
CPackRPM. See the documentation here:
https://cmake.org/cmake/help/v3.4/module/CPackRPM.html

All of this should be done before calling:
include(CPack)

Hope this helps.

Regards,
Domen

From gurenchan at gmail.com  Fri Jan 15 08:04:43 2016
From: gurenchan at gmail.com (Owen Hogarth II)
Date: Fri, 15 Jan 2016 13:04:43 +0000
Subject: [CMake] using macros
In-Reply-To: <CAKohaZeoK9CmR4gdiQiECgS2h+7kXUUGPUWMLUp4JsLOq2U4tA@mail.gmail.com>
References: <CALM2mE=Mwwh9O4t17dGq5_gxtiLH=8FvRpYjYO+wuUoK7DqM-w@mail.gmail.com>
 <CAKohaZeoK9CmR4gdiQiECgS2h+7kXUUGPUWMLUp4JsLOq2U4tA@mail.gmail.com>
Message-ID: <CALM2mEk+5QCvj_bW2yOs3MdDGjY=-a_67_5s4oj4N_7ZH244XQ@mail.gmail.com>

Yes, indeed. Yikes, thanks for this!

On Thu, Jan 14, 2016, 17:21 Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi Owen.
>
> As a sanity check, the definition of the macro in the toplevel CMakeList
> comes *before* the add_subdirectory() command for the one which errors out,
> right?
>
> Petr
>
> On Thu, Jan 14, 2016 at 8:25 AM, Owen Hogarth II <gurenchan at gmail.com>
> wrote:
>
>> I am trying to use a macro to enable c99 in some of my cmake modules.
>>
>> In the top level cmake file I add this macro
>>
>> macro(use_c99)
>>   if (CMAKE_VERSION VERSION_LESS "3.1")
>>     if (CMAKE_C_COMPILER_ID STREQUAL "GNU")
>>       set (CMAKE_C_FLAGS "--std=gnu99 ${CMAKE_C_FLAGS}")
>>     endif ()
>>   else ()
>>     set (CMAKE_C_STANDARD 99)
>>   endif ()
>> endmacro(use_c99)
>>
>> then in another CMakeLists.txt file I add
>> use_c99()
>>
>> but I get this error:
>>
>> CMake Error at source/internal_src/cube/CMakeLists.txt:1 (use_c
>> 99):
>>   Unknown CMake command "use_c99".
>>
>> why am I unable to use the macro? My main cmake is using 3.0.2 from
>> debian repository.
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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/20160115/39ed2631/attachment.html>

From morris at maynidea.com  Fri Jan 15 11:26:01 2016
From: morris at maynidea.com (mozzis)
Date: Fri, 15 Jan 2016 09:26:01 -0700 (MST)
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <56981071.4020802@kitware.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
Message-ID: <1452875161340-7592499.post@n2.nabble.com>

>You can not change the generator.  It is better to remove the entire 
>build tree.  Out of source builds are a best practice with CMake.  Once 
>a build tree has been configured with one compiler, it must be 
>completely removed to change to a new compiler

Clearly, "can not" is incorrect, since I did. "must be" seems also
incorrect.
It seems like the developers don't understand about 32-bit vs. 64-bit
builds, or don't intend for this tool to be used with software that is a
product. Determining that after painstakingly configuring all of the build
options, the user must throw it all away in order to build for the other
"bitness", seems wrong. Almost anyone that is intending to build software
that can be installed (without the end user having to build it from source
every time, that way lies madness) needs to produce a 32-bit and a 64-bit
package these days.

>CMake creates VS projects that should 
>work to build the project that is the goal. I don't understand about 
>make and MSVS, CMake can create makefiles or ninja files if that is what 
>you are talking about. 

The VC project files produced by the CMAKE system for OpenCV use absolute
paths and use them throughout the project files, rather than defining things
at top-level and then using predetermined macros like $(TargetDir) and
$(TargetName), to say nothing of conveniences like $(PlatformTarget). I
don't really know if that is inherent in how CMAKE generates the project
files or if there is a way to produce more easily maintainable project
files, but every time I have to utilize a project that involves CMAKE I
cringe because of the ugly project files it produces. The makefiles produced
have been the same way, with the same absolute paths occurring over and over
in the file. I do not like this, as it makes the project files/makefiles
difficult to debug or maintain. Having expressed this dislike here, I feel
much better and will probably not think about this much in the future, up
until the point I have to update to a new version of a library such as
OpenCV or HDF5. Then I will cringe; pick through all of the settings and
generate the makefiles/project files again; debug the results for a day or
so until the builds actually, you know, work; and then do my little
edit-and-regenerate trick to build for the other architecture. Because the
design of CMAKE does not recognize that the results of "try-compile" tests
are orthogonal to settings like "build module A" or "build shared
libraries", so that the latter should not depend upon the former.




--
View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html
Sent from the CMake mailing list archive at Nabble.com.

From arankin at robarts.ca  Fri Jan 15 11:03:48 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Fri, 15 Jan 2016 16:03:48 +0000
Subject: [CMake] ExternalProject_Add support for git clone -o option
Message-ID: <f627e1cbe3584f4fad5b2f3fad08811c@dag2.robarts.ca>

Hello all,

I am reading through the ExternalProject source for 3.2 at the moment (if updating to 3.4 is the answer, great!) and trying to determine if there is support for the -o option when using a git repository.

Has anyone accomplished this? I would like to have names other than "origin"

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

From nicholas11braden at gmail.com  Fri Jan 15 12:01:44 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Fri, 15 Jan 2016 11:01:44 -0600
Subject: [CMake] ExternalProject_Add support for git clone -o option
In-Reply-To: <f627e1cbe3584f4fad5b2f3fad08811c@dag2.robarts.ca>
References: <f627e1cbe3584f4fad5b2f3fad08811c@dag2.robarts.ca>
Message-ID: <CAHk1PgGPEprousga80SkbCbS0Hafgs00yFDQELz_Hnf+AUKUcQ@mail.gmail.com>

Why would you like to have names other than origin? I am struggling to
think of a use case for this, seeing as you never directly interact
with the cloned repository. I don't even think it's safe to assume
that a git repository is involved at all, for all you know it could be
changed to just download the code and never even involve git. (Maybe
it is guaranteed somewhere but I don't see such a guarantee in the
documentation)

On Fri, Jan 15, 2016 at 10:03 AM, Adam Rankin <arankin at robarts.ca> wrote:
> Hello all,
>
>
>
> I am reading through the ExternalProject source for 3.2 at the moment (if
> updating to 3.4 is the answer, great!) and trying to determine if there is
> support for the ?o option when using a git repository.
>
>
>
> Has anyone accomplished this? I would like to have names other than ?origin?
>
>
>
> Cheers,
>
> Adam
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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  Fri Jan 15 12:03:47 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Fri, 15 Jan 2016 17:03:47 +0000
Subject: [CMake] ExternalProject_Add support for git clone -o option
In-Reply-To: <CAHk1PgGPEprousga80SkbCbS0Hafgs00yFDQELz_Hnf+AUKUcQ@mail.gmail.com>
References: <f627e1cbe3584f4fad5b2f3fad08811c@dag2.robarts.ca>
 <CAHk1PgGPEprousga80SkbCbS0Hafgs00yFDQELz_Hnf+AUKUcQ@mail.gmail.com>
Message-ID: <37025a774cc8494a943beac992d586a9@dag2.robarts.ca>

My use case is for forked repositories and sending pull requests upstream. In this case "origin" is ambiguous as manage both remotes and I would like to give the cloned repository a more accurate name.

Cheers,
Adam

-----Original Message-----
From: Nicholas Braden [mailto:nicholas11braden at gmail.com] 
Sent: Friday, January 15, 2016 12:02 PM
To: Adam Rankin <arankin at robarts.ca>
Cc: cmake at cmake.org
Subject: Re: [CMake] ExternalProject_Add support for git clone -o option

Why would you like to have names other than origin? I am struggling to think of a use case for this, seeing as you never directly interact with the cloned repository. I don't even think it's safe to assume that a git repository is involved at all, for all you know it could be changed to just download the code and never even involve git. (Maybe it is guaranteed somewhere but I don't see such a guarantee in the
documentation)

On Fri, Jan 15, 2016 at 10:03 AM, Adam Rankin <arankin at robarts.ca> wrote:
> Hello all,
>
>
>
> I am reading through the ExternalProject source for 3.2 at the moment 
> (if updating to 3.4 is the answer, great!) and trying to determine if 
> there is support for the ?o option when using a git repository.
>
>
>
> Has anyone accomplished this? I would like to have names other than ?origin?
>
>
>
> Cheers,
>
> Adam
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For 
> more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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  Fri Jan 15 12:14:42 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Fri, 15 Jan 2016 17:14:42 +0000
Subject: [CMake] ExternalProject_Add support for git clone -o option
In-Reply-To: <CAHk1PgGPEprousga80SkbCbS0Hafgs00yFDQELz_Hnf+AUKUcQ@mail.gmail.com>
References: <f627e1cbe3584f4fad5b2f3fad08811c@dag2.robarts.ca>
 <CAHk1PgGPEprousga80SkbCbS0Hafgs00yFDQELz_Hnf+AUKUcQ@mail.gmail.com>
Message-ID: <8b3dbcb19fae4edcaff6b1618e67f6df@dag2.robarts.ca>

To elaborate on my reply:

I do indeed interact with the repository after it's cloned (as per my previous email).

With regards to implementation, I have implemented it such that the git remote name is only involved if git is chosen as the source of choice, in much the same manner as the git_tag implementation. My implementation makes the git remote name completely optional and defaults to "origin".

Regards,
Adam

-----Original Message-----
From: Nicholas Braden [mailto:nicholas11braden at gmail.com] 
Sent: Friday, January 15, 2016 12:02 PM
To: Adam Rankin <arankin at robarts.ca>
Cc: cmake at cmake.org
Subject: Re: [CMake] ExternalProject_Add support for git clone -o option

Why would you like to have names other than origin? I am struggling to think of a use case for this, seeing as you never directly interact with the cloned repository. I don't even think it's safe to assume that a git repository is involved at all, for all you know it could be changed to just download the code and never even involve git. (Maybe it is guaranteed somewhere but I don't see such a guarantee in the
documentation)

On Fri, Jan 15, 2016 at 10:03 AM, Adam Rankin <arankin at robarts.ca> wrote:
> Hello all,
>
>
>
> I am reading through the ExternalProject source for 3.2 at the moment 
> (if updating to 3.4 is the answer, great!) and trying to determine if 
> there is support for the ?o option when using a git repository.
>
>
>
> Has anyone accomplished this? I would like to have names other than ?origin?
>
>
>
> Cheers,
>
> Adam
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For 
> more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 d3ck0r at gmail.com  Fri Jan 15 13:09:29 2016
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 15 Jan 2016 10:09:29 -0800
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <1452875161340-7592499.post@n2.nabble.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com>
 <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com>
Message-ID: <CAA2GJqXULcoXG03=noz61e8uNWcbc2pO4zGs1HPDWHbFP45LgA@mail.gmail.com>

On Fri, Jan 15, 2016 at 8:26 AM, mozzis <morris at maynidea.com> wrote:
>
> Clearly, "can not" is incorrect, since I did. "must be" seems also
> incorrect.
Changing Generator is not exactly the same idea of what you're doing
1) If you actually chaned from VS 2010 to VS2012 or more radically to
MinGW Makefiles and redid the build, you would have only partially
correct results.  And actually even changing the bitness you already
have products built (.obj files) which won't be retriggered to compile
to some other flavor since the .obj will aready be newer than the
source so you'd have to do a rebuild.

> It seems like the developers don't understand about 32-bit vs. 64-bit
> builds, or don't intend for this tool to be used with software that is a
> product. Determining that after painstakingly configuring all of the build
> options, the user must throw it all away in order to build for the other
> "bitness", seems wrong. Almost anyone that is intending to build software
> that can be installed (without the end user having to build it from source
> every time, that way lies madness) needs to produce a 32-bit and a 64-bit
> package these days.
>

This is 2 different packages, 2 different targets, (4 if you
distribute debug versions also).  The packing stage will really expect
separate targets.  However, I solve this by making simple 'makeit.bat'
scripts.  copy and replace the generator and go.  But it also sounds
like you're trying to get Cmake to play with existing builds instead
of treating cmake as the primary build system.  I fought with this a
bit and was discusted myself in the lack of conformance to default
project $(outputdir)/$(targetname) stuff.  Was expecting to use cmake
to generate projects I could then maintain as visual studio projects
myself.  But I was already supporting a Make system for targeting
linux/mingw/watcom/lcc.... having bit the bullet and converted exising
visual studio projects o cmakelists and migraing to using cmake as a
primary tool has made life a lot simpler.

I like that I can now just add_subdirectory( ../../../bullet3 Bullet3
) and then have those libraries available to just specify
target_link_libraryes( physics_demo bullet )  or openal or .. Kind of
wish the whole world would switch now that cmake is quite mature.
(back in version 1.4 something it still seemed insufficient for some
things)

Yes, you often cannot just build a target and run it (wish it would
build into a single solution relative output directory instead of
project relative, which would make running in the debugger just so
much easier )  BUt I've included INSTALL() rules and just always build
the INstall target which only builds the things that have changed and
copies only those things to the output, and setup Debugging properties
on the install project to launch the thing I want to  (I have a core
library with a half dozen utilties, and a binaries library that
outputs probably some 60 simple tools )  (CMAKE_INSTALL_PREFIX doesn't
have to target /program files but rather can just target 'otuput'
which is relative to the CMAKE_BINARY_DIR ) for testing/build
processes... then Package target (with NSIS Support) is pretty easy to
add and get target packages.

But I target primarily MinGW, Linux, Android, VS 2015(now)
OpenWatcom... each of these has their own additional libraries, and
ways of generating code which are in most cases mutually exclusive, so
even attempting to change generator in CMakeCache is not even a
thought (yes, think I did try to do that at the beginning also)

--- one makeit.bat generated by a cmakelists to build all targets ---

"c:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 14 2015" -T
"v140"  "M:/sack/cmake_all/.." -DCMAKE_BUILD_TYPE=release
-DCMAKE_INSTALL_PREFIX=C:/General/Build/sack-vs14/release_out/core
-DBUILD_MONOLITHIC=OFF -DBUILD_EXTRAS=ON -D__NO_ODBC__=0FF
-DNEED_FREETYPE=ON -DNEED_JPEG=ON -DNEED_PNG=ON -DNEED_ZLIB=ON

c:\tools\unix\cmake\bin\cmake.exe --build . --config "release"
--target "INSTALL" -- /m:4 /v:m
---
Using the cmake --build unifies having to call MSBuild or Make of
MingW32Make or WMake as appropriate for the generator in question....
(although the arguments do change based on the genartor for specifying
build-tool specific options like /m:4  or /j 4(make) )



>>CMake creates VS projects that should
>>work to build the project that is the goal. I don't understand about
>>make and MSVS, CMake can create makefiles or ninja files if that is what
>>you are talking about.
>
> The VC project files produced by the CMAKE system for OpenCV use absolute
> paths and use them throughout the project files, rather than defining things
> at top-level and then using predetermined macros like $(TargetDir) and
> $(TargetName), to say nothing of conveniences like $(PlatformTarget). I
> don't really know if that is inherent in how CMAKE generates the project
> files or if there is a way to produce more easily maintainable project
> files, but every time I have to utilize a project that involves CMAKE I
> cringe because of the ugly project files it produces. The makefiles produced
> have been the same way, with the same absolute paths occurring over and over
> in the file. I do not like this, as it makes the project files/makefiles
> difficult to debug or maintain. Having expressed this dislike here, I feel
> much better and will probably not think about this much in the future, up
> until the point I have to update to a new version of a library such as
> OpenCV or HDF5. Then I will cringe; pick through all of the settings and
> generate the makefiles/project files again; debug the results for a day or
> so until the builds actually, you know, work; and then do my little
> edit-and-regenerate trick to build for the other architecture. Because the
> design of CMAKE does not recognize that the results of "try-compile" tests
> are orthogonal to settings like "build module A" or "build shared
> libraries", so that the latter should not depend upon the former.
>
>
>
>
> --
> View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From bill.hoffman at kitware.com  Fri Jan 15 14:32:16 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Fri, 15 Jan 2016 14:32:16 -0500
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <1452875161340-7592499.post@n2.nabble.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com>
Message-ID: <56994940.6000606@kitware.com>

On 1/15/2016 11:26 AM, mozzis wrote:
>> You can not change the generator.  It is better to remove the entire
>> build tree.  Out of source builds are a best practice with CMake.  Once
>> a build tree has been configured with one compiler, it must be
>> completely removed to change to a new compiler
>
> Clearly, "can not" is incorrect, since I did. "must be" seems also
> incorrect.

You can do it by changing the CMakeCache.txt file, but it won't work in 
the general case.  You should put them in separate directories: build-32 
and build-64.
> It seems like the developers don't understand about 32-bit vs. 64-bit
> builds, or don't intend for this tool to be used with software that is a
> product. Determining that after painstakingly configuring all of the build
> options, the user must throw it all away in order to build for the other
> "bitness", seems wrong. Almost anyone that is intending to build software
> that can be installed (without the end user having to build it from source
> every time, that way lies madness) needs to produce a 32-bit and a 64-bit
> package these days.

You can build both 32 and 64 from the same SOURCE tree, just not the 
same build tree.

src
build32   (cmake ../src -G"Visual Studio 10 2010")
build64   (cmake ../src -G"Visual Studio 10 2010 Win64")

You seem to be trying to reuse the same build tree for different builds 
which is not a supported use case.  I think if you stopped doing that 
your life might get easier when working with CMake projects.


-Bill


From greg.marr at autodesk.com  Fri Jan 15 14:41:22 2016
From: greg.marr at autodesk.com (Greg Marr)
Date: Fri, 15 Jan 2016 19:41:22 +0000
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <56994940.6000606@kitware.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com> <56994940.6000606@kitware.com>
Message-ID: <7449edcaea314f5b8068011e9732bc22@BN1PR79MB006.MGDADSK.autodesk.com>

Bill Hoffman wrote:
	You can do it by changing the CMakeCache.txt file, but it won't work in 
the general case.  You should put them in separate directories: build-32 
and build-64.

	You can build both 32 and 64 from the same SOURCE tree, just not the 
same build tree.

	build32   (cmake ../src -G"Visual Studio 10 2010")
	build64   (cmake ../src -G"Visual Studio 10 2010 Win64")

	You seem to be trying to reuse the same build tree for different builds 
which is not a supported use case.  I think if you stopped doing that 
your life might get easier when working with CMake projects.


You can do both in the same solution/projects with the Microsoft fork of CMake, but it's not a general solution, and it doesn't handle different settings for 32 bit and 64 bit.  Because of that, they're "not pushing too hard" for it to be in mainline CMake.

https://cmake.org/pipermail/cmake/2015-August/061346.html


From bill.hoffman at kitware.com  Fri Jan 15 15:36:16 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Fri, 15 Jan 2016 15:36:16 -0500
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <7449edcaea314f5b8068011e9732bc22@BN1PR79MB006.MGDADSK.autodesk.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com> <56994940.6000606@kitware.com>
 <7449edcaea314f5b8068011e9732bc22@BN1PR79MB006.MGDADSK.autodesk.com>
Message-ID: <56995840.3070903@kitware.com>

On 1/15/2016 2:41 PM, Greg Marr wrote:
> You can do both in the same solution/projects with the Microsoft fork
> of CMake, but it's not a general solution, and it doesn't handle
> different settings for 32 bit and 64 bit.  Because of that, they're
> "not pushing too hard" for it to be in mainline CMake.
>
> https://cmake.org/pipermail/cmake/2015-August/061346.html

Yes, and things like CMAKE_SIZEOF_VOID_P would not have valid values. 
However, if you want cmake builds to work, you should never change the 
generator in a CMakeCache.txt file, it is going to more often than not 
cause problems.  A build tree should be configured with one generator 
and if you need another generator you should use a different directory 
and a different build tree sharing the same source tree.

-Bill

From greg.marr at autodesk.com  Fri Jan 15 16:18:08 2016
From: greg.marr at autodesk.com (Greg Marr)
Date: Fri, 15 Jan 2016 21:18:08 +0000
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <56995840.3070903@kitware.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com> <56994940.6000606@kitware.com>
 <7449edcaea314f5b8068011e9732bc22@BN1PR79MB006.MGDADSK.autodesk.com>
 <56995840.3070903@kitware.com>
Message-ID: <2d0b5af5d3c64308ba8866ebc5a6af1d@BN1PR79MB006.MGDADSK.autodesk.com>

Bill Hoffman wrote:
>On 1/15/2016 2:41 PM, Greg Marr wrote:
>> You can do both in the same solution/projects with the Microsoft fork
>> of CMake, but it's not a general solution, and it doesn't handle
>> different settings for 32 bit and 64 bit. 
>
>Yes, and things like CMAKE_SIZEOF_VOID_P would not have valid values. 

Correct, so if you require different settings based on that value, you can't use this solution.  However, if you never look at it, then this may work for you.

> However, if you want cmake builds to work, you should never change the 
> generator in a CMakeCache.txt file, it is going to more often than not 
> cause problems.  A build tree should be configured with one generator 
> and if you need another generator you should use a different directory 
> and a different build tree sharing the same source tree.

Absolutely, that's why this is a single generator and is generated once.  

Unfortunately, the different settings limitation of this solution is rather...limiting.  It would be really nice if this could be made to work with different settings for the different CPU architectures (mostly just library paths for my past uses), just like native Visual Studio, XCode, Eclipse, and Android Studio projects do, but that would apparently be a very major change.


From morris at maynidea.com  Fri Jan 15 19:19:17 2016
From: morris at maynidea.com (mozzis)
Date: Fri, 15 Jan 2016 17:19:17 -0700 (MST)
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <CAA2GJqXULcoXG03=noz61e8uNWcbc2pO4zGs1HPDWHbFP45LgA@mail.gmail.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com>
 <CAA2GJqXULcoXG03=noz61e8uNWcbc2pO4zGs1HPDWHbFP45LgA@mail.gmail.com>
Message-ID: <SN1PR10MB0894F70AD0318CE00153C9EBBFCE0@SN1PR10MB0894.namprd10.prod.outlook.com>

Well, CMAKE is the thing that is conflating this idea of a "generator" (which is clearly a concept in CMAKE's own domain of "build configuration generator") with the idea of "platform" or "architecture" (which is a concept in the domain of certain kinds of build tools, such as a C compiler.) It would be healthier if platform/arch were broken out as a separate item in CMAKE, i.e. CMAKE recognizes that some build tools have this concept, but is (possibly) agnostic about how it is represented. I assume that it is not really possible to do so in the config files that drive CMAKE at present, only because I have never seen it done and did not find it when I went looking. Instead, that information is scattered across several files in the CMakeFiles folder.

Thank you for the hints and examples about using batch files. I may try to implement that scheme for building support libraries that come dependent on CMake. But I don't believe that I will ever use CMake for any product I am in control of, mainly because I have seen what an unmaintainable mess it creates for project files. And at least partly as a result, since there is no direct comprehension on the part of the developer/maintainer as to the project file structure, it becomes impossible to adequately manage that structure, so making large-scale improvements is nearly impossible without starting over from scratch. In addition, the build process becomes way inefficient. For example, once when I was really at loose ends due to a management blow-up, I reworked the build system for HDF5 on Visual Studio so it had "normal" project files that could be used to build for various platforms and configurations. The resulting build time was cut by a factor of 5, plus it became much easier (for me anyways) to be able to do things like change the output file names based on platform, something I have so far found impossible to do with CMake. [Once again, it really has no concept of this.]
I would do the same thing for OpenCV, but it is ten times worse than HDF5 in this regard. For instance, apparently project files are modified <i>as part of the MSVS build process</i>, so that Visual Studio always complains about project files needing to be reloaded after a build. This is a recipe for mysterious bugs that you will never be able to fix.

I have created/maintained multi-platform projects, and I find that the effort needed to produce efficient, readable makefiles for each platform is worth it. Once done, I can change the platform or the library type or similar parameters by changing one switch in each platform's makefile. Plus there are fewer gotchas at runtime, as not querying the build environment for every build ensures more consistent behavior in the binaries I am going to distribute.

Thanks again to all for the comments on this thread. It is good to know that development continues on this tool. At some point, it may become more interesting for me.

From: J Decker [via CMake] [mailto:ml-node+s3232098n7592504h60 at n2.nabble.com]
Sent: Friday, January 15, 2016 1:10 PM
To: Morris Maynard <morris at maynidea.com>
Subject: Re: Changing the the current generator in CMake GUI

On Fri, Jan 15, 2016 at 8:26 AM, mozzis <[hidden email]</user/SendEmail.jtp?type=node&node=7592504&i=0>> wrote:
>
> Clearly, "can not" is incorrect, since I did. "must be" seems also
> incorrect.
Changing Generator is not exactly the same idea of what you're doing
1) If you actually chaned from VS 2010 to VS2012 or more radically to
MinGW Makefiles and redid the build, you would have only partially
correct results.  And actually even changing the bitness you already
have products built (.obj files) which won't be retriggered to compile
to some other flavor since the .obj will aready be newer than the
source so you'd have to do a rebuild.

> It seems like the developers don't understand about 32-bit vs. 64-bit
> builds, or don't intend for this tool to be used with software that is a
> product. Determining that after painstakingly configuring all of the build
> options, the user must throw it all away in order to build for the other
> "bitness", seems wrong. Almost anyone that is intending to build software
> that can be installed (without the end user having to build it from source
> every time, that way lies madness) needs to produce a 32-bit and a 64-bit
> package these days.
>

This is 2 different packages, 2 different targets, (4 if you
distribute debug versions also).  The packing stage will really expect
separate targets.  However, I solve this by making simple 'makeit.bat'
scripts.  copy and replace the generator and go.  But it also sounds
like you're trying to get Cmake to play with existing builds instead
of treating cmake as the primary build system.  I fought with this a
bit and was discusted myself in the lack of conformance to default
project $(outputdir)/$(targetname) stuff.  Was expecting to use cmake
to generate projects I could then maintain as visual studio projects
myself.  But I was already supporting a Make system for targeting
linux/mingw/watcom/lcc.... having bit the bullet and converted exising
visual studio projects o cmakelists and migraing to using cmake as a
primary tool has made life a lot simpler.

I like that I can now just add_subdirectory( ../../../bullet3 Bullet3
) and then have those libraries available to just specify
target_link_libraryes( physics_demo bullet )  or openal or .. Kind of
wish the whole world would switch now that cmake is quite mature.
(back in version 1.4 something it still seemed insufficient for some
things)

Yes, you often cannot just build a target and run it (wish it would
build into a single solution relative output directory instead of
project relative, which would make running in the debugger just so
much easier )  BUt I've included INSTALL() rules and just always build
the INstall target which only builds the things that have changed and
copies only those things to the output, and setup Debugging properties
on the install project to launch the thing I want to  (I have a core
library with a half dozen utilties, and a binaries library that
outputs probably some 60 simple tools )  (CMAKE_INSTALL_PREFIX doesn't
have to target /program files but rather can just target 'otuput'
which is relative to the CMAKE_BINARY_DIR ) for testing/build
processes... then Package target (with NSIS Support) is pretty easy to
add and get target packages.

But I target primarily MinGW, Linux, Android, VS 2015(now)
OpenWatcom... each of these has their own additional libraries, and
ways of generating code which are in most cases mutually exclusive, so
even attempting to change generator in CMakeCache is not even a
thought (yes, think I did try to do that at the beginning also)

--- one makeit.bat generated by a cmakelists to build all targets ---

"c:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 14 2015" -T
"v140"  "M:/sack/cmake_all/.." -DCMAKE_BUILD_TYPE=release
-DCMAKE_INSTALL_PREFIX=C:/General/Build/sack-vs14/release_out/core
-DBUILD_MONOLITHIC=OFF -DBUILD_EXTRAS=ON -D__NO_ODBC__=0FF
-DNEED_FREETYPE=ON -DNEED_JPEG=ON -DNEED_PNG=ON -DNEED_ZLIB=ON

c:\tools\unix\cmake\bin\cmake.exe --build . --config "release"
--target "INSTALL" -- /m:4 /v:m
---
Using the cmake --build unifies having to call MSBuild or Make of
MingW32Make or WMake as appropriate for the generator in question....
(although the arguments do change based on the genartor for specifying
build-tool specific options like /m:4  or /j 4(make) )


>>CMake creates VS projects that should
>>work to build the project that is the goal. I don't understand about
>>make and MSVS, CMake can create makefiles or ninja files if that is what
>>you are talking about.
>
> The VC project files produced by the CMAKE system for OpenCV use absolute
> paths and use them throughout the project files, rather than defining things
> at top-level and then using predetermined macros like $(TargetDir) and
> $(TargetName), to say nothing of conveniences like $(PlatformTarget). I
> don't really know if that is inherent in how CMAKE generates the project
> files or if there is a way to produce more easily maintainable project
> files, but every time I have to utilize a project that involves CMAKE I
> cringe because of the ugly project files it produces. The makefiles produced
> have been the same way, with the same absolute paths occurring over and over
> in the file. I do not like this, as it makes the project files/makefiles
> difficult to debug or maintain. Having expressed this dislike here, I feel
> much better and will probably not think about this much in the future, up
> until the point I have to update to a new version of a library such as
> OpenCV or HDF5. Then I will cringe; pick through all of the settings and
> generate the makefiles/project files again; debug the results for a day or
> so until the builds actually, you know, work; and then do my little
> edit-and-regenerate trick to build for the other architecture. Because the
> design of CMAKE does not recognize that the results of "try-compile" tests
> are orthogonal to settings like "build module A" or "build shared
> libraries", so that the latter should not depend upon the former.
>
>
>
>
> --
> View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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
--

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

________________________________
If you reply to this email, your message will be added to the discussion below:
http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592504.html
To unsubscribe from Changing the the current generator in CMake GUI, click here<http://cmake.3232098.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7587876&code=bW9ycmlzQG1heW5pZGVhLmNvbXw3NTg3ODc2fC0yMTQ2NDMyNDU5>.
NAML<http://cmake.3232098.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592509.html
Sent from the CMake mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160115/c7d31032/attachment-0001.html>

From iosif.neitzke+cmake at gmail.com  Sat Jan 16 10:35:13 2016
From: iosif.neitzke+cmake at gmail.com (iosif neitzke)
Date: Sat, 16 Jan 2016 09:35:13 -0600
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <SN1PR10MB0894F70AD0318CE00153C9EBBFCE0@SN1PR10MB0894.namprd10.prod.outlook.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com>
 <CAA2GJqXULcoXG03=noz61e8uNWcbc2pO4zGs1HPDWHbFP45LgA@mail.gmail.com>
 <SN1PR10MB0894F70AD0318CE00153C9EBBFCE0@SN1PR10MB0894.namprd10.prod.outlook.com>
Message-ID: <bafebe8e-0386-81c9-2de9-dcdd8a327e49@gmail.com>

http://reactiongifs.me/krysten-ritter-eyeroll/

From t.ruschival at gmail.com  Sun Jan 17 04:39:25 2016
From: t.ruschival at gmail.com (Thomas Ruschival)
Date: Sun, 17 Jan 2016 10:39:25 +0100
Subject: [CMake] Interpackage dependencies - find_package() from package
Message-ID: <569B614D.4090800@gmail.com>

Hi,
I have problems understanding how the cmake-buildsystem is supposed to
resolve inter-package dependencies (imported targets form installed
packages).

Let say I have a project with an executable target (e.g. someApp) that
depends on a library (libfoo). While libfoo is built in a separate
project and depends on libbar which is built in another project.
Libbar and libfoo export cmake packages (fooConfig.cmake,
fooVersion.cmake fooTargets.cmake etc.) according to [1] and [3]

I.e.:
someApp->libfoo->libbar

In libfoo:
- find_package(bar CONFIG REQUIRED)
- target_link_libraries(bar::bar)

The packages are installed and found - no problem here.
In FooTargets.cmake the dependency on bar::bar is added to
INTERFACE_LINK_LIBRARIES.

If in someApp I find foo find_package(foo CONFIG REQUIRED)
I get an error: "The following imported targets are referenced, but are
missing: bar::bar"

The current workaround is to manually add in someApp
find_package(bar CONFIG REQUIRED) before
find_package(foo CONFIG REQUIRED)


But in my understanding this find_package(bar) should somehow be
resolved from the package foo - am I wrong?
The client should not have to resolve the entire dependency tree
manually bay adding find_package() in the correct order.
How can this be done?

Do I miss something or does CMake (3.4) just not do what I want it to do
out of the box?

Thanks in advance!
Thomas

I am using the wiki + reference:
[1] https://cmake.org/Wiki/CMake/Tutorials/Packaging
[2] https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html
and this example:
[3] https://github.com/forexample/package-example



From domen.vrankar at gmail.com  Sun Jan 17 05:47:04 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Sun, 17 Jan 2016 11:47:04 +0100
Subject: [CMake] Interpackage dependencies - find_package() from package
In-Reply-To: <569B614D.4090800@gmail.com>
References: <569B614D.4090800@gmail.com>
Message-ID: <CAKgx6BJ=9z_iv=2LNAwa_AUn8UqBWi1jhZJcMgXVTQVKHBAbQw@mail.gmail.com>

> If in someApp I find foo find_package(foo CONFIG REQUIRED)
> I get an error: "The following imported targets are referenced, but are
> missing: bar::bar"
>
> The current workaround is to manually add in someApp
> find_package(bar CONFIG REQUIRED) before
> find_package(foo CONFIG REQUIRED)
>
>
> But in my understanding this find_package(bar) should somehow be
> resolved from the package foo - am I wrong?
> The client should not have to resolve the entire dependency tree
> manually bay adding find_package() in the correct order.
> How can this be done?

As far as I know find_package(foo) will not search for its
dependencies (e.g. bar) except if you put another find_package inside
Findfoo.cmake script that finds it for you.

On the other hand I doubt that this is a CMake issue/shortcoming.
I imagine that your dependency tree looks something like this:

your_program <- foo <- bar
                    <- bar

so both your program and foo library depend on bar library and there
are three cases that I see:

1) your application has direct dependency on bar library (is using bar api)
2a) your application depends on foo that exposes bar api because it
uses bar api as public foo api
2b) you application depends on foo that exposes bar api but foo
doesn't use it as public foo api

In all cases you will have to search for bar library yourself and link
it to your application but:

In case 1 it is logical that you have to search for bar lib yourself
since it is just a coincidence that foo is using bar internally.

In case 2a dependency to bar is by design and it's questionable why
bar is used in public foo api (maybe performance reasons?) so it might
be a flaw in library design (or is your own library in which case it
would probably be better to create an object library and do all the
linking and searching for libraries in you applications cmake list -
in this case you could also set a variable with PARENT_SCOPE that gets
propagated to root cmake list to automate you dependency detection).

In case 2b dependency to bar is accidental and is just poor/old
library design - library is not linked with everything being a private
symbol and only public api being marked as public either by using an
attribute (https://gcc.gnu.org/wiki/Visibility   - supported in one
way or the other in gcc, Visual C++, xlC from version 13.1 and
probably clang and others) or some other form like export lists or
static keywords
(http://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/).
If this is an external library and you are using it for production
application I would suggest that  if possible you write a wrapper
library that only exposes its public api and link your application
only to your wrapper - or if library is open sourced ask if they are
interested in such patches and contribute them there.

In any case if this is not supporter directly by CMake (could be that
it is and I only don't know about it) I doubt that it should be since
libraries leaking their internal implementation probably have API and
ABI compatibility issues between versions and can cause interesting
compile and runtime errors when linked twice as in your case but with
different shared library versions (e.g. you get an already compiled
library and just want to link to it but don't know with which version
of internally dependent library it was built).

Issues with this can be easily seen in cases such as:
your_program <- foo <- bar (v 1.0)
                     <- bas <- bar (v 2.1)
                    <- bar (v 1.3)
If your application, foo, bar and bas are not built as the same super
project or expect different (not API compatible) versions of bar and
they all leak their internal use to the world (and let's also say that
bar 1 and 2 were not tested for combined use in the same application)
then have fun building such an application without causing interesting
runtime errors (e.g. constructor from being called version 1.0 and
destructor from version 2.1).

Hope this helps.

Regards,
Domen

From kaparis.dimitri at gmail.com  Sun Jan 17 06:45:34 2016
From: kaparis.dimitri at gmail.com (Dimitri Kaparis)
Date: Sun, 17 Jan 2016 13:45:34 +0200
Subject: [CMake] Code::blocks: parallel build from IDE
In-Reply-To: <6790985.K0psM2NUZv@tuxedo.neundorf.net>
References: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>
 <6790985.K0psM2NUZv@tuxedo.neundorf.net>
Message-ID: <CAFzH18i1Yd1j4W+RCyS41thQCN9nJLGEta_FT8v8FVc0ca6fcg@mail.gmail.com>

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, or an idea for a workaround?

Thanks,
Dimitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160117/61a24c25/attachment.html>

From nilsgladitz at gmail.com  Sun Jan 17 07:14:02 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Sun, 17 Jan 2016 13:14:02 +0100
Subject: [CMake] Code::blocks: parallel build from IDE
In-Reply-To: <CAFzH18i1Yd1j4W+RCyS41thQCN9nJLGEta_FT8v8FVc0ca6fcg@mail.gmail.com>
References: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>
 <6790985.K0psM2NUZv@tuxedo.neundorf.net>
 <CAFzH18i1Yd1j4W+RCyS41thQCN9nJLGEta_FT8v8FVc0ca6fcg@mail.gmail.com>
Message-ID: <569B858A.8000005@gmail.com>

On 17.01.2016 12:45, Dimitri Kaparis wrote:
> On Sat, Jan 9, 2016 at 9:16 PM, Alexander Neundorf 
> <a.neundorf-work at gmx.net <mailto:a.neundorf-work at gmx.net>> wrote:
>
>
>     Oops, sorry, that's not implemented for C::B.
>
>     Alex
>
>
> Any plans on it, or an idea for a workaround?

As a workaround perhaps "CodeBlocks - Ninja" would be an option?
ninja builds parallel by default.

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160117/84f98937/attachment.html>

From a.neundorf-work at gmx.net  Sun Jan 17 08:01:59 2016
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Sun, 17 Jan 2016 14:01:59 +0100
Subject: [CMake] Code::blocks: parallel build from IDE
In-Reply-To: <CAFzH18i1Yd1j4W+RCyS41thQCN9nJLGEta_FT8v8FVc0ca6fcg@mail.gmail.com>
References: <CAFzH18i26pWia=7WTXuXoAhdnt691sJot=0X61f2jzBa2Ld=bA@mail.gmail.com>
 <6790985.K0psM2NUZv@tuxedo.neundorf.net>
 <CAFzH18i1Yd1j4W+RCyS41thQCN9nJLGEta_FT8v8FVc0ca6fcg@mail.gmail.com>
Message-ID: <3211808.HRXAgpu4YV@tuxedo.neundorf.net>

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.

Alex


From t.ruschival at gmail.com  Sun Jan 17 10:05:57 2016
From: t.ruschival at gmail.com (Thomas Ruschival)
Date: Sun, 17 Jan 2016 16:05:57 +0100
Subject: [CMake] Interpackage dependencies - find_package() from package
In-Reply-To: <CAKgx6BJ=9z_iv=2LNAwa_AUn8UqBWi1jhZJcMgXVTQVKHBAbQw@mail.gmail.com>
References: <569B614D.4090800@gmail.com>
 <CAKgx6BJ=9z_iv=2LNAwa_AUn8UqBWi1jhZJcMgXVTQVKHBAbQw@mail.gmail.com>
Message-ID: <569BADD5.1040204@gmail.com>

Thank you Domen
for your detailed answer!

> If your application, foo, bar and bas are not built as the same super
> project [...]
In fact this is where I started, for now all are build in the same
super-project and foo and bar have tight coupling. In fact foo and bar
end up in the same Cpack package and are installed together.
(BTW. foo and bar are static libraries and bar exports compile_flags to
let its clients know how it  was compiled.)

I started playing around trying if I can use the packages installed and
found the problem that while bar can be used in the client program foo
couldn't and I wondered wether this is possible.
Your arguments make total sense... althought it would be cool if it
worked...

Thanks again!
Thomas


From oblf.br at gmail.com  Mon Jan 18 02:57:33 2016
From: oblf.br at gmail.com (Bettina R.)
Date: Mon, 18 Jan 2016 08:57:33 +0100
Subject: [CMake] Looking for Cmake / CPACK documentation
Message-ID: <CAPDR1uZwMX3uyxxKHPKQ81MAOjWZ+T5cnvMJH3a9RgJBQGoY4g@mail.gmail.com>

Hello,

I am not absolutely sure if this is the right place to ask, so excuse me if
I am totally wrong here and show me the right way :)

For my software I am looking to create a NSIS installer via CMake (3.2.2)
on Windows. Creating an installer with things like components and required
parts wasn't that hard, but now I am having two problems:
1.
I need a custom page with 2 mutual exclusive options. Depending on the
selection I need to copy either file A or file B in "Component 1" while I
would need to copy file C or D in "component 2".
Is this possible with cmake / cpack or a problem to be tackled within the
NSIS system?

2.
When starting the created installer itself the GUI is very small, basically
having three columns in the window:
 - A column describing what to do (Left).
 - A tree view of the available components (Middle)
 - A description of the selected component (right).
The users complained that the window was too small and the texts were near
impossible to read. The window itself can't not be resized at all. I tried
to switch the GUI by changing to

!include "MUI2.nsh"

in NSIS.template.in (I was led to believe that this would change the layout
to 2 horizontal blocks:
Component tree and description of selected component).

Compiled, got errors that some variables and macros have changed, corrected
that but still the installer shows me the 3 column window layout.

As I am currently lost, I am looking for some pointers on where to look for
documentation regarding those problems.

Thank you in advance
Bettina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160118/1c699e56/attachment.html>

From nikita.barawade at einfochips.com  Mon Jan 18 09:08:02 2016
From: nikita.barawade at einfochips.com (Nikita Barawade)
Date: Mon, 18 Jan 2016 14:08:02 +0000
Subject: [CMake] Alternative to CMAKE_PREFIX_PATH
Message-ID: <PS1PR02MB1401C9CAB970962DC15CD0DA86C00@PS1PR02MB1401.apcprd02.prod.outlook.com>



Hi,

My project needs Qt5   .

Adding
find_package (Qt5Widgets)
to CMakeLists.txt  could not find Qt .

So I added,
set (CMAKE_PREFIX_PATH
"< Qt installation  path>")

It is working fine now. But is there any alternative to find qt5 package  without  hardcoding  CMAKE_PREFIX_PATH ?

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/20160118/2e6323c1/attachment.html>

From dumont.guillaume at gmail.com  Mon Jan 18 09:46:37 2016
From: dumont.guillaume at gmail.com (Guillaume Dumont)
Date: Mon, 18 Jan 2016 09:46:37 -0500
Subject: [CMake] Alternative to CMAKE_PREFIX_PATH
In-Reply-To: <PS1PR02MB1401C9CAB970962DC15CD0DA86C00@PS1PR02MB1401.apcprd02.prod.outlook.com>
References: <PS1PR02MB1401C9CAB970962DC15CD0DA86C00@PS1PR02MB1401.apcprd02.prod.outlook.com>
Message-ID: <CAKGHxZzcxckguiQUY-OFzRGkRgwFuTi2s+LfxBEkajuR6rUh3A@mail.gmail.com>

A better alternative would be to use the command line switch
-DCMAKE_PREFIX_PATH=<Qt install location> or similarly via CMake-GUI. Or
you could also use the env var. See
https://cmake.org/cmake/help/v3.3/command/find_package.html?highlight=cmake_prefix_path
for search order.

On Mon, Jan 18, 2016 at 9:08 AM, Nikita Barawade <
nikita.barawade at einfochips.com> wrote:

>
>
> Hi,
>
> My project needs Qt5   .
>
> Adding
> find_package (Qt5Widgets)
> to CMakeLists.txt  could not find Qt .
>
> So I added,
> set (CMAKE_PREFIX_PATH
> "< Qt installation  path>")
>
> It is working fine now. But is there any alternative to find qt5 package
>  without  hardcoding  CMAKE_PREFIX_PATH ?
>
> 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
>



-- 
Guillaume Dumont
=========================
dumont.guillaume at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160118/15c11261/attachment-0001.html>

From Thomas.Richard at imgtec.com  Mon Jan 18 09:49:24 2016
From: Thomas.Richard at imgtec.com (Thomas Richard)
Date: Mon, 18 Jan 2016 14:49:24 +0000
Subject: [CMake] Alternative to CMAKE_PREFIX_PATH
In-Reply-To: <PS1PR02MB1401C9CAB970962DC15CD0DA86C00@PS1PR02MB1401.apcprd02.prod.outlook.com>
References: <PS1PR02MB1401C9CAB970962DC15CD0DA86C00@PS1PR02MB1401.apcprd02.prod.outlook.com>
Message-ID: <0E9BBE95FC3BFC4EAE3C7EF5C73CE9DD47D7997C@HHMAIL01.hh.imgtec.org>

For our project we set QT_BINARY_DIR which finds most of the Qt5XXX ones (it is defined in the FindQt5.cmake).
We however also added the non-standard QT_LIBRARY_CMAKE_DIR to search for the Qt5XXXX when they are not installed in the default location (the default we put is ${QT_BINARY_DIR}/../lib/cmake/ but for instance on some linux installation they may be somewhere else).

Thomas

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nikita Barawade
Sent: 18 January 2016 14:08
To: cmake at cmake.org
Subject: [CMake] Alternative to CMAKE_PREFIX_PATH

Hi,

My project needs Qt5 ? .?

Adding ?
find_package (Qt5Widgets)
to CMakeLists.txt ?could not find Qt?.?

So I added,
set (CMAKE_PREFIX_PATH?
"<?Qt installation??path>")

It is working fine now. But is there any alternative to find qt5 package ?without??hardcoding??CMAKE_PREFIX_PATH ?
Regards,
Nikita 

From bill.hoffman at kitware.com  Mon Jan 18 10:51:12 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 18 Jan 2016 10:51:12 -0500
Subject: [CMake] Changing the the current generator in CMake GUI
In-Reply-To: <SN1PR10MB0894F70AD0318CE00153C9EBBFCE0@SN1PR10MB0894.namprd10.prod.outlook.com>
References: <lposk5$2iv$1@ger.gmane.org>
 <1452801775327-7592486.post@n2.nabble.com> <56981071.4020802@kitware.com>
 <1452875161340-7592499.post@n2.nabble.com>
 <CAA2GJqXULcoXG03=noz61e8uNWcbc2pO4zGs1HPDWHbFP45LgA@mail.gmail.com>
 <SN1PR10MB0894F70AD0318CE00153C9EBBFCE0@SN1PR10MB0894.namprd10.prod.outlook.com>
Message-ID: <569D09F0.3020902@kitware.com>

On 1/15/2016 7:19 PM, mozzis wrote:
> Well, CMAKE is the thing that is conflating this idea of a ?generator?
> (which is clearly a concept in CMAKE?s own domain of ?build
> configuration generator?) with the idea of ?platform? or ?architecture?
> (which is a concept in the domain of certain kinds of build tools, such
> as a C compiler.) It would be healthier if platform/arch were broken out
> as a separate item in CMAKE, i.e. CMAKE recognizes that some build tools
> have this concept, but is (possibly) agnostic about how it is
> represented. I assume that it is not really possible to do so in the
> config files that drive CMAKE at present, only because I have never seen
> it done and did not find it when I went looking. Instead, that
> information is scattered across several files in the CMakeFiles folder.

So, in CMake it currently supports one platform/arch at a time.  This is 
because of support for system introspection (trycompile/tryrun).

> configurations. The resulting build time was cut by a factor of 5, plus
> it became much easier (for me anyways) to be able to do things like
> change the output file names based on platform, something I have so far
> found impossible to do with CMake. [Once again, it really has no concept
> of this.]

I really can't believe the build was faster, that just does not sound 
possible.  At the end of the day CMake gives VS  a list of files and VS 
compiles them.  If you want something really fast with VS, use the CMake 
ninja generator instead of VS and get builds that are significantly 
faster than VS IDE builds.  I would like to see a real example of that 
which I can reproduce, because we could modify CMake to create a similar 
project file.  The only thing that could improve build times that much 
is adding the /MP flag, but that can be done with CMake right now. (see 
my blog http://www.kitware.com/blog/home/post/434)

CMake does have the ability to change output names based on 
configuration with target properties.  However, the VS project files are 
not intended to be changed but only generated.  The changes should all 
happen in the CMake input files or the next time you run CMake all the 
changes will be lost.  CMake is not intended to create an IDE file that 
then can be changed/maintained on its own.  It will be erased and 
overwritten as soon as there is any change in a CMake input file used to 
generate it.
>
> I would do the same thing for OpenCV, but it is ten times worse than
> HDF5 in this regard. For instance, apparently project files are modified
> <i>/as part of the MSVS build process/</i>, so that Visual Studio always
> complains about project files needing to be reloaded after a build. This
> is a recipe for mysterious bugs that you will never be able to fix.
That sounds like something wrong in the OpenCV CMake files, it should 
not rerun cmake with each build.
>
> I have created/maintained multi-platform projects, and I find that the
> effort needed to produce efficient, readable makefiles for each platform
> is worth it. Once done, I can change the platform or the library type or
> similar parameters by changing one switch in each platform?s makefile.
> Plus there are fewer gotchas at runtime, as not querying the build
> environment for every build ensures more consistent behavior in the
> binaries I am going to distribute.
>
If you have the time to maintain hand crafted makefiles/IDE project 
files then more power to you.  Also, I assume that every developer on 
your project knows how to make changes to each platforms build files 
when they want to add a new source file or library.
> Thanks again to all for the comments on this thread. It is good to know
> that development continues on this tool. At some point, it may become
> more interesting for me.
>
I really don't care if you use CMake or not.  However, I want to make 
sure that I clear up any misconceptions that this thread may raise for 
others.  To sum things up:

- CMake is a cross platform build generator, the makefiles/IDE/build 
files that it generates are not meant to be human readable and 
especially human editable. The way to change what happens in the build 
has to be done by changing either the source CMakeLists.txt files or the 
CMakaCache.txt and not the build files.  This is because the build files 
are written over each time CMake is run.

- CMake is setup to make it easier for cross platform development with a 
team of developers that only needs to know how to add sources and modify 
the build by changing the input to CMake.  They are not required to know 
how to edit and maintain files for make/ninja/VS 9,10,11,12,13,14, Xcode 
various versions.

- You should use out of source builds and once a build generator is 
picked (VS some version, make, ninja, ect), You can not change that 
build generator without erasing the directory or creating a new one.

- It might be possible in future versions of CMake that VS IDEs support 
64/32 bit builds like they support release/debug right now, but 
currently this is not supported in a released CMake.  If it were 
supported projects would have to be careful with try-compile/try-run 
commands.

-Bill


From julien.jomier at kitware.com  Mon Jan 18 10:51:32 2016
From: julien.jomier at kitware.com (Julien Jomier)
Date: Mon, 18 Jan 2016 16:51:32 +0100
Subject: [CMake] ANN: CMake Course - March 14 in Lyon, France
Message-ID: <569D0A04.4080704@kitware.com>

Happy New Year!

To start the new year right, Kitware will be holding a CMake training 
course on March 14, 2016 at Kitware's office in Lyon, France. This 
one-day course will cover CMake, CTest, CPack and CDash.

Visit our website for more information and registration details (early 
registration and student discounts available):

    http://training.kitware.fr/browse/120

Note that the course will be taught in English. If you have any 
questions, please contact me directly or training at kitware.fr.

We are looking forward to seeing you in Lyon,
Julien
-- 
Kitware SAS
26 rue Louis Gu?rin
69100 Villeurbanne, France
http://www.kitware.eu

From dave at morsberger.com  Mon Jan 18 14:58:58 2016
From: dave at morsberger.com (David Morsberger)
Date: Mon, 18 Jan 2016 14:58:58 -0500
Subject: [CMake] XCode Generation Issue
Message-ID: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>

I?m having an issue generating and using a XCode project using cmake -G.

cmake ?version
    cmake version 3.4.1

Xcode Version 7.2 (7C68)

Mac OS 10.11.


My CMakeLists.txt has a clang option that fails during the -G Xcode pass but fails when linking within XCode.

The compiler / linker option is ?-Wl,?as-needed?

The test compile/link step in ?cmake -G Xcode' creates a long clang command with arguments ?-Wl,?as-needed? plus ??serialize-diagnostics <path to .dia file>?

The link step within Xcode after the project created has the ?-Wl,?as-needed? argument and does not have the ??serialize-diagnostics <path to .dia file>? argument. The link fails because ?-Wl,?as-needed? isn?t supported.

If copy and execute the long clang command from the ?cmake -G Xcode? command and remove the ??serialize-diagnostics <path to .dia file>? then it successfully fails with ?-Wl, ?as-needed? isn?t supported. 

Finally, when I use cmake to generate unix makefiles it works meaning cmake determines ?-Wl?as-needed? isn?t supported and doesn?t add it to the argument list.

Questions:
 - Where is the ??serialized-diagnostics? argument coming from when executing ?cmake -G Xcode??

 - What is a .dia file and how do I read it?

 - What?s the preferred / recommended way of detecting the non-supported ?-Wl,?as-needed? argument during the ?cmake -G Xcode? phase? One option might to be to remove the ??serialize-diagnostics? argument during the generation phase.

I can provide more details on request.

David






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

From biddisco at cscs.ch  Tue Jan 19 02:55:27 2016
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Tue, 19 Jan 2016 07:55:27 +0000
Subject: [CMake] cdash/ctest question
In-Reply-To: <8703684.uaWUrAkQri@tuxedo.neundorf.net>
References: <D2BDD6E9.973FC%biddisco@cscs.ch>
 <8703684.uaWUrAkQri@tuxedo.neundorf.net>
Message-ID: <50320452A334BD42A5EC72BAD21450993DDCE4B5@MBX110.d.ethz.ch>

Alex

Thank you for this information. I shall test this out right away.

Yours

JB

-----Original Message-----
From: Alexander Neundorf [mailto:a.neundorf-work at gmx.net] 
Sent: 14 January 2016 23:17
To: cmake at cmake.org
Cc: Biddiscombe, John A.
Subject: Re: [CMake] cdash/ctest question

On Thursday, January 14, 2016 21:51:23 Biddiscombe, John A. wrote:
> Apologies for posting a cdash question question to the cmake list?
> 
> CDash plots the run-time of tests, which is very useful indeed, but it 
> would be even more useful if one could output a performance related 
> ?time? from a test where a specific feature was being benchmarked and 
> one could see how it changes over a period of days/weeks/months as 
> changes to code are being made.
> The time would be specific to the tested code and not include startup 
> and other uninteresting overheads (such as when the filesystem is 
> misbehaving and the test starts slowly).
> Does such a feature exist in ctest/cdash at all?

yes, we do exactly that.

You have to generate <DartMeasurement> tags in the stdoutof the test <DartMeasurement name="Simple" type="numeric/integer">42</DartMeasurement>
<DartMeasurement name="ExecutionTime" 
type="numeric/double">1.23456</DartMeasurement>

and then in cdash you can configure the tests-overview page to display certain such measurements by name, and on the tests page you can also display graphs for such named measurements.

Alex



From laasunde at hotmail.com  Tue Jan 19 06:30:39 2016
From: laasunde at hotmail.com (Lars)
Date: Tue, 19 Jan 2016 12:30:39 +0100
Subject: [CMake] add_custom_command scope
Message-ID: <DUB128-W43899E2DD73F30559020B7CAC10@phx.gbl>

 Hello,
 
Using CMake 3.3 and VS2012.
 
The below cmake scripts generate "Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command must exists". Why cannot the custom/CMakeLists.txt file see the target created in app/CMakeLists.txt ? Moving the ADD_CUSTOM_COMMAND to the app/CMakeLists.txt fixes the problem but I would like to keep them separate if possible.
 
PROJECT(TEST)
ADD_DIRECTORY(app)
ADD_DIRECTORY(custom)
 
The app CMakeLists.txt looks like this;
ADD_EXECUTABLE(app main.cpp)
TARGET_LINK_LIBRARIES(app)
 
The custom CMakeLists.txt looks like this;
ADD_CUSTOM_COMMAND(
  TARGET app 
  POST_BUILD
  COMMAND tbd.exe)
 
Appreciate any input.
 
Kind regards, Lars
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160119/a24fc648/attachment.html>

From post at hendrik-sattler.de  Tue Jan 19 07:15:13 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Tue, 19 Jan 2016 13:15:13 +0100
Subject: [CMake] add_custom_command scope
In-Reply-To: <DUB128-W43899E2DD73F30559020B7CAC10@phx.gbl>
References: <DUB128-W43899E2DD73F30559020B7CAC10@phx.gbl>
Message-ID: <5D7DC25E-D6AB-49AA-8AC4-4D921CE2F547@hendrik-sattler.de>



Am 19. Januar 2016 12:30:39 MEZ, schrieb Lars <laasunde at hotmail.com>:
> Hello,
> 
>Using CMake 3.3 and VS2012.
> 
>The below cmake scripts generate "Policy CMP0040 is not set: The target
>in the TARGET signature of add_custom_command must exists". Why cannot
>the custom/CMakeLists.txt file see the target created in
>app/CMakeLists.txt ? Moving the ADD_CUSTOM_COMMAND to the
>app/CMakeLists.txt fixes the problem but I would like to keep them
>separate if possible.
> 
>PROJECT(TEST)
>ADD_DIRECTORY(app)
>ADD_DIRECTORY(custom)
> 
>The app CMakeLists.txt looks like this;
>ADD_EXECUTABLE(app main.cpp)
>TARGET_LINK_LIBRARIES(app)
> 
>The custom CMakeLists.txt looks like this;
>ADD_CUSTOM_COMMAND(
>  TARGET app 
>  POST_BUILD
>  COMMAND tbd.exe)
> 
>Appreciate any input.

Make that its own custom target and let it depend on app target.

>Kind regards, Lars
> 		 	   		  
>
>------------------------------------------------------------------------


From robert.maynard at kitware.com  Tue Jan 19 15:14:31 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 19 Jan 2016 15:14:31 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.4.2 available for download
Message-ID: <CAFzjYVrRmpmiTJGj0q=ouWeVBNotE-XW39K8wjeKFSMiVui-dw@mail.gmail.com>

We are pleased to announce that CMake 3.4.2 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.4.2 since 3.4.1:

Brad King (6):
    CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889)
    VS: Do not select a partial Windows 10 SDK folder (#15831)
    VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation (#15894)
    cmSystemTools: Add VersionCompareEqual helper
    VS: Fix Windows 10 SDK version selection (#15831)
    CMake 3.4.2

Marc Chevrier (2):
    FindJava: Fix typos in IdlJ and JarSigner component implementation
    AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW

From taylor at braun-jones.org  Tue Jan 19 15:53:03 2016
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Tue, 19 Jan 2016 15:53:03 -0500
Subject: [CMake] Why does INTERFACE type targets only support
	whitelisted properties?
In-Reply-To: <n719kh$kvu$1@ger.gmane.org>
References: <CAFmT9kTgrVmtsxEsGE0f=1FO3xygt5S+dWsiLVyniRKB9dJt=g@mail.gmail.com>
 <568F9BB7.7090604@gmail.com>
 <CAFmT9kS=GunOF8q-rxvYx1n=6REjuKWp13bXHeM_ktnrMmxPmQ@mail.gmail.com>
 <568FB358.9060005@gmail.com>
 <CAFmT9kT3eZy+5KfMPWyRiZ7OBrsvSO=BHFMwpwOjp-y_fWff=Q@mail.gmail.com>
 <568FC3C1.50803@gmail.com>
 <CAKfKJYvAKEdwXGkad6+eJiYbBkOw0GkCvenAiRm076kZ01Wv9w@mail.gmail.com>
 <n719kh$kvu$1@ger.gmane.org>
Message-ID: <CAKfKJYsk8nC8oihM2hJXZ6S5S3qs=VEhPbnpQwR7bs4OujhzAg@mail.gmail.com>

On Mon, Jan 11, 2016 at 5:16 PM, Stephen Kelly <steveire at gmaicom> wrote:
> Taylor Braun-Jones wrote:
>
>> Consider library project Foo that uses a header-only project Bar. In
>> FooConfig.cmake, it is a important to ensure any projects using Foo also
>> use the exact same version of Bar that Foo was originally built with
>
> COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use
> case.
>
> You would populate an INTERFACE_ property on the INTERFACE target, which is
> whitelisted already:
>
>  https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties
>
>  http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813

Thanks - that's exactly what I was looking for!

Taylor

From ggarra13 at gmail.com  Tue Jan 19 20:42:58 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Tue, 19 Jan 2016 22:42:58 -0300
Subject: [CMake] Internal error bug in v3.4.2.
Message-ID: <569EE622.4070906@gmail.com>

I compiled v3.4.2 and after installing it in /usr/local, I tried running 
it in a project that was working fine with cmake 2.8.  I removed 
cmake2.8 from my computer.

I get:

-- Buildir /media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-57-generic-64/Release

> cd /media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-57-generic-64/Release/tmp


> cmake ../../../.. -DCMAKE_INSTALL_PREFIX=/usr/local -DEXECUTABLE_OUTPUT_PATH=/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-57-generic-64/Release/bin -DLIBRARY_OUTPUT_PATH=/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-57-generic-64/Release/lib -DCMAKE_LIBRARY_PATH=/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-57-generic-64/Release/lib -DCMAKE_NATIVE_ARCH=64 -DCMAKE_BUILD_ARCH=64 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CFG_INTDIR=/Release -G 'Ninja'

>>> BOOST LIBRARY DIR: /usr/lib
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
>>> BOOST LIBRARY DIR: /usr/lib
FLTK2_INCLUDE_DIR/usr/local/include/usr/local/include
-- SEARCH=/usr/local/bin/../lib;/usr/local/include/lib/x64/Release;/usr/local/include/lib/x64/Debug;/usr/lib;/usr/local/lib;/usr/local/fltk2/lib;/usr/X11R6/lib;/usr/local/include/lib/
FLTK2 LIBS=/usr/local/lib/libfltk2_images.so/usr/local/lib/libfltk2_gl.so-ljpeg-lz/usr/local/lib/libfltk2.so/usr/lib/x86_64-linux-gnu/libSM.so/usr/lib/x86_64-linux-gnu/libICE.so/usr/lib/x86_64-linux-gnu/libX11.so/usr/lib/x86_64-linux-gnu/libXext.so-lm
-- MAGICK: /VisualMagick/lib
IlmImf=/usr/local/lib/libIlmImf-2_2.so
/lib/x64/Release/lib/Win32/Release/lib/Release/lib/x64/Debug/lib/Debug/lib/lib/x64/Release/lib/Win32/Release/lib/Release/lib/x64/Debug/lib/Debug/lib/usr/local/lib64/usr/lib64
SEARCH DIRS=/bin/static/lib/libavcodec/libavdevice/libavfilter/libavformat/libavutil/libpostproc/libswscale/usr/local/lib64
-- FFMPEG_INCLUDE_DIR=/usr/local/include
-- FFMPEG_avutil_LIBRARY=/usr/local/lib/libavutil.so
-- FFMPEG_avformat_LIBRARY=/usr/local/lib/libavformat.so
-- FFMPEG_avcodec_LIBRARY=/usr/local/lib/libavcodec.so
-- FFMPEG_avdevice_LIBRARY=/usr/local/lib/libavdevice.so
-- FFMPEG_swscale_LIBRARY=/usr/local/lib/libswscale.so
-- FFMPEG_swresample_LIBRARY=/usr/local/lib/libswresample.so
-- GLEW ROOT=
-- LIBINTL was not found.
SampleICC_INCLUDE_DIR= /usr/local/include/SampleICC
SEARCH_INCLUDE_PATHS=  /IccProfLib;/SampleICC;/include/IccProfLib;/include/SampleICC;/include;/usr/include/w32api;/usr/X11R6/include;/usr/include/X11;/usr/pkg/include;/opt/csw/include;/opt/include;/usr/openwin/include;/usr/local/include/SampleICC;/usr/include/SampleICC
SEARCH_PATHS=  /usr/local/lib64;/opt/local/lib64;/opt/lib64;/usr/lib64
-- Found SampleICC: /usr/local/lib64/libSampleICC.so
-- -------------------------------------------------------------
-- Summary for mrViewer:
-- -------------------------------------------------------------
-- FLTK2:         YES
-- OpenEXR:       YES
-- ImageMagick:   YES 6.9.3
-- ffmpeg:        YES
-- Boost:         YES
-- TCLAP:         YES
-- CTL:           YES
-- libintl:       NO
-- TinyXML2:      YES
-- GLUT INCLUDE DIR=/usr/include
-- GLUT LIBRARIES=/usr/lib/x86_64-linux-gnu/libglut.so;/usr/lib/x86_64-linux-gnu/libXmu.so;/usr/lib/x86_64-linux-gnu/libXi.so
-- FLTK2 INCLUDE DIR=/usr/local/include
-- FLTK2 LIBRARIES=/usr/local/lib/libfltk2_images.so;/usr/local/lib/libfltk2_gl.so;-ljpeg;-lz;/usr/local/lib/libfltk2.so;/usr/lib/x86_64-linux-gnu/libSM.so;/usr/lib/x86_64-linux-gnu/libICE.so;/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so;-lm
-- ImageMagick   include: /usr/local/include/ImageMagick-6
-- ImageMagick   library: /usr/local/lib
-- ImageMagick++ include: /usr/local/include/ImageMagick-6
-- ImageMagick++ library: /usr/local/lib
-- ImageMagick++ libs:    /usr/local/lib/libMagick++-6.Q32HDRI.so;/usr/local/lib/libMagickWand-6.Q32HDRI.so;/usr/local/lib/libMagickCore-6.Q32HDRI.so
-- OpenEXR include:       /usr/local/include/OpenEXR
-- OpenEXR library:       /usr/local/lib
-- OpenEXR libs:          /usr/local/lib/libIlmImfUtil-2_2.so;/usr/local/lib/libIlmImf-2_2.so;/usr/local/lib/libImath-2_2.so;/usr/local/lib/libHalf.so;/usr/local/lib/libIexMath-2_2.so;/usr/local/lib/libIex-2_2.so;/usr/local/lib/libIlmThread-2_2.so
-- FLTK2 include:         /usr/local/include
-- FLTK2 library:         /usr/local/lib
-- FLTK2 libs:            /usr/local/lib/libfltk2_images.so;/usr/local/lib/libfltk2_gl.so;-ljpeg;-lz;/usr/local/lib/libfltk2.so;/usr/lib/x86_64-linux-gnu/libSM.so;/usr/lib/x86_64-linux-gnu/libICE.so;/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so;-lm
-- Boost include:         /usr/include
-- Boost library:         /usr/lib/x86_64-linux-gnu/libboost_locale.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so
-- ffmpeg include:        /usr/local/include
-- ffmpeg BSD  codecs:
-- ffmpeg LGPL codecs:    /usr/local/lib/libavcodec.so;/usr/local/lib/libavformat.so;/usr/local/lib/libswscale.so;/usr/local/lib/libswresample.so;/usr/local/lib/libavutil.so
-- ffmpeg libraries:      /usr/local/lib/libavcodec.so;/usr/local/lib/libavformat.so;/usr/local/lib/libswscale.so;/usr/local/lib/libswresample.so;/usr/local/lib/libavutil.so
-- TCLAP include:    /usr/local/include
-- CTL include:    /usr/local/include/CTL
-- CTL library:
-- CTL libraries:  /usr/local/lib/libIlmCtlSimd.so;/usr/local/lib/libIlmCtlMath.so;/usr/local/lib/libIlmCtl.so
-- OpenEXR CTL include:    /usr/local/include/OpenEXR
-- OpenEXR CTL library:
-- OpenEXR CTL libraries:  /usr/local/lib/libIlmCtlSimd.so;/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-57-generic-64/Release/lib/libIlmImfCtl.so
-- TinyXML2 include:    /usr/local/include
-- TinyXML2 library:    /usr/local/lib/x86_64-linux-gnu
-- TinyXML2 libraries:  /usr/local/lib/x86_64-linux-gnu/libtinyxml2.so
-- mrViewer version: 3.0.9
IlmImf=/usr/local/lib/libIlmImf-2_2.so
-- CTL_INCLUDE_DIR=/usr/local/include/CTL
-- OPENEXR_INCLUDE_DIR=/usr/local/include/OpenEXR
-- LIBRARIES=/usr/local/lib/libIlmCtlSimd.so;/usr/local/lib/libIlmCtlMath.so;/usr/local/lib/libIlmCtl.so;/usr/local/lib/libIlmImfUtil-2_2.so;/usr/local/lib/libIlmImf-2_2.so;/usr/local/lib/libImath-2_2.so;/usr/local/lib/libHalf.so;/usr/local/lib/libIexMath-2_2.so;/usr/local/lib/libIex-2_2.so;/usr/local/lib/libIlmThread-2_2.so;pthread
-- Found Cg: /usr/bin/cgc
-- Found CgGL: /usr/lib/x86_64-linux-gnu/libCgGL.so
-- CG_ROOT:
-- Cg include:   /usr/include/Cg
-- Cg libraries: /usr/lib/x86_64-linux-gnu/libCg.so
-- CgGL include:   /usr/include/Cg
-- CgGL libraries: /usr/lib/x86_64-linux-gnu/libCg.so
CMake Internal Error (please report a bug):
   Missing cmGeneratorTarget instance!

Note: The stack trace will not use advanced capabilities because this is a release build.
0x829476 : cmsys::SystemInformationImplementation::GetProgramStack(int, int) [(cmake) ???:-1]
0x82a459 : cmsys::SystemInformation::GetProgramStack(int, int) [(cmake) ???:-1]
0x5bb683 : displayMessage(cmake::MessageType, std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >&) [(cmake) ???:-1]
0x5c30e1 : cmake::IssueMessage(cmake::MessageType, std::string const&, cmListFileBacktrace const&) [(cmake) ???:-1]
0x73dfb3 : cmGlobalGenerator::GetGeneratorTarget(cmTarget const*) const [(cmake) ???:-1]
0x7078fe : TargetPropertyNode::Evaluate(std::vector<std::string, std::allocator<std::string> > const&, cmGeneratorExpressionContext*, GeneratorExpressionContent const*, cmGeneratorExpressionDAGChecker*) const [(cmake) ???:-1]
0x701220 : GeneratorExpressionContent::Evaluate(cmGeneratorExpressionContext*, cmGeneratorExpressionDAGChecker*) const [(cmake) ???:-1]
0x7157c0 : cmCompiledGeneratorExpression::EvaluateWithContext(cmGeneratorExpressionContext&, cmGeneratorExpressionDAGChecker*) const [(cmake) ???:-1]
0x715b88 : cmCompiledGeneratorExpression::Evaluate(cmMakefile*, std::string const&, bool, cmTarget const*, cmTarget const*, cmGeneratorExpressionDAGChecker*, std::string const&) const [(cmake) ???:-1]
0x59fc0d : ??? [(???) ???:-1]
0x5a9f21 : cmTarget::GetSourceFiles(std::vector<std::string, std::allocator<std::string> >&, std::string const&) const [(cmake) ???:-1]
0x5aa51d : cmTarget::GetSourceFiles(std::vector<cmSourceFile*, std::allocator<cmSourceFile*> >&, std::string const&) const [(cmake) ???:-1]
0x697281 : cmFLTKWrapUICommand::FinalPass() [(cmake) ???:-1]
0x54b9bd : cmMakefile::FinalPass() [(cmake) ???:-1]
0x54babd : cmMakefile::ConfigureFinalPass() [(cmake) ???:-1]
0x744f4e : cmGlobalGenerator::CheckTargetProperties() [(cmake) ???:-1]
0x74f039 : cmGlobalGenerator::Configure() [(cmake) ???:-1]
0x5ba660 : cmake::ActualConfigure() [(cmake) ???:-1]
0x5bf653 : cmake::Configure() [(cmake) ???:-1]
0x5c37fc : cmake::Run(std::vector<std::string, std::allocator<std::string> > const&, bool) [(cmake) ???:-1]
0x513446 : do_cmake(int, char const* const*) [(cmake) ???:-1]
0x514cbe : main [(cmake) ???:-1]
0x7f9fa3b14ec5 : __libc_start_main [(libc.so.6) ???:-1]
0x511d1a : ??? [(???) ???:-1]

Anything to try?

--
Gonzalo Garramu?o
ggarra13 at gmail.com


From dave at morsberger.com  Tue Jan 19 21:43:10 2016
From: dave at morsberger.com (David Morsberger)
Date: Tue, 19 Jan 2016 21:43:10 -0500
Subject: [CMake] XCode Generation Issue
In-Reply-To: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
Message-ID: <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>

Any help would be appreciated. 

In particular I?d like to know how the default compiler arguments are set when ?cmake -G Xcode? is executed. The attached file contains the cmake test compile extracted and reformatted from CMakeOutput.log that should have failed. Again, what is setting all the clang compiler options when this is executed?



All help is appreciated

> On Jan 18, 2016, at 2:58 PM, David Morsberger <dave at morsberger.com> wrote:
> 
> I?m having an issue generating and using a XCode project using cmake -G.
> 
> cmake ?version
>     cmake version 3.4.1
> 
> Xcode Version 7.2 (7C68)
> 
> Mac OS 10.11.
> 
> 
> My CMakeLists.txt has a clang option that fails during the -G Xcode pass but fails when linking within XCode.
> 
> The compiler / linker option is ?-Wl,?as-needed?
> 
> The test compile/link step in ?cmake -G Xcode' creates a long clang command with arguments ?-Wl,?as-needed? plus ??serialize-diagnostics <path to .dia file>?
> 
> The link step within Xcode after the project created has the ?-Wl,?as-needed? argument and does not have the ??serialize-diagnostics <path to .dia file>? argument. The link fails because ?-Wl,?as-needed? isn?t supported.
> 
> If copy and execute the long clang command from the ?cmake -G Xcode? command and remove the ??serialize-diagnostics <path to .dia file>? then it successfully fails with ?-Wl, ?as-needed? isn?t supported. 
> 
> Finally, when I use cmake to generate unix makefiles it works meaning cmake determines ?-Wl?as-needed? isn?t supported and doesn?t add it to the argument list.
> 
> Questions:
>  - Where is the ??serialized-diagnostics? argument coming from when executing ?cmake -G Xcode??
> 
>  - What is a .dia file and how do I read it?
> 
>  - What?s the preferred / recommended way of detecting the non-supported ?-Wl,?as-needed? argument during the ?cmake -G Xcode? phase? One option might to be to remove the ??serialize-diagnostics? argument during the generation phase.
> 
> I can provide more details on request.
> 
> David
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160119/971eb704/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: make_pass.sh.txt
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160119/971eb704/attachment-0001.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160119/971eb704/attachment-0003.html>

From ewmailing at gmail.com  Tue Jan 19 22:11:45 2016
From: ewmailing at gmail.com (Eric Wing)
Date: Tue, 19 Jan 2016 19:11:45 -0800
Subject: [CMake] XCode Generation Issue
In-Reply-To: <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
Message-ID: <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>

On 1/19/16, David Morsberger <dave at morsberger.com> wrote:
> Any help would be appreciated.
>
> In particular I?d like to know how the default compiler arguments are set
> when ?cmake -G Xcode? is executed. The attached file contains the cmake test
> compile extracted and reformatted from CMakeOutput.log that should have
> failed. Again, what is setting all the clang compiler options when this is
> executed?
>
>
>
> All help is appreciated
>
>> On Jan 18, 2016, at 2:58 PM, David Morsberger <dave at morsberger.com>
>> wrote:
>>
>> I?m having an issue generating and using a XCode project using cmake -G.
>>
>> cmake ?version
>>     cmake version 3.4.1
>>
>> Xcode Version 7.2 (7C68)
>>
>> Mac OS 10.11.
>>
>>
>> My CMakeLists.txt has a clang option that fails during the -G Xcode pass
>> but fails when linking within XCode.
>>
>> The compiler / linker option is ?-Wl,?as-needed?
>>
>> The test compile/link step in ?cmake -G Xcode' creates a long clang
>> command with arguments ?-Wl,?as-needed? plus ??serialize-diagnostics <path
>> to .dia file>?
>>
>> The link step within Xcode after the project created has the
>> ?-Wl,?as-needed? argument and does not have the ??serialize-diagnostics
>> <path to .dia file>? argument. The link fails because ?-Wl,?as-needed?
>> isn?t supported.
>>
>> If copy and execute the long clang command from the ?cmake -G Xcode?
>> command and remove the ??serialize-diagnostics <path to .dia file>? then
>> it successfully fails with ?-Wl, ?as-needed? isn?t supported.
>>
>> Finally, when I use cmake to generate unix makefiles it works meaning
>> cmake determines ?-Wl?as-needed? isn?t supported and doesn?t add it to the
>> argument list.
>>
>> Questions:
>>  - Where is the ??serialized-diagnostics? argument coming from when
>> executing ?cmake -G Xcode??
>>
>>  - What is a .dia file and how do I read it?
>>
>>  - What?s the preferred / recommended way of detecting the non-supported
>> ?-Wl,?as-needed? argument during the ?cmake -G Xcode? phase? One option
>> might to be to remove the ??serialize-diagnostics? argument during the
>> generation phase.
>>
>> I can provide more details on request.
>>
>> David
>>
>>
>>


I just spot checked one of my Xcode compile logs. I see the
?serialize-diagnostics flag, but I don't have ?as-needed anywhere.
Maybe one of your CMake scripts is adding that in, or you have set
some kind of environment variable that clang or Xcode is picking up?
(This recently happened to me on Linux.)

From andrew.amaclean at gmail.com  Tue Jan 19 23:48:52 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 20 Jan 2016 15:48:52 +1100
Subject: [CMake] [ANNOUNCE] CMake 3.4.2 available for download
Message-ID: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>

Works well, although I did find that I had to update my Windows SDK
to 10.0.10586.0 when using Visual Studio 2015 on Windows 10. This is
because CMake detected the system as Windows - 10.0.10586 - AMD64.

This was not the case with the previous version of CMake (3.4.1).

Andrew



> ---------- Forwarded message ----------
> From: Robert Maynard <robert.maynard at kitware.com>
> To: CMake MailingList <cmake at cmake.org>
> Cc:
> Date: Tue, 19 Jan 2016 15:14:31 -0500
> Subject: [CMake] [ANNOUNCE] CMake 3.4.2 available for download
> We are pleased to announce that CMake 3.4.2 is now available for download.
>
> Please use the latest release from our download page:
>   https://cmake.org/download/
>
> Thanks for your support!
>
> -------------------------------------------------------------------------
> Changes in 3.4.2 since 3.4.1:
>
> Brad King (6):
>     CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889)
>     VS: Do not select a partial Windows 10 SDK folder (#15831)
>     VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation
> (#15894)
>     cmSystemTools: Add VersionCompareEqual helper
>     VS: Fix Windows 10 SDK version selection (#15831)
>     CMake 3.4.2
>
> Marc Chevrier (2):
>     FindJava: Fix typos in IdlJ and JarSigner component implementation
>     AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
>



-- 
___________________________________________
Andrew J. P. Maclean

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

From nikita.barawade at einfochips.com  Wed Jan 20 05:20:11 2016
From: nikita.barawade at einfochips.com (Nikita Barawade)
Date: Wed, 20 Jan 2016 10:20:11 +0000
Subject: [CMake] Alternative to CMAKE_PREFIX_PATH
In-Reply-To: <CAKGHxZzcxckguiQUY-OFzRGkRgwFuTi2s+LfxBEkajuR6rUh3A@mail.gmail.com>
References: <PS1PR02MB1401C9CAB970962DC15CD0DA86C00@PS1PR02MB1401.apcprd02.prod.outlook.com>,
 <CAKGHxZzcxckguiQUY-OFzRGkRgwFuTi2s+LfxBEkajuR6rUh3A@mail.gmail.com>
Message-ID: <PS1PR02MB1401840AFB51A8F3E691A42286C20@PS1PR02MB1401.apcprd02.prod.outlook.com>



Hi,

I set CMAKE_PREFIX_PATH in system's environment variable on windows but cmake does not check for it.
can we make cmake to search for system's environment variable as happens in Linux ?


Regards,
Nikita


________________________________
From: Guillaume Dumont <dumont.guillaume at gmail.com>
Sent: 18 January 2016 08:16 PM
To: Nikita Barawade
Cc: cmake at cmake.org
Subject: Re: [CMake] Alternative to CMAKE_PREFIX_PATH

A better alternative would be to use the command line switch -DCMAKE_PREFIX_PATH=<Qt install location> or similarly via CMake-GUI. Or you could also use the env var. See https://cmake.org/cmake/help/v3.3/command/find_package.html?highlight=cmake_prefix_path for search order.

On Mon, Jan 18, 2016 at 9:08 AM, Nikita Barawade <nikita.barawade at einfochips.com<mailto:nikita.barawade at einfochips.com>> wrote:



Hi,

My project needs Qt5   .

Adding
find_package (Qt5Widgets)
to CMakeLists.txt  could not find Qt .

So I added,
set (CMAKE_PREFIX_PATH
"< Qt installation  path>")

It is working fine now. But is there any alternative to find qt5 package  without  hardcoding  CMAKE_PREFIX_PATH ?

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



--
Guillaume Dumont
=========================
dumont.guillaume at gmail.com<mailto:dumont.guillaume at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160120/72f50796/attachment-0001.html>

From attila.krasznahorkay at gmail.com  Wed Jan 20 05:26:04 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Wed, 20 Jan 2016 11:26:04 +0100
Subject: [CMake] Creating RPMs from failing projects with CPack
Message-ID: <32FCFA2A-94CD-4C9B-9C54-9928FD5E98D9@gmail.com>

Dear All,

I have a slightly unusual question (I guess). Is it possible somehow to force CPack to produce RPM files from projects that have build problems?

We use CMake in our nightly build system to test the latest changes in our software. When a build problem occurs we don't want the whole build to fail. To this end, we run the build with:

make -k
make -k install/fast

This second target executes the installation no matter what. (We set all our build results as "optional installations".) So that at least the "successful part" of the build would become visible on a shared filesystem.

Now, I'd like to do something similar with CPack. To make it behave like "install/fast" does. All in all, I'd like to tell it to use this "install/fast" target while creating the package instead of the "install" target. Is there any way of making this happen?

Cheers,
              Attila

From dave at morsberger.com  Wed Jan 20 07:21:16 2016
From: dave at morsberger.com (David Morsberger)
Date: Wed, 20 Jan 2016 07:21:16 -0500
Subject: [CMake] XCode Generation Issue
In-Reply-To: <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
 <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
Message-ID: <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>


> On Jan 19, 2016, at 10:11 PM, Eric Wing <ewmailing at gmail.com> wrote:
> 
> On 1/19/16, David Morsberger <dave at morsberger.com> wrote:
>> Any help would be appreciated.
>> 
>> In particular I?d like to know how the default compiler arguments are set
>> when ?cmake -G Xcode? is executed. The attached file contains the cmake test
>> compile extracted and reformatted from CMakeOutput.log that should have
>> failed. Again, what is setting all the clang compiler options when this is
>> executed?
>> 
>> 
>> 
>> All help is appreciated
>> 
>>> On Jan 18, 2016, at 2:58 PM, David Morsberger <dave at morsberger.com>
>>> wrote:
>>> 
>>> I?m having an issue generating and using a XCode project using cmake -G.
>>> 
>>> cmake ?version
>>>    cmake version 3.4.1
>>> 
>>> Xcode Version 7.2 (7C68)
>>> 
>>> Mac OS 10.11.
>>> 
>>> 
>>> My CMakeLists.txt has a clang option that fails during the -G Xcode pass
>>> but fails when linking within XCode.
>>> 
>>> The compiler / linker option is ?-Wl,?as-needed?
>>> 
>>> The test compile/link step in ?cmake -G Xcode' creates a long clang
>>> command with arguments ?-Wl,?as-needed? plus ??serialize-diagnostics <path
>>> to .dia file>?
>>> 
>>> The link step within Xcode after the project created has the
>>> ?-Wl,?as-needed? argument and does not have the ??serialize-diagnostics
>>> <path to .dia file>? argument. The link fails because ?-Wl,?as-needed?
>>> isn?t supported.
>>> 
>>> If copy and execute the long clang command from the ?cmake -G Xcode?
>>> command and remove the ??serialize-diagnostics <path to .dia file>? then
>>> it successfully fails with ?-Wl, ?as-needed? isn?t supported.
>>> 
>>> Finally, when I use cmake to generate unix makefiles it works meaning
>>> cmake determines ?-Wl?as-needed? isn?t supported and doesn?t add it to the
>>> argument list.
>>> 
>>> Questions:
>>> - Where is the ??serialized-diagnostics? argument coming from when
>>> executing ?cmake -G Xcode??
>>> 
>>> - What is a .dia file and how do I read it?
>>> 
>>> - What?s the preferred / recommended way of detecting the non-supported
>>> ?-Wl,?as-needed? argument during the ?cmake -G Xcode? phase? One option
>>> might to be to remove the ??serialize-diagnostics? argument during the
>>> generation phase.
>>> 
>>> I can provide more details on request.
>>> 
>>> David
>>> 
>>> 
>>> 
> 
> 
> I just spot checked one of my Xcode compile logs. I see the
> ?serialize-diagnostics flag, but I don't have ?as-needed anywhere.
> Maybe one of your CMake scripts is adding that in, or you have set
> some kind of environment variable that clang or Xcode is picking up?
> (This recently happened to me on Linux.)

Ed,

In this case cmake is attempting to determine if ??as-needed' is a supported option and the build should fail. 

I have searched (grep?d) everything I can think of for the string ?serialize-diagnostics? with zero hits. 

I can easily add an ?if( Xcode )? around the setting in CMakeLists.txt however I?m trying to figure out what is exactly going on. The best solutions are chosen when you know what is going on under the hood.




From brad.king at kitware.com  Wed Jan 20 08:26:39 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jan 2016 08:26:39 -0500
Subject: [CMake] CMake 3.4.2 available for download
In-Reply-To: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
Message-ID: <569F8B0F.1090002@kitware.com>

On 01/19/2016 11:48 PM, Andrew Maclean wrote:
> Works well, although I did find that I had to update my Windows SDK
> to 10.0.10586.0 when using Visual Studio 2015 on Windows 10.
> This is because CMake detected the system as Windows - 10.0.10586 - AMD64. 
> This was not the case with the previous version of CMake (3.4.1).

That is due to this fix:

 VS: Fix Windows 10 SDK version selection (#15831)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57caf7e

See commit message for details.  It shouldn't have /required/ you to
update the SDK though because the fallback is now to just use the latest
SDK available.  What indicated that you needed to update?

Thanks,
-Brad


From brad.king at kitware.com  Wed Jan 20 09:24:25 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jan 2016 09:24:25 -0500
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <569EE622.4070906@gmail.com>
References: <569EE622.4070906@gmail.com>
Message-ID: <569F9899.9050804@kitware.com>

On 01/19/2016 08:42 PM, Gonzalo wrote:
> I compiled v3.4.2 and after installing it in /usr/local, I tried running 
> it in a project that was working fine with cmake 2.8.

Thanks for reporting this.  The 2.8 series was quite long.  To help narrow
the changes between these versions, what 2.8 version were you using?

> CMake Internal Error (please report a bug):
>    Missing cmGeneratorTarget instance!
[snip]
> 0x5aa51d : cmTarget::GetSourceFiles(std::vector<cmSourceFile*, std::allocator<cmSourceFile*> >&, std::string const&) const [(cmake) ???:-1]
> 0x697281 : cmFLTKWrapUICommand::FinalPass() [(cmake) ???:-1]
> 0x54b9bd : cmMakefile::FinalPass() [(cmake) ???:-1]
> 0x54babd : cmMakefile::ConfigureFinalPass() [(cmake) ???:-1]

This looks like the FLTK_WRAP_UI() command is not working for you.
The command is a holdover from very early CMake days when we did not
have modern add_custom_command and macro/function capabilities.
AFAIK it is not widely used and has only minimal coverage in CMake's
test suite.

I cloned mrViewer but it has way too many dependencies for me to try
to configure a full build locally.  I stripped down the

  mrViewer/src/CMakeLists.txt

enough to get it to configure and call FLTK_WRAP_UI but I'm unable to
reproduce this problem.

Please try stripping the CMake files in mrViewer down a bit at a time
until the problem goes away and then try to use that to produce a
small example demonstrating the problem.

Thanks,
-Brad


From fkillus at googlemail.com  Wed Jan 20 12:41:26 2016
From: fkillus at googlemail.com (fkillus)
Date: Wed, 20 Jan 2016 18:41:26 +0100
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
Message-ID: <CACaBFwyxEQhhT_JOtf0pgQ31VooO6MU3p=xKh_m+eJERi8mOqw@mail.gmail.com>

I have been trying to compile Ogre [1] as external dependency with
ExternalProject_Add(). In theory this should be straightforward since Ogre
itself also uses CMake as buildsystem. However, in the process I
encountered the following problem:

Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
places (e.g. [2]). I am running Linux and compiling with g++ and everything
works fine if I manually configure Ogre with cmake or cmake-gui.
Unfortunately, after wrapping everything inside ExternalProject_Add(), the
CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.

A simple workaround is to manually set this variable, i.e.:

 ExternalProject_Add(
    ogre
    URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
    CMAKE_ARGS
      -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
      -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   # workaround
  )

This works, but I'm uncertain if this should be necessary. Is this a bug or
a feature?


[1] https://bitbucket.org/sinbad/ogre
[2]
https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160120/df4b8e0d/attachment.html>

From nicholas11braden at gmail.com  Wed Jan 20 12:58:46 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Wed, 20 Jan 2016 11:58:46 -0600
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
In-Reply-To: <CACaBFwyxEQhhT_JOtf0pgQ31VooO6MU3p=xKh_m+eJERi8mOqw@mail.gmail.com>
References: <CACaBFwyxEQhhT_JOtf0pgQ31VooO6MU3p=xKh_m+eJERi8mOqw@mail.gmail.com>
Message-ID: <CAHk1PgESiSGw-23ViQ77M7B-0eLCLc+1=k7uhaayWtF_weneBw@mail.gmail.com>

Where/how is that variable normally set? External projects have no
awareness of the project they are in, they just run CMake as usual the
same way you would. If the variable is normally set by CMake itself,
make sure that your containing project and the external project both
find the same compiler. (They each do their own automatic search for
compilers)

On Wed, Jan 20, 2016 at 11:41 AM, fkillus via CMake <cmake at cmake.org> wrote:
> I have been trying to compile Ogre [1] as external dependency with
> ExternalProject_Add(). In theory this should be straightforward since Ogre
> itself also uses CMake as buildsystem. However, in the process I encountered
> the following problem:
>
> Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
> places (e.g. [2]). I am running Linux and compiling with g++ and everything
> works fine if I manually configure Ogre with cmake or cmake-gui.
> Unfortunately, after wrapping everything inside ExternalProject_Add(), the
> CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
>
> A simple workaround is to manually set this variable, i.e.:
>
>  ExternalProject_Add(
>     ogre
>     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
>     CMAKE_ARGS
>       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
>       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   # workaround
>   )
>
> This works, but I'm uncertain if this should be necessary. Is this a bug or
> a feature?
>
>
> [1] https://bitbucket.org/sinbad/ogre
> [2]
> https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 ggarra13 at gmail.com  Wed Jan 20 13:16:16 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Wed, 20 Jan 2016 15:16:16 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <569F9899.9050804@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
Message-ID: <569FCEF0.3010504@gmail.com>



El 20/01/16 a las 11:24, Brad King escribi?:
> On 01/19/2016 08:42 PM, Gonzalo wrote:
>> I compiled v3.4.2 and after installing it in /usr/local, I tried running
>> it in a project that was working fine with cmake 2.8.
> Thanks for reporting this.  The 2.8 series was quite long.  To help narrow
> the changes between these versions, what 2.8 version were you using?
$ cmake --version
cmake version 2.8.12.2


> Please try stripping the CMake files in mrViewer down a bit at a time 
> until the problem goes away and then try to use that to produce a 
> small example demonstrating the problem. 
I'll try that.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From wonder.mice at gmail.com  Wed Jan 20 15:02:18 2016
From: wonder.mice at gmail.com (Andrey Pokrovskiy)
Date: Wed, 20 Jan 2016 12:02:18 -0800
Subject: [CMake] Customizing output of ctest command
Message-ID: <CAH23LE6w_UyfQE8KoGOUmGWNxhG-L59Nqaws+sF+oncEVLQbtQ@mail.gmail.com>

Hi,

One of my tests generates a report table (file in text format). I
would like to see its content after each ctest (or make test)
invocation. Is there any way to achieve that?
I noticed that tests targets have ATTACHED_FILES property, though it
looks like it has no effect on ctest run when dashboard is not
configured. I don't need and don't want to setup dashboard, but I
would like to include information that is important to me in ctest
output.

For example:

[...]
Start 33: run_tests
33/33 Test #33: run_tests .............................   Passed    0.06 sec

100% tests passed, 0 tests failed out of 33

Total Test time (real) =   0.28 sec

/* Attached: results.json */
{
    "call_site_size": {
        "zf_log": "48",
        "easylogging++": "376",
        "glog": "144",
        "spdlog": "352",
        "g3log": "360"
    }
}

From andrew.amaclean at gmail.com  Wed Jan 20 16:36:46 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Thu, 21 Jan 2016 08:36:46 +1100
Subject: [CMake] CMake 3.4.2 available for download
In-Reply-To: <569F8B0F.1090002@kitware.com>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
Message-ID: <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>

Hi Brad,

I can reproduce this on my other windows machine. Just a guess but it may
be related to Update 1 of Visual Studio 2015. I can't test this hypothesis
because I have update 1 installed on both machines. Note that everything
works Ok for Visual Studio 2013.

Here are the details:
Here is the error:
"CMake Error at CMakeLists.txt:1 (project):
  Could not find an appropriate version of the Windows 10 SDK installed on
  this machine"

In CMakeOutput.log, there is one line:
"The system is: Windows - 10.0.10586 - AMD64"

On the machine I have the following SDK versions in C:\Program Files
(x86)\Windows Kits\10:
10.0.10150.0 and 10.0.10240.0.

Installing the latest version of the SDK will fix this issue.

The compiler is: Visual Studio 14 2015 Win64. I am using update 1 for this
compiler.

If I use Visual Studio 12 2013 Win64, everything is Ok.

Regards
   Andrew




On Thu, Jan 21, 2016 at 12:26 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/19/2016 11:48 PM, Andrew Maclean wrote:
> > Works well, although I did find that I had to update my Windows SDK
> > to 10.0.10586.0 when using Visual Studio 2015 on Windows 10.
> > This is because CMake detected the system as Windows - 10.0.10586 -
> AMD64.
> > This was not the case with the previous version of CMake (3.4.1).
>
> That is due to this fix:
>
>  VS: Fix Windows 10 SDK version selection (#15831)
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57caf7e
>
> See commit message for details.  It shouldn't have /required/ you to
> update the SDK though because the fallback is now to just use the latest
> SDK available.  What indicated that you needed to update?
>
> Thanks,
> -Brad
>
>


-- 
___________________________________________
Andrew J. P. Maclean

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

From ggarra13 at gmail.com  Wed Jan 20 17:21:52 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Wed, 20 Jan 2016 19:21:52 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <569FD74E.8000708@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
Message-ID: <56A00880.8030901@gmail.com>



El 20/01/16 a las 15:51, Brad King escribi?:
> On 01/20/2016 01:46 PM, Gonzalo wrote:
>> So that I know.  What's the way of using FLTK now with cmake if
>> FLTK_WRAP_UI is gone.
> It's not gone or even deprecated.  It's just not well tested
> and seems to be broken in your particular case in a way not
> reproduced by the test.
>
> I don't know much about FLTK or recall specifically what the
> command does but I think it is about running "fluid" to generate
> some source files.  This can now be done with add_custom_command
> calls, which could be packaged inside a macro or function that
> takes the place of fltk_wrap_ui().  That is what is done for
> similar use cases with other GUI toolkits.  FLTK just happened
> to be one of the early use cases back at a time when everything
> needed a new command.
>
> Either way we should fix fltk_wrap_ui() in support of existing
> projects.
Thanks, Brad.  I think the test does not pick the problem because it 
deals with fltk1 only.  I am using fltk2 (bad idea, I know). 
FLTK_WRAP_UI relied on FLTK_FLUID_EXECUTABLE to create a .cxx and .h 
file of the .fl files.  It is possible and likely that fluid2 does not 
support all flags of fluid1.  I would like to see what command gets 
passed onto fluid.  Is there a debug way of showing that?

In the near future I think wrapping the command in a custom function 
will work just as well or better.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From audiofanatic at gmail.com  Wed Jan 20 17:44:28 2016
From: audiofanatic at gmail.com (Craig Scott)
Date: Thu, 21 Jan 2016 09:44:28 +1100
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
Message-ID: <CACQP5UfxPQ54ojx-Fx19=CTp16QEKLe0mhTTTobbmghbJbpT3A@mail.gmail.com>

> From: fkillus <fkillus at googlemail.com>
> To: cmake at cmake.org
> Cc:
> Date: Wed, 20 Jan 2016 18:41:26 +0100
> Subject: [CMake] ExternalProject_Add() macro does not set
> CMAKE_COMPILER_IS_GNUCXX
> I have been trying to compile Ogre [1] as external dependency with
> ExternalProject_Add(). In theory this should be straightforward since Ogre
> itself also uses CMake as buildsystem. However, in the process I
> encountered the following problem:
>

> Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
> places (e.g. [2]). I am running Linux and compiling with g++ and everything
> works fine if I manually configure Ogre with cmake or cmake-gui.
> Unfortunately, after wrapping everything inside ExternalProject_Add(), the
> CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
>
> A simple workaround is to manually set this variable, i.e.:
>
>  ExternalProject_Add(
>     ogre
>     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
>     CMAKE_ARGS
>       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
>       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   # workaround
>   )
>
> This works, but I'm uncertain if this should be necessary. Is this a bug
> or a feature?
>
>
> [1] https://bitbucket.org/sinbad/ogre
> [2]
> https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
>
>

Since Ogre is a CMake project, you may find the technique described at the
following link useful. It uses GoogleTest as its example, but it should
also apply to your situation. The approach uses ExternalProject only to
download the source at CMake time. It then pulls it into your normal build
via add_subdirectory(), so it gets all the same compiler details, etc. as
your main build because it IS part of your main build.

http://crascit.com/2015/07/25/cmake-gtest/

I am not familiar with Ogre's build, so I can't comment on whether it will
play nice if pulled into a parent build like this, but it's worth a try.
The article links to a github repo which provides a fully generalised
implementation you should be able to use out of the box.


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

From ggarra13 at gmail.com  Wed Jan 20 18:34:08 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Wed, 20 Jan 2016 20:34:08 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <569FD74E.8000708@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
Message-ID: <56A01970.5090008@gmail.com>



El 20/01/16 a las 15:51, Brad King escribi?:
> I don't know much about FLTK or recall specifically what the command 
> does but I think it is about running "fluid" to generate some source 
> files. This can now be done with add_custom_command calls, which could 
> be packaged inside a macro or function that takes the place of 
> fltk_wrap_ui(). That is what is done for similar use cases with other 
> GUI toolkits. FLTK just happened to be one of the early use cases back 
> at a time when everything needed a new command. 
Your recollection is correct.  I tried a simple sample with FLTK2 and it 
works fine (the flags passed are compatible).  So I am puzzled.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From domen.vrankar at gmail.com  Wed Jan 20 18:49:45 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 21 Jan 2016 00:49:45 +0100
Subject: [CMake] Creating RPMs from failing projects with CPack
In-Reply-To: <32FCFA2A-94CD-4C9B-9C54-9928FD5E98D9@gmail.com>
References: <32FCFA2A-94CD-4C9B-9C54-9928FD5E98D9@gmail.com>
Message-ID: <CAKgx6BLz1g48xEAS7Pc02KamRebnGMgyMXDY+TwbgFXFW_f8dQ@mail.gmail.com>

> I have a slightly unusual question (I guess). Is it possible somehow to force CPack to produce RPM files from projects that have build problems?
>
> We use CMake in our nightly build system to test the latest changes in our software. When a build problem occurs we don't want the whole build to fail. To this end, we run the build with:
>
> make -k
> make -k install/fast
>
> This second target executes the installation no matter what. (We set all our build results as "optional installations".) So that at least the "successful part" of the build would become visible on a shared filesystem.
>
> Now, I'd like to do something similar with CPack. To make it behave like "install/fast" does. All in all, I'd like to tell it to use this "install/fast" target while creating the package instead of the "install" target. Is there any way of making this happen?

I don't know of any clean way to do this but you could write an
install script (let's name it install_k.sh):

#!/bin/bash
make -k install/fast
exit 0

Then your would add two CPACK variables to your CMakeLists.txt:

#set(CPACK_RPM_COMPONENT_INSTALL "ON") <- I'll explain this commented line later
set(CPACK_INSTALL_CMAKE_PROJECTS "")
set(CPACK_INSTALL_COMMANDS "${CMAKE_CURRENT_SOURCE_DIR}/install_k.sh")

And instead of packaging with "make package" command execute "cpack -G RPM".

However there is an additional problem that this hack only works for
monolithic packages (that's why I commented out
CPACK_RPM_COMPONENT_INSTALL in example above) so you will have to
disable component packages generation if you are using it.

Regards,
Domen

2016-01-20 11:26 GMT+01:00 Attila Krasznahorkay
<attila.krasznahorkay at gmail.com>:
> Dear All,
>
> I have a slightly unusual question (I guess). Is it possible somehow to force CPack to produce RPM files from projects that have build problems?
>
> We use CMake in our nightly build system to test the latest changes in our software. When a build problem occurs we don't want the whole build to fail. To this end, we run the build with:
>
> make -k
> make -k install/fast
>
> This second target executes the installation no matter what. (We set all our build results as "optional installations".) So that at least the "successful part" of the build would become visible on a shared filesystem.
>
> Now, I'd like to do something similar with CPack. To make it behave like "install/fast" does. All in all, I'd like to tell it to use this "install/fast" target while creating the package instead of the "install" target. Is there any way of making this happen?
>
> Cheers,
>               Attila
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 ewmailing at gmail.com  Thu Jan 21 01:51:31 2016
From: ewmailing at gmail.com (Eric Wing)
Date: Wed, 20 Jan 2016 22:51:31 -0800
Subject: [CMake] XCode Generation Issue
In-Reply-To: <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
 <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
 <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>
Message-ID: <CA+Q62MBkeRDXEzt7dEpeQbzixV83OpyWAbPg92nSUhv3zS3Ksg@mail.gmail.com>

On 1/20/16, David Morsberger <dave at morsberger.com> wrote:
>
>> On Jan 19, 2016, at 10:11 PM, Eric Wing <ewmailing at gmail.com> wrote:
>>
>> On 1/19/16, David Morsberger <dave at morsberger.com> wrote:
>>> Any help would be appreciated.
>>>
>>> In particular I?d like to know how the default compiler arguments are
>>> set
>>> when ?cmake -G Xcode? is executed. The attached file contains the cmake
>>> test
>>> compile extracted and reformatted from CMakeOutput.log that should have
>>> failed. Again, what is setting all the clang compiler options when this
>>> is
>>> executed?
>>>
>>>
>>>
>>> All help is appreciated
>>>
>>>> On Jan 18, 2016, at 2:58 PM, David Morsberger <dave at morsberger.com>
>>>> wrote:
>>>>
>>>> I?m having an issue generating and using a XCode project using cmake
>>>> -G.
>>>>
>>>> cmake ?version
>>>>    cmake version 3.4.1
>>>>
>>>> Xcode Version 7.2 (7C68)
>>>>
>>>> Mac OS 10.11.
>>>>
>>>>
>>>> My CMakeLists.txt has a clang option that fails during the -G Xcode
>>>> pass
>>>> but fails when linking within XCode.
>>>>
>>>> The compiler / linker option is ?-Wl,?as-needed?
>>>>
>>>> The test compile/link step in ?cmake -G Xcode' creates a long clang
>>>> command with arguments ?-Wl,?as-needed? plus ??serialize-diagnostics
>>>> <path
>>>> to .dia file>?
>>>>
>>>> The link step within Xcode after the project created has the
>>>> ?-Wl,?as-needed? argument and does not have the ??serialize-diagnostics
>>>> <path to .dia file>? argument. The link fails because ?-Wl,?as-needed?
>>>> isn?t supported.
>>>>
>>>> If copy and execute the long clang command from the ?cmake -G Xcode?
>>>> command and remove the ??serialize-diagnostics <path to .dia file>?
>>>> then
>>>> it successfully fails with ?-Wl, ?as-needed? isn?t supported.
>>>>
>>>> Finally, when I use cmake to generate unix makefiles it works meaning
>>>> cmake determines ?-Wl?as-needed? isn?t supported and doesn?t add it to
>>>> the
>>>> argument list.
>>>>
>>>> Questions:
>>>> - Where is the ??serialized-diagnostics? argument coming from when
>>>> executing ?cmake -G Xcode??
>>>>
>>>> - What is a .dia file and how do I read it?
>>>>
>>>> - What?s the preferred / recommended way of detecting the non-supported
>>>> ?-Wl,?as-needed? argument during the ?cmake -G Xcode? phase? One option
>>>> might to be to remove the ??serialize-diagnostics? argument during the
>>>> generation phase.
>>>>
>>>> I can provide more details on request.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>
>>
>> I just spot checked one of my Xcode compile logs. I see the
>> ?serialize-diagnostics flag, but I don't have ?as-needed anywhere.
>> Maybe one of your CMake scripts is adding that in, or you have set
>> some kind of environment variable that clang or Xcode is picking up?
>> (This recently happened to me on Linux.)
>
> Ed,
>
> In this case cmake is attempting to determine if ??as-needed' is a supported
> option and the build should fail.
>
> I have searched (grep?d) everything I can think of for the string
> ?serialize-diagnostics? with zero hits.
>
> I can easily add an ?if( Xcode )? around the setting in CMakeLists.txt
> however I?m trying to figure out what is exactly going on. The best
> solutions are chosen when you know what is going on under the hood.
>
>
>

I believe the serialize-diagnostics flag is added by Xcode itself. I
see it (along with many other flags) in a native (non-CMake generated)
Xcode project.

-Eric

From csiga.biga at aol.com  Thu Jan 21 04:57:09 2016
From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=)
Date: Thu, 21 Jan 2016 10:57:09 +0100
Subject: [CMake] Customizing output of ctest command
In-Reply-To: <CAH23LE6w_UyfQE8KoGOUmGWNxhG-L59Nqaws+sF+oncEVLQbtQ@mail.gmail.com>
References: <CAH23LE6w_UyfQE8KoGOUmGWNxhG-L59Nqaws+sF+oncEVLQbtQ@mail.gmail.com>
Message-ID: <mailman.2.1453370234.8417.cmake@cmake.org>


I would also be very much interested how this could be done. There was a thread I started a few months ago on a similar topic. I wanted to see the execution times of various tests without the initialization part. If my tests could output in some form the useful part of their run times, it would be nice if CTest could collect them and print them to console.



Felad?: Andrey Pokrovskiy
Elk?ldve: 2016. janu?r 20., szerda 21:02
C?mzett: CMake ML
T?rgy: [CMake] Customizing output of ctest command

Hi,

One of my tests generates a report table (file in text format). I
would like to see its content after each ctest (or make test)
invocation. Is there any way to achieve that?
I noticed that tests targets have ATTACHED_FILES property, though it
looks like it has no effect on ctest run when dashboard is not
configured. I don't need and don't want to setup dashboard, but I
would like to include information that is important to me in ctest
output.

For example:

[...]
Start 33: run_tests
33/33 Test #33: run_tests .............................   Passed    0.06 sec

100% tests passed, 0 tests failed out of 33

Total Test time (real) =   0.28 sec

/* Attached: results.json */
{
    "call_site_size": {
        "zf_log": "48",
        "easylogging++": "376",
        "glog": "144",
        "spdlog": "352",
        "g3log": "360"
    }
}
-- 

Powered by www.kitware.com

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

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

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

From ggarra13 at gmail.com  Thu Jan 21 07:53:05 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Thu, 21 Jan 2016 09:53:05 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <569FD74E.8000708@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
Message-ID: <56A0D4B1.3040009@gmail.com>



El 20/01/16 a las 15:51, Brad King escribi?:
> It's not gone or even deprecated.  It's just not well tested
> and seems to be broken in your particular case in a way not
> reproduced by the test.
I delved into the cmake 3.4.2 source code and found the offending line 
in cmTarget.cxx:

     cmSystemTools::ExpandListArgument((*it)->ge->Evaluate(mf,
                                               config,
                                               false,
                                               tgt,
                                               tgt,
                                               dagChecker),
                                     entrySources);

This line never ends up calling ExpandListArgument and crashes before.  
All variables are defined but I am suspicious of the (*it)->ge auto 
pointer, but cannot comment further.
I hope this helps you track it.


-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From brad.king at kitware.com  Thu Jan 21 08:28:58 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jan 2016 08:28:58 -0500
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <56A0D4B1.3040009@gmail.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
 <56A0D4B1.3040009@gmail.com>
Message-ID: <56A0DD1A.5010504@kitware.com>

On 01/21/2016 07:53 AM, Gonzalo wrote:
> I delved into the cmake 3.4.2 source code and found the offending line 
> in cmTarget.cxx:
> 
>      cmSystemTools::ExpandListArgument((*it)->ge->Evaluate(mf,
>                                                config,
>                                                false,
>                                                tgt,
>                                                tgt,
>                                                dagChecker),
>                                      entrySources);
> 
> This line never ends up calling ExpandListArgument and crashes before.  
> All variables are defined but I am suspicious of the (*it)->ge auto 
> pointer, but cannot comment further.

Thanks.  This is consistent with the call stack shown in your original
post.  That line is always executed so we need to figure out what goes
wrong with it in your particular case.  Since you can reproduce it in
mrViewer's configuration that is a good starting point.  Try removing
sources and libraries from mrViewer/src/CMakeLists.txt to simplify
it while still reproducing the problem.  If you can get rid of most
of the find_package calls at the top and the uses of their results
while still showing the problem then I can likely use that to get
the problem reproduced locally.

Thanks,
-Brad


From brad.king at kitware.com  Thu Jan 21 08:38:55 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jan 2016 08:38:55 -0500
Subject: [CMake] CMake 3.4.2 available for download
In-Reply-To: <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
Message-ID: <56A0DF6F.4020402@kitware.com>

On 01/20/2016 04:36 PM, Andrew Maclean wrote:
> "CMake Error at CMakeLists.txt:1 (project):
>   Could not find an appropriate version of the Windows 10 SDK installed on
>   this machine"
>   
> In CMakeOutput.log, there is one line:
> "The system is: Windows - 10.0.10586 - AMD64"

It looks like this has been reported to the issue tracker here:

 https://cmake.org/Bug/view.php?id=15929

Please follow discussion over there for more.

Thanks,
-Brad


From dave at morsberger.com  Thu Jan 21 09:07:03 2016
From: dave at morsberger.com (David Morsberger)
Date: Thu, 21 Jan 2016 09:07:03 -0500
Subject: [CMake] XCode Generation Issue
In-Reply-To: <CA+Q62MBkeRDXEzt7dEpeQbzixV83OpyWAbPg92nSUhv3zS3Ksg@mail.gmail.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
 <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
 <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>
 <CA+Q62MBkeRDXEzt7dEpeQbzixV83OpyWAbPg92nSUhv3zS3Ksg@mail.gmail.com>
Message-ID: <404CBD9D-EB12-4D3A-94E6-F0CFA0925283@morsberger.com>

Eric,

I went down a rabbit hole and pulled myself back out. I narrowed it down to the following.

We are using cmake to check if the linker supports -Wl,?as-needed. The test compile (and link?) command cmake builds using ?cmake -G Xcode?  does not fail.

The command from ?cmake -G? has been narrowed down to the following:

$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \
 -Qunused-arguments \
 -DWS_LD_FLAG_VALID0 \
 -Wl,--as-needed \
 -c src.c \
 -o src.o 
$

The following modified command generates an error:

$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \
 -Qunused-arguments \
 -DWS_LD_FLAG_VALID0 \
 -Wl,--as-needed \
 src.c

ld: unknown option: --as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$

It appears the linker isn?t called when the -c and the -o options are present. The following warning is generated when the ?-Qunused-arguments? is removed.

clang: warning: -Wl,--as-needed: 'linker' input unused

The cmake logic in CMakeLists.txt is basically:

   SET(CMAKE_REQUIRED_FLAGS "${_FLAG}")
   CHECK_C_SOURCE_RUNS(?int main() { return 0;}" ${_RESULT})

where _FLAG is set to ?-DWS_LD_FLAG_VALID0 -Wl,?-as-needed?


So, how/where is the clang compile/link command generated and why isn?t it being setup for clang to link?



> On Jan 21, 2016, at 1:51 AM, Eric Wing <ewmailing at gmail.com> wrote:
> 
> On 1/20/16, David Morsberger <dave at morsberger.com> wrote:
>> 
>>> On Jan 19, 2016, at 10:11 PM, Eric Wing <ewmailing at gmail.com> wrote:
>>> 
>>> On 1/19/16, David Morsberger <dave at morsberger.com> wrote:
>>>> Any help would be appreciated.
>>>> 
>>>> In particular I?d like to know how the default compiler arguments are
>>>> set
>>>> when ?cmake -G Xcode? is executed. The attached file contains the cmake
>>>> test
>>>> compile extracted and reformatted from CMakeOutput.log that should have
>>>> failed. Again, what is setting all the clang compiler options when this
>>>> is
>>>> executed?
>>>> 
>>>> 
>>>> 
>>>> All help is appreciated
>>>> 
>>>>> On Jan 18, 2016, at 2:58 PM, David Morsberger <dave at morsberger.com>
>>>>> wrote:
>>>>> 
>>>>> I?m having an issue generating and using a XCode project using cmake
>>>>> -G.
>>>>> 
>>>>> cmake ?version
>>>>>   cmake version 3.4.1
>>>>> 
>>>>> Xcode Version 7.2 (7C68)
>>>>> 
>>>>> Mac OS 10.11.
>>>>> 
>>>>> 
>>>>> My CMakeLists.txt has a clang option that fails during the -G Xcode
>>>>> pass
>>>>> but fails when linking within XCode.
>>>>> 
>>>>> The compiler / linker option is ?-Wl,?as-needed?
>>>>> 
>>>>> The test compile/link step in ?cmake -G Xcode' creates a long clang
>>>>> command with arguments ?-Wl,?as-needed? plus ??serialize-diagnostics
>>>>> <path
>>>>> to .dia file>?
>>>>> 
>>>>> The link step within Xcode after the project created has the
>>>>> ?-Wl,?as-needed? argument and does not have the ??serialize-diagnostics
>>>>> <path to .dia file>? argument. The link fails because ?-Wl,?as-needed?
>>>>> isn?t supported.
>>>>> 
>>>>> If copy and execute the long clang command from the ?cmake -G Xcode?
>>>>> command and remove the ??serialize-diagnostics <path to .dia file>?
>>>>> then
>>>>> it successfully fails with ?-Wl, ?as-needed? isn?t supported.
>>>>> 
>>>>> Finally, when I use cmake to generate unix makefiles it works meaning
>>>>> cmake determines ?-Wl?as-needed? isn?t supported and doesn?t add it to
>>>>> the
>>>>> argument list.
>>>>> 
>>>>> Questions:
>>>>> - Where is the ??serialized-diagnostics? argument coming from when
>>>>> executing ?cmake -G Xcode??
>>>>> 
>>>>> - What is a .dia file and how do I read it?
>>>>> 
>>>>> - What?s the preferred / recommended way of detecting the non-supported
>>>>> ?-Wl,?as-needed? argument during the ?cmake -G Xcode? phase? One option
>>>>> might to be to remove the ??serialize-diagnostics? argument during the
>>>>> generation phase.
>>>>> 
>>>>> I can provide more details on request.
>>>>> 
>>>>> David
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> I just spot checked one of my Xcode compile logs. I see the
>>> ?serialize-diagnostics flag, but I don't have ?as-needed anywhere.
>>> Maybe one of your CMake scripts is adding that in, or you have set
>>> some kind of environment variable that clang or Xcode is picking up?
>>> (This recently happened to me on Linux.)
>> 
>> Ed,
>> 
>> In this case cmake is attempting to determine if ??as-needed' is a supported
>> option and the build should fail.
>> 
>> I have searched (grep?d) everything I can think of for the string
>> ?serialize-diagnostics? with zero hits.
>> 
>> I can easily add an ?if( Xcode )? around the setting in CMakeLists.txt
>> however I?m trying to figure out what is exactly going on. The best
>> solutions are chosen when you know what is going on under the hood.
>> 
>> 
>> 
> 
> I believe the serialize-diagnostics flag is added by Xcode itself. I
> see it (along with many other flags) in a native (non-CMake generated)
> Xcode project.
> 
> -Eric

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

From vania.joloboff at inria.fr  Thu Jan 21 09:14:54 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 21 Jan 2016 15:14:54 +0100
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <56A0DF6F.4020402@kitware.com>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com>
Message-ID: <56A0E7DE.7000604@inria.fr>

Hi

I want to add two definitions to compile one specific files
in addition to the global definitions.
I have the following problem. If I use

set_source_files_properties(source.cpp
PROPERTIES
COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )

then I get error message incorrect number of arguments for 
set_source_files_properties

If I put
set_source_files_properties(source.cpp
PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )

then it generates strangely enough the compile command

/usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp

with the double quotes as above, which gives a weird value to VAR1 and 
no value to VAR2

If I use twice set_source_files_properties
the first one is overwritten by the second
and I only get the definition of VAR2

What am I supposed to do ?

Thankx

PS I am using cmake 3.2.2 on Linux Mint.


From petr.kmoch at gmail.com  Thu Jan 21 09:21:32 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 21 Jan 2016 15:21:32 +0100
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <56A0E7DE.7000604@inria.fr>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com> <56A0E7DE.7000604@inria.fr>
Message-ID: <CAKohaZc=-xtA9+MPjYYa5+vw+-Z0CCfpEinEQU8fr8VAnf6OQg@mail.gmail.com>

Hi Vania.

For your case, it's best to forget about the
not-as-convenient-as-they-could-be convenience functions set_*_properties,
and just invoke set_property:

set_property(
  SOURCE source.cpp
  PROPERTY COMPILE_DEFINITIONS
    VAR1=${MY_VAR1} VAR2=${MY_VAR2}
)

Petr

On Thu, Jan 21, 2016 at 3:14 PM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> Hi
>
> I want to add two definitions to compile one specific files
> in addition to the global definitions.
> I have the following problem. If I use
>
> set_source_files_properties(source.cpp
> PROPERTIES
> COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>
> then I get error message incorrect number of arguments for
> set_source_files_properties
>
> If I put
> set_source_files_properties(source.cpp
> PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )
>
> then it generates strangely enough the compile command
>
> /usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp
>
> with the double quotes as above, which gives a weird value to VAR1 and no
> value to VAR2
>
> If I use twice set_source_files_properties
> the first one is overwritten by the second
> and I only get the definition of VAR2
>
> What am I supposed to do ?
>
> Thankx
>
> PS I am using cmake 3.2.2 on Linux Mint.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160121/839234d7/attachment.html>

From gjasny at googlemail.com  Thu Jan 21 09:24:00 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Thu, 21 Jan 2016 15:24:00 +0100
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <56A0E7DE.7000604@inria.fr>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com> <56A0E7DE.7000604@inria.fr>
Message-ID: <56A0EA00.2050600@googlemail.com>

Hi,

On 21/01/16 15:14, Vania Joloboff wrote:
> Hi
>
> I want to add two definitions to compile one specific files
> in addition to the global definitions.
> I have the following problem. If I use
>
> set_source_files_properties(source.cpp
> PROPERTIES
> COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>
> then I get error message incorrect number of arguments for
> set_source_files_properties
>
> If I put
> set_source_files_properties(source.cpp
> PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )

Try to delimit the two definitions by a ; to create a list.

Alternatively set property should do the trick:
https://cmake.org/cmake/help/v3.2/command/set_property.html

set_property(SOURCE source.cpp PROPERTY COMPILE_DEFINITIONS 
VAR1=${MY_VAR1} VAR2=${MY_VAR2})

With set_property you also have the option to specify APPEND or 
APPEND_STRING.

Thanks,
Gregor

From vania.joloboff at inria.fr  Thu Jan 21 09:26:58 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Thu, 21 Jan 2016 15:26:58 +0100
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <CAKohaZc=-xtA9+MPjYYa5+vw+-Z0CCfpEinEQU8fr8VAnf6OQg@mail.gmail.com>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com> <56A0E7DE.7000604@inria.fr>
 <CAKohaZc=-xtA9+MPjYYa5+vw+-Z0CCfpEinEQU8fr8VAnf6OQg@mail.gmail.com>
Message-ID: <56A0EAB2.2030608@inria.fr>

HI Petr

Thanks for the suggestion.
But this will erase the existing compile definitions, won't it ?
So may be I should do a get_property first,
append my new definitions and reset the property ?
I'll try anyway...

Vania

On 01/21/2016 03:21 PM, Petr Kmoch wrote:
> Hi Vania.
>
> For your case, it's best to forget about the 
> not-as-convenient-as-they-could-be convenience functions 
> set_*_properties, and just invoke set_property:
>
> set_property(
>   SOURCE source.cpp
>   PROPERTY COMPILE_DEFINITIONS
>     VAR1=${MY_VAR1} VAR2=${MY_VAR2}
> )
>
> Petr
>
> On Thu, Jan 21, 2016 at 3:14 PM, Vania Joloboff 
> <vania.joloboff at inria.fr <mailto:vania.joloboff at inria.fr>> wrote:
>
>     Hi
>
>     I want to add two definitions to compile one specific files
>     in addition to the global definitions.
>     I have the following problem. If I use
>
>     set_source_files_properties(source.cpp
>     PROPERTIES
>     COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>
>     then I get error message incorrect number of arguments for
>     set_source_files_properties
>
>     If I put
>     set_source_files_properties(source.cpp
>     PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )
>
>     then it generates strangely enough the compile command
>
>     /usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp
>
>     with the double quotes as above, which gives a weird value to VAR1
>     and no value to VAR2
>
>     If I use twice set_source_files_properties
>     the first one is overwritten by the second
>     and I only get the definition of VAR2
>
>     What am I supposed to do ?
>
>     Thankx
>
>     PS I am using cmake 3.2.2 on Linux Mint.
>
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     http://public.kitware.com/mailman/listinfo/cmake
>
>


From fkillus at googlemail.com  Thu Jan 21 09:27:10 2016
From: fkillus at googlemail.com (fkillus)
Date: Thu, 21 Jan 2016 15:27:10 +0100
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
In-Reply-To: <CAHk1PgESiSGw-23ViQ77M7B-0eLCLc+1=k7uhaayWtF_weneBw@mail.gmail.com>
References: <CACaBFwyxEQhhT_JOtf0pgQ31VooO6MU3p=xKh_m+eJERi8mOqw@mail.gmail.com>
 <CAHk1PgESiSGw-23ViQ77M7B-0eLCLc+1=k7uhaayWtF_weneBw@mail.gmail.com>
Message-ID: <CACaBFwzTZEvkrnegrK9882H8-gn0h5v9=9t3+7Se-sRghEbfZQ@mail.gmail.com>

Thanks for clarifying that external projects are not aware of the project
they are embedded in.
The CMAKE_COMPILER_IS_GNUCXX variable should be set automatically by CMake
as far
as I understand it (see https://cmake.org/Wiki/CMake_Useful_Variables).

I narrowed down the problem by creating a minimal setup which still
reproduces the issue.
In this case the super project is simply a wrapper around an external dummy
project.

external/CMakeLists.txt:

  cmake_minimum_required( VERSION 3.4 )
  project( external )
  message( "External - CMAKE_COMPILER_IS_GNUCXX: "
${CMAKE_COMPILER_IS_GNUCXX} )
  message( "External - CMAKE_CXX_COMPILER_ID: " ${CMAKE_CXX_COMPILER_ID} )
  message( "External - CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )

super/CMakeLists.txt:

  cmake_minimum_required( VERSION 3.4 )
  project( super )
  message( "Super - CMAKE_COMPILER_IS_GNUCXX: " ${CMAKE_COMPILER_IS_GNUCXX}
)
  message( "Super - CMAKE_CXX_COMPILER_ID: " ${CMAKE_CXX_COMPILER_ID} )
  message( "Super - CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )
  include( ExternalProject )
  ExternalProject_Add(
    external
    DOWNLOAD_COMMAND ""
    SOURCE_DIR ${CMAKE_SOURCE_DIR}/../external
    CMAKE_ARGS
      -DCMAKE_CXX_FLAGS="-march=native"
    INSTALL_COMMAND  ""
  )

The problem occurs when the CMAKE_CXX_FLAGS variable is set inside the
ExternalProject_Add
command using quotes (i.e. "-march=native" in this example). The output
obtained when configuring
the super project with 'cmake ../super' is:

-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is GNU 5.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Super - CMAKE_COMPILER_IS_GNUCXX: 1
Super - CMAKE_CXX_COMPILER_ID: GNU
Super - CMAKE_CXX_FLAGS:
-- Configuring done
-- Generating done

Afterwards building with 'make' results in:

[ 12%] Creating directories for 'external'
[ 25%] No download step for 'external'
[ 37%] No patch step for 'external'
[ 50%] No update step for 'external'
[ 62%] Performing configure step for 'external'
-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is unknown
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
External - CMAKE_COMPILER_IS_GNUCXX:
External - CMAKE_CXX_COMPILER_ID:
External - CMAKE_CXX_FLAGS: "-march=native"
-- Configuring done
-- Generating done

This shows the compiler is not correctly identified for the external
project. Directly configuring
the external project with 'cmake -DCMAKE_CXX_FLAGS="-march=native"
../external' works though:

-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is GNU 5.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
External - CMAKE_COMPILER_IS_GNUCXX: 1
External - CMAKE_CXX_COMPILER_ID: GNU
External - CMAKE_CXX_FLAGS: -march=native
-- Configuring done
-- Generating done


It also works if the quotations marks in the super project listfile are
removed. I.e. changing
  CMAKE_ARGS
   -DCMAKE_CXX_FLAGS="-march=native"
to
  CMAKE_ARGS
   -DCMAKE_CXX_FLAGS=-march=native

The question is now, is it still possible to add mutiple compile flags if
one cannot use quotation marks?


On Wed, Jan 20, 2016 at 6:58 PM, Nicholas Braden <nicholas11braden at gmail.com
> wrote:

> Where/how is that variable normally set? External projects have no
> awareness of the project they are in, they just run CMake as usual the
> same way you would. If the variable is normally set by CMake itself,
> make sure that your containing project and the external project both
> find the same compiler. (They each do their own automatic search for
> compilers)
>
> On Wed, Jan 20, 2016 at 11:41 AM, fkillus via CMake <cmake at cmake.org>
> wrote:
> > I have been trying to compile Ogre [1] as external dependency with
> > ExternalProject_Add(). In theory this should be straightforward since
> Ogre
> > itself also uses CMake as buildsystem. However, in the process I
> encountered
> > the following problem:
> >
> > Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
> > places (e.g. [2]). I am running Linux and compiling with g++ and
> everything
> > works fine if I manually configure Ogre with cmake or cmake-gui.
> > Unfortunately, after wrapping everything inside ExternalProject_Add(),
> the
> > CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
> >
> > A simple workaround is to manually set this variable, i.e.:
> >
> >  ExternalProject_Add(
> >     ogre
> >     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
> >     CMAKE_ARGS
> >       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
> >       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   #
> workaround
> >   )
> >
> > This works, but I'm uncertain if this should be necessary. Is this a bug
> or
> > a feature?
> >
> >
> > [1] https://bitbucket.org/sinbad/ogre
> > [2]
> >
> https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/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/20160121/afa7d886/attachment-0001.html>

From fkillus at googlemail.com  Thu Jan 21 09:31:58 2016
From: fkillus at googlemail.com (fkillus)
Date: Thu, 21 Jan 2016 15:31:58 +0100
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
In-Reply-To: <CACQP5UfxPQ54ojx-Fx19=CTp16QEKLe0mhTTTobbmghbJbpT3A@mail.gmail.com>
References: <CACQP5UfxPQ54ojx-Fx19=CTp16QEKLe0mhTTTobbmghbJbpT3A@mail.gmail.com>
Message-ID: <CACaBFww7B5OvE+cwsQ_Ri9NEpvfvH+U8GL+7HGSnjq5LLwA9Fw@mail.gmail.com>

Thanks for your suggestion! I consider trying it soon.

On Wed, Jan 20, 2016 at 11:44 PM, Craig Scott <audiofanatic at gmail.com>
wrote:

>
> From: fkillus <fkillus at googlemail.com>
>> To: cmake at cmake.org
>> Cc:
>> Date: Wed, 20 Jan 2016 18:41:26 +0100
>> Subject: [CMake] ExternalProject_Add() macro does not set
>> CMAKE_COMPILER_IS_GNUCXX
>> I have been trying to compile Ogre [1] as external dependency with
>> ExternalProject_Add(). In theory this should be straightforward since Ogre
>> itself also uses CMake as buildsystem. However, in the process I
>> encountered the following problem:
>>
>
>> Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
>> places (e.g. [2]). I am running Linux and compiling with g++ and everything
>> works fine if I manually configure Ogre with cmake or cmake-gui.
>> Unfortunately, after wrapping everything inside ExternalProject_Add(), the
>> CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
>>
>> A simple workaround is to manually set this variable, i.e.:
>>
>>  ExternalProject_Add(
>>     ogre
>>     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
>>     CMAKE_ARGS
>>       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
>>       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   # workaround
>>   )
>>
>> This works, but I'm uncertain if this should be necessary. Is this a bug
>> or a feature?
>>
>>
>> [1] https://bitbucket.org/sinbad/ogre
>> [2]
>> https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
>>
>>
>
> Since Ogre is a CMake project, you may find the technique described at the
> following link useful. It uses GoogleTest as its example, but it should
> also apply to your situation. The approach uses ExternalProject only to
> download the source at CMake time. It then pulls it into your normal build
> via add_subdirectory(), so it gets all the same compiler details, etc. as
> your main build because it IS part of your main build.
>
> http://crascit.com/2015/07/25/cmake-gtest/
>
> I am not familiar with Ogre's build, so I can't comment on whether it will
> play nice if pulled into a parent build like this, but it's worth a try.
> The article links to a github repo which provides a fully generalised
> implementation you should be able to use out of the box.
>
>
> --
> Craig Scott
> Melbourne, Australia
> http://crascit.com
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160121/58fff688/attachment.html>

From marc.chevrier at sap.com  Thu Jan 21 09:30:50 2016
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Thu, 21 Jan 2016 14:30:50 +0000
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <56A0EAB2.2030608@inria.fr>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com> <56A0E7DE.7000604@inria.fr>
 <CAKohaZc=-xtA9+MPjYYa5+vw+-Z0CCfpEinEQU8fr8VAnf6OQg@mail.gmail.com>
 <56A0EAB2.2030608@inria.fr>
Message-ID: <3520A9A1-57EA-47C1-86F7-9BEA8C9B50D4@sap.com>

Use APPEND keyword:
set_property(
   SOURCE source.cpp
APPEND PROPERTY COMPILE_DEFINITIONS
     VAR1=${MY_VAR1} VAR2=${MY_VAR2}
)






On 21/01/16 15:26, "CMake on behalf of Vania Joloboff" <cmake-bounces at cmake.org on behalf of vania.joloboff at inria.fr> wrote:

>HI Petr
>
>Thanks for the suggestion.
>But this will erase the existing compile definitions, won't it ?
>So may be I should do a get_property first,
>append my new definitions and reset the property ?
>I'll try anyway...
>
>Vania
>
>On 01/21/2016 03:21 PM, Petr Kmoch wrote:
>> Hi Vania.
>>
>> For your case, it's best to forget about the 
>> not-as-convenient-as-they-could-be convenience functions 
>> set_*_properties, and just invoke set_property:
>>
>> set_property(
>>   SOURCE source.cpp
>>   PROPERTY COMPILE_DEFINITIONS
>>     VAR1=${MY_VAR1} VAR2=${MY_VAR2}
>> )
>>
>> Petr
>>
>> On Thu, Jan 21, 2016 at 3:14 PM, Vania Joloboff 
>> <vania.joloboff at inria.fr <mailto:vania.joloboff at inria.fr>> wrote:
>>
>>     Hi
>>
>>     I want to add two definitions to compile one specific files
>>     in addition to the global definitions.
>>     I have the following problem. If I use
>>
>>     set_source_files_properties(source.cpp
>>     PROPERTIES
>>     COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>>
>>     then I get error message incorrect number of arguments for
>>     set_source_files_properties
>>
>>     If I put
>>     set_source_files_properties(source.cpp
>>     PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )
>>
>>     then it generates strangely enough the compile command
>>
>>     /usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp
>>
>>     with the double quotes as above, which gives a weird value to VAR1
>>     and no value to VAR2
>>
>>     If I use twice set_source_files_properties
>>     the first one is overwritten by the second
>>     and I only get the definition of VAR2
>>
>>     What am I supposed to do ?
>>
>>     Thankx
>>
>>     PS I am using cmake 3.2.2 on Linux Mint.
>>
>>     -- 
>>
>>     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
>>
>>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/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  Thu Jan 21 09:43:34 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Thu, 21 Jan 2016 15:43:34 +0100 (CET)
Subject: [CMake] =?iso-8859-1?q?Re=A0=3A_Re=3A__How_to_pass_a_configuratio?=
 =?iso-8859-1?q?n_file_to_CMake=3F?=
In-Reply-To: <726390889.4117381.1450700945898.JavaMail.zimbra@inria.fr>
References: <1703394343.4113760.1450699712465.JavaMail.zimbra@inria.fr>
 <653657175.4114402.1450699928888.JavaMail.zimbra@inria.fr>
 <CAKohaZeLHaFgYcajM_i_f=v8vriS7HVevZQJRz13sEu6_QW13g@mail.gmail.com>
 <726390889.4117381.1450700945898.JavaMail.zimbra@inria.fr>
Message-ID: <1778809942.11508682.1453387414774.JavaMail.zimbra@inria.fr>



Hello,
I do not manage to pass a configuration file to cmake.

I type 'cmake -C ../config.cmake'

where config.cmake belongs to the parent directory and contains these lines:

set(ENABLE_DOWNLOAD True CACHE BOOL)
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)

I get the following error message but I don't understand why:

loading initial cache file ../config.cmake
CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
  set given invalid arguments for CACHE mode.


CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
  set given invalid arguments for CACHE mode.


CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a file, not a directory.


Do you know how to solve this problem?
----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
>
Hi Peter!
Thank you very much!It seems to be exactly what I want. :)I will try to use it.
C?dric
De: "Petr Kmoch" <petr.kmoch at gmail.com>
?: "Cedric Doucet" <cedric.doucet at inria.fr>
Cc: cmake at cmake.org
Envoy?: Lundi 21 D?cembre 2015 13:25:53
Objet: Re: [CMake] How to pass a configuration file to CMake?

Hi Cedric.

I have never used it myself, but I believe you're looking for CMake's command-line option '-C <initial-cache>': https://cmake.org/cmake/help/latest/manual/cmake.1.html

Petr

On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr> wrote:

Hello,
I would like to know if it's possible to pass a configuration file to CMake.I have to pass a lot of information to CMake and the resulting command line is very long to type.Would it be possible to create a file containing all needed definitions and pass it to CMake?
For exemple, instead of typing
cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
would it be possible to create a file containing
CMAKE_BUILD_TYPE=DebugCMAKE_INSTALL_PREFIX=/home/me/thereCMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
and pass it to CMake?
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


>

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

From eric.noulard at gmail.com  Thu Jan 21 09:50:34 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 21 Jan 2016 15:50:34 +0100
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <56A0E7DE.7000604@inria.fr>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com> <56A0E7DE.7000604@inria.fr>
Message-ID: <CAPASGLpYCAUtZ3VTRXcfk-cSSAU8=fbUww+TYBQuw4zaqZZfvg@mail.gmail.com>

2016-01-21 15:14 GMT+01:00 Vania Joloboff <vania.joloboff at inria.fr>:

> Hi
>
> I want to add two definitions to compile one specific files
> in addition to the global definitions.
> I have the following problem. If I use
>
> set_source_files_properties(source.cpp
> PROPERTIES
> COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>
> then I get error message incorrect number of arguments for
> set_source_files_properties
>
> If I put
> set_source_files_properties(source.cpp
> PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )
>
> then it generates strangely enough the compile command
>
> /usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp
>
> with the double quotes as above, which gives a weird value to VAR1 and no
> value to VAR2
>
> If I use twice set_source_files_properties
> the first one is overwritten by the second
> and I only get the definition of VAR2
>
> What am I supposed to do ?
>

Did you try to separate you VAR1 and VAR2 def suing semicolon as indicated
in the doc:
"The COMPILE_DEFINITIONS property may be set to a semicolon-separated
list of preprocessor definitions using the syntax VAR or VAR=value."

see
cmake --help-property COMPILE_DEFINITIONS

so try:
set_source_files_properties(source.cpp
PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1};VAR2=${MY_VAR2}" )


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

From petr.kmoch at gmail.com  Thu Jan 21 09:51:33 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 21 Jan 2016 15:51:33 +0100
Subject: [CMake] Adding definitions to compile one file ?
In-Reply-To: <56A0EAB2.2030608@inria.fr>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com> <56A0E7DE.7000604@inria.fr>
 <CAKohaZc=-xtA9+MPjYYa5+vw+-Z0CCfpEinEQU8fr8VAnf6OQg@mail.gmail.com>
 <56A0EAB2.2030608@inria.fr>
Message-ID: <CAKohaZeG-K=4m9q7D=RmMWwczao8XWPmPHVQSpqtyPjJxaMHgw@mail.gmail.com>

On Thu, Jan 21, 2016 at 3:26 PM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> HI Petr
>
> Thanks for the suggestion.
> But this will erase the existing compile definitions, won't it ?
> So may be I should do a get_property first,
> append my new definitions and reset the property ?
> I'll try anyway...
>

This would erase the previous value of the property COMPILE_DEFINITIONS
specified on the source file(s), if you've already provided one for it. But
the globally specified compilation definitions, flags etc. do not get
copied into these per-source properties. Instead, the final command line
used for compiling a source is combined from the global, target, and source
file properties (and relevant variables and other things).

If you really need to append to the property, though, you can use APPEND or
APPEND_STRING arguments before the PROPERTY keyword; refer to CMake docs
for more details.

Petr


>
> Vania
>
> On 01/21/2016 03:21 PM, Petr Kmoch wrote:
>
>> Hi Vania.
>>
>> For your case, it's best to forget about the
>> not-as-convenient-as-they-could-be convenience functions set_*_properties,
>> and just invoke set_property:
>>
>> set_property(
>>   SOURCE source.cpp
>>   PROPERTY COMPILE_DEFINITIONS
>>     VAR1=${MY_VAR1} VAR2=${MY_VAR2}
>> )
>>
>> Petr
>>
>> On Thu, Jan 21, 2016 at 3:14 PM, Vania Joloboff <vania.joloboff at inria.fr
>> <mailto:vania.joloboff at inria.fr>> wrote:
>>
>>     Hi
>>
>>     I want to add two definitions to compile one specific files
>>     in addition to the global definitions.
>>     I have the following problem. If I use
>>
>>     set_source_files_properties(source.cpp
>>     PROPERTIES
>>     COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>>
>>     then I get error message incorrect number of arguments for
>>     set_source_files_properties
>>
>>     If I put
>>     set_source_files_properties(source.cpp
>>     PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )
>>
>>     then it generates strangely enough the compile command
>>
>>     /usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp
>>
>>     with the double quotes as above, which gives a weird value to VAR1
>>     and no value to VAR2
>>
>>     If I use twice set_source_files_properties
>>     the first one is overwritten by the second
>>     and I only get the definition of VAR2
>>
>>     What am I supposed to do ?
>>
>>     Thankx
>>
>>     PS I am using cmake 3.2.2 on Linux Mint.
>>
>>     --
>>     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/20160121/49166703/attachment.html>

From chuck.atkins at kitware.com  Thu Jan 21 09:53:08 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 21 Jan 2016 09:53:08 -0500
Subject: [CMake] How to pass a configuration file to CMake?
Message-ID: <CAOXZzG7VE4xesLoD51jdakDjQG20_yJ+jMGa-xztv8gALhG-kA@mail.gmail.com>

Hi Cedric,

The option can be a bit confusing.  The cache file you pass is actually a
CMake script that sets cache variables, rather than the cache variables as
seen in CMakeCache.txt.  So you would actually want your cache file to
contain:

set(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build")
set(CMAKE_INSTALL_PREFIX /home/me/there CACHE PATH "Install path prefix,
prepended onto install directories.")
set(CMAKE_CXX_COMPILER /usr/local/gcc/4.9.3/g++ CACHE FILEPATH "CXX
Compiler")


- Chuck

On Thu, Jan 21, 2016 at 9:43 AM, Cedric Doucet <cedric.doucet at inria.fr>
wrote:

>
>
> Hello,
>
> I do not manage to pass a configuration file to cmake.
>
> I type 'cmake -C ../config.cmake'
>
> where config.cmake belongs to the parent directory and contains these
> lines:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL)
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>
> I get the following error message but I don't understand why:
>
> loading initial cache file ../config.cmake
> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
>
> Do you know how to solve this problem?
>
> ----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
> >
>
> Hi Peter!
>
> Thank you very much!
> It seems to be exactly what I want. :)
> I will try to use it.
>
> C?dric
>
> ------------------------------
>
> *De: *"Petr Kmoch" <petr.kmoch at gmail.com>
> *?: *"Cedric Doucet" <cedric.doucet at inria.fr>
> *Cc: *cmake at cmake.org
> *Envoy?: *Lundi 21 D?cembre 2015 13:25:53
> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>
> Hi Cedric.
>
> I have never used it myself, but I believe you're looking for CMake's
> command-line option '-C <initial-cache>':
> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>
> Petr
>
> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
>
>>
>> Hello,
>>
>> I would like to know if it's possible to pass a configuration file to
>> CMake.
>> I have to pass a lot of information to CMake and the resulting command
>> line is very long to type.
>> Would it be possible to create a file containing all needed definitions
>> and pass it to CMake?
>>
>> For exemple, instead of typing
>>
>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> would it be possible to create a file containing
>>
>> CMAKE_BUILD_TYPE=Debug
>> CMAKE_INSTALL_PREFIX=/home/me/there
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> and pass it to CMake?
>>
>> 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
>>
>
>
> >
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160121/a5efa8b2/attachment-0001.html>

From petr.kmoch at gmail.com  Thu Jan 21 09:54:13 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 21 Jan 2016 15:54:13 +0100
Subject: [CMake] How to pass a configuration file to CMake?
Message-ID: <CAKohaZcj1N4rfiAO-J=_N5_z+wAgyZn_DPRKiWhbOu8+JutzZw@mail.gmail.com>

Hi Cedric.

I believe the comment string argument is mandatory in a set(... CACHE), so
it should be something like this:

set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root directory
of GCC installation")

Petr


On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet <cedric.doucet at inria.fr>
wrote:

>
>
> Hello,
>
> I do not manage to pass a configuration file to cmake.
>
> I type 'cmake -C ../config.cmake'
>
> where config.cmake belongs to the parent directory and contains these
> lines:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL)
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>
> I get the following error message but I don't understand why:
>
> loading initial cache file ../config.cmake
> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
>
> Do you know how to solve this problem?
>
> ----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
> >
>
> Hi Peter!
>
> Thank you very much!
> It seems to be exactly what I want. :)
> I will try to use it.
>
> C?dric
>
> ------------------------------
>
> *De: *"Petr Kmoch" <petr.kmoch at gmail.com>
> *?: *"Cedric Doucet" <cedric.doucet at inria.fr>
> *Cc: *cmake at cmake.org
> *Envoy?: *Lundi 21 D?cembre 2015 13:25:53
> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>
> Hi Cedric.
>
> I have never used it myself, but I believe you're looking for CMake's
> command-line option '-C <initial-cache>':
> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>
> Petr
>
> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
>
>>
>> Hello,
>>
>> I would like to know if it's possible to pass a configuration file to
>> CMake.
>> I have to pass a lot of information to CMake and the resulting command
>> line is very long to type.
>> Would it be possible to create a file containing all needed definitions
>> and pass it to CMake?
>>
>> For exemple, instead of typing
>>
>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> would it be possible to create a file containing
>>
>> CMAKE_BUILD_TYPE=Debug
>> CMAKE_INSTALL_PREFIX=/home/me/there
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> and pass it to CMake?
>>
>> 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
>>
>
>
> >
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160121/eb8a45cd/attachment.html>

From nicholas11braden at gmail.com  Thu Jan 21 09:56:55 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Thu, 21 Jan 2016 08:56:55 -0600
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
In-Reply-To: <CACaBFwzTZEvkrnegrK9882H8-gn0h5v9=9t3+7Se-sRghEbfZQ@mail.gmail.com>
References: <CACaBFwyxEQhhT_JOtf0pgQ31VooO6MU3p=xKh_m+eJERi8mOqw@mail.gmail.com>
 <CAHk1PgESiSGw-23ViQ77M7B-0eLCLc+1=k7uhaayWtF_weneBw@mail.gmail.com>
 <CACaBFwzTZEvkrnegrK9882H8-gn0h5v9=9t3+7Se-sRghEbfZQ@mail.gmail.com>
Message-ID: <CAHk1PgH4PCZj4Mz8x9SejmNdgtLcpsN29vzOfDqayd9S-ZV_bA@mail.gmail.com>

Ah, I ran into this quirk too - the issue is that you have the quotes incorrect:

-DCMAKE_CXX_FLAGS="-march=native"

Should be like this instead:

"-DCMAKE_CXX_FLAGS=-march=native"

Try that and see if it helps, I am pretty sure I ran into the exact
same problem.

On Thu, Jan 21, 2016 at 8:27 AM, fkillus <fkillus at googlemail.com> wrote:
> Thanks for clarifying that external projects are not aware of the project
> they are embedded in.
> The CMAKE_COMPILER_IS_GNUCXX variable should be set automatically by CMake
> as far
> as I understand it (see https://cmake.org/Wiki/CMake_Useful_Variables).
>
> I narrowed down the problem by creating a minimal setup which still
> reproduces the issue.
> In this case the super project is simply a wrapper around an external dummy
> project.
>
> external/CMakeLists.txt:
>
>   cmake_minimum_required( VERSION 3.4 )
>   project( external )
>   message( "External - CMAKE_COMPILER_IS_GNUCXX: "
> ${CMAKE_COMPILER_IS_GNUCXX} )
>   message( "External - CMAKE_CXX_COMPILER_ID: " ${CMAKE_CXX_COMPILER_ID} )
>   message( "External - CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )
>
> super/CMakeLists.txt:
>
>   cmake_minimum_required( VERSION 3.4 )
>   project( super )
>   message( "Super - CMAKE_COMPILER_IS_GNUCXX: " ${CMAKE_COMPILER_IS_GNUCXX}
> )
>   message( "Super - CMAKE_CXX_COMPILER_ID: " ${CMAKE_CXX_COMPILER_ID} )
>   message( "Super - CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )
>   include( ExternalProject )
>   ExternalProject_Add(
>     external
>     DOWNLOAD_COMMAND ""
>     SOURCE_DIR ${CMAKE_SOURCE_DIR}/../external
>     CMAKE_ARGS
>       -DCMAKE_CXX_FLAGS="-march=native"
>     INSTALL_COMMAND  ""
>   )
>
> The problem occurs when the CMAKE_CXX_FLAGS variable is set inside the
> ExternalProject_Add
> command using quotes (i.e. "-march=native" in this example). The output
> obtained when configuring
> the super project with 'cmake ../super' is:
>
> -- The C compiler identification is GNU 5.2.0
> -- The CXX compiler identification is GNU 5.2.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> Super - CMAKE_COMPILER_IS_GNUCXX: 1
> Super - CMAKE_CXX_COMPILER_ID: GNU
> Super - CMAKE_CXX_FLAGS:
> -- Configuring done
> -- Generating done
>
> Afterwards building with 'make' results in:
>
> [ 12%] Creating directories for 'external'
> [ 25%] No download step for 'external'
> [ 37%] No patch step for 'external'
> [ 50%] No update step for 'external'
> [ 62%] Performing configure step for 'external'
> -- The C compiler identification is GNU 5.2.0
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> External - CMAKE_COMPILER_IS_GNUCXX:
> External - CMAKE_CXX_COMPILER_ID:
> External - CMAKE_CXX_FLAGS: "-march=native"
> -- Configuring done
> -- Generating done
>
> This shows the compiler is not correctly identified for the external
> project. Directly configuring
> the external project with 'cmake -DCMAKE_CXX_FLAGS="-march=native"
> ../external' works though:
>
> -- The C compiler identification is GNU 5.2.0
> -- The CXX compiler identification is GNU 5.2.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> External - CMAKE_COMPILER_IS_GNUCXX: 1
> External - CMAKE_CXX_COMPILER_ID: GNU
> External - CMAKE_CXX_FLAGS: -march=native
> -- Configuring done
> -- Generating done
>
>
> It also works if the quotations marks in the super project listfile are
> removed. I.e. changing
>   CMAKE_ARGS
>    -DCMAKE_CXX_FLAGS="-march=native"
> to
>   CMAKE_ARGS
>    -DCMAKE_CXX_FLAGS=-march=native
>
> The question is now, is it still possible to add mutiple compile flags if
> one cannot use quotation marks?
>
>
> On Wed, Jan 20, 2016 at 6:58 PM, Nicholas Braden
> <nicholas11braden at gmail.com> wrote:
>>
>> Where/how is that variable normally set? External projects have no
>> awareness of the project they are in, they just run CMake as usual the
>> same way you would. If the variable is normally set by CMake itself,
>> make sure that your containing project and the external project both
>> find the same compiler. (They each do their own automatic search for
>> compilers)
>>
>> On Wed, Jan 20, 2016 at 11:41 AM, fkillus via CMake <cmake at cmake.org>
>> wrote:
>> > I have been trying to compile Ogre [1] as external dependency with
>> > ExternalProject_Add(). In theory this should be straightforward since
>> > Ogre
>> > itself also uses CMake as buildsystem. However, in the process I
>> > encountered
>> > the following problem:
>> >
>> > Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
>> > places (e.g. [2]). I am running Linux and compiling with g++ and
>> > everything
>> > works fine if I manually configure Ogre with cmake or cmake-gui.
>> > Unfortunately, after wrapping everything inside ExternalProject_Add(),
>> > the
>> > CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
>> >
>> > A simple workaround is to manually set this variable, i.e.:
>> >
>> >  ExternalProject_Add(
>> >     ogre
>> >     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
>> >     CMAKE_ARGS
>> >       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
>> >       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   #
>> > workaround
>> >   )
>> >
>> > This works, but I'm uncertain if this should be necessary. Is this a bug
>> > or
>> > a feature?
>> >
>> >
>> > [1] https://bitbucket.org/sinbad/ogre
>> > [2]
>> >
>> > https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake community. For more
>> > information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/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 fkillus at googlemail.com  Thu Jan 21 10:07:07 2016
From: fkillus at googlemail.com (fkillus)
Date: Thu, 21 Jan 2016 16:07:07 +0100
Subject: [CMake] ExternalProject_Add() macro does not set
	CMAKE_COMPILER_IS_GNUCXX
In-Reply-To: <CAHk1PgH4PCZj4Mz8x9SejmNdgtLcpsN29vzOfDqayd9S-ZV_bA@mail.gmail.com>
References: <CACaBFwyxEQhhT_JOtf0pgQ31VooO6MU3p=xKh_m+eJERi8mOqw@mail.gmail.com>
 <CAHk1PgESiSGw-23ViQ77M7B-0eLCLc+1=k7uhaayWtF_weneBw@mail.gmail.com>
 <CACaBFwzTZEvkrnegrK9882H8-gn0h5v9=9t3+7Se-sRghEbfZQ@mail.gmail.com>
 <CAHk1PgH4PCZj4Mz8x9SejmNdgtLcpsN29vzOfDqayd9S-ZV_bA@mail.gmail.com>
Message-ID: <CACaBFwy5fB15OvhF-SxQJXDrXj5QpaRc==yLRVMyhOqUVfHDQg@mail.gmail.com>

Nice, thank you very much! This solves my problem.

On Thu, Jan 21, 2016 at 3:56 PM, Nicholas Braden <nicholas11braden at gmail.com
> wrote:

> Ah, I ran into this quirk too - the issue is that you have the quotes
> incorrect:
>
> -DCMAKE_CXX_FLAGS="-march=native"
>
> Should be like this instead:
>
> "-DCMAKE_CXX_FLAGS=-march=native"
>
> Try that and see if it helps, I am pretty sure I ran into the exact
> same problem.
>
> On Thu, Jan 21, 2016 at 8:27 AM, fkillus <fkillus at googlemail.com> wrote:
> > Thanks for clarifying that external projects are not aware of the project
> > they are embedded in.
> > The CMAKE_COMPILER_IS_GNUCXX variable should be set automatically by
> CMake
> > as far
> > as I understand it (see https://cmake.org/Wiki/CMake_Useful_Variables).
> >
> > I narrowed down the problem by creating a minimal setup which still
> > reproduces the issue.
> > In this case the super project is simply a wrapper around an external
> dummy
> > project.
> >
> > external/CMakeLists.txt:
> >
> >   cmake_minimum_required( VERSION 3.4 )
> >   project( external )
> >   message( "External - CMAKE_COMPILER_IS_GNUCXX: "
> > ${CMAKE_COMPILER_IS_GNUCXX} )
> >   message( "External - CMAKE_CXX_COMPILER_ID: " ${CMAKE_CXX_COMPILER_ID}
> )
> >   message( "External - CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )
> >
> > super/CMakeLists.txt:
> >
> >   cmake_minimum_required( VERSION 3.4 )
> >   project( super )
> >   message( "Super - CMAKE_COMPILER_IS_GNUCXX: "
> ${CMAKE_COMPILER_IS_GNUCXX}
> > )
> >   message( "Super - CMAKE_CXX_COMPILER_ID: " ${CMAKE_CXX_COMPILER_ID} )
> >   message( "Super - CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )
> >   include( ExternalProject )
> >   ExternalProject_Add(
> >     external
> >     DOWNLOAD_COMMAND ""
> >     SOURCE_DIR ${CMAKE_SOURCE_DIR}/../external
> >     CMAKE_ARGS
> >       -DCMAKE_CXX_FLAGS="-march=native"
> >     INSTALL_COMMAND  ""
> >   )
> >
> > The problem occurs when the CMAKE_CXX_FLAGS variable is set inside the
> > ExternalProject_Add
> > command using quotes (i.e. "-march=native" in this example). The output
> > obtained when configuring
> > the super project with 'cmake ../super' is:
> >
> > -- The C compiler identification is GNU 5.2.0
> > -- The CXX compiler identification is GNU 5.2.0
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > Super - CMAKE_COMPILER_IS_GNUCXX: 1
> > Super - CMAKE_CXX_COMPILER_ID: GNU
> > Super - CMAKE_CXX_FLAGS:
> > -- Configuring done
> > -- Generating done
> >
> > Afterwards building with 'make' results in:
> >
> > [ 12%] Creating directories for 'external'
> > [ 25%] No download step for 'external'
> > [ 37%] No patch step for 'external'
> > [ 50%] No update step for 'external'
> > [ 62%] Performing configure step for 'external'
> > -- The C compiler identification is GNU 5.2.0
> > -- The CXX compiler identification is unknown
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > External - CMAKE_COMPILER_IS_GNUCXX:
> > External - CMAKE_CXX_COMPILER_ID:
> > External - CMAKE_CXX_FLAGS: "-march=native"
> > -- Configuring done
> > -- Generating done
> >
> > This shows the compiler is not correctly identified for the external
> > project. Directly configuring
> > the external project with 'cmake -DCMAKE_CXX_FLAGS="-march=native"
> > ../external' works though:
> >
> > -- The C compiler identification is GNU 5.2.0
> > -- The CXX compiler identification is GNU 5.2.0
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > External - CMAKE_COMPILER_IS_GNUCXX: 1
> > External - CMAKE_CXX_COMPILER_ID: GNU
> > External - CMAKE_CXX_FLAGS: -march=native
> > -- Configuring done
> > -- Generating done
> >
> >
> > It also works if the quotations marks in the super project listfile are
> > removed. I.e. changing
> >   CMAKE_ARGS
> >    -DCMAKE_CXX_FLAGS="-march=native"
> > to
> >   CMAKE_ARGS
> >    -DCMAKE_CXX_FLAGS=-march=native
> >
> > The question is now, is it still possible to add mutiple compile flags if
> > one cannot use quotation marks?
> >
> >
> > On Wed, Jan 20, 2016 at 6:58 PM, Nicholas Braden
> > <nicholas11braden at gmail.com> wrote:
> >>
> >> Where/how is that variable normally set? External projects have no
> >> awareness of the project they are in, they just run CMake as usual the
> >> same way you would. If the variable is normally set by CMake itself,
> >> make sure that your containing project and the external project both
> >> find the same compiler. (They each do their own automatic search for
> >> compilers)
> >>
> >> On Wed, Jan 20, 2016 at 11:41 AM, fkillus via CMake <cmake at cmake.org>
> >> wrote:
> >> > I have been trying to compile Ogre [1] as external dependency with
> >> > ExternalProject_Add(). In theory this should be straightforward since
> >> > Ogre
> >> > itself also uses CMake as buildsystem. However, in the process I
> >> > encountered
> >> > the following problem:
> >> >
> >> > Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
> >> > places (e.g. [2]). I am running Linux and compiling with g++ and
> >> > everything
> >> > works fine if I manually configure Ogre with cmake or cmake-gui.
> >> > Unfortunately, after wrapping everything inside ExternalProject_Add(),
> >> > the
> >> > CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
> >> >
> >> > A simple workaround is to manually set this variable, i.e.:
> >> >
> >> >  ExternalProject_Add(
> >> >     ogre
> >> >     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
> >> >     CMAKE_ARGS
> >> >       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
> >> >       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   #
> >> > workaround
> >> >   )
> >> >
> >> > This works, but I'm uncertain if this should be necessary. Is this a
> bug
> >> > or
> >> > a feature?
> >> >
> >> >
> >> > [1] https://bitbucket.org/sinbad/ogre
> >> > [2]
> >> >
> >> >
> https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
> >> >
> >> > --
> >> >
> >> > Powered by www.kitware.com
> >> >
> >> > Please keep messages on-topic and check the CMake FAQ at:
> >> > http://www.cmake.org/Wiki/CMake_FAQ
> >> >
> >> > Kitware offers various services to support the CMake community. For
> more
> >> > information on each offering, please visit:
> >> >
> >> > CMake Support: http://cmake.org/cmake/help/support.html
> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> > CMake Training Courses: http://cmake.org/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/20160121/e8f94c62/attachment-0001.html>

From cedric.doucet at inria.fr  Thu Jan 21 10:10:23 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Thu, 21 Jan 2016 16:10:23 +0100 (CET)
Subject: [CMake] =?iso-8859-1?q?Re=A0=3A_Re=3A__Re_=3A_Re=3A_How_to_pass_a?=
 =?iso-8859-1?q?_configuration_file_to_CMake=3F?=
In-Reply-To: <CAKohaZcj1N4rfiAO-J=_N5_z+wAgyZn_DPRKiWhbOu8+JutzZw@mail.gmail.com>
References: <CAKohaZcj1N4rfiAO-J=_N5_z+wAgyZn_DPRKiWhbOu8+JutzZw@mail.gmail.com>
Message-ID: <1270324540.11543921.1453389023871.JavaMail.zimbra@inria.fr>



Hi Petr,

thank you very much for your answer!

Indeed, comment string arguments seem to be mandatory.
I modified my configuration file like this:

set(ENABLE_DOWNLOAD True CACHE BOOL "Automatic installation of third-party libraries")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Root of GCC")

Now, I get the following error message:

CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a file, not a directory.

I am quite surprised about this message because I thought a file was required to the command 'cmake -C'.

Do you have any idea of what I am doing wrong here?

----- Petr Kmoch <petr.kmoch at gmail.com> a ?crit :
>Hi Cedric.

I believe the comment string argument is mandatory in a set(... CACHE), so it should be something like this:

set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root directory of GCC installation")

Petr


On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet <cedric.doucet at inria.fr> wrote:


Hello,
I do not manage to pass a configuration file to cmake.

I type 'cmake -C ../config.cmake'

where config.cmake belongs to the parent directory and contains these lines:

set(ENABLE_DOWNLOAD True CACHE BOOL)
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)

I get the following error message but I don't understand why:

loading initial cache file ../config.cmake
CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
  set given invalid arguments for CACHE mode.


CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
  set given invalid arguments for CACHE mode.


CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a file, not a directory.


Do you know how to solve this problem?
----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
>
Hi Peter!
Thank you very much!It seems to be exactly what I want. :)I will try to use it.
C?dric
De: "Petr Kmoch" <petr.kmoch at gmail.com>
?: "Cedric Doucet" <cedric.doucet at inria.fr>
Cc: cmake at cmake.org
Envoy?: Lundi 21 D?cembre 2015 13:25:53
Objet: Re: [CMake] How to pass a configuration file to CMake?

Hi Cedric.

I have never used it myself, but I believe you're looking for CMake's command-line option '-C <initial-cache>': https://cmake.org/cmake/help/latest/manual/cmake.1.html

Petr

On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr> wrote:

Hello,
I would like to know if it's possible to pass a configuration file to CMake.I have to pass a lot of information to CMake and the resulting command line is very long to type.Would it be possible to create a file containing all needed definitions and pass it to CMake?
For exemple, instead of typing
cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
would it be possible to create a file containing
CMAKE_BUILD_TYPE=DebugCMAKE_INSTALL_PREFIX=/home/me/thereCMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
and pass it to CMake?
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


>


--

>

> Powered by www.kitware.com

>

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

>

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

>

> CMake Support: http://cmake.org/cmake/help/support.html

> CMake Consulting: http://cmake.org/cmake/help/consulting.html

> CMake Training Courses: http://cmake.org/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/20160121/d76a6cdf/attachment.html>

From attila.krasznahorkay at gmail.com  Thu Jan 21 10:17:13 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Thu, 21 Jan 2016 16:17:13 +0100
Subject: [CMake] Creating RPMs from failing projects with CPack
In-Reply-To: <CAKgx6BLz1g48xEAS7Pc02KamRebnGMgyMXDY+TwbgFXFW_f8dQ@mail.gmail.com>
References: <32FCFA2A-94CD-4C9B-9C54-9928FD5E98D9@gmail.com>
 <CAKgx6BLz1g48xEAS7Pc02KamRebnGMgyMXDY+TwbgFXFW_f8dQ@mail.gmail.com>
Message-ID: <0C86C81E-D3FF-4C03-AA77-6E693E56228C@gmail.com>

Hi Domen,

Thanks a lot for the tip! I'll give it a try. (The "monolithic limitation" should not be an issue for us. We do build single RPMs for our projects.)

Cheers,
            Attila

> On 21 Jan 2016, at 00:49, Domen Vrankar <domen.vrankar at gmail.com> wrote:
> 
>> I have a slightly unusual question (I guess). Is it possible somehow to force CPack to produce RPM files from projects that have build problems?
>> 
>> We use CMake in our nightly build system to test the latest changes in our software. When a build problem occurs we don't want the whole build to fail. To this end, we run the build with:
>> 
>> make -k
>> make -k install/fast
>> 
>> This second target executes the installation no matter what. (We set all our build results as "optional installations".) So that at least the "successful part" of the build would become visible on a shared filesystem.
>> 
>> Now, I'd like to do something similar with CPack. To make it behave like "install/fast" does. All in all, I'd like to tell it to use this "install/fast" target while creating the package instead of the "install" target. Is there any way of making this happen?
> 
> I don't know of any clean way to do this but you could write an
> install script (let's name it install_k.sh):
> 
> #!/bin/bash
> make -k install/fast
> exit 0
> 
> Then your would add two CPACK variables to your CMakeLists.txt:
> 
> #set(CPACK_RPM_COMPONENT_INSTALL "ON") <- I'll explain this commented line later
> set(CPACK_INSTALL_CMAKE_PROJECTS "")
> set(CPACK_INSTALL_COMMANDS "${CMAKE_CURRENT_SOURCE_DIR}/install_k.sh")
> 
> And instead of packaging with "make package" command execute "cpack -G RPM".
> 
> However there is an additional problem that this hack only works for
> monolithic packages (that's why I commented out
> CPACK_RPM_COMPONENT_INSTALL in example above) so you will have to
> disable component packages generation if you are using it.
> 
> Regards,
> Domen
> 
> 2016-01-20 11:26 GMT+01:00 Attila Krasznahorkay
> <attila.krasznahorkay at gmail.com>:
>> Dear All,
>> 
>> I have a slightly unusual question (I guess). Is it possible somehow to force CPack to produce RPM files from projects that have build problems?
>> 
>> We use CMake in our nightly build system to test the latest changes in our software. When a build problem occurs we don't want the whole build to fail. To this end, we run the build with:
>> 
>> make -k
>> make -k install/fast
>> 
>> This second target executes the installation no matter what. (We set all our build results as "optional installations".) So that at least the "successful part" of the build would become visible on a shared filesystem.
>> 
>> Now, I'd like to do something similar with CPack. To make it behave like "install/fast" does. All in all, I'd like to tell it to use this "install/fast" target while creating the package instead of the "install" target. Is there any way of making this happen?
>> 
>> Cheers,
>>              Attila
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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 petr.kmoch at gmail.com  Thu Jan 21 10:22:38 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 21 Jan 2016 16:22:38 +0100
Subject: [CMake] How to pass a configuration file to CMake?
Message-ID: <CAKohaZe+6RGMSWMqvu8iAb3ZGH5qZsfupD8AO_vaz6fM2XmDNw@mail.gmail.com>

It looks as if CMake was interpreting the path as both the source directory
and the initial cache file. Perhaps you could help it by adding the path to
source explicitly:

cmake -C ../config.cmake whatever/your/path/to/source/is

Petr

On Thu, Jan 21, 2016 at 4:10 PM, Cedric Doucet <cedric.doucet at inria.fr>
wrote:

>
>
> Hi Petr,
>
> thank you very much for your answer!
>
> Indeed, comment string arguments seem to be mandatory.
> I modified my configuration file like this:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL "Automatic installation of third-party
> libraries")
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Root of GCC")
>
> Now, I get the following error message:
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
> I am quite surprised about this message because I thought a file was
> required to the command 'cmake -C'.
>
> Do you have any idea of what I am doing wrong here?
>
> ----- Petr Kmoch <petr.kmoch at gmail.com> a ?crit :
> >
> Hi Cedric.
>
> I believe the comment string argument is mandatory in a set(... CACHE), so
> it should be something like this:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root
> directory of GCC installation")
>
> Petr
>
>
> On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
>
>>
>>
>> Hello,
>>
>> I do not manage to pass a configuration file to cmake.
>>
>> I type 'cmake -C ../config.cmake'
>>
>> where config.cmake belongs to the parent directory and contains these
>> lines:
>>
>> set(ENABLE_DOWNLOAD True CACHE BOOL)
>> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>>
>> I get the following error message but I don't understand why:
>>
>> loading initial cache file ../config.cmake
>> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>>   set given invalid arguments for CACHE mode.
>>
>>
>> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>>   set given invalid arguments for CACHE mode.
>>
>>
>> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is
>> a file, not a directory.
>>
>>
>> Do you know how to solve this problem?
>>
>> ----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
>> >
>>
>> Hi Peter!
>>
>> Thank you very much!
>> It seems to be exactly what I want. :)
>> I will try to use it.
>>
>> C?dric
>>
>> ------------------------------
>>
>> *De: *"Petr Kmoch" <petr.kmoch at gmail.com>
>> *?: *"Cedric Doucet" <cedric.doucet at inria.fr>
>> *Cc: *cmake at cmake.org
>> *Envoy?: *Lundi 21 D?cembre 2015 13:25:53
>> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>>
>> Hi Cedric.
>>
>> I have never used it myself, but I believe you're looking for CMake's
>> command-line option '-C <initial-cache>':
>> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>>
>> Petr
>>
>> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr>
>> wrote:
>>
>>>
>>> Hello,
>>>
>>> I would like to know if it's possible to pass a configuration file to
>>> CMake.
>>> I have to pass a lot of information to CMake and the resulting command
>>> line is very long to type.
>>> Would it be possible to create a file containing all needed definitions
>>> and pass it to CMake?
>>>
>>> For exemple, instead of typing
>>>
>>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there
>>> -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>>
>>> would it be possible to create a file containing
>>>
>>> CMAKE_BUILD_TYPE=Debug
>>> CMAKE_INSTALL_PREFIX=/home/me/there
>>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>>
>>> and pass it to CMake?
>>>
>>> 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
>>>
>>
>>
>> >
>>
>>
>>
>>
>> --
>>
>> >
>>
>> > Powered by www.kitware.com
>>
>> >
>>
>> > Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> >
>>
>> > Kitware offers various services to support the CMake community. For
>> more information on each offering, please visit:
>>
>> >
>>
>> > CMake Support: http://cmake.org/cmake/help/support.html
>>
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>
>> > CMake Training Courses: http://cmake.org/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/20160121/ba2af7da/attachment-0001.html>

From chuck.atkins at kitware.com  Thu Jan 21 10:41:10 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 21 Jan 2016 10:41:10 -0500
Subject: [CMake] How to pass a configuration file to CMake?
Message-ID: <CAOXZzG5fb0su1ooO2vjmDQ9PHNSP=LR9ayWdEEfVRDfVfzxcPA@mail.gmail.com>

CMake strongly encourages the use of separate source and build directories
(unlike autotools).  So, try something like this:

mkdir build
cd build
cmake -C /path/to/SuperCoolCacheFile.cmake /path/to/source


- Chuck

On Thu, Jan 21, 2016 at 10:10 AM, Cedric Doucet <cedric.doucet at inria.fr>
wrote:

>
>
> Hi Petr,
>
> thank you very much for your answer!
>
> Indeed, comment string arguments seem to be mandatory.
> I modified my configuration file like this:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL "Automatic installation of third-party
> libraries")
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Root of GCC")
>
> Now, I get the following error message:
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
> I am quite surprised about this message because I thought a file was
> required to the command 'cmake -C'.
>
> Do you have any idea of what I am doing wrong here?
>
> ----- Petr Kmoch <petr.kmoch at gmail.com> a ?crit :
> >
> Hi Cedric.
>
> I believe the comment string argument is mandatory in a set(... CACHE), so
> it should be something like this:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root
> directory of GCC installation")
>
> Petr
>
>
> On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
>
>>
>>
>> Hello,
>>
>> I do not manage to pass a configuration file to cmake.
>>
>> I type 'cmake -C ../config.cmake'
>>
>> where config.cmake belongs to the parent directory and contains these
>> lines:
>>
>> set(ENABLE_DOWNLOAD True CACHE BOOL)
>> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>>
>> I get the following error message but I don't understand why:
>>
>> loading initial cache file ../config.cmake
>> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>>   set given invalid arguments for CACHE mode.
>>
>>
>> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>>   set given invalid arguments for CACHE mode.
>>
>>
>> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is
>> a file, not a directory.
>>
>>
>> Do you know how to solve this problem?
>>
>> ----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
>> >
>>
>> Hi Peter!
>>
>> Thank you very much!
>> It seems to be exactly what I want. :)
>> I will try to use it.
>>
>> C?dric
>>
>> ------------------------------
>>
>> *De: *"Petr Kmoch" <petr.kmoch at gmail.com>
>> *?: *"Cedric Doucet" <cedric.doucet at inria.fr>
>> *Cc: *cmake at cmake.org
>> *Envoy?: *Lundi 21 D?cembre 2015 13:25:53
>> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>>
>> Hi Cedric.
>>
>> I have never used it myself, but I believe you're looking for CMake's
>> command-line option '-C <initial-cache>':
>> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>>
>> Petr
>>
>> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr>
>> wrote:
>>
>>>
>>> Hello,
>>>
>>> I would like to know if it's possible to pass a configuration file to
>>> CMake.
>>> I have to pass a lot of information to CMake and the resulting command
>>> line is very long to type.
>>> Would it be possible to create a file containing all needed definitions
>>> and pass it to CMake?
>>>
>>> For exemple, instead of typing
>>>
>>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there
>>> -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>>
>>> would it be possible to create a file containing
>>>
>>> CMAKE_BUILD_TYPE=Debug
>>> CMAKE_INSTALL_PREFIX=/home/me/there
>>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>>
>>> and pass it to CMake?
>>>
>>> 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
>>>
>>
>>
>> >
>>
>>
>>
>>
>> --
>>
>> >
>>
>> > Powered by www.kitware.com
>>
>> >
>>
>> > Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> >
>>
>> > Kitware offers various services to support the CMake community. For
>> more information on each offering, please visit:
>>
>> >
>>
>> > CMake Support: http://cmake.org/cmake/help/support.html
>>
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>
>> > CMake Training Courses: http://cmake.org/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/20160121/eccb6131/attachment.html>

From cedric.doucet at inria.fr  Thu Jan 21 10:50:45 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Thu, 21 Jan 2016 16:50:45 +0100 (CET)
Subject: [CMake] =?iso-8859-1?q?Re=A0=3A_Re=3A__Re_=3A_Re=3A_Re_=3A_Re=3A_?=
 =?iso-8859-1?q?How_to_pass_a_configuration_file_to_CMake=3F?=
In-Reply-To: <CAOXZzG5fb0su1ooO2vjmDQ9PHNSP=LR9ayWdEEfVRDfVfzxcPA@mail.gmail.com>
References: <CAOXZzG5fb0su1ooO2vjmDQ9PHNSP=LR9ayWdEEfVRDfVfzxcPA@mail.gmail.com>
Message-ID: <939735779.11570735.1453391445048.JavaMail.zimbra@inria.fr>



Thank you Chuck & Petr!
It works fine now! :)

C?dric

----- Chuck Atkins <chuck.atkins at kitware.com> a ?crit :
>CMake strongly encourages the use of separate source and build directories (unlike autotools).  So, try something like this:

mkdir build
cd build
cmake -C /path/to/SuperCoolCacheFile.cmake /path/to/source

- Chuck

>
On Thu, Jan 21, 2016 at 10:10 AM, Cedric Doucet <cedric.doucet at inria.fr> wrote:


Hi Petr,

thank you very much for your answer!

Indeed, comment string arguments seem to be mandatory.
I modified my configuration file like this:

set(ENABLE_DOWNLOAD True CACHE BOOL "Automatic installation of third-party libraries")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Root of GCC")

Now, I get the following error message:

CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a file, not a directory.

I am quite surprised about this message because I thought a file was required to the command 'cmake -C'.

Do you have any idea of what I am doing wrong here?

----- Petr Kmoch <petr.kmoch at gmail.com> a ?crit :
>Hi Cedric.

I believe the comment string argument is mandatory in a set(... CACHE), so it should be something like this:

set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root directory of GCC installation")

Petr


On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet <cedric.doucet at inria.fr> wrote:


Hello,
I do not manage to pass a configuration file to cmake.

I type 'cmake -C ../config.cmake'

where config.cmake belongs to the parent directory and contains these lines:

set(ENABLE_DOWNLOAD True CACHE BOOL)
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)

I get the following error message but I don't understand why:

loading initial cache file ../config.cmake
CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
  set given invalid arguments for CACHE mode.


CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
  set given invalid arguments for CACHE mode.


CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a file, not a directory.


Do you know how to solve this problem?
----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
>
Hi Peter!
Thank you very much!It seems to be exactly what I want. :)I will try to use it.
C?dric
De: "Petr Kmoch" <petr.kmoch at gmail.com>
?: "Cedric Doucet" <cedric.doucet at inria.fr>
Cc: cmake at cmake.org
Envoy?: Lundi 21 D?cembre 2015 13:25:53
Objet: Re: [CMake] How to pass a configuration file to CMake?

Hi Cedric.

I have never used it myself, but I believe you're looking for CMake's command-line option '-C <initial-cache>': https://cmake.org/cmake/help/latest/manual/cmake.1.html

Petr

On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr> wrote:

Hello,
I would like to know if it's possible to pass a configuration file to CMake.I have to pass a lot of information to CMake and the resulting command line is very long to type.Would it be possible to create a file containing all needed definitions and pass it to CMake?
For exemple, instead of typing
cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
would it be possible to create a file containing
CMAKE_BUILD_TYPE=DebugCMAKE_INSTALL_PREFIX=/home/me/thereCMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
and pass it to CMake?
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


>


--

>

> Powered by www.kitware.com

>

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

>

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

>

> CMake Support: http://cmake.org/cmake/help/support.html

> CMake Consulting: http://cmake.org/cmake/help/consulting.html

> CMake Training Courses: http://cmake.org/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/20160121/073eb84b/attachment-0001.html>

From ggarra13 at gmail.com  Thu Jan 21 11:00:24 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Thu, 21 Jan 2016 13:00:24 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <56A0DD1A.5010504@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
 <56A0D4B1.3040009@gmail.com> <56A0DD1A.5010504@kitware.com>
Message-ID: <56A10098.4030304@gmail.com>


> Thanks.  This is consistent with the call stack shown in your original
> post.  That line is always executed so we need to figure out what goes
> wrong with it in your particular case.  Since you can reproduce it in
> mrViewer's configuration that is a good starting point.  Try removing
> sources and libraries from mrViewer/src/CMakeLists.txt to simplify
> it while still reproducing the problem.  If you can get rid of most
> of the find_package calls at the top and the uses of their results
> while still showing the problem then I can likely use that to get
> the problem reproduced locally.
>

Find attached the mrViewer/src/CMakeList.txt file that still fails.

The problem is the dependency on ACESclip library, which is built as 
another library within the project.  Taking that library out makes the 
code parse and start compiling.
Maybe I am setting the two projects wrong, but I wanted to have both 
projects compile from the top CMakeLists.txt file, and also be able to 
compile the library individually.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com

-------------- next part --------------




#
# These are the libraries we will depend on
#

# For window management
FIND_PACKAGE( FLTK2       REQUIRED )    # for window management




#
# List directories for -I options.
#
INCLUDE_DIRECTORIES(
  ${FLTK2_INCLUDE_DIR}
  )


FLTK_WRAP_UI( mrViewer  
  gui/aviSave.fl
  )




SET( SOURCES 

  ${mrViewer_FLTK_UI_SRCS}

  )



SET( LIBRARIES 
  ${FLTK2_LIBRARIES}
  )


ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} )
TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ACESclip )

SET_TARGET_PROPERTIES( mrViewer
  PROPERTIES
  LINK_FLAGS "${LINK_FLAGS}"
  )


From ggarra13 at gmail.com  Thu Jan 21 12:03:22 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Thu, 21 Jan 2016 14:03:22 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <56A0DD1A.5010504@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
 <56A0D4B1.3040009@gmail.com> <56A0DD1A.5010504@kitware.com>
Message-ID: <56A10F5A.8030309@gmail.com>



El 21/01/16 a las 10:28, Brad King escribi?:
> Thanks. This is consistent with the call stack shown in your original 
> post. That line is always executed so we need to figure out what goes 
> wrong with it in your particular case. Since you can reproduce it in 
I forgot to mention.  FLTK2.0 is available on SVN only here:

     svn co http://seriss.com/public/fltk/fltk/trunk fltk-2.0


-- 
Gonzalo Garramu?o
ggarra13 at gmail.com

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

From xavier.besseron at uni.lu  Thu Jan 21 12:43:25 2016
From: xavier.besseron at uni.lu (Xavier Besseron)
Date: Thu, 21 Jan 2016 18:43:25 +0100
Subject: [CMake] How to pass a configuration file to CMake?
Message-ID: <CABgOZMYA_gYbxnKTpxExfJCL2P8xR_1R0hN11pmK+bUV_obmeQ@mail.gmail.com>

Hi Cedric,

I believe you should do it this way:

Your config.cmake file should be:

set(ENABLE_DOWNLOAD True CACHE BOOL "")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "")



In the signature of set() for "Set Cache Entry", the *docstring* is
mandatory.
cf https://cmake.org/cmake/help/v3.4/command/set.html#set-cache-entry


And you forgot the path to your source directory in your CMake command line
:

cmake -C ../config.cmake /path/to/your/source




I hope this helps!

Xavier



On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet <cedric.doucet at inria.fr>
wrote:

>
>
> Hello,
>
> I do not manage to pass a configuration file to cmake.
>
> I type 'cmake -C ../config.cmake'
>
> where config.cmake belongs to the parent directory and contains these
> lines:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL)
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>
> I get the following error message but I don't understand why:
>
> loading initial cache file ../config.cmake
> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
>
> Do you know how to solve this problem?
>
> ----- Cedric Doucet <cedric.doucet at inria.fr> a ?crit :
> >
>
> Hi Peter!
>
> Thank you very much!
> It seems to be exactly what I want. :)
> I will try to use it.
>
> C?dric
>
> ------------------------------
>
> *De: *"Petr Kmoch" <petr.kmoch at gmail.com>
> *?: *"Cedric Doucet" <cedric.doucet at inria.fr>
> *Cc: *cmake at cmake.org
> *Envoy?: *Lundi 21 D?cembre 2015 13:25:53
> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>
> Hi Cedric.
>
> I have never used it myself, but I believe you're looking for CMake's
> command-line option '-C <initial-cache>':
> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>
> Petr
>
> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet <cedric.doucet at inria.fr>
> wrote:
>
>>
>> Hello,
>>
>> I would like to know if it's possible to pass a configuration file to
>> CMake.
>> I have to pass a lot of information to CMake and the resulting command
>> line is very long to type.
>> Would it be possible to create a file containing all needed definitions
>> and pass it to CMake?
>>
>> For exemple, instead of typing
>>
>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> would it be possible to create a file containing
>>
>> CMAKE_BUILD_TYPE=Debug
>> CMAKE_INSTALL_PREFIX=/home/me/there
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> and pass it to CMake?
>>
>> 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
>>
>
>
> >
>
>
>
>


-- 
Dr Xavier BESSERON
Research associate
FSTC, University of Luxembourg
Campus Kirchberg, Office E-007
Phone: +352 46 66 44 5418
http://luxdem.uni.lu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160121/f265d5ec/attachment.html>

From brad.king at kitware.com  Thu Jan 21 13:47:43 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jan 2016 13:47:43 -0500
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <56A10098.4030304@gmail.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
 <56A0D4B1.3040009@gmail.com> <56A0DD1A.5010504@kitware.com>
 <56A10098.4030304@gmail.com>
Message-ID: <56A127CF.30701@kitware.com>

On 01/21/2016 11:00 AM, Gonzalo wrote:
> Find attached the mrViewer/src/CMakeList.txt file that still fails.

Thanks.  From that I was able to reproduce it in a small test case
with CMake 3.4.  It appears that the problem has been fixed since
then in 'master'.  I've added a test case to keep it working:

 Tests: Cover fltk_wrap_ui on an executable that links libraries
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f98ae28e

Thanks,
-Brad


From ggarra13 at gmail.com  Thu Jan 21 14:08:44 2016
From: ggarra13 at gmail.com (=?UTF-8?B?R29uemFsbyBHYXJyYW11w7Fv?=)
Date: Thu, 21 Jan 2016 16:08:44 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <56A127CF.30701@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
 <56A0D4B1.3040009@gmail.com> <56A0DD1A.5010504@kitware.com>
 <56A10098.4030304@gmail.com> <56A127CF.30701@kitware.com>
Message-ID: <56A12CBC.10603@gmail.com>

On 21/01/2016 03:47 p.m., Brad King wrote:
> On 01/21/2016 11:00 AM, Gonzalo wrote:
>> Find attached the mrViewer/src/CMakeList.txt file that still fails.
> Thanks.  From that I was able to reproduce it in a small test case
> with CMake 3.4.  It appears that the problem has been fixed since
> then in 'master'.  I've added a test case to keep it working:
Thank you very much for the prompt resolution.   I'll check the master 
repo and shall confirm if all is fixed.

Once again,
thank you very mucho :D


From david.kuegler at gris.informatik.tu-darmstadt.de  Thu Jan 21 14:33:12 2016
From: david.kuegler at gris.informatik.tu-darmstadt.de (=?iso-8859-1?Q?K=FCgler=2C_David?=)
Date: Thu, 21 Jan 2016 19:33:12 +0000
Subject: [CMake] ExternalProject not being configured / custom_command not
	executed
Message-ID: <91200C1B8609A64FAB0B8F6F86EF81B92041F292@EXMBS1.ad.igd.fraunhofer.de>

Hello everybody,

I am trying to build a Project (via ExternalProject from a parent project).

More precisely, I want to build the plus Toolkit (plustoolkit.org) and the subprojects using the build "superproject" (i.e. PlusBuild).

It partly seems to work fine, but the ExternalProject PlusApp never actually gets built. Build-rule-files in the CMakeFiles folder are created, but it seems, the "configure"-command is never actually called. Thusly there is never ANY file created in the BINARY_DIR of the PlusApp-project subfolder.

Why do I ask you guys, and not the people from Plus? Because a second subproject (i.e. PlusLib) just works fine, AND if I go ahead and extract the configure-command (i.e. the command-line-command) either from -trace-expand or from the PlusApp-CfgCmd.txt file (replacing ';' with '" "' (space and double quotation) ) it works fine.

So: The command to configure, and the rule-files are created from CMake, but the command is actually not executed and I cannot say why.

This definitely seems to be a hiccup in CMake, but I am at a deadend.

Any Idea, why this is so?

Using CMake 3.4.10 ; Visual Studio 2013 x64 ; Windows 8.1 ; plustoolkit
(I hope this would be the relevant information)

Thank you!
David

--
Dipl.-Ing. David K?gler
Gruppe "Medical Computing"
Fachgebiet Graphisch-Interaktive Systeme
Technische Universit?t Darmstadt

Geb?ude S3|05
Fraunhoferstr. 5
64289 Darmstadt

Tel.: +49 6151 155-672
Fax: +49 6151 155-603
david.kuegler at gris.tu-darmstadt.de
http://www.gris.tu-darmstadt.de/

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

From ggarra13 at gmail.com  Thu Jan 21 14:53:44 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Thu, 21 Jan 2016 16:53:44 -0300
Subject: [CMake] Internal error bug in v3.4.2.
In-Reply-To: <56A127CF.30701@kitware.com>
References: <569EE622.4070906@gmail.com> <569F9899.9050804@kitware.com>
 <569FD615.70507@gmail.com> <569FD74E.8000708@kitware.com>
 <56A0D4B1.3040009@gmail.com> <56A0DD1A.5010504@kitware.com>
 <56A10098.4030304@gmail.com> <56A127CF.30701@kitware.com>
Message-ID: <56A13748.4000903@gmail.com>

El 21/01/16 a las 15:47, Brad King escribi?:
> Thanks.  From that I was able to reproduce it in a small test case
> with CMake 3.4.  It appears that the problem has been fixed since
> then in 'master'.  I've added a test case to keep it working:
I confirm the bug is squashed in master!  Congratulations and thanks again.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From bill.hoffman at kitware.com  Thu Jan 21 14:57:37 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Thu, 21 Jan 2016 14:57:37 -0500
Subject: [CMake] ExternalProject not being configured / custom_command
 not executed
In-Reply-To: <91200C1B8609A64FAB0B8F6F86EF81B92041F292@EXMBS1.ad.igd.fraunhofer.de>
References: <91200C1B8609A64FAB0B8F6F86EF81B92041F292@EXMBS1.ad.igd.fraunhofer.de>
Message-ID: <56A13831.3010808@kitware.com>

On 1/21/2016 2:33 PM, K?gler, David wrote:
> Hello everybody,
>
> I am trying to build a Project (via ExternalProject from a parent project).
>
> More precisely, I want to build the plus Toolkit (plustoolkit.org) and
> the subprojects using the build ?superproject? (i.e. PlusBuild).
>
> It partly seems to work fine, but the ExternalProject PlusApp never
> actually gets built. Build-rule-files in the CMakeFiles folder are
> created, but it seems, the ?configure?-command is never actually called.
> Thusly there is never ANY file created in the BINARY_DIR of the
> PlusApp-project subfolder.
>
> Why do I ask you guys, and not the people from Plus? Because a second
> subproject (i.e. PlusLib) just works fine, AND if I go ahead and extract
> the configure-command (i.e. the command-line-command) either from
> ?trace-expand or from the PlusApp-CfgCmd.txt file (replacing ?;? with ??
> ?? (space and double quotation) ) it works fine.
>
> So: The command to configure, and the rule-files are created from CMake,
> but the command is actually not executed and I cannot say why.
>
> This definitely seems to be a hiccup in CMake, but I am at a deadend.
>
> Any Idea, why this is so?
>
> Using CMake 3.4.10 ; Visual Studio 2013 x64 ; Windows 8.1 ; plustoolkit
>
> (I hope this would be the relevant information)
>
Still sounds like a question for the PlusApp guys.  It is possible that 
they have some error in their CMakeLists.txt files that prevents this 
from working.  CMake is pretty well tested and external project tests 
are all passing for that platform and version  of CMake.

-Bill


From ewmailing at gmail.com  Thu Jan 21 18:16:34 2016
From: ewmailing at gmail.com (Eric Wing)
Date: Thu, 21 Jan 2016 15:16:34 -0800
Subject: [CMake] XCode Generation Issue
In-Reply-To: <404CBD9D-EB12-4D3A-94E6-F0CFA0925283@morsberger.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
 <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
 <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>
 <CA+Q62MBkeRDXEzt7dEpeQbzixV83OpyWAbPg92nSUhv3zS3Ksg@mail.gmail.com>
 <404CBD9D-EB12-4D3A-94E6-F0CFA0925283@morsberger.com>
Message-ID: <CA+Q62MAxq4+2_JvpSFBf3WO1OKzj3XMx=1zrbP8WODwJeWUmFQ@mail.gmail.com>

On 1/21/16, David Morsberger <dave at morsberger.com> wrote:
> Eric,
>
> I went down a rabbit hole and pulled myself back out. I narrowed it down to
> the following.
>
> We are using cmake to check if the linker supports -Wl,?as-needed. The test
> compile (and link?) command cmake builds using ?cmake -G Xcode?  does not
> fail.
>
> The command from ?cmake -G? has been narrowed down to the following:
>
> $
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> \
>  -Qunused-arguments \
>  -DWS_LD_FLAG_VALID0 \
>  -Wl,--as-needed \
>  -c src.c \
>  -o src.o
> $
>
> The following modified command generates an error:
>
> $
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> \
>  -Qunused-arguments \
>  -DWS_LD_FLAG_VALID0 \
>  -Wl,--as-needed \
>  src.c
>
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> $
>
> It appears the linker isn?t called when the -c and the -o options are
> present. The following warning is generated when the ?-Qunused-arguments? is
> removed.
>
> clang: warning: -Wl,--as-needed: 'linker' input unused
>
> The cmake logic in CMakeLists.txt is basically:
>
>    SET(CMAKE_REQUIRED_FLAGS "${_FLAG}")
>    CHECK_C_SOURCE_RUNS(?int main() { return 0;}" ${_RESULT})
>
> where _FLAG is set to ?-DWS_LD_FLAG_VALID0 -Wl,?-as-needed?
>
>
> So, how/where is the clang compile/link command generated and why isn?t it
> being setup for clang to link?
>
>

Sorry, these are internals I'm not very familiar with. I'm just
starting to get up to speed on the CMake internals for the Makefile
generator (Linux focus) because I'm trying to add a Swift backend.

My impression has always been (this could be wrong) that the Xcode
generator has more deference to Xcode than CMake actively getting
involved. I probably helped push this attitude too because Apple tries
to handle a lot of specific details through Xcode that they feel is
too arcane to expect/require their developers to know about. In
general, I find this to be the right thing, because ultimately getting
stuff that works well with Obj-C (CMake makefiles have a bug where
they compile as Obj-C++), all the packaging and codesigning, and
working with the iOS simulator are platform specific and somewhat
private/changing implementation details they don't want us to manually
hardcode.


Anyway, to your question, I almost never use CHECK_ commands so I'm not sure.
CHECK_C_SOURCE_RUNS is something I would never use because 'running'
is a serious problem for cross-compilation (Mac was
PowerPC/Intel/32-bit/64-bit, iOS is armv6/armv7(s)/arm64/i386).
Cross-compilation is kind of built-into Xcode's thinking now because
there are so many targets. I don't even know how LLVM bitcode factors
into this now, but hopefully the idea of deference to Xcode is that I
mostly won't need to care.

Are there separate CHECK_ commands for compilation and linking
(without running)?

-Eric

From andrew.amaclean at gmail.com  Thu Jan 21 23:00:10 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 22 Jan 2016 15:00:10 +1100
Subject: [CMake] CMake 3.4.2 available for download
In-Reply-To: <56A0DF6F.4020402@kitware.com>
References: <CAHDsG9PwDGmOkf=ij8kidrB3aP_v6WrUT2e4ULa+W9bDaqE9CA@mail.gmail.com>
 <569F8B0F.1090002@kitware.com>
 <CAHDsG9PHOA_eHk6K7EPY=xqOJYyJK5aXPohOxG5cZvo_iJqO2Q@mail.gmail.com>
 <56A0DF6F.4020402@kitware.com>
Message-ID: <CAHDsG9P2+Xos2CKozW4D=cvONTZMZvH2T7w1+QdOe84XRmZvXg@mail.gmail.com>

Thanks for this Brad, your comments in
https://cmake.org/Bug/view.php?id=15929#c40287 make it very clear as to
what is happening.

I had naively assumed that when installing a new Visual Studio compiler
that the latest SDK would be also installed! It is nice to see that CMake
3.4.2 does the checks now! It is nice to get a message.

I'll update the SDK on my other machine on Monday, unless you want me to
test something.

Andrew

On Fri, Jan 22, 2016 at 12:38 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/20/2016 04:36 PM, Andrew Maclean wrote:
> > "CMake Error at CMakeLists.txt:1 (project):
> >   Could not find an appropriate version of the Windows 10 SDK installed
> on
> >   this machine"
> >
> > In CMakeOutput.log, there is one line:
> > "The system is: Windows - 10.0.10586 - AMD64"
>
> It looks like this has been reported to the issue tracker here:
>
>  https://cmake.org/Bug/view.php?id=15929
>
> Please follow discussion over there for more.
>
> Thanks,
> -Brad
>
>


-- 
___________________________________________
Andrew J. P. Maclean

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

From ggarra13 at gmail.com  Thu Jan 21 12:49:40 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Thu, 21 Jan 2016 14:49:40 -0300
Subject: [CMake] Shared library for a executable
Message-ID: <56A11A34.1040005@gmail.com>

I have the need to have a shared library be created and then this same 
library be accessed by my executable.
I want both to remain in different sibling directories and have one main 
CMakeList.txt that would call the other two CMakeList.txt (one in the 
lib dir, one in the exe dir) to build the library and the executable.
In addition, I would like my library to be able to be compiled by itself 
(its own project).

Can someone point me how to do this?  I set it up for my program with 
v2.8 but now this is failing on 3.4.2.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From sam.thursfield at codethink.co.uk  Fri Jan 22 05:41:54 2016
From: sam.thursfield at codethink.co.uk (Sam Thursfield)
Date: Fri, 22 Jan 2016 10:41:54 +0000
Subject: [CMake] Announcing Buildroot.cmake: a CMake module that wraps the
 Buildroot build system
Message-ID: <56A20772.3020907@codethink.co.uk>

Hello

I'd like to announce the release of Buildroot.cmake, available here: 
<https://github.com/raumfeld/Buildroot.cmake>

This was developed thanks to Teufel, who make the Raumfeld multi-room 
audio system. The firmware for Raumfeld speakers is built using 
Buildroot. There are several different platforms and devices that they 
need to support (a total of 15 different configurations being built from 
the same Buildroot tree) so we have introduced a meta-build system to 
drive all them. This toplevel meta-build system is generated by CMake, 
and uses the Buildroot.cmake module to wrap Buildroot's own Makefile.

This is a rough initial release, with only minimal documentation and 
examples. Questions, bug reports and patches are welcome, although I 
don't yet know how much time we'll be able to devote to on-going 
maintenance.

If it turns out to be widely useful then maybe we can look at supporting 
it as part of the Buildroot or CMake projects. I hope it is of interest 
to some readers of this list, anyway!

Thanks
Sam

-- 
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575

From vania.joloboff at inria.fr  Fri Jan 22 06:29:01 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Fri, 22 Jan 2016 12:29:01 +0100
Subject: [CMake] string regexp replace removes the semicolons
In-Reply-To: <CA+Q62MAxq4+2_JvpSFBf3WO1OKzj3XMx=1zrbP8WODwJeWUmFQ@mail.gmail.com>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
 <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
 <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>
 <CA+Q62MBkeRDXEzt7dEpeQbzixV83OpyWAbPg92nSUhv3zS3Ksg@mail.gmail.com>
 <404CBD9D-EB12-4D3A-94E6-F0CFA0925283@morsberger.com>
 <CA+Q62MAxq4+2_JvpSFBf3WO1OKzj3XMx=1zrbP8WODwJeWUmFQ@mail.gmail.com>
Message-ID: <56A2127D.4060108@inria.fr>

Hi

I want to remove from a list of sources those that start with 'foo'
So I have

file(GLOB ALL_SOURCES "*.cc")
# this gives ALL_SOURCES = "a.cc;b.cc;foo_u.cc;foo_v.cc;c.cc;y.cc"
# separated by semicolons

string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ${ALL_SOURCES})

But in the COMPILE_ONLY variable the semicolons are removed !
and then
add_library(lib ${COMPILE_ONLY}) fails

why is it removing the semicolons ?
Vania


From michael.stuermer at schaeffler.com  Fri Jan 22 05:30:02 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Fri, 22 Jan 2016 10:30:02 +0000
Subject: [CMake] CTest integration in Visual Studio TestExplorer
Message-ID: <8459a300caa94947a53f9d35608174bc@DE013815.schaeffler.com>

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>


From marc.chevrier at sap.com  Fri Jan 22 07:06:45 2016
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Fri, 22 Jan 2016 12:06:45 +0000
Subject: [CMake] string regexp replace removes the semicolons
In-Reply-To: <56A2127D.4060108@inria.fr>
References: <D67A6883-7698-412F-B384-C452C51A8D18@morsberger.com>
 <8A2CCE60-0355-4B36-86F5-2FEA9FD2C0EF@morsberger.com>
 <CA+Q62MDJEmCd7c078W-ZfO2tvfPBQYb5a4gMen16phgjOu=f0g@mail.gmail.com>
 <BA8F9AEF-B40F-4B0E-B27A-9C1FCAD3D74B@morsberger.com>
 <CA+Q62MBkeRDXEzt7dEpeQbzixV83OpyWAbPg92nSUhv3zS3Ksg@mail.gmail.com>
 <404CBD9D-EB12-4D3A-94E6-F0CFA0925283@morsberger.com>
 <CA+Q62MAxq4+2_JvpSFBf3WO1OKzj3XMx=1zrbP8WODwJeWUmFQ@mail.gmail.com>
 <56A2127D.4060108@inria.fr>
Message-ID: <5A123D07-96A4-4D7C-B4C7-2BC66653A9E7@sap.com>

Hi,

Command file(GLOB) returns a CMake list (in a CMake list, items are separated by ;)

Now you pass to command string the content of the list, so the list is expanded: in your example,
string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ${ALL_SOURCES})

Is equivalent to:
string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY a.cc b.cc foo_u.cc foo_v.cc c.cc y.cc)

So, command string will concatenate all the input strings in a single string.

To keep semi colons, you have to pass ALL_SOURCES as a string, not a list:
string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ?${ALL_SOURCES}")






On 22/01/16 12:29, "CMake on behalf of Vania Joloboff" <cmake-bounces at cmake.org on behalf of vania.joloboff at inria.fr> wrote:

>Hi
>
>I want to remove from a list of sources those that start with 'foo'
>So I have
>
>file(GLOB ALL_SOURCES "*.cc")
># this gives ALL_SOURCES = "a.cc;b.cc;foo_u.cc;foo_v.cc;c.cc;y.cc"
># separated by semicolons
>
>string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ${ALL_SOURCES})
>
>But in the COMPILE_ONLY variable the semicolons are removed !
>and then
>add_library(lib ${COMPILE_ONLY}) fails
>
>why is it removing the semicolons ?
>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 rwan.work at gmail.com  Fri Jan 22 08:50:10 2016
From: rwan.work at gmail.com (Raymond Wan)
Date: Fri, 22 Jan 2016 21:50:10 +0800
Subject: [CMake] Shared library for a executable
In-Reply-To: <56A11A34.1040005@gmail.com>
References: <56A11A34.1040005@gmail.com>
Message-ID: <CAH8UK3UEzOBjcNTckN1pduaCo-=Mcnv0G=o-ECm9q6aFQ26veg@mail.gmail.com>

Hi Gonzalo,



On Fri, Jan 22, 2016 at 1:49 AM, Gonzalo <ggarra13 at gmail.com> wrote:
> I have the need to have a shared library be created and then this same
> library be accessed by my executable.
> I want both to remain in different sibling directories and have one main
> CMakeList.txt that would call the other two CMakeList.txt (one in the lib
> dir, one in the exe dir) to build the library and the executable.
> In addition, I would like my library to be able to be compiled by itself
> (its own project).
>
> Can someone point me how to do this?  I set it up for my program with v2.8
> but now this is failing on 3.4.2.


I recently tried doing this and wrote it up as a record for myself.
Of course, I don't know if it's the right way, but I'm doing it this
way until I figure out a better way...

See if this helps and let me know if you figure out something better:

http://www.rwanwork.info/sysdocs/cmake/overview/

Ray

From tom.kacvinsky at vectorcast.com  Fri Jan 22 09:23:53 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Fri, 22 Jan 2016 09:23:53 -0500
Subject: [CMake] PROPERTY for list of link libraries
Message-ID: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>

I have need for a cross platform methods of getting libraries linked
into an executable.

Say for instance, we have

add_library(foo STATIC a.c)
add_exceutable(bar b.c)
target_link_libraries(bar foo)

So I know for that bar has a dependency on foo.lib (on Windows) and
libfoo.a on Linux.

And so forth.  What I would like to do is after everything is set up,
query the properties of bar
and find the list of libraries linked into bar in such a fashion I get
that platform's specific library name (instead of the library's target
name).

IS this possible?  I read the docs and didn't see a property for
getting this list.  Did I miss something?  If so I plan on using
either get_property of get_target_property.

Thanks.

From omnijack at gmail.com  Fri Jan 22 10:14:27 2016
From: omnijack at gmail.com (Jack Stalnaker)
Date: Fri, 22 Jan 2016 09:14:27 -0600
Subject: [CMake] exclude a dependency from export
Message-ID: <CAOGUJ6HQh7ZHKz58F_-__NsTW=ZPWOaNgi4M9nBMvNrTRTS4_w@mail.gmail.com>

Is there any way to exclude a dependency from an export? If I build a
static library target "A" but do not wish to install it, and then link that
target to another target "B" using target_link_libraries(B A), and then
attempt to export B, I get the error message:

install (EXPORT "B" ...) includes target "B" which requires target "A" that
is not in the export set.

I can solve the problem by installing A, but there is no need to. It is a
temporary target that is statically linked. I just need to export for
creating a package config file, so there's no need for the package config
to ever need to worry about statically linked libraries.

Is there a workaround for this?

Long story short, I am trying to replicate convenience libraries from
autotools. I'm having a hell of time doing it. I can use lists of sources,
but that requires passing around global variables that include the sources
and others that include the required libraries. This is far messier and far
less convenient. I've tried object libraries, and while they eliminate the
global source variables and prevent rebuilding things, they fail when the
source is nested, and you want to build a "super library" from smaller
object libraries, which I believe is a fairly common working pattern.
Building a static library that is never installed works really well ...
until I go to create a package config file. Then this export fails.

Thanks,
--Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160122/0aca5075/attachment.html>

From tom.kacvinsky at vectorcast.com  Fri Jan 22 10:19:52 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Fri, 22 Jan 2016 10:19:52 -0500
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
Message-ID: <CAAEKttzwPbYuJUG-+sizJ2VLFdDnUvBXhqreTSfbwwbbhMn-4A@mail.gmail.com>

On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky
<tom.kacvinsky at vectorcast.com> wrote:
> I have need for a cross platform methods of getting libraries linked
> into an executable.
>
> Say for instance, we have
>
> add_library(foo STATIC a.c)
> add_exceutable(bar b.c)
> target_link_libraries(bar foo)
>
> So I know for that bar has a dependency on foo.lib (on Windows) and
> libfoo.a on Linux.
>
> And so forth.  What I would like to do is after everything is set up,
> query the properties of bar
> and find the list of libraries linked into bar in such a fashion I get
> that platform's specific library name (instead of the library's target
> name).
>
> IS this possible?  I read the docs and didn't see a property for
> getting this list.  Did I miss something?  If so I plan on using
> either get_property of get_target_property.
>
> Thanks.

Answering my own question

get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
foreach(lib ${libs})
  if(TARGET ${lib})
    get_property(path TARGET ${lib} PROPERTY LOCATION)
    message(STATUS ${path})
  else()
    message(STATUS ${lib})
  endif()
endforeach()

From d3ck0r at gmail.com  Fri Jan 22 10:42:45 2016
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 22 Jan 2016 07:42:45 -0800
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAAEKttzwPbYuJUG-+sizJ2VLFdDnUvBXhqreTSfbwwbbhMn-4A@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
 <CAAEKttzwPbYuJUG-+sizJ2VLFdDnUvBXhqreTSfbwwbbhMn-4A@mail.gmail.com>
Message-ID: <CAA2GJqUwXD+Q6ymY2GqzDOMMMk0XreUfYXZARFoqczpXx3WQhw@mail.gmail.com>

LOCATION was/is deprecated... the preferred method is generator expressions
https://cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html
$<TARGET_FILE_DIR:tgt>
$<TARGET_FILE_NAME:tgt>

On Fri, Jan 22, 2016 at 7:19 AM, Tom Kacvinsky
<tom.kacvinsky at vectorcast.com> wrote:
> On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky
> <tom.kacvinsky at vectorcast.com> wrote:
>> I have need for a cross platform methods of getting libraries linked
>> into an executable.
>>
>> Say for instance, we have
>>
>> add_library(foo STATIC a.c)
>> add_exceutable(bar b.c)
>> target_link_libraries(bar foo)
>>
>> So I know for that bar has a dependency on foo.lib (on Windows) and
>> libfoo.a on Linux.
>>
>> And so forth.  What I would like to do is after everything is set up,
>> query the properties of bar
>> and find the list of libraries linked into bar in such a fashion I get
>> that platform's specific library name (instead of the library's target
>> name).
>>
>> IS this possible?  I read the docs and didn't see a property for
>> getting this list.  Did I miss something?  If so I plan on using
>> either get_property of get_target_property.
>>
>> Thanks.
>
> Answering my own question
>
> get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
> foreach(lib ${libs})
>   if(TARGET ${lib})
>     get_property(path TARGET ${lib} PROPERTY LOCATION)
>     message(STATUS ${path})
>   else()
>     message(STATUS ${lib})
>   endif()
> endforeach()
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 post at hendrik-sattler.de  Fri Jan 22 11:19:37 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Fri, 22 Jan 2016 17:19:37 +0100
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
Message-ID: <999D45E8-0D55-4C36-8EF6-B0B2BB5AAFD9@hendrik-sattler.de>



Am 22. Januar 2016 15:23:53 MEZ, schrieb Tom Kacvinsky <tom.kacvinsky at vectorcast.com>:
>I have need for a cross platform methods of getting libraries linked
>into an executable.
>
>Say for instance, we have
>
>add_library(foo STATIC a.c)
>add_exceutable(bar b.c)
>target_link_libraries(bar foo)
>
>So I know for that bar has a dependency on foo.lib (on Windows) and
>libfoo.a on Linux.
>
>And so forth.  What I would like to do is after everything is set up,
>query the properties of bar
>and find the list of libraries linked into bar in such a fashion I get
>that platform's specific library name (instead of the library's target
>name).

Is that the description of your problem or part of your idea of a solution?

If you need the real list after the executable is built, you can use
https://cmake.org/cmake/help/v3.4/module/GetPrerequisites.html

I use that to assemble a  build directory on windows where the executable can be debugged easily. Use it as part of a post build cmake script that of configured with the proper search paths.

>IS this possible?  I read the docs and didn't see a property for
>getting this list.  Did I miss something?  If so I plan on using
>either get_property of get_target_property.
>
>Thanks.


From nicholas11braden at gmail.com  Fri Jan 22 12:51:00 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Fri, 22 Jan 2016 11:51:00 -0600
Subject: [CMake] exclude a dependency from export
In-Reply-To: <CAOGUJ6HQh7ZHKz58F_-__NsTW=ZPWOaNgi4M9nBMvNrTRTS4_w@mail.gmail.com>
References: <CAOGUJ6HQh7ZHKz58F_-__NsTW=ZPWOaNgi4M9nBMvNrTRTS4_w@mail.gmail.com>
Message-ID: <CAHk1PgHga9rPpzho92tHKvrzqbeFnUgXEuyZ5D88QZiik+3X+w@mail.gmail.com>

Have you tried using the PRIVATE keyword when linking to A?
https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents

On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <omnijack at gmail.com> wrote:
> Is there any way to exclude a dependency from an export? If I build a static
> library target "A" but do not wish to install it, and then link that target
> to another target "B" using target_link_libraries(B A), and then attempt to
> export B, I get the error message:
>
> install (EXPORT "B" ...) includes target "B" which requires target "A" that
> is not in the export set.
>
> I can solve the problem by installing A, but there is no need to. It is a
> temporary target that is statically linked. I just need to export for
> creating a package config file, so there's no need for the package config to
> ever need to worry about statically linked libraries.
>
> Is there a workaround for this?
>
> Long story short, I am trying to replicate convenience libraries from
> autotools. I'm having a hell of time doing it. I can use lists of sources,
> but that requires passing around global variables that include the sources
> and others that include the required libraries. This is far messier and far
> less convenient. I've tried object libraries, and while they eliminate the
> global source variables and prevent rebuilding things, they fail when the
> source is nested, and you want to build a "super library" from smaller
> object libraries, which I believe is a fairly common working pattern.
> Building a static library that is never installed works really well ...
> until I go to create a package config file. Then this export fails.
>
> Thanks,
> --Jack
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 jack.stalnaker at gmail.com  Fri Jan 22 14:20:26 2016
From: jack.stalnaker at gmail.com (Jack Stalnaker)
Date: Fri, 22 Jan 2016 13:20:26 -0600
Subject: [CMake] exclude a dependency from export
In-Reply-To: <CAHk1PgHga9rPpzho92tHKvrzqbeFnUgXEuyZ5D88QZiik+3X+w@mail.gmail.com>
References: <CAOGUJ6HQh7ZHKz58F_-__NsTW=ZPWOaNgi4M9nBMvNrTRTS4_w@mail.gmail.com>
 <CAHk1PgHga9rPpzho92tHKvrzqbeFnUgXEuyZ5D88QZiik+3X+w@mail.gmail.com>
Message-ID: <CAOGUJ6EgvS-9ihyG7grOOY5b=_st4ncYmX_k+05SwDQ8c8QBBw@mail.gmail.com>

Private doesn't work because the names in A need to be part of the public
interface.

On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden <
nicholas11braden at gmail.com> wrote:

> Have you tried using the PRIVATE keyword when linking to A?
>
> https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents
>
> On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <omnijack at gmail.com>
> wrote:
> > Is there any way to exclude a dependency from an export? If I build a
> static
> > library target "A" but do not wish to install it, and then link that
> target
> > to another target "B" using target_link_libraries(B A), and then attempt
> to
> > export B, I get the error message:
> >
> > install (EXPORT "B" ...) includes target "B" which requires target "A"
> that
> > is not in the export set.
> >
> > I can solve the problem by installing A, but there is no need to. It is a
> > temporary target that is statically linked. I just need to export for
> > creating a package config file, so there's no need for the package
> config to
> > ever need to worry about statically linked libraries.
> >
> > Is there a workaround for this?
> >
> > Long story short, I am trying to replicate convenience libraries from
> > autotools. I'm having a hell of time doing it. I can use lists of
> sources,
> > but that requires passing around global variables that include the
> sources
> > and others that include the required libraries. This is far messier and
> far
> > less convenient. I've tried object libraries, and while they eliminate
> the
> > global source variables and prevent rebuilding things, they fail when the
> > source is nested, and you want to build a "super library" from smaller
> > object libraries, which I believe is a fairly common working pattern.
> > Building a static library that is never installed works really well ...
> > until I go to create a package config file. Then this export fails.
> >
> > Thanks,
> > --Jack
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/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/20160122/20105fb6/attachment.html>

From jack.stalnaker at gmail.com  Fri Jan 22 14:38:50 2016
From: jack.stalnaker at gmail.com (Jack Stalnaker)
Date: Fri, 22 Jan 2016 13:38:50 -0600
Subject: [CMake] exclude a dependency from export
In-Reply-To: <CAOGUJ6EgvS-9ihyG7grOOY5b=_st4ncYmX_k+05SwDQ8c8QBBw@mail.gmail.com>
References: <CAOGUJ6HQh7ZHKz58F_-__NsTW=ZPWOaNgi4M9nBMvNrTRTS4_w@mail.gmail.com>
 <CAHk1PgHga9rPpzho92tHKvrzqbeFnUgXEuyZ5D88QZiik+3X+w@mail.gmail.com>
 <CAOGUJ6EgvS-9ihyG7grOOY5b=_st4ncYmX_k+05SwDQ8c8QBBw@mail.gmail.com>
Message-ID: <CAOGUJ6Ed5rzYxm=5BLydW_viCX4H2tp8UAD02cmu4pj=Jho5jg@mail.gmail.com>

I've found several workarounds, though I'm not sure of the long term
ramifications.

1. I can "install" library A to CMAKE_CURRENT_BINARY_DIR effectively doing
nothing. Since A is never referenced, only consumed, this should be okay?

2. I can remove the export from both A's and B's install, and simply not
include the target.cmake file in my package config prototype. I can just
include my targets as variables the same way a FindXXX.cmake file does.
Makes the syntax slightly uglier in that you cannot refer to B by target
name. It also might break the expectations of a user who thinks a package
should include target names.

I've started several discussions here on convenience libraries, and I think
I'm starting to realize the Cmake team has a different definition than I
do. To me, a convenience lib is not just an archived collection of sources.
The convenience lib is already linked to any external libs and already was
compiled with any special flags--in essence it's fully cooked. The nice
thing about this is that it keeps all the details specific to that part of
the code confined to that code's place on disc and that part of the code's
CMakeLists.txt. Object libraries and source list variables require that
other information to be passed around as well, leaking the convenience
lib's requirements all over the code tree. You could argue that that means
A should be a plain old library, then, but installing it serves no purpose.
It will like never be referenced outside of the code tree, and it pollutes
the system library folder.



On Fri, Jan 22, 2016 at 1:20 PM, Jack Stalnaker <jack.stalnaker at gmail.com>
wrote:

> Private doesn't work because the names in A need to be part of the public
> interface.
>
> On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden <
> nicholas11braden at gmail.com> wrote:
>
>> Have you tried using the PRIVATE keyword when linking to A?
>>
>> https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents
>>
>> On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <omnijack at gmail.com>
>> wrote:
>> > Is there any way to exclude a dependency from an export? If I build a
>> static
>> > library target "A" but do not wish to install it, and then link that
>> target
>> > to another target "B" using target_link_libraries(B A), and then
>> attempt to
>> > export B, I get the error message:
>> >
>> > install (EXPORT "B" ...) includes target "B" which requires target "A"
>> that
>> > is not in the export set.
>> >
>> > I can solve the problem by installing A, but there is no need to. It is
>> a
>> > temporary target that is statically linked. I just need to export for
>> > creating a package config file, so there's no need for the package
>> config to
>> > ever need to worry about statically linked libraries.
>> >
>> > Is there a workaround for this?
>> >
>> > Long story short, I am trying to replicate convenience libraries from
>> > autotools. I'm having a hell of time doing it. I can use lists of
>> sources,
>> > but that requires passing around global variables that include the
>> sources
>> > and others that include the required libraries. This is far messier and
>> far
>> > less convenient. I've tried object libraries, and while they eliminate
>> the
>> > global source variables and prevent rebuilding things, they fail when
>> the
>> > source is nested, and you want to build a "super library" from smaller
>> > object libraries, which I believe is a fairly common working pattern.
>> > Building a static library that is never installed works really well ...
>> > until I go to create a package config file. Then this export fails.
>> >
>> > Thanks,
>> > --Jack
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake community. For more
>> > information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/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/20160122/d59dcc86/attachment.html>

From guy at alum.mit.edu  Fri Jan 22 15:24:59 2016
From: guy at alum.mit.edu (Guy Harris)
Date: Fri, 22 Jan 2016 12:24:59 -0800
Subject: [CMake] Checking whether particular *linker* flags are supported
Message-ID: <90E95A04-BA47-4BF6-930B-E54614516BE8@alum.mit.edu>

CMake has the macros CHECK_C_COMPILER_FLAG and CHECK_CXX_COMPILER_FLAG, which allow checking for whether a given C or C++ compiler flag is supported by the compiler being used.

However, there's no CHECK_LINKER_FLAG macro, so that you can check whether a given *linker* flag is supported by the linker being used, so there doesn't seem to be a good way to use a flag, such as the --as-needed flag, if it's not *required*, but is "nice to have", but isn't available on all platforms.

So what's the best way to do such a check?

(I'm assuming here that, for all generators on UN*X platforms, linking is done by using the compiler driver, so that you don't have to worry about, for example, using -Wl,{linker flag} with some generators and just {linker flag} with other generators.)

From tom.kacvinsky at vectorcast.com  Fri Jan 22 16:40:02 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Fri, 22 Jan 2016 16:40:02 -0500
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
Message-ID: <CAAEKttwvpemAd+pEbCZQQCYoh2fgR12O2NENJBvdmcOehLtLhw@mail.gmail.com>

I am now having a problem with transitive dependencies.  I need all
libraries that are linked in.  I am missing the ones that are linked in
transitively.  Modified code is, ignoring J. Decker's suggestion about
using generator expressions to get the path to the target's output.

get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
foreach(lib ${libs})
  if(TARGET ${lib})
    # If this is a library, get its transitive dependencies
    get_property(trans TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
    foreach(tran ${trans})
      if(TARGET ${tran})
        get_property(path TARGET ${tran} PROPERTY LOCATION)
        file(APPEND "${CMAKE_BINARY_DIR/libs.txt" "${path}\n")
      endif()
    endforeach()
    get_property(path TARGET ${lib} PROPERTY LOCATION)
    file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${path}\n")
  else()
    file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${lib}\n")
  endif()
endforeach()

I am using cmake 2.8.11.2, perhaps this property doesn't do what I thought
it would with this version of cmake?

Thanks,

Tom

On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky <tom.kacvinsky at vectorcast.com
> wrote:

> I have need for a cross platform methods of getting libraries linked
> into an executable.
>
> Say for instance, we have
>
> add_library(foo STATIC a.c)
> add_exceutable(bar b.c)
> target_link_libraries(bar foo)
>
> So I know for that bar has a dependency on foo.lib (on Windows) and
> libfoo.a on Linux.
>
> And so forth.  What I would like to do is after everything is set up,
> query the properties of bar
> and find the list of libraries linked into bar in such a fashion I get
> that platform's specific library name (instead of the library's target
> name).
>
> IS this possible?  I read the docs and didn't see a property for
> getting this list.  Did I miss something?  If so I plan on using
> either get_property of get_target_property.
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160122/af59e086/attachment.html>

From tom.kacvinsky at vectorcast.com  Fri Jan 22 17:01:32 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Fri, 22 Jan 2016 17:01:32 -0500
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAAEKttwvpemAd+pEbCZQQCYoh2fgR12O2NENJBvdmcOehLtLhw@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
 <CAAEKttwvpemAd+pEbCZQQCYoh2fgR12O2NENJBvdmcOehLtLhw@mail.gmail.com>
Message-ID: <CAAEKttyYnTZB72MdcK+MOJqCV=KwQCqmyy1g1iHz0gQCeyB1tg@mail.gmail.com>

Ah yes, that was it.  Switching to 3.3.2 did the trick.  Time to upgrade
cmake.

On Fri, Jan 22, 2016 at 4:40 PM, Tom Kacvinsky <tom.kacvinsky at vectorcast.com
> wrote:

> I am now having a problem with transitive dependencies.  I need all
> libraries that are linked in.  I am missing the ones that are linked in
> transitively.  Modified code is, ignoring J. Decker's suggestion about
> using generator expressions to get the path to the target's output.
>
> get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
> foreach(lib ${libs})
>   if(TARGET ${lib})
>     # If this is a library, get its transitive dependencies
>     get_property(trans TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
>     foreach(tran ${trans})
>       if(TARGET ${tran})
>         get_property(path TARGET ${tran} PROPERTY LOCATION)
>         file(APPEND "${CMAKE_BINARY_DIR/libs.txt" "${path}\n")
>       endif()
>     endforeach()
>     get_property(path TARGET ${lib} PROPERTY LOCATION)
>     file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${path}\n")
>   else()
>     file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${lib}\n")
>   endif()
> endforeach()
>
> I am using cmake 2.8.11.2, perhaps this property doesn't do what I thought
> it would with this version of cmake?
>
> Thanks,
>
> Tom
>
> On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky <
> tom.kacvinsky at vectorcast.com> wrote:
>
>> I have need for a cross platform methods of getting libraries linked
>> into an executable.
>>
>> Say for instance, we have
>>
>> add_library(foo STATIC a.c)
>> add_exceutable(bar b.c)
>> target_link_libraries(bar foo)
>>
>> So I know for that bar has a dependency on foo.lib (on Windows) and
>> libfoo.a on Linux.
>>
>> And so forth.  What I would like to do is after everything is set up,
>> query the properties of bar
>> and find the list of libraries linked into bar in such a fashion I get
>> that platform's specific library name (instead of the library's target
>> name).
>>
>> IS this possible?  I read the docs and didn't see a property for
>> getting this list.  Did I miss something?  If so I plan on using
>> either get_property of get_target_property.
>>
>> Thanks.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160122/ac6718c2/attachment.html>

From tamas.kenez at gmail.com  Sat Jan 23 03:14:26 2016
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Sat, 23 Jan 2016 09:14:26 +0100
Subject: [CMake] exclude a dependency from export
In-Reply-To: <CAOGUJ6EgvS-9ihyG7grOOY5b=_st4ncYmX_k+05SwDQ8c8QBBw@mail.gmail.com>
References: <CAOGUJ6HQh7ZHKz58F_-__NsTW=ZPWOaNgi4M9nBMvNrTRTS4_w@mail.gmail.com>
 <CAHk1PgHga9rPpzho92tHKvrzqbeFnUgXEuyZ5D88QZiik+3X+w@mail.gmail.com>
 <CAOGUJ6EgvS-9ihyG7grOOY5b=_st4ncYmX_k+05SwDQ8c8QBBw@mail.gmail.com>
Message-ID: <CAPB8=n8uhTvtQ3fKUy-UzQ=hDCz9NopJN5mhmKKaBgK7D79JTA@mail.gmail.com>

The PRIVATE keyword for `target_link_libraries` has no effect on the
visibility of the names.
If `A` is static and `B` is shared then I think

    target_link_libraries(B PRIVATE A)
    install(TARGETS B ...)

should work for you.

Of course, if B static then it won't work. For that case they've introduced
the OBJECT library.  It has it it's own shortcomings but I've successfully
used it for the 'B'-is-static case.

Tamas

On Fri, Jan 22, 2016 at 8:20 PM, Jack Stalnaker <jack.stalnaker at gmail.com>
wrote:

> Private doesn't work because the names in A need to be part of the public
> interface.
>
> On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden <
> nicholas11braden at gmail.com> wrote:
>
>> Have you tried using the PRIVATE keyword when linking to A?
>>
>> https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents
>>
>> On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <omnijack at gmail.com>
>> wrote:
>> > Is there any way to exclude a dependency from an export? If I build a
>> static
>> > library target "A" but do not wish to install it, and then link that
>> target
>> > to another target "B" using target_link_libraries(B A), and then
>> attempt to
>> > export B, I get the error message:
>> >
>> > install (EXPORT "B" ...) includes target "B" which requires target "A"
>> that
>> > is not in the export set.
>> >
>> > I can solve the problem by installing A, but there is no need to. It is
>> a
>> > temporary target that is statically linked. I just need to export for
>> > creating a package config file, so there's no need for the package
>> config to
>> > ever need to worry about statically linked libraries.
>> >
>> > Is there a workaround for this?
>> >
>> > Long story short, I am trying to replicate convenience libraries from
>> > autotools. I'm having a hell of time doing it. I can use lists of
>> sources,
>> > but that requires passing around global variables that include the
>> sources
>> > and others that include the required libraries. This is far messier and
>> far
>> > less convenient. I've tried object libraries, and while they eliminate
>> the
>> > global source variables and prevent rebuilding things, they fail when
>> the
>> > source is nested, and you want to build a "super library" from smaller
>> > object libraries, which I believe is a fairly common working pattern.
>> > Building a static library that is never installed works really well ...
>> > until I go to create a package config file. Then this export fails.
>> >
>> > Thanks,
>> > --Jack
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake community. For more
>> > information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/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/20160123/ca5160e6/attachment-0001.html>

From ggarra13 at gmail.com  Mon Jan 25 04:22:37 2016
From: ggarra13 at gmail.com (Gonzalo)
Date: Mon, 25 Jan 2016 06:22:37 -0300
Subject: [CMake] Shared library for a executable
In-Reply-To: <CAH8UK3UEzOBjcNTckN1pduaCo-=Mcnv0G=o-ECm9q6aFQ26veg@mail.gmail.com>
References: <56A11A34.1040005@gmail.com>
 <CAH8UK3UEzOBjcNTckN1pduaCo-=Mcnv0G=o-ECm9q6aFQ26veg@mail.gmail.com>
Message-ID: <56A5E95D.1090305@gmail.com>



El 22/01/16 a las 10:50, Raymond Wan escribi?:
> Hi Gonzalo,
>
> I recently tried doing this and wrote it up as a record for myself.
> Of course, I don't know if it's the right way, but I'm doing it this
> way until I figure out a better way...
>
> See if this helps and let me know if you figure out something better:
>
> http://www.rwanwork.info/sysdocs/cmake/overview/
>
> Ray
Thanks, Ray.  Your approach is exactly the same as mine.  We already 
found out that the problem I was having with v3.4.2 is a bug in cmake, 
which has been fixed in the git repository.

-- 
Gonzalo Garramu?o
ggarra13 at gmail.com


From tamas.kenez at gmail.com  Mon Jan 25 04:33:34 2016
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Mon, 25 Jan 2016 10:33:34 +0100
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAAEKttyYnTZB72MdcK+MOJqCV=KwQCqmyy1g1iHz0gQCeyB1tg@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
 <CAAEKttwvpemAd+pEbCZQQCYoh2fgR12O2NENJBvdmcOehLtLhw@mail.gmail.com>
 <CAAEKttyYnTZB72MdcK+MOJqCV=KwQCqmyy1g1iHz0gQCeyB1tg@mail.gmail.com>
Message-ID: <CAPB8=n_40Yo-XkT3Hok8nbghE9Kz5rt6xxXR1q3P=qt-958a9w@mail.gmail.com>

I think you need something like CMakeExpandImportedTargets.cmake (
https://cmake.org/cmake/help/latest/module/CMakeExpandImportedTargets.html).
But that module has been deprecated for a while and does not support some
newer CMake features.

Instead, feel free to try out my fork:
https://gist.github.com/tamaskenez/ef98237fff654c6d28b5 . This fork adds
support for IMPORTED_IMPLIB, INTERFACE_LINK_LIBRARIES and $<CONFIG:>
expressions.

It recursively resolves all dependencies for the given configuration
(Debug, Release, ...)

Tamas


On Fri, Jan 22, 2016 at 11:01 PM, Tom Kacvinsky <
tom.kacvinsky at vectorcast.com> wrote:

> Ah yes, that was it.  Switching to 3.3.2 did the trick.  Time to upgrade
> cmake.
>
> On Fri, Jan 22, 2016 at 4:40 PM, Tom Kacvinsky <
> tom.kacvinsky at vectorcast.com> wrote:
>
>> I am now having a problem with transitive dependencies.  I need all
>> libraries that are linked in.  I am missing the ones that are linked in
>> transitively.  Modified code is, ignoring J. Decker's suggestion about
>> using generator expressions to get the path to the target's output.
>>
>> get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
>> foreach(lib ${libs})
>>   if(TARGET ${lib})
>>     # If this is a library, get its transitive dependencies
>>     get_property(trans TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
>>     foreach(tran ${trans})
>>       if(TARGET ${tran})
>>         get_property(path TARGET ${tran} PROPERTY LOCATION)
>>         file(APPEND "${CMAKE_BINARY_DIR/libs.txt" "${path}\n")
>>       endif()
>>     endforeach()
>>     get_property(path TARGET ${lib} PROPERTY LOCATION)
>>     file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${path}\n")
>>   else()
>>     file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${lib}\n")
>>   endif()
>> endforeach()
>>
>> I am using cmake 2.8.11.2, perhaps this property doesn't do what I
>> thought it would with this version of cmake?
>>
>> Thanks,
>>
>> Tom
>>
>> On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky <
>> tom.kacvinsky at vectorcast.com> wrote:
>>
>>> I have need for a cross platform methods of getting libraries linked
>>> into an executable.
>>>
>>> Say for instance, we have
>>>
>>> add_library(foo STATIC a.c)
>>> add_exceutable(bar b.c)
>>> target_link_libraries(bar foo)
>>>
>>> So I know for that bar has a dependency on foo.lib (on Windows) and
>>> libfoo.a on Linux.
>>>
>>> And so forth.  What I would like to do is after everything is set up,
>>> query the properties of bar
>>> and find the list of libraries linked into bar in such a fashion I get
>>> that platform's specific library name (instead of the library's target
>>> name).
>>>
>>> IS this possible?  I read the docs and didn't see a property for
>>> getting this list.  Did I miss something?  If so I plan on using
>>> either get_property of get_target_property.
>>>
>>> Thanks.
>>>
>>
>>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160125/ac194a8a/attachment.html>

From cedric.doucet at inria.fr  Mon Jan 25 05:22:05 2016
From: cedric.doucet at inria.fr (Cedric Doucet)
Date: Mon, 25 Jan 2016 11:22:05 +0100 (CET)
Subject: [CMake] Library target names and the ExternalProject_Add command
Message-ID: <1163968331.12371359.1453717325370.JavaMail.zimbra@inria.fr>


Hello,

I use the ExternalProject_Add command to download and build a static library called 'foo.a'.
I build another library 'bar' which depends on 'foo.a'.

For the moment, I use the target_link_libraries command to create a link between foo and bar:

    target_link_libraries(bar ${FOO_INSTALL_DIR}/lib/foo.a)
However, this approach is not portable, especially if I want foo to be a shared library.
Indeed, the extension of such libraries is plateform dependent.

Therefore, I tried to replace the path to foo by its name 'foo' from the call to the ExternalProject_Add command:

    target_link_libraries(bar foo)
However, it does not work and I get the following error message:

    Target "foo" of type UTILITY 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.

I guess I understand that foo has the wrong type UTILITY and it would work only if I had defined my target like this:
  
    add_library(foo blablabla)

However, I need to use the ExternalProject_Add command.

Is there a way to create a library target name 'foo' in this case?

Thank you!

C?dric

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

From tamas.kenez at gmail.com  Mon Jan 25 06:02:44 2016
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Mon, 25 Jan 2016 12:02:44 +0100
Subject: [CMake] Shared library for a executable
In-Reply-To: <56A5E95D.1090305@gmail.com>
References: <56A11A34.1040005@gmail.com>
 <CAH8UK3UEzOBjcNTckN1pduaCo-=Mcnv0G=o-ECm9q6aFQ26veg@mail.gmail.com>
 <56A5E95D.1090305@gmail.com>
Message-ID: <CAPB8=n8RQn2oSsye-iLdqyTNNmR5pZJsdzm0RjA1-45twodxiw@mail.gmail.com>

Gonzalo, Ray,

I think your approaches are not in accordance with some CMake best
practices (or at least what I believe they are).

Please take a look at Ray's example after a heavy refactor:
https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe

These are the things I changed:

- In your test executables don't compile the source files of the
library-under-test into your test. Instead, link to the library. Reason (1)
ODR, (2) this way you'll test the linking operation, too.
- Don't reach out from a subdirectory ('B') to include a sibling ('A'). It
creates harmful coupling between the subdirectories. All information that
'B' needs to know about 'A' should be concentrated in the properties of the
target 'A'. So you need to use commands like target_include_directories().
- Unnecessary verbosity makes it harder to read and debug the CMakeLists.

With my changes:

- you can build and test 'A' standalone
- you can build and test 'A', 'B' and 'X' in one project using the
top-level CMakeLists.txt
- you can't build 'B' standalone or can't build 'X' without 'A' and 'B'
being there. If you need that feature, we need to add an install step to
'A' and 'B' and use find_package() in 'B' and 'X' on demand

Tamas



On Mon, Jan 25, 2016 at 10:22 AM, Gonzalo <ggarra13 at gmail.com> wrote:

>
>
> El 22/01/16 a las 10:50, Raymond Wan escribi?:
>
>> Hi Gonzalo,
>>
>> I recently tried doing this and wrote it up as a record for myself.
>> Of course, I don't know if it's the right way, but I'm doing it this
>> way until I figure out a better way...
>>
>> See if this helps and let me know if you figure out something better:
>>
>> http://www.rwanwork.info/sysdocs/cmake/overview/
>>
>> Ray
>>
> Thanks, Ray.  Your approach is exactly the same as mine.  We already found
> out that the problem I was having with v3.4.2 is a bug in cmake, which has
> been fixed in the git repository.
>
> --
> Gonzalo Garramu?o
> ggarra13 at gmail.com
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160125/d5e02c12/attachment-0001.html>

From tom.kacvinsky at vectorcast.com  Mon Jan 25 09:33:52 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Mon, 25 Jan 2016 09:33:52 -0500
Subject: [CMake] PROPERTY for list of link libraries
In-Reply-To: <CAPB8=n_40Yo-XkT3Hok8nbghE9Kz5rt6xxXR1q3P=qt-958a9w@mail.gmail.com>
References: <CAAEKttwYtWSh-=W7iWgPjVXOa+ZMv1XERx-rnB+8Us-DCGALZg@mail.gmail.com>
 <CAAEKttwvpemAd+pEbCZQQCYoh2fgR12O2NENJBvdmcOehLtLhw@mail.gmail.com>
 <CAAEKttyYnTZB72MdcK+MOJqCV=KwQCqmyy1g1iHz0gQCeyB1tg@mail.gmail.com>
 <CAPB8=n_40Yo-XkT3Hok8nbghE9Kz5rt6xxXR1q3P=qt-958a9w@mail.gmail.com>
Message-ID: <CAAEKttwfFLgkw6MFNjL_Mr2-n8DZR-1tooYVFX7UbM3+2i8U_Q@mail.gmail.com>

Thanks.  Upgrading cmake right now is problematic.

On Mon, Jan 25, 2016 at 4:33 AM, Tam?s Ken?z <tamas.kenez at gmail.com> wrote:

> I think you need something like CMakeExpandImportedTargets.cmake (
> https://cmake.org/cmake/help/latest/module/CMakeExpandImportedTargets.html).
> But that module has been deprecated for a while and does not support some
> newer CMake features.
>
> Instead, feel free to try out my fork:
> https://gist.github.com/tamaskenez/ef98237fff654c6d28b5 . This fork adds
> support for IMPORTED_IMPLIB, INTERFACE_LINK_LIBRARIES and $<CONFIG:>
> expressions.
>
> It recursively resolves all dependencies for the given configuration
> (Debug, Release, ...)
>
> Tamas
>
>
> On Fri, Jan 22, 2016 at 11:01 PM, Tom Kacvinsky <
> tom.kacvinsky at vectorcast.com> wrote:
>
>> Ah yes, that was it.  Switching to 3.3.2 did the trick.  Time to upgrade
>> cmake.
>>
>> On Fri, Jan 22, 2016 at 4:40 PM, Tom Kacvinsky <
>> tom.kacvinsky at vectorcast.com> wrote:
>>
>>> I am now having a problem with transitive dependencies.  I need all
>>> libraries that are linked in.  I am missing the ones that are linked in
>>> transitively.  Modified code is, ignoring J. Decker's suggestion about
>>> using generator expressions to get the path to the target's output.
>>>
>>> get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
>>> foreach(lib ${libs})
>>>   if(TARGET ${lib})
>>>     # If this is a library, get its transitive dependencies
>>>     get_property(trans TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
>>>     foreach(tran ${trans})
>>>       if(TARGET ${tran})
>>>         get_property(path TARGET ${tran} PROPERTY LOCATION)
>>>         file(APPEND "${CMAKE_BINARY_DIR/libs.txt" "${path}\n")
>>>       endif()
>>>     endforeach()
>>>     get_property(path TARGET ${lib} PROPERTY LOCATION)
>>>     file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${path}\n")
>>>   else()
>>>     file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${lib}\n")
>>>   endif()
>>> endforeach()
>>>
>>> I am using cmake 2.8.11.2, perhaps this property doesn't do what I
>>> thought it would with this version of cmake?
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>> On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky <
>>> tom.kacvinsky at vectorcast.com> wrote:
>>>
>>>> I have need for a cross platform methods of getting libraries linked
>>>> into an executable.
>>>>
>>>> Say for instance, we have
>>>>
>>>> add_library(foo STATIC a.c)
>>>> add_exceutable(bar b.c)
>>>> target_link_libraries(bar foo)
>>>>
>>>> So I know for that bar has a dependency on foo.lib (on Windows) and
>>>> libfoo.a on Linux.
>>>>
>>>> And so forth.  What I would like to do is after everything is set up,
>>>> query the properties of bar
>>>> and find the list of libraries linked into bar in such a fashion I get
>>>> that platform's specific library name (instead of the library's target
>>>> name).
>>>>
>>>> IS this possible?  I read the docs and didn't see a property for
>>>> getting this list.  Did I miss something?  If so I plan on using
>>>> either get_property of get_target_property.
>>>>
>>>> Thanks.
>>>>
>>>
>>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160125/5925c396/attachment.html>

From vania.joloboff at inria.fr  Mon Jan 25 09:34:11 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Mon, 25 Jan 2016 15:34:11 +0100
Subject: [CMake] add_library object argument question
Message-ID: <56A63263.9090006@inria.fr>

Hi

In a library project there are two level of subdirectories that contain 
modules
to be included into the main library.
In other words, directory lib contains subdirectories foo and bar
Subdirectory foo contains A and B.
Subdirectory bar contains C and D.
All of the objects from A, B, C and D must belong to the library

I understand I can use at the bottom levels A, B, C, D
  add_library() with the OBJECT argument
and I should be able to use add_library() in the top directory
to collect all of the object files from the subdirectories

add_library(... $<TARGET_OBJECTS:some_name> ...)

for each of the sub directories. But the documentation is unclear
about the naming schema to use. What is the syntax/meaning of some_name ?

add_library(... $<TARGET_OBJECTS:foo/A> $<TARGET_OBJECTS:foo/B> 
$<TARGET_OBJECTS:bar/C> $<TARGET_OBJECTS:bar/D> ...)

Or I need to gather at level foo and bar the objects from bottom layer
and recursively make them go up one level by one level ?

Thanks

From petr.kmoch at gmail.com  Mon Jan 25 09:56:24 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 25 Jan 2016 15:56:24 +0100
Subject: [CMake] add_library object argument question
In-Reply-To: <56A63263.9090006@inria.fr>
References: <56A63263.9090006@inria.fr>
Message-ID: <CAKohaZe1BjJD2TOYuvj=YfDHRL3Y139LS5=iJrkVhW-a=joavg@mail.gmail.com>

Hi,

the name given after the : in the TARGET_OBJECTS generator expression is
the logical (CMake) name of a target. There's no scoping in target names,
they're all at the same global scope. So if you have this:

add_library(A OBJECT ...)

then you will access its objects like this:

add_library(... $<TARGET_OBJECTS:A> ...)

regardless of whether this happens in the same CMakeList or an entirely
different one (parent, child, sibling, it makes not difference).

Which also means there's no need for progressively going up levels: just
use all the A, B, C, D directly in the toplevel add_library call.

Petr

On Mon, Jan 25, 2016 at 3:34 PM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> Hi
>
> In a library project there are two level of subdirectories that contain
> modules
> to be included into the main library.
> In other words, directory lib contains subdirectories foo and bar
> Subdirectory foo contains A and B.
> Subdirectory bar contains C and D.
> All of the objects from A, B, C and D must belong to the library
>
> I understand I can use at the bottom levels A, B, C, D
>  add_library() with the OBJECT argument
> and I should be able to use add_library() in the top directory
> to collect all of the object files from the subdirectories
>
> add_library(... $<TARGET_OBJECTS:some_name> ...)
>
> for each of the sub directories. But the documentation is unclear
> about the naming schema to use. What is the syntax/meaning of some_name ?
>
> add_library(... $<TARGET_OBJECTS:foo/A> $<TARGET_OBJECTS:foo/B>
> $<TARGET_OBJECTS:bar/C> $<TARGET_OBJECTS:bar/D> ...)
>
> Or I need to gather at level foo and bar the objects from bottom layer
> and recursively make them go up one level by one level ?
>
> Thanks
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160125/d29a2752/attachment.html>

From tom.kacvinsky at vectorcast.com  Mon Jan 25 11:24:26 2016
From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky)
Date: Mon, 25 Jan 2016 11:24:26 -0500
Subject: [CMake] making a custom target like add_library()
Message-ID: <CAAEKttwpc7pU=wbngr1+P0cLKdHmeO8hsfTn5Des5xt67tUKmw@mail.gmail.com>

I create a DLL and import library via custom commands, but for my purposes
right now, I need these libraries to be treated as if they were generated
with add_library() (for the project I am workingon where I get transitive
dependencies);

I read this

http://stackoverflow.com/questions/31274577/custom-target-as-a-target-library-in-cmake

but I am not sure if this will invoke the MS linker tools and wreal havoc
with the specialized build of the DLL.  Also, this is for a DLL, not a
static archive, so in the line

add_library(lib2 STATIC IMPORTED GLOBAL)

would I change STATIC to SHARED?

Thanks,

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

From robert.maynard at kitware.com  Mon Jan 25 14:36:34 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 25 Jan 2016 14:36:34 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.4.3 available for download
Message-ID: <CAFzjYVpcSNeBMsmawZBqOFsb1FiUVbrwCeBkrQ9manO-rsL1qg@mail.gmail.com>

We are pleased to announce that CMake 3.4.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.4.3 since 3.4.2:

Brad King (2):
    VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)
    CMake 3.4.3

From ggarra13 at gmail.com  Mon Jan 25 16:12:12 2016
From: ggarra13 at gmail.com (=?ISO-8859-1?Q?Gonzalo_Garramu=F1o?=)
Date: Mon, 25 Jan 2016 18:12:12 -0300
Subject: [CMake] [ANNOUNCE] CMake 3.4.3 available for download
In-Reply-To: <CAFzjYVpcSNeBMsmawZBqOFsb1FiUVbrwCeBkrQ9manO-rsL1qg@mail.gmail.com>
References: <CAFzjYVpcSNeBMsmawZBqOFsb1FiUVbrwCeBkrQ9manO-rsL1qg@mail.gmail.com>
Message-ID: <56A68FAC.6030504@gmail.com>

On 25/01/2016 04:36 p.m., Robert Maynard wrote:
> We are pleased to announce that CMake 3.4.3 is now available for download.
>
> Please use the latest release from our download page:
>    https://cmake.org/download/

Brad,

Does this one have the fix for the FLTK_WRAP_UI?


From nicholas11braden at gmail.com  Mon Jan 25 20:13:26 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Mon, 25 Jan 2016 19:13:26 -0600
Subject: [CMake] Library target names and the ExternalProject_Add command
In-Reply-To: <1163968331.12371359.1453717325370.JavaMail.zimbra@inria.fr>
References: <1163968331.12371359.1453717325370.JavaMail.zimbra@inria.fr>
Message-ID: <CAHk1PgG1+C8g3iyEr06rmOcuinnaA7oTtK+mCQGvgqwT=0_wfA@mail.gmail.com>

ExternalProject makes no assumptions about what is being built. It
could just be a collection of executables, or maybe nothing is built
at all. It is up to the project being built to provide facilities for
accessing its targets in a platform-independent way. For example, the
external project can install an export file that you can include to
get the imported targets. Or, it could have a traditional
FindXXX.cmake script that you can use. Either way, ExternalProject
doesn't know about any of that - it just downloads and builds stuff.

Alternatively, you could include the external library as part of your
project and use add_subdirectory to just build it with the rest of
your project, thus giving you direct access to the targets you want.

On Mon, Jan 25, 2016 at 4:22 AM, Cedric Doucet <cedric.doucet at inria.fr> wrote:
>
> Hello,
>
> I use the ExternalProject_Add command to download and build a static library
> called 'foo.a'.
> I build another library 'bar' which depends on 'foo.a'.
>
> For the moment, I use the target_link_libraries command to create a link
> between foo and bar:
>
>     target_link_libraries(bar ${FOO_INSTALL_DIR}/lib/foo.a)
>
> However, this approach is not portable, especially if I want foo to be a
> shared library.
> Indeed, the extension of such libraries is plateform dependent.
>
> Therefore, I tried to replace the path to foo by its name 'foo' from the
> call to the ExternalProject_Add command:
>
>     target_link_libraries(bar foo)
>
> However, it does not work and I get the following error message:
>
>     Target "foo" of type UTILITY 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.
>
> I guess I understand that foo has the wrong type UTILITY and it would work
> only if I had defined my target like this:
>
>     add_library(foo blablabla)
>
> However, I need to use the ExternalProject_Add command.
>
> Is there a way to create a library target name 'foo' in this case?
>
> Thank you!
>
> 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 rwan.work at gmail.com  Mon Jan 25 22:48:09 2016
From: rwan.work at gmail.com (Raymond Wan)
Date: Tue, 26 Jan 2016 11:48:09 +0800
Subject: [CMake] Shared library for a executable
In-Reply-To: <CAPB8=n8RQn2oSsye-iLdqyTNNmR5pZJsdzm0RjA1-45twodxiw@mail.gmail.com>
References: <56A11A34.1040005@gmail.com>
 <CAH8UK3UEzOBjcNTckN1pduaCo-=Mcnv0G=o-ECm9q6aFQ26veg@mail.gmail.com>
 <56A5E95D.1090305@gmail.com>
 <CAPB8=n8RQn2oSsye-iLdqyTNNmR5pZJsdzm0RjA1-45twodxiw@mail.gmail.com>
Message-ID: <CAH8UK3WEPGWF=p4+u6MEqTBe=qPBGsvaS+nmafcgAjLCSB=Rpw@mail.gmail.com>

Hi Tam?s,


On Mon, Jan 25, 2016 at 7:02 PM, Tam?s Ken?z <tamas.kenez at gmail.com> wrote:
> Gonzalo, Ray,
>
> I think your approaches are not in accordance with some CMake best practices
> (or at least what I believe they are).


Thank you for looking over my web site!  I welcome comments since I am
learning as I go along and I also don't know what "CMake best
practices" are.  There seems to be a lot of flexibility and a lot of
ways to get things wrong.


> Please take a look at Ray's example after a heavy refactor:
> https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe


Thanks for refactoring it!  I just realized I probably should have put
my example on GitHub.  Perhaps I'll do it instead of having just a
tar.gz file.


> These are the things I changed:
>
> - In your test executables don't compile the source files of the
> library-under-test into your test. Instead, link to the library. Reason (1)
> ODR, (2) this way you'll test the linking operation, too.


That's an excellent point!  Thanks!


> - Don't reach out from a subdirectory ('B') to include a sibling ('A'). It
> creates harmful coupling between the subdirectories. All information that
> 'B' needs to know about 'A' should be concentrated in the properties of the
> target 'A'. So you need to use commands like target_include_directories().
> - Unnecessary verbosity makes it harder to read and debug the CMakeLists.


The verbosity was a bit on purpose.  To help others follow the example
and to help me follow months after I look at it!  But, another reason
is that I have many CMakeLists.txt that are very similar.  And the
only part that is different are the filenames.  So, I do copy and
paste my CMakeLists.txt and change just all the filenames in one
place.

Perhaps it is hard to read and debug, but when almost all of my
CMakeLists.txt are the same, then it is actually a bit easier.


> - you can build and test 'A' standalone
> - you can build and test 'A', 'B' and 'X' in one project using the top-level
> CMakeLists.txt
> - you can't build 'B' standalone or can't build 'X' without 'A' and 'B'
> being there. If you need that feature, we need to add an install step to 'A'
> and 'B' and use find_package() in 'B' and 'X' on demand


Hmmmmm, I see.

However, the last point isn't what I was trying to achieve.  And I
mentioned it on the "Summary" page.

I was playing with this for a long time and did try what you suggest
above.  But, in one project, I had tree-like dependencies that
stretched for more than two levels.  (i.e., it wasn't just X needed A,
X needed B, X needed C, etc.).  So, I could have installed them into
the system, but I only needed it to compile X and cluttering a user's
system with libraries didn't seem like a good idea.

BUT, I now see a way around it.  I suppose I can install them into an
install path within the build tree.  And apply find_package () to just
within the build tree.

That would satisfy all of these criteria:

1)  A and B are independent,
2)  B can be built stand-alone,
3)  A and B are installed within the build tree,
4)  A and B are to be found with find_package (), and
5)  Only X is installed in the system-level directory (since that is
the only program that a user should run).

I think this sounds fine...  I will give it a try.  Thank you for your comments!

Ray

From rwan.work at gmail.com  Mon Jan 25 22:49:08 2016
From: rwan.work at gmail.com (Raymond Wan)
Date: Tue, 26 Jan 2016 11:49:08 +0800
Subject: [CMake] Shared library for a executable
In-Reply-To: <56A5E95D.1090305@gmail.com>
References: <56A11A34.1040005@gmail.com>
 <CAH8UK3UEzOBjcNTckN1pduaCo-=Mcnv0G=o-ECm9q6aFQ26veg@mail.gmail.com>
 <56A5E95D.1090305@gmail.com>
Message-ID: <CAH8UK3VhDzPTiKPZLRj+-iGTPONrD3U0v_0ARYnP3ZkHXR9+Cg@mail.gmail.com>

Hi Gonzalo,


On Mon, Jan 25, 2016 at 5:22 PM, Gonzalo <ggarra13 at gmail.com> wrote:
>
>
> El 22/01/16 a las 10:50, Raymond Wan escribi?:
>>
>> Hi Gonzalo,
>>
>> I recently tried doing this and wrote it up as a record for myself.
>> Of course, I don't know if it's the right way, but I'm doing it this
>> way until I figure out a better way...
>>
>> See if this helps and let me know if you figure out something better:
>>
>> http://www.rwanwork.info/sysdocs/cmake/overview/
>>
>> Ray
>
> Thanks, Ray.  Your approach is exactly the same as mine.  We already found
> out that the problem I was having with v3.4.2 is a bug in cmake, which has
> been fixed in the git repository.


You're welcome!  I wasn't following the discussion about the v3.4.2
bug so I didn't realize that was the cause.

Nevertheless, I'm glad it helped and I'll be sure to skip v3.4.2 -- thank you!

Ray

From luqiuwen at gmail.com  Tue Jan 26 00:35:01 2016
From: luqiuwen at gmail.com (=?UTF-8?B?6ZmG56eL5paH?=)
Date: Tue, 26 Jan 2016 13:35:01 +0800
Subject: [CMake]  How to override CMAKE_C_IMPLICIT_LINK_LIBRARIES
Message-ID: <CAH1gxTudrZXwZNg_GiaXoDhO7u6bG8ZVyGJ9Cpaj+s8y=P852A@mail.gmail.com>

I have the need to link a shared library to all the targets without
modifying the CMakeLists.txt(for example, tcmalloc.so). I used the command:

# cmake -DCMAKE_C_IMPLICIT_LINK_LIBRARIES:STRING=tcmalloc

However, It didn't work. I used the message() command to print the
CMAKE_C_IMPLICIT_LINK_LIBRARIES, It show:

-- CMAKE_C_IMPLICIT_LINK_LIBRARIES=c

Can someone point me why this happens? Thanks very much!

Qiuwen Lu
luqiuwen at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160126/fcb55631/attachment.html>

From nilsgladitz at gmail.com  Tue Jan 26 02:46:08 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Tue, 26 Jan 2016 08:46:08 +0100
Subject: [CMake] How to override CMAKE_C_IMPLICIT_LINK_LIBRARIES
In-Reply-To: <CAH1gxTudrZXwZNg_GiaXoDhO7u6bG8ZVyGJ9Cpaj+s8y=P852A@mail.gmail.com>
References: <CAH1gxTudrZXwZNg_GiaXoDhO7u6bG8ZVyGJ9Cpaj+s8y=P852A@mail.gmail.com>
Message-ID: <56A72440.4040305@gmail.com>

On 01/26/2016 06:35 AM, ??? wrote:
> I have the need to link a shared library to all the targets without 
> modifying the CMakeLists.txt(for example, tcmalloc.so). I used the 
> command:
>
> # cmake -DCMAKE_C_IMPLICIT_LINK_LIBRARIES:STRING=tcmalloc
>
> However, It didn't work. I used the message() command to print the 
> CMAKE_C_IMPLICIT_LINK_LIBRARIES, It show:
>
> -- CMAKE_C_IMPLICIT_LINK_LIBRARIES=c
>
> Can someone point me why this happens? Thanks very much!

Implicit link libraries are those that the compiler (not CMake) itself 
implicitly links.
They are detected by CMake and stored in the variable; the variable is 
not meant to be modified.

I can't think of any way to portably link libraries without modifying 
the project.
(There are linker flag variables e.g. CMAKE_EXE_LINKER_FLAGS but they 
are inserted before object files on the command line which will not work 
for many toolsets)

link_libraries() [1] might have the smallest impact if you do end up 
having to modify the project.

Nils

[1] https://cmake.org/cmake/help/v3.4/command/link_libraries.html

From guy at alum.mit.edu  Tue Jan 26 03:12:11 2016
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 26 Jan 2016 00:12:11 -0800
Subject: [CMake] Checking whether particular *linker* flags are supported
In-Reply-To: <90E95A04-BA47-4BF6-930B-E54614516BE8@alum.mit.edu>
References: <90E95A04-BA47-4BF6-930B-E54614516BE8@alum.mit.edu>
Message-ID: <965FA58B-1141-4C42-B2A2-1D6ACD64A2FB@alum.mit.edu>

On Jan 22, 2016, at 12:24 PM, Guy Harris <guy at alum.mit.edu> wrote:

> CMake has the macros CHECK_C_COMPILER_FLAG and CHECK_CXX_COMPILER_FLAG, which allow checking for whether a given C or C++ compiler flag is supported by the compiler being used.
> 
> However, there's no CHECK_LINKER_FLAG macro, so that you can check whether a given *linker* flag is supported by the linker being used, so there doesn't seem to be a good way to use a flag, such as the --as-needed flag, if it's not *required*, but is "nice to have", but isn't available on all platforms.
> 
> So what's the best way to do such a check?
> 
> (I'm assuming here that, for all generators on UN*X platforms, linking is done by using the compiler driver, so that you don't have to worry about, for example, using -Wl,{linker flag} with some generators and just {linker flag} with other generators.)

Bug 0015934:

	https://public.kitware.com/Bug/view.php?id=15934

filed.



From vania.joloboff at inria.fr  Tue Jan 26 03:36:09 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Tue, 26 Jan 2016 09:36:09 +0100
Subject: [CMake] errors with add_custom_command and add_custom_target
Message-ID: <56A72FF9.7040609@inria.fr>

Hi

I have a generator that generates some, but not all of the source files.
My understanding was that I should use add_custom_command for that

When I do
set(EXIST_SOURCES A.cc B.cc C.cc)
set(GEN_SOURCES X.cc Y.cc Z.cc)
add_custom_command(OUTPUT ${GEN_SOURCES}
                        COMMAND generator
                        MAIN_DEPENDENCY gendir/generator   )
set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )

I get error "Cannot find source file : X.cc"

So, I tried

set(EXIST_SOURCES A.cc B.cc C.cc)
set(GEN_SOURCES X.cc Y.cc Z.cc)
add_custom_target(generate
               COMMAND generator
               COMMENT "Generate"
               DEPENDS gendir/generator   )
set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
add_dependencies(mylib generate)

I get same error "Cannot find source file : X.cc"

I just don't get it...

Vania


From petr.kmoch at gmail.com  Tue Jan 26 03:43:49 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 26 Jan 2016 09:43:49 +0100
Subject: [CMake] errors with add_custom_command and add_custom_target
In-Reply-To: <56A72FF9.7040609@inria.fr>
References: <56A72FF9.7040609@inria.fr>
Message-ID: <CAKohaZed=BuUhscfO1XgJHRWBwz9+LyTDfm0bKhhOAy0FwjnUA@mail.gmail.com>

Hi, Vania.

You should remove this line:

set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )

CMake will mark the files as generated automatically.

What your line is actually doing is setting them as *not* generated,
because you didn't pass any argument to set the property to, so it's
implicitly unset. What you probably wanted would have been this:

set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED TRUE)

But again, remove the line altogether, it's unnecessary.

You should also remove the quotes from your `add_library` call. The way you
have it would look for a single file named "A.cc;B.cc;C.cc X.cc;Y.cc;Z.cc".

Petr

On Tue, Jan 26, 2016 at 9:36 AM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> Hi
>
> I have a generator that generates some, but not all of the source files.
> My understanding was that I should use add_custom_command for that
>
> When I do
> set(EXIST_SOURCES A.cc B.cc C.cc)
> set(GEN_SOURCES X.cc Y.cc Z.cc)
> add_custom_command(OUTPUT ${GEN_SOURCES}
>                        COMMAND generator
>                        MAIN_DEPENDENCY gendir/generator   )
> set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
> add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
>
> I get error "Cannot find source file : X.cc"
>
> So, I tried
>
> set(EXIST_SOURCES A.cc B.cc C.cc)
> set(GEN_SOURCES X.cc Y.cc Z.cc)
> add_custom_target(generate
>               COMMAND generator
>               COMMENT "Generate"
>               DEPENDS gendir/generator   )
> set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
> add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
> add_dependencies(mylib generate)
>
> I get same error "Cannot find source file : X.cc"
>
> I just don't get it...
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160126/f30557c9/attachment.html>

From vania.joloboff at inria.fr  Tue Jan 26 04:07:54 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Tue, 26 Jan 2016 10:07:54 +0100
Subject: [CMake] errors with add_custom_command and add_custom_target
In-Reply-To: <CAKohaZed=BuUhscfO1XgJHRWBwz9+LyTDfm0bKhhOAy0FwjnUA@mail.gmail.com>
References: <56A72FF9.7040609@inria.fr>
 <CAKohaZed=BuUhscfO1XgJHRWBwz9+LyTDfm0bKhhOAy0FwjnUA@mail.gmail.com>
Message-ID: <56A7376A.7020202@inria.fr>

Hi Petr,

Thanks, indeed I had unset the property !
Cmake works fine with removing the line. But I have now a doubt.
My generator generates the files in the current dir.
Should I indicate the working directory in add_custom_command ?
so that the generated sources are added in CMAKE_CURRENT_SOURCE_DIR
or it will automatically add them in the source dir and not the build dir ?
Vania



On 01/26/2016 09:43 AM, Petr Kmoch wrote:
> Hi, Vania.
>
> You should remove this line:
>
> set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
>
> CMake will mark the files as generated automatically.
>
> What your line is actually doing is setting them as *not* generated, 
> because you didn't pass any argument to set the property to, so it's 
> implicitly unset. What you probably wanted would have been this:
>
> set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED TRUE)
>
> But again, remove the line altogether, it's unnecessary.
>
> You should also remove the quotes from your `add_library` call. The 
> way you have it would look for a single file named "A.cc;B.cc;C.cc 
> X.cc;Y.cc;Z.cc".
>
> Petr
>
> On Tue, Jan 26, 2016 at 9:36 AM, Vania Joloboff 
> <vania.joloboff at inria.fr <mailto:vania.joloboff at inria.fr>> wrote:
>
>     Hi
>
>     I have a generator that generates some, but not all of the source
>     files.
>     My understanding was that I should use add_custom_command for that
>
>     When I do
>     set(EXIST_SOURCES A.cc B.cc C.cc)
>     set(GEN_SOURCES X.cc Y.cc Z.cc)
>     add_custom_command(OUTPUT ${GEN_SOURCES}
>                            COMMAND generator
>                            MAIN_DEPENDENCY gendir/generator   )
>     set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
>     add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
>
>     I get error "Cannot find source file : X.cc"
>
>     So, I tried
>
>     set(EXIST_SOURCES A.cc B.cc C.cc)
>     set(GEN_SOURCES X.cc Y.cc Z.cc)
>     add_custom_target(generate
>                   COMMAND generator
>                   COMMENT "Generate"
>                   DEPENDS gendir/generator   )
>     set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
>     add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
>     add_dependencies(mylib generate)
>
>     I get same error "Cannot find source file : X.cc"
>
>     I just don't get it...
>
>     Vania
>
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     http://public.kitware.com/mailman/listinfo/cmake
>
>


From petr.kmoch at gmail.com  Tue Jan 26 04:12:01 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 26 Jan 2016 10:12:01 +0100
Subject: [CMake] errors with add_custom_command and add_custom_target
In-Reply-To: <56A7376A.7020202@inria.fr>
References: <56A72FF9.7040609@inria.fr>
 <CAKohaZed=BuUhscfO1XgJHRWBwz9+LyTDfm0bKhhOAy0FwjnUA@mail.gmail.com>
 <56A7376A.7020202@inria.fr>
Message-ID: <CAKohaZf=Aw5Z3x5oJPk9VWrPXk7SwM-tX_USz5GTC-zDwkczJg@mail.gmail.com>

Normally, you would want to keep your source tree clean from any build-time
modifications (CMake *strongly discourages* in-source builds, with good
reason).
Therefore, you'd want to generate the files in CMAKE_CURRENT_BINARY_DIR.
Assuming the generator always writes them into its current directory, you'd
do this:

set(EXIST_SOURCES A.cc B.cc C.cc)
set(GEN_SOURCES ${CMAKE_CURRENT_BINARY_DIR}/X.cc
${CMAKE_CURRENT_BINARY_DIR}/Y.cc ${CMAKE_CURRENT_BINARY_DIR}/Z.cc)
add_custom_command(OUTPUT ${GEN_SOURCES}
                       COMMAND generator
                       WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
                       MAIN_DEPENDENCY gendir/generator)
add_library(mylib OBJECT ${EXIST_SOURCES} ${GEN_SOURCES} )

Petr


On Tue, Jan 26, 2016 at 10:07 AM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> Hi Petr,
>
> Thanks, indeed I had unset the property !
> Cmake works fine with removing the line. But I have now a doubt.
> My generator generates the files in the current dir.
> Should I indicate the working directory in add_custom_command ?
> so that the generated sources are added in CMAKE_CURRENT_SOURCE_DIR
> or it will automatically add them in the source dir and not the build dir ?
> Vania
>
>
>
> On 01/26/2016 09:43 AM, Petr Kmoch wrote:
>
>> Hi, Vania.
>>
>> You should remove this line:
>>
>> set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
>>
>> CMake will mark the files as generated automatically.
>>
>> What your line is actually doing is setting them as *not* generated,
>> because you didn't pass any argument to set the property to, so it's
>> implicitly unset. What you probably wanted would have been this:
>>
>> set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED TRUE)
>>
>> But again, remove the line altogether, it's unnecessary.
>>
>> You should also remove the quotes from your `add_library` call. The way
>> you have it would look for a single file named "A.cc;B.cc;C.cc
>> X.cc;Y.cc;Z.cc".
>>
>> Petr
>>
>> On Tue, Jan 26, 2016 at 9:36 AM, Vania Joloboff <vania.joloboff at inria.fr
>> <mailto:vania.joloboff at inria.fr>> wrote:
>>
>>     Hi
>>
>>     I have a generator that generates some, but not all of the source
>>     files.
>>     My understanding was that I should use add_custom_command for that
>>
>>     When I do
>>     set(EXIST_SOURCES A.cc B.cc C.cc)
>>     set(GEN_SOURCES X.cc Y.cc Z.cc)
>>     add_custom_command(OUTPUT ${GEN_SOURCES}
>>                            COMMAND generator
>>                            MAIN_DEPENDENCY gendir/generator   )
>>     set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
>>     add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
>>
>>     I get error "Cannot find source file : X.cc"
>>
>>     So, I tried
>>
>>     set(EXIST_SOURCES A.cc B.cc C.cc)
>>     set(GEN_SOURCES X.cc Y.cc Z.cc)
>>     add_custom_target(generate
>>                   COMMAND generator
>>                   COMMENT "Generate"
>>                   DEPENDS gendir/generator   )
>>     set_property(SOURCE ${GEN_SOURCES} PROPERTY GENERATED )
>>     add_library(mylib OBJECT "${EXIST_SOURCES} ${GEN_SOURCES}" )
>>     add_dependencies(mylib generate)
>>
>>     I get same error "Cannot find source file : X.cc"
>>
>>     I just don't get it...
>>
>>     Vania
>>
>>     --
>>     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/20160126/27f90531/attachment-0001.html>

From Micha.Renner at t-online.de  Tue Jan 26 05:12:11 2016
From: Micha.Renner at t-online.de (Micha Renner)
Date: Tue, 26 Jan 2016 11:12:11 +0100
Subject: [CMake] WINDOWS_EXPORT_ALL_SYMBOLS
Message-ID: <1453803131.2976.2.camel@t-online.de>

Hallo all,

SET_TARGET_PROPERTIES(TLib PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
generates this exportall.def file

	EXPORTS 
	testCall1_1
	__local_stdio_printf_options
	_vfprintf_l
	vprintf
	printf
	_vsnprintf_l
	vsprintf

my library is this:

#include "tlib.h"
#include <stdio.h>
May be there exists an explanation.
#include <Windows.h>

void testCall1_1(const char*  fmt, ...)
{
	char buffer[10];
		 
	int c = 5;
	va_list      ap;

	printf("... in testCall-1-1\n"); 

	va_start(ap, fmt);
	vprintf(fmt, ap);
	vsprintf(buffer, fmt, ap);
	va_end(ap);

}

>From what comes:
__local_stdio_printf_options
_vfprintf_l
_vsnprintf_l

It prevents that I can link the library to a program since there is no
__local_stdio_printf_options etc.

May be there exists an explanation.

Greetings

Michael


cmake 3.4.2 Windows 10 VS Express 15
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BuildDll.zip
Type: application/zip
Size: 12394 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160126/ae9a5a2e/attachment.zip>

From brad.king at kitware.com  Tue Jan 26 08:23:21 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 26 Jan 2016 08:23:21 -0500
Subject: [CMake] CMake 3.4.3 available for download
In-Reply-To: <56A68FAC.6030504@gmail.com>
References: <CAFzjYVpcSNeBMsmawZBqOFsb1FiUVbrwCeBkrQ9manO-rsL1qg@mail.gmail.com>
 <56A68FAC.6030504@gmail.com>
Message-ID: <56A77349.8030800@kitware.com>

On 01/25/2016 04:12 PM, Gonzalo Garramu?o wrote:
> Does this one have the fix for the FLTK_WRAP_UI?

No, sorry.  3.4.3 was released only as a quick fix to 3.4.2's problems
on Windows 10.  3.5 will have the fltk fix, and the freeze for that is
next week.

-Brad


From laasunde at hotmail.com  Tue Jan 26 09:43:58 2016
From: laasunde at hotmail.com (Lars)
Date: Tue, 26 Jan 2016 15:43:58 +0100
Subject: [CMake] include_external_msproject
Message-ID: <DUB128-W4679EB698CF4508415E801CAD80@phx.gbl>

Appreciate some help understanding include_external_msproject.
Using Windows 7 and cmake 3.3  
 
This is what has been done so far,
 
1. Opened Visual Studio 2012 and created a new project (Windows Forms Application) and saved it under c:\temp\test.
 
2. Used the following to an cmake;
include_external_msproject(ext_test c:/test/test/test.sln)
 
This generates an error MSB4126: The specified solution configuration "Debug|x86" is invalid. Please specify a valid solution configuration using the configuration and platform properties...
 
3. So update the cmake file (below), clear build folder and build again;
include_external_msproject(ext_test c:/test/test/test.sln PLATFORM "Any CPU")
 
This generate the exact same error message as above. So the PLATFORM keyword does not appear to be used in this context. Anyone care to explain how PLATFORM works and howto specify correct configuration and platform?
 
4. To workaround the problem we open the visual studio project and added the configuration and platform combo "Debug" and "x86" which cmake appears to require. We use the original cmake script (below), clear build folder and build again.
include_external_msproject(ext_test c:/test/test/test.sln)
 
The following error is produced;
c:\temp\test\test\test.sln.metaproj : error MSB4057: The target "GetNativeManifest" does not exists in the project.
 
Searched all files in source and build directory and cannot find any reference to "GetNativeManifest". See some issue online in regards to build order but cannot see how that applies to this simple example. Really do not understand this issue. Any ideas?
 
6. Update cmake and use .csproj instead of the solution file and it works. The test.exe file is build. The cmake looks like this
include_external_msproject(ext_test c:/test/test/test.csproj)
 
Does include_external_msproject support solution files?
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160126/4121301c/attachment.html>

From iosif.neitzke+cmake at gmail.com  Tue Jan 26 10:24:35 2016
From: iosif.neitzke+cmake at gmail.com (iosif neitzke)
Date: Tue, 26 Jan 2016 09:24:35 -0600
Subject: [CMake] include_external_msproject
In-Reply-To: <DUB128-W4679EB698CF4508415E801CAD80@phx.gbl>
References: <DUB128-W4679EB698CF4508415E801CAD80@phx.gbl>
Message-ID: <CAGyo1oxx8_-HrMabg=zFL=+hKEKA6mxygJZWBOuK_MXfCrpd5g@mail.gmail.com>

No, I do not believe so.

https://cmake.org/cmake/help/v3.4/command/include_external_msproject.html

Keyword being 'project'.

On Tue, Jan 26, 2016 at 8:43 AM, Lars <laasunde at hotmail.com> wrote:
> Appreciate some help understanding include_external_msproject.
> Using Windows 7 and cmake 3.3
>
> This is what has been done so far,
>
> 1. Opened Visual Studio 2012 and created a new project (Windows Forms
> Application) and saved it under c:\temp\test.
>
> 2. Used the following to an cmake;
> include_external_msproject(ext_test c:/test/test/test.sln)
>
> This generates an error MSB4126: The specified solution configuration
> "Debug|x86" is invalid. Please specify a valid solution configuration using
> the configuration and platform properties...
>
> 3. So update the cmake file (below), clear build folder and build again;
> include_external_msproject(ext_test c:/test/test/test.sln PLATFORM "Any
> CPU")
>
> This generate the exact same error message as above. So the PLATFORM keyword
> does not appear to be used in this context. Anyone care to explain how
> PLATFORM works and howto specify correct configuration and platform?
>
> 4. To workaround the problem we open the visual studio project and added the
> configuration and platform combo "Debug" and "x86" which cmake appears to
> require. We use the original cmake script (below), clear build folder and
> build again.
> include_external_msproject(ext_test c:/test/test/test.sln)
>
> The following error is produced;
> c:\temp\test\test\test.sln.metaproj : error MSB4057: The target
> "GetNativeManifest" does not exists in the project.
>
> Searched all files in source and build directory and cannot find any
> reference to "GetNativeManifest". See some issue online in regards to build
> order but cannot see how that applies to this simple example. Really do not
> understand this issue. Any ideas?
>
> 6. Update cmake and use .csproj instead of the solution file and it works.
> The test.exe file is build. The cmake looks like this
> include_external_msproject(ext_test c:/test/test/test.csproj)
>
> Does include_external_msproject support solution files?
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 bill.hoffman at kitware.com  Tue Jan 26 12:51:57 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 26 Jan 2016 12:51:57 -0500
Subject: [CMake] WINDOWS_EXPORT_ALL_SYMBOLS
In-Reply-To: <1453803131.2976.2.camel@t-online.de>
References: <1453803131.2976.2.camel@t-online.de>
Message-ID: <56A7B23D.8010902@kitware.com>

On 1/26/2016 5:12 AM, Micha Renner wrote:
> It prevents that I can link the library to a program since there is no
> __local_stdio_printf_options etc.
>
> May be there exists an explanation.
>
> Greetings
>
> Michael
>
>
> cmake 3.4.2 Windows 10 VS Express 15
So, I am able to get this to work with Visual Studio 14 2015.  CMake 3.4.3

$ cat TLib.dir/Debug/exportall.def
EXPORTS
         testCall1_1
         __local_stdio_printf_options
         _vfprintf_l
         vprintf
         printf
         _vsnprintf_l
         vsprintf

Those symbols show up in the .def file but get resolved by system libraries.

Here is my link line:
(output from cmake --build .)

Link:
   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe 
/ERRORREPORT:QUEUE 
/OUT:"C:\Users\hoffman\Documents\BuildDll\BuildDLL-44\src\b\Debug\TLib.dll" 
/INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib 
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib 
/DEF:"TLib.dir\Debug\exportall.def" /MANIFEST 
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG 
/PDB:"C:/Users/hoffman/Documents/BuildDll/BuildDLL-44/src/b/Debug/TLib.pdb" 
/SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT 
/IMPLIB:"C:/Users/hoffman/Documents/BuildDll/BuildDLL-44/src/b/Debug/TLib.lib" 
/MACHINE:X86 /SAFESEH  /machine:X86 /debug /DLL TLib.dir\Debug\tlib.obj

You can see I get the dll and .lib file here:
$ ls Debug/
TLib.dll  TLib.exp  TLib.ilk  TLib.lib  TLib.pdb

I am running the community edition...  Maybe there is some difference 
with express?

-Bill



From Matthew.Johnson1 at med.ge.com  Tue Jan 26 15:25:55 2016
From: Matthew.Johnson1 at med.ge.com (Johnson, Matt (GE Healthcare))
Date: Tue, 26 Jan 2016 20:25:55 +0000
Subject: [CMake] Importing a static library,
 then adding dependencies. Should the dependencies be transitive?
 They aren't for me!
Message-ID: <BE73B6714FF4E843992984FDF5B6EA0227458F96@CINURCNA05.e2k.ad.ge.com>

I'm using the Visual Studio 2013 generator and cmake 3.4.3.
Example:
add_library(NS::a_lib STATIC IMPORTED)
set_target_properties(NS::a_lib PROPERTIES IMPORTED_LOCATION ${a_lib_location})
set_target_properties(NS::a_lib PROPERTIES INTERFACE_LINK_LIBRARIES "/path/to/a/another_lib.lib")
set_target_properties(NS::a_lib PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "an/include/dir")

add_library(NS::b_lib STATIC IMPORTED)
set_target_properties(NS::b_lib PROPERTIES IMPORTED_LOCATION ${b_lib_location})
add_dependencies(NS::b_lib NS::a_lib)

add_executable(test_exe main.cpp)
target_link_libraries(test_exe NS::b_lib) #I expect to pull in all of A's stuff too.  Howver, it doesn't for me.

Assume I have two libraries, A and B.  A has some libraries that it links to.  B depends on A.  I add import targets for both A and B.  I use add_dependencies to signal the B->A dependency.  When I use target_link_libraries for an executable and only list B, should it auto pull in A and A's dependencies?  For me, all I get is B.  I don't get any of its dependencies.  Nor do I get A's include directories.  Am I doing something wrong or misunderstanding the usage of these functions?

I've done a lot of googling and searching the mailing list.  I do see a couple of bugs that revolved around this, but all of them seem to indicate that they are fixed and this is supported.  Am I wrong?  Do I have to manually set the INTERFACE_LINK_LIBRARIES of B?

Thanks for your help!
Matt
  

From nilsgladitz at gmail.com  Tue Jan 26 16:23:33 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Tue, 26 Jan 2016 22:23:33 +0100
Subject: [CMake] Importing a static library,
 then adding dependencies. Should the dependencies be transitive?
 They aren't for me!
In-Reply-To: <BE73B6714FF4E843992984FDF5B6EA0227458F96@CINURCNA05.e2k.ad.ge.com>
References: <BE73B6714FF4E843992984FDF5B6EA0227458F96@CINURCNA05.e2k.ad.ge.com>
Message-ID: <56A7E3D5.3050901@gmail.com>

On 26.01.2016 21:25, Johnson, Matt (GE Healthcare) wrote:
> I'm using the Visual Studio 2013 generator and cmake 3.4.3.
> Example:
> add_library(NS::a_lib STATIC IMPORTED)
> set_target_properties(NS::a_lib PROPERTIES IMPORTED_LOCATION ${a_lib_location})
> set_target_properties(NS::a_lib PROPERTIES INTERFACE_LINK_LIBRARIES "/path/to/a/another_lib.lib")
> set_target_properties(NS::a_lib PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "an/include/dir")
>
> add_library(NS::b_lib STATIC IMPORTED)
> set_target_properties(NS::b_lib PROPERTIES IMPORTED_LOCATION ${b_lib_location})
> add_dependencies(NS::b_lib NS::a_lib)
>
> add_executable(test_exe main.cpp)
> target_link_libraries(test_exe NS::b_lib) #I expect to pull in all of A's stuff too.  Howver, it doesn't for me.
>
> Assume I have two libraries, A and B.  A has some libraries that it links to.  B depends on A.  I add import targets for both A and B.  I use add_dependencies to signal the B->A dependency.  When I use target_link_libraries for an executable and only list B, should it auto pull in A and A's dependencies?  For me, all I get is B.  I don't get any of its dependencies.  Nor do I get A's include directories.  Am I doing something wrong or misunderstanding the usage of these functions?
>
> I've done a lot of googling and searching the mailing list.  I do see a couple of bugs that revolved around this, but all of them seem to indicate that they are fixed and this is supported.  Am I wrong?  Do I have to manually set the INTERFACE_LINK_LIBRARIES of B?

Yes you have to set INTERFACE_LINK_LIBRARIES.
add_dependencies() is for order (not link) dependencies.

Nils


From Matthew.Johnson1 at med.ge.com  Tue Jan 26 21:54:08 2016
From: Matthew.Johnson1 at med.ge.com (Johnson, Matt (GE Healthcare))
Date: Wed, 27 Jan 2016 02:54:08 +0000
Subject: [CMake] What is the best way to handle Boost dependencies in a
 package config file
Message-ID: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>

I like package config files.  I want to use more of them.  However, I have a dependency on boost.  While boost has a Find module, it doesn't have a package config file.  I'm not going to be able to depend on the users of my package building boost via cmake (also, is that still an active thing?).

It seems like the best I could hope for is to generate the package config file, then hack it up to deal with the boost stuff.  Has anyone already solved this problem or have any tips?  I found this Hunter package manager (https://github.com/ruslo/hunter), but it seems a bit heavyweight when all I want is boost.  Also, I can't have my build system going out and downloading the packages - they all have to come from an internal source.  

Thanks,
Matt



From michi.henning at canonical.com  Wed Jan 27 01:54:41 2016
From: michi.henning at canonical.com (Michi Henning)
Date: Wed, 27 Jan 2016 16:54:41 +1000
Subject: [CMake] What is the best way to handle Boost dependencies in a
	package config file
In-Reply-To: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
References: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
Message-ID: <3FE52583-5E48-4920-B24F-9682754EE721@canonical.com>

We use this, which works fine for me on Ubuntu:

find_package(Boost COMPONENTS system filesystem regex serialization thread log REQUIRED)

Cheers,

Michi.

> On 27 Jan 2016, at 12:54 , Johnson, Matt (GE Healthcare) <Matthew.Johnson1 at med.ge.com> wrote:
> 
> I like package config files.  I want to use more of them.  However, I have a dependency on boost.  While boost has a Find module, it doesn't have a package config file.  I'm not going to be able to depend on the users of my package building boost via cmake (also, is that still an active thing?).
> 
> It seems like the best I could hope for is to generate the package config file, then hack it up to deal with the boost stuff.  Has anyone already solved this problem or have any tips?  I found this Hunter package manager (https://github.com/ruslo/hunter), but it seems a bit heavyweight when all I want is boost.  Also, I can't have my build system going out and downloading the packages - they all have to come from an internal source.  
> 
> Thanks,
> Matt
> 
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 ruslan_baratov at yahoo.com  Wed Jan 27 02:18:09 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 27 Jan 2016 14:18:09 +0700
Subject: [CMake] What is the best way to handle Boost dependencies in a
 package config file
In-Reply-To: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
References: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
Message-ID: <56A86F31.7070206@yahoo.com>

On 27-Jan-16 09:54, Johnson, Matt (GE Healthcare) wrote:
> I like package config files.  I want to use more of them.  However, I have a dependency on boost.  While boost has a Find module, it doesn't have a package config file.  I'm not going to be able to depend on the users of my package building boost via cmake (also, is that still an active thing?).
>
> It seems like the best I could hope for is to generate the package config file, then hack it up to deal with the boost stuff.  Has anyone already solved this problem or have any tips?  I found this Hunter package manager (https://github.com/ruslo/hunter), but it seems a bit heavyweight when all I want is boost.
--
> Also, I can't have my build system going out and downloading the packages - they all have to come from an internal source.
>
Just for your information you can use "file://" links instead of regular 
"http://" in both hunter.cmake and HunterGate so there is no need to "go 
out" - you can be completely offline.

Ruslo

From Matthew.Johnson1 at med.ge.com  Wed Jan 27 07:57:38 2016
From: Matthew.Johnson1 at med.ge.com (Johnson, Matt (GE Healthcare))
Date: Wed, 27 Jan 2016 12:57:38 +0000
Subject: [CMake] What is the best way to handle Boost dependencies in a
 package config file
In-Reply-To: <3FE52583-5E48-4920-B24F-9682754EE721@canonical.com>
References: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
 <3FE52583-5E48-4920-B24F-9682754EE721@canonical.com>
Message-ID: <BE73B6714FF4E843992984FDF5B6EA02274590B1@CINURCNA05.e2k.ad.ge.com>

Thanks for the reply, Michi.  Forgive me if I'm missing something - how does this help with your package config file?  Doesn't Boost_LIBRARIES contain full paths to  the component libraries you listed?  My understanding is that in order to have a package config file result in something that can be relocated, I'd need to be able to do something like:

find_package(Boost CONFIG COMPONENTS system filesystem regex REQUIRED)
target_link_libraries(my_target Boost::system Boost::filesystem  Boost::regex)

That is, the  find package would have to create imported targets for the boost dependencies.  As far as I know, FindBoost.cmake does not do this.  Please correct me if I'm wrong - that would make me  most happy! 

Thanks again for the help.

Matt

> -----Original Message-----
> From: Michi Henning [mailto:michi.henning at canonical.com]
> Sent: Wednesday, January 27, 2016 1:55 AM
> To: Johnson, Matt (GE Healthcare)
> Cc: cmake at cmake.org
> Subject: Re: [CMake] What is the best way to handle Boost dependencies in
> a package config file
> 
> We use this, which works fine for me on Ubuntu:
> 
> find_package(Boost COMPONENTS system filesystem regex serialization
> thread log REQUIRED)
> 
> Cheers,
> 
> Michi.
> 
> > On 27 Jan 2016, at 12:54 , Johnson, Matt (GE Healthcare)
> <Matthew.Johnson1 at med.ge.com> wrote:
> >
> > I like package config files.  I want to use more of them.  However, I have a
> dependency on boost.  While boost has a Find module, it doesn't have a
> package config file.  I'm not going to be able to depend on the users of my
> package building boost via cmake (also, is that still an active thing?).
> >
> > It seems like the best I could hope for is to generate the package config file,
> then hack it up to deal with the boost stuff.  Has anyone already solved this
> problem or have any tips?  I found this Hunter package manager
> (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_ruslo_hunter&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh
> _RiV3wUrLrDQYWSI&r=qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m
> =PrIOuKSVt-ib8BwXCLUzXhcXKOaI-nPRE3lR3m-
> XYH8&s=2LvLkrDkWzloxqrrBP6UdCiiL0YnWgmToNjL2_5mZTw&e= ), but it
> seems a bit heavyweight when all I want is boost.  Also, I can't have my build
> system going out and downloading the packages - they all have to come from
> an internal source.
> >
> > Thanks,
> > Matt
> >
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.cmake.org_Wiki
> > _CMake-
> 5FFAQ&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=
> > qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m=PrIOuKSVt-
> ib8BwXCLUzXhcX
> > KOaI-nPRE3lR3m-
> XYH8&s=voIOJHSB3_3nWFPCHnLZrEHATQTMvoAv6TceyDyGQZA&e=
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support:
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cmake.org_cmake_he
> >
> lp_support.html&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQ
> YWSI
> > &r=qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m=PrIOuKSVt-
> ib8BwXCLUzX
> > hcXKOaI-nPRE3lR3m-
> XYH8&s=g65Y7hDTwOo3VrTo2tEH3SUkWkr98xxGzXD1HwzQYsw&e
> > = CMake Consulting:
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cmake.org_cmake_he
> >
> lp_consulting.html&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLr
> DQY
> > WSI&r=qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m=PrIOuKSVt-
> ib8BwXCL
> > UzXhcXKOaI-nPRE3lR3m-XYH8&s=Ldr318Ilc_hQg2SdaGdLBb-
> iz_KqDMgeeUbtAMAodH
> > U&e= CMake Training Courses:
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cmake.org_cmake_he
> >
> lp_training.html&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQ
> YWS
> > I&r=qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m=PrIOuKSVt-
> ib8BwXCLUz
> > XhcXKOaI-nPRE3lR3m-
> XYH8&s=QihVB4Y2sUhcmA1sx5eJiP5U6bAEPUiv0eWvBaxQCBM&
> > e=
> >
> > Visit other Kitware open-source projects at
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.kitware.com_op
> >
> ensource_opensource.html&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh_Ri
> V3wU
> >
> rLrDQYWSI&r=qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m=PrIOuKS
> Vt-ib
> > 8BwXCLUzXhcXKOaI-nPRE3lR3m-
> XYH8&s=HS6ra4DuapPlznsB2bTbsvGRHWo1VqrLEC8W
> > LkNuNE4&e=
> >
> > Follow this link to subscribe/unsubscribe:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__public.kitware.com
> >
> _mailman_listinfo_cmake&d=CwIFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV
> 3wUrLrDQYWSI&r=qts7iZJBjQRtedrrcqcDRKGTou2a2ZKSs95InlFGa34&m=PrIO
> uKSVt-ib8BwXCLUzXhcXKOaI-nPRE3lR3m-
> XYH8&s=aXGbP0VkR84NnoG05l6FMHvDll3S2Z788vYWyD5bQp0&e=


From Matthew.Johnson1 at med.ge.com  Wed Jan 27 08:08:39 2016
From: Matthew.Johnson1 at med.ge.com (Johnson, Matt (GE Healthcare))
Date: Wed, 27 Jan 2016 13:08:39 +0000
Subject: [CMake] What is the best way to handle Boost dependencies in a
 package config file
In-Reply-To: <56A86F31.7070206@yahoo.com>
References: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
 <56A86F31.7070206@yahoo.com>
Message-ID: <BE73B6714FF4E843992984FDF5B6EA02274590CA@CINURCNA05.e2k.ad.ge.com>

> -----Original Message-----
> From: Ruslan Baratov [mailto:ruslan_baratov at yahoo.com]
> Sent: Wednesday, January 27, 2016 2:18 AM
> To: Johnson, Matt (GE Healthcare)
> Cc: cmake at cmake.org
> Subject: Re: [CMake] What is the best way to handle Boost dependencies in
> a package config file
> 
> On 27-Jan-16 09:54, Johnson, Matt (GE Healthcare) wrote:
> > I like package config files.  I want to use more of them.  However, I have a
> dependency on boost.  While boost has a Find module, it doesn't have a
> package config file.  I'm not going to be able to depend on the users of my
> package building boost via cmake (also, is that still an active thing?).
> >
> > It seems like the best I could hope for is to generate the package config file,
> then hack it up to deal with the boost stuff.  Has anyone already solved this
> problem or have any tips?  I found this Hunter package manager
> (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_ruslo_hunter&d=CwIC-
> g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=qts7iZJBjQRtedrrc
> qcDRKGTou2a2ZKSs95InlFGa34&m=h5ntMfnYSIOG1mQp_twkUPunK5Nz0q9
> HBqa7Ld4B_hs&s=zi9sk8NwKokHEqrLyGA5a_yrRxLdHF9P7ID23wgrWPY&e=
> ), but it seems a bit heavyweight when all I want is boost.
> --
> > Also, I can't have my build system going out and downloading the packages
> - they all have to come from an internal source.
> >
> Just for your information you can use "file://" links instead of regular
> "https://urldefense.proofpoint.com/v2/url?u=http-3A__&d=CwIC-
> g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=qts7iZJBjQRtedrrc
> qcDRKGTou2a2ZKSs95InlFGa34&m=h5ntMfnYSIOG1mQp_twkUPunK5Nz0q9
> HBqa7Ld4B_hs&s=ts63TtZeGvflnLyyJ8pKESTjxabuzNCPmS0fGn_1L7E&e= " in
> both hunter.cmake and HunterGate so there is no need to "go out" - you can
> be completely offline.
> 
> Ruslo

Ruslo - thanks for that.  I'm seriously going to look into Hunter more.  From my cursory glance at it, it's a seriously impressive bit of cmake scripting.

Can  I ask you a few follow ups? 
1. in the case of boost, what it is doing is using the find package module, then creating import targets based off the information.  Correct?
2. If I require a newer version of boost than what is listed in the gate file, I'd need to  update hunter.cmake and HunterGate,  correct?
3. If I want to distribute my package to others, they too would need  to use Hunter, correct?  Since boost doesn't have a package config file in  its distribution, the dependency targets (e.g. Boost::regex) wouldn't exist on their system)  Any tips on this? 

Thanks again for your hard  work on  Hunter.  I've done a bit of cmake to download and install some dependencies in the past.  Yours is WAY nicer than what I came up with. 

Matt

From vania.joloboff at inria.fr  Wed Jan 27 09:24:08 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Wed, 27 Jan 2016 15:24:08 +0100
Subject: [CMake] seeking advice for building and testing variants
Message-ID: <56A8D308.60109@inria.fr>

Hi

We have a library that we want to build with N different variants
  in the compile flags for the same source code.
Then in the test phase, I want to build N versions of a benchmark
linked with the N versions of the library, then run the benchmark
and compare.

I can create N subdirectories (one for each variant) in my source dir
with a CMakeLists.txt in each directory that will set  the compile flags
for that variant and build the benchmark for that variant.
  I will get N build directories.

Is this the 'recommended' way of doing in this case,
or there would be a smarter way ?

Vania


From ruslan_baratov at yahoo.com  Wed Jan 27 09:58:52 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 27 Jan 2016 21:58:52 +0700
Subject: [CMake] What is the best way to handle Boost dependencies in a
 package config file
In-Reply-To: <BE73B6714FF4E843992984FDF5B6EA02274590CA@CINURCNA05.e2k.ad.ge.com>
References: <BE73B6714FF4E843992984FDF5B6EA0227459026@CINURCNA05.e2k.ad.ge.com>
 <56A86F31.7070206@yahoo.com>
 <BE73B6714FF4E843992984FDF5B6EA02274590CA@CINURCNA05.e2k.ad.ge.com>
Message-ID: <56A8DB2C.1090800@yahoo.com>

On 27-Jan-16 20:08, Johnson, Matt (GE Healthcare) wrote:
>> -----Original Message-----
>> From: Ruslan Baratov [mailto:ruslan_baratov at yahoo.com]
>> Sent: Wednesday, January 27, 2016 2:18 AM
>> To: Johnson, Matt (GE Healthcare)
>> Cc: cmake at cmake.org
>> Subject: Re: [CMake] What is the best way to handle Boost dependencies in
>> a package config file
>>
>> On 27-Jan-16 09:54, Johnson, Matt (GE Healthcare) wrote:
>>> I like package config files.  I want to use more of them.  However, I have a
>> dependency on boost.  While boost has a Find module, it doesn't have a
>> package config file.  I'm not going to be able to depend on the users of my
>> package building boost via cmake (also, is that still an active thing?).
>>> It seems like the best I could hope for is to generate the package config file,
>> then hack it up to deal with the boost stuff.  Has anyone already solved this
>> problem or have any tips?  I found this Hunter package manager
>> (https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__github.com_ruslo_hunter&d=CwIC-
>> g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=qts7iZJBjQRtedrrc
>> qcDRKGTou2a2ZKSs95InlFGa34&m=h5ntMfnYSIOG1mQp_twkUPunK5Nz0q9
>> HBqa7Ld4B_hs&s=zi9sk8NwKokHEqrLyGA5a_yrRxLdHF9P7ID23wgrWPY&e=
>> ), but it seems a bit heavyweight when all I want is boost.
>> --
>>> Also, I can't have my build system going out and downloading the packages
>> - they all have to come from an internal source.
>> Just for your information you can use "file://" links instead of regular
>> "https://urldefense.proofpoint.com/v2/url?u=http-3A__&d=CwIC-
>> g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=qts7iZJBjQRtedrrc
>> qcDRKGTou2a2ZKSs95InlFGa34&m=h5ntMfnYSIOG1mQp_twkUPunK5Nz0q9
>> HBqa7Ld4B_hs&s=ts63TtZeGvflnLyyJ8pKESTjxabuzNCPmS0fGn_1L7E&e= " in
>> both hunter.cmake and HunterGate so there is no need to "go out" - you can
>> be completely offline.
>>
>> Ruslo
> Ruslo - thanks for that.  I'm seriously going to look into Hunter more.  From my cursory glance at it, it's a seriously impressive bit of cmake scripting.
--

>
> Can  I ask you a few follow ups?
> 1. in the case of boost, what it is doing is using the find package module, then creating import targets based off the information.  Correct?
In general yes, but also some information passed from 
ExternalProject_Add recipe, like optional dependency. So it differs from 
approach "just add BoostConfig.cmake file" after boost installed.
Templates:
* 
https://github.com/ruslo/hunter/blob/master/cmake/templates/BoostConfig.cmake.in
* 
https://github.com/ruslo/hunter/blob/master/cmake/templates/BoostBZip2Dependency.cmake.in 
(optional boost.iostreams -> bzip2 dependency)

> 2. If I require a newer version of boost than what is listed in the gate file, I'd need to  update hunter.cmake and HunterGate,  correct?
URL/SHA1 of HunterGate command doesn't hold version of Boost to be 
precise. It holds version of archive with several versions of Boost 
(Boost/hunter.cmake: 1.55, 1.56, ...) and default version 
(configs/default.cmake: 1.58). User can choose non-default version by 
adding custom local config.cmake file: 
https://github.com/ruslo/hunter/wiki/example.custom.config.id. If you 
need version that is not listed in Boost/hunter.cmake you have to add it 
to Boost/hunter.cmake and create new archive. There is feature request 
that can allow to do it locally so it will be improved in future.

> 3. If I want to distribute my package to others, they too would need  to use Hunter, correct?  Since boost doesn't have a package config file in  its distribution, the dependency targets (e.g. Boost::regex) wouldn't exist on their system)  Any tips on this?
Well somebody have to install such extra code with Boost::* targets 
anyway, the easiest way is to delegate this job to Hunter. Also if you 
add your package to Hunter archive then users can add your package just 
by `hunter_add_package(Foo)` without even knowing about Boost and type 
of Boost targets. This is package distribution design.

> Thanks again for your hard  work on  Hunter.  I've done a bit of cmake to download and install some dependencies in the past.  Yours is WAY nicer than what I came up with.
>
> Matt

Thanks, Ruslo

From bill.hoffman at kitware.com  Wed Jan 27 10:27:00 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Wed, 27 Jan 2016 10:27:00 -0500
Subject: [CMake] WINDOWS_EXPORT_ALL_SYMBOLS
In-Reply-To: <56A7B23D.8010902@kitware.com>
References: <1453803131.2976.2.camel@t-online.de>
 <56A7B23D.8010902@kitware.com>
Message-ID: <56A8E1C4.5000809@kitware.com>

On 1/26/2016 12:51 PM, Bill Hoffman wrote:
>
> I am running the community edition...  Maybe there is some difference
> with express?
One other question, did you build 64 or 32 bit?

-Bill


From vania.joloboff at inria.fr  Wed Jan 27 10:48:17 2016
From: vania.joloboff at inria.fr (Vania Joloboff)
Date: Wed, 27 Jan 2016 16:48:17 +0100
Subject: [CMake] virtual machine project, cross compiling question
Message-ID: <56A8E6C1.8010400@inria.fr>

Hi

Our project is a virtual machine.
All of the VM software must be compiled for the host platform.
But, since the software is a VM emulating some target platform
the VM tests must be cross compiled for the target.
And we have several targets.
Thus, in the top VM build the CMAKE_CROSSCOMPILING flag
must not be set to true.

But if we set the CMAKE_CROSSCOMPILING flag into
a test subdirectory and change the variables such as CMAKE_C_COMPILER
for the corresponding target platform in some nested CMakeLists.txt
what is the scope of the change ?

Will it change the value of the variable for all future accesses
or these variables have a directory and sub-directories scope ?

This is not clear in the documentation.

Vania



From tamas.kenez at gmail.com  Wed Jan 27 16:24:15 2016
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Wed, 27 Jan 2016 22:24:15 +0100
Subject: [CMake] seeking advice for building and testing variants
In-Reply-To: <56A8D308.60109@inria.fr>
References: <56A8D308.60109@inria.fr>
Message-ID: <CAPB8=n8DRWqkUN7PzyWorvP1S3DbZN_pkZxPo+fLFJhTjOOoLg@mail.gmail.com>

You can build the N variants from the same CMakeLists.txt in a single
directory.

On Wed, Jan 27, 2016 at 3:24 PM, Vania Joloboff <vania.joloboff at inria.fr>
wrote:

> Hi
>
> We have a library that we want to build with N different variants
>  in the compile flags for the same source code.
> Then in the test phase, I want to build N versions of a benchmark
> linked with the N versions of the library, then run the benchmark
> and compare.
>
> I can create N subdirectories (one for each variant) in my source dir
> with a CMakeLists.txt in each directory that will set  the compile flags
> for that variant and build the benchmark for that variant.
>  I will get N build directories.
>
> Is this the 'recommended' way of doing in this case,
> or there would be a smarter way ?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160127/5649c4ca/attachment.html>

From fabian.wein at fau.de  Wed Jan 27 17:05:24 2016
From: fabian.wein at fau.de (Fabian Wein)
Date: Wed, 27 Jan 2016 23:05:24 +0100
Subject: [CMake] arguments for EXECUTE_PROCESS
Message-ID: <38182A80-B1D7-4B2F-BEB3-81075F928206@fau.de>

For my a test suite I want to test a Python script,
I have the arguments in a variable like

SET(MATVIZ_ARGS ??res 2 ?type bulk2d?")

and call it similar to

EXECUTE_PROCESS(
    COMMAND "${MATVIZ_PY}" "${MATVIZ_ARGS}"
    WORKING_DIRECTORY "${CCSD}"
    ERROR_VARIABLE MATVIZ_ERROR
    RESULT_VARIABLE MATVIZ_RETVAL
  )

print sys.args in the python script then tells me that there is one argument with spaces
[??py?, ??res 2 --type bulk2d']

separate_arguments(MATVIZ_ARGS_LIST UNIX_COMMAND ?${MATVIZ_ARGS}?)
COMMAND "${MATVIZ_PY}" "${MATVIZ_ARGS_LIST}"
does also not work, it delivers
[?.?py?, '--res;2;--type;bulk2d']

Trying various ways did not help.

I do not know in advance how many arguments my MATVIZ_ARGS will hold.

Is there a way to achieve it? The only idea I have at the moment is to have a small python script
that gets all arguments in one argument and does a system call via python but I would prefer a 
clean cmake solution.

Thank you very much for any suggestion,

Fabian


From AlbrechtS.fltk at online.de  Wed Jan 27 17:59:23 2016
From: AlbrechtS.fltk at online.de (Albrecht Schlosser)
Date: Wed, 27 Jan 2016 23:59:23 +0100
Subject: [CMake] arguments for EXECUTE_PROCESS
In-Reply-To: <38182A80-B1D7-4B2F-BEB3-81075F928206@fau.de>
References: <38182A80-B1D7-4B2F-BEB3-81075F928206@fau.de>
Message-ID: <56A94BCB.5090001@online.de>

On 27.01.2016 23:05 Fabian Wein wrote:
> For my a test suite I want to test a Python script,
> I have the arguments in a variable like
>
> SET(MATVIZ_ARGS ??res 2 ?type bulk2d?")
>
> and call it similar to
>
> EXECUTE_PROCESS(
>      COMMAND "${MATVIZ_PY}" "${MATVIZ_ARGS}"

Suggestion: do not quote the argument variable here:

        COMMAND "${MATVIZ_PY}" ${MATVIZ_ARGS}

>      WORKING_DIRECTORY "${CCSD}"
>      ERROR_VARIABLE MATVIZ_ERROR
>      RESULT_VARIABLE MATVIZ_RETVAL
>    )

or do something like this:

SET(MATVIZ_ARGS "?res 2" "?type bulk2d")

EXECUTE_PROCESS(
COMMAND "${MATVIZ_PY}" ${MATVIZ_ARGS}
...

If you need arguments with spaces, you might have to double quote the 
arguments in the SET command.


From jon.kristensen at km.kongsberg.com  Thu Jan 28 01:52:42 2016
From: jon.kristensen at km.kongsberg.com (Jon Kristensen)
Date: Thu, 28 Jan 2016 06:52:42 +0000
Subject: [CMake] Bug report
Message-ID: <d5483ab9dd534392b02727f5af055273@exchmbnodat10.kongsberg.master.int>

Hi,

Host:                     Windows
Program:             CMake-gui.exe
Version                3.4.3

Problem:
Running a generator that uses the Windows Shell, and then running a generator that uses the Unix shell without exiting Cmake-gui first, causes the makefiles from the latter to have the wrong shell command (SHELL = cmd.exe)

Example:

1.       Start cmake-gui

2.       Select a project that uses the Visual Studio 2015 generator and run configure and generate

3.       Select a project that uses the CDT4 - Unix makefiles and run configure and generate



The Unix makefiles will have "SHELL=cmd.exe" and Windows path names (with '\'s instead of '/'s).



Assumed cause (based on cmake-3.4.3 source distribution) :



The selection of shell seems to be based on the variable cmState::windowsShell

This variable is set to false in the cmState constructor

And is set to true (through a call to member SetWindowsShell(true) from all generators that use a Windows shell

But I could find no code that resets it if a non-Windows-Shell generator is run a(at a later stage)



Thanks

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

From Micha.Renner at t-online.de  Thu Jan 28 02:35:03 2016
From: Micha.Renner at t-online.de (Micha Renner)
Date: Thu, 28 Jan 2016 08:35:03 +0100
Subject: [CMake] WINDOWS_EXPORT_ALL_SYMBOLS
In-Reply-To: <56A8E1C4.5000809@kitware.com>
References: <1453803131.2976.2.camel@t-online.de>
 <56A7B23D.8010902@kitware.com> <56A8E1C4.5000809@kitware.com>
Message-ID: <1453966503.1581.2.camel@t-online.de>

Am Mittwoch, den 27.01.2016, 10:27 -0500 schrieb Bill Hoffman:
> On 1/26/2016 12:51 PM, Bill Hoffman wrote:
> > 
> > I am running the community edition...  Maybe there is some
> > difference
> > with express?
> One other question, did you build 64 or 32 bit?

64-bit.

Michael


From laasunde at hotmail.com  Thu Jan 28 05:25:17 2016
From: laasunde at hotmail.com (Lars)
Date: Thu, 28 Jan 2016 11:25:17 +0100
Subject: [CMake] include_external_msproject
In-Reply-To: <CAGyo1oxx8_-HrMabg=zFL=+hKEKA6mxygJZWBOuK_MXfCrpd5g@mail.gmail.com>
References: <DUB128-W4679EB698CF4508415E801CAD80@phx.gbl>,
 <CAGyo1oxx8_-HrMabg=zFL=+hKEKA6mxygJZWBOuK_MXfCrpd5g@mail.gmail.com>
Message-ID: <DUB128-W68E37E1B98B6A308DE8715CADA0@phx.gbl>

A solution file is in my view just an aggregation of projects. So I expected it to work in this context. Anyway, that leaves one question, how do I specify configuration and platform for the include_external_msproject?
 
Using (below) does not work. I still get the error message "Please check to make sure that your have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x86'. 
 
include_external_msproject(ext_test c:/test/test/test.sln PLATFORM "AnyCPU")
 
Updating the visual studio project with Configurations "Debug", "RelWithDebInfo" and "Release" and Platform "x86" is a workaround. Obviously it would be ideal if this could be controlled using cmake.
 
Appreciate any input.
 
Regards, Lars
 
> From: iosif.neitzke+cmake at gmail.com
> Date: Tue, 26 Jan 2016 09:24:35 -0600
> To: cmake at cmake.org
> Subject: Re: [CMake] include_external_msproject
> 
> No, I do not believe so.
> 
> https://cmake.org/cmake/help/v3.4/command/include_external_msproject.html
> 
> Keyword being 'project'.
> 
> On Tue, Jan 26, 2016 at 8:43 AM, Lars <laasunde at hotmail.com> wrote:
> > Appreciate some help understanding include_external_msproject.
> > Using Windows 7 and cmake 3.3
> >
> > This is what has been done so far,
> >
> > 1. Opened Visual Studio 2012 and created a new project (Windows Forms
> > Application) and saved it under c:\temp\test.
> >
> > 2. Used the following to an cmake;
> > include_external_msproject(ext_test c:/test/test/test.sln)
> >
> > This generates an error MSB4126: The specified solution configuration
> > "Debug|x86" is invalid. Please specify a valid solution configuration using
> > the configuration and platform properties...
> >
> > 3. So update the cmake file (below), clear build folder and build again;
> > include_external_msproject(ext_test c:/test/test/test.sln PLATFORM "Any
> > CPU")
> >
> > This generate the exact same error message as above. So the PLATFORM keyword
> > does not appear to be used in this context. Anyone care to explain how
> > PLATFORM works and howto specify correct configuration and platform?
> >
> > 4. To workaround the problem we open the visual studio project and added the
> > configuration and platform combo "Debug" and "x86" which cmake appears to
> > require. We use the original cmake script (below), clear build folder and
> > build again.
> > include_external_msproject(ext_test c:/test/test/test.sln)
> >
> > The following error is produced;
> > c:\temp\test\test\test.sln.metaproj : error MSB4057: The target
> > "GetNativeManifest" does not exists in the project.
> >
> > Searched all files in source and build directory and cannot find any
> > reference to "GetNativeManifest". See some issue online in regards to build
> > order but cannot see how that applies to this simple example. Really do not
> > understand this issue. Any ideas?
> >
> > 6. Update cmake and use .csproj instead of the solution file and it works.
> > The test.exe file is build. The cmake looks like this
> > include_external_msproject(ext_test c:/test/test/test.csproj)
> >
> > Does include_external_msproject support solution files?
> >
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/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/20160128/38c8d102/attachment-0001.html>

From attila.krasznahorkay at gmail.com  Thu Jan 28 05:33:28 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Thu, 28 Jan 2016 11:33:28 +0100
Subject: [CMake] Stopping CPack from compiling python files
Message-ID: <3762E967-FF22-4EE8-9B12-95CB4B13D150@gmail.com>

Dear All,

This should be a simple question, but somehow I don't seem to find an answer to it with Google.

Our projects have a lot of python files in them. Many of which are not simple python files. They are files that need our software to interpret them. So CPack should just leave them alone.

But CPack is trying to do something "smart". Which I'd like to turn off. Since in all of our rpmbuild.err files I see lines like:

+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
warning: Installed (but unpackaged) file(s) found:
...
   /usr/AtlasCore/21.0.0/InstallArea/x86_64-slc6-gcc49-opt/jobOptions/AthAnalysisBaseComps/SuppressLogging.pyc
   /usr/AtlasCore/21.0.0/InstallArea/x86_64-slc6-gcc49-opt/jobOptions/AthAnalysisBaseComps/SuppressLogging.pyo
...

(And in some projects the RPM building actually fails, seemingly because of problems with compiling some of these files.)

I guess it's the "brp-python-bytecompile" command that's responsible for doing this. Is there an easy way that I can tell CPackRPM to forget about this step? I would really like to avoid writing a custom spec file if I can...

Cheers,
            Attila

From thomas.lehmann at teamaol.com  Thu Jan 28 06:03:34 2016
From: thomas.lehmann at teamaol.com (Thomas Lehmann)
Date: Thu, 28 Jan 2016 12:03:34 +0100
Subject: [CMake] problems with multiple relocateable components
Message-ID: <CAEdhodzwrdLTs=J=f5DP9A0uFvUW4sMZkRUBg5iSdKLgQsnDGA@mail.gmail.com>

I'm currently "fighting" with the relocation using cpack ...
When creating an executable AND a library resulting in
two RPM's with two different paths lets say ...

 - /foo/bin/mybin        | executable
 - /usr/local/include    | library headers
 - /usr/local/lib64      | library binary file

That's how I configured the components ...

set(CPACK_RPM_bin_PACKAGE_PREFIX "/foo/bin")
set(CPACK_RPM_devel_PACKAGE_PREFIX "/usr/local")

I alway get this:

CMake Warning (dev) at /usr/share/cmake-3.4/Modules/CPackRPM.cmake:633
(message):
  CPackRPM:Warning: Path /usr/lib64/libfoo.a is not on one of the
  relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
  /usr/share/cmake-3.4/Modules/CPackRPM.cmake:1282
(cpack_rpm_prepare_relocation_paths)
  /usr/share/cmake-3.4/Modules/CPackRPM.cmake:1770
(cpack_rpm_generate_package)

I guess ... I can use CPACK_RPM_RELOCATION_PATHS but my problem is
that I don't know the installation path in the sub directory of the library
since
I did add_subdirectory(Library) ...

Any idea, comments, proposes?

Kind Regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160128/93e3b36d/attachment.html>

From nikita.barawade at einfochips.com  Thu Jan 28 06:42:03 2016
From: nikita.barawade at einfochips.com (Nikita Barawade)
Date: Thu, 28 Jan 2016 11:42:03 +0000
Subject: [CMake] Multiple Visual Studio Solutions through same master
	CMakeLists.txt
Message-ID: <PS1PR02MB1401CE2CBB15C8874988B0E386DA0@PS1PR02MB1401.apcprd02.prod.outlook.com>



Hi All ,

It is possible to same master CMakeList to generate multiple visual studio solution files ?

here is my master CMakeList :

cmake_minimum_required (VERSION 2.8.11)
project (Myproject_all)

set_property (GLOBAL PROPERTY USE_FOLDERS ON)

# Set compiler flags and options.
# enable the Visual Studio warning level to 4
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")

# Sub-directories where more CMakeLists.txt exist
add_subdirectory (lib1)
add_subdirectory (TestApp1)
add_subdirectory (lib2)
add_subdirectory (TestApp2)
add_subdirectory (TestApp3)

Now , my project "Myproject_all" includes all sub-projects as lib1,TestApp1,lib2,TestApp2,TestApp3 (testApps depend on libraries )
I want another solution to be generated through same CMakeList for example with name "Myproject" which includes only ,
lib1,TestApp1,lib2.
I should not always edit master CMakeList to change project name and remove TestApp2 and TestApp3.Is there any way to automate this?


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/20160128/eafc0fd0/attachment.html>

From nilsgladitz at gmail.com  Thu Jan 28 06:57:25 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 28 Jan 2016 12:57:25 +0100
Subject: [CMake] Multiple Visual Studio Solutions through same master
 CMakeLists.txt
In-Reply-To: <PS1PR02MB1401CE2CBB15C8874988B0E386DA0@PS1PR02MB1401.apcprd02.prod.outlook.com>
References: <PS1PR02MB1401CE2CBB15C8874988B0E386DA0@PS1PR02MB1401.apcprd02.prod.outlook.com>
Message-ID: <56AA0225.2010402@gmail.com>



On 01/28/2016 12:42 PM, Nikita Barawade wrote:
>
>
>
> Hi All ,
>
> It is possible to same master CMakeList to generate multiple visual 
> studio solution files ?
>
> here is my master CMakeList :
>
> cmake_minimum_required (VERSION 2.8.11)
> project (Myproject_all)
>
> set_property (GLOBAL PROPERTY USE_FOLDERS ON)
>
> # Set compiler flags and options.
> # enable the Visual Studio warning level to 4
> set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
>
> # Sub-directories where more CMakeLists.txt exist
> add_subdirectory (lib1)
> add_subdirectory (TestApp1)
> add_subdirectory (lib2)
> add_subdirectory (TestApp2)
> add_subdirectory (TestApp3)
>
> Now , my project "Myproject_all" includes all sub-projects as 
> lib1,TestApp1,lib2,TestApp2,TestApp3 (testApps depend on libraries )
> I want another solution to be generated through same CMakeList for 
> example with name "Myproject" which includes only ,
> lib1,TestApp1,lib2.
> I should not always edit master CMakeList to change project name and 
> remove TestApp2 and TestApp3.Is there any way to automate this?

CMake generates one solution per directory (CMakeLists.txt) that has its 
own project() call.
To put lib1,TestApp1,lib2 into their own solution you would therefor 
have to put them into a common parent directory (distinct from the other 
targets) and give that parent directory's CMakeLists.txt its own 
project(Myproject) call.

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

From jan.hegewald at awi.de  Thu Jan 28 06:56:36 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Thu, 28 Jan 2016 12:56:36 +0100
Subject: [CMake] globs case sensitivity depends on platform
Message-ID: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>

Hi all,
I have some trouble with file globbing using the glob command like so:
	file(GLOB all_sources ${src_home}/*.F**)
the src_home contains files with uppercase and also some with lowercase suffixes, e.g. .F and .f (This makes an important difference to some Fortran compilers regarding the C preprocessor.).
Now the all_sources does not contain the same list of files on different platforms: On my Mac, the F* glob returns the F* and the f* files, whereas on linux it only returns the F* files.
I tested with a case sensitive filesystem on the Mac too, same result: uppercase and lowercase are returned.
The cmake on both tested systems is "cmake version 3.4.3".

My current solution is this:
	file(GLOB all_sources ${src_home}/*.F** ${src_home}/*.f**)
	list(REMOVE_DUPLICATES all_sources)

Am I missing something obvious here? Do you know a better workaround? I think this is an error with cmakes glob, where can I report it?

Many TIA,
Jan

From nikita.barawade at einfochips.com  Thu Jan 28 07:03:07 2016
From: nikita.barawade at einfochips.com (Nikita Barawade)
Date: Thu, 28 Jan 2016 12:03:07 +0000
Subject: [CMake] Multiple Visual Studio Solutions through same master
 CMakeLists.txt
In-Reply-To: <56AA0225.2010402@gmail.com>
References: <PS1PR02MB1401CE2CBB15C8874988B0E386DA0@PS1PR02MB1401.apcprd02.prod.outlook.com>,
 <56AA0225.2010402@gmail.com>
Message-ID: <KL1PR02MB14005D09830A7DB3C229ADE386DA0@KL1PR02MB1400.apcprd02.prod.outlook.com>



Hi,

Thanks Nils !

Regards,
Nikita


________________________________
From: Nils Gladitz <nilsgladitz at gmail.com>
Sent: 28 January 2016 05:27 PM
To: Nikita Barawade; cmake at cmake.org
Subject: Re: [CMake] Multiple Visual Studio Solutions through same master CMakeLists.txt



On 01/28/2016 12:42 PM, Nikita Barawade wrote:



Hi All ,

It is possible to same master CMakeList to generate multiple visual studio solution files ?

here is my master CMakeList :

cmake_minimum_required (VERSION 2.8.11)
project (Myproject_all)

set_property (GLOBAL PROPERTY USE_FOLDERS ON)

# Set compiler flags and options.
# enable the Visual Studio warning level to 4
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")

# Sub-directories where more CMakeLists.txt exist
add_subdirectory (lib1)
add_subdirectory (TestApp1)
add_subdirectory (lib2)
add_subdirectory (TestApp2)
add_subdirectory (TestApp3)

Now , my project "Myproject_all" includes all sub-projects as lib1,TestApp1,lib2,TestApp2,TestApp3 (testApps depend on libraries )
I want another solution to be generated through same CMakeList for example with name "Myproject" which includes only ,
lib1,TestApp1,lib2.
I should not always edit master CMakeList to change project name and remove TestApp2 and TestApp3.Is there any way to automate this?

CMake generates one solution per directory (CMakeLists.txt) that has its own project() call.
To put lib1,TestApp1,lib2 into their own solution you would therefor have to put them into a common parent directory (distinct from the other targets) and give that parent directory's CMakeLists.txt its own project(Myproject) call.

Nils
************************************************************************************************************************************************************* 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/20160128/3ae8548c/attachment.html>

From nilsgladitz at gmail.com  Thu Jan 28 07:39:50 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 28 Jan 2016 13:39:50 +0100
Subject: [CMake] globs case sensitivity depends on platform
In-Reply-To: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
References: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
Message-ID: <56AA0C16.3020102@gmail.com>

On 01/28/2016 12:56 PM, ? Jan Hegewald wrote:
> Hi all,
> I have some trouble with file globbing using the glob command like so:
> 	file(GLOB all_sources ${src_home}/*.F**)

You might already be aware but CMake discourages using GLOB for source 
files; though for different reasons (see Note in [1]).
Incidentally using explicit source file listings would work around this 
issue as well.

Nils

[1] https://cmake.org/cmake/help/v3.4/command/file.html

From eric.noulard at gmail.com  Thu Jan 28 07:43:56 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 28 Jan 2016 13:43:56 +0100
Subject: [CMake] Stopping CPack from compiling python files
In-Reply-To: <3762E967-FF22-4EE8-9B12-95CB4B13D150@gmail.com>
References: <3762E967-FF22-4EE8-9B12-95CB4B13D150@gmail.com>
Message-ID: <CAPASGLqpaNpJiZRPq7hvZYrzcaCPnC7uSocWUjcfj2f6yEOixA@mail.gmail.com>

2016-01-28 11:33 GMT+01:00 Attila Krasznahorkay <
attila.krasznahorkay at gmail.com>:

> Dear All,
>
> This should be a simple question, but somehow I don't seem to find an
> answer to it with Google.
>
> Our projects have a lot of python files in them. Many of which are not
> simple python files. They are files that need our software to interpret
> them. So CPack should just leave them alone.
>
> But CPack is trying to do something "smart". Which I'd like to turn off.
> Since in all of our rpmbuild.err files I see lines like:
>
> + /usr/lib/rpm/check-buildroot
> + /usr/lib/rpm/redhat/brp-compress
> + /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
> + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
> + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip
> /usr/bin/objdump
> + /usr/lib/rpm/brp-python-bytecompile
> + /usr/lib/rpm/redhat/brp-python-hardlink
> + /usr/lib/rpm/redhat/brp-java-repack-jars
> warning: Installed (but unpackaged) file(s) found:
> ...
>
>  /usr/AtlasCore/21.0.0/InstallArea/x86_64-slc6-gcc49-opt/jobOptions/AthAnalysisBaseComps/SuppressLogging.pyc
>
>  /usr/AtlasCore/21.0.0/InstallArea/x86_64-slc6-gcc49-opt/jobOptions/AthAnalysisBaseComps/SuppressLogging.pyo
> ...
>
> (And in some projects the RPM building actually fails, seemingly because
> of problems with compiling some of these files.)
>
> I guess it's the "brp-python-bytecompile" command that's responsible for
> doing this. Is there an easy way that I can tell CPackRPM to forget about
> this step? I would really like to avoid writing a custom spec file if I
> can...
>

This kind of "automatic" scripts calls are due to your system specific RPM
setup.
Have a look at:

https://lists.fedoraproject.org/pipermail/devel/2010-April/135366.html
https://www.redhat.com/archives/rpm-list/2007-November/msg00020.html

you can try:
$ rpm --showrc

in order to see default RPM macros values on your particular system,
in particular seek for "__os_install_post".

Not sure how we can disable such script call from CPackRPM unless adding
the extra feature to call
rpm/rpmbuild wiht appropriate option. May be you can try to fill the
CPACK_RPM_SPEC_MORE_DEFINE variable
with appropriate macro redefining "__os_install_post".

This would be more like a hack than a solution.
-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160128/0b7cf479/attachment-0001.html>

From domen.vrankar at gmail.com  Thu Jan 28 08:07:25 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 28 Jan 2016 14:07:25 +0100
Subject: [CMake] Stopping CPack from compiling python files
In-Reply-To: <CAPASGLqpaNpJiZRPq7hvZYrzcaCPnC7uSocWUjcfj2f6yEOixA@mail.gmail.com>
References: <3762E967-FF22-4EE8-9B12-95CB4B13D150@gmail.com>
 <CAPASGLqpaNpJiZRPq7hvZYrzcaCPnC7uSocWUjcfj2f6yEOixA@mail.gmail.com>
Message-ID: <CAKgx6B+Q-ifuQZtWy-Wnam_aFFH6cpspokJBe6O6bWKj76wZ9g@mail.gmail.com>

> Not sure how we can disable such script call from CPackRPM unless adding the
> extra feature to call
> rpm/rpmbuild wiht appropriate option. May be you can try to fill the
> CPACK_RPM_SPEC_MORE_DEFINE variable
> with appropriate macro redefining "__os_install_post".
>
> This would be more like a hack than a solution.

As far as I can tell from links such as
https://www.redhat.com/archives/rpm-list/2007-November/msg00020.html
and
http://www.math-linux.com/linux/rpm/article/how-to-turn-off-avoid-brp-python-bytecompile-script-in-a-spec-file
there is no non hack solution for this so even if we'd put it in
CPackRPM it would be a hackish workaround.

Content from the second link might be the right candidate for
CPACK_RPM_SPEC_MORE_DEFINE (haven't tested it).

set(CPACK_RPM_SPEC_MORE_DEFINE "%global __os_install_post %(echo
'%{__os_install_post}' | sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')")

Regards,
Domen

From jan.hegewald at awi.de  Thu Jan 28 08:35:35 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Thu, 28 Jan 2016 14:35:35 +0100
Subject: [CMake] globs case sensitivity depends on platform
In-Reply-To: <56AA0C16.3020102@gmail.com>
References: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
 <56AA0C16.3020102@gmail.com>
Message-ID: <821C1B3D-9BD6-4F63-B4F5-206B03CF46FC@awi.de>

Hi Nils,

> On 28.01.2016, at 13:39, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> 
> You might already be aware but CMake discourages using GLOB for source files

yes, I read the docs before posting (:
Avoiding glob would be a workaround to my problem. But anyway I think that glob is broken if it produces different results on different platforms.

Cheers,
Jan

From apaku at gmx.de  Thu Jan 28 10:43:37 2016
From: apaku at gmx.de (Andreas Pakulat)
Date: Thu, 28 Jan 2016 16:43:37 +0100
Subject: [CMake] globs case sensitivity depends on platform
In-Reply-To: <821C1B3D-9BD6-4F63-B4F5-206B03CF46FC@awi.de>
References: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
 <56AA0C16.3020102@gmail.com>
 <821C1B3D-9BD6-4F63-B4F5-206B03CF46FC@awi.de>
Message-ID: <CAExHGmQLzgaXo481mT7a67NH=VuZupcCAJ_qMv22p86WEJQx-w@mail.gmail.com>

Hi Jan,

On Thu, Jan 28, 2016 at 2:35 PM, ? Jan Hegewald <jan.hegewald at awi.de>
wrote:

> Hi Nils,
>
> > On 28.01.2016, at 13:39, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> >
> > You might already be aware but CMake discourages using GLOB for source
> files
>
> yes, I read the docs before posting (:
> Avoiding glob would be a workaround to my problem. But anyway I think that
> glob is broken if it produces different results on different platforms.
>

I can't find any docs on cmake.org about what a globbing-expression is
exactly, but the docs for file(glob) at least don't say anything about this
function producing the same results on different platforms. In fact I'd be
surprised if the behavior of the file(glob) function is different than
using the same wildcards with ls/dir on a terminal.

The only bug that I can see from your description is that the behavior is
inconsistent with different types of FS on OSX, that is definetly not
matching above mentioned expectation.

Anyway, the right place to report bugs/problems is
https://public.kitware.com/Bug/my_view_page.php

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160128/2f5ce241/attachment.html>

From jan.hegewald at awi.de  Thu Jan 28 10:52:06 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Thu, 28 Jan 2016 16:52:06 +0100
Subject: [CMake] globs case sensitivity depends on platform
In-Reply-To: <CAExHGmQLzgaXo481mT7a67NH=VuZupcCAJ_qMv22p86WEJQx-w@mail.gmail.com>
References: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
 <56AA0C16.3020102@gmail.com> <821C1B3D-9BD6-4F63-B4F5-206B03CF46FC@awi.de>
 <CAExHGmQLzgaXo481mT7a67NH=VuZupcCAJ_qMv22p86WEJQx-w@mail.gmail.com>
Message-ID: <02BC5959-D2C5-4959-90B9-6CC8F1C33E1D@awi.de>

Hi Andreas,

> On 28.01.2016, at 16:43, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> Hi Jan,
> 
> On Thu, Jan 28, 2016 at 2:35 PM, ? Jan Hegewald <jan.hegewald at awi.de> wrote:
> Hi Nils,
> 
> > On 28.01.2016, at 13:39, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> >
> > You might already be aware but CMake discourages using GLOB for source files
> 
> yes, I read the docs before posting (:
> Avoiding glob would be a workaround to my problem. But anyway I think that glob is broken if it produces different results on different platforms.
> 
> I can't find any docs on cmake.org about what a globbing-expression is exactly, but the docs for file(glob) at least don't say anything about this function producing the same results on different platforms. In fact I'd be surprised if the behavior of the file(glob) function is different than using the same wildcards with ls/dir on a terminal.

the cmake glob is different from the results of a terminal ls.

> 
> The only bug that I can see from your description is that the behavior is inconsistent with different types of FS on OSX, that is definetly not matching above mentioned expectation.

Maybe I was unclear about this, but cmake glob ignores the case regardless of the FS being case sensitive or not.

> 
> Anyway, the right place to report bugs/problems is https://public.kitware.com/Bug/my_view_page.php

As you hinted at above, I am not really sure if this really is a bug (:

Cheers,
Jan

From taylor at braun-jones.org  Thu Jan 28 11:04:17 2016
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Thu, 28 Jan 2016 11:04:17 -0500
Subject: [CMake] ninja command line options not propagated to ninja
 invocation for superbuild projects
In-Reply-To: <CAKfKJYvvdjOumvQx5v641Q-dqNVEagzMS5P5Fk1yaiRtBwFvnQ@mail.gmail.com>
References: <CAKfKJYvvdjOumvQx5v641Q-dqNVEagzMS5P5Fk1yaiRtBwFvnQ@mail.gmail.com>
Message-ID: <CAKfKJYuGRvmx6mr+cU1dNxyDwhLArK-uSJR9Hbb2j3A8=Ji2cQ@mail.gmail.com>

On Sat, Mar 28, 2015 at 10:38 AM, Taylor Braun-Jones <taylor at braun-jones.org>
wrote:
>
> See htop screenshot below for an example of what I mean. Note that
`ninja` in the original command line invocation is just a bash alias for
ninja-build (the name of the ninja binary on Fedora-based systems)
>
> Should I expect to see the -l3 option to be propagated automatically to
the sub projects of my superbuild? Or do I need to do some special cmake
configuration to make this happen? Or is this just a known issue?

I'm still seeing this behavior with CMake 3.4.1. Here's a friendlier
plaintext representation of the previous htop screenshot snippet:

ninja -l3
??? /usr/bin/ninja-build
    ??? /usr/bin/ninja-build
    ??? /usr/bin/ninja-build

Is this expected behavior, a known bug, or a new bug that I should file?
Note that this example shows the -l option not being propagated, but I
think all of the following Ninja options should be propagated:

  -l N         do not start new jobs if the load average is greater than N
  -n           dry run (don't run commands but act like they succeeded)
  -v           show all command lines while building
  -d stats     print operation counts/timing info
  -d explain   explain what caused a command to execute
  -t clean     clean built files
  -t commands  list all commands required to rebuild given targets

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

From brad.king at kitware.com  Thu Jan 28 11:18:04 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 28 Jan 2016 11:18:04 -0500
Subject: [CMake] [cmake-developers] ninja command line options not
 propagated to ninja invocation for superbuild projects
In-Reply-To: <CAKfKJYuGRvmx6mr+cU1dNxyDwhLArK-uSJR9Hbb2j3A8=Ji2cQ@mail.gmail.com>
References: <CAKfKJYvvdjOumvQx5v641Q-dqNVEagzMS5P5Fk1yaiRtBwFvnQ@mail.gmail.com>
 <CAKfKJYuGRvmx6mr+cU1dNxyDwhLArK-uSJR9Hbb2j3A8=Ji2cQ@mail.gmail.com>
Message-ID: <56AA3F3C.7080506@kitware.com>

On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote:
> Is this expected behavior, a known bug, or a new bug that I should file?

Currently it is expected, but I don't think anyone has thoroughly
investigated it or tried to implement it.  IIRC it works in Makefile
generators only because the make tool does it under the hood when
one uses $(MAKE) in a makefile to run another make.  It is a feature
of the build tool itself, not of CMake.  Unless Ninja offers some
equivalent it may not be possible.

-Brad


From apaku at gmx.de  Thu Jan 28 14:28:11 2016
From: apaku at gmx.de (Andreas Pakulat)
Date: Thu, 28 Jan 2016 20:28:11 +0100
Subject: [CMake] globs case sensitivity depends on platform
In-Reply-To: <02BC5959-D2C5-4959-90B9-6CC8F1C33E1D@awi.de>
References: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
 <56AA0C16.3020102@gmail.com>
 <821C1B3D-9BD6-4F63-B4F5-206B03CF46FC@awi.de>
 <CAExHGmQLzgaXo481mT7a67NH=VuZupcCAJ_qMv22p86WEJQx-w@mail.gmail.com>
 <02BC5959-D2C5-4959-90B9-6CC8F1C33E1D@awi.de>
Message-ID: <CAExHGmTma8p5qkKKTMUmYoA=fQ1ojLrVgXnnScqsh++Tt=qtBw@mail.gmail.com>

Hi Jan,

On Thu, Jan 28, 2016 at 4:52 PM, ? Jan Hegewald <jan.hegewald at awi.de>
wrote:

> Hi Andreas,
>
> > On 28.01.2016, at 16:43, Andreas Pakulat <apaku at gmx.de> wrote:
> >
> > Hi Jan,
> >
> > On Thu, Jan 28, 2016 at 2:35 PM, ? Jan Hegewald <jan.hegewald at awi.de>
> wrote:
> > Hi Nils,
> >
> > > On 28.01.2016, at 13:39, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> > >
> > > You might already be aware but CMake discourages using GLOB for source
> files
> >
> > yes, I read the docs before posting (:
> > Avoiding glob would be a workaround to my problem. But anyway I think
> that glob is broken if it produces different results on different platforms.
> >
> > I can't find any docs on cmake.org about what a globbing-expression is
> exactly, but the docs for file(glob) at least don't say anything about this
> function producing the same results on different platforms. In fact I'd be
> surprised if the behavior of the file(glob) function is different than
> using the same wildcards with ls/dir on a terminal.
>
> the cmake glob is different from the results of a terminal ls


On the Mac apparently (based on your first mail)

> The only bug that I can see from your description is that the behavior is
> inconsistent with different types of FS on OSX, that is definetly not
> matching above mentioned expectation.
>
> Maybe I was unclear about this, but cmake glob ignores the case regardless
> of the FS being case sensitive or not.
>

Now that contradicts your initial mail, you said there that on OSX you get
F* and f* files for a case-insensitive filesystem, but on Linux you get
only F*. But you also said that a case-sensitive filesystem on OSX still
gives you F* and f* files, which in my eyes is a bug in the implementation.

I also just checked the CMake sources quickly and it seems that the
glob-support is completely 'inhouse', meaning it does not call out to
platform-specific functions (I guess that would explain the discrepancy on
OSX).

So I guess asking for the same behavior across platforms is just as
reasonable (given the logics are fully under CMake's control) as asking for
it to reflect what a ls/dir would do on the corresponding platform.

I think a bugreport is the correct next step, even if it merely leads to a
clarification of the behavior in the documentation.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160128/70a6c6fd/attachment.html>

From taylor at braun-jones.org  Thu Jan 28 15:15:58 2016
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Thu, 28 Jan 2016 15:15:58 -0500
Subject: [CMake] [cmake-developers] ninja command line options not
 propagated to ninja invocation for superbuild projects
In-Reply-To: <CAPqtr1+27R8zGPz1b7R_fgieMRXK7Zbijv3f9ke5d0cw_Pvx+Q@mail.gmail.com>
References: <CAKfKJYvvdjOumvQx5v641Q-dqNVEagzMS5P5Fk1yaiRtBwFvnQ@mail.gmail.com>
 <CAKfKJYuGRvmx6mr+cU1dNxyDwhLArK-uSJR9Hbb2j3A8=Ji2cQ@mail.gmail.com>
 <56AA3F3C.7080506@kitware.com>
 <CAPqtr1+27R8zGPz1b7R_fgieMRXK7Zbijv3f9ke5d0cw_Pvx+Q@mail.gmail.com>
Message-ID: <CAKfKJYvEt6qpEkCKjR-xdVQZ4sxGKQ1DPeoz1tiQaiKDFe3xug@mail.gmail.com>

On Thu, Jan 28, 2016 at 11:28 AM, Nicolas Despr?s
<nicolas.despres at gmail.com> wrote:
> Unfortunately, Ninja won't offer it:
> https://github.com/ninja-build/ninja/pull/1079

That's too bad. I understand the perspective of the Ninja developers,
but it's not clear to me what the proposed alternative should be.
Should CMake be using the subninja[1] keyword to include the
build.ninja of External Projects?

[1] https://ninja-build.org/manual.html#ref_scope

From ben.boeckel at kitware.com  Thu Jan 28 15:36:35 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 28 Jan 2016 15:36:35 -0500
Subject: [CMake] [cmake-developers] ninja command line options not
 propagated to ninja invocation for superbuild projects
In-Reply-To: <CAKfKJYvEt6qpEkCKjR-xdVQZ4sxGKQ1DPeoz1tiQaiKDFe3xug@mail.gmail.com>
References: <CAKfKJYvvdjOumvQx5v641Q-dqNVEagzMS5P5Fk1yaiRtBwFvnQ@mail.gmail.com>
 <CAKfKJYuGRvmx6mr+cU1dNxyDwhLArK-uSJR9Hbb2j3A8=Ji2cQ@mail.gmail.com>
 <56AA3F3C.7080506@kitware.com>
 <CAPqtr1+27R8zGPz1b7R_fgieMRXK7Zbijv3f9ke5d0cw_Pvx+Q@mail.gmail.com>
 <CAKfKJYvEt6qpEkCKjR-xdVQZ4sxGKQ1DPeoz1tiQaiKDFe3xug@mail.gmail.com>
Message-ID: <20160128203635.GA11605@megas.kitware.com>

On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote:
> That's too bad. I understand the perspective of the Ninja developers,
> but it's not clear to me what the proposed alternative should be.
> Should CMake be using the subninja[1] keyword to include the
> build.ninja of External Projects?

That would be possible with the work that's been done here:

    http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364

--Ben

From taylor at braun-jones.org  Thu Jan 28 17:28:11 2016
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Thu, 28 Jan 2016 17:28:11 -0500
Subject: [CMake] [cmake-developers] ninja command line options not
 propagated to ninja invocation for superbuild projects
In-Reply-To: <20160128203635.GA11605@megas.kitware.com>
References: <CAKfKJYvvdjOumvQx5v641Q-dqNVEagzMS5P5Fk1yaiRtBwFvnQ@mail.gmail.com>
 <CAKfKJYuGRvmx6mr+cU1dNxyDwhLArK-uSJR9Hbb2j3A8=Ji2cQ@mail.gmail.com>
 <56AA3F3C.7080506@kitware.com>
 <CAPqtr1+27R8zGPz1b7R_fgieMRXK7Zbijv3f9ke5d0cw_Pvx+Q@mail.gmail.com>
 <CAKfKJYvEt6qpEkCKjR-xdVQZ4sxGKQ1DPeoz1tiQaiKDFe3xug@mail.gmail.com>
 <20160128203635.GA11605@megas.kitware.com>
Message-ID: <CAKfKJYu0vP-vBKcsFXeuXoL42WWckxfhPouFZaS1CNHmSAo+=A@mail.gmail.com>

On Thu, Jan 28, 2016 at 3:36 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote:
>> That's too bad. I understand the perspective of the Ninja developers,
>> but it's not clear to me what the proposed alternative should be.
>> Should CMake be using the subninja[1] keyword to include the
>> build.ninja of External Projects?
>
> That would be possible with the work that's been done here:
>
>     http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364

Awesome. Nothing left to be said in this thread. I'll start following that one.

Taylor

From jan.hegewald at awi.de  Fri Jan 29 05:08:25 2016
From: jan.hegewald at awi.de (=?utf-8?Q?=F0=9F=90=8B_Jan_Hegewald?=)
Date: Fri, 29 Jan 2016 11:08:25 +0100
Subject: [CMake] globs case sensitivity depends on platform
In-Reply-To: <CAExHGmTma8p5qkKKTMUmYoA=fQ1ojLrVgXnnScqsh++Tt=qtBw@mail.gmail.com>
References: <6D90D15D-D0D5-413B-831A-D98628D1AA30@awi.de>
 <56AA0C16.3020102@gmail.com> <821C1B3D-9BD6-4F63-B4F5-206B03CF46FC@awi.de>
 <CAExHGmQLzgaXo481mT7a67NH=VuZupcCAJ_qMv22p86WEJQx-w@mail.gmail.com>
 <02BC5959-D2C5-4959-90B9-6CC8F1C33E1D@awi.de>
 <CAExHGmTma8p5qkKKTMUmYoA=fQ1ojLrVgXnnScqsh++Tt=qtBw@mail.gmail.com>
Message-ID: <1893C4E2-A3D4-4D75-B7D1-45335317F376@awi.de>

Hi Andreas,

thanks for bearing with me (-:

> On 28.01.2016, at 20:28, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> Hi Jan,
> 
> On Thu, Jan 28, 2016 at 4:52 PM, ? Jan Hegewald <jan.hegewald at awi.de> wrote:
> Hi Andreas,
> 
> > On 28.01.2016, at 16:43, Andreas Pakulat <apaku at gmx.de> wrote:
> >
> > Hi Jan,
> >
> > On Thu, Jan 28, 2016 at 2:35 PM, ? Jan Hegewald <jan.hegewald at awi.de> wrote:
> > Hi Nils,
> >
> > > On 28.01.2016, at 13:39, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> > >
> > > You might already be aware but CMake discourages using GLOB for source files
> >
> > yes, I read the docs before posting (:
> > Avoiding glob would be a workaround to my problem. But anyway I think that glob is broken if it produces different results on different platforms.
> >
> > I can't find any docs on cmake.org about what a globbing-expression is exactly, but the docs for file(glob) at least don't say anything about this function producing the same results on different platforms. In fact I'd be surprised if the behavior of the file(glob) function is different than using the same wildcards with ls/dir on a terminal.
> 
> the cmake glob is different from the results of a terminal ls
> 
> On the Mac apparently (based on your first mail)

Yes, on the Mac. ls behaves the same on both platforms.

> 
> > The only bug that I can see from your description is that the behavior is inconsistent with different types of FS on OSX, that is definetly not matching above mentioned expectation.
> 
> Maybe I was unclear about this, but cmake glob ignores the case regardless of the FS being case sensitive or not.
> 
> Now that contradicts your initial mail, you said there that on OSX you get F* and f* files for a case-insensitive filesystem, but on Linux you get only F*. But you also said that a case-sensitive filesystem on OSX still gives you F* and f* files, which in my eyes is a bug in the implementation.

Yes. On the Mac I get the same unexpected results for case sensitive and case insensitive FS (i.e. glob returns files with different cases).

> 
> I also just checked the CMake sources quickly and it seems that the glob-support is completely 'inhouse', meaning it does not call out to platform-specific functions (I guess that would explain the discrepancy on OSX).
> 
> So I guess asking for the same behavior across platforms is just as reasonable (given the logics are fully under CMake's control) as asking for it to reflect what a ls/dir would do on the corresponding platform.
> 
> I think a bugreport is the correct next step, even if it merely leads to a clarification of the behavior in the documentation.
> 
> Andreas

OK, I did that: https://public.kitware.com/Bug/view.php?id=15941

FYI, regarding the specification of glob patterns there is https://public.kitware.com/Bug/view.php?id=8814

Best,
Jan


From attila.krasznahorkay at gmail.com  Fri Jan 29 09:12:41 2016
From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay)
Date: Fri, 29 Jan 2016 15:12:41 +0100
Subject: [CMake] Stopping CPack from compiling python files
In-Reply-To: <CAKgx6B+Q-ifuQZtWy-Wnam_aFFH6cpspokJBe6O6bWKj76wZ9g@mail.gmail.com>
References: <3762E967-FF22-4EE8-9B12-95CB4B13D150@gmail.com>
 <CAPASGLqpaNpJiZRPq7hvZYrzcaCPnC7uSocWUjcfj2f6yEOixA@mail.gmail.com>
 <CAKgx6B+Q-ifuQZtWy-Wnam_aFFH6cpspokJBe6O6bWKj76wZ9g@mail.gmail.com>
Message-ID: <99B944A9-CE3E-4AB7-B351-817CE349C16A@gmail.com>

Thanks for the suggestions! I'll give it a try.

Cheers,
            Attila

> On 28 Jan 2016, at 14:07, Domen Vrankar <domen.vrankar at gmail.com> wrote:
> 
>> Not sure how we can disable such script call from CPackRPM unless adding the
>> extra feature to call
>> rpm/rpmbuild wiht appropriate option. May be you can try to fill the
>> CPACK_RPM_SPEC_MORE_DEFINE variable
>> with appropriate macro redefining "__os_install_post".
>> 
>> This would be more like a hack than a solution.
> 
> As far as I can tell from links such as
> https://www.redhat.com/archives/rpm-list/2007-November/msg00020.html
> and
> http://www.math-linux.com/linux/rpm/article/how-to-turn-off-avoid-brp-python-bytecompile-script-in-a-spec-file
> there is no non hack solution for this so even if we'd put it in
> CPackRPM it would be a hackish workaround.
> 
> Content from the second link might be the right candidate for
> CPACK_RPM_SPEC_MORE_DEFINE (haven't tested it).
> 
> set(CPACK_RPM_SPEC_MORE_DEFINE "%global __os_install_post %(echo
> '%{__os_install_post}' | sed -e
> 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')")
> 
> Regards,
> Domen


From michael.stuermer at schaeffler.com  Fri Jan 29 09:43:00 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Fri, 29 Jan 2016 14:43:00 +0000
Subject: [CMake] Setting target property FOLDER  on target ALL_BUILD
Message-ID: <af41f72484f44fdcbbc5682671e3cc2a@DE013815.schaeffler.com>

I would like to move the ALL_BUILD target tot he "CMakePredefinedTargets", however this seems not be possible straight away. At least even at the very end of the very last CMakeLists.txt I still cannot call

set_target_properties(ALL_BUILD
    PROPERTIES
    FOLDER " CMakePredefinedTargets ")

without getting an error that the target does not exist. Can it be done at all?

best regards,
Michael

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

From michael.stuermer at schaeffler.com  Fri Jan 29 10:43:02 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Fri, 29 Jan 2016 15:43:02 +0000
Subject: [CMake] Setting target property FOLDER  on target ALL_BUILD
In-Reply-To: <af41f72484f44fdcbbc5682671e3cc2a@DE013815.schaeffler.com>
References: <af41f72484f44fdcbbc5682671e3cc2a@DE013815.schaeffler.com>
Message-ID: <8f0df02a8c9449cdba4e556725d73025@DE013815.schaeffler.com>

>From cmGlobalVisualStudioGenerator.cxx (line 92ff):

#if 0
      // Can't activate this code because we want ALL_BUILD
      // selected as the default "startup project" when first
      // opened in Visual Studio... And if it's nested in a
      // folder, then that doesn't happen.
      //
      // Organize in the "predefined targets" folder:
      //
      if (this->UseFolderProperty())
        {
        allBuild->SetProperty("FOLDER", this->GetPredefinedTargetsFolder());
        }
#endif

Ok, this makes it pretty clear. But "we" don't want ALL_BUILD always to be selected as default "startup project". How about something like this:

      if (this->UseFolderProperty())
        {
        const char* prop = this->GetCMakeInstance()->GetState()
          ->GetGlobalProperty("ALL_BUILD_TARGET_FOLDER");
        if(prop)
          {
          allBuild->SetProperty("FOLDER", prop);
         }
        }

This would allow relocating the ALL_BUILD target, but it must be done explicitly using a new global property ALL_BUILD_TARGET_FOLDER.

If it's acceptable I'd submit a patch for this.

best regards,
Michael


From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP
Sent: Friday, January 29, 2016 3:43 PM
To: cmake at cmake.org
Subject: [CMake] Setting target property FOLDER on target ALL_BUILD

I would like to move the ALL_BUILD target tot he "CMakePredefinedTargets", however this seems not be possible straight away. At least even at the very end of the very last CMakeLists.txt I still cannot call

set_target_properties(ALL_BUILD
    PROPERTIES
    FOLDER " CMakePredefinedTargets ")

without getting an error that the target does not exist. Can it be done at all?

best regards,
Michael

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

From b95705030 at ntu.edu.tw  Fri Jan 29 13:04:26 2016
From: b95705030 at ntu.edu.tw (Yi-Hong Lyu)
Date: Sat, 30 Jan 2016 02:04:26 +0800
Subject: [CMake] Is there any way to use clang-cl with MSBuild on Windows?
Message-ID: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160130/cc30dd8b/attachment.html>

From nioncode at gmail.com  Fri Jan 29 14:13:46 2016
From: nioncode at gmail.com (Nicolas Schneider)
Date: Fri, 29 Jan 2016 20:13:46 +0100
Subject: [CMake] Execute command after project generation
Message-ID: <56ABB9EA.6080401@gmail.com>

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?

From bill.hoffman at kitware.com  Fri Jan 29 14:27:42 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Fri, 29 Jan 2016 14:27:42 -0500
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
Message-ID: <56ABBD2E.5020204@kitware.com>

On 1/29/2016 1:04 PM, Yi-Hong Lyu 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.
>
You could get it to work with ninja, make or nmake.  How does one 
normally force the VS IDE to use the clang compiler?

-Bill


From cristian.adam at gmail.com  Fri Jan 29 18:47:49 2016
From: cristian.adam at gmail.com (Cristian Adam)
Date: Sat, 30 Jan 2016 00:47:49 +0100
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
Message-ID: <56ABFA25.7070303@gmail.com>

On 29-Jan-16 19:04, Yi-Hong Lyu 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
>

I use clang-cl with ninja.  Open a Visual Studio 2013 command prompt 
window and then set:

$ set PATH=C:\Program Files (x86)\LLVM\msbuild-bin\;%PATH%
$ set INCLUDE=C:\Program Files (x86)\LLVM\lib\clang\3.7.0\include\;%INCLUDE%


The same can be done with Qt Creator and a cloned Visual C++ kit, but in 
the environment settings instead of %PATH% and %INCLUDE% use
$(PATH) and $(INCLUDE).

Cheers,
Cristian.

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

From nicholas11braden at gmail.com  Fri Jan 29 19:33:29 2016
From: nicholas11braden at gmail.com (Nicholas Braden)
Date: Fri, 29 Jan 2016 18:33:29 -0600
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
Message-ID: <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.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

From vadtec at vadtec.net  Sat Jan 30 21:42:32 2016
From: vadtec at vadtec.net (vadtec)
Date: Sat, 30 Jan 2016 20:42:32 -0600
Subject: [CMake] Help for a cmake newbie
Message-ID: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>

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


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

From rpf2116 at columbia.edu  Sat Jan 30 22:14:43 2016
From: rpf2116 at columbia.edu (Elizabeth Fischer)
Date: Sat, 30 Jan 2016 22:14:43 -0500
Subject: [CMake] Help for a cmake newbie
In-Reply-To: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
References: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
Message-ID: <CAC_jL3zq6twTt8qqsBWZJHw0bW9tmtHH7dGaAbb827G4XTQkZQ@mail.gmail.com>

I generally use one CMake build for compiling a single project.  Your
dependencies should be built separately from your main program.  Ways to do
this:

1. Try EasyBuild or Spack.  The only reason I wouldn't recommend them is
I'm not sure if they've ever been run on Windows.  But that doesn't mean it
wouldn't work.

2. Figure out how to compile all your prerequisites, and put them into a
single install tree.

Either way, it's unlikely that you'll be able to build the projects exactly
the same on the two systems.  Your goal should be a script that builds and
install the prerequisites in an appropriate way, taking into account system
differences.

-- Elizabeth


On Sat, Jan 30, 2016 at 9:42 PM, 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/20160130/16a0ee47/attachment.html>

From cristian.adam at gmail.com  Sun Jan 31 03:40:41 2016
From: cristian.adam at gmail.com (Cristian Adam)
Date: Sun, 31 Jan 2016 09:40:41 +0100
Subject: [CMake] Help for a cmake newbie
In-Reply-To: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
References: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
Message-ID: <56ADC889.8060807@gmail.com>

On 31-Jan-16 03:42, vadtec wrote:
>
> 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.
>

Have a look at hunter <https://github.com/ruslo/hunter/> ? 
Cross-platform package manager for C++ (based on CMake ExternalProject).

Hunter has CMake versions for:

  * libpng <https://github.com/ruslo/hunter/wiki/pkg.png>
  * libssh2 <https://github.com/ruslo/hunter/wiki/pkg.libssh2>
  * zlib <https://github.com/ruslo/hunter/wiki/pkg.zlib>

Curl <https://github.com/bagder/curl> has CMake support by itself. The 
only library missing is libiconv. It seems that
LuaDist project has added  a CMake build here 
<https://github.com/LuaDist/libiconv>.

You could either take all the libraries and include in your project or 
open hunter tickets. <https://github.com/ruslo/hunter/issues>

Cheers,
Cristian.

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

From tamas.kenez at gmail.com  Sun Jan 31 09:08:05 2016
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Sun, 31 Jan 2016 15:08:05 +0100
Subject: [CMake] Help for a cmake newbie
In-Reply-To: <56ADC889.8060807@gmail.com>
References: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
 <56ADC889.8060807@gmail.com>
Message-ID: <CAPB8=n-wHhJSycS3a03UQfHaAHTiYaxdBS3vjvor1uhjVYw1KQ@mail.gmail.com>

Vadtec,

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

I'll answer the question of finding the libraries and not the building
problem. We (in my company) are facing similar problems. This is the
workflow which has been working for us:

1. we make sure that all 3rdparty dependencies can be built with CMake and
install a config-module

Note that the "can be built with CMake" needs to be interpreted loosely:

- some 3rdparty libs already provide CMake builds which can be used as is.
In case of anything is missing (config-module) we fork and modify
- when a 3rdparty lib uses autotools we rewrite its build system in CMake
for windows compatibility
- in case the lib's build system is too complex we just wrap it in a CMake
build which launches autotools and also installs a config-module
- when only the binaries of the 3rdparty lib are available we create a
CMakeLists for the lib which detects the platform, installs the required
binaries and config-modules

In any case we end up having a project that can be built with cmake command
lines and installs a proper config-module.

2. For these 3rdparty libs we don't use the find-modules distributed with
CMake. We Set the CMAKE_PREFIX_PATH to the install prefix where we
installed our 3rdparty deps to make sure only those will be found by our
own projects.

On Sun, Jan 31, 2016 at 9:40 AM, Cristian Adam <cristian.adam at gmail.com>
wrote:

> On 31-Jan-16 03:42, vadtec wrote:
>
>
> 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.
>
>
> Have a look at hunter <https://github.com/ruslo/hunter/> ? Cross-platform
> package manager for C++ (based on CMake ExternalProject).
>
> Hunter has CMake versions for:
>
>    - libpng <https://github.com/ruslo/hunter/wiki/pkg.png>
>    - libssh2 <https://github.com/ruslo/hunter/wiki/pkg.libssh2>
>    - zlib <https://github.com/ruslo/hunter/wiki/pkg.zlib>
>
> Curl <https://github.com/bagder/curl> has CMake support by itself. The
> only library missing is libiconv. It seems that
> LuaDist project has added  a CMake build here
> <https://github.com/LuaDist/libiconv>.
>
> You could either take all the libraries and include in your project or
> open hunter tickets. <https://github.com/ruslo/hunter/issues>
>
> Cheers,
> Cristian.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20160131/d24bbcb2/attachment.html>

From h2+lists2016 at fsfe.org  Sun Jan 31 09:21:55 2016
From: h2+lists2016 at fsfe.org (Hannes Hauswedell)
Date: Sun, 31 Jan 2016 15:21:55 +0100
Subject: [CMake] CheckLibraryExists requires C Compiler
Message-ID: <56AE1883.2090907@fsfe.org>

Dear CMake-Hackers,

I have a project which is purely C++. We have recently switched from

project (FOO)

to

project (FOO CXX)

so that we don't depend on CMAKE_C_COMPILER being set. This has broken
our BZip2 detection:

-- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so (found version "1.0.6")
-- Looking for BZ2_bzCompressInit in /usr/lib/x86_64-linux-gnu/libbz2.so
CMake Error at /usr/share/cmake-3.0/Modules/CheckLibraryExists.cmake:52
(try_compile):
  Unknown extension ".c" for file

    /usr/share/cmake-3.0/Modules/CheckFunctionExists.c

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

    CXX

  See project() command to enable other languages.
Call Stack (most recent call first):
  /usr/share/cmake-3.0/Modules/FindBZip2.cmake:60 (CHECK_LIBRARY_EXISTS)

Note that this is fixed in cmake-3.4 by
https://github.com/Kitware/CMake/commit/23876eda9f1d4b5725407aef7d218fc3ce4113cb
because the CheckLibraryExists is removed. However I depend on shipping
the software on platforms with cmake>=3.0 so this doesn't help.

I have tried to set
SET_SOURCE_FILES_PROPERTIES(CheckFunctionExists.c PROPERTIES LANGUAGE CXX)
but this doesn't help, either.

Is there any workaround for this problem?

And isn't requiring C_COMPILER in CheckLibraryExists a bug? IMHO it
should check CMAKE_C_COMPILER_LOADED and use cxx otherwise...

Thank you for your help!
-- 
Best regards,
Hannes Hauswedell
Free Software Foundation Europe -- German Team

pgp-key:
https://blogs.fsfe.org/h2/files/2015/09/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF

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

From mjsurette at gmail.com  Sun Jan 31 12:47:03 2016
From: mjsurette at gmail.com (Michael Surette)
Date: Sun, 31 Jan 2016 12:47:03 -0500
Subject: [CMake] Help for a cmake newbie
In-Reply-To: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
References: <152958f75a7.d2fbb67a132248.5271304616753456549@vadtec.net>
Message-ID: <n8lhao$7dv$1@ger.gmane.org>

On 30/01/16 09:42 PM, vadtec 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.
...
 > Any help is greatly appreciated.
 >
 > ------------------------------------------------------------------------
 > Vadtec
 > vadtec at vadtec.net
 >
 >
Check out how it's done with FLTK at fltk.org.

We put each dependency in its own folder with its own CMakeLists.txt 
then do an add_subdirectory for each. The add_subdirectory calls are 
dependent on whether that particular library is available as a system 
library and if so which you want to build with.

I'm sure you could adapt this to your purpose.

Mike



From mjsurette at gmail.com  Sun Jan 31 13:09:33 2016
From: mjsurette at gmail.com (Michael Surette)
Date: Sun, 31 Jan 2016 13:09:33 -0500
Subject: [CMake] include_directories question
Message-ID: <n8liku$qku$1@ger.gmane.org>

I have the following CMakeLists file which builds one of the examples in 
FLTK as a separate project.

---
cmake_minimum_required(VERSION 2.6)

project(CubeView)

set(FLTK_DIR /home/msurette/build/fltk-release/)

find_package(FLTK REQUIRED NO_MODULE)
include(${FLTK_USE_FILE})

#run fluid -c to generate cxx and h files
add_custom_command(
	OUTPUT "CubeViewUI.cxx" "CubeViewUI.h"
	COMMAND fluid -c ${CMAKE_CURRENT_SOURCE_DIR}/CubeViewUI.fl
)

include_directories(${CMAKE_BINARY_DIR})
include_directories(${CMAKE_SOURCE_DIR})
add_executable(CubeView WIN32 CubeMain.cxx  CubeView.cxx  CubeViewUI.cxx)

target_link_libraries(CubeView fltk fltk_gl)
---

It works well, but not without the two include_directories commands.

Could someone please explain to me why they are necessary,

Seeing as the custom command deposits its results in CMAKE_BINARY_DIR I 
would expect it to be searched for source and header files.

CMAKE_SOURCE_DIR should always be searched for source and header files, 
shouldn't it?

Mike


From b95705030 at ntu.edu.tw  Sun Jan 31 13:47:58 2016
From: b95705030 at ntu.edu.tw (Yi-Hong Lyu)
Date: Mon, 1 Feb 2016 02:47:58 +0800
Subject: [CMake] Is there any way to use clang-cl with MSBuild on
	Windows?
In-Reply-To: <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
References: <CAH1oQ8oHo=eH5mxZiE5GPTC2pb4BEXU1vfJRBec5GK8QLA3p9g@mail.gmail.com>
 <CAHk1PgGOyKmcEqGY_oC-mHLHmQdZYCGETSwAa6VKzReiyc+g=w@mail.gmail.com>
Message-ID: <CAH1oQ8rr9GdrnEBZfmq6YnJZ0eibeCfMEQSWZeFpxY2gZKWjHg@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160201/3b13c1db/attachment.html>

From audiofanatic at gmail.com  Sun Jan 31 22:52:43 2016
From: audiofanatic at gmail.com (Craig Scott)
Date: Mon, 1 Feb 2016 14:52:43 +1100
Subject: [CMake] Using ccache with Xcode generator
Message-ID: <CACQP5Ucjbt6V2BATxvu1wkcABCit1hXB+=vtK=Xgy6CtddA2LQ@mail.gmail.com>

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?

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