From quang.t.ha.20 at gmail.com  Wed Aug  1 00:32:25 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Tue, 31 Jul 2018 22:32:25 -0600
Subject: [CMake] ctest to output files
Message-ID: <CAGfE9+MAuym92QsThaW7i+Y7e6Y+zzhp3UZOcROw3CyPoF1S+Q@mail.gmail.com>

Hi all,

Is there a way to let ctest create an output file after a certain test? Say
I want to run test 1 (name "run_simulation"), which is a simulation and
should produce an output file containing numerical results. I then want to
compare it against analytical results in test 2 (name "compare_results")?

Thanks,
QT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180731/dec49e3a/attachment.html>

From domen.vrankar at gmail.com  Wed Aug  1 01:28:42 2018
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Wed, 1 Aug 2018 07:28:42 +0200
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <b192f4b9-42aa-7137-361c-cf1b95e6047f@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <1549AA90-9773-45C9-A5E1-650B8DE5D623@gmail.com>
 <b192f4b9-42aa-7137-361c-cf1b95e6047f@gmail.com>
Message-ID: <CAKgx6BK=G-oUJbf9A5gaW=kJsadPizKNs6r2FWCMyvNKrtx3kw@mail.gmail.com>

On Wed, Aug 1, 2018, 03:46 CrestChristopher <crestchristopher at gmail.com>
wrote:

> Hi, I'm using CMake for Windows as I was informed that I couldn't use
> `make` as the CMakeLists.txt file was only for CMake.
>

CMake is a meta build system which means that on for example Linux it
henerates make fliles so CMakeLists.txt should be run with cmake to
generate those make files and then you run make in the build directory.

On Windows you usually use visual studio so cmake generates build and
project files for it there.

Not use make and use cmake instead in this case means that you should use
cmake to generate build files with cmake and not change generated build
files by hand. It doesn't mean that after running cmake you shouldn't run
make on those generated files if they were generated for make.

Within CMake for Windows I select the location of the source code which
> is the cloned repository which include the CMakeLists.txt file that I
> want to compile, followed by I select a folder where to build the
> binaries; I'm then prompt for a generator for the project. Up to this
> point am I doing this correctly ?
>

Michael already answered for you how to build it from command line on all
platforms (on Linux you can also use 'make' directly instead of running
'cmake - build'). If you selected to generate files for Visual Studio cmake
also generated vs project file so you can open it in ide and run build
there instead.

Hope this clarifies things a bit more.

Regards,
Domen

On 7/31/2018 12:56 PM, Michael Ellery wrote:
> > mkdir mybuild && cd mybuild
> > cmake -DCMAKE_BUILD_TYPE=Release ..
> > cmake ?build .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180801/701485b6/attachment.html>

From robert.maynard at kitware.com  Wed Aug  1 08:42:02 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 1 Aug 2018 08:42:02 -0400
Subject: [CMake] ctest to output files
In-Reply-To: <CAGfE9+MAuym92QsThaW7i+Y7e6Y+zzhp3UZOcROw3CyPoF1S+Q@mail.gmail.com>
References: <CAGfE9+MAuym92QsThaW7i+Y7e6Y+zzhp3UZOcROw3CyPoF1S+Q@mail.gmail.com>
Message-ID: <CAFzjYVoawfFfgYxMTz22pSsL2nRiBzwjY6Wt4LjHUhdX=TjDNw@mail.gmail.com>

I would look at use the FIXTURES features to define the file as a
shared resource. Here is a good article on how to use this feature:

https://crascit.com/2016/10/18/test-fixtures-with-cmake-ctest/
On Wed, Aug 1, 2018 at 12:32 AM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>
> Hi all,
>
> Is there a way to let ctest create an output file after a certain test? Say I want to run test 1 (name "run_simulation"), which is a simulation and should produce an output file containing numerical results. I then want to compare it against analytical results in test 2 (name "compare_results")?
>
> Thanks,
> QT
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From andrew.bell.ia at gmail.com  Wed Aug  1 09:05:53 2018
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Wed, 1 Aug 2018 09:05:53 -0400
Subject: [CMake] ctest to output files
In-Reply-To: <CAGfE9+MAuym92QsThaW7i+Y7e6Y+zzhp3UZOcROw3CyPoF1S+Q@mail.gmail.com>
References: <CAGfE9+MAuym92QsThaW7i+Y7e6Y+zzhp3UZOcROw3CyPoF1S+Q@mail.gmail.com>
Message-ID: <CACJ51z3YkxTBE90_s2+g7=Pf=0mC6obzNs0-aYXuUrQKVE=8oQ@mail.gmail.com>

We do this in a single test, where the test calls some function like
"compare_results".

On Wed, Aug 1, 2018 at 12:32 AM, Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> Hi all,
>
> Is there a way to let ctest create an output file after a certain test?
> Say I want to run test 1 (name "run_simulation"), which is a simulation and
> should produce an output file containing numerical results. I then want to
> compare it against analytical results in test 2 (name "compare_results")?
>
> Thanks,
> QT
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>


-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180801/ec74ada4/attachment.html>

From mellery451 at gmail.com  Wed Aug  1 11:15:18 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Wed, 1 Aug 2018 08:15:18 -0700
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <b192f4b9-42aa-7137-361c-cf1b95e6047f@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <1549AA90-9773-45C9-A5E1-650B8DE5D623@gmail.com>
 <b192f4b9-42aa-7137-361c-cf1b95e6047f@gmail.com>
Message-ID: <ECE9945F-31ED-4077-824B-ACEA6EF22256@gmail.com>

So it sounds like you are on windows. First, be sure that the project that you are building claims support for windows. Windows is still the ?odd man out? platform in many cases, so you don?t want to chase your tail with a project that never claimed windows support in the first place. That said, assuming windows is a supported build env, then it further sounds like you are using cmake-gui.

The most sensible generator is one of the visual studio ones - 64 or 32 bit depending on your needs. Once you have generated a project with cmake, you then open that generated project with VS.

Alternatively, however, I?d also suggest you consider just using the built-in CMake support in Visual Studio. If you download the latest version of VS (even the community version), then you can just open a CMakeLIsts.txt file directly and VS will run the generation step for you. It works pretty well in my limited experience. It can a little tricky to figure out how to set some non-default options in this workflow, but that?s more advanced usage anyhow.

-Mike


> On Jul 31, 2018, at 6:46 PM, CrestChristopher <crestchristopher at gmail.com> wrote:
> 
> Hi, I'm using CMake for Windows as I was informed that I couldn't use `make` as the CMakeLists.txt file was only for CMake.
> 
> Within CMake for Windows I select the location of the source code which is the cloned repository which include the CMakeLists.txt file that I want to compile, followed by I select a folder where to build the binaries; I'm then prompt for a generator for the project. Up to this point am I doing this correctly ?
> 
> Thank You
> 
> 
> 
> 
> On 7/31/2018 12:56 PM, Michael Ellery wrote:
>> typical usage would be something like (assuming you are at repo root) :
>> 
>> mkdir mybuild && cd mybuild
>> cmake -DCMAKE_BUILD_TYPE=Release ..
>> cmake ?build .
>> 
>> you can also opt to configure cmake (the equivalent of the first cmake command above) using a GUI like ccmake or cmake-gui if you prefer. The cmake build type can be changed depending on your needs. If the project depends on other libraries/tools, you might need to install those before building.
>> 
>> HTH,
>> Mike
>> 
>>> On Jul 30, 2018, at 9:17 PM, CrestChristopher <crestchristopher at gmail.com> wrote:
>>> 
>>> Hi, I'm a beginner to CMake and for weeks I've been trying to compile a CMake file which I found on a github repository.  All I can say is I have a CMakeLists.txt file but I don't know how to compile and I hope someone can help ?
>>> 
>>> Christopher
>>> 
>>> --
>>> 
>>> Powered by www.kitware.com
>>> 
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>> 
>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>> 
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>> 
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20180801/2b1fb235/attachment.sig>

From volker.enderlein at ifm-chemnitz.de  Wed Aug  1 17:20:46 2018
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Wed, 1 Aug 2018 23:20:46 +0200
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
Message-ID: <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>

Am 31.07.2018 um 06:17 schrieb CrestChristopher:
> Hi, I'm a beginner to CMake and for weeks I've been trying to compile a 
> CMake file which I found on a github repository.? All I can say is I 
> have a CMakeLists.txt file but I don't know how to compile and I hope 
> someone can help ?
> 
> Christopher
> 
You may want to include information about the name and the link to the 
project repository from Github to get the best possible responses. 
Without that it's just shooting in the dark.

Cheers Volker


From mario at emmenlauer.de  Thu Aug  2 07:58:17 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Thu, 2 Aug 2018 13:58:17 +0200
Subject: [CMake] order of includes seems wrong (or please help me
 understand)
In-Reply-To: <CAFzjYVpTodzxoQ0R4_F3xAmcqH43UWx2yZBKD3+Wu4GNZDw8Qw@mail.gmail.com>
References: <13ec3e40-afdc-0980-62c9-8095e36b211c@emmenlauer.de>
 <9ab4f86e-1466-67fc-efb3-ab85df58033e@emmenlauer.de>
 <CAFzjYVpTodzxoQ0R4_F3xAmcqH43UWx2yZBKD3+Wu4GNZDw8Qw@mail.gmail.com>
Message-ID: <6e258d74-d9f4-f219-e626-a32fda81c04e@emmenlauer.de>


Dear Robert,

On 31.07.2018 15:04, Robert Maynard wrote:
> The BEFORE keyword places the includes before any other paths such as
> ones from other target_include_directories statements or from
> transitive propagation from targets you linked too.
> 
> As to why `CMAKE_PREFIX_PATH` is being added, I expect that some find
> call is bring it in as an include directory.
> On Mon, Jul 30, 2018 at 5:43 PM Mario Emmenlauer <mario at emmenlauer.de> wrote:

I would like to understand why `CMAKE_PREFIX_PATH` is in second position
of includes. I add ${CMAKE_CURRENT_SOURCE_DIR}/include before. Are you
saying that find_package() is modifying the includes directly, like by
calling include_directories()? That would be pretty bad!

I am rather under the assumption that target_link_libraries() is changing
the order of includes.

All the best,

   Mario



>>
>> Should I report this as a bug or am I just doing something wrong?
>> Help would be greatly appreciated!
>>
>> All the best,
>>
>>     Mario
>>
>>
>> On 26.07.2018 11:58, Mario Emmenlauer wrote:
>>>
>>> Dear CMake users and developers,
>>>
>>> I've just discovered a build problem that comes from a wrong order of
>>> includes. I would know the correct order, but I am unable to instruct
>>> CMake to use the order I need.
>>>
>>> Here is a toy example that I tested with cmake 3.12.0:
>>>
>>>
>>> ----
>>> cmake_minimum_required(VERSION 3.8)
>>> project(MyLib VERSION 1.0.0)
>>> find_package(XXX REQUIRED)
>>> find_package(YYY REQUIRED)
>>> add_library(${PROJECT_NAME} include/MyLib.hh src/MyLib.cc)
>>> target_include_directories(${PROJECT_NAME}
>>>     PRIVATE
>>>         ${CMAKE_CURRENT_SOURCE_DIR}/src
>>>         ${CMAKE_CURRENT_BINARY_DIR}
>>>     PUBLIC
>>>         $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
>>>         $<INSTALL_INTERFACE:include>
>>>         ${XXX_INCLUDE_DIRS} ${YYY_INCLUDE_DIRS})
>>> target_link_libraries(MyLib PUBLIC ${XXX_LIBRARIES} ${YYY_LIBRARIES})
>>> # here come more commands for build flags etc.
>>>
>>> enable_testing()
>>> add_executable(MyTest test/src/MyTest.cc test/src/MyTest.hh)
>>> target_include_directories(MyTest PRIVATE
>>>     ${CMAKE_CURRENT_SOURCE_DIR}/include
>>>     ${CMAKE_CURRENT_SOURCE_DIR}/test/src
>>>     ${CMAKE_CURRENT_SOURCE_DIR}/src
>>>     ${CMAKE_CURRENT_BINARY_DIR}
>>>     ${GTEST_INCLUDE_DIRS})
>>> target_link_libraries(MyTest PRIVATE MyLib ${GTEST_MAIN_LIBRARIES})
>>> # here come more commands for build flags etc.
>>> ----
>>>
>>>
>>> I configure cmake with -DCMAKE_PREFIX_PATH=${MY_PREFIX_PATH}. When
>>> I build the project, the order of includes for MyLib is fine. But
>>> for MyTest, the following are the first two includes:
>>>    -IMyTest_autogen/include
>>>    -I${MY_PREFIX_PATH}/include
>>>
>>> I think the second include should come much later, only *after*
>>> ${CMAKE_CURRENT_SOURCE_DIR}/include, but it comes before. Therefore,
>>> if older headers exists in ${MY_PREFIX_PATH}/include, they will be
>>> used instead of ${CMAKE_CURRENT_SOURCE_DIR}/include!
>>>
>>> I found that I can fix the problem by adding 'BEFORE' to all
>>> target_include_directories(). However I'm puzzled why this helps.
>>> Before anything I call target_include_directories(), and before other
>>> includes I have ${CMAKE_CURRENT_SOURCE_DIR}/src,
>>> ${CMAKE_CURRENT_BINARY_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}/include.
>>> So what does 'BEFORE' mean in this case? Aren't these the first
>>> includes any ways?
>>>
>>> Thanks for any help, and Cheers,
>>>
>>>     Mario Emmenlauer
>>
>>
>>
>> Viele Gruesse,
>>
>>     Mario Emmenlauer
>>
>>
>> --
>> BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
>> Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
>> D-81669 M?nchen                          http://www.biodataanalysis.de/
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
> 



Viele Gruesse,

    Mario Emmenlauer


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

From robert.maynard at kitware.com  Thu Aug  2 08:37:36 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 2 Aug 2018 08:37:36 -0400
Subject: [CMake] order of includes seems wrong (or please help me
 understand)
In-Reply-To: <6e258d74-d9f4-f219-e626-a32fda81c04e@emmenlauer.de>
References: <13ec3e40-afdc-0980-62c9-8095e36b211c@emmenlauer.de>
 <9ab4f86e-1466-67fc-efb3-ab85df58033e@emmenlauer.de>
 <CAFzjYVpTodzxoQ0R4_F3xAmcqH43UWx2yZBKD3+Wu4GNZDw8Qw@mail.gmail.com>
 <6e258d74-d9f4-f219-e626-a32fda81c04e@emmenlauer.de>
Message-ID: <CAFzjYVpqO++aZD1LPs2wBJUrYgwujEf3FggpnsoY6J_JE+rQug@mail.gmail.com>

While the find modules that CMake provide don't use
include_directories some externally written find module you are using
could.

You really need to provide a standalone reproduction of the problem,
as currently people can only speculate on what is occurring.
On Thu, Aug 2, 2018 at 7:58 AM Mario Emmenlauer <mario at emmenlauer.de> wrote:
>
>
> Dear Robert,
>
> On 31.07.2018 15:04, Robert Maynard wrote:
> > The BEFORE keyword places the includes before any other paths such as
> > ones from other target_include_directories statements or from
> > transitive propagation from targets you linked too.
> >
> > As to why `CMAKE_PREFIX_PATH` is being added, I expect that some find
> > call is bring it in as an include directory.
> > On Mon, Jul 30, 2018 at 5:43 PM Mario Emmenlauer <mario at emmenlauer.de> wrote:
>
> I would like to understand why `CMAKE_PREFIX_PATH` is in second position
> of includes. I add ${CMAKE_CURRENT_SOURCE_DIR}/include before. Are you
> saying that find_package() is modifying the includes directly, like by
> calling include_directories()? That would be pretty bad!
>
> I am rather under the assumption that target_link_libraries() is changing
> the order of includes.
>
> All the best,
>
>    Mario
>
>
>
> >>
> >> Should I report this as a bug or am I just doing something wrong?
> >> Help would be greatly appreciated!
> >>
> >> All the best,
> >>
> >>     Mario
> >>
> >>
> >> On 26.07.2018 11:58, Mario Emmenlauer wrote:
> >>>
> >>> Dear CMake users and developers,
> >>>
> >>> I've just discovered a build problem that comes from a wrong order of
> >>> includes. I would know the correct order, but I am unable to instruct
> >>> CMake to use the order I need.
> >>>
> >>> Here is a toy example that I tested with cmake 3.12.0:
> >>>
> >>>
> >>> ----
> >>> cmake_minimum_required(VERSION 3.8)
> >>> project(MyLib VERSION 1.0.0)
> >>> find_package(XXX REQUIRED)
> >>> find_package(YYY REQUIRED)
> >>> add_library(${PROJECT_NAME} include/MyLib.hh src/MyLib.cc)
> >>> target_include_directories(${PROJECT_NAME}
> >>>     PRIVATE
> >>>         ${CMAKE_CURRENT_SOURCE_DIR}/src
> >>>         ${CMAKE_CURRENT_BINARY_DIR}
> >>>     PUBLIC
> >>>         $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
> >>>         $<INSTALL_INTERFACE:include>
> >>>         ${XXX_INCLUDE_DIRS} ${YYY_INCLUDE_DIRS})
> >>> target_link_libraries(MyLib PUBLIC ${XXX_LIBRARIES} ${YYY_LIBRARIES})
> >>> # here come more commands for build flags etc.
> >>>
> >>> enable_testing()
> >>> add_executable(MyTest test/src/MyTest.cc test/src/MyTest.hh)
> >>> target_include_directories(MyTest PRIVATE
> >>>     ${CMAKE_CURRENT_SOURCE_DIR}/include
> >>>     ${CMAKE_CURRENT_SOURCE_DIR}/test/src
> >>>     ${CMAKE_CURRENT_SOURCE_DIR}/src
> >>>     ${CMAKE_CURRENT_BINARY_DIR}
> >>>     ${GTEST_INCLUDE_DIRS})
> >>> target_link_libraries(MyTest PRIVATE MyLib ${GTEST_MAIN_LIBRARIES})
> >>> # here come more commands for build flags etc.
> >>> ----
> >>>
> >>>
> >>> I configure cmake with -DCMAKE_PREFIX_PATH=${MY_PREFIX_PATH}. When
> >>> I build the project, the order of includes for MyLib is fine. But
> >>> for MyTest, the following are the first two includes:
> >>>    -IMyTest_autogen/include
> >>>    -I${MY_PREFIX_PATH}/include
> >>>
> >>> I think the second include should come much later, only *after*
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/include, but it comes before. Therefore,
> >>> if older headers exists in ${MY_PREFIX_PATH}/include, they will be
> >>> used instead of ${CMAKE_CURRENT_SOURCE_DIR}/include!
> >>>
> >>> I found that I can fix the problem by adding 'BEFORE' to all
> >>> target_include_directories(). However I'm puzzled why this helps.
> >>> Before anything I call target_include_directories(), and before other
> >>> includes I have ${CMAKE_CURRENT_SOURCE_DIR}/src,
> >>> ${CMAKE_CURRENT_BINARY_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}/include.
> >>> So what does 'BEFORE' mean in this case? Aren't these the first
> >>> includes any ways?
> >>>
> >>> Thanks for any help, and Cheers,
> >>>
> >>>     Mario Emmenlauer
> >>
> >>
> >>
> >> Viele Gruesse,
> >>
> >>     Mario Emmenlauer
> >>
> >>
> >> --
> >> BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
> >> Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
> >> D-81669 M?nchen                          http://www.biodataanalysis.de/
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://cmake.org/mailman/listinfo/cmake
> >
>
>
>
> Viele Gruesse,
>
>     Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
> Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
> D-81669 M?nchen                          http://www.biodataanalysis.de/

From crestchristopher at gmail.com  Thu Aug  2 09:07:26 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Thu, 2 Aug 2018 09:07:26 -0400
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <ECE9945F-31ED-4077-824B-ACEA6EF22256@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <1549AA90-9773-45C9-A5E1-650B8DE5D623@gmail.com>
 <b192f4b9-42aa-7137-361c-cf1b95e6047f@gmail.com>
 <ECE9945F-31ED-4077-824B-ACEA6EF22256@gmail.com>
Message-ID: <4a177e35-eb77-4c5b-7933-262bdc452bed@gmail.com>

How can I verify whether what I want to built claims support for Windows ?


On 8/1/2018 11:15 AM, Michael Ellery wrote:
> So it sounds like you are on windows. First, be sure that the project that you are building claims support for windows. Windows is still the ?odd man out? platform in many cases, so you don?t want to chase your tail with a project that never claimed windows support in the first place. That said, assuming windows is a supported build env, then it further sounds like you are using cmake-gui.
>
> The most sensible generator is one of the visual studio ones - 64 or 32 bit depending on your needs. Once you have generated a project with cmake, you then open that generated project with VS.
>
> Alternatively, however, I?d also suggest you consider just using the built-in CMake support in Visual Studio. If you download the latest version of VS (even the community version), then you can just open a CMakeLIsts.txt file directly and VS will run the generation step for you. It works pretty well in my limited experience. It can a little tricky to figure out how to set some non-default options in this workflow, but that?s more advanced usage anyhow.
>
> -Mike
>
>
>> On Jul 31, 2018, at 6:46 PM, CrestChristopher<crestchristopher at gmail.com>  wrote:
>>
>> Hi, I'm using CMake for Windows as I was informed that I couldn't use `make` as the CMakeLists.txt file was only for CMake.
>>
>> Within CMake for Windows I select the location of the source code which is the cloned repository which include the CMakeLists.txt file that I want to compile, followed by I select a folder where to build the binaries; I'm then prompt for a generator for the project. Up to this point am I doing this correctly ?
>>
>> Thank You
>>
>>
>>
>>
>> On 7/31/2018 12:56 PM, Michael Ellery wrote:
>>> typical usage would be something like (assuming you are at repo root) :
>>>
>>> mkdir mybuild && cd mybuild
>>> cmake -DCMAKE_BUILD_TYPE=Release ..
>>> cmake ?build .
>>>
>>> you can also opt to configure cmake (the equivalent of the first cmake command above) using a GUI like ccmake or cmake-gui if you prefer. The cmake build type can be changed depending on your needs. If the project depends on other libraries/tools, you might need to install those before building.
>>>
>>> HTH,
>>> Mike
>>>
>>>> On Jul 30, 2018, at 9:17 PM, CrestChristopher<crestchristopher at gmail.com>  wrote:
>>>>
>>>> Hi, I'm a beginner to CMake and for weeks I've been trying to compile a CMake file which I found on a github repository.  All I can say is I have a CMakeLists.txt file but I don't know how to compile and I hope someone can help ?
>>>>
>>>> Christopher
>>>>
>>>> --
>>>>
>>>> Powered bywww.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>>
>>>> CMake Support:http://cmake.org/cmake/help/support.html
>>>> CMake Consulting:http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses:http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects athttp://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/02fb50ea/attachment-0001.html>

From crestchristopher at gmail.com  Thu Aug  2 09:18:41 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Thu, 2 Aug 2018 09:18:41 -0400
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
Message-ID: <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>

I hope this helps; 
https://github.com/imageworks/OpenShadingLanguage/pull/824 ?


On 8/1/2018 5:20 PM, Volker Enderlein wrote:
> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>> Hi, I'm a beginner to CMake and for weeks I've been trying to compile 
>> a CMake file which I found on a github repository.? All I can say is 
>> I have a CMakeLists.txt file but I don't know how to compile and I 
>> hope someone can help ?
>>
>> Christopher
>>
> You may want to include information about the name and the link to the 
> project repository from Github to get the best possible responses. 
> Without that it's just shooting in the dark.
>
> Cheers Volker
>


From sd at syntonetic.com  Thu Aug  2 09:24:42 2018
From: sd at syntonetic.com (=?UTF-8?B?U8O4cmVu?=)
Date: Thu, 2 Aug 2018 15:24:42 +0200
Subject: [CMake] Can't find boost libs on VS2017 CMake 3.12
Message-ID: <5beefc68-c81f-06ae-3ce5-f5ced37f2f13@syntonetic.com>

Dear cmake community

I can't make CMake find the built boost libraries on Windows. At this line:

 ??? find_package(Boost REQUIRED COMPONENTS thread)

I get this error message:
"Unable to find the requested Boost libraries.

 ? Boost version: 1.67.0

 ? Boost include path: C:/download/boost/boost_1_67_0

 ? Could not find the following static Boost libraries:

 ????????? boost_thread

 ? Some (but not all) of the required Boost libraries were found. You may
 ? need to install these additional Boost libraries.? Alternatively, set
 ? BOOST_LIBRARYDIR to the directory containing Boost libraries or 
BOOST_ROOT
 ? to the location of Boost."

Other facts and observations:
* Error both observed with stand alone Cmake 3.12, and the version cmake 
3.11 that ships with VS2017.
* VS2017 version 15.7.5 (currently the latest)
* The same error with older Boost versions 1.65.x or 1.66
* Building and linking the same program using VS2017 without cmake works 
fine.
* It's not only threat that has the problem. Tested also date_time and 
chrono with same errors.
* Building a program with cmake that only requires boost 
headers-only-libs works fine.
* Building the same project on linux works fine.

Any ideas?
Thanks in advance
Soren


From volker.enderlein at ifm-chemnitz.de  Thu Aug  2 09:30:37 2018
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Thu, 2 Aug 2018 15:30:37 +0200
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
 <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
Message-ID: <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>

Please have a look into the appveyor.yml file under section 
build_script: you see the typical invocation of cmake for this github 
project.

Cheers Volker

Am 02/08/2018 um 15:18 schrieb CrestChristopher:
> I hope this helps; 
> https://github.com/imageworks/OpenShadingLanguage/pull/824 ?
>
>
> On 8/1/2018 5:20 PM, Volker Enderlein wrote:
>> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>>> Hi, I'm a beginner to CMake and for weeks I've been trying to 
>>> compile a CMake file which I found on a github repository.? All I 
>>> can say is I have a CMakeLists.txt file but I don't know how to 
>>> compile and I hope someone can help ?
>>>
>>> Christopher
>>>
>> You may want to include information about the name and the link to 
>> the project repository from Github to get the best possible 
>> responses. Without that it's just shooting in the dark.
>>
>> Cheers Volker
>>
>

-- 
Volker Enderlein                         Institut f?r Mechatronik e.V.
Phone: +49 (0)371 531 19651              Reichenhainer Strasse 88
Fax:   +49 (0)371 531 19699              D-09126 Chemnitz
Mail: volker.enderlein at ifm-chemnitz.de   www.ifm-chemnitz.de

Vorstand:
Prof. Dr.-Ing. Welf-Guntram Drossel (Vorsitz)
Dipl.-Ing. Heiko Freudenberg (Gesch?ftsf?hrer)

Amtsgericht Chemnitz VR 713
Ust.-IdNr. DE 159285348


From randy.heiland at gmail.com  Thu Aug  2 10:01:39 2018
From: randy.heiland at gmail.com (Randy Heiland)
Date: Thu, 2 Aug 2018 10:01:39 -0400
Subject: [CMake] simple find_package example
Message-ID: <CAO_spu5nvHMVow2=Bt8nrTLsHZPgq1X_psjNy7fb5Q0hriMU8w@mail.gmail.com>

Hi,

I'd like to figure out how to modify the simple "hello" demo (
https://cmake.org/examples/) so that the Hello project is a library with an
accompanying FindHello.cmake and then the Demo project uses that
information and "find_package" to discover/use it.

Hopefully that makes sense. Basically, I'm looking for a simple tutorial on
how I can make my library easily accessible to a CMake project. Fwiw, my
library is not (currently) built with CMake.

thanks for suggestions,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/375b2be1/attachment.html>

From rubendibattista at gmail.com  Thu Aug  2 15:03:43 2018
From: rubendibattista at gmail.com (Ruben Di Battista)
Date: Thu, 2 Aug 2018 21:03:43 +0200
Subject: [CMake] LD_LIBRARY_PATH not used by the linker
Message-ID: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>

Hello,
I'm running cmake on a system where I have module-loaded software such that
`LD_LIBRARY_PATH` gets populated by the module (actually I'm using Lmod)
function.

In my project, I have a dependency on VTK, and VTK could be compiled with
Python wrapping.

This is what I have in my main CMakeFiles.txt

project(HG)
set(HG_VERSION MAJOR 0)
set(HG_VERSION MINOR 1)

# We use VTK extensively
find_package(VTK REQUIRED)
include(${VTK_USE_FILE})


add_subdirectory(src)

# :: Tests ::
set(BUILD_TESTS FALSE CACHE BOOL "Set this to TRUE if you want to build and
\
    run the tests ")

if(BUILD_TESTS)
    # We use catch2 for tests
    find_package(Catch2 QUIET
        HINTS
        "${CMAKE_BINARY_DIR}/third_party"
        )

    if(NOT Catch2_FOUND)
        message(WARNING "Catch2 was not found in the system. \
        It will be downloaded from its git repository and installed")

        # Bootstrap Catch2
        include(DownloadCatch2)

        # Try again
        find_package(Catch2 REQUIRED)
    endif(NOT Catch2_FOUND)

    enable_testing()
    add_subdirectory(tests)

endif(BUILD_TESTS)

In the `tests` directory I have:

set(TEST_TARGET "test_${PROJECT_NAME}")

# find_package(PythonInterp REQUIRED)
# find_package(PythonLibs REQUIRED)
# message(FATAL_ERROR ${PYTHON_LIBRARIES})

# Generate test executable
add_executable(${TEST_TARGET}
    test_hg.cxx
    test_polydata_wrapper.cxx)
target_link_libraries(${TEST_TARGET} ${PROJECT_NAME} Catch2::Catch2
${VTK_LIBRARIES})

Now, when I compile the project, when linking the tests target:
cmake -DBUILD_TESTS:BOOL=ON ..

[100%] Linking CXX executable test_HG
PATH_TO_VTK_LIB_DIR/vtkWrappingPython27Core-7.1.so.1: error: undefined
reference to '_PyUnicodeUCS2_AsDefaultEncodedString'
PATH_TO_VTK_LIB_DIR/vtkWrappingPython27Core-7.1.so.1: error: undefined
reference to 'PyUnicodeUCS2_AsUTF8String'
PATH_TO_VTK_LIB_DIR/vtkWrappingPython27Core-7.1.so.1: error: undefined
reference to 'PyUnicodeUCS2_DecodeUTF8'
PATH_TO_VTK_LIB_DIR/vtkWrappingPython27Core-7.1.so.1: error: undefined
reference to 'PyUnicodeUCS2_GetSize'
collect2: error: ld returned 1 exit status
make[2]: *** [tests/test_HG] Error 1
make[1]: *** [tests/CMakeFiles/test_HG.dir/all] Error 2
make: *** [all] Error 2

That is because the linker is linking against the system Python library
instead of the one in the LD_LIBRARY_PATH.

Checking the command in VERBOSE=1 mode, I get that the c++ command is
linking against python using `-lpython2.7` instead of the fullpath to the
library.

To confirm that, explicitly adding to LDFLAGS the path to the python
library:
LDFLAGS='-L/path/to/the/dir/of/libpython2.7.so' cmake
-DBUILD_TESTS:BOOL=ON' allows the project to compile correctly.

So now, why the linker does not look into LD_LIBRARY_PATH? Is that normal?
And if it is, how should I be supposed to make the linker look into
LD_LIBRARY_PATH?

Thanks in advance,







-- 
          _
-.     .?  |????
  ',  ;    |??????
    ??     |????????? RdB
    ,.,    |??????
  .'   '.  |????
-'       `'
http://rdb.is
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/358497b6/attachment.html>

From rleigh at codelibre.net  Thu Aug  2 15:06:30 2018
From: rleigh at codelibre.net (Roger Leigh)
Date: Thu, 2 Aug 2018 20:06:30 +0100
Subject: [CMake] LD_LIBRARY_PATH not used by the linker
In-Reply-To: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>
References: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>
Message-ID: <9a0bc66b-4461-273b-6d5b-4d032180efe1@codelibre.net>

On 02/08/18 20:03, Ruben Di Battista wrote:

> I'm running cmake on a system where I have module-loaded software such 
> that `LD_LIBRARY_PATH` gets populated by the module (actually I'm using 
> Lmod) function.

LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not used 
when linking at *build* time, with ld.


Regards,
Roger

From rubendibattista at gmail.com  Thu Aug  2 15:43:00 2018
From: rubendibattista at gmail.com (Ruben Di Battista)
Date: Thu, 2 Aug 2018 21:43:00 +0200
Subject: [CMake] LD_LIBRARY_PATH not used by the linker
In-Reply-To: <9a0bc66b-4461-273b-6d5b-4d032180efe1@codelibre.net>
References: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>
 <9a0bc66b-4461-273b-6d5b-4d032180efe1@codelibre.net>
Message-ID: <CACnYWRfZD1duf9PgQrvx1J5ychrj4qJr06VVgBaWOTgQxvWC6g@mail.gmail.com>

Hi Roger,
so I explicitly passing the LDFLAGS is the way to go?

On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh <rleigh at codelibre.net> wrote:

> On 02/08/18 20:03, Ruben Di Battista wrote:
>
> > I'm running cmake on a system where I have module-loaded software such
> > that `LD_LIBRARY_PATH` gets populated by the module (actually I'm using
> > Lmod) function.
>
> LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not used
> when linking at *build* time, with ld.
>
>
> Regards,
> Roger
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
          _
-.     .?  |????
  ',  ;    |??????
    ??     |????????? RdB
    ,.,    |??????
  .'   '.  |????
-'       `'
http://rdb.is
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/9312d1d7/attachment.html>

From rleigh at codelibre.net  Thu Aug  2 15:56:02 2018
From: rleigh at codelibre.net (Roger Leigh)
Date: Thu, 2 Aug 2018 20:56:02 +0100
Subject: [CMake] LD_LIBRARY_PATH not used by the linker
In-Reply-To: <CACnYWRfZD1duf9PgQrvx1J5ychrj4qJr06VVgBaWOTgQxvWC6g@mail.gmail.com>
References: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>
 <9a0bc66b-4461-273b-6d5b-4d032180efe1@codelibre.net>
 <CACnYWRfZD1duf9PgQrvx1J5ychrj4qJr06VVgBaWOTgQxvWC6g@mail.gmail.com>
Message-ID: <551974ae-d72a-0139-d6c5-c28223fbb611@codelibre.net>

It's the quick and easy way to do it.

However, I'd suggest looking at getting CMake to use the proper path 
without it.  Can you use any module-specific variables like 
PYTHON_LIBRARY to override the search.  Or even just add to 
CMAKE_PREFIX_PATH.  (Does VTK support imported targets?)

Regards,
Roger

On 02/08/18 20:43, Ruben Di Battista wrote:
> Hi Roger,
> so I explicitly passing the LDFLAGS is the way to go?
> 
> On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh <rleigh at codelibre.net 
> <mailto:rleigh at codelibre.net>> wrote:
> 
>     On 02/08/18 20:03, Ruben Di Battista wrote:
> 
>      > I'm running cmake on a system where I have module-loaded software
>     such
>      > that `LD_LIBRARY_PATH` gets populated by the module (actually I'm
>     using
>      > Lmod) function.
> 
>     LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.? It is not used
>     when linking at *build* time, with ld.

From cmake at kant.sophonet.de  Thu Aug  2 16:00:07 2018
From: cmake at kant.sophonet.de (Sophonet)
Date: Thu, 2 Aug 2018 22:00:07 +0200
Subject: [CMake] VS 2017 + CUDA 9.0
Message-ID: <E7C0AA0B-4188-4152-A785-C3364B852625@kant.sophonet.de>

Hi list,

it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires an old toolset to be installed for successful compilation (15.4, see https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/). The new VS 2017 toolset have an incompatible _MSC_VER variable, among other things.

The link above mentions to manually revert the toolset for a solution, but I was wondering how CMake-based projects could be configured to automatically pick the 15.4 toolset (which has version 14.11 instead of 14.12). The CMake documentation for toolsets is somehow sparse and only mentions toolsets with name ?v141?, which I think would apply for both. Any hints to find out (i) what toolsets are actually available for a specific compiler or (ii) forcing toolset 14.12 as mentioned above - without manual editing of the vcproj project files?

Thanks,

	Sophonet



From rubendibattista at gmail.com  Thu Aug  2 16:13:01 2018
From: rubendibattista at gmail.com (Ruben Di Battista)
Date: Thu, 2 Aug 2018 22:13:01 +0200
Subject: [CMake] LD_LIBRARY_PATH not used by the linker
In-Reply-To: <551974ae-d72a-0139-d6c5-c28223fbb611@codelibre.net>
References: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>
 <9a0bc66b-4461-273b-6d5b-4d032180efe1@codelibre.net>
 <CACnYWRfZD1duf9PgQrvx1J5ychrj4qJr06VVgBaWOTgQxvWC6g@mail.gmail.com>
 <551974ae-d72a-0139-d6c5-c28223fbb611@codelibre.net>
Message-ID: <CACnYWRedgebvGWjONyAAJ1=wd=af2KaX8xfHSCG6PNYD9qSAzQ@mail.gmail.com>

Thanks for your answer,

The thing is that, since the Python dependency comes from VTK, I checked in
the VTK install directory all the CMake configuration files (In particulare
the UseVTK.cmake) file to see if they keep the Python path somewhere.

And it happens that yes, they do.
If I run: `grep -e 'python2.7' -r <PATH_TO_VTK/lib/cmake/vtk-7.1>`, I
actually get that in the file `VTKTargets.cmake`and in the
`Modules/vtkPython.cmake` they actually keep the path of the python used to
compile VTK.

For example in VTKTargets.cmake, you find:

set_target_properties(vtkWrappingPythonCore PROPERTIES
  INTERFACE_LINK_LIBRARIES
"vtkCommonCore;/home2/softmassot/eb/Compiler/GCCcore/7.2.0/Python/2.7.14-bare/lib/
libpython2.7.so;vtksys"
)

So when I link my test target to ${VTK_LIBRARIES}, shouldn't it also be
able to retrieve the right python library from the target properties?


On Thu, Aug 2, 2018 at 9:56 PM Roger Leigh <rleigh at codelibre.net> wrote:

> It's the quick and easy way to do it.
>
> However, I'd suggest looking at getting CMake to use the proper path
> without it.  Can you use any module-specific variables like
> PYTHON_LIBRARY to override the search.  Or even just add to
> CMAKE_PREFIX_PATH.  (Does VTK support imported targets?)
>
> Regards,
> Roger
>
> On 02/08/18 20:43, Ruben Di Battista wrote:
> > Hi Roger,
> > so I explicitly passing the LDFLAGS is the way to go?
> >
> > On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh <rleigh at codelibre.net
> > <mailto:rleigh at codelibre.net>> wrote:
> >
> >     On 02/08/18 20:03, Ruben Di Battista wrote:
> >
> >      > I'm running cmake on a system where I have module-loaded software
> >     such
> >      > that `LD_LIBRARY_PATH` gets populated by the module (actually I'm
> >     using
> >      > Lmod) function.
> >
> >     LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not
> used
> >     when linking at *build* time, with ld.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
          _
-.     .?  |????
  ',  ;    |??????
    ??     |????????? RdB
    ,.,    |??????
  .'   '.  |????
-'       `'
https://rdb.is <http://rdb.is>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/b4bd6bf2/attachment-0001.html>

From mellery451 at gmail.com  Thu Aug  2 16:24:48 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Thu, 2 Aug 2018 13:24:48 -0700
Subject: [CMake] Can't find boost libs on VS2017 CMake 3.12
In-Reply-To: <5beefc68-c81f-06ae-3ce5-f5ced37f2f13@syntonetic.com>
References: <5beefc68-c81f-06ae-3ce5-f5ced37f2f13@syntonetic.com>
Message-ID: <FE0120B6-1369-4F3E-9925-2EFA2C9C6037@gmail.com>

did you build boost yourself or download a pre-built package? What subdirectory are the import libraries (.lib) located in? Do you set any boost-finder variables before calling find_package(Boost)? I have at times in the past had to set BOOST_LIBRARYDIR when the package I was using had an odd lib file location, but I don?t think that?s typically needed.


> On Aug 2, 2018, at 6:24 AM, S?ren <sd at syntonetic.com> wrote:
> 
> Dear cmake community
> 
> I can't make CMake find the built boost libraries on Windows. At this line:
> 
>     find_package(Boost REQUIRED COMPONENTS thread)
> 
> I get this error message:
> "Unable to find the requested Boost libraries.
> 
>   Boost version: 1.67.0
> 
>   Boost include path: C:/download/boost/boost_1_67_0
> 
>   Could not find the following static Boost libraries:
> 
>           boost_thread
> 
>   Some (but not all) of the required Boost libraries were found. You may
>   need to install these additional Boost libraries.  Alternatively, set
>   BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
>   to the location of Boost."
> 
> Other facts and observations:
> * Error both observed with stand alone Cmake 3.12, and the version cmake 3.11 that ships with VS2017.
> * VS2017 version 15.7.5 (currently the latest)
> * The same error with older Boost versions 1.65.x or 1.66
> * Building and linking the same program using VS2017 without cmake works fine.
> * It's not only threat that has the problem. Tested also date_time and chrono with same errors.
> * Building a program with cmake that only requires boost headers-only-libs works fine.
> * Building the same project on linux works fine.
> 
> Any ideas?
> Thanks in advance
> Soren
> 
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/fbf770bf/attachment.sig>

From cmake at kant.sophonet.de  Thu Aug  2 16:34:15 2018
From: cmake at kant.sophonet.de (Sophonet)
Date: Thu, 2 Aug 2018 22:34:15 +0200
Subject: [CMake] Can't find boost libs on VS2017 CMake 3.12
In-Reply-To: <FE0120B6-1369-4F3E-9925-2EFA2C9C6037@gmail.com>
References: <5beefc68-c81f-06ae-3ce5-f5ced37f2f13@syntonetic.com>
 <FE0120B6-1369-4F3E-9925-2EFA2C9C6037@gmail.com>
Message-ID: <6ACE6ED3-5836-45D9-BC62-5F29BBC3AE01@kant.sophonet.de>

One hint would be to SET(Boost_DEBUG ON) and to watch the output of the cmake call. There, you can check the names of the libraries that CMake is looking for.

On Windows, the new boost versions add a suffix fo x64/x86 to their library name.

Can you confirm that the library names that Boost_DEBUG report are the ones that cover your compiled library? If not, then I would think that CMake ist not yet able to find new boost libraries due to the x86/64 sufffix - but again, please check if this applies to your version numbers?


> Am 02.08.2018 um 22:24 schrieb Michael Ellery <mellery451 at gmail.com>:
> 
> did you build boost yourself or download a pre-built package? What subdirectory are the import libraries (.lib) located in? Do you set any boost-finder variables before calling find_package(Boost)? I have at times in the past had to set BOOST_LIBRARYDIR when the package I was using had an odd lib file location, but I don?t think that?s typically needed.
> 
> 
>> On Aug 2, 2018, at 6:24 AM, S?ren <sd at syntonetic.com> wrote:
>> 
>> Dear cmake community
>> 
>> I can't make CMake find the built boost libraries on Windows. At this line:
>> 
>>    find_package(Boost REQUIRED COMPONENTS thread)
>> 
>> I get this error message:
>> "Unable to find the requested Boost libraries.
>> 
>>  Boost version: 1.67.0
>> 
>>  Boost include path: C:/download/boost/boost_1_67_0
>> 
>>  Could not find the following static Boost libraries:
>> 
>>          boost_thread
>> 
>>  Some (but not all) of the required Boost libraries were found. You may
>>  need to install these additional Boost libraries.  Alternatively, set
>>  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
>>  to the location of Boost."
>> 
>> Other facts and observations:
>> * Error both observed with stand alone Cmake 3.12, and the version cmake 3.11 that ships with VS2017.
>> * VS2017 version 15.7.5 (currently the latest)
>> * The same error with older Boost versions 1.65.x or 1.66
>> * Building and linking the same program using VS2017 without cmake works fine.
>> * It's not only threat that has the problem. Tested also date_time and chrono with same errors.
>> * Building a program with cmake that only requires boost headers-only-libs works fine.
>> * Building the same project on linux works fine.
>> 
>> Any ideas?
>> Thanks in advance
>> Soren
>> 
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake


From robert.maynard at kitware.com  Thu Aug  2 16:50:26 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 2 Aug 2018 16:50:26 -0400
Subject: [CMake] VS 2017 + CUDA 9.0
In-Reply-To: <E7C0AA0B-4188-4152-A785-C3364B852625@kant.sophonet.de>
References: <E7C0AA0B-4188-4152-A785-C3364B852625@kant.sophonet.de>
Message-ID: <CAFzjYVqUDK7VA6KUgkbcj3TYXAtP0pcCyhsq-Y68Rw97m0Sf=g@mail.gmail.com>

When initially configuring a project you can specify which toolset you
would like to use. Starting in CMake 3.12 this now also supports
specifying which patch version. You can see what the syntax looks like
at: https://cmake.org/cmake/help/v3.12/release/3.12.html#id3
On Thu, Aug 2, 2018 at 4:12 PM Sophonet <cmake at kant.sophonet.de> wrote:
>
> Hi list,
>
> it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires an old toolset to be installed for successful compilation (15.4, see https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/). The new VS 2017 toolset have an incompatible _MSC_VER variable, among other things.
>
> The link above mentions to manually revert the toolset for a solution, but I was wondering how CMake-based projects could be configured to automatically pick the 15.4 toolset (which has version 14.11 instead of 14.12). The CMake documentation for toolsets is somehow sparse and only mentions toolsets with name ?v141?, which I think would apply for both. Any hints to find out (i) what toolsets are actually available for a specific compiler or (ii) forcing toolset 14.12 as mentioned above - without manual editing of the vcproj project files?
>
> Thanks,
>
>         Sophonet
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From crestchristopher at gmail.com  Thu Aug  2 20:40:10 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Thu, 2 Aug 2018 20:40:10 -0400
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
 <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
 <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>
Message-ID: <dd6747bb-f06e-a121-4539-4d5e80ddbf1b@gmail.com>

Sorry, what is this information for; and how can it be used within the 
`build_script` section in the appveyor.yml file ?


On 8/2/2018 9:30 AM, Volker Enderlein wrote:
> Please have a look into the appveyor.yml file under section 
> build_script: you see the typical invocation of cmake for this github 
> project.
>
> Cheers Volker
>
> Am 02/08/2018 um 15:18 schrieb CrestChristopher:
>> I hope this helps; 
>> https://github.com/imageworks/OpenShadingLanguage/pull/824 ?
>>
>>
>> On 8/1/2018 5:20 PM, Volker Enderlein wrote:
>>> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>>>> Hi, I'm a beginner to CMake and for weeks I've been trying to 
>>>> compile a CMake file which I found on a github repository.? All I 
>>>> can say is I have a CMakeLists.txt file but I don't know how to 
>>>> compile and I hope someone can help ?
>>>>
>>>> Christopher
>>>>
>>> You may want to include information about the name and the link to 
>>> the project repository from Github to get the best possible 
>>> responses. Without that it's just shooting in the dark.
>>>
>>> Cheers Volker
>>>
>>
>


From quang.t.ha.20 at gmail.com  Thu Aug  2 22:56:45 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Thu, 2 Aug 2018 20:56:45 -0600
Subject: [CMake] setting FIXTURES_* and RESOURCE_LOCK caused permission
 denied for dependent test?
Message-ID: <CAGfE9+Oa4Jo0rgTRrbEM+wZUcVW+PUxFKzrFir951TrGxApoEg@mail.gmail.com>

Hi all,

I am facing the issue of FIXTURES for setting up dependent test. Using
RESOURCE_LOCK. Currently, it looks something like this:

===================================================
set_test_properties(run_simulation PROPERTIES FIXTURES_SETUP
${simulation_name})
set_test_properties(compare_results PROPERTIES FIXTURES_REQUIRED
${simulation_name})

[...]

set_test_properties(run_simulation compare_results PROPERTIES RESOURCE_LOCK
data_${simulation_name})
===================================================

If I include the line of RESOURCE_LOCK, the compare_results test will
failed with permission denied. Removing it will make it run fine. I don't
think I'm doing anything wrong though - why such behaviour is observed?

Thanks,
QT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180802/7ded2bf7/attachment.html>

From volker.enderlein at ifm-chemnitz.de  Fri Aug  3 02:48:03 2018
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Fri, 3 Aug 2018 08:48:03 +0200
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <dd6747bb-f06e-a121-4539-4d5e80ddbf1b@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
 <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
 <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>
 <dd6747bb-f06e-a121-4539-4d5e80ddbf1b@gmail.com>
Message-ID: <0a158c53-7003-c49f-af28-e9baa3216fd8@ifm-chemnitz.de>

If you go to https://github.com/imageworks/OpenShadingLanguage

i.e. the top level directory of the github project, you'll se an 
appveyor.yml file entry. That is the information for the continuous 
integration tool (CI, AppVeyor) they are using to build the project from 
scratch. If you look into it, you'll find a before_build and a 
build_script section. Both contain calls to CMake either to build the 
dependencies (before_build) or the project itself (build_script). This 
is a starting point for you how to formulate your CMake call.

Cheers Volker

Am 03/08/2018 um 02:40 schrieb CrestChristopher:
> Sorry, what is this information for; and how can it be used within the 
> `build_script` section in the appveyor.yml file ?
>
>
> On 8/2/2018 9:30 AM, Volker Enderlein wrote:
>> Please have a look into the appveyor.yml file under section 
>> build_script: you see the typical invocation of cmake for this github 
>> project.
>>
>> Cheers Volker
>>
>> Am 02/08/2018 um 15:18 schrieb CrestChristopher:
>>> I hope this helps; 
>>> https://github.com/imageworks/OpenShadingLanguage/pull/824 ?
>>>
>>>
>>> On 8/1/2018 5:20 PM, Volker Enderlein wrote:
>>>> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>>>>> Hi, I'm a beginner to CMake and for weeks I've been trying to 
>>>>> compile a CMake file which I found on a github repository.? All I 
>>>>> can say is I have a CMakeLists.txt file but I don't know how to 
>>>>> compile and I hope someone can help ?
>>>>>
>>>>> Christopher
>>>>>
>>>> You may want to include information about the name and the link to 
>>>> the project repository from Github to get the best possible 
>>>> responses. Without that it's just shooting in the dark.
>>>>
>>>> Cheers Volker
>>>>
>>>
>>
>

-- 


From craig.scott at crascit.com  Fri Aug  3 05:28:33 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 3 Aug 2018 19:28:33 +1000
Subject: [CMake] setting FIXTURES_* and RESOURCE_LOCK caused permission
 denied for dependent test?
In-Reply-To: <CAGfE9+Oa4Jo0rgTRrbEM+wZUcVW+PUxFKzrFir951TrGxApoEg@mail.gmail.com>
References: <CAGfE9+Oa4Jo0rgTRrbEM+wZUcVW+PUxFKzrFir951TrGxApoEg@mail.gmail.com>
Message-ID: <CA+dygY=e43wvqU0TWsbc-Yf+3UKD03uLvv_4se9pJ2_MbTa_1A@mail.gmail.com>

On Fri, Aug 3, 2018 at 12:56 PM, Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> Hi all,
>
> I am facing the issue of FIXTURES for setting up dependent test. Using
> RESOURCE_LOCK. Currently, it looks something like this:
>
> ===================================================
> set_test_properties(run_simulation PROPERTIES FIXTURES_SETUP
> ${simulation_name})
> set_test_properties(compare_results PROPERTIES FIXTURES_REQUIRED
> ${simulation_name})
>
> [...]
>
> set_test_properties(run_simulation compare_results PROPERTIES
> RESOURCE_LOCK data_${simulation_name})
> ===================================================
>
> If I include the line of RESOURCE_LOCK, the compare_results test will
> failed with permission denied. Removing it will make it run fine. I don't
> think I'm doing anything wrong though - why such behaviour is observed?
>

There doesn't seem to be anything wrong with your example code above, but
the problem might be in the other things that you have omitted. Does
anything else use the same resource lock name? If so, those are most likely
the cause. The code above on its own should not be able to lead to the
behavior you have described, since the use of RESOURCE_LOCK only has the
effect of preventing tests with the same named resource from running
concurrently. It doesn't touch any files directly, only your tests
themselves would be doing that. The other thing I would check is the
specific reason why the compare_results test is complaining with the
message "permission denied". Maybe add more debug logging to the test case
to check what you expect to exist (or not exist) at the start of the test.
You can also make ctest show more output by adding the -V option which will
show all the commands and test output.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180803/f1dfa38d/attachment.html>

From lp.cordier at dynamixyz.com  Fri Aug  3 05:19:39 2018
From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER)
Date: Fri, 3 Aug 2018 11:19:39 +0200
Subject: [CMake] $<TARGET_PDB_FILE:tgt> is not empty even if configuration
 has no PDB
Message-ID: <46933b39-f156-8770-c9bb-210e002c11f1@dynamixyz.com>

Hi everybody,

I am currently trying to add reproducible MSVC build to my project using 
ducible tool.

ducible can take in optional parameter, a pdb file.

I am using the following command:

 ? set(DUCIBLE_BINARY "${CMAKE_CURRENT_LIST_DIR}/bin/ducible.exe")
 ? add_custom_command(TARGET ${MYTARGET}
 ???????????????????? POST_BUILD
 ???????????????????? COMMAND ${DUCIBLE_BINARY} 
\"$<TARGET_FILE:${MYTARGET}>\" \"$<TARGET_PDB_FILE:${MYTARGET}>\"
 ???????????????????? COMMENT "Patching for reproducible build.")

However even if the current configuration is not generating a PDB (for 
Release for instance), this generator expression is providing a path, 
making the ducible tool to fail because the pdb file does not exists. Is 
it a bug? How can I detect using generator expression if a file exists? 
I tried to check all _PDB_ properties of the target but they are all 
empty by default.

Thank you very much for your help,

Louis-Paul CORDIER

From nilsgladitz at gmail.com  Fri Aug  3 06:17:40 2018
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 3 Aug 2018 12:17:40 +0200
Subject: [CMake] $<TARGET_PDB_FILE:tgt> is not empty even if
 configuration has no PDB
In-Reply-To: <46933b39-f156-8770-c9bb-210e002c11f1@dynamixyz.com>
References: <46933b39-f156-8770-c9bb-210e002c11f1@dynamixyz.com>
Message-ID: <CAEbDRx0XmtwjhDQS-UqJ3=v4K2eb1f6Vfe08j_GciSBL8Xe4HA@mail.gmail.com>

On Fri, Aug 3, 2018 at 11:31 AM Louis-Paul CORDIER <lp.cordier at dynamixyz.com>
wrote:

> How can I detect using generator expression if a file exists?
>

Since there is no first class CMake feature controlling if PDB files are
generated and since CMake does not try to interpret custom compiler flags
projects or users might be setting it doesn't necessarily know which
configurations may or may not generate PDBs.
I.e. a project might add the required compiler flags to generate PDBs in
Release configurations as well.

If you know for your use case that PDBs are generated for all
configurations except Release you could guard expansion of
$<TARGET_PDB_FILE> with something like
$<$<NOT:$<CONFIG:Release>>:$<TARGET_PDB_FILE:...>> (untested) or
alternatively and perhaps cleaner and more flexible you could replace your
direct command invocation with a cmake script wrapper that checks for
existence of files before invoking the actual tool. That way it would also
work when users directly manipulated PDB specific compiler flags.

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

From sd at syntonetic.com  Fri Aug  3 07:24:41 2018
From: sd at syntonetic.com (=?UTF-8?B?U8O4cmVu?=)
Date: Fri, 3 Aug 2018 13:24:41 +0200
Subject: [CMake] Can't find boost libs on VS2017 CMake 3.12
In-Reply-To: <6ACE6ED3-5836-45D9-BC62-5F29BBC3AE01@kant.sophonet.de>
References: <5beefc68-c81f-06ae-3ce5-f5ced37f2f13@syntonetic.com>
 <FE0120B6-1369-4F3E-9925-2EFA2C9C6037@gmail.com>
 <6ACE6ED3-5836-45D9-BC62-5F29BBC3AE01@kant.sophonet.de>
Message-ID: <2c402bc4-7918-65d3-ac5e-954afd8d03c7@syntonetic.com>

Thanks

Debug output shows
* that it already searchs in the right folders.
* It appears to search for the right patterns e.g. 
"boost_chrono-vc141-mt-x64-1_67" (file is there 
"libboost_chrono-vc141-mt-x64-1_67.lib")
* It also states? "Boost_FOUND = 1"

But still that error. So far I can't see from the debug output why it 
fails.

From crestchristopher at gmail.com  Fri Aug  3 08:43:47 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Fri, 3 Aug 2018 08:43:47 -0400
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <0a158c53-7003-c49f-af28-e9baa3216fd8@ifm-chemnitz.de>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
 <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
 <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>
 <dd6747bb-f06e-a121-4539-4d5e80ddbf1b@gmail.com>
 <0a158c53-7003-c49f-af28-e9baa3216fd8@ifm-chemnitz.de>
Message-ID: <58a453d8-6c71-2ec4-e427-66334ae4a8d9@gmail.com>

Hi, I assume that the first link I posted which was a link to OSL Toy 
within the Open Shading Language repository uses the methods which you 
mention to compile the file ?

> i.e. the top level directory of the github project, you'll se an 
> appveyor.yml file entry. That is the information for the continuous 
> integration tool (CI, AppVeyor) they are using to build the project 
> from scratch. If you look into it, you'll find a before_build and a 
> build_script section. Both contain calls to CMake either to build the 
> dependencies (before_build) or the project itself (build_script). This 
> is a starting point for you how to formulate your CMake call. 

With the information within the before_build & build_script section; how 
do I formulate the CMake call, as to compile ?

Thank You.


On 8/3/2018 2:48 AM, Volker Enderlein wrote:
> If you go to https://github.com/imageworks/OpenShadingLanguage
>
> i.e. the top level directory of the github project, you'll se an 
> appveyor.yml file entry. That is the information for the continuous 
> integration tool (CI, AppVeyor) they are using to build the project 
> from scratch. If you look into it, you'll find a before_build and a 
> build_script section. Both contain calls to CMake either to build the 
> dependencies (before_build) or the project itself (build_script). This 
> is a starting point for you how to formulate your CMake call.
>
> Cheers Volker
>
> Am 03/08/2018 um 02:40 schrieb CrestChristopher:
>> Sorry, what is this information for; and how can it be used within 
>> the `build_script` section in the appveyor.yml file ?
>>
>>
>> On 8/2/2018 9:30 AM, Volker Enderlein wrote:
>>> Please have a look into the appveyor.yml file under section 
>>> build_script: you see the typical invocation of cmake for this 
>>> github project.
>>>
>>> Cheers Volker
>>>
>>> Am 02/08/2018 um 15:18 schrieb CrestChristopher:
>>>> I hope this helps; 
>>>> https://github.com/imageworks/OpenShadingLanguage/pull/824 ?
>>>>
>>>>
>>>> On 8/1/2018 5:20 PM, Volker Enderlein wrote:
>>>>> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>>>>>> Hi, I'm a beginner to CMake and for weeks I've been trying to 
>>>>>> compile a CMake file which I found on a github repository.? All I 
>>>>>> can say is I have a CMakeLists.txt file but I don't know how to 
>>>>>> compile and I hope someone can help ?
>>>>>>
>>>>>> Christopher
>>>>>>
>>>>> You may want to include information about the name and the link to 
>>>>> the project repository from Github to get the best possible 
>>>>> responses. Without that it's just shooting in the dark.
>>>>>
>>>>> Cheers Volker
>>>>>
>>>>
>>>
>>
>


From volker.enderlein at ifm-chemnitz.de  Fri Aug  3 10:02:45 2018
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Fri, 3 Aug 2018 16:02:45 +0200
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <58a453d8-6c71-2ec4-e427-66334ae4a8d9@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
 <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
 <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>
 <dd6747bb-f06e-a121-4539-4d5e80ddbf1b@gmail.com>
 <0a158c53-7003-c49f-af28-e9baa3216fd8@ifm-chemnitz.de>
 <58a453d8-6c71-2ec4-e427-66334ae4a8d9@gmail.com>
Message-ID: <5c19dfd8-e9e3-e9b7-7480-738cf1bfc4e7@ifm-chemnitz.de>

Hi,

the configuration step of OSL is running this command (via a powershell 
command), $... denotes always variables defined somewhere in the 
appveyor file, $env: denotes environment variables.

cmake ..\.. -G "$GENERATOR" 
-DCMAKE_CONFIGURATION_TYPES="$env:CONFIGURATION" 
-DCMAKE_PREFIX_PATH="$env:OPENIMAGEIOHOME;$DEP_DIR;$BOOST_ROOT;$LLVM_DIR" 
-DCMAKE_INSTALL_PREFIX="$DEP_DIR" -DLLVM_DIRECTORY="$LLVM_DIR" 
-DLLVM_STATIC=ON -DOPENIMAGEIOHOME="$env:OPENIMAGEIOHOME" 
-DBOOST_LIBRARYDIR="$BOOST_LIBRARYDIR" 
-DFLEX_EXECUTABLE="C:\ProgramData\chocolatey\lib\winflexbison\tools\win_flex.exe" 
-DBISON_EXECUTABLE="C:\ProgramData\chocolatey\lib\winflexbison\tools\win_bison.exe" 
-DUSE_QT=OFF -DBUILDSTATIC=OFF -DLINKSTATIC=OFF

The build step is run via this command:

cmake --build . --config $env:CONFIGURATION -- /nologo /verbosity:minimal

So it builds the entire OSL Project.

As the OSL Toy is included in the master it should be built too. 
(According to the documentation of the PR you linked to, you should 
remove "-DUSE_QT=OFF" from the CMake configuration call.) And because 
you are on Windows using a Visual Studio I suppose you can safely remove 
-DLLVM_DIRECTORY="$LLVM_DIR" -DLLVM_STATIC=ON (as you are not building 
with LLVM) and replace -G "$GENERATOR" by -G "Visual Studio 14 2015" or 
-G "Visual Studio 15 2017". "$env:Configuration" ca be replaced with 
"Release" (without the double quotes). Other environment variables and 
variables may need to be replaced by %variable% if you build on a non 
powershell command prompt. This is not tested, so you may need to adopt 
other settings too.

I am not aware of any way to build OSL Toy separately. Maybe you should 
drop Larry Gritz (the committer of the PR) a message asking for further 
guidance as this is not really a CMake issue rather than a "How do I 
compile only subproject Y of X" with CMake.

Cheers Volker

Am 03/08/2018 um 14:43 schrieb CrestChristopher:
> Hi, I assume that the first link I posted which was a link to OSL Toy 
> within the Open Shading Language repository uses the methods which you 
> mention to compile the file ?
>
>> i.e. the top level directory of the github project, you'll se an 
>> appveyor.yml file entry. That is the information for the continuous 
>> integration tool (CI, AppVeyor) they are using to build the project 
>> from scratch. If you look into it, you'll find a before_build and a 
>> build_script section. Both contain calls to CMake either to build the 
>> dependencies (before_build) or the project itself (build_script). 
>> This is a starting point for you how to formulate your CMake call. 
>
> With the information within the before_build & build_script section; 
> how do I formulate the CMake call, as to compile ?
>
> Thank You.
>
>
> On 8/3/2018 2:48 AM, Volker Enderlein wrote:
>> If you go to https://github.com/imageworks/OpenShadingLanguage
>>
>> i.e. the top level directory of the github project, you'll se an 
>> appveyor.yml file entry. That is the information for the continuous 
>> integration tool (CI, AppVeyor) they are using to build the project 
>> from scratch. If you look into it, you'll find a before_build and a 
>> build_script section. Both contain calls to CMake either to build the 
>> dependencies (before_build) or the project itself (build_script). 
>> This is a starting point for you how to formulate your CMake call.
>>
>> Cheers Volker
>>
>> Am 03/08/2018 um 02:40 schrieb CrestChristopher:
>>> Sorry, what is this information for; and how can it be used within 
>>> the `build_script` section in the appveyor.yml file ?
>>>
>>>
>>> On 8/2/2018 9:30 AM, Volker Enderlein wrote:
>>>> Please have a look into the appveyor.yml file under section 
>>>> build_script: you see the typical invocation of cmake for this 
>>>> github project.
>>>>
>>>> Cheers Volker
>>>>
>>>> Am 02/08/2018 um 15:18 schrieb CrestChristopher:
>>>>> I hope this helps; 
>>>>> https://github.com/imageworks/OpenShadingLanguage/pull/824 ?
>>>>>
>>>>>
>>>>> On 8/1/2018 5:20 PM, Volker Enderlein wrote:
>>>>>> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>>>>>>> Hi, I'm a beginner to CMake and for weeks I've been trying to 
>>>>>>> compile a CMake file which I found on a github repository.? All 
>>>>>>> I can say is I have a CMakeLists.txt file but I don't know how 
>>>>>>> to compile and I hope someone can help ?
>>>>>>>
>>>>>>> Christopher
>>>>>>>
>>>>>> You may want to include information about the name and the link 
>>>>>> to the project repository from Github to get the best possible 
>>>>>> responses. Without that it's just shooting in the dark.
>>>>>>
>>>>>> Cheers Volker
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 


From robert.maynard at kitware.com  Fri Aug  3 15:20:07 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 3 Aug 2018 15:20:07 -0400
Subject: [CMake] LD_LIBRARY_PATH not used by the linker
In-Reply-To: <CACnYWRedgebvGWjONyAAJ1=wd=af2KaX8xfHSCG6PNYD9qSAzQ@mail.gmail.com>
References: <CACnYWRfMKpG6ow6pF9qF2uaVEbF+ZqNixL+DcGa422sqof_sRg@mail.gmail.com>
 <9a0bc66b-4461-273b-6d5b-4d032180efe1@codelibre.net>
 <CACnYWRfZD1duf9PgQrvx1J5ychrj4qJr06VVgBaWOTgQxvWC6g@mail.gmail.com>
 <551974ae-d72a-0139-d6c5-c28223fbb611@codelibre.net>
 <CACnYWRedgebvGWjONyAAJ1=wd=af2KaX8xfHSCG6PNYD9qSAzQ@mail.gmail.com>
Message-ID: <CAFzjYVqm0NHZhU1usiLze-OYd+nuagHy=hq5-p5bXhafCMMyHA@mail.gmail.com>

When you dumb out the contents of VTK_LIBRARIES do you see
';/home2/softmassot/eb/Compiler/GCCcore/7.2.0/Python/2.7.14-bare/lib/libpython2.7.so'.

In general CMake will only stop using the absolute path of a library
when the library resides in an implicit directory provided by the
compiler. On Thu, Aug 2, 2018 at 4:13 PM Ruben Di Battista
<rubendibattista at gmail.com> wrote:
>
> Thanks for your answer,
>
> The thing is that, since the Python dependency comes from VTK, I checked in the VTK install directory all the CMake configuration files (In particulare the UseVTK.cmake) file to see if they keep the Python path somewhere.
>
> And it happens that yes, they do.
> If I run: `grep -e 'python2.7' -r <PATH_TO_VTK/lib/cmake/vtk-7.1>`, I actually get that in the file `VTKTargets.cmake`and in the `Modules/vtkPython.cmake` they actually keep the path of the python used to compile VTK.
>
> For example in VTKTargets.cmake, you find:
>
> set_target_properties(vtkWrappingPythonCore PROPERTIES
>   INTERFACE_LINK_LIBRARIES "vtkCommonCore;/home2/softmassot/eb/Compiler/GCCcore/7.2.0/Python/2.7.14-bare/lib/libpython2.7.so;vtksys"
> )
>
> So when I link my test target to ${VTK_LIBRARIES}, shouldn't it also be able to retrieve the right python library from the target properties?
>
>
> On Thu, Aug 2, 2018 at 9:56 PM Roger Leigh <rleigh at codelibre.net> wrote:
>>
>> It's the quick and easy way to do it.
>>
>> However, I'd suggest looking at getting CMake to use the proper path
>> without it.  Can you use any module-specific variables like
>> PYTHON_LIBRARY to override the search.  Or even just add to
>> CMAKE_PREFIX_PATH.  (Does VTK support imported targets?)
>>
>> Regards,
>> Roger
>>
>> On 02/08/18 20:43, Ruben Di Battista wrote:
>> > Hi Roger,
>> > so I explicitly passing the LDFLAGS is the way to go?
>> >
>> > On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh <rleigh at codelibre.net
>> > <mailto:rleigh at codelibre.net>> wrote:
>> >
>> >     On 02/08/18 20:03, Ruben Di Battista wrote:
>> >
>> >      > I'm running cmake on a system where I have module-loaded software
>> >     such
>> >      > that `LD_LIBRARY_PATH` gets populated by the module (actually I'm
>> >     using
>> >      > Lmod) function.
>> >
>> >     LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not used
>> >     when linking at *build* time, with ld.
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>
>
>
> --
>           _
> -.     .?  |????
>   ',  ;    |??????
>     ??     |????????? RdB
>     ,.,    |??????
>   .'   '.  |????
> -'       `'
> https://rdb.is
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From nuquaquaraqua at gmail.com  Sat Aug  4 07:12:49 2018
From: nuquaquaraqua at gmail.com (=?UTF-8?Q?Quaquaraqu=c3=a0?=)
Date: Sat, 4 Aug 2018 13:12:49 +0200
Subject: [CMake] Install interface
Message-ID: <f1c00ba7-3333-db99-c0ec-1d794f7452d7@gmail.com>

Good morning,
given the following configuration:

/CMakeLists.txt
/include/
/lib1/CMakeLists.txt
/lib2/CMakeLists.txt
...

where each /lib.*/CMakeLists.txt creates its own archive:

add_library(lib.* EXCLUDE_FROM_ALL
foo.cpp
bar.cpp
)
target_link_libraries(lib1 PUBLIC interface)

and the final /CMakeLists.txt should wrap all libraries together::

add_library(interface INTERFACE)
target_include_directories(interface INTERFACE include/)
add_subdirectory(lib1 lib2...)
add_library(libcommon INTERFACE)
target_link_libraries(libcommon INTERFACE lib1 lib2...)

I wonder how to create an install target for the final library `libcommon' ?
This snippet doesn't seem effective with INTERFACE targets:
install(TARGETS libcommon
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
 ??? ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
 ??? LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
)

Thanks,
Quack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180804/1938e154/attachment.html>

From bram at cocamware.com  Sat Aug  4 07:53:59 2018
From: bram at cocamware.com (Bram de Greve)
Date: Sat, 4 Aug 2018 13:53:59 +0200
Subject: [CMake] documentation on how to use cmake as an "end-user"?
Message-ID: <8b6fb619-e27c-4f63-0e99-cd0277ae42ac@cocamware.com>

Hi all,

As a developer using CMake, I'd like to add to the README a link to 
general documentation on how to use CMake to build the source code.? 
Something like this, but it's a bit out of date: 
https://cmake.org/runningcmake/?? Is there something more recent I can 
link to?? I've looked into the documentation, and while I very much 
appreciate it as reference on how to write CMakeList.txt, I didn't find 
anything suitable.

Thanks,

Bram


From damir_porobic at live.com  Sun Aug  5 04:54:26 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Sun, 5 Aug 2018 08:54:26 +0000
Subject: [CMake] cmake fails on first run but succeeds when run again after
 make
In-Reply-To: <AM0PR0202MB3411CD63EFDCCC42F6A1CF36E5210@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411CD63EFDCCC42F6A1CF36E5210@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3411E7FAAFFB57798BC70209E5210@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Hi folks,


I'm trying to troubleshoot a build problem where, when I first time run "cmake .." it fails to find a resource file, when I run "make" it builds the resource files but fails later on, now when I try to run "cmake .." again it succeeds. After this point everything runs fine and it happens when building for the first time.

Any idea what I'm doing wrong?


Here are the CMakeList files https://pastebin.com/pyhVTJUr and the output that I get https://pastebin.com/4wGjR3Lx


Thanks in advance!

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

From philip at codeminded.be  Mon Aug  6 14:27:23 2018
From: philip at codeminded.be (Philip Van Hoof)
Date: Mon, 06 Aug 2018 20:27:23 +0200
Subject: [CMake] How to build fully correctly versioned shared object files
 with cmake
Message-ID: <1533580043.7439.9.camel@codeminded.be>

Hello everyone,

I noticed that it sometimes happens that I find a package for a shared
object file(s) (or DLLs, on platforms like Windows) that have a build
set up using cmake, that doesn't set everything that should be set.

Usually as packagers of various popular open source softwares correct
enthusiasts' attempts at understanding the sometimes bizarre
complexities of for example autotools, but (although it's all less
complicated) also cmake, it ends up somewhat right. Somewhat. I noticed
that especially in corporate world, things tend to go spectacularly
wrong. Almost without exception.

In particular am I concerned about ABI versioning of shared object
files so that they are easy to package and distribute by various
operating systems (like, among others, Linux distributions). But also
API versioning of development files (compiler header files and pkg-
config) and installing to the right installation paths.

I wanted to invite the community to scrutinize some equivalent examples
that I made for autotools (with libtool), qmake, cmake and meson.

https://github.com/pvanhoof/dir-examples/

In particular I wanted to invite the cmake community to take a look at
this example:

https://github.com/pvanhoof/dir-examples/tree/master/cmake-example

The idea is that the examples are as correct as possible. That means
the examples should simple and educational. Easing (some amount) of
platform independence (ie. supporting Windows) and packaging.

ps. I don't think CC-ing a huge amount of mailing lists is necessarily
a good idea. So feel free to forward to the appropriate people.

ps. I attached no license to the examples yet. Perhaps I should attach
one? My goal would be that as much entities could copy and use it.
Including for, indeed, non-free purposes (as much as they want).


Kind regards,

Philip Van Hoof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://cmake.org/pipermail/cmake/attachments/20180806/c3a98fe8/attachment.sig>

From robert.maynard at kitware.com  Mon Aug  6 15:17:04 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 6 Aug 2018 15:17:04 -0400
Subject: [CMake] cmake fails on first run but succeeds when run again
 after make
In-Reply-To: <AM0PR0202MB3411E7FAAFFB57798BC70209E5210@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411CD63EFDCCC42F6A1CF36E5210@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <AM0PR0202MB3411E7FAAFFB57798BC70209E5210@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <CAFzjYVrT9QWVkT75THRUCrcyLcoaBjt4CjkUE9ze4BkVu8cGOw@mail.gmail.com>

The error sounds like the file needs to be marked as GENERATED (
https://cmake.org/cmake/help/latest/prop_sf/GENERATED.html ) but I
would have thought qt5_add_resources would do that for you.

You might look at using CMake built in rc support (
https://cmake.org/cmake/help/latest/prop_tgt/AUTORCC.html )On Sun, Aug
5, 2018 at 4:54 AM Damir Porobic <damir_porobic at live.com> wrote:
>
> Hi folks,
>
>
> I'm trying to troubleshoot a build problem where, when I first time run "cmake .." it fails to find a resource file, when I run "make" it builds the resource files but fails later on, now when I try to run "cmake .." again it succeeds. After this point everything runs fine and it happens when building for the first time.
>
> Any idea what I'm doing wrong?
>
>
> Here are the CMakeList files https://pastebin.com/pyhVTJUr and the output that I get https://pastebin.com/4wGjR3Lx
>
>
> Thanks in advance!
>
>
> Damir
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From robert.maynard at kitware.com  Mon Aug  6 15:25:11 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 6 Aug 2018 15:25:11 -0400
Subject: [CMake] Install interface
In-Reply-To: <f1c00ba7-3333-db99-c0ec-1d794f7452d7@gmail.com>
References: <f1c00ba7-3333-db99-c0ec-1d794f7452d7@gmail.com>
Message-ID: <CAFzjYVoptEJGDkjN0rAGPJ_UJT_yrxUtkaR4ouSBBDWAKZtGnQ@mail.gmail.com>

Installing interface libraries has no effect without the 'EXPORT'
keyword as they have no artifacts, you will need to install the actual
archives to get any artifacts.

To generate a CMake file containing the correct import targets for
consumers of your project you should like at the 'EXPORT' keyword for
the install command (
https://cmake.org/cmake/help/latest/command/install.html#export )
On Sat, Aug 4, 2018 at 7:13 AM Quaquaraqu? <nuquaquaraqua at gmail.com> wrote:
>
> Good morning,
> given the following configuration:
>
> /CMakeLists.txt
> /include/
> /lib1/CMakeLists.txt
> /lib2/CMakeLists.txt
> ...
>
> where each /lib.*/CMakeLists.txt creates its own archive:
>
> add_library(lib.* EXCLUDE_FROM_ALL
>     foo.cpp
>     bar.cpp
> )
> target_link_libraries(lib1 PUBLIC interface)
>
> and the final /CMakeLists.txt should wrap all libraries together::
>
> add_library(interface INTERFACE)
> target_include_directories(interface INTERFACE include/)
> add_subdirectory(lib1 lib2 ...)
> add_library(libcommon INTERFACE)
> target_link_libraries(libcommon INTERFACE lib1 lib2 ...)
>
> I wonder how to create an install target for the final library `libcommon' ?
> This snippet doesn't seem effective with INTERFACE targets:
> install(TARGETS libcommon
>     RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
>     ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
>     LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> )
>
> Thanks,
> Quack
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From post at hendrik-sattler.de  Mon Aug  6 15:54:33 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Mon, 06 Aug 2018 21:54:33 +0200
Subject: [CMake] How to build fully correctly versioned shared object
 files with cmake
In-Reply-To: <1533580043.7439.9.camel@codeminded.be>
References: <1533580043.7439.9.camel@codeminded.be>
Message-ID: <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>



Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof <philip at codeminded.be>:
>Hello everyone,
>
>I noticed that it sometimes happens that I find a package for a shared
>object file(s) (or DLLs, on platforms like Windows) that have a build
>set up using cmake, that doesn't set everything that should be set.
>
>Usually as packagers of various popular open source softwares correct
>enthusiasts' attempts at understanding the sometimes bizarre
>complexities of for example autotools, but (although it's all less
>complicated) also cmake, it ends up somewhat right. Somewhat. I noticed
>that especially in corporate world, things tend to go spectacularly
>wrong. Almost without exception.
>
>In particular am I concerned about ABI versioning of shared object
>files so that they are easy to package and distribute by various
>operating systems (like, among others, Linux distributions). But also
>API versioning of development files (compiler header files and pkg-
>config) and installing to the right installation paths.
>
>I wanted to invite the community to scrutinize some equivalent examples
>that I made for autotools (with libtool), qmake, cmake and meson.
>
>https://github.com/pvanhoof/dir-examples/
>
>In particular I wanted to invite the cmake community to take a look at
>this example:
>
>https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
>
>The idea is that the examples are as correct as possible. That means
>the examples should simple and educational. Easing (some amount) of
>platform independence (ie. supporting Windows) and packaging.

Is there ANY reason to use libtool library versioning? It might surprise people but it really is not any kind of standard.

Just change the SOVERSION when you make incompatible ABI changes and a normal library VERSION. There's really not more to it, especially nothing like the sick results that libtool produces, sometimes.

The difficult thing is to realize the need for such a change. But there are tools that can help.

>ps. I don't think CC-ing a huge amount of mailing lists is necessarily
>a good idea. So feel free to forward to the appropriate people.
>
>ps. I attached no license to the examples yet. Perhaps I should attach
>one? My goal would be that as much entities could copy and use it.
>Including for, indeed, non-free purposes (as much as they want).
>
>
>Kind regards,
>
>Philip Van Hoof

From neundorf at kde.org  Mon Aug  6 16:00:52 2018
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 06 Aug 2018 22:00:52 +0200
Subject: [CMake] Using Different Computers for cmake and ctest
In-Reply-To: <CAA5VmpuJsmg1uaP4uzeM5T2e29TRLRJ8k+3PrqU_nZ9B1BoGUQ@mail.gmail.com>
References: <CAA5VmpuJsmg1uaP4uzeM5T2e29TRLRJ8k+3PrqU_nZ9B1BoGUQ@mail.gmail.com>
Message-ID: <2821507.y0UZnhg4Cp@linux-l7nd>

On 2018 M07 18, Wed 09:49:47 CEST Brian S wrote:
> I currently use cmake/ctest to build and test my software. The software is
> C++/CUDA. During the build step I don't need a GPU but in the test step I
> do. I would like to build the code with cmake on a cluster with many CPUs
> and then run the tests using ctest on a target machine with a GPU. Is this
> possible?

as far as I know this is currently not possible.
I would also like to do that, to test the same executable on a set of 
different clusters (or at least with a different number of nodes. For that 
there is no need to rebuild the project multiple times.

For tests, cmake generates CTestTestFile.cmake. 
These are executed when running a test.
Copying the buildtree somewhere and then see what happens when you run ctest. 
E.g. RPATHs probably won't be correct. The tests may also have references into 
the source directory.

Having a nice way to do this properly would be nice IMO :-)

Alex


From neundorf at kde.org  Mon Aug  6 16:09:34 2018
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 06 Aug 2018 22:09:34 +0200
Subject: [CMake] simple find_package example
In-Reply-To: <CAO_spu5nvHMVow2=Bt8nrTLsHZPgq1X_psjNy7fb5Q0hriMU8w@mail.gmail.com>
References: <CAO_spu5nvHMVow2=Bt8nrTLsHZPgq1X_psjNy7fb5Q0hriMU8w@mail.gmail.com>
Message-ID: <21015618.ipb0pL2FiA@linux-l7nd>

On 2018 M08 2, Thu 10:01:39 CEST Randy Heiland wrote:
> Hi,
> 
> I'd like to figure out how to modify the simple "hello" demo (
> https://cmake.org/examples/) so that the Hello project is a library with an
> accompanying FindHello.cmake and then the Demo project uses that
> information and "find_package" to discover/use it.
> 
> Hopefully that makes sense. Basically, I'm looking for a simple tutorial on
> how I can make my library easily accessible to a CMake project. 

for that, you don't want a FindHello.cmake (which would typically be shipped 
either by cmake or by the consuming application), instead you want to generate 
and install a HelloConfig.cmake file.

Alex


From juan.e.sanchez at gmail.com  Mon Aug  6 16:16:11 2018
From: juan.e.sanchez at gmail.com (Juan E. Sanchez)
Date: Mon, 6 Aug 2018 15:16:11 -0500
Subject: [CMake] Using Different Computers for cmake and ctest
In-Reply-To: <2821507.y0UZnhg4Cp@linux-l7nd>
References: <CAA5VmpuJsmg1uaP4uzeM5T2e29TRLRJ8k+3PrqU_nZ9B1BoGUQ@mail.gmail.com>
 <2821507.y0UZnhg4Cp@linux-l7nd>
Message-ID: <dcacc8b6-5d70-dfbb-8d19-75c918491a5f@gmail.com>

Hi,

CTest should work.  You would just need to set the paths to the 
executable you want to test.  In my case, I have my tests in a different 
repository than my source code.

Regards,

Juan

On 8/6/18 3:00 PM, Alexander Neundorf wrote:
> On 2018 M07 18, Wed 09:49:47 CEST Brian S wrote:
>> I currently use cmake/ctest to build and test my software. The software is
>> C++/CUDA. During the build step I don't need a GPU but in the test step I
>> do. I would like to build the code with cmake on a cluster with many CPUs
>> and then run the tests using ctest on a target machine with a GPU. Is this
>> possible?
> 
> as far as I know this is currently not possible.
> I would also like to do that, to test the same executable on a set of
> different clusters (or at least with a different number of nodes. For that
> there is no need to rebuild the project multiple times.
> 
> For tests, cmake generates CTestTestFile.cmake.
> These are executed when running a test.
> Copying the buildtree somewhere and then see what happens when you run ctest.
> E.g. RPATHs probably won't be correct. The tests may also have references into
> the source directory.
> 
> Having a nice way to do this properly would be nice IMO :-)
> 
> Alex
> 


From philip at codeminded.be  Mon Aug  6 16:26:50 2018
From: philip at codeminded.be (Philip Van Hoof)
Date: Mon, 06 Aug 2018 22:26:50 +0200
Subject: [CMake] How to build fully correctly versioned shared object
 files with cmake
In-Reply-To: <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
References: <1533580043.7439.9.camel@codeminded.be>
 <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
Message-ID: <1533587210.7439.13.camel@codeminded.be>

On Mon, 2018-08-06 at 21:54 +0200, Hendrik Sattler wrote:

Hello Hendrik,

> > https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
> > 
> > The idea is that the examples are as correct as possible. That
> > means the examples should simple and educational. Easing (some
> > amount) of platform independence (ie. supporting Windows) and
> > packaging.
> 
> Is there ANY reason to use libtool library versioning? It might
> surprise people but it really is not any kind of standard.

Right, I got a similar remark from the meson people. And I guess people
who are used to qmake will probably also rightfully wonder about this.

The reason is that I wanted to create four examples with identical
method of doing versioning, and that I wanted to refer to the autotools
mythbusters and official libtool documentation for the time being.

	For the time being until there is a sort of community consensus
(crossing multiple popular build environments), and that this gets
documented somewhat 'officially'. Right now, GNU kinda sets the de
facto standard and GNU (fortunately or unfortunately) utilizes libtool
and autotools (a lot). (Please don't read that as me saying that's a
good thing, as I'm not saying that).

I did however tried to make it easy to change the variable fabrication
at the root of the projects (the cmake-example/CMakeLists.txt).

For the cmake example you could take these (which admittedly are not
necessarily easy to understand, but, documented):

set(CMAKE_EXAMPLE_CURRENT_VERSION 3)
set(CMAKE_EXAMPLE_REVISION_VERSION 0)
set(CMAKE_EXAMPLE_AGE_VERSION 1)

math(EXPR CMAKE_EXAMPLE_SOVERSION "${CMAKE_EXAMPLE_CURRENT_VERSION} -
      ${CMAKE_EXAMPLE_AGE_VERSION}")

set(CMAKE_EXAMPLE_VERSION
  ${CMAKE_EXAMPLE_SOVERSION}.
    ${CMAKE_EXAMPLE_AGE_VERSION}.
    ${CMAKE_EXAMPLE_REVISION_VERSION})


And replace them with these (or something like these):

set(CMAKE_EXAMPLE_SOVERSION "2")
set(CMAKE_EXAMPLE_VERSION "2.1.0")

> Just change the SOVERSION when you make incompatible ABI changes and
> a normal library VERSION. There's really not more to it, especially
> nothing like the sick results that libtool produces, sometimes.

nod.

However. I'm not sure about trying to explain different versioning
style for equivalent examples (and in my examples I also include a
autotools one - unfortunately, or fortunately for people who are
converting from a autotools to a cmake, for example. Which is also
among the educational purposes of the examples).

I guess I could document it a little bit better in README.md ...

If people have suggestions? Just, however, let's try to keep it easy
for people coming from libtool-world. A lot of people do.

> The difficult thing is to realize the need for such a change. But
> there are tools that can help.

nod. I tried to explain the necessity in README.md.

I think it would be helpful to mention the tools, though. Suggestions
are welcome.

Thanks,

Kind regards,

Philip Van Hoof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://cmake.org/pipermail/cmake/attachments/20180806/f58f9797/attachment-0001.sig>

From neundorf at kde.org  Mon Aug  6 16:29:21 2018
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 06 Aug 2018 22:29:21 +0200
Subject: [CMake] How to build fully correctly versioned shared object
 files with cmake
In-Reply-To: <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
References: <1533580043.7439.9.camel@codeminded.be>
 <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
Message-ID: <9190746.OKG0mvDWAW@linux-l7nd>

On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote:
> Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof 
<philip at codeminded.be>:
> >Hello everyone,
> >
> >I noticed that it sometimes happens that I find a package for a shared
> >object file(s) (or DLLs, on platforms like Windows) that have a build
> >set up using cmake, that doesn't set everything that should be set.
> >
> >Usually as packagers of various popular open source softwares correct
> >enthusiasts' attempts at understanding the sometimes bizarre
> >complexities of for example autotools, but (although it's all less
> >complicated) also cmake, it ends up somewhat right. Somewhat. I noticed
> >that especially in corporate world, things tend to go spectacularly
> >wrong. Almost without exception.
> >
> >In particular am I concerned about ABI versioning of shared object
> >files so that they are easy to package and distribute by various
> >operating systems (like, among others, Linux distributions). But also
> >API versioning of development files (compiler header files and pkg-
> >config) and installing to the right installation paths.
> >
> >I wanted to invite the community to scrutinize some equivalent examples
> >that I made for autotools (with libtool), qmake, cmake and meson.
> >
> >https://github.com/pvanhoof/dir-examples/
> >
> >In particular I wanted to invite the cmake community to take a look at
> >this example:
> >
> >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
> >
> >The idea is that the examples are as correct as possible. That means
> >the examples should simple and educational. Easing (some amount) of
> >platform independence (ie. supporting Windows) and packaging.
> 
> Is there ANY reason to use libtool library versioning? It might surprise
> people but it really is not any kind of standard.
> 
> Just change the SOVERSION when you make incompatible ABI changes and a
> normal library VERSION. There's really not more to it, especially nothing
> like the sick results that libtool produces, sometimes.

I agree.
I would recommend
Major version  = SO version, increase it if you break ABI compatibility
Minor version: increase it if you add ABI compatible features
Patch version: increase it for bug fix releases.

Alex


From philip at codeminded.be  Mon Aug  6 16:42:01 2018
From: philip at codeminded.be (Philip Van Hoof)
Date: Mon, 06 Aug 2018 22:42:01 +0200
Subject: [CMake] How to build fully correctly versioned shared object
 files with cmake
In-Reply-To: <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
References: <1533580043.7439.9.camel@codeminded.be>
 <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
Message-ID: <1533588121.7439.16.camel@codeminded.be>

Alexander Neundorf?wrote:

> On Mon, 2018-08-06 at 21:54 +0200, Hendrik Sattler wrote:
> > Is there ANY reason to use libtool library versioning? It might 
> > surprise people but it really is not any kind of standard.
> >?
> > Just change the SOVERSION when you make incompatible ABI changes 
> > and a normal library VERSION. There's really not more to it,
> > especially nothing like the sick results that libtool produces, 
> > sometimes.

> I agree.

> I would recommend
> Major version??= SO version, increase it if you break ABI
> compatibility
> Minor version: increase it if you add ABI compatible features
> Patch version: increase it for bug fix releases.
> 
> Alex

Ok, I added this note to README.md, cmake, meson and qmake examples:

# When you don't care about compatibility with libtool's -version-info, 
then you can take the following rules for VERSION in cmake, meson and
qmake:

# * SOVERSION = Major version
# * Major version: increase it if you break ABI compatibility
# * Minor version: increase it if you add ABI compatible features
# * Patch version: increase it for bug fix releases.

https://github.com/pvanhoof/dir-examples/commit/02a9a2d23ddf3627f87dd7a1af74b42603c4f890

(Because yes, you're right that libtool's -version-info is just
pointlessly complicated and messy for people who don't need to care)

Kind regards,

Philip Van Hoof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://cmake.org/pipermail/cmake/attachments/20180806/b9c26676/attachment.sig>

From bo.schwarzstein at gmail.com  Mon Aug  6 20:47:40 2018
From: bo.schwarzstein at gmail.com (Bo Zhou)
Date: Tue, 7 Aug 2018 09:47:40 +0900
Subject: [CMake] Using Different Computers for cmake and ctest
In-Reply-To: <CAA5VmpuJsmg1uaP4uzeM5T2e29TRLRJ8k+3PrqU_nZ9B1BoGUQ@mail.gmail.com>
References: <CAA5VmpuJsmg1uaP4uzeM5T2e29TRLRJ8k+3PrqU_nZ9B1BoGUQ@mail.gmail.com>
Message-ID: <CAMX42NBEDkqtUhD5E_memR-gBJRLVF3M_0XHvsE2GO2FwQqNzQ@mail.gmail.com>

Maybe you could improve the CTest system to allow execute remotely, by a
shared file system to hold the all built binary files, and do a RPC-like
test, and redirect the all output and terminate code from the target GPU
machine, it should be able to work.

On Wed, Jul 18, 2018 at 10:50 PM Brian S <briansdeveloper at gmail.com> wrote:

> I currently use cmake/ctest to build and test my software. The software is
> C++/CUDA. During the build step I don't need a GPU but in the test step I
> do. I would like to build the code with cmake on a cluster with many CPUs
> and then run the tests using ctest on a target machine with a GPU. Is this
> possible?
>
> I have thought about using nvidia-docker but that only works on one of my
> target platforms.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180807/43136ca9/attachment.html>

From post at hendrik-sattler.de  Tue Aug  7 00:14:59 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Tue, 07 Aug 2018 06:14:59 +0200
Subject: [CMake] How to build fully correctly versioned shared object
 files with cmake
In-Reply-To: <9190746.OKG0mvDWAW@linux-l7nd>
References: <1533580043.7439.9.camel@codeminded.be>
 <AF6A6D19-4351-48DD-A19D-32FEFE32BA70@hendrik-sattler.de>
 <9190746.OKG0mvDWAW@linux-l7nd>
Message-ID: <C6AA3C91-4CF7-40D0-AC19-CD8163A08053@hendrik-sattler.de>



Am 6. August 2018 22:29:21 MESZ schrieb Alexander Neundorf <neundorf at kde.org>:
>On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote:
>> Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof 
><philip at codeminded.be>:
>> >Hello everyone,
>> >
>> >I noticed that it sometimes happens that I find a package for a
>shared
>> >object file(s) (or DLLs, on platforms like Windows) that have a
>build
>> >set up using cmake, that doesn't set everything that should be set.
>> >
>> >Usually as packagers of various popular open source softwares
>correct
>> >enthusiasts' attempts at understanding the sometimes bizarre
>> >complexities of for example autotools, but (although it's all less
>> >complicated) also cmake, it ends up somewhat right. Somewhat. I
>noticed
>> >that especially in corporate world, things tend to go spectacularly
>> >wrong. Almost without exception.
>> >
>> >In particular am I concerned about ABI versioning of shared object
>> >files so that they are easy to package and distribute by various
>> >operating systems (like, among others, Linux distributions). But
>also
>> >API versioning of development files (compiler header files and pkg-
>> >config) and installing to the right installation paths.
>> >
>> >I wanted to invite the community to scrutinize some equivalent
>examples
>> >that I made for autotools (with libtool), qmake, cmake and meson.
>> >
>> >https://github.com/pvanhoof/dir-examples/
>> >
>> >In particular I wanted to invite the cmake community to take a look
>at
>> >this example:
>> >
>> >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
>> >
>> >The idea is that the examples are as correct as possible. That means
>> >the examples should simple and educational. Easing (some amount) of
>> >platform independence (ie. supporting Windows) and packaging.
>> 
>> Is there ANY reason to use libtool library versioning? It might
>surprise
>> people but it really is not any kind of standard.
>> 
>> Just change the SOVERSION when you make incompatible ABI changes and
>a
>> normal library VERSION. There's really not more to it, especially
>nothing
>> like the sick results that libtool produces, sometimes.
>
>I agree.
>I would recommend
>Major version  = SO version, increase it if you break ABI compatibility
>Minor version: increase it if you add ABI compatible features
>Patch version: increase it for bug fix releases.

Right. See http://semver.org

A  tool to check is e.g. the abi compliance checker.

It may be worth to mention that project version and library version may differ but that it also might confuse people.



From daniel.eiband at brainlab.com  Tue Aug  7 06:54:45 2018
From: daniel.eiband at brainlab.com (Daniel Eiband)
Date: Tue, 7 Aug 2018 10:54:45 +0000
Subject: [CMake] Link flags in CMAKE_CXX_CREATE_STATIC_LIBRARY
Message-ID: <5f26d23896ab4e6886a445cf30019c5a@despmsx01.brainlab.net>

Hi,

I'm using CMake on Windows with Ninja and MSVC inside Visual Studio. I'd like to suppress linker warning 4221. To do so I added the following linker flag:

set_property(TARGET MyTarget APPEND PROPERTY LINK_FLAGS "/ignore:4221")

This however doesn't affect the creation of static libraries. The only workaround I found is to manipulate the CMAKE_CXX_CREATE_STATIC_LIBRARY variable:

string(REPLACE "<LINK_FLAGS>" "<LINK_FLAGS> /ignore:4221" CMAKE_CXX_CREATE_STATIC_LIBRARY "${CMAKE_CXX_CREATE_STATIC_LIBRARY}")

Is there a nicer way to do this? Why are the link flags not passed to the static library creation or - if not possible - why are there no static library link flag properties?

Regards,
Daniel

From randy.heiland at gmail.com  Tue Aug  7 08:48:26 2018
From: randy.heiland at gmail.com (Randy Heiland)
Date: Tue, 7 Aug 2018 08:48:26 -0400
Subject: [CMake] simple find_package example
In-Reply-To: <21015618.ipb0pL2FiA@linux-l7nd>
References: <CAO_spu5nvHMVow2=Bt8nrTLsHZPgq1X_psjNy7fb5Q0hriMU8w@mail.gmail.com>
 <21015618.ipb0pL2FiA@linux-l7nd>
Message-ID: <CAO_spu6K+MQw_ZYQYQ9mH=DTwL=6ftv5gpvJNDYp_E1vmka-ow@mail.gmail.com>

Hmm, well if that's the case, how does one generate the HelloConfig.cmake
file?

Although, for my particular situation, my question about wanting to
generate a "Find" file still remains, I think. I have a library which is,
potentially, useful to several projects. I assume there's some sort of
"Find" template for any such lib, i.e., a project needs to be able to
locate a lib (static or dynamic) and headers, cross-platform.

thanks, Randy

On Mon, Aug 6, 2018 at 4:09 PM, Alexander Neundorf <neundorf at kde.org> wrote:

> On 2018 M08 2, Thu 10:01:39 CEST Randy Heiland wrote:
> > Hi,
> >
> > I'd like to figure out how to modify the simple "hello" demo (
> > https://cmake.org/examples/) so that the Hello project is a library
> with an
> > accompanying FindHello.cmake and then the Demo project uses that
> > information and "find_package" to discover/use it.
> >
> > Hopefully that makes sense. Basically, I'm looking for a simple tutorial
> on
> > how I can make my library easily accessible to a CMake project.
>
> for that, you don't want a FindHello.cmake (which would typically be
> shipped
> either by cmake or by the consuming application), instead you want to
> generate
> and install a HelloConfig.cmake file.
>
> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180807/4be6f931/attachment-0001.html>

From gavin.wheeler at kcl.ac.uk  Tue Aug  7 12:15:28 2018
From: gavin.wheeler at kcl.ac.uk (Wheeler, Gavin)
Date: Tue, 7 Aug 2018 16:15:28 +0000
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
 <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
Message-ID: <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>

Hi,

Thanks for the suggestions and apologies for my tardiness in getting back on this issue. I'm replying with my experiences for other to use as a future reference, hopefully they can avoid some of the frustration I've encountered.

I spent half a day on this with two colleagues who are well versed in using CMake, and we found a simple solution.

DON'T BOTHER!

"Windows + CMake + source boost "build seems intractable, or at the very least intractable enough to basically be impossible, or at any rate just not worth bothering with.

If are using Windows and you rate your sanity and time higher than you rate the ability to use CMake and a source build of boost together I suggest you do the following...


1.       Look in C:\Program Files\CMake\share\cmake-3.9\Modules\FindBoost.cmake

2.       Search for _Boost_KNOWN_VERSIONS

3.       Download the binary build of the newest version listed from https://sourceforge.net/projects/boost/files/boost-binaries/

4.       If Windows Defender has a wobbly and your IT policy won't allow you to ignore the wobble then move back thorugh older versions until one works

5.       Install the boost to the default location and default settings

6.       Run CMake with the following sort of thing...

    find_package(Boost REQUIRED COMPONENTS system filesystem thread date_time iostreams)
    include_directories(${Boost_INCLUDE_DIRS})
    link_directories(${Boost_LIBRARY_DIRS})


7.       ...relax and make a nice cup of tea

Best Regards,

Gavin


From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Dvir Yitzchaki
Sent: 15 July 2018 08:27
To: Innokentiy Alaytsev <alaitsev at gmail.com>; cmake at cmake.org
Subject: Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?


I recommend using Hunter package manager:

https://docs.hunter.sh/en/latest/quick-start/boost-components.html<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.hunter.sh%2Fen%2Flatest%2Fquick-start%2Fboost-components.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=iwvlHuibo8%2Fu3bGB1woxV5fcI7T6daJRHII5l37dzGc%3D&reserved=0>



Regards,

Dvir



-----Original Message-----
From: CMake <cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>> On Behalf Of Innokentiy Alaytsev
Sent: Thursday, July 12, 2018 13:29
To: cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?



Hello!



First of all, I suggest you use Boost imported targets instead of Boost_INCLUDE_DIRS and Boost_LIBRARY_DIRS and the

target_include_directories() and target_link_libraries() functions. Al this is to better support exporting CMake package if you need it. If you do not produce CMake package for use in some other projects, then just ignore this advice.



Second, just use  pre-built Boost binaries <https://dl.bintray.com/boostorg/release/1.67.0/binaries/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.bintray.com%2Fboostorg%2Frelease%2F1.67.0%2Fbinaries%2F&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=p7Gr9TztBZhINb3iTb9PZJs0oOSp3fu%2FkR5HtZs624M%3D&reserved=0>>  . They are just fine. If your Windows Defender finds something in them then it's the problem in Windows Defender.



Best regards,

Innokentiy Alaytsev







--

Sent from: http://cmake.3232098.n2.nabble.com/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.3232098.n2.nabble.com%2F&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=Bn6BpFHeaEY%2FPICsFuyxhedwJz74DnCqPj6JwX1OCWU%3D&reserved=0>

--



Powered by www.kitware.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=h%2B9%2FVFYma%2BR7EpgKMbW2SK0y8nmoVzSnUgUSauMofWI%3D&reserved=0>



Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=8qV0sbl6p82iFJjdrr5BpcU1Gl6fmgB%2Ba%2Bl5TW3xMVU%3D&reserved=0>



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



CMake Support: http://cmake.org/cmake/help/support.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=TnN9QdIdT1U%2Ffpb%2Fco%2BTeQ7FjVnHmT%2BAi61qKomtbx8%3D&reserved=0>

CMake Consulting: http://cmake.org/cmake/help/consulting.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=QSq%2FThpzrrKQxGKslOFRJeAfdjApu%2FQG8v4nGb6IC74%3D&reserved=0>

CMake Training Courses: http://cmake.org/cmake/help/training.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=c72JN2QChO0q6k6OMmT3Z%2B%2BTM5lEiQ4DG%2BtoMud5kNY%3D&reserved=0>



Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=JRGE6gVyK3u%2FOVq5r1E9fSkWl9cU8EHzDE%2F8ujZCi8s%3D&reserved=0>



Follow this link to subscribe/unsubscribe:

https://cmake.org/mailman/listinfo/cmake<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Ce36bc216c96b4234004408d5ea267d17%7C8370cf1416f34c16b83c724071654356%7C0&sdata=6O6VKBtD6BlbqMIMvU5HGUy723y%2BW%2BLiRofNuPDi8Jw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180807/1e7f2ee1/attachment-0001.html>

From mateusz at loskot.net  Tue Aug  7 12:34:03 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Tue, 7 Aug 2018 18:34:03 +0200
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
 <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
 <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>
Message-ID: <CABUeae95=2QAJY7aPmQRQobpvRYLcAOw+EnG1=ptq-S6vP2knQ@mail.gmail.com>

On 7 August 2018 at 18:15, Wheeler, Gavin <gavin.wheeler at kcl.ac.uk> wrote:
> [...]
> 1.       Look in C:\Program
> Files\CMake\share\cmake-3.9\Modules\FindBoost.cmake

Rule #1: never use CMake older than the latest release!

Rule #2: if you die hard for old CMake, force use of the latest FindBoost.cmake

if (CMAKE_VERSION VERSION_LESS 3.12)
  if (NOT EXISTS "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
    message(STATUS "You are using CMake older than 3.10")
    message(STATUS "FindBoost.cmake has likely been updated to detect
newer or even not yet released Boost")
    message(STATUS "Downloading FindBoost.cmake from
https://gitlab.kitware.com/cmake/ release branch")
    message(STATUS "The auto-download can be disabled with
GIL_DISABLE_FINDBOOST_DOWNLOAD=ON")
    file(DOWNLOAD
      "https://gitlab.kitware.com/cmake/cmake/raw/release/Modules/FindBoost.cmake"
      "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
  endif()
  list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_BINARY_DIR}/cmake)
endif()


The rules work most of the time, unless a lil' bug sneaks in eg.

https://gitlab.kitware.com/cmake/cmake/merge_requests/1731
https://gitlab.kitware.com/cmake/cmake/issues/17701

Remember, FindBoost.cmake is *always* a step or two behind CMake release.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From johannes at zarl-zierl.at  Tue Aug  7 17:23:09 2018
From: johannes at zarl-zierl.at (Johannes Zarl-Zierl)
Date: Tue, 07 Aug 2018 23:23:09 +0200
Subject: [CMake] simple find_package example
In-Reply-To: <CAO_spu6K+MQw_ZYQYQ9mH=DTwL=6ftv5gpvJNDYp_E1vmka-ow@mail.gmail.com>
References: <CAO_spu5nvHMVow2=Bt8nrTLsHZPgq1X_psjNy7fb5Q0hriMU8w@mail.gmail.com>
 <21015618.ipb0pL2FiA@linux-l7nd>
 <CAO_spu6K+MQw_ZYQYQ9mH=DTwL=6ftv5gpvJNDYp_E1vmka-ow@mail.gmail.com>
Message-ID: <1802081.QpUKiA5gKj@mani>

Am Dienstag, 7. August 2018, 14:48:26 CEST schrieb Randy Heiland:
> Hmm, well if that's the case, how does one generate the HelloConfig.cmake
> file?

The official documentation is here:
https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html

> Although, for my particular situation, my question about wanting to
> generate a "Find" file still remains, I think. I have a library which is,
> potentially, useful to several projects. I assume there's some sort of
> "Find" template for any such lib, i.e., a project needs to be able to
> locate a lib (static or dynamic) and headers, cross-platform.

Im almost positively sure that you don't want a FindXYZ.cmake, but a 
XYZConfig.cmake file instead. These are the main differences between Find-
module packages and config-file packages:

Find-Module packages:
- are written and maintained independently of the "consumed" project
  (usually because the project does not support CMake)
- are usually shipped by the consuming project
- are hard to get right (they have to deal with strange installations, or old 
versions of the software, etc.)

Config-file packages:
- are generated by the "consumed" project
- are shipped by the consumed project
- have tooling to ensure correctness


For the consuming project, there's no visible difference between both (you 
call "find_package(XYZ)" and cmake uses whatever it finds. In principle, it's 
even possible to use both together (note: please don't).

That said, the official documentation can be a bit overwhelming at first.
You probably can write some kind of cmake-2.6-style Find-Module package in 
less time, but the time to do it "right" is worth your effort.

Just start by reading the documentation and don't hesitate to ask when you hit 
a problem?

Cheers,
  Johannes




From gavin.wheeler at kcl.ac.uk  Wed Aug  8 05:53:19 2018
From: gavin.wheeler at kcl.ac.uk (Wheeler, Gavin)
Date: Wed, 8 Aug 2018 09:53:19 +0000
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <CABUeae95=2QAJY7aPmQRQobpvRYLcAOw+EnG1=ptq-S6vP2knQ@mail.gmail.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
 <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
 <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CABUeae95=2QAJY7aPmQRQobpvRYLcAOw+EnG1=ptq-S6vP2knQ@mail.gmail.com>
Message-ID: <AM6PR03MB34939C92904AB13365F3E4CABF260@AM6PR03MB3493.eurprd03.prod.outlook.com>

Hi Mateusz,

I absolutely agree - use the latest CMake! That will help fix and bugs and ensure it works with more up-to-date versions of Boost.

My cut and paste instructions were from 2 different computers, and the one I wrote the mail on has an older version of CMake - I wasn't suggesting people purposely use an old version, more to use the steps with the latest version. I've just got a new development machine - so now I'm working with new CMake :)

So, if I may, I will add another step...

0. Download and install the latest CMake

Thank-you,

Gavin


-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateusz Loskot
Sent: 07 August 2018 17:34
To: cmake at cmake.org
Subject: Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?

On 7 August 2018 at 18:15, Wheeler, Gavin <gavin.wheeler at kcl.ac.uk> wrote:
> [...]
> 1.       Look in C:\Program
> Files\CMake\share\cmake-3.9\Modules\FindBoost.cmake

Rule #1: never use CMake older than the latest release!

Rule #2: if you die hard for old CMake, force use of the latest FindBoost.cmake

if (CMAKE_VERSION VERSION_LESS 3.12)
  if (NOT EXISTS "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
    message(STATUS "You are using CMake older than 3.10")
    message(STATUS "FindBoost.cmake has likely been updated to detect newer or even not yet released Boost")
    message(STATUS "Downloading FindBoost.cmake from
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2F&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=2ORH%2BnLCBqCDNIwIrs7%2FkcdPZhtP8hYE%2FVKrBe%2FYpDQ%3D&amp;reserved=0 release branch")
    message(STATUS "The auto-download can be disabled with
GIL_DISABLE_FINDBOOST_DOWNLOAD=ON")
    file(DOWNLOAD
      "https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fraw%2Frelease%2FModules%2FFindBoost.cmake&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=W9QJth1ZQZiT2VlDaub2rUgsS8BnhT7Ps5STKlzqma8%3D&amp;reserved=0"
      "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
  endif()
  list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_BINARY_DIR}/cmake)
endif()


The rules work most of the time, unless a lil' bug sneaks in eg.

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fmerge_requests%2F1731&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=MaRqgu7Rz8TwUvwQD%2FgIfm6bPje3spWfzDwwA%2BIQ5rA%3D&amp;reserved=0
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fissues%2F17701&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=eB9j5AGT7EW1TPeGXHxIyvstvLIjk8NlscleVeOPFJk%3D&amp;reserved=0

Remember, FindBoost.cmake is *always* a step or two behind CMake release.

Best regards,
--
Mateusz Loskot, https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmateusz.loskot.net&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=LyXA5Iv76X0qxQKYT1ts6%2Fvtc%2F2v%2BEa9g778QoL6%2BdI%3D&amp;reserved=0
-- 

Powered by https://emea01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=%2BUZyhXV9EXuLreYKa2Kx9yAnlzN9X5%2Fpw8%2FeV%2BUrCoE%3D&amp;reserved=0

Please keep messages on-topic and check the CMake FAQ at: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=L2gB6A4DMwOI%2BwD%2FK2lwDRQf%2BaHJ4K9gi52cYRG2fSk%3D&amp;reserved=0

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

CMake Support: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=Tjljc0Fic6aB7lm2Idu0TOj%2B2MAT8iGNBESYsJ0rqR4%3D&amp;reserved=0
CMake Consulting: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=jeQYQWP0dYxBfc6vF7gSllG3k%2BDxmSjufD8h58SWOkA%3D&amp;reserved=0
CMake Training Courses: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=JmQKOS6nZLEMKNi%2BS02znt9SX1fEDT9hBNfMJm89Lt0%3D&amp;reserved=0

Visit other Kitware open-source projects at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=01SHgapkca41kiv%2FRNuTM4DGl0rljDn6Vc1a70ZSSKg%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=Q9Nrpc%2FA52FFCvo%2B3JCU5XWBWMFqbtiq6OvG2Oc3pvA%3D&amp;reserved=0

From sd at syntonetic.com  Wed Aug  8 06:29:04 2018
From: sd at syntonetic.com (=?UTF-8?B?U8O4cmVu?=)
Date: Wed, 8 Aug 2018 12:29:04 +0200
Subject: [CMake] Can't find boost libs on VS2017 CMake 3.12
In-Reply-To: <2c402bc4-7918-65d3-ac5e-954afd8d03c7@syntonetic.com>
References: <5beefc68-c81f-06ae-3ce5-f5ced37f2f13@syntonetic.com>
 <FE0120B6-1369-4F3E-9925-2EFA2C9C6037@gmail.com>
 <6ACE6ED3-5836-45D9-BC62-5F29BBC3AE01@kant.sophonet.de>
 <2c402bc4-7918-65d3-ac5e-954afd8d03c7@syntonetic.com>
Message-ID: <4bd6b57c-5f51-8b10-70ad-1e6ab0d95cf3@syntonetic.com>

Update: I put this before find packages boost and now it WORKS:

if (WIN32)
 ? set (Boost_USE_STATIC_LIBS ON)
endif (WIN32)

Think I tried this earlier with no luck but it may have been obscured by 
cache or some other attempts.

On 03-08-2018 13:24, S?ren wrote:
> Thanks
>
> Debug output shows
> * that it already searchs in the right folders.
> * It appears to search for the right patterns e.g. 
> "boost_chrono-vc141-mt-x64-1_67" (file is there 
> "libboost_chrono-vc141-mt-x64-1_67.lib")
> * It also states? "Boost_FOUND = 1"
>
> But still that error. So far I can't see from the debug output why it 
> fails.

-- 

Best regards,

S?ren Dyrsting

Senior Software Engineer

cid:image001.png at 01D38889.00F59D30

T: +45 36 16 36 00

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180808/a8c620a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adfhcmicfbldodni.png
Type: image/png
Size: 5848 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180808/a8c620a0/attachment-0001.png>

From chris+cmake at qwirx.com  Wed Aug  8 07:39:23 2018
From: chris+cmake at qwirx.com (Chris Wilson)
Date: Wed, 8 Aug 2018 12:39:23 +0100
Subject: [CMake] Fwd:  Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <CAOg7f83CEjN=2Lz8eXCREhkrvSigwXjJQzj-_NsR++GzjkYdEw@mail.gmail.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
 <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
 <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CABUeae95=2QAJY7aPmQRQobpvRYLcAOw+EnG1=ptq-S6vP2knQ@mail.gmail.com>
 <AM6PR03MB34939C92904AB13365F3E4CABF260@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CAOg7f83CEjN=2Lz8eXCREhkrvSigwXjJQzj-_NsR++GzjkYdEw@mail.gmail.com>
Message-ID: <CAOg7f83Z4TPqvuT11_8eDu6+dtsoNdWcwK7qysCkV2dgnXd08Q@mail.gmail.com>

Hi all,

I solved this problem (or a very similar one) by using a CMake superbuild
<https://github.com/boxbackup/boxbackup/blob/master/infrastructure/cmake/windows/CMakeLists.txt>
which builds Boost and then my project, like this:

# Version of Boost to download, unpack, and compile Box Backup against:
set(BOOST_VERSION    1.62.0)
# Hash of the Boost download file, to be verified after download:
set(BOOST_HASH SHA1=5fd97433c3f859d8cbab1eaed4156d3068ae3648)
...
string(REPLACE "." "_" BOOST_VERSION_UNDERSCORES ${BOOST_VERSION})
ExternalProject_Add(boost
URL "http://downloads.sourceforge.net/project/boost/boost/${
BOOST_VERSION}/boost_${BOOST_VERSION_UNDERSCORES}.tar.bz2"
URL_HASH ${BOOST_HASH}
# DOWNLOAD_NO_PROGRESS 1
# Disable automatic updating (untarring) as it's slow and not necessary
UPDATE_DISCONNECTED 1
CONFIGURE_COMMAND ${CMAKE_COMMAND} -E echo "No configure step needed"
BUILD_COMMAND ${CMAKE_COMMAND} -E echo "No build step needed"
INSTALL_COMMAND ${CMAKE_COMMAND} -E echo "No install step needed"
)
...
ExternalProject_Add(boxbackup
DEPENDS zlib openssl pcre boost
SOURCE_DIR ${boxbackup_dir}/infrastructure/cmake
CMAKE_ARGS
-DZLIB_ROOT=${install_dir}
-DOPENSSL_ROOT_DIR=${install_dir}
-DPCRE_ROOT=${install_dir}
*-DBOOST_ROOT=${CMAKE_BINARY_DIR}/Source/boost*
-DBOX_SUPPORT_READLINE=OFF
-DCMAKE_INSTALL_PREFIX=${install_dir}
-DAPPVEYOR_MODE=1
-DDEBUG=${DEBUG}
${boxbackup_cmake_args}
${SUB_CMAKE_EXTRA_ARGS}
INSTALL_COMMAND ${CMAKE_COMMAND} -E echo "No install step needed"
STEP_TARGETS configure build
)


Having set BOOST_ROOT, FindBoost should just work.

In this case, I didn't need to compile any of Boost, only its headers, but
if you do need to, then you can change its CONFIGURE_COMMAND and
BUILD_COMMAND.

Hope this helps.

Thanks, Chris.


On 8 August 2018 at 10:53, Wheeler, Gavin <gavin.wheeler at kcl.ac.uk> wrote:

> Hi Mateusz,
>
> I absolutely agree - use the latest CMake! That will help fix and bugs and
> ensure it works with more up-to-date versions of Boost.
>
> My cut and paste instructions were from 2 different computers, and the one
> I wrote the mail on has an older version of CMake - I wasn't suggesting
> people purposely use an old version, more to use the steps with the latest
> version. I've just got a new development machine - so now I'm working with
> new CMake :)
>
> So, if I may, I will add another step...
>
> 0. Download and install the latest CMake
>
> Thank-you,
>
> Gavin
>
>
> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateusz Loskot
> Sent: 07 August 2018 17:34
> To: cmake at cmake.org
> Subject: Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?
>
> On 7 August 2018 at 18:15, Wheeler, Gavin <gavin.wheeler at kcl.ac.uk> wrote:
> > [...]
> > 1.       Look in C:\Program
> > Files\CMake\share\cmake-3.9\Modules\FindBoost.cmake
>
> Rule #1: never use CMake older than the latest release!
>
> Rule #2: if you die hard for old CMake, force use of the latest
> FindBoost.cmake
>
> if (CMAKE_VERSION VERSION_LESS 3.12)
>   if (NOT EXISTS "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
>     message(STATUS "You are using CMake older than 3.10")
>     message(STATUS "FindBoost.cmake has likely been updated to detect
> newer or even not yet released Boost")
>     message(STATUS "Downloading FindBoost.cmake from
> https://emea01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fgitlab.kitware.com%2Fcmake%2F&amp;data=01%7C01%
> 7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b2
> 15%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=2ORH%2Bn
> LCBqCDNIwIrs7%2FkcdPZhtP8hYE%2FVKrBe%2FYpDQ%3D&amp;reserved=0 release
> branch")
>     message(STATUS "The auto-download can be disabled with
> GIL_DISABLE_FINDBOOST_DOWNLOAD=ON")
>     file(DOWNLOAD
>       "https://emea01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fraw%2Freleas
> e%2FModules%2FFindBoost.cmake&amp;data=01%7C01%7Cgavin.
> wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C837
> 0cf1416f34c16b83c724071654356%7C0&amp;sdata=W9QJth1ZQZiT2VlD
> aub2rUgsS8BnhT7Ps5STKlzqma8%3D&amp;reserved=0"
>       "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
>   endif()
>   list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_BINARY_DIR}/cmake)
> endif()
>
>
> The rules work most of the time, unless a lil' bug sneaks in eg.
>
> https://emea01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fmerge_reques
> ts%2F1731&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C
> f685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c72407
> 1654356%7C0&amp;sdata=MaRqgu7Rz8TwUvwQD%2FgIfm6bPje3spWfzDww
> A%2BIQ5rA%3D&amp;reserved=0
> https://emea01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fissues%2F177
> 01&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba54
> 2e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%
> 7C0&amp;sdata=eB9j5AGT7EW1TPeGXHxIyvstvLIjk8NlscleVeOPFJk%
> 3D&amp;reserved=0
>
> Remember, FindBoost.cmake is *always* a step or two behind CMake release.
>
> Best regards,
> --
> Mateusz Loskot, https://emea01.safelinks.protection.outlook.com/?url=http%
> 3A%2F%2Fmateusz.loskot.net&amp;data=01%7C01%7Cgavin.wheel
> er%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf14
> 16f34c16b83c724071654356%7C0&amp;sdata=LyXA5Iv76X0qxQKYT1ts
> 6%2Fvtc%2F2v%2BEa9g778QoL6%2BdI%3D&amp;reserved=0
> --
>
> Powered by https://emea01.safelinks.protection.outlook.com/?url=www.
> kitware.com&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C
> f685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c72407
> 1654356%7C0&amp;sdata=%2BUZyhXV9EXuLreYKa2Kx9yAnlzN9X5%
> 2Fpw8%2FeV%2BUrCoE%3D&amp;reserved=0
>
> Please keep messages on-topic and check the CMake FAQ at:
> https://emea01.safelinks.protection.outlook.com/?url=http%
> 3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&amp;data=01%7C01%
> 7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b2
> 15%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=L2gB6A4D
> MwOI%2BwD%2FK2lwDRQf%2BaHJ4K9gi52cYRG2fSk%3D&amp;reserved=0
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: https://emea01.safelinks.protection.outlook.com/?url=http%
> 3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&amp;
> data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e784971
> 3baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;
> sdata=Tjljc0Fic6aB7lm2Idu0TOj%2B2MAT8iGNBESYsJ0rqR4%3D&amp;reserved=0
> CMake Consulting: https://emea01.safelinks.prote
> ction.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%
> 2Fhelp%2Fconsulting.html&amp;data=01%7C01%7Cgavin.wheeler%
> 40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f
> 34c16b83c724071654356%7C0&amp;sdata=jeQYQWP0dYxBfc6vF7gSllG3
> k%2BDxmSjufD8h58SWOkA%3D&amp;reserved=0
> CMake Training Courses: https://emea01.safelinks.prote
> ction.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%
> 2Fhelp%2Ftraining.html&amp;data=01%7C01%7Cgavin.wheeler%
> 40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f
> 34c16b83c724071654356%7C0&amp;sdata=JmQKOS6nZLEMKNi%2BS02znt
> 9SX1fEDT9hBNfMJm89Lt0%3D&amp;reserved=0
>
> Visit other Kitware open-source projects at https://emea01.safelinks.prote
> ction.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopen
> source%2Fopensource.html&amp;data=01%7C01%7Cgavin.wheeler%
> 40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f
> 34c16b83c724071654356%7C0&amp;sdata=01SHgapkca41kiv%2FRNuTM4
> DGl0rljDn6Vc1a70ZSSKg%3D&amp;reserved=0
>
> Follow this link to subscribe/unsubscribe:
> https://emea01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&amp;data=
> 01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08
> d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=
> Q9Nrpc%2FA52FFCvo%2B3JCU5XWBWMFqbtiq6OvG2Oc3pvA%3D&amp;reserved=0
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180808/e80fad62/attachment-0001.html>

From rleigh at codelibre.net  Wed Aug  8 07:45:56 2018
From: rleigh at codelibre.net (Roger Leigh)
Date: Wed, 8 Aug 2018 12:45:56 +0100
Subject: [CMake] Fwd: Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <CAOg7f83Z4TPqvuT11_8eDu6+dtsoNdWcwK7qysCkV2dgnXd08Q@mail.gmail.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
 <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
 <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CABUeae95=2QAJY7aPmQRQobpvRYLcAOw+EnG1=ptq-S6vP2knQ@mail.gmail.com>
 <AM6PR03MB34939C92904AB13365F3E4CABF260@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CAOg7f83CEjN=2Lz8eXCREhkrvSigwXjJQzj-_NsR++GzjkYdEw@mail.gmail.com>
 <CAOg7f83Z4TPqvuT11_8eDu6+dtsoNdWcwK7qysCkV2dgnXd08Q@mail.gmail.com>
Message-ID: <b276a4f9-4066-8788-3741-9ce5ab856955@codelibre.net>

On 08/08/18 12:39, Chris Wilson wrote:
> Having set BOOST_ROOT, FindBoost should just work.
> 
> In this case, I didn't need to compile any of Boost, only its headers, 
> but if you do need to, then you can change its CONFIGURE_COMMAND?and 
> BUILD_COMMAND.

Portable build and configure commands can be found here: 
https://github.com/ome/ome-cmake-superbuild/tree/master/packages/boost

There are plenty of other examples as well if you have a search around.

Regards,
Roger

From cmake at kant.sophonet.de  Wed Aug  8 15:58:03 2018
From: cmake at kant.sophonet.de (Sophonet)
Date: Wed, 8 Aug 2018 21:58:03 +0200
Subject: [CMake] VS 2017 + CUDA 9.0
In-Reply-To: <CAFzjYVqUDK7VA6KUgkbcj3TYXAtP0pcCyhsq-Y68Rw97m0Sf=g@mail.gmail.com>
References: <E7C0AA0B-4188-4152-A785-C3364B852625@kant.sophonet.de>
 <CAFzjYVqUDK7VA6KUgkbcj3TYXAtP0pcCyhsq-Y68Rw97m0Sf=g@mail.gmail.com>
Message-ID: <C47C074B-A771-45B7-AD0D-98FF6AC6E7E0@kant.sophonet.de>

Hi Robert,

thanks for the hint - indeed, it somewhat solved the problems I have mentioned. However, the CMake backend for CUDA (one of the preprocessing steps in CUDA_ADD_LIBRARY for example) calls nvcc -M (do get dependencies), and this command first tries to load vcvars.bat without any command line options. Therefore, nvcc -M still sees the default toolkit and not the one which I have specified with CMAKE_GENERATOR_TOOLSET=?version=14.11?.

The only solution up to now is to run the vcvars.bat script from VS 2017 before doing any cmake operations with the option "-vcvars_ver=14.11?, such that the INCLUDE_PATH variables etc are already set to the right value before nvcc tries to set them anew (with the wrong value).

Any hint how this can be added to the CUDA functionality in CMake? I guess others might stumble across this problem as well.

Thanks,

    Sophonet

> Am 02.08.2018 um 22:50 schrieb Robert Maynard <robert.maynard at kitware.com>:
> 
> When initially configuring a project you can specify which toolset you
> would like to use. Starting in CMake 3.12 this now also supports
> specifying which patch version. You can see what the syntax looks like
> at: https://cmake.org/cmake/help/v3.12/release/3.12.html#id3
> On Thu, Aug 2, 2018 at 4:12 PM Sophonet <cmake at kant.sophonet.de> wrote:
>> 
>> Hi list,
>> 
>> it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires an old toolset to be installed for successful compilation (15.4, see https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/). The new VS 2017 toolset have an incompatible _MSC_VER variable, among other things.
>> 
>> The link above mentions to manually revert the toolset for a solution, but I was wondering how CMake-based projects could be configured to automatically pick the 15.4 toolset (which has version 14.11 instead of 14.12). The CMake documentation for toolsets is somehow sparse and only mentions toolsets with name ?v141?, which I think would apply for both. Any hints to find out (i) what toolsets are actually available for a specific compiler or (ii) forcing toolset 14.12 as mentioned above - without manual editing of the vcproj project files?
>> 
>> Thanks,
>> 
>>        Sophonet
>> 
>> 
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake

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

From robert.maynard at kitware.com  Wed Aug  8 16:02:16 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 8 Aug 2018 16:02:16 -0400
Subject: [CMake] VS 2017 + CUDA 9.0
In-Reply-To: <C47C074B-A771-45B7-AD0D-98FF6AC6E7E0@kant.sophonet.de>
References: <E7C0AA0B-4188-4152-A785-C3364B852625@kant.sophonet.de>
 <CAFzjYVqUDK7VA6KUgkbcj3TYXAtP0pcCyhsq-Y68Rw97m0Sf=g@mail.gmail.com>
 <C47C074B-A771-45B7-AD0D-98FF6AC6E7E0@kant.sophonet.de>
Message-ID: <CAFzjYVrYv3iU8VUVhiZSWTCkp_z43CGn7EEnkqYN2_M7KQm4dA@mail.gmail.com>

The CUDA_ADD_LIBRARY infrastructure is deprecated and it is
understandable that it isn't aware of the toolsets since it is based
on custom commands.

I recommend using the new CUDA first class language support. You can
find an intro blog post on using this at:
https://devblogs.nvidia.com/building-cuda-applications-cmake/
On Wed, Aug 8, 2018 at 3:58 PM Sophonet <cmake at kant.sophonet.de> wrote:
>
> Hi Robert,
>
> thanks for the hint - indeed, it somewhat solved the problems I have mentioned. However, the CMake backend for CUDA (one of the preprocessing steps in CUDA_ADD_LIBRARY for example) calls nvcc -M (do get dependencies), and this command first tries to load vcvars.bat without any command line options. Therefore, nvcc -M still sees the default toolkit and not the one which I have specified with CMAKE_GENERATOR_TOOLSET=?version=14.11?.
>
> The only solution up to now is to run the vcvars.bat script from VS 2017 before doing any cmake operations with the option "-vcvars_ver=14.11?, such that the INCLUDE_PATH variables etc are already set to the right value before nvcc tries to set them anew (with the wrong value).
>
> Any hint how this can be added to the CUDA functionality in CMake? I guess others might stumble across this problem as well.
>
> Thanks,
>
>     Sophonet
>
> Am 02.08.2018 um 22:50 schrieb Robert Maynard <robert.maynard at kitware.com>:
>
> When initially configuring a project you can specify which toolset you
> would like to use. Starting in CMake 3.12 this now also supports
> specifying which patch version. You can see what the syntax looks like
> at: https://cmake.org/cmake/help/v3.12/release/3.12.html#id3
> On Thu, Aug 2, 2018 at 4:12 PM Sophonet <cmake at kant.sophonet.de> wrote:
>
>
> Hi list,
>
> it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires an old toolset to be installed for successful compilation (15.4, see https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/). The new VS 2017 toolset have an incompatible _MSC_VER variable, among other things.
>
> The link above mentions to manually revert the toolset for a solution, but I was wondering how CMake-based projects could be configured to automatically pick the 15.4 toolset (which has version 14.11 instead of 14.12). The CMake documentation for toolsets is somehow sparse and only mentions toolsets with name ?v141?, which I think would apply for both. Any hints to find out (i) what toolsets are actually available for a specific compiler or (ii) forcing toolset 14.12 as mentioned above - without manual editing of the vcproj project files?
>
> Thanks,
>
>        Sophonet
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>

From crestchristopher at gmail.com  Wed Aug  8 20:06:11 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Wed, 8 Aug 2018 20:06:11 -0400
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <5c19dfd8-e9e3-e9b7-7480-738cf1bfc4e7@ifm-chemnitz.de>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <e0f87249-4d03-914c-b371-9a926eda84bf@ifm-chemnitz.de>
 <d4bdf26d-5542-c0be-62ab-5395636703b4@gmail.com>
 <ef55c338-b77f-df77-0dd0-c07293430eef@ifm-chemnitz.de>
 <dd6747bb-f06e-a121-4539-4d5e80ddbf1b@gmail.com>
 <0a158c53-7003-c49f-af28-e9baa3216fd8@ifm-chemnitz.de>
 <58a453d8-6c71-2ec4-e427-66334ae4a8d9@gmail.com>
 <5c19dfd8-e9e3-e9b7-7480-738cf1bfc4e7@ifm-chemnitz.de>
Message-ID: <b2282459-c34a-74d4-900f-919156db8207@gmail.com>

Hi,

 From my understanding I must compile with Powershell ?

These variables mentioned in the appveyor file they are environment 
variables which are set within cPanel ?

What is the first step I need to do and with what file from the 
repository whether in PowerShell or CMake or both ?

Thanks


On 8/3/2018 10:02 AM, Volker Enderlein wrote:
> Hi,
>
> the configuration step of OSL is running this command (via a 
> powershell command), $... denotes always variables defined somewhere 
> in the appveyor file, $env: denotes environment variables.
>
> cmake ..\.. -G "$GENERATOR" 
> -DCMAKE_CONFIGURATION_TYPES="$env:CONFIGURATION" 
> -DCMAKE_PREFIX_PATH="$env:OPENIMAGEIOHOME;$DEP_DIR;$BOOST_ROOT;$LLVM_DIR" 
> -DCMAKE_INSTALL_PREFIX="$DEP_DIR" -DLLVM_DIRECTORY="$LLVM_DIR" 
> -DLLVM_STATIC=ON -DOPENIMAGEIOHOME="$env:OPENIMAGEIOHOME" 
> -DBOOST_LIBRARYDIR="$BOOST_LIBRARYDIR" 
> -DFLEX_EXECUTABLE="C:\ProgramData\chocolatey\lib\winflexbison\tools\win_flex.exe" 
> -DBISON_EXECUTABLE="C:\ProgramData\chocolatey\lib\winflexbison\tools\win_bison.exe" 
> -DUSE_QT=OFF -DBUILDSTATIC=OFF -DLINKSTATIC=OFF
>
> The build step is run via this command:
>
> cmake --build . --config $env:CONFIGURATION -- /nologo /verbosity:minimal
>
> So it builds the entire OSL Project.
>
> As the OSL Toy is included in the master it should be built too. 
> (According to the documentation of the PR you linked to, you should 
> remove "-DUSE_QT=OFF" from the CMake configuration call.) And because 
> you are on Windows using a Visual Studio I suppose you can safely 
> remove -DLLVM_DIRECTORY="$LLVM_DIR" -DLLVM_STATIC=ON (as you are not 
> building with LLVM) and replace -G "$GENERATOR" by -G "Visual Studio 
> 14 2015" or -G "Visual Studio 15 2017". "$env:Configuration" ca be 
> replaced with "Release" (without the double quotes). Other environment 
> variables and variables may need to be replaced by %variable% if you 
> build on a non powershell command prompt. This is not tested, so you 
> may need to adopt other settings too.
>
> I am not aware of any way to build OSL Toy separately. Maybe you 
> should drop Larry Gritz (the committer of the PR) a message asking for 
> further guidance as this is not really a CMake issue rather than a 
> "How do I compile only subproject Y of X" with CMake.
>
> Cheers Volker
>
> Am 03/08/2018 um 14:43 schrieb CrestChristopher:
>> Hi, I assume that the first link I posted which was a link to OSL Toy 
>> within the Open Shading Language repository uses the methods which 
>> you mention to compile the file ?
>>
>>> i.e. the top level directory of the github project, you'll se an 
>>> appveyor.yml file entry. That is the information for the continuous 
>>> integration tool (CI, AppVeyor) they are using to build the project 
>>> from scratch. If you look into it, you'll find a before_build and a 
>>> build_script section. Both contain calls to CMake either to build 
>>> the dependencies (before_build) or the project itself 
>>> (build_script). This is a starting point for you how to formulate 
>>> your CMake call. 
>>
>> With the information within the before_build & build_script section; 
>> how do I formulate the CMake call, as to compile ?
>>
>> Thank You.
>>
>>
>> On 8/3/2018 2:48 AM, Volker Enderlein wrote:
>>> If you go to https://github.com/imageworks/OpenShadingLanguage
>>>
>>> i.e. the top level directory of the github project, you'll se an 
>>> appveyor.yml file entry. That is the information for the continuous 
>>> integration tool (CI, AppVeyor) they are using to build the project 
>>> from scratch. If you look into it, you'll find a before_build and a 
>>> build_script section. Both contain calls to CMake either to build 
>>> the dependencies (before_build) or the project itself 
>>> (build_script). This is a starting point for you how to formulate 
>>> your CMake call.
>>>
>>> Cheers Volker
>>>
>>> Am 03/08/2018 um 02:40 schrieb CrestChristopher:
>>>> Sorry, what is this information for; and how can it be used within 
>>>> the `build_script` section in the appveyor.yml file ?
>>>>
>>>>
>>>> On 8/2/2018 9:30 AM, Volker Enderlein wrote:
>>>>> Please have a look into the appveyor.yml file under section 
>>>>> build_script: you see the typical invocation of cmake for this 
>>>>> github project.
>>>>>
>>>>> Cheers Volker
>>>>>
>>>>> Am 02/08/2018 um 15:18 schrieb CrestChristopher:
>>>>>> I hope this helps; 
>>>>>> https://github.com/imageworks/OpenShadingLanguage/pull/824 ?
>>>>>>
>>>>>>
>>>>>> On 8/1/2018 5:20 PM, Volker Enderlein wrote:
>>>>>>> Am 31.07.2018 um 06:17 schrieb CrestChristopher:
>>>>>>>> Hi, I'm a beginner to CMake and for weeks I've been trying to 
>>>>>>>> compile a CMake file which I found on a github repository.? All 
>>>>>>>> I can say is I have a CMakeLists.txt file but I don't know how 
>>>>>>>> to compile and I hope someone can help ?
>>>>>>>>
>>>>>>>> Christopher
>>>>>>>>
>>>>>>> You may want to include information about the name and the link 
>>>>>>> to the project repository from Github to get the best possible 
>>>>>>> responses. Without that it's just shooting in the dark.
>>>>>>>
>>>>>>> Cheers Volker
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From roman.wueger at gmx.at  Thu Aug  9 03:02:34 2018
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 9 Aug 2018 09:02:34 +0200
Subject: [CMake] Android project with CMake and Visual Studio and without
 Nsight Tegra
Message-ID: <F29AC789-2AFE-4B76-923F-A64909F86DE9@gmx.at>

Hello,

is it somehow possible to build an Android project with CMake and Visual Studio without the Nsight Tegra Visual Studio Edition? Because the installation of NVIDIA Nsight Tegra hangs during configuring the Visual Studio 2017 in a Virtual Machine.

Thanks in advance

Best Regards

From roman.wueger at gmx.at  Thu Aug  9 03:03:54 2018
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 9 Aug 2018 09:03:54 +0200
Subject: [CMake] CMake and Visual Studio Code under linux
Message-ID: <3AD130A5-02AC-4C2C-9E2C-131B60433DAE@gmx.at>

Hello,

how can I configure my Project to run it with the Visual Studio Code under Linux? I did not find a useful generator.

Thanks in advance

Best Regards

From eric.noulard at gmail.com  Thu Aug  9 03:45:09 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 9 Aug 2018 09:45:09 +0200
Subject: [CMake] CMake and Visual Studio Code under linux
In-Reply-To: <3AD130A5-02AC-4C2C-9E2C-131B60433DAE@gmx.at>
References: <3AD130A5-02AC-4C2C-9E2C-131B60433DAE@gmx.at>
Message-ID: <CAPASGLoQvNjLTqawXsTxHiq4Jc+xHtvzkAW1eqRRtqNCTAFQdQ@mail.gmail.com>

Le jeu. 9 ao?t 2018 ? 09:09, Roman W?ger <roman.wueger at gmx.at> a ?crit :

> Hello,
>
> how can I configure my Project to run it with the Visual Studio Code under
> Linux? I did not find a useful generator.
>

AFAIK there is no VSCode generator, however you can install VSCode CMake
Tools extension which begins to interesting to use (my opinion).
See:  https://vector-of-bool.github.io/2018/07/20/cmt-1.1.0.html

interesting meaning I think the project has matured to a point it gives you
many valuable features:
- CMake project view
- Intellisense
...
have a look at the doc as well:
https://vector-of-bool.github.io/docs/vscode-cmake-tools/index.html

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180809/93547f08/attachment.html>

From roman.wueger at gmx.at  Thu Aug  9 05:11:47 2018
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 9 Aug 2018 11:11:47 +0200
Subject: [CMake] CMake and Visual Studio Code under linux
In-Reply-To: <CAPASGLoQvNjLTqawXsTxHiq4Jc+xHtvzkAW1eqRRtqNCTAFQdQ@mail.gmail.com>
References: <3AD130A5-02AC-4C2C-9E2C-131B60433DAE@gmx.at>
 <CAPASGLoQvNjLTqawXsTxHiq4Jc+xHtvzkAW1eqRRtqNCTAFQdQ@mail.gmail.com>
Message-ID: <CB606556-B4B5-4DFB-9560-1170E59FC274@gmx.at>

Thank you, I will give it a try.

Regards
Roman

> Am 09.08.2018 um 09:45 schrieb Eric Noulard <eric.noulard at gmail.com>:
> 
> 
>> Le jeu. 9 ao?t 2018 ? 09:09, Roman W?ger <roman.wueger at gmx.at> a ?crit :
>> Hello,
>> 
>> how can I configure my Project to run it with the Visual Studio Code under Linux? I did not find a useful generator.
> 
> AFAIK there is no VSCode generator, however you can install VSCode CMake Tools extension which begins to interesting to use (my opinion).
> See:  https://vector-of-bool.github.io/2018/07/20/cmt-1.1.0.html
> 
> interesting meaning I think the project has matured to a point it gives you many valuable features:
> - CMake project view
> - Intellisense
> ...
> have a look at the doc as well: https://vector-of-bool.github.io/docs/vscode-cmake-tools/index.html
> 
> -- 
> Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180809/72613f88/attachment.html>

From gavin.wheeler at kcl.ac.uk  Thu Aug  9 05:40:32 2018
From: gavin.wheeler at kcl.ac.uk (Wheeler, Gavin)
Date: Thu, 9 Aug 2018 09:40:32 +0000
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <CAOg7f83CEjN=2Lz8eXCREhkrvSigwXjJQzj-_NsR++GzjkYdEw@mail.gmail.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
 <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>
 <AM6PR03MB3493D3D8AE40924AEF683E27BF270@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CABUeae95=2QAJY7aPmQRQobpvRYLcAOw+EnG1=ptq-S6vP2knQ@mail.gmail.com>
 <AM6PR03MB34939C92904AB13365F3E4CABF260@AM6PR03MB3493.eurprd03.prod.outlook.com>
 <CAOg7f83CEjN=2Lz8eXCREhkrvSigwXjJQzj-_NsR++GzjkYdEw@mail.gmail.com>
Message-ID: <AM6PR03MB34935887E6918D4B17AE1FA7BF250@AM6PR03MB3493.eurprd03.prod.outlook.com>

Hi Chris,

Thanks fort that suggestion too. Right now I have boost integrated using the pre-built libs and the program I need it for is working - so I?m loath to change it.

However, I?ll keep this for future reference, I?m sure it will come in handy.

Best Regards,

Gavin

From: chris at simply-italian.co.uk <chris at simply-italian.co.uk> On Behalf Of Chris Wilson
Sent: 08 August 2018 12:29
To: Wheeler, Gavin <gavin.wheeler at kcl.ac.uk>
Cc: cmake at cmake.org
Subject: Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?

Hi all,

I solved this problem (or a very similar one) by using a CMake superbuild<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboxbackup%2Fboxbackup%2Fblob%2Fmaster%2Finfrastructure%2Fcmake%2Fwindows%2FCMakeLists.txt&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=mlCc8Yqqnmxo7yaEg3SzuAg%2FGvYXseuo7WW5YgGkQw4%3D&reserved=0> which builds Boost and then my project, like this:

# Version of Boost to download, unpack, and compile Box Backup against:
set(BOOST_VERSION    1.62.0)
# Hash of the Boost download file, to be verified after download:
set(BOOST_HASH SHA1=5fd97433c3f859d8cbab1eaed4156d3068ae3648)
...
string(REPLACE "." "_" BOOST_VERSION_UNDERSCORES ${BOOST_VERSION})
ExternalProject_Add(boost
URL "http://downloads.sourceforge.net/project/boost/boost/${BOOST_VERSION}/boost_${BOOST_VERSION_UNDERSCORES}.tar.bz2<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdownloads.sourceforge.net%2Fproject%2Fboost%2Fboost%2F%24%7BBOOST_VERSION%7D%2Fboost_%24%7BBOOST_VERSION_UNDERSCORES%7D.tar.bz2&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=3jIIq9zc4JfBlW0Owf39zmKTDK%2BW%2FFQsnFcESEryyd0%3D&reserved=0>"
URL_HASH ${BOOST_HASH}
# DOWNLOAD_NO_PROGRESS 1
# Disable automatic updating (untarring) as it's slow and not necessary
UPDATE_DISCONNECTED 1
CONFIGURE_COMMAND ${CMAKE_COMMAND} -E echo "No configure step needed"
BUILD_COMMAND ${CMAKE_COMMAND} -E echo "No build step needed"
INSTALL_COMMAND ${CMAKE_COMMAND} -E echo "No install step needed"
)
...
ExternalProject_Add(boxbackup
DEPENDS zlib openssl pcre boost
SOURCE_DIR ${boxbackup_dir}/infrastructure/cmake
CMAKE_ARGS
      -DZLIB_ROOT=${install_dir}
      -DOPENSSL_ROOT_DIR=${install_dir}
      -DPCRE_ROOT=${install_dir}
      -DBOOST_ROOT=${CMAKE_BINARY_DIR}/Source/boost
      -DBOX_SUPPORT_READLINE=OFF
      -DCMAKE_INSTALL_PREFIX=${install_dir}
      -DAPPVEYOR_MODE=1
      -DDEBUG=${DEBUG}
      ${boxbackup_cmake_args}
      ${SUB_CMAKE_EXTRA_ARGS}
INSTALL_COMMAND ${CMAKE_COMMAND} -E echo "No install step needed"
STEP_TARGETS configure build
)

Having set BOOST_ROOT, FindBoost should just work.

In this case, I didn't need to compile any of Boost, only its headers, but if you do need to, then you can change its CONFIGURE_COMMAND and BUILD_COMMAND.

Hope this helps.

Thanks, Chris.


On 8 August 2018 at 10:53, Wheeler, Gavin <gavin.wheeler at kcl.ac.uk<mailto:gavin.wheeler at kcl.ac.uk>> wrote:
Hi Mateusz,

I absolutely agree - use the latest CMake! That will help fix and bugs and ensure it works with more up-to-date versions of Boost.

My cut and paste instructions were from 2 different computers, and the one I wrote the mail on has an older version of CMake - I wasn't suggesting people purposely use an old version, more to use the steps with the latest version. I've just got a new development machine - so now I'm working with new CMake :)

So, if I may, I will add another step...

0. Download and install the latest CMake

Thank-you,

Gavin


-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>] On Behalf Of Mateusz Loskot
Sent: 07 August 2018 17:34
To: cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?

On 7 August 2018 at 18:15, Wheeler, Gavin <gavin.wheeler at kcl.ac.uk<mailto:gavin.wheeler at kcl.ac.uk>> wrote:
> [...]
> 1.       Look in C:\Program
> Files\CMake\share\cmake-3.9\Modules\FindBoost.cmake

Rule #1: never use CMake older than the latest release!

Rule #2: if you die hard for old CMake, force use of the latest FindBoost.cmake

if (CMAKE_VERSION VERSION_LESS 3.12)
  if (NOT EXISTS "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
    message(STATUS "You are using CMake older than 3.10")
    message(STATUS "FindBoost.cmake has likely been updated to detect newer or even not yet released Boost")
    message(STATUS "Downloading FindBoost.cmake from
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2F&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=2ORH%2BnLCBqCDNIwIrs7%2FkcdPZhtP8hYE%2FVKrBe%2FYpDQ%3D&amp;reserved=0 release branch")
    message(STATUS "The auto-download can be disabled with
GIL_DISABLE_FINDBOOST_DOWNLOAD=ON")
    file(DOWNLOAD
      "https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fraw%2Frelease%2FModules%2FFindBoost.cmake&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=W9QJth1ZQZiT2VlDaub2rUgsS8BnhT7Ps5STKlzqma8%3D&amp;reserved=0"
      "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
  endif()
  list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_BINARY_DIR}/cmake)
endif()


The rules work most of the time, unless a lil' bug sneaks in eg.

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fmerge_requests%2F1731&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=MaRqgu7Rz8TwUvwQD%2FgIfm6bPje3spWfzDwwA%2BIQ5rA%3D&amp;reserved=0
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fissues%2F17701&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=eB9j5AGT7EW1TPeGXHxIyvstvLIjk8NlscleVeOPFJk%3D&amp;reserved=0

Remember, FindBoost.cmake is *always* a step or two behind CMake release.

Best regards,
--
Mateusz Loskot, https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmateusz.loskot.net&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=LyXA5Iv76X0qxQKYT1ts6%2Fvtc%2F2v%2BEa9g778QoL6%2BdI%3D&amp;reserved=0
--

Powered by https://emea01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=%2BUZyhXV9EXuLreYKa2Kx9yAnlzN9X5%2Fpw8%2FeV%2BUrCoE%3D&amp;reserved=0

Please keep messages on-topic and check the CMake FAQ at: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=L2gB6A4DMwOI%2BwD%2FK2lwDRQf%2BaHJ4K9gi52cYRG2fSk%3D&amp;reserved=0

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

CMake Support: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=Tjljc0Fic6aB7lm2Idu0TOj%2B2MAT8iGNBESYsJ0rqR4%3D&amp;reserved=0
CMake Consulting: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=jeQYQWP0dYxBfc6vF7gSllG3k%2BDxmSjufD8h58SWOkA%3D&amp;reserved=0
CMake Training Courses: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=JmQKOS6nZLEMKNi%2BS02znt9SX1fEDT9hBNfMJm89Lt0%3D&amp;reserved=0

Visit other Kitware open-source projects at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=01SHgapkca41kiv%2FRNuTM4DGl0rljDn6Vc1a70ZSSKg%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&amp;data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7Cf685ba542e7849713baa08d5fc83b215%7C8370cf1416f34c16b83c724071654356%7C0&amp;sdata=Q9Nrpc%2FA52FFCvo%2B3JCU5XWBWMFqbtiq6OvG2Oc3pvA%3D&amp;reserved=0
--

Powered by www.kitware.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=%2BDwnlxYPXo%2B7XtvQDWNmVyzoRsxjEmRNMp4VV9Pv0QQ%3D&reserved=0>

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=YDZkz8jfLRTremn5U1y89qn%2BaOSaKx4g%2FNlzwx0yJHA%3D&reserved=0>

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

CMake Support: http://cmake.org/cmake/help/support.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=GlAgHdttNOHHCX%2FXXORVO2lLNR%2BoVXrOPdnvTXV9OXE%3D&reserved=0>
CMake Consulting: http://cmake.org/cmake/help/consulting.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=2jZOeYDHH0mSCUu%2B%2B4YKfkotLUtm7gZe4Xwtajm7AyQ%3D&reserved=0>
CMake Training Courses: http://cmake.org/cmake/help/training.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=qkNgoY4w3N0kZWiY716v1molKMcDWyZxSmI8nzU6p70%3D&reserved=0>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=HgYjbH3ThP1dAGUdVFUy4QDtGA2UvbEilHNxMNAgMQ8%3D&reserved=0>

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&data=01%7C01%7Cgavin.wheeler%40kcl.ac.uk%7C15ca36a76a0a473b2b5208d5fd222ce3%7C8370cf1416f34c16b83c724071654356%7C0&sdata=1BdLPbBlD9ekWN3DNL%2FnS1dqIQmf8jHzuAegkdg5wDs%3D&reserved=0>

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

From andres.zarzadavila at student.uclouvain.be  Thu Aug  9 06:24:58 2018
From: andres.zarzadavila at student.uclouvain.be (Andres Zarza Davila)
Date: Thu, 9 Aug 2018 10:24:58 +0000
Subject: [CMake] Using static,
 -static-libgcc -static-libstdc++ flags and linking winpthread
Message-ID: <AM6PR03MB407020D6BA86D2E4D35537CAA0250@AM6PR03MB4070.eurprd03.prod.outlook.com>

Good afternoon.

We are using CMake to build an open source project. We would like to build it on Windows. For that purpose, we use MingW.
However, we have trouble linking three libraries :

  *   libstdc++-6.dll
  *   libwinpthread-1.dll
  *   libgcc_s_seh-1.dll
To solve this, we decided to link all three statically. In order to do so, we added the following to our main CMakeLists.txt [1]:

    set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ -lwsock32 -lws2_32 ${CMAKE_CSS_STANDARD_LIBRARIES}")
    set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive")

Is this the correct way to proceed in CMake ? Are these the right variables and flags to set ? Do we have to use two different cmake variables to achieve our goal ?

Any hints on improving this CMakeLists.txt is welcome.
Thanks.

Andres.

[1]: https://github.com/azarzadavila/mozart2/blob/d086c4b560472a29a7312e4f291bbc5b3a423414/CMakeLists.txt#L41-L63
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180809/149831dd/attachment.html>

From brad.king at kitware.com  Thu Aug  9 09:21:06 2018
From: brad.king at kitware.com (Brad King)
Date: Thu, 9 Aug 2018 09:21:06 -0400
Subject: [CMake] Link flags in CMAKE_CXX_CREATE_STATIC_LIBRARY
In-Reply-To: <5f26d23896ab4e6886a445cf30019c5a@despmsx01.brainlab.net>
References: <5f26d23896ab4e6886a445cf30019c5a@despmsx01.brainlab.net>
Message-ID: <48a02527-4724-a66f-770f-260dc4ac4dc0@kitware.com>

On 08/07/2018 06:54 AM, Daniel Eiband wrote:
> set_property(TARGET MyTarget APPEND PROPERTY LINK_FLAGS "/ignore:4221")
> 
> This however doesn't affect the creation of static libraries.

Static libraries are created by the librarian tool, not the linker.
There is a separate STATIC_LIBRARY_FLAGS property for this:

  https://cmake.org/cmake/help/v3.12/prop_tgt/STATIC_LIBRARY_FLAGS.html

-Brad

From daniel.eiband at brainlab.com  Thu Aug  9 09:30:00 2018
From: daniel.eiband at brainlab.com (Daniel Eiband)
Date: Thu, 9 Aug 2018 13:30:00 +0000
Subject: [CMake] Link flags in CMAKE_CXX_CREATE_STATIC_LIBRARY
In-Reply-To: <48a02527-4724-a66f-770f-260dc4ac4dc0@kitware.com>
References: <5f26d23896ab4e6886a445cf30019c5a@despmsx01.brainlab.net>
 <48a02527-4724-a66f-770f-260dc4ac4dc0@kitware.com>
Message-ID: <4f4ff5314cb040ecbd8a9a19f78ada54@despmsx01.brainlab.net>

Hi Brad,

Thanks a lot, works like a charm!

Daniel

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Donnerstag, 9. August 2018 15:21
To: Daniel Eiband <daniel.eiband at brainlab.com>; cmake at cmake.org
Subject: Re: [CMake] Link flags in CMAKE_CXX_CREATE_STATIC_LIBRARY

On 08/07/2018 06:54 AM, Daniel Eiband wrote:
> set_property(TARGET MyTarget APPEND PROPERTY LINK_FLAGS "/ignore:4221")
> 
> This however doesn't affect the creation of static libraries.

Static libraries are created by the librarian tool, not the linker.
There is a separate STATIC_LIBRARY_FLAGS property for this:

  https://cmake.org/cmake/help/v3.12/prop_tgt/STATIC_LIBRARY_FLAGS.html

-Brad

From robert.maynard at kitware.com  Thu Aug  9 11:25:27 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 9 Aug 2018 11:25:27 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.12.1 available for download
Message-ID: <CAFzjYVp2o6juDJsvN3f=e0SOJtGoY6ZE83xjdbJVyYAbwesinA@mail.gmail.com>

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

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

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.12.1 since 3.12.0:

Brad King (8):
      CSharp: Set CMAKE_CSharp_COMPILER_LOADED variable when language is enabled
      UseSWIG: Use CSharp language only if it is enabled
      Help: Add explicit <PackageName>_ROOT variable documentation
      Tests: Add case showing CMP0048 warning on injected project command
      project: Do not issue CMP0048 warnings on injected call
      CPack: Restore support for 0-valued version components
      FindCUDA/select_compute_arch: Restore two-component CUDA_VERSION
      CMake 3.12.1

Craig Scott (1):
      GoogleTest: Ensure policy settings allow use of IN_LIST

Dima Panov (1):
      FindTCL: Add support for version 8.7

Marc Chevrier (2):
      FindPython*: fix erroneous behavior on multiple 'find_package' calls
      UseSWIG: restore legacy behavior for SWIG_MODULE_<name>_EXTRA_FLAGS

From smancill at jlab.org  Fri Aug 10 17:48:42 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Fri, 10 Aug 2018 17:48:42 -0400
Subject: [CMake] Issues trying to use the Anaconda compiler tools with CMake
Message-ID: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>

I am trying to use Conda as a package manager for isolated C++ development
environments. But unfortunately, when using CMake with the Anaconda-provided
compilers [1] (which are used to compile the binary packages in the Anaconda
repositories), things do not work as expected.

I have a small test case available here [2], with an executable calling a
shared library and a third-party dependency installed with Conda.

[1]:
https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
[2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b

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

First, when using the system compiler, all works fine (but I am not sure of
the
binary compatibility with the Conda packages, that's why I want to use the
Anaconda compilers):

    # create the environment and install XercesC
    $ conda create -n test-system xerces-c
    ...
    environment location:
/Users/smancill/.local/share/miniconda3/envs/test-system
    ...
    The following NEW packages will be INSTALLED:

    icu:       58.2-h4b95b61_1
    libcxx:    4.0.1-h579ed51_0
    libcxxabi: 4.0.1-hebd6815_0
    xerces-c:  3.2.1-h44e365a_0
    ...

    # activate the environment
    $ conda activate test-system

    $ mkdir build-osx-system
    $ cd build-osx-system
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
-DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is AppleClang 9.0.0.9000039
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ -- works
    ...
    -- Found XercesC:
/Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
(found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to:
/Users/smancill/src/conda-test/build-osx-system

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
--verbose=1
    /usr/bin/c++   -isysroot
/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
-mmacosx-version-min=10.12 -Wl,-search_paths_first
-Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
-Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
-Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
libfoo.dylib
/Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
    ...

The build directory (~/src/conda-test/build-osx-system) and the conda
environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
are correctly added to the RPATH in the build tree by the link command:

    $ ./bar
    Hello, world!

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 1.0.0, current version
0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
            cmd LC_RPATH
        cmdsize 56
            path /Users/smancill/src/conda-test/build-osx-system (offset 12)
    --
            cmd LC_RPATH
        cmdsize 80
            path
/Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)

If I install the binary, it fails because I haven't configured CMake to set
the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing:
/Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
    -- Installing:
/Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
    -- Installing:
/Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar

    $ bar
    dyld: Library not loaded: @rpath/libfoo.dylib
      Referenced from:
/Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
      Reason: image not found
    [1]    84611 abort      bar

    $ otool -L $CONDA_PREFIX/bin/bar
    /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version
0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.0.0)

    $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
    # empty

    # deactivate the environment to start again
    $ conda deactivate

The same can be observed on Linux. Everything works as it should.

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

If I try to use Anaconda compilers on macOS, the build RPATH is not set
properly anymore:

    # create the environment and install the Anaconda compiler for macOS,
and XercesC
    $ conda create -n test-conda clangxx_osx-64 xerces-c
    ...
    environment location:
/Users/smancill/.local/share/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        cctools:        895-h7512d6f_0
        clang:          4.0.1-h662ec87_0
        clang_osx-64:   4.0.1-h1ce6c1d_11
        clangxx:        4.0.1-hc9b4283_0
        clangxx_osx-64: 4.0.1-h22b1bf0_11
        compiler-rt:    4.0.1-h5487866_0
        icu:            58.2-h4b95b61_1
        ld64:           274.2-h7c2db76_0
        libcxx:         4.0.1-h579ed51_0
        libcxxabi:      4.0.1-hebd6815_0
        llvm:           4.0.1-hc748206_0
        llvm-lto-tapi:  4.0.1-h6701bc3_0
        xerces-c:       3.2.1-h44e365a_0
    ...

    # activate the environment (which sets the variables to use the
Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-osx-conda
    $ cd build-osx-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
-DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is Clang 4.0.1
    -- Check for working CXX compiler:
/Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
    -- Check for working CXX compiler:
/Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
-- works
    ...
    -- Found XercesC:
/Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
(found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to:
/Users/smancill/src/conda-test/build-osx-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
--verbose=1

/Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
-march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
-fstack-protector-strong -O2 -pipe -stdlib=libc++
-fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
-mmacosx-version-min=10.12 -Wl,-search_paths_first
-Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
-Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
-Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
/Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
    ...

You can see that the environment lib path is not added to the RPATH by the
link command,
which in turns result in the executable not running from the build tree
anymore:

    $ ./bar
    dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
      Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
      Reason: image not found
    [1]    89350 abort      ./bar

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version
0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
version 0.0.0)
        @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 56
         path /Users/smancill/src/conda-test/build-osx-conda (offset 12)

    # deactivate the environment
    $ conda deactivate

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

If I try the Anaconda compilers on Linux, there are strange results too:

    # create the environment and install the Anaconda compiler for Linux,
and XercesC
    $ conda create -n test-conda gxx_linux-64 xerces-c
    ...
    environment location: /home/vagrant/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        binutils_impl_linux-64: 2.28.1-had2808c_3
        binutils_linux-64:      7.2.0-had2808c_27
        gcc_impl_linux-64:      7.2.0-habb00fd_3
        gcc_linux-64:           7.2.0-h550dcbe_27
        gxx_impl_linux-64:      7.2.0-hdf63c60_3
        gxx_linux-64:           7.2.0-h550dcbe_27
        icu:                    58.2-h9c2bf20_1
        libgcc-ng:              7.2.0-hdf63c60_3
        libstdcxx-ng:           7.2.0-hdf63c60_3
        xerces-c:               3.2.1-hac72e42_0

    # activate the environment (which sets the variables to use the
Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-linux-conda
    $ cd build-linux-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
-DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is GNU 7.2.0
    -- Check for working CXX compiler:
/home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
    -- Check for working CXX compiler:
/home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
-- works
    ...
    -- Found XercesC:
/home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
"3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to:
/vagrant/conda-test/build-linux-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
--verbose=1

/home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
 -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
-mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
-pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
/home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
-Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
    ...

You can see that the environment lib path is added to the RPATH by the link
command (unlike macOS):

    $ ./bar
    Hello World!

But when inspecting the dependencies, the environment lib path appears
twice:

    $ readelf -d ./bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [
libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library:
[libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath:
[/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
    ...

Which is wrong. Now the build tree binary will pick first any old version of
the foo library installed in the environment instead of the version in the
build tree.

It seems that the Anaconda toolchain is setting the environment lib path
into
the RPATH by its own. It is also set when installing the binaries, even when
CMake is not configured to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
    -- Set runtime path of
"/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""

    $ bar
    Hello World!

    $ readelf -d $CONDA_PREFIX/bin/bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [
libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library:
[libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath:
[/home/vagrant/miniconda3/envs/test-conda/lib]
    ...

    # deactivate the environment
    $ conda deactivate

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

TL;DR I cannot get CMake and the Anaconda compilers and packages working
correctly.

- On macOS, the Conda environment library path is not added to the build
RPATH.
- On Linux, the Conda environment library path is always added to the RPATH
  (in both build and install) independently of CMake.

Any advice or workarounds?

-- 
Sebastian Mancilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180810/999b3788/attachment-0001.html>

From james.turner at kdab.com  Sat Aug 11 04:44:34 2018
From: james.turner at kdab.com (James Turner)
Date: Sat, 11 Aug 2018 09:44:34 +0100
Subject: [CMake] Force configure_file to re-run
Message-ID: <27F64A8F-EDE4-43CE-ABEF-DD00F696A5B3@kdab.com>

Hi,

I was wondering if the official advice on re-running ?configure_file? has evolved? There?s some answers on StackOverflow about using custom targets / commands to force it but they seem ? ugly.

Essentially I want configure_file to re-run each build - I still want the ?only update the timestamp on the output file to change if the file is really changed? logic, otherwise I could use file(WRITE).

(I have some variables, expanded in the foo.in file which is the input to configure_file, which change fairly often but not every build, so I?d like to use configure_file to check these variables each build, but only touch/modify <output>.h when the variables really did change)

Kind regards,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4155 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180811/1f7e1850/attachment.bin>

From damir_porobic at live.com  Sun Aug 12 04:49:52 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Sun, 12 Aug 2018 08:49:52 +0000
Subject: [CMake] How to share a custom widget with cmake
Message-ID: <AM0PR0202MB34114FD686FD127364BE132BE53A0@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Hi all,


As the subject line says, what would be the best  approach to share a custom Widget with cmake? I have written a custom Qt Widget that I would like to be able to use in other projects.

Would that be a shared library? Or is there another approach?


Thanks in advance!


Best regards,
Damir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180812/75f0bcfd/attachment.html>

From mte.zych at gmail.com  Sun Aug 12 08:45:39 2018
From: mte.zych at gmail.com (Mateusz Zych)
Date: Sun, 12 Aug 2018 14:45:39 +0200
Subject: [CMake] Modular build system for repository with libraries shared
 between multiple targets.
Message-ID: <CAGxDeXzTYC9=9mH1pZddD0woRhr9rV=YLDrXU6d8SQhuzSjy3w@mail.gmail.com>

Hi, I'm trying to understand what's the recommended way of
implementing CMake build system in the following repository:

repo
|
|___ util
|    |___ include
|    |    |___ util
|    |         |___ util.h
|    |
|    |___ source
|    |    |___ util.cpp
|    |
|    |___ CMakeLists.txt
|
|___ tool
|    |___ include
|    |    |___ tool
|    |         |___ tool.h
|    |
|    |___ source
|    |    |___ tool.cpp
|    |
|    |___ CMakeLists.txt
|
|___ app
     |___ app.cpp
     |
     |___ CMakeLists.txt

Essentially this repo contains static library util, shared library tool and
executable app.

Both executable app and shared library tool depend on static library util,
but they don't depend on each other.
This can be represented by dependency graph like so:

app   tool
 |    |
 |    |
 V    V
  util

The reason why static library util is placed in the root of repo,
is the fact that it's shared by both executable app and shared library tool.

Writing //repo/util/CMakeLists.txt is very easy:

cmake_minimum_required(VERSION 3.11)

*project(util)*

add_library(util STATIC)
target_sources(util PRIVATE include/util/util.h
                                  source/util.cpp)
target_include_directories(util PUBLIC include)


However, implementing //repo/tool/CMakeLists.txt

cmake_minimum_required(VERSION 3.11)

*# no project definition*


add_library(tool SHARED)
target_sources(tool PRIVATE include/tool/tool.h
                                  source/tool.cpp)
target_include_directories(tool PUBLIC include)
target_link_libraries(tool PRIVATE util)


and //repo/app/CMakeLists.txt is more challenging.

cmake_minimum_required (VERSION 3.11)

*# no project definition*

add_executable(app)
target_sources(app PRIVATE app.cpp)
target_link_libraries(app PRIVATE util)

I understand CMake project as a set of targets, which are standalone (can
be built by themselves).

Source: https://stackoverflow.com/questions/26878379/in-
cmake-what-is-a-project

This meas that I can define project util

consisting
of one target (static library util),
because target util doesn't have any dependencies
, meaning it's standalone.
Unfortunately defining project
tool
 and project app is problematic,
because
executable
app and shared library
tool
do d
epend on static library
util
.

I found two solutions to this issue, but neither seems "correct" to me:

1. Create //repo/CMakeLists.txt and define project repo which will add util
, tool and app as sub-directories.


cmake_minimum_required(VERSION 3.11)


project(repo)

add_subdirectory(util)

add_subdirectory(tool)

add_subdirectory(app)


This is the cleanest solution, but it has a serious drawback of not
defining project app and project tool,
which could be built independently from each other.


I thought that I will be able to mitigate this issue by
defining multiple projects in //repo/CMakeLists.txt each with its own
separate set of targets.


cmake_minimum_required(VERSION 3.11)

*project(tool)*

*add_subdirectory(util)*

*add_subdirectory(tool)*


*project(app)*

*add_subdirectory(util)*

*add_subdirectory(app)*


project(repo)

add_subdirectory(util)

add_subdirectory(tool)

add_subdirectory(app)


T
his is not possible, since one CMakeLists.txt can define only single
project and
calling add_subdirectory() twice on the same directory is an error.
I believe these constraints arise from the fact that
*CMake projects are not providing any scoping / grouping mechanism for
targets.*

Source: https://cmake.org/pipermail/cmake/2009-June/030188.html


It is possible to create W/A mitigating this issue,
by using if(), elseif() and else() commands in //repo/CMakeLists.txt,
but this solution looks to me like an awful hack.

cmake_minimum_required(VERSION 3.11)


*if(TOOL)*

project(tool)

add_subdirectory(util)

add_subdirectory(tool)

*elseif(APP)*

project(app)

add_subdirectory(util)

add_subdirectory(app)

*else()*

project(repo)

add_subdirectory(util)

add_subdirectory(tool)

add_subdirectory(app)

*endif()*


Making matters worse this approach requires global handling of
sub-directories in a project,
meaning that knowledge of the whole dependency graph is required to add
sub-directories in correct order.

This breaks down the most desirable properties of modern CMake - modularity
and isolation of targets.


2. Define project as a self-containing set of targets by adding
sub-directories were they are required.


In this approach //repo/tool/CMakeLists.txt would add upper directory util
by defining not only source directory, but also binary directory.

cmake_minimum_required(VERSION 3.11)


*project(tool)*

*add_subdirectory(../util util)*


add_library(tool SHARED)

target_sources(tool PRIVATE include/tool/tool.h

                                  source/tool.cpp)

target_include_directories(tool PUBLIC include)

target_link_libraries(tool PRIVATE util)


Using the exact same technique //repo/app/CMakeLists.txt would also add
upper directory util.


cmake_minimum_required (VERSION 3.11)


*project(app)*

*add_subdirectory(../util util)*


add_executable(app)

target_sources(app PRIVATE app.cpp)

target_link_libraries(app PRIVATE util)


This approach allows each project to be stand-alone,
because all sub-directories required by targets directly defined by that
project are added directly in place.


This is huge advantage compared to the first solution,

because project is responsible only for adding sub-directories,

which are required by direct dependencies of
targets defined
directly
in that project.


All sub-directories required for satisfying project's indirect dependencies
will be added automatically by projects defining targets,
which are direct dependencies of
targets defined
directly
in that project.

For example, if target util would depend on target foo,
then in project util sub-directory foo would be added to satisfy that
dependency.

cmake_minimum_required(VERSION 3.11)


project(util)

*add_subdirectory(../foo foo)*


add_library(util STATIC)

target_sources(util PRIVATE include/util/util.h

                                  source/util.cpp)

target_include_directories(util PUBLIC include)

* target_link_libraries(util PRIVATE foo)*


So in case of app project util sub-directory would be added first,
then foo sub-directory would be added by the util project.
Effectively adding sub-directory will create a cascade of
add_subdirectory() commands,

meaning that sub-directories would be added transitively.

This approach doesn't require knowledge of the whole dependency graph -
just direct dependencies are needed to be known.

Now targets can be modular and isolated, which is what modern CMake is all
about.



Unfortunately this approach has major flaw - it doesn't allow sharing
libraries between targets.
It's a trap giving false illusion, that knowledge of whole dependency graph
is not required.

Consider adding repo project in //repo/CMakeLists.txt.

cmake_minimum_required(VERSION 3.11)


*project(repo)*


*add_subdirectory(tool)*

*add_subdirectory(app)*


This will immediately fail,
because directory util will be added twice - first time by project tool and
second time by project app.
Essentially in this approach projects cannot share libraries,
because it is required to  control globally how sub-directories are added
to make sure that they are added exactly once.


Considering that both solutions feels like complete failures,
what is recommended way of implementing CMake build system in described
repository?

Am I missing something or CMake legitimately lacks mechanisms for handling
this case properly?
Honestly it's hard to believe that CMake would lack support for this case,
considering this is such a widely used and flexible build system.

I would really appreciate help with solving this issue. :-)
Thank you, Mateusz Zych
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180812/8cb34203/attachment-0001.html>

From maomaowyh at gmail.com  Mon Aug 13 03:12:37 2018
From: maomaowyh at gmail.com (maomao)
Date: Mon, 13 Aug 2018 15:12:37 +0800
Subject: [CMake] Is cmake failed with any Error message?
Message-ID: <CAMi=NdJFFfQ9Was1OhO_8uE=0nK5PCApKF12QNLz6qzpaM_=8A@mail.gmail.com>

Dear admin,

I am trying to build a project that is a open source and have a package on
the website.
The required binaries are installed by macports on my macbook pro with
OSX10.13.6 (High Sierra).
When I tried to cmake the project, I got the output message as:

es2039:build maomao$ cmake ..

-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)

-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
OpenMP_CXX_LIB_NAMES)

-- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND)

-- HDF5: Using hdf5 compiler wrapper to determine C configuration

CMake Error at /opt/local/share/cmake-3.12/Modules/UseSWIG.cmake:509
(message):

  SWIG_ADD_LIBRARY: python;quakelib.i: unexpected arguments

Call Stack (most recent call first):

  quakelib/python/CMakeLists.txt:10 (SWIG_ADD_LIBRARY)



-- Configuring incomplete, errors occurred!

See also "/Users/maomao/VirtualTaiwan/build/CMakeFiles/CMakeOutput.log".

and failed when I proceeded to make.
So, the question is:
Is the project configured or not with any error message like that?
What kind output should I see when I succeed to configure the project by
cmake?
If cmake is failed to configure project, the code could not be build by
make anyway?

Best,
Maomao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180813/a14d538a/attachment.html>

From isaiah.norton at gmail.com  Mon Aug 13 11:54:00 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Mon, 13 Aug 2018 11:54:00 -0400
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
Message-ID: <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>

The RPATH is not included when using Anaconda because CMake considers the
Anaconda lib path to be an implicit link directory (as reported by the
compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section
about "implicit link info".

The simplest work-around is to set BUILD_RPATH manually, and possibly also
INSTALL_RPATH, depending on what conda-build's fixup routine expects.

For example, adding this line near the top of your example CMakeList fixed
the resulting binary, at least in the build directory:

set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")


On Fri, Aug 10, 2018 at 5:55 PM Sebasti?n Mancilla <smancill at jlab.org>
wrote:

> I am trying to use Conda as a package manager for isolated C++ development
> environments. But unfortunately, when using CMake with the
> Anaconda-provided
> compilers [1] (which are used to compile the binary packages in the
> Anaconda
> repositories), things do not work as expected.
>
> I have a small test case available here [2], with an executable calling a
> shared library and a third-party dependency installed with Conda.
>
> [1]:
> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>
> --------------------------------------------------
>
> First, when using the system compiler, all works fine (but I am not sure
> of the
> binary compatibility with the Conda packages, that's why I want to use the
> Anaconda compilers):
>
>     # create the environment and install XercesC
>     $ conda create -n test-system xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
>     ...
>     The following NEW packages will be INSTALLED:
>
>     icu:       58.2-h4b95b61_1
>     libcxx:    4.0.1-h579ed51_0
>     libcxxabi: 4.0.1-hebd6815_0
>     xerces-c:  3.2.1-h44e365a_0
>     ...
>
>     # activate the environment
>     $ conda activate test-system
>
>     $ mkdir build-osx-system
>     $ cd build-osx-system
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>     -- Check for working CXX compiler: /usr/bin/c++
>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>     /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>     ...
>
> The build directory (~/src/conda-test/build-osx-system) and the conda
> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
> are correctly added to the RPATH in the build tree by the link command:
>
>     $ ./bar
>     Hello, world!
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>             cmd LC_RPATH
>         cmdsize 56
>             path /Users/smancill/src/conda-test/build-osx-system (offset
> 12)
>     --
>             cmd LC_RPATH
>         cmdsize 80
>             path
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>
> If I install the binary, it fails because I haven't configured CMake to
> set the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>
>     $ bar
>     dyld: Library not loaded: @rpath/libfoo.dylib
>       Referenced from:
> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>       Reason: image not found
>     [1]    84611 abort      bar
>
>     $ otool -L $CONDA_PREFIX/bin/bar
>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>     # empty
>
>     # deactivate the environment to start again
>     $ conda deactivate
>
> The same can be observed on Linux. Everything works as it should.
>
> --------------------------------------------------
>
> If I try to use Anaconda compilers on macOS, the build RPATH is not set
> properly anymore:
>
>     # create the environment and install the Anaconda compiler for macOS,
> and XercesC
>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         cctools:        895-h7512d6f_0
>         clang:          4.0.1-h662ec87_0
>         clang_osx-64:   4.0.1-h1ce6c1d_11
>         clangxx:        4.0.1-hc9b4283_0
>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>         compiler-rt:    4.0.1-h5487866_0
>         icu:            58.2-h4b95b61_1
>         ld64:           274.2-h7c2db76_0
>         libcxx:         4.0.1-h579ed51_0
>         libcxxabi:      4.0.1-hebd6815_0
>         llvm:           4.0.1-hc748206_0
>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>         xerces-c:       3.2.1-h44e365a_0
>     ...
>
>     # activate the environment (which sets the variables to use the
> Anaconda compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-osx-conda
>     $ cd build-osx-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is Clang 4.0.1
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> -fstack-protector-strong -O2 -pipe -stdlib=libc++
> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>     ...
>
> You can see that the environment lib path is not added to the RPATH by the
> link command,
> which in turns result in the executable not running from the build tree
> anymore:
>
>     $ ./bar
>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>       Reason: image not found
>     [1]    89350 abort      ./bar
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>           cmd LC_RPATH
>       cmdsize 56
>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> If I try the Anaconda compilers on Linux, there are strange results too:
>
>     # create the environment and install the Anaconda compiler for Linux,
> and XercesC
>     $ conda create -n test-conda gxx_linux-64 xerces-c
>     ...
>     environment location: /home/vagrant/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         binutils_impl_linux-64: 2.28.1-had2808c_3
>         binutils_linux-64:      7.2.0-had2808c_27
>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>         gcc_linux-64:           7.2.0-h550dcbe_27
>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>         gxx_linux-64:           7.2.0-h550dcbe_27
>         icu:                    58.2-h9c2bf20_1
>         libgcc-ng:              7.2.0-hdf63c60_3
>         libstdcxx-ng:           7.2.0-hdf63c60_3
>         xerces-c:               3.2.1-hac72e42_0
>
>     # activate the environment (which sets the variables to use the
> Anaconda compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-linux-conda
>     $ cd build-linux-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is GNU 7.2.0
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -- works
>     ...
>     -- Found XercesC:
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
> "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /vagrant/conda-test/build-linux-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>  -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>     ...
>
> You can see that the environment lib path is added to the RPATH by the link
> command (unlike macOS):
>
>     $ ./bar
>     Hello World!
>
> But when inspecting the dependencies, the environment lib path appears
> twice:
>
>     $ readelf -d ./bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library: [
> libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>     ...
>
> Which is wrong. Now the build tree binary will pick first any old version
> of
> the foo library installed in the environment instead of the version in the
> build tree.
>
> It seems that the Anaconda toolchain is setting the environment lib path
> into
> the RPATH by its own. It is also set when installing the binaries, even
> when
> CMake is not configured to set the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>     -- Set runtime path of
> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>
>     $ bar
>     Hello World!
>
>     $ readelf -d $CONDA_PREFIX/bin/bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library: [
> libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib]
>     ...
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> TL;DR I cannot get CMake and the Anaconda compilers and packages working
> correctly.
>
> - On macOS, the Conda environment library path is not added to the build
> RPATH.
> - On Linux, the Conda environment library path is always added to the RPATH
>   (in both build and install) independently of CMake.
>
> Any advice or workarounds?
>
> --
> Sebastian Mancilla
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180813/f25265c5/attachment-0001.html>

From isaiah.norton at gmail.com  Mon Aug 13 12:35:03 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Mon, 13 Aug 2018 12:35:03 -0400
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
Message-ID: <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>

See also:

https://gitlab.kitware.com/cmake/cmake/merge_requests/207


https://gitlab.kitware.com/cmake/cmake/issues/17483 (looks semi-related)

Ray Donnelly, who filed those issues, maintains the Anaconda compiler
toolchain -- so you are in good company hitting this issue. It looks like
some conda recipes explicitly define INSTALL_RPATH, likely for this reason:

https://github.com/AnacondaRecipes/vtk-feedstock/blob/791a1db9026fa2c81d171c38835b512adf221794/recipe/build.sh#L30



On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <isaiah.norton at gmail.com>
wrote:

> The RPATH is not included when using Anaconda because CMake considers the
> Anaconda lib path to be an implicit link directory (as reported by the
> compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section
> about "implicit link info".
>
> The simplest work-around is to set BUILD_RPATH manually, and possibly also
> INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>
> For example, adding this line near the top of your example CMakeList fixed
> the resulting binary, at least in the build directory:
>
> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>
>
> On Fri, Aug 10, 2018 at 5:55 PM Sebasti?n Mancilla <smancill at jlab.org>
> wrote:
>
>> I am trying to use Conda as a package manager for isolated C++ development
>> environments. But unfortunately, when using CMake with the
>> Anaconda-provided
>> compilers [1] (which are used to compile the binary packages in the
>> Anaconda
>> repositories), things do not work as expected.
>>
>> I have a small test case available here [2], with an executable calling a
>> shared library and a third-party dependency installed with Conda.
>>
>> [1]:
>> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>
>> --------------------------------------------------
>>
>> First, when using the system compiler, all works fine (but I am not sure
>> of the
>> binary compatibility with the Conda packages, that's why I want to use the
>> Anaconda compilers):
>>
>>     # create the environment and install XercesC
>>     $ conda create -n test-system xerces-c
>>     ...
>>     environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-system
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>     icu:       58.2-h4b95b61_1
>>     libcxx:    4.0.1-h579ed51_0
>>     libcxxabi: 4.0.1-hebd6815_0
>>     xerces-c:  3.2.1-h44e365a_0
>>     ...
>>
>>     # activate the environment
>>     $ conda activate test-system
>>
>>     $ mkdir build-osx-system
>>     $ cd build-osx-system
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>     -- Check for working CXX compiler: /usr/bin/c++
>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>     ...
>>     -- Found XercesC:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>> (found version "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /Users/smancill/src/conda-test/build-osx-system
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>     /usr/bin/c++   -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
>> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
>> libfoo.dylib
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>     ...
>>
>> The build directory (~/src/conda-test/build-osx-system) and the conda
>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>> are correctly added to the RPATH in the build tree by the link command:
>>
>>     $ ./bar
>>     Hello, world!
>>
>>     $ otool -L ./bar
>>     ./bar:
>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
>> current version 0.0.0)
>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> version 400.9.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>             cmd LC_RPATH
>>         cmdsize 56
>>             path /Users/smancill/src/conda-test/build-osx-system (offset
>> 12)
>>     --
>>             cmd LC_RPATH
>>         cmdsize 80
>>             path
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>
>> If I install the binary, it fails because I haven't configured CMake to
>> set the install RPATH:
>>
>>     $ make install
>>     ...
>>     Install the project...
>>     -- Install configuration: ""
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>
>>     $ bar
>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>       Referenced from:
>> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>       Reason: image not found
>>     [1]    84611 abort      bar
>>
>>     $ otool -L $CONDA_PREFIX/bin/bar
>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
>> current version 0.0.0)
>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> version 400.9.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>     # empty
>>
>>     # deactivate the environment to start again
>>     $ conda deactivate
>>
>> The same can be observed on Linux. Everything works as it should.
>>
>> --------------------------------------------------
>>
>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>> properly anymore:
>>
>>     # create the environment and install the Anaconda compiler for macOS,
>> and XercesC
>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>     ...
>>     environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>         cctools:        895-h7512d6f_0
>>         clang:          4.0.1-h662ec87_0
>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>         clangxx:        4.0.1-hc9b4283_0
>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>         compiler-rt:    4.0.1-h5487866_0
>>         icu:            58.2-h4b95b61_1
>>         ld64:           274.2-h7c2db76_0
>>         libcxx:         4.0.1-h579ed51_0
>>         libcxxabi:      4.0.1-hebd6815_0
>>         llvm:           4.0.1-hc748206_0
>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>         xerces-c:       3.2.1-h44e365a_0
>>     ...
>>
>>     # activate the environment (which sets the variables to use the
>> Anaconda compiler)
>>     $ conda activate test-conda
>>
>>     $ mkdir build-osx-conda
>>     $ cd build-osx-conda
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is Clang 4.0.1
>>     -- Check for working CXX compiler:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>     -- Check for working CXX compiler:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> -- works
>>     ...
>>     -- Found XercesC:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>> (found version "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /Users/smancill/src/conda-test/build-osx-conda
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
>> -fstack-protector-strong -O2 -pipe -stdlib=libc++
>> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
>> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>     ...
>>
>> You can see that the environment lib path is not added to the RPATH by
>> the link command,
>> which in turns result in the executable not running from the build tree
>> anymore:
>>
>>     $ ./bar
>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>       Referenced from:
>> /Users/smancill/src/conda-test/build-osx-conda/./bar
>>       Reason: image not found
>>     [1]    89350 abort      ./bar
>>
>>     $ otool -L ./bar
>>     ./bar:
>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
>> current version 0.0.0)
>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>           cmd LC_RPATH
>>       cmdsize 56
>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>
>>     # deactivate the environment
>>     $ conda deactivate
>>
>> --------------------------------------------------
>>
>> If I try the Anaconda compilers on Linux, there are strange results too:
>>
>>     # create the environment and install the Anaconda compiler for Linux,
>> and XercesC
>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>     ...
>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>         binutils_linux-64:      7.2.0-had2808c_27
>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>         icu:                    58.2-h9c2bf20_1
>>         libgcc-ng:              7.2.0-hdf63c60_3
>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>         xerces-c:               3.2.1-hac72e42_0
>>
>>     # activate the environment (which sets the variables to use the
>> Anaconda compiler)
>>     $ conda activate test-conda
>>
>>     $ mkdir build-linux-conda
>>     $ cd build-linux-conda
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is GNU 7.2.0
>>     -- Check for working CXX compiler:
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>     -- Check for working CXX compiler:
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> -- works
>>     ...
>>     -- Found XercesC:
>> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
>> "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /vagrant/conda-test/build-linux-conda
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>  -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
>> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
>> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
>> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
>> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
>> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>     ...
>>
>> You can see that the environment lib path is added to the RPATH by the
>> link
>> command (unlike macOS):
>>
>>     $ ./bar
>>     Hello World!
>>
>> But when inspecting the dependencies, the environment lib path appears
>> twice:
>>
>>     $ readelf -d ./bar
>>     ...
>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>      0x0000000000000001 (NEEDED)             Shared library: [
>> libxerces-c-3.2.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libstdc++.so.6]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libgcc_s.so.1]
>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>      0x000000000000000f (RPATH)              Library rpath:
>> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>     ...
>>
>> Which is wrong. Now the build tree binary will pick first any old version
>> of
>> the foo library installed in the environment instead of the version in the
>> build tree.
>>
>> It seems that the Anaconda toolchain is setting the environment lib path
>> into
>> the RPATH by its own. It is also set when installing the binaries, even
>> when
>> CMake is not configured to set the install RPATH:
>>
>>     $ make install
>>     ...
>>     Install the project...
>>     -- Install configuration: ""
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>     -- Installing:
>> /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>     -- Set runtime path of
>> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>
>>     $ bar
>>     Hello World!
>>
>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>     ...
>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>      0x0000000000000001 (NEEDED)             Shared library: [
>> libxerces-c-3.2.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libstdc++.so.6]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libgcc_s.so.1]
>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>      0x000000000000000f (RPATH)              Library rpath:
>> [/home/vagrant/miniconda3/envs/test-conda/lib]
>>     ...
>>
>>     # deactivate the environment
>>     $ conda deactivate
>>
>> --------------------------------------------------
>>
>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>> correctly.
>>
>> - On macOS, the Conda environment library path is not added to the build
>> RPATH.
>> - On Linux, the Conda environment library path is always added to the
>> RPATH
>>   (in both build and install) independently of CMake.
>>
>> Any advice or workarounds?
>>
>> --
>> Sebastian Mancilla
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180813/d7e9cb72/attachment-0001.html>

From mellery451 at gmail.com  Mon Aug 13 12:37:09 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Mon, 13 Aug 2018 09:37:09 -0700
Subject: [CMake] Modular build system for repository with libraries
 shared between multiple targets.
In-Reply-To: <CAGxDeXzTYC9=9mH1pZddD0woRhr9rV=YLDrXU6d8SQhuzSjy3w@mail.gmail.com>
References: <CAGxDeXzTYC9=9mH1pZddD0woRhr9rV=YLDrXU6d8SQhuzSjy3w@mail.gmail.com>
Message-ID: <DBCF57C6-8A5D-4615-A2DD-3E208CF822A2@gmail.com>

it?s not clear to me why you are trying to do this multiple project thing?I mean why not just?:

project(myrepo)
add_subdirectory(util)
add_subdirectory(tool)
add_subdirectory(app)

and then if you only want to build util for instance:

cd build && cmake .. && cmake --build . --target=util

is there some other reason using the targets generated by the project doesn?t work for you?

-Mike

> On Aug 12, 2018, at 5:45 AM, Mateusz Zych <mte.zych at gmail.com> wrote:
> 
> Hi, I'm trying to understand what's the recommended way of
> implementing CMake build system in the following repository:
> 
> repo
> |
> |___ util
> |    |___ include
> |    |    |___ util
> |    |         |___ util.h
> |    |
> |    |___ source
> |    |    |___ util.cpp
> |    |
> |    |___ CMakeLists.txt
> |
> |___ tool
> |    |___ include
> |    |    |___ tool
> |    |         |___ tool.h
> |    |
> |    |___ source
> |    |    |___ tool.cpp
> |    |
> |    |___ CMakeLists.txt
> |
> |___ app
>      |___ app.cpp
>      |
>      |___ CMakeLists.txt
> 
> Essentially this repo contains static library util, shared library tool and executable app.
> 
> Both executable app and shared library tool depend on static library util,
> but they don't depend on each other.
> This can be represented by dependency graph like so:
> 
> app   tool
>  |    |
>  |    |
>  V    V
>   util
> 
> The reason why static library util is placed in the root of repo,
> is the fact that it's shared by both executable app and shared library tool.
> 
> Writing //repo/util/CMakeLists.txt is very easy:
> 
> cmake_minimum_required(VERSION 3.11)
> 
> project(util)
> 
> add_library(util STATIC)
> target_sources(util PRIVATE include/util/util.h
>                                   source/util.cpp)
> target_include_directories(util PUBLIC include)
> 
> However, implementing //repo/tool/CMakeLists.txt
> 
> cmake_minimum_required(VERSION 3.11)
> 
> # no project definition
> 
> add_library(tool SHARED)
> target_sources(tool PRIVATE include/tool/tool.h
>                                   source/tool.cpp)
> target_include_directories(tool PUBLIC include)
> target_link_libraries(tool PRIVATE util)
> 
> and //repo/app/CMakeLists.txt is more challenging.
> 
> cmake_minimum_required (VERSION 3.11)
> 
> # no project definition
> 
> add_executable(app)
> target_sources(app PRIVATE app.cpp)
> target_link_libraries(app PRIVATE util)
> 
> I understand CMake project as a set of targets, which are standalone (can be built by themselves).
> Source: https://stackoverflow.com/questions/26878379/in-cmake-what-is-a-project
> 
> This meas that I can define project util consisting of one target (static library util),
> because target util doesn't have any dependencies, meaning it's standalone.
> Unfortunately defining project tool and project app is problematic,
> because executable app and shared library tool do depend on static library util.
> 
> I found two solutions to this issue, but neither seems "correct" to me:
> 
> 1. Create //repo/CMakeLists.txt and define project repo which will add util, tool and app as sub-directories.
> 
> cmake_minimum_required(VERSION 3.11)
> 
> project(repo)
> add_subdirectory(util)
> add_subdirectory(tool)
> add_subdirectory(app)
> 
> This is the cleanest solution, but it has a serious drawback of not defining project app and project tool,
> which could be built independently from each other.
> 
> I thought that I will be able to mitigate this issue by
> defining multiple projects in //repo/CMakeLists.txt each with its own separate set of targets.
> 
> cmake_minimum_required(VERSION 3.11)
> 
> project(tool)
> add_subdirectory(util)
> add_subdirectory(tool)
> 
> project(app)
> add_subdirectory(util)
> add_subdirectory(app)
> 
> project(repo)
> add_subdirectory(util)
> add_subdirectory(tool)
> add_subdirectory(app)
> 
> This is not possible, since one CMakeLists.txt can define only single project and
> calling add_subdirectory() twice on the same directory is an error.
> I believe these constraints arise from the fact that
> CMake projects are not providing any scoping / grouping mechanism for targets.
> Source: https://cmake.org/pipermail/cmake/2009-June/030188.html
> 
> It is possible to create W/A mitigating this issue,
> by using if(), elseif() and else() commands in //repo/CMakeLists.txt,
> but this solution looks to me like an awful hack.
> 
> cmake_minimum_required(VERSION 3.11)
> 
> if(TOOL)
> 	project(tool)
> 	add_subdirectory(util)
> 	add_subdirectory(tool)
> elseif(APP)
> 	project(app)
> 	add_subdirectory(util)
> 	add_subdirectory(app)
> else()
> 	project(repo)
> 	add_subdirectory(util)
> 	add_subdirectory(tool)
> 	add_subdirectory(app)
> endif()
> 
> Making matters worse this approach requires global handling of sub-directories in a project,
> meaning that knowledge of the whole dependency graph is required to add sub-directories in correct order.
> This breaks down the most desirable properties of modern CMake - modularity and isolation of targets.
> 
> 2. Define project as a self-containing set of targets by adding sub-directories were they are required.
> 
> In this approach //repo/tool/CMakeLists.txt would add upper directory util
> by defining not only source directory, but also binary directory.
> 
> cmake_minimum_required(VERSION 3.11)
> 
> project(tool)
> add_subdirectory(../util util)
> 
> add_library(tool SHARED)
> target_sources(tool PRIVATE include/tool/tool.h
>                                   source/tool.cpp)
> target_include_directories(tool PUBLIC include)
> target_link_libraries(tool PRIVATE util)
> 
> Using the exact same technique //repo/app/CMakeLists.txt would also add upper directory util.
> 
> cmake_minimum_required (VERSION 3.11)
> 
> project(app)
> add_subdirectory(../util util)
> 
> add_executable(app)
> target_sources(app PRIVATE app.cpp)
> target_link_libraries(app PRIVATE util)
> 
> This approach allows each project to be stand-alone,
> because all sub-directories required by targets directly defined by that project are added directly in place.
> 
> This is huge advantage compared to the first solution,
> because project is responsible only for adding sub-directories,
> which are required by direct dependencies of targets defined directly in that project.
> 
> All sub-directories required for satisfying project's indirect dependencies
> will be added automatically by projects defining targets,
> which are direct dependencies of targets defined directly in that project.
> 
> For example, if target util would depend on target foo,
> then in project util sub-directory foo would be added to satisfy that dependency.
> 
> cmake_minimum_required(VERSION 3.11)
> 
> project(util)
> add_subdirectory(../foo foo)
> 
> add_library(util STATIC)
> target_sources(util PRIVATE include/util/util.h
>                                   source/util.cpp)
> target_include_directories(util PUBLIC include)
> target_link_libraries(util PRIVATE foo)
> 
> So in case of app project util sub-directory would be added first,
> then foo sub-directory would be added by the util project.
> Effectively adding sub-directory will create a cascade of add_subdirectory() commands,
> meaning that sub-directories would be added transitively.
> 
> This approach doesn't require knowledge of the whole dependency graph - just direct dependencies are needed to be known.
> Now targets can be modular and isolated, which is what modern CMake is all about.
> 
> 
> Unfortunately this approach has major flaw - it doesn't allow sharing libraries between targets.
> It's a trap giving false illusion, that knowledge of whole dependency graph is not required.
> 
> Consider adding repo project in //repo/CMakeLists.txt.
> 
> cmake_minimum_required(VERSION 3.11)
> 
> project(repo)
> add_subdirectory(tool)
> add_subdirectory(app)
> 
> This will immediately fail,
> because directory util will be added twice - first time by project tool and second time by project app.
> Essentially in this approach projects cannot share libraries,
> because it is required to  control globally how sub-directories are added to make sure that they are added exactly once.
> 
> Considering that both solutions feels like complete failures,
> what is recommended way of implementing CMake build system in described repository?
> 
> Am I missing something or CMake legitimately lacks mechanisms for handling this case properly?
> Honestly it's hard to believe that CMake would lack support for this case,
> considering this is such a widely used and flexible build system.
> 
> I would really appreciate help with solving this issue. :-)
> Thank you, Mateusz Zych
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20180813/2e9e2703/attachment.sig>

From mte.zych at gmail.com  Mon Aug 13 14:40:57 2018
From: mte.zych at gmail.com (Mateusz Zych)
Date: Mon, 13 Aug 2018 20:40:57 +0200
Subject: [CMake] Modular build system for repository with libraries
 shared between multiple targets.
In-Reply-To: <DBCF57C6-8A5D-4615-A2DD-3E208CF822A2@gmail.com>
References: <CAGxDeXzTYC9=9mH1pZddD0woRhr9rV=YLDrXU6d8SQhuzSjy3w@mail.gmail.com>
 <DBCF57C6-8A5D-4615-A2DD-3E208CF822A2@gmail.com>
Message-ID: <CAGxDeXzG0tOy8YNzb1rf5fQ+a21+cKOp6bpUKB_CJ-0RxWhsPg@mail.gmail.com>

Hi Michael, thanks for reply!

Essentially *I don't want to artificially couple app executable and tool
shared library*
by defining repo project with both targets.

I have three main motivations:


1) I want to be able to load into an IDE (for example CLion, Visual Studio,
Qt Creator)
only one target that at the time (plus its dependencies).
That way IDE will not have to process code that I'm not interested at the
moment,
so I could get very fast code navigation, finding usages, code completion,
etc.

For example if I would want to work on util static library in CLion,
I would just load //repo/util/CMakeLists.txt and everything would work
great.
However, if I would want to work only on app executable,
I would be forced to load tool shared library, because I would point to
//repo/CMakeLists.txt.


2) I also want to be able to selectively check out code from repository,
so I won't be forced to download code that I don't need at the moment.

For example if I would want to work on tool shared library,
I don't want to be forced to check out //repo/app from the repository.
I think that checking out //repo/util and //repo/tool should work just fine
(plus or minus //repo/CMakeLists.txt).


3) I want to be able to analyse source code (including CMake source code)
form just part of the repo and be able to have complete knowledge of that
part (local reasoning).

For example, if I need to analyse code defining tool shared library,
I have to know that there is another place in the CMake source code (in
this case //repo/CMakeLists.txt),
which will add sub-directories with targets satisfying dependencies of tool
target (in this case add_subdirectory(util)).

The point is project repo is a global entity, with which every shared
target needs to synchronize with.
I know that I presented simple example, but think about repo with large
number of projects.
I as a developer need to manually make sure that this global list is
defined correctly - it's not something enforced automatically.

It would be much better if each project defining a target with dependencies
would add sub-directories satisfying its dependencies - no global
synchronization point needed.
Unfortunately this is not currently possible, since calling
add_subdirectory() twice is an error.

To me this situation is very similar to how header files work in C++.
It is not a good idea to write a header file, which requires another header
file included before it.
Header files should be stand-alone and I think that similar rule should
apply for CMake projects.


I hope my arguments makes sense to you and my motivation is clear.

Thank you, Mateusz Zych

2018-08-13 18:37 GMT+02:00 Michael Ellery <mellery451 at gmail.com>:

> it?s not clear to me why you are trying to do this multiple project
> thing?I mean why not just?:
>
> project(myrepo)
> add_subdirectory(util)
> add_subdirectory(tool)
> add_subdirectory(app)
>
> and then if you only want to build util for instance:
>
> cd build && cmake .. && cmake --build . --target=util
>
> is there some other reason using the targets generated by the project
> doesn?t work for you?
>
> -Mike
>
> > On Aug 12, 2018, at 5:45 AM, Mateusz Zych <mte.zych at gmail.com> wrote:
> >
> > Hi, I'm trying to understand what's the recommended way of
> > implementing CMake build system in the following repository:
> >
> > repo
> > |
> > |___ util
> > |    |___ include
> > |    |    |___ util
> > |    |         |___ util.h
> > |    |
> > |    |___ source
> > |    |    |___ util.cpp
> > |    |
> > |    |___ CMakeLists.txt
> > |
> > |___ tool
> > |    |___ include
> > |    |    |___ tool
> > |    |         |___ tool.h
> > |    |
> > |    |___ source
> > |    |    |___ tool.cpp
> > |    |
> > |    |___ CMakeLists.txt
> > |
> > |___ app
> >      |___ app.cpp
> >      |
> >      |___ CMakeLists.txt
> >
> > Essentially this repo contains static library util, shared library tool
> and executable app.
> >
> > Both executable app and shared library tool depend on static library
> util,
> > but they don't depend on each other.
> > This can be represented by dependency graph like so:
> >
> > app   tool
> >  |    |
> >  |    |
> >  V    V
> >   util
> >
> > The reason why static library util is placed in the root of repo,
> > is the fact that it's shared by both executable app and shared library
> tool.
> >
> > Writing //repo/util/CMakeLists.txt is very easy:
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > project(util)
> >
> > add_library(util STATIC)
> > target_sources(util PRIVATE include/util/util.h
> >                                   source/util.cpp)
> > target_include_directories(util PUBLIC include)
> >
> > However, implementing //repo/tool/CMakeLists.txt
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > # no project definition
> >
> > add_library(tool SHARED)
> > target_sources(tool PRIVATE include/tool/tool.h
> >                                   source/tool.cpp)
> > target_include_directories(tool PUBLIC include)
> > target_link_libraries(tool PRIVATE util)
> >
> > and //repo/app/CMakeLists.txt is more challenging.
> >
> > cmake_minimum_required (VERSION 3.11)
> >
> > # no project definition
> >
> > add_executable(app)
> > target_sources(app PRIVATE app.cpp)
> > target_link_libraries(app PRIVATE util)
> >
> > I understand CMake project as a set of targets, which are standalone
> (can be built by themselves).
> > Source: https://stackoverflow.com/questions/26878379/in-cmake-
> what-is-a-project
> >
> > This meas that I can define project util consisting of one target
> (static library util),
> > because target util doesn't have any dependencies, meaning it's
> standalone.
> > Unfortunately defining project tool and project app is problematic,
> > because executable app and shared library tool do depend on static
> library util.
> >
> > I found two solutions to this issue, but neither seems "correct" to me:
> >
> > 1. Create //repo/CMakeLists.txt and define project repo which will add
> util, tool and app as sub-directories.
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > project(repo)
> > add_subdirectory(util)
> > add_subdirectory(tool)
> > add_subdirectory(app)
> >
> > This is the cleanest solution, but it has a serious drawback of not
> defining project app and project tool,
> > which could be built independently from each other.
> >
> > I thought that I will be able to mitigate this issue by
> > defining multiple projects in //repo/CMakeLists.txt each with its own
> separate set of targets.
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > project(tool)
> > add_subdirectory(util)
> > add_subdirectory(tool)
> >
> > project(app)
> > add_subdirectory(util)
> > add_subdirectory(app)
> >
> > project(repo)
> > add_subdirectory(util)
> > add_subdirectory(tool)
> > add_subdirectory(app)
> >
> > This is not possible, since one CMakeLists.txt can define only single
> project and
> > calling add_subdirectory() twice on the same directory is an error.
> > I believe these constraints arise from the fact that
> > CMake projects are not providing any scoping / grouping mechanism for
> targets.
> > Source: https://cmake.org/pipermail/cmake/2009-June/030188.html
> >
> > It is possible to create W/A mitigating this issue,
> > by using if(), elseif() and else() commands in //repo/CMakeLists.txt,
> > but this solution looks to me like an awful hack.
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > if(TOOL)
> >       project(tool)
> >       add_subdirectory(util)
> >       add_subdirectory(tool)
> > elseif(APP)
> >       project(app)
> >       add_subdirectory(util)
> >       add_subdirectory(app)
> > else()
> >       project(repo)
> >       add_subdirectory(util)
> >       add_subdirectory(tool)
> >       add_subdirectory(app)
> > endif()
> >
> > Making matters worse this approach requires global handling of
> sub-directories in a project,
> > meaning that knowledge of the whole dependency graph is required to add
> sub-directories in correct order.
> > This breaks down the most desirable properties of modern CMake -
> modularity and isolation of targets.
> >
> > 2. Define project as a self-containing set of targets by adding
> sub-directories were they are required.
> >
> > In this approach //repo/tool/CMakeLists.txt would add upper directory
> util
> > by defining not only source directory, but also binary directory.
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > project(tool)
> > add_subdirectory(../util util)
> >
> > add_library(tool SHARED)
> > target_sources(tool PRIVATE include/tool/tool.h
> >                                   source/tool.cpp)
> > target_include_directories(tool PUBLIC include)
> > target_link_libraries(tool PRIVATE util)
> >
> > Using the exact same technique //repo/app/CMakeLists.txt would also add
> upper directory util.
> >
> > cmake_minimum_required (VERSION 3.11)
> >
> > project(app)
> > add_subdirectory(../util util)
> >
> > add_executable(app)
> > target_sources(app PRIVATE app.cpp)
> > target_link_libraries(app PRIVATE util)
> >
> > This approach allows each project to be stand-alone,
> > because all sub-directories required by targets directly defined by that
> project are added directly in place.
> >
> > This is huge advantage compared to the first solution,
> > because project is responsible only for adding sub-directories,
> > which are required by direct dependencies of targets defined directly in
> that project.
> >
> > All sub-directories required for satisfying project's indirect
> dependencies
> > will be added automatically by projects defining targets,
> > which are direct dependencies of targets defined directly in that
> project.
> >
> > For example, if target util would depend on target foo,
> > then in project util sub-directory foo would be added to satisfy that
> dependency.
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > project(util)
> > add_subdirectory(../foo foo)
> >
> > add_library(util STATIC)
> > target_sources(util PRIVATE include/util/util.h
> >                                   source/util.cpp)
> > target_include_directories(util PUBLIC include)
> > target_link_libraries(util PRIVATE foo)
> >
> > So in case of app project util sub-directory would be added first,
> > then foo sub-directory would be added by the util project.
> > Effectively adding sub-directory will create a cascade of
> add_subdirectory() commands,
> > meaning that sub-directories would be added transitively.
> >
> > This approach doesn't require knowledge of the whole dependency graph -
> just direct dependencies are needed to be known.
> > Now targets can be modular and isolated, which is what modern CMake is
> all about.
> >
> >
> > Unfortunately this approach has major flaw - it doesn't allow sharing
> libraries between targets.
> > It's a trap giving false illusion, that knowledge of whole dependency
> graph is not required.
> >
> > Consider adding repo project in //repo/CMakeLists.txt.
> >
> > cmake_minimum_required(VERSION 3.11)
> >
> > project(repo)
> > add_subdirectory(tool)
> > add_subdirectory(app)
> >
> > This will immediately fail,
> > because directory util will be added twice - first time by project tool
> and second time by project app.
> > Essentially in this approach projects cannot share libraries,
> > because it is required to  control globally how sub-directories are
> added to make sure that they are added exactly once.
> >
> > Considering that both solutions feels like complete failures,
> > what is recommended way of implementing CMake build system in described
> repository?
> >
> > Am I missing something or CMake legitimately lacks mechanisms for
> handling this case properly?
> > Honestly it's hard to believe that CMake would lack support for this
> case,
> > considering this is such a widely used and flexible build system.
> >
> > I would really appreciate help with solving this issue. :-)
> > Thank you, Mateusz Zych
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180813/aefa0e8c/attachment-0001.html>

From smancill at jlab.org  Mon Aug 13 21:12:14 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Mon, 13 Aug 2018 22:12:14 -0300
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
Message-ID: <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>

Thanks for the links.

The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
for binaries and libraries in the build tree, the list of RPATH
locations will be in the wrong order: the dependencies library path
will be first, and then the build tree. This will break the unit tests
if the library was installed previously (for example, to check the
library by running other installed programs), and then modified as
part of normal development, because the installed version will be
loaded instead of the version in the build tree. CMake supports this
use case out of the box and it works great (when not using Anaconda).

Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
RPATH by the Anaconda toolchain itself, and it will appear first, so
there is nothing that can be done about that with CMake.

It seems that the workarounds when using Anaconda compilers, and doing
development, are:

- Always install before unit testing changes to the library being
developed (and set CMAKE_BUILD_RPATH).
- Never install the library (so the build tree not being first in the
RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
environment to test installation.
- Don't use the build RPATH and set the proper environment variables
([DY]LD_LIBRARY_PATH) with the right path order when running from the
build tree.
- Manipulate the RPATH manually (with patchelf or similar).
- Don't use Anaconda compilers (will there be binary issues with
Anaconda dependencies?)

But they are not ideal.


If the Conda environment is not being used for development and someone
wants to just build and use some binary/library, setting
CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
fine. And it looks that is not even necessary on Linux, because the
RPATH is already set by the toolchain.

El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
(isaiah.norton at gmail.com) escribi?:
>
> See also:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>
>
> https://gitlab.kitware.com/cmake/cmake/issues/17483 (looks semi-related)
>
> Ray Donnelly, who filed those issues, maintains the Anaconda compiler toolchain -- so you are in good company hitting this issue. It looks like some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
>
> https://github.com/AnacondaRecipes/vtk-feedstock/blob/791a1db9026fa2c81d171c38835b512adf221794/recipe/build.sh#L30
>
>
>
> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <isaiah.norton at gmail.com> wrote:
>>
>> The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".
>>
>> The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>>
>> For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:
>>
>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>>
>>
>> On Fri, Aug 10, 2018 at 5:55 PM Sebasti?n Mancilla <smancill at jlab.org> wrote:
>>>
>>> I am trying to use Conda as a package manager for isolated C++ development
>>> environments. But unfortunately, when using CMake with the Anaconda-provided
>>> compilers [1] (which are used to compile the binary packages in the Anaconda
>>> repositories), things do not work as expected.
>>>
>>> I have a small test case available here [2], with an executable calling a
>>> shared library and a third-party dependency installed with Conda.
>>>
>>> [1]: https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>>
>>> --------------------------------------------------
>>>
>>> First, when using the system compiler, all works fine (but I am not sure of the
>>> binary compatibility with the Conda packages, that's why I want to use the
>>> Anaconda compilers):
>>>
>>>     # create the environment and install XercesC
>>>     $ conda create -n test-system xerces-c
>>>     ...
>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
>>>     ...
>>>     The following NEW packages will be INSTALLED:
>>>
>>>     icu:       58.2-h4b95b61_1
>>>     libcxx:    4.0.1-h579ed51_0
>>>     libcxxabi: 4.0.1-hebd6815_0
>>>     xerces-c:  3.2.1-h44e365a_0
>>>     ...
>>>
>>>     # activate the environment
>>>     $ conda activate test-system
>>>
>>>     $ mkdir build-osx-system
>>>     $ cd build-osx-system
>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>>     -- Check for working CXX compiler: /usr/bin/c++
>>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>     ...
>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
>>>     -- Configuring done
>>>     -- Generating done
>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system
>>>
>>>     $ make -j1 VERBOSE=1
>>>     ...
>>>     [100%] Linking CXX executable bar
>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>     /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>>     ...
>>>
>>> The build directory (~/src/conda-test/build-osx-system) and the conda
>>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>>> are correctly added to the RPATH in the build tree by the link command:
>>>
>>>     $ ./bar
>>>     Hello, world!
>>>
>>>     $ otool -L ./bar
>>>     ./bar:
>>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>
>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>             cmd LC_RPATH
>>>         cmdsize 56
>>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>>     --
>>>             cmd LC_RPATH
>>>         cmdsize 80
>>>             path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>>
>>> If I install the binary, it fails because I haven't configured CMake to set the install RPATH:
>>>
>>>     $ make install
>>>     ...
>>>     Install the project...
>>>     -- Install configuration: ""
>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>>
>>>     $ bar
>>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>>       Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>>       Reason: image not found
>>>     [1]    84611 abort      bar
>>>
>>>     $ otool -L $CONDA_PREFIX/bin/bar
>>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>
>>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>>     # empty
>>>
>>>     # deactivate the environment to start again
>>>     $ conda deactivate
>>>
>>> The same can be observed on Linux. Everything works as it should.
>>>
>>> --------------------------------------------------
>>>
>>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>>> properly anymore:
>>>
>>>     # create the environment and install the Anaconda compiler for macOS, and XercesC
>>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>>     ...
>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
>>>     ...
>>>     The following NEW packages will be INSTALLED:
>>>
>>>         cctools:        895-h7512d6f_0
>>>         clang:          4.0.1-h662ec87_0
>>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>>         clangxx:        4.0.1-hc9b4283_0
>>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>>         compiler-rt:    4.0.1-h5487866_0
>>>         icu:            58.2-h4b95b61_1
>>>         ld64:           274.2-h7c2db76_0
>>>         libcxx:         4.0.1-h579ed51_0
>>>         libcxxabi:      4.0.1-hebd6815_0
>>>         llvm:           4.0.1-hc748206_0
>>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>>         xerces-c:       3.2.1-h44e365a_0
>>>     ...
>>>
>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>     $ conda activate test-conda
>>>
>>>     $ mkdir build-osx-conda
>>>     $ cd build-osx-conda
>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>     -- The CXX compiler identification is Clang 4.0.1
>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
>>>     ...
>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
>>>     -- Configuring done
>>>     -- Generating done
>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda
>>>
>>>     $ make -j1 VERBOSE=1
>>>     ...
>>>     [100%] Linking CXX executable bar
>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>     /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>>     ...
>>>
>>> You can see that the environment lib path is not added to the RPATH by the link command,
>>> which in turns result in the executable not running from the build tree anymore:
>>>
>>>     $ ./bar
>>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>>       Reason: image not found
>>>     [1]    89350 abort      ./bar
>>>
>>>     $ otool -L ./bar
>>>     ./bar:
>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>
>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>           cmd LC_RPATH
>>>       cmdsize 56
>>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>>
>>>     # deactivate the environment
>>>     $ conda deactivate
>>>
>>> --------------------------------------------------
>>>
>>> If I try the Anaconda compilers on Linux, there are strange results too:
>>>
>>>     # create the environment and install the Anaconda compiler for Linux, and XercesC
>>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>>     ...
>>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>>     ...
>>>     The following NEW packages will be INSTALLED:
>>>
>>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>>         binutils_linux-64:      7.2.0-had2808c_27
>>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>>         icu:                    58.2-h9c2bf20_1
>>>         libgcc-ng:              7.2.0-hdf63c60_3
>>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>>         xerces-c:               3.2.1-hac72e42_0
>>>
>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>     $ conda activate test-conda
>>>
>>>     $ mkdir build-linux-conda
>>>     $ cd build-linux-conda
>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>     -- The CXX compiler identification is GNU 7.2.0
>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
>>>     ...
>>>     -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
>>>     -- Configuring done
>>>     -- Generating done
>>>     -- Build files have been written to: /vagrant/conda-test/build-linux-conda
>>>
>>>     $ make -j1 VERBOSE=1
>>>     ...
>>>     [100%] Linking CXX executable bar
>>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>     /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>>     ...
>>>
>>> You can see that the environment lib path is added to the RPATH by the link
>>> command (unlike macOS):
>>>
>>>     $ ./bar
>>>     Hello World!
>>>
>>> But when inspecting the dependencies, the environment lib path appears twice:
>>>
>>>     $ readelf -d ./bar
>>>     ...
>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>>     ...
>>>
>>> Which is wrong. Now the build tree binary will pick first any old version of
>>> the foo library installed in the environment instead of the version in the
>>> build tree.
>>>
>>> It seems that the Anaconda toolchain is setting the environment lib path into
>>> the RPATH by its own. It is also set when installing the binaries, even when
>>> CMake is not configured to set the install RPATH:
>>>
>>>     $ make install
>>>     ...
>>>     Install the project...
>>>     -- Install configuration: ""
>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>>     -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>>
>>>     $ bar
>>>     Hello World!
>>>
>>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>>     ...
>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
>>>     ...
>>>
>>>     # deactivate the environment
>>>     $ conda deactivate
>>>
>>> --------------------------------------------------
>>>
>>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>>> correctly.
>>>
>>> - On macOS, the Conda environment library path is not added to the build RPATH.
>>> - On Linux, the Conda environment library path is always added to the RPATH
>>>   (in both build and install) independently of CMake.
>>>
>>> Any advice or workarounds?
>>>
>>> --
>>> Sebastian Mancilla
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake



-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile

From mingw.android at gmail.com  Tue Aug 14 02:43:15 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Tue, 14 Aug 2018 07:43:15 +0100
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
Message-ID: <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>

Why are you not using conda-build here? Anaconda Distro and
conda-forge build countless CMake projects. It handles so much extra
stuff on top of building (DSO verification, rpath rewriting, more). If
your end goal is not conda packages then you can untar most sets of
conda-packages to make working software installations (caveat for most
being that some software requires what we call 'prefix replacament'
and those aren't trivially relocatable).

IMHO CMake's handling of RPATHs is broken, as per my "determine
implicit linker directories" PR which there seems to be little to no
interest in instead preferring toolchain cmake files for something
that *clearly* should be queried from the link as it is imperative
when building software that CMake and the toolchain agree on things as
fundamental as this.

RPATH is never set by a toolchain except through being passed to it
(by CMake's logic, fixed by
https://gitlab.kitware.com/cmake/cmake/merge_requests/207).

I would again request that this pretty trivial, obvious and important
PR gets some consideration. Without it CMake asks anyone trying to
build a software distro with more than simple system prefix-based
compilation will run into needing this fix or needing to provide a
toolchain just to tell CMake what it should figure out for itself.

On Tue, Aug 14, 2018 at 2:12 AM, Sebasti?n Mancilla <smancill at jlab.org> wrote:
> Thanks for the links.
>
> The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
> for binaries and libraries in the build tree, the list of RPATH
> locations will be in the wrong order: the dependencies library path
> will be first, and then the build tree. This will break the unit tests
> if the library was installed previously (for example, to check the
> library by running other installed programs), and then modified as
> part of normal development, because the installed version will be
> loaded instead of the version in the build tree. CMake supports this
> use case out of the box and it works great (when not using Anaconda).
>
> Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
> RPATH by the Anaconda toolchain itself, and it will appear first, so
> there is nothing that can be done about that with CMake.
>
> It seems that the workarounds when using Anaconda compilers, and doing
> development, are:
>
> - Always install before unit testing changes to the library being
> developed (and set CMAKE_BUILD_RPATH).
> - Never install the library (so the build tree not being first in the
> RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
> environment to test installation.
> - Don't use the build RPATH and set the proper environment variables
> ([DY]LD_LIBRARY_PATH) with the right path order when running from the
> build tree.
> - Manipulate the RPATH manually (with patchelf or similar).
> - Don't use Anaconda compilers (will there be binary issues with
> Anaconda dependencies?)
>
> But they are not ideal.
>
>
> If the Conda environment is not being used for development and someone
> wants to just build and use some binary/library, setting
> CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
> fine. And it looks that is not even necessary on Linux, because the
> RPATH is already set by the toolchain.
>
> El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
> (isaiah.norton at gmail.com) escribi?:
>>
>> See also:
>>
>> https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>>
>>
>> https://gitlab.kitware.com/cmake/cmake/issues/17483 (looks semi-related)
>>
>> Ray Donnelly, who filed those issues, maintains the Anaconda compiler toolchain -- so you are in good company hitting this issue. It looks like some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
>>
>> https://github.com/AnacondaRecipes/vtk-feedstock/blob/791a1db9026fa2c81d171c38835b512adf221794/recipe/build.sh#L30
>>
>>
>>
>> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <isaiah.norton at gmail.com> wrote:
>>>
>>> The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".
>>>
>>> The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>>>
>>> For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:
>>>
>>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>>>
>>>
>>> On Fri, Aug 10, 2018 at 5:55 PM Sebasti?n Mancilla <smancill at jlab.org> wrote:
>>>>
>>>> I am trying to use Conda as a package manager for isolated C++ development
>>>> environments. But unfortunately, when using CMake with the Anaconda-provided
>>>> compilers [1] (which are used to compile the binary packages in the Anaconda
>>>> repositories), things do not work as expected.
>>>>
>>>> I have a small test case available here [2], with an executable calling a
>>>> shared library and a third-party dependency installed with Conda.
>>>>
>>>> [1]: https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>>>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>>>
>>>> --------------------------------------------------
>>>>
>>>> First, when using the system compiler, all works fine (but I am not sure of the
>>>> binary compatibility with the Conda packages, that's why I want to use the
>>>> Anaconda compilers):
>>>>
>>>>     # create the environment and install XercesC
>>>>     $ conda create -n test-system xerces-c
>>>>     ...
>>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>     icu:       58.2-h4b95b61_1
>>>>     libcxx:    4.0.1-h579ed51_0
>>>>     libcxxabi: 4.0.1-hebd6815_0
>>>>     xerces-c:  3.2.1-h44e365a_0
>>>>     ...
>>>>
>>>>     # activate the environment
>>>>     $ conda activate test-system
>>>>
>>>>     $ mkdir build-osx-system
>>>>     $ cd build-osx-system
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>>>     -- Check for working CXX compiler: /usr/bin/c++
>>>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>     ...
>>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>>>     ...
>>>>
>>>> The build directory (~/src/conda-test/build-osx-system) and the conda
>>>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>>>> are correctly added to the RPATH in the build tree by the link command:
>>>>
>>>>     $ ./bar
>>>>     Hello, world!
>>>>
>>>>     $ otool -L ./bar
>>>>     ./bar:
>>>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>>             cmd LC_RPATH
>>>>         cmdsize 56
>>>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>>>     --
>>>>             cmd LC_RPATH
>>>>         cmdsize 80
>>>>             path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>>>
>>>> If I install the binary, it fails because I haven't configured CMake to set the install RPATH:
>>>>
>>>>     $ make install
>>>>     ...
>>>>     Install the project...
>>>>     -- Install configuration: ""
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>>>
>>>>     $ bar
>>>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>>>       Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>>>       Reason: image not found
>>>>     [1]    84611 abort      bar
>>>>
>>>>     $ otool -L $CONDA_PREFIX/bin/bar
>>>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>>>     # empty
>>>>
>>>>     # deactivate the environment to start again
>>>>     $ conda deactivate
>>>>
>>>> The same can be observed on Linux. Everything works as it should.
>>>>
>>>> --------------------------------------------------
>>>>
>>>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>>>> properly anymore:
>>>>
>>>>     # create the environment and install the Anaconda compiler for macOS, and XercesC
>>>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>>>     ...
>>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>         cctools:        895-h7512d6f_0
>>>>         clang:          4.0.1-h662ec87_0
>>>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>>>         clangxx:        4.0.1-hc9b4283_0
>>>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>>>         compiler-rt:    4.0.1-h5487866_0
>>>>         icu:            58.2-h4b95b61_1
>>>>         ld64:           274.2-h7c2db76_0
>>>>         libcxx:         4.0.1-h579ed51_0
>>>>         libcxxabi:      4.0.1-hebd6815_0
>>>>         llvm:           4.0.1-hc748206_0
>>>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>>>         xerces-c:       3.2.1-h44e365a_0
>>>>     ...
>>>>
>>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>>     $ conda activate test-conda
>>>>
>>>>     $ mkdir build-osx-conda
>>>>     $ cd build-osx-conda
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is Clang 4.0.1
>>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
>>>>     ...
>>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>>>     ...
>>>>
>>>> You can see that the environment lib path is not added to the RPATH by the link command,
>>>> which in turns result in the executable not running from the build tree anymore:
>>>>
>>>>     $ ./bar
>>>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>>>       Reason: image not found
>>>>     [1]    89350 abort      ./bar
>>>>
>>>>     $ otool -L ./bar
>>>>     ./bar:
>>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>>           cmd LC_RPATH
>>>>       cmdsize 56
>>>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>>>
>>>>     # deactivate the environment
>>>>     $ conda deactivate
>>>>
>>>> --------------------------------------------------
>>>>
>>>> If I try the Anaconda compilers on Linux, there are strange results too:
>>>>
>>>>     # create the environment and install the Anaconda compiler for Linux, and XercesC
>>>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>>>     ...
>>>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>>>         binutils_linux-64:      7.2.0-had2808c_27
>>>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>>>         icu:                    58.2-h9c2bf20_1
>>>>         libgcc-ng:              7.2.0-hdf63c60_3
>>>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>>>         xerces-c:               3.2.1-hac72e42_0
>>>>
>>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>>     $ conda activate test-conda
>>>>
>>>>     $ mkdir build-linux-conda
>>>>     $ cd build-linux-conda
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is GNU 7.2.0
>>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
>>>>     ...
>>>>     -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /vagrant/conda-test/build-linux-conda
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>>>     ...
>>>>
>>>> You can see that the environment lib path is added to the RPATH by the link
>>>> command (unlike macOS):
>>>>
>>>>     $ ./bar
>>>>     Hello World!
>>>>
>>>> But when inspecting the dependencies, the environment lib path appears twice:
>>>>
>>>>     $ readelf -d ./bar
>>>>     ...
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>>>     ...
>>>>
>>>> Which is wrong. Now the build tree binary will pick first any old version of
>>>> the foo library installed in the environment instead of the version in the
>>>> build tree.
>>>>
>>>> It seems that the Anaconda toolchain is setting the environment lib path into
>>>> the RPATH by its own. It is also set when installing the binaries, even when
>>>> CMake is not configured to set the install RPATH:
>>>>
>>>>     $ make install
>>>>     ...
>>>>     Install the project...
>>>>     -- Install configuration: ""
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>>>     -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>>>
>>>>     $ bar
>>>>     Hello World!
>>>>
>>>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>>>     ...
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
>>>>     ...
>>>>
>>>>     # deactivate the environment
>>>>     $ conda deactivate
>>>>
>>>> --------------------------------------------------
>>>>
>>>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>>>> correctly.
>>>>
>>>> - On macOS, the Conda environment library path is not added to the build RPATH.
>>>> - On Linux, the Conda environment library path is always added to the RPATH
>>>>   (in both build and install) independently of CMake.
>>>>
>>>> Any advice or workarounds?
>>>>
>>>> --
>>>> Sebastian Mancilla
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake
>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valpara?so, Chile
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From ichern at google.com  Tue Aug 14 12:30:57 2018
From: ichern at google.com (Irina Chernushina)
Date: Tue, 14 Aug 2018 18:30:57 +0200
Subject: [CMake] Linker and archiver options
Message-ID: <CA+6+hcHEfMRBaP7CBspsusFmHWNf5Np8n-hQRyYnjnQ=TGFQQw@mail.gmail.com>

Hi,

What is the correct way of setting archiver (and flags) and linker
(and flags) outside the CMakeLists.txt?

1) I am trying to use the following pattern:

cmake -DCMAKE_AR="<path-to-ar>" -DCMAKE_CXX_LINK_EXECUTABLE="<linker
path> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o
<TARGET> <LINK_LIBRARIES>" -DSTATIC_LIBRARY_FLAGS="<flags>"
-DCMAKE_SHARED_LINKER_FLAGS="<flags>"
-DCMAKE_EXE_LINKER_FLAGS="<flags>"

Is that in general correct options to pass that information?
Judging by documentation, they are.

2) However, I am getting the following warning:
CMake Warning:
  Manually-specified variables were not used by the project:

    STATIC_LIBRARY_FLAGS
(Also, in CMakeCache.txt this variable is UNINITIALIZED)

If I am trying to use CMAKE_STATIC_LINKER_FLAGS, I get in the cache:

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar
...
//Flags used by the linker during the creation of static libraries.
CMAKE_STATIC_LINKER_FLAGS:STRING=rcsD

But the link command looks like:

/usr/bin/ar qc libXXX.a rcsD file1.o .. filen.o
/usr/bin/ranlib libz.a

and I get the error:
/usr/bin/ar: rcsD: No such file or directory

Because the order of ar arguments is wrong, flags should come before "qc".

Thank you in advance
Irina


Irina Chernushina | Software Developer | ichern at google.com |


Google Germany GmbH

Erika-Mann-Stra?e 33

80636 M?nchen


Gesch?ftsf?hrer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese f?lschlicherweise
erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
weiter, l?schen Sie alle Kopien und Anh?nge davon und lassen Sie mich
bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.



This e-mail is confidential. If you received this communication by
mistake, please don't forward it to anyone else, please erase all
copies and attachments, and please let me know that it has gone to the
wrong person.

From mellery451 at gmail.com  Tue Aug 14 13:34:03 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Tue, 14 Aug 2018 10:34:03 -0700
Subject: [CMake] Linker and archiver options
In-Reply-To: <CA+6+hcHEfMRBaP7CBspsusFmHWNf5Np8n-hQRyYnjnQ=TGFQQw@mail.gmail.com>
References: <CA+6+hcHEfMRBaP7CBspsusFmHWNf5Np8n-hQRyYnjnQ=TGFQQw@mail.gmail.com>
Message-ID: <9C22F813-C4B6-4677-B82E-956D9DCFDCAF@gmail.com>

This seems like something that would be best-suited for a toolchain file:

https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html

Have you given that a try? Also, I wonder if STATIC_LIBRARY_FLAGS is a custom setting, because I don?t think that one is a standard cmake variable.

-Mike

> On Aug 14, 2018, at 9:30 AM, Irina Chernushina via CMake <cmake at cmake.org> wrote:
> 
> Hi,
> 
> What is the correct way of setting archiver (and flags) and linker
> (and flags) outside the CMakeLists.txt?
> 
> 1) I am trying to use the following pattern:
> 
> cmake -DCMAKE_AR="<path-to-ar>" -DCMAKE_CXX_LINK_EXECUTABLE="<linker
> path> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o
> <TARGET> <LINK_LIBRARIES>" -DSTATIC_LIBRARY_FLAGS="<flags>"
> -DCMAKE_SHARED_LINKER_FLAGS="<flags>"
> -DCMAKE_EXE_LINKER_FLAGS="<flags>"
> 
> Is that in general correct options to pass that information?
> Judging by documentation, they are.
> 
> 2) However, I am getting the following warning:
> CMake Warning:
>  Manually-specified variables were not used by the project:
> 
>    STATIC_LIBRARY_FLAGS
> (Also, in CMakeCache.txt this variable is UNINITIALIZED)
> 
> If I am trying to use CMAKE_STATIC_LINKER_FLAGS, I get in the cache:
> 
> //Path to a program.
> CMAKE_AR:FILEPATH=/usr/bin/ar
> ...
> //Flags used by the linker during the creation of static libraries.
> CMAKE_STATIC_LINKER_FLAGS:STRING=rcsD
> 
> But the link command looks like:
> 
> /usr/bin/ar qc libXXX.a rcsD file1.o .. filen.o
> /usr/bin/ranlib libz.a
> 
> and I get the error:
> /usr/bin/ar: rcsD: No such file or directory
> 
> Because the order of ar arguments is wrong, flags should come before "qc".
> 
> Thank you in advance
> Irina
> 
> 
> Irina Chernushina | Software Developer | ichern at google.com |
> 
> 
> Google Germany GmbH
> 
> Erika-Mann-Stra?e 33
> 
> 80636 M?nchen
> 
> 
> Gesch?ftsf?hrer: Paul Manicle, Halimah DeLaine Prado
> 
> Registergericht und -nummer: Hamburg, HRB 86891
> 
> Sitz der Gesellschaft: Hamburg
> 
> 
> Diese E-Mail ist vertraulich. Falls sie diese f?lschlicherweise
> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
> weiter, l?schen Sie alle Kopien und Anh?nge davon und lassen Sie mich
> bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
> 
> 
> 
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all
> copies and attachments, and please let me know that it has gone to the
> wrong person.
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/6826f996/attachment.sig>

From Riley.Bohr at RadiantSolutions.com  Tue Aug 14 13:28:03 2018
From: Riley.Bohr at RadiantSolutions.com (Bohr, Riley)
Date: Tue, 14 Aug 2018 17:28:03 +0000
Subject: [CMake] External header only library (boost)
Message-ID: <3F2AD636235F7B4DA57BB93BD9E5FA9E76D5F0@MIINFEX01.mdaus.corp>

Hi CMake people,

I am trying to configure CMake to retrieve boost, and then run boosts bcp tool to extract a subset of boost (math/special_functions) that I need for my project. I had it working before, but now I'm not sure what went wrong.

Right now when I build, CMake is able to retrieve the boost zip archive from their website, extract it, and run bcp to extract the subset, but now when I build my project that depends on the imported boost library it is looking for .obj files.

Since boost is header only, it doesn't need to be built, so should CMake be looking for library files?

This is the contents of CMakeLists-BOOST.txt that the main CMakeLists.txt calls. The boost-bcp.py script is able to extract the subset of header files that I need, so the problem shouldn't be in there.

Any help is appreciated, thank you



include(ExternalProject)

set(BOOST_PREFIX "${CMAKE_SOURCE_DIR}/../pulsar-boost")

file(MAKE_DIRECTORY ${BOOST_PREFIX})
file(MAKE_DIRECTORY ${BOOST_PREFIX}/boost-full)
file(MAKE_DIRECTORY ${BOOST_PREFIX}/include)

ExternalProject_Add(boost
    URL https://dl.bintray.com/boostorg/release/1.67.0/source/boost_1_67_0.zip

    PATCH_COMMAND ""

    PREFIX "${BOOST_PREFIX}"

    SOURCE_DIR "${BOOST_PREFIX}/boost-full"


    CONFIGURE_COMMAND ""
    BUILD_COMMAND ""
    INSTALL_COMMAND ""

    TEST_COMMAND ""

    LOG_DOWNLOAD 1
    LOG_CONFIGURE 1
    LOG_INSTALL 1
)




# Additional submodules can be passed to the python script if needed
# BCP will extract each subset
ExternalProject_Add_Step(boost
    bcp
    COMMAND python boost-bcp.py math/special_functions
    DEPENDEES download
    ALWAYS 0
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    LOG 1
)

ExternalProject_Get_Property(boost install_dir)

message("boost install dir: " ${install_dir})

add_library(pulsar-boost STATIC IMPORTED)

set_property(TARGET pulsar-boost PROPERTY IMPORTED_LOCATION ${install_dir}/lib/lib-boost)

add_dependencies(pulsar-boost boost)

include_directories(${install_dir}/include)




The information contained in this communication is confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/350768f6/attachment-0001.html>

From smancill at jlab.org  Tue Aug 14 14:38:10 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Tue, 14 Aug 2018 15:38:10 -0300
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
 <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
Message-ID: <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>

I wanted to try Conda for normal day-to-day C++ development, while having
all the dependencies isolated from other projects and the base system.

- Change the sources
- Build
- Run the tests
- Repeat

The most common workflow possible. I shouldn't go through conda-build for
that. There is nothing special about $CONDA_PREFIX that requires handling
by conda-build, I just need to point to the headers and the libraries
(which by using Conda are conveniently under a single prefix).

Then when development is more or less ready I can use conda-build to create
a package that can be installed and tested in other environments, and it
works fine when building/installing a CMake project (I have being doing
that without problems these last days and I happy with it, much better than
Nix).

My main issue is that, as I explained, I cannot run the tests because
$CONDA_PREFIX/lib is not in the build RPATH, and I wanted to understand
why, and maybe get a workaround.
Passing -DCMAKE_BUILD_RPATH=$CONDA_PREFIX/lib allows the dependencies to be
found, but it doesn't really do the same thing.


Another common thing that may be done is to develop a couple of projects in
the same environment:

- Work on A
- Install A into $CONDA_PREFIX, so I can compile B against it and check
their integration
- Back to more work on A
- Run the tests of A to check changes

I have being using CMake exclusively in the last 5+ years, and I got used
to the way the RPATH are set in the build tree. I know that if I run the
tests, they will run agains the modified version of A compiled in the build
tree, and not the version installed previously in PREFIX.

(Somebody may say that A and B should be built at the same time [with build
tree exports and add_directory, or going through the package registry], but
that's not the point. B may not even use CMake).

CMake defaults plus Anaconda compilers break that by not having the RPATH
in the expected order. And it is not easy to get them right.

But maybe it is just me too accustomed to the way CMake works by default. I
don't really know how people using Autotools or Meson run their tests. Do
they set the RPATH?


El mar., 14 de ago. de 2018 a la(s) 03:43, Ray Donnelly (
mingw.android at gmail.com) escribi?:

> Why are you not using conda-build here? Anaconda Distro and
> conda-forge build countless CMake projects. It handles so much extra
> stuff on top of building (DSO verification, rpath rewriting, more). If
> your end goal is not conda packages then you can untar most sets of
> conda-packages to make working software installations (caveat for most
> being that some software requires what we call 'prefix replacament'
> and those aren't trivially relocatable).
>
> IMHO CMake's handling of RPATHs is broken, as per my "determine
> implicit linker directories" PR which there seems to be little to no
> interest in instead preferring toolchain cmake files for something
> that *clearly* should be queried from the link as it is imperative
> when building software that CMake and the toolchain agree on things as
> fundamental as this.
>
> RPATH is never set by a toolchain except through being passed to it
> (by CMake's logic, fixed by
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_merge-5Frequests_207&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=wviv_JywOo9sb5vTUw4ilTQ5JMOrMD9A_hxuf-rCcZA&e=
> ).
>
> I would again request that this pretty trivial, obvious and important
> PR gets some consideration. Without it CMake asks anyone trying to
> build a software distro with more than simple system prefix-based
> compilation will run into needing this fix or needing to provide a
> toolchain just to tell CMake what it should figure out for itself.
>
> On Tue, Aug 14, 2018 at 2:12 AM, Sebasti?n Mancilla <smancill at jlab.org>
> wrote:
> > Thanks for the links.
> >
> > The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
> > for binaries and libraries in the build tree, the list of RPATH
> > locations will be in the wrong order: the dependencies library path
> > will be first, and then the build tree. This will break the unit tests
> > if the library was installed previously (for example, to check the
> > library by running other installed programs), and then modified as
> > part of normal development, because the installed version will be
> > loaded instead of the version in the build tree. CMake supports this
> > use case out of the box and it works great (when not using Anaconda).
> >
> > Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
> > RPATH by the Anaconda toolchain itself, and it will appear first, so
> > there is nothing that can be done about that with CMake.
> >
> > It seems that the workarounds when using Anaconda compilers, and doing
> > development, are:
> >
> > - Always install before unit testing changes to the library being
> > developed (and set CMAKE_BUILD_RPATH).
> > - Never install the library (so the build tree not being first in the
> > RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
> > environment to test installation.
> > - Don't use the build RPATH and set the proper environment variables
> > ([DY]LD_LIBRARY_PATH) with the right path order when running from the
> > build tree.
> > - Manipulate the RPATH manually (with patchelf or similar).
> > - Don't use Anaconda compilers (will there be binary issues with
> > Anaconda dependencies?)
> >
> > But they are not ideal.
> >
> >
> > If the Conda environment is not being used for development and someone
> > wants to just build and use some binary/library, setting
> > CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
> > fine. And it looks that is not even necessary on Linux, because the
> > RPATH is already set by the toolchain.
> >
> > El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
> > (isaiah.norton at gmail.com) escribi?:
> >>
> >> See also:
> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_merge-5Frequests_207&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=wviv_JywOo9sb5vTUw4ilTQ5JMOrMD9A_hxuf-rCcZA&e=
> >>
> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_issues_17483&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=1HXSUEWs7xRLJp5YZX-GkAVK2XOSe8fuzCRIAvAfNcA&e=
> (looks semi-related)
> >>
> >> Ray Donnelly, who filed those issues, maintains the Anaconda compiler
> toolchain -- so you are in good company hitting this issue. It looks like
> some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_AnacondaRecipes_vtk-2Dfeedstock_blob_791a1db9026fa2c81d171c38835b512adf221794_recipe_build.sh-23L30&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=06Ed9Yo2DX991fx_H21n9HBNLLFLNa94vVxrGHTc75I&e=
> >>
> >>
> >>
> >> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <isaiah.norton at gmail.com>
> wrote:
> >>>
> >>> The RPATH is not included when using Anaconda because CMake considers
> the Anaconda lib path to be an implicit link directory (as reported by the
> compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section
> about "implicit link info".
> >>>
> >>> The simplest work-around is to set BUILD_RPATH manually, and possibly
> also INSTALL_RPATH, depending on what conda-build's fixup routine expects.
> >>>
> >>> For example, adding this line near the top of your example CMakeList
> fixed the resulting binary, at least in the build directory:
> >>>
> >>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
> >>>
> >>>
> >>> On Fri, Aug 10, 2018 at 5:55 PM Sebasti?n Mancilla <smancill at jlab.org>
> wrote:
> >>>>
> >>>> I am trying to use Conda as a package manager for isolated C++
> development
> >>>> environments. But unfortunately, when using CMake with the
> Anaconda-provided
> >>>> compilers [1] (which are used to compile the binary packages in the
> Anaconda
> >>>> repositories), things do not work as expected.
> >>>>
> >>>> I have a small test case available here [2], with an executable
> calling a
> >>>> shared library and a third-party dependency installed with Conda.
> >>>>
> >>>> [1]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__conda.io_docs_user-2Dguide_tasks_build-2Dpackages_compiler-2Dtools.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=jvTiH6i8c51MldDSbrw1AxiclEs1TKUMg-iQpLOoJqM&e=
> >>>> [2]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_smancill_b28ca07ac11fdf285b4d559545a1630b&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=q3em0cZgykXNfXgRt7bdxCnVuz0FkuNVx462yPtpEbA&e=
> >>>>
> >>>> --------------------------------------------------
> >>>>
> >>>> First, when using the system compiler, all works fine (but I am not
> sure of the
> >>>> binary compatibility with the Conda packages, that's why I want to
> use the
> >>>> Anaconda compilers):
> >>>>
> >>>>     # create the environment and install XercesC
> >>>>     $ conda create -n test-system xerces-c
> >>>>     ...
> >>>>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
> >>>>     ...
> >>>>     The following NEW packages will be INSTALLED:
> >>>>
> >>>>     icu:       58.2-h4b95b61_1
> >>>>     libcxx:    4.0.1-h579ed51_0
> >>>>     libcxxabi: 4.0.1-hebd6815_0
> >>>>     xerces-c:  3.2.1-h44e365a_0
> >>>>     ...
> >>>>
> >>>>     # activate the environment
> >>>>     $ conda activate test-system
> >>>>
> >>>>     $ mkdir build-osx-system
> >>>>     $ cd build-osx-system
> >>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> >>>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
> >>>>     -- Check for working CXX compiler: /usr/bin/c++
> >>>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
> >>>>     ...
> >>>>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
> >>>>     -- Configuring done
> >>>>     -- Generating done
> >>>>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
> >>>>
> >>>>     $ make -j1 VERBOSE=1
> >>>>     ...
> >>>>     [100%] Linking CXX executable bar
> >>>>     /usr/local/bin/cmake -E cmake_link_script
> CMakeFiles/bar.dir/link.txt --verbose=1
> >>>>     /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> >>>>     ...
> >>>>
> >>>> The build directory (~/src/conda-test/build-osx-system) and the conda
> >>>> environment lib directory
> (~/.local/share/miniconda3/envs/test-system/lib)
> >>>> are correctly added to the RPATH in the build tree by the link
> command:
> >>>>
> >>>>     $ ./bar
> >>>>     Hello, world!
> >>>>
> >>>>     $ otool -L ./bar
> >>>>     ./bar:
> >>>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current
> version 0.0.0)
> >>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> >>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
> >>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 1252.0.0)
> >>>>
> >>>>     $ otool -l ./bar | grep -A2 LC_RPATH
> >>>>             cmd LC_RPATH
> >>>>         cmdsize 56
> >>>>             path /Users/smancill/src/conda-test/build-osx-system
> (offset 12)
> >>>>     --
> >>>>             cmd LC_RPATH
> >>>>         cmdsize 80
> >>>>             path
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
> >>>>
> >>>> If I install the binary, it fails because I haven't configured CMake
> to set the install RPATH:
> >>>>
> >>>>     $ make install
> >>>>     ...
> >>>>     Install the project...
> >>>>     -- Install configuration: ""
> >>>>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
> >>>>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
> >>>>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
> >>>>
> >>>>     $ bar
> >>>>     dyld: Library not loaded: @rpath/libfoo.dylib
> >>>>       Referenced from:
> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
> >>>>       Reason: image not found
> >>>>     [1]    84611 abort      bar
> >>>>
> >>>>     $ otool -L $CONDA_PREFIX/bin/bar
> >>>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
> >>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current
> version 0.0.0)
> >>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> >>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
> >>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 1252.0.0)
> >>>>
> >>>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
> >>>>     # empty
> >>>>
> >>>>     # deactivate the environment to start again
> >>>>     $ conda deactivate
> >>>>
> >>>> The same can be observed on Linux. Everything works as it should.
> >>>>
> >>>> --------------------------------------------------
> >>>>
> >>>> If I try to use Anaconda compilers on macOS, the build RPATH is not
> set
> >>>> properly anymore:
> >>>>
> >>>>     # create the environment and install the Anaconda compiler for
> macOS, and XercesC
> >>>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
> >>>>     ...
> >>>>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-conda
> >>>>     ...
> >>>>     The following NEW packages will be INSTALLED:
> >>>>
> >>>>         cctools:        895-h7512d6f_0
> >>>>         clang:          4.0.1-h662ec87_0
> >>>>         clang_osx-64:   4.0.1-h1ce6c1d_11
> >>>>         clangxx:        4.0.1-hc9b4283_0
> >>>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
> >>>>         compiler-rt:    4.0.1-h5487866_0
> >>>>         icu:            58.2-h4b95b61_1
> >>>>         ld64:           274.2-h7c2db76_0
> >>>>         libcxx:         4.0.1-h579ed51_0
> >>>>         libcxxabi:      4.0.1-hebd6815_0
> >>>>         llvm:           4.0.1-hc748206_0
> >>>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
> >>>>         xerces-c:       3.2.1-h44e365a_0
> >>>>     ...
> >>>>
> >>>>     # activate the environment (which sets the variables to use the
> Anaconda compiler)
> >>>>     $ conda activate test-conda
> >>>>
> >>>>     $ mkdir build-osx-conda
> >>>>     $ cd build-osx-conda
> >>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> >>>>     -- The CXX compiler identification is Clang 4.0.1
> >>>>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> >>>>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -- works
> >>>>     ...
> >>>>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> (found version "3.2.1")
> >>>>     -- Configuring done
> >>>>     -- Generating done
> >>>>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-conda
> >>>>
> >>>>     $ make -j1 VERBOSE=1
> >>>>     ...
> >>>>     [100%] Linking CXX executable bar
> >>>>     /usr/local/bin/cmake -E cmake_link_script
> CMakeFiles/bar.dir/link.txt --verbose=1
> >>>>
>  /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> -fstack-protector-strong -O2 -pipe -stdlib=libc++
> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> >>>>     ...
> >>>>
> >>>> You can see that the environment lib path is not added to the RPATH
> by the link command,
> >>>> which in turns result in the executable not running from the build
> tree anymore:
> >>>>
> >>>>     $ ./bar
> >>>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
> >>>>       Referenced from:
> /Users/smancill/src/conda-test/build-osx-conda/./bar
> >>>>       Reason: image not found
> >>>>     [1]    89350 abort      ./bar
> >>>>
> >>>>     $ otool -L ./bar
> >>>>     ./bar:
> >>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current
> version 0.0.0)
> >>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> >>>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> >>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 1252.0.0)
> >>>>
> >>>>     $ otool -l ./bar | grep -A2 LC_RPATH
> >>>>           cmd LC_RPATH
> >>>>       cmdsize 56
> >>>>          path /Users/smancill/src/conda-test/build-osx-conda (offset
> 12)
> >>>>
> >>>>     # deactivate the environment
> >>>>     $ conda deactivate
> >>>>
> >>>> --------------------------------------------------
> >>>>
> >>>> If I try the Anaconda compilers on Linux, there are strange results
> too:
> >>>>
> >>>>     # create the environment and install the Anaconda compiler for
> Linux, and XercesC
> >>>>     $ conda create -n test-conda gxx_linux-64 xerces-c
> >>>>     ...
> >>>>     environment location: /home/vagrant/miniconda3/envs/test-conda
> >>>>     ...
> >>>>     The following NEW packages will be INSTALLED:
> >>>>
> >>>>         binutils_impl_linux-64: 2.28.1-had2808c_3
> >>>>         binutils_linux-64:      7.2.0-had2808c_27
> >>>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
> >>>>         gcc_linux-64:           7.2.0-h550dcbe_27
> >>>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
> >>>>         gxx_linux-64:           7.2.0-h550dcbe_27
> >>>>         icu:                    58.2-h9c2bf20_1
> >>>>         libgcc-ng:              7.2.0-hdf63c60_3
> >>>>         libstdcxx-ng:           7.2.0-hdf63c60_3
> >>>>         xerces-c:               3.2.1-hac72e42_0
> >>>>
> >>>>     # activate the environment (which sets the variables to use the
> Anaconda compiler)
> >>>>     $ conda activate test-conda
> >>>>
> >>>>     $ mkdir build-linux-conda
> >>>>     $ cd build-linux-conda
> >>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> >>>>     -- The CXX compiler identification is GNU 7.2.0
> >>>>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> >>>>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -- works
> >>>>     ...
> >>>>     -- Found XercesC:
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
> "3.2.1")
> >>>>     -- Configuring done
> >>>>     -- Generating done
> >>>>     -- Build files have been written to:
> /vagrant/conda-test/build-linux-conda
> >>>>
> >>>>     $ make -j1 VERBOSE=1
> >>>>     ...
> >>>>     [100%] Linking CXX executable bar
> >>>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
> >>>>
>  /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>  -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
> >>>>     ...
> >>>>
> >>>> You can see that the environment lib path is added to the RPATH by
> the link
> >>>> command (unlike macOS):
> >>>>
> >>>>     $ ./bar
> >>>>     Hello World!
> >>>>
> >>>> But when inspecting the dependencies, the environment lib path
> appears twice:
> >>>>
> >>>>     $ readelf -d ./bar
> >>>>     ...
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libfoo.so]
> >>>>      0x0000000000000001 (NEEDED)             Shared library: [
> libxerces-c-3.2.so]
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libgcc_s.so.1]
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libc.so.6]
> >>>>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
> >>>>     ...
> >>>>
> >>>> Which is wrong. Now the build tree binary will pick first any old
> version of
> >>>> the foo library installed in the environment instead of the version
> in the
> >>>> build tree.
> >>>>
> >>>> It seems that the Anaconda toolchain is setting the environment lib
> path into
> >>>> the RPATH by its own. It is also set when installing the binaries,
> even when
> >>>> CMake is not configured to set the install RPATH:
> >>>>
> >>>>     $ make install
> >>>>     ...
> >>>>     Install the project...
> >>>>     -- Install configuration: ""
> >>>>     -- Installing:
> /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
> >>>>     -- Installing:
> /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
> >>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
> >>>>     -- Set runtime path of
> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
> >>>>
> >>>>     $ bar
> >>>>     Hello World!
> >>>>
> >>>>     $ readelf -d $CONDA_PREFIX/bin/bar
> >>>>     ...
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libfoo.so]
> >>>>      0x0000000000000001 (NEEDED)             Shared library: [
> libxerces-c-3.2.so]
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libgcc_s.so.1]
> >>>>      0x0000000000000001 (NEEDED)             Shared library:
> [libc.so.6]
> >>>>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib]
> >>>>     ...
> >>>>
> >>>>     # deactivate the environment
> >>>>     $ conda deactivate
> >>>>
> >>>> --------------------------------------------------
> >>>>
> >>>> TL;DR I cannot get CMake and the Anaconda compilers and packages
> working
> >>>> correctly.
> >>>>
> >>>> - On macOS, the Conda environment library path is not added to the
> build RPATH.
> >>>> - On Linux, the Conda environment library path is always added to the
> RPATH
> >>>>   (in both build and install) independently of CMake.
> >>>>
> >>>> Any advice or workarounds?
> >>>>
> >>>> --
> >>>> Sebastian Mancilla
> >>>> --
> >>>>
> >>>> 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=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=uBEF8GemaQb9eJ-UK_hEzA_YgX3pQ-boOIEG7uPkAyc&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_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=svD5IJGKwoXnqAMeR130SGVF4UsybjdD3_6P3kozhAA&e=
> >>>> CMake Consulting:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=07p3Ic2lHKjWP1e65eN4md9oL_EaUWgnDc4fUQCx4oI&e=
> >>>> CMake Training Courses:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=z4EmjaY7PSqPEwinemJnTXOI9drLVGgOGoIE1HRhk4o&e=
> >>>>
> >>>> Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=QzHKjq3n_bPKgzhchCEiD0_KFJrVhaXBFSACVpxG5nU&e=
> >>>>
> >>>> Follow this link to subscribe/unsubscribe:
> >>>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=fOiqJW-HpoDIaOBxq5-_9vu0GwxF4qjmchJS1C3GHjI&e=
> >
> >
> >
> > --
> > Sebastian Mancilla Matta
> > CCTVal, UTFSM
> > Valpara?so, Chile
> > --
> >
> > 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=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=uBEF8GemaQb9eJ-UK_hEzA_YgX3pQ-boOIEG7uPkAyc&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_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=svD5IJGKwoXnqAMeR130SGVF4UsybjdD3_6P3kozhAA&e=
> > CMake Consulting:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=07p3Ic2lHKjWP1e65eN4md9oL_EaUWgnDc4fUQCx4oI&e=
> > CMake Training Courses:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=z4EmjaY7PSqPEwinemJnTXOI9drLVGgOGoIE1HRhk4o&e=
> >
> > Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=QzHKjq3n_bPKgzhchCEiD0_KFJrVhaXBFSACVpxG5nU&e=
> >
> > Follow this link to subscribe/unsubscribe:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=fOiqJW-HpoDIaOBxq5-_9vu0GwxF4qjmchJS1C3GHjI&e=
>


-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/4b3c1ac1/attachment-0001.html>

From smancill at jlab.org  Tue Aug 14 16:08:36 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Tue, 14 Aug 2018 17:08:36 -0300
Subject: [CMake] Printing "Found <package>..." message in config mode
Message-ID: <CAJPSwc3MncfeFEWE=M_KpfYQNx=srriv=OgJjTVxBR16sQUPRw@mail.gmail.com>

Normally, find modules call FIND_PACKAGE_HANDLE_STANDARD_ARGS, which in
turn calls FIND_PACKAGE_MESSAGE, to print a nice message about the location
and version of the dependency.

But I haven't found any way or example to do the same when using the CONFIG
mode of find_package. And I really want to see some output about where the
dependencies are located. So I came up with this:

    # Prints a message with the location and version of a package
    # found in config mode, similar to the message printed by module files.
    # When multiple configurations are installed, this tries to print
    # the location to the same library selected by the CMake generator.
    #
    # TODO: handle configuration mapping (?)
    function(find_package_config_message _package _target _version)
      # The location matching the same build configuration as downstream
      # is selected when linking to the library
      set(_build_type ${CMAKE_BUILD_TYPE})
      if (_build_type)
        string(TOUPPER "IMPORTED_LOCATION_${_build_type}" _location_prop)
        get_target_property(_location_path ${_target} ${_location_prop})
      endif()
      # If downstream has no build configuration set,
      # or the installed package has no matching configuration,
      # the first listed configuration is used to get the location to the
library
      if(NOT _location_path)
        get_target_property(_target_configurations ${_target}
IMPORTED_CONFIGURATIONS)
        if(_target_configurations)
          list(GET _target_configurations 0 _build_type)
          get_target_property(_location_path ${_target}
"IMPORTED_LOCATION_${_build_type}")
        endif()
        if (NOT _location_path)
          message(SEND_ERROR "No imported location for target ${_target}")
        endif()
      endif()

      set(_message "Found ${_package}")
      set(_details "[${_build_type}]")
      if(_location_path)
        set(_message "${_message}: ${_location_path}")
        set(_details "[${_location_path}]${_details}")
      endif()
      if(_version)
        set(_message "${_message} (found version \"${_version}\")")
        set(_details "[${_version}]${_details}")
      endif()
      find_package_message(${_package} ${_message} ${_details})
    endfunction()

I think I got it right, based on the observed behavior while experimenting
with different values for CMAKE_BUILD_TYPE on both upstream and downstream,
and it works fine for most common cases.

I would use in the FooConfig.cmake like this (the function would be in
FooHelpers.cmake):

    if(NOT TARGET Foo::Foo)
      include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake")
      include("${CMAKE_CURRENT_LIST_DIR}/FooHelpers.cmake")
      find_package_config_message(Foo Foo::Foo "@PROJECT_VERSION@")
    endif()

Any thoughts/comments?

-- 
Sebastian Mancilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/fad8c490/attachment.html>

From bitminer at gmail.com  Tue Aug 14 18:20:37 2018
From: bitminer at gmail.com (Brian Davis)
Date: Tue, 14 Aug 2018 17:20:37 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after
 installing 2017... sigh.
Message-ID: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>

Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing
2017... sigh.

Without even regenerating or re configuring (even though that has no effect
either) when "Open Project" is selected 2017 is opened and not 2013... errr
what am I targeting again?  Happened after 2017 install.  How does CMake
Decide which app to call.... err I got a sneaky suspicion as to how.... in
a not so goodly way.

Sure wishI could get CMake to open VS2013 with the environment vars I ahve
set when it was called... guess  I'll have to settle for the new and
improved VS2017 I can't use on the project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/7856faac/attachment.html>

From scott at towel42.com  Tue Aug 14 18:26:13 2018
From: scott at towel42.com (Scott Bloom)
Date: Tue, 14 Aug 2018 22:26:13 +0000
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
Message-ID: <CY1PR10MB0812C284433050439917AEBFA9380@CY1PR10MB0812.namprd10.prod.outlook.com>

It doesn?t for me..  I would check your path?  its probably just calling devenv, and not an explicit path

Scott

From: CMake <cmake-bounces at cmake.org> On Behalf Of Brian Davis
Sent: Tuesday, August 14, 2018 15:21
To: cmake Mailing List <cmake at cmake.org>
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.


Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.

Without even regenerating or re configuring (even though that has no effect either) when "Open Project" is selected 2017 is opened and not 2013... errr what am I targeting again?  Happened after 2017 install.  How does CMake Decide which app to call.... err I got a sneaky suspicion as to how.... in a not so goodly way.

Sure wishI could get CMake to open VS2013 with the environment vars I ahve set when it was called... guess  I'll have to settle for the new and improved VS2017 I can't use on the project.



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

From post at hendrik-sattler.de  Tue Aug 14 18:36:48 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 15 Aug 2018 00:36:48 +0200
Subject: [CMake] Printing "Found <package>..." message in config mode
In-Reply-To: <CAJPSwc3MncfeFEWE=M_KpfYQNx=srriv=OgJjTVxBR16sQUPRw@mail.gmail.com>
References: <CAJPSwc3MncfeFEWE=M_KpfYQNx=srriv=OgJjTVxBR16sQUPRw@mail.gmail.com>
Message-ID: <C15005C5-5F77-4A96-872B-7F8EF4579AC2@hendrik-sattler.de>



Am 14. August 2018 22:08:36 MESZ schrieb "Sebasti?n Mancilla" <smancill at jlab.org>:
>Normally, find modules call FIND_PACKAGE_HANDLE_STANDARD_ARGS, which in
>turn calls FIND_PACKAGE_MESSAGE, to print a nice message about the
>location
>and version of the dependency.

You can do that with FIND_PACKAGE_HANDLE_STANDARD_ARGS, just use module name and CONFIG_MODE as arguments.

HS

From post at hendrik-sattler.de  Tue Aug 14 18:41:23 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 15 Aug 2018 00:41:23 +0200
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
Message-ID: <C91B8C18-B3CB-484E-B84B-4AE114432BEB@hendrik-sattler.de>



Am 15. August 2018 00:20:37 MESZ schrieb Brian Davis <bitminer at gmail.com>:
>Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing
>2017... sigh.
>
>Without even regenerating or re configuring (even though that has no
>effect
>either) when "Open Project" is selected 2017 is opened and not 2013...
>errr
>what am I targeting again?  Happened after 2017 install.  How does
>CMake
>Decide which app to call.... err I got a sneaky suspicion as to how....
>in
>a not so goodly way.
>
>Sure wishI could get CMake to open VS2013 with the environment vars I
>ahve
>set when it was called... guess  I'll have to settle for the new and
>improved VS2017 I can't use on the project.

Or probably uses the Qt function to open the project file with the same program that is configured in Explorer. So change it there. There is a Visual Studio version selector but VS2017 can also open some older versions and use their toolkits.

HS

From d3ck0r at gmail.com  Tue Aug 14 19:05:43 2018
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 14 Aug 2018 16:05:43 -0700
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
Message-ID: <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>

Visual studio 2017 is able to keep old project types and build them as
is... so it is using the 2013 tools even though loaded in the 2017 IDE.
I noticed this because the command line build tools are 2015, so if I
configure a project for node; it gets built as 2015, and the visual studio
project when loaded in 2017 shows (Visual Studio 2015) after the project in
solution explorer...

And/or you should be able to set the platform toolset

(in the project property dialog, General) Platform toolset : Visual Studio
2015 (v140)
I've seen it with other IDE projects; I don't have that system available
though (back to v110_xp)

On Tue, Aug 14, 2018 at 3:20 PM Brian Davis <bitminer at gmail.com> wrote:

>
> Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing
> 2017... sigh.
>
> Without even regenerating or re configuring (even though that has no
> effect either) when "Open Project" is selected 2017 is opened and not
> 2013... errr what am I targeting again?  Happened after 2017 install.  How
> does CMake Decide which app to call.... err I got a sneaky suspicion as to
> how.... in a not so goodly way.
>
> Sure wishI could get CMake to open VS2013 with the environment vars I ahve
> set when it was called... guess  I'll have to settle for the new and
> improved VS2017 I can't use on the project.
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/0b85dbaa/attachment.html>

From bitminer at gmail.com  Tue Aug 14 19:27:00 2018
From: bitminer at gmail.com (Brian Davis)
Date: Tue, 14 Aug 2018 18:27:00 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
Message-ID: <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>

It also cannot find CUDA likely as CUDA was not installed after 2017.  I
would like it to load 2013 after being told to generate Visual Studio 2013
project files.  Is this difficult to ask fo Kitware?  I am sure there are
certainly some shenanigans like path or VS2017 hooking calls to 2013 tools
or the like all of which I am sure make sens to a cubite in the bowels of
the MS machine.  VS loaded 2017 and vs 2013  proj files then promptly had
problems searching files, compiling stale targets and the like.  So while
VS2017 make "hook" 2013 tools it certainly can't do any thing useful with
them IME.  Is there a Meta buld tool (goop generator) that will build goop
for a target goop reader then call said target goop reader (of correct
specified version) to read goop and compile my code?  sigh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/35fe28a3/attachment.html>

From rubendibattista at gmail.com  Tue Aug 14 20:06:53 2018
From: rubendibattista at gmail.com (Ruben Di Battista)
Date: Tue, 14 Aug 2018 20:06:53 -0400
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
Message-ID: <CACnYWRfUiFinLy1HWRsRSXEPVW3163XA+30vAGN64LE3_=QZNw@mail.gmail.com>

What about switching to Linux? It generally does what you tell it to do. :)

(Just wanted to release a bit the tension here? Dunno how effective it
is...)
_

-.     .?  |????
  ',  ;    |??????
    ??     |????????? RdB
    ,.,    |??????
  .'   '.  |????
-'       `?
https://rdb.is


On 15 agosto 2018 a 01:27:07, Brian Davis (bitminer at gmail.com) scritto:


It also cannot find CUDA likely as CUDA was not installed after 2017.  I
would like it to load 2013 after being told to generate Visual Studio 2013
project files.  Is this difficult to ask fo Kitware?  I am sure there are
certainly some shenanigans like path or VS2017 hooking calls to 2013 tools
or the like all of which I am sure make sens to a cubite in the bowels of
the MS machine.  VS loaded 2017 and vs 2013  proj files then promptly had
problems searching files, compiling stale targets and the like.  So while
VS2017 make "hook" 2013 tools it certainly can't do any thing useful with
them IME.  Is there a Meta buld tool (goop generator) that will build goop
for a target goop reader then call said target goop reader (of correct
specified version) to read goop and compile my code?  sigh.

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/c117bd56/attachment.html>

From isaiah.norton at gmail.com  Tue Aug 14 22:16:37 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Tue, 14 Aug 2018 22:16:37 -0400
Subject: [CMake] Linker and archiver options
In-Reply-To: <9C22F813-C4B6-4677-B82E-956D9DCFDCAF@gmail.com>
References: <CA+6+hcHEfMRBaP7CBspsusFmHWNf5Np8n-hQRyYnjnQ=TGFQQw@mail.gmail.com>
 <9C22F813-C4B6-4677-B82E-956D9DCFDCAF@gmail.com>
Message-ID: <CADFtqoqvW-PaJQNPLqd6DXmrYB3SoWznvR_GibQuCAh8-hY=qw@mail.gmail.com>

>
> This seems like something that would be best-suited for a toolchain file
>

Is a toolchain file not equivalent to the corresponding list of '-D'
initializers? (aside from convenience)

On Tue, Aug 14, 2018 at 1:34 PM Michael Ellery <mellery451 at gmail.com> wrote:

> This seems like something that would be best-suited for a toolchain file:
>
> https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html
>
> Have you given that a try? Also, I wonder if STATIC_LIBRARY_FLAGS is a
> custom setting, because I don?t think that one is a standard cmake variable.
>
> -Mike
>
> > On Aug 14, 2018, at 9:30 AM, Irina Chernushina via CMake <
> cmake at cmake.org> wrote:
> >
> > Hi,
> >
> > What is the correct way of setting archiver (and flags) and linker
> > (and flags) outside the CMakeLists.txt?
> >
> > 1) I am trying to use the following pattern:
> >
> > cmake -DCMAKE_AR="<path-to-ar>" -DCMAKE_CXX_LINK_EXECUTABLE="<linker
> > path> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o
> > <TARGET> <LINK_LIBRARIES>" -DSTATIC_LIBRARY_FLAGS="<flags>"
> > -DCMAKE_SHARED_LINKER_FLAGS="<flags>"
> > -DCMAKE_EXE_LINKER_FLAGS="<flags>"
> >
> > Is that in general correct options to pass that information?
> > Judging by documentation, they are.
> >
> > 2) However, I am getting the following warning:
> > CMake Warning:
> >  Manually-specified variables were not used by the project:
> >
> >    STATIC_LIBRARY_FLAGS
> > (Also, in CMakeCache.txt this variable is UNINITIALIZED)
> >
> > If I am trying to use CMAKE_STATIC_LINKER_FLAGS, I get in the cache:
> >
> > //Path to a program.
> > CMAKE_AR:FILEPATH=/usr/bin/ar
> > ...
> > //Flags used by the linker during the creation of static libraries.
> > CMAKE_STATIC_LINKER_FLAGS:STRING=rcsD
> >
> > But the link command looks like:
> >
> > /usr/bin/ar qc libXXX.a rcsD file1.o .. filen.o
> > /usr/bin/ranlib libz.a
> >
> > and I get the error:
> > /usr/bin/ar: rcsD: No such file or directory
> >
> > Because the order of ar arguments is wrong, flags should come before
> "qc".
> >
> > Thank you in advance
> > Irina
> >
> >
> > Irina Chernushina | Software Developer | ichern at google.com |
> >
> >
> > Google Germany GmbH
> >
> > Erika-Mann-Stra?e 33
> >
> > 80636 M?nchen
> >
> >
> > Gesch?ftsf?hrer: Paul Manicle, Halimah DeLaine Prado
> >
> > Registergericht und -nummer: Hamburg, HRB 86891
> >
> > Sitz der Gesellschaft: Hamburg
> >
> >
> > Diese E-Mail ist vertraulich. Falls sie diese f?lschlicherweise
> > erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
> > weiter, l?schen Sie alle Kopien und Anh?nge davon und lassen Sie mich
> > bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
> >
> >
> >
> > This e-mail is confidential. If you received this communication by
> > mistake, please don't forward it to anyone else, please erase all
> > copies and attachments, and please let me know that it has gone to the
> > wrong person.
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180814/45e0d3f5/attachment-0001.html>

From eric.noulard at gmail.com  Wed Aug 15 04:29:38 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 15 Aug 2018 10:29:38 +0200
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
 <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
 <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>
Message-ID: <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>

Le mar. 14 ao?t 2018 ? 20:38, Sebasti?n Mancilla <smancill at jlab.org> a
?crit :

> I wanted to try Conda for normal day-to-day C++ development, while having
> all the dependencies isolated from other projects and the base system.
>
> - Change the sources
> - Build
> - Run the tests
> - Repeat
>

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology
like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better
isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like
as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda
packaged software:
https://github.com/BioContainers/mulled
I have no experience with that whatsoever, I usually craft my own
dockerfile and work with that.

If your goal includes the distrubution of your software as conda package
may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of
cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/2965d0fc/attachment.html>

From damir_porobic at live.com  Wed Aug 15 04:32:26 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Wed, 15 Aug 2018 08:32:26 +0000
Subject: [CMake] Problem with creating shared library
Message-ID: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Hi Folks,


I'm trying to write a shared library and run into an issue where I can't find any clues to where the problem is.

I have a project with following structure:


src/

    dir1/

        file1.h

        file1.cpp

    dir2/

        file2.h

        file2.cpp



Now I have this CMakeList:

cmake_minimum_required(VERSION 3.5)

project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)


...


add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons KF5::I18n KF5::WidgetsAddons)

target_include_directories(${PROJECT_NAME} PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)

set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION} SOVERSION 1)

set(kimageannotator_CONFIG ${PROJECT_NAME}Config)

install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
        ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})

install(EXPORT ${kimageannotator_CONFIG} DESTINATION share/${kimageannotator_CONFIG}/cmake)

export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)


In another test project, I add the library like this:
...
find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp Qt5::Widgets kImageAnnotator)


Now when I try to build my test project, I get this:

dporobic at linux ~/projects/testApp/build
$ cmake .. && make
-- Could not set up the appstream test. appstreamcli is missing.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dporobic/projects/testApp/build
[ 25%] Automatic moc for target testApp
[ 25%] Built target testApp_automoc
Scanning dependencies of target testApp
[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
[ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
[100%] Linking CXX executable testApp
CMakeFiles/testApp.dir/main.cpp.o: In function `main':
main.cpp:(.text+0x8e): undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
make[2]: *** [testApp] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all' failed
make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Any idea how I could/should troubleshoot such issue?

Thanks in advance!

Regards,
Damir


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

From mingw.android at gmail.com  Wed Aug 15 04:57:07 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Wed, 15 Aug 2018 09:57:07 +0100
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
 <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
 <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>
 <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>
Message-ID: <CAOYw7ds6s4UNng98Nk05URbDGB4URBgJkdmi2-fsY0HJj9TnWw@mail.gmail.com>

Docker is unnecessary overhead here and irrelevant to the question of which
compilers to use when building conda packages (use ours or risk binary
incompatibility with the rest of the ecosystems, please do not attempt to
use e.g. CentOS6 system compilers to compile modern software either!). Docker
doesn't come with modern compilers patched to support things like c++17 on
CentOS6, they are also slow and to not mitigate against Spectre.

Our compilation story is very good. We use fully isolated pdeudo cross
compilers that both target and run on CentOS6 in Linux and our own builds
of clang on macOS. We repackage CentOS6 rpms into the compiler sysroot for
the few packages that link to system libs.

I like and use for docker but conda has its own story here and docker and
compiler technology are orthogonal in this regard. To t, I still use our
computers on docker.

I honestly believe the isolation fans sometimes go far to far though and
will accept a lot of unnecessary complication and overhead chasing this
goal. Sufficient isolation is possible in other ways.

For testing the packages though (on Linux targets) I love using docker. I
can make sure our conda packages work on all the OSes we support.

You can if you want use our compilers in docker but it's pretty pointless
(and routing conda package building thorough something like docker is a
requirement the community, conda forge in particular does not need).

I dream of a day when docker is seen as one great tool with lots of useful
applications instead of the solution to everything but I don't see it
coming anytime soon.

On Aug 15, 2018 9:29 AM, "Eric Noulard" <eric.noulard at gmail.com> wrote:



Le mar. 14 ao?t 2018 ? 20:38, Sebasti?n Mancilla <smancill at jlab.org> a
?crit :

> I wanted to try Conda for normal day-to-day C++ development, while having
> all the dependencies isolated from other projects and the base system.
>
> - Change the sources
> - Build
> - Run the tests
> - Repeat
>

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology
like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better
isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like
as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda
packaged software:
https://github.com/BioContainers/mulled
I have no experience with that whatsoever, I usually craft my own
dockerfile and work with that.

If your goal includes the distrubution of your software as conda package
may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of
cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/53eb3734/attachment-0001.html>

From eric.noulard at gmail.com  Wed Aug 15 05:50:29 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 15 Aug 2018 11:50:29 +0200
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAOYw7ds6s4UNng98Nk05URbDGB4URBgJkdmi2-fsY0HJj9TnWw@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
 <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
 <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>
 <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>
 <CAOYw7ds6s4UNng98Nk05URbDGB4URBgJkdmi2-fsY0HJj9TnWw@mail.gmail.com>
Message-ID: <CAPASGLoJVYY3X5kCf7wej7Wy+WQP7iC23itcByoi7gCEE4TnuQ@mail.gmail.com>

Le mer. 15 ao?t 2018 ? 10:57, Ray Donnelly <mingw.android at gmail.com> a
?crit :

> Docker is unnecessary overhead here and irrelevant to the question of
> which compilers to use when building conda packages (use ours or risk
> binary incompatibility with the rest of the ecosystems, please do not
> attempt to use e.g. CentOS6 system compilers to compile modern software
> either!). Docker doesn't come with modern compilers patched to support
> things like c++17 on CentOS6, they are also slow and to not mitigate
> against Spectre.
>

Hi Ray,

Don't get me wrong I certainly don't want to generate flamewar against the
benefits conda gives to many users.
I routinely use custom-compiled compilers in native environment (without
docker nor conda though) and I did never have any issue while compiling
things with CMake and those custom compilers.


> Our compilation story is very good.
>

Again I don't doubt that, and please accept my apologies if my previous
words may have been understood otherwise.


> For testing the packages though (on Linux targets) I love using docker. I
> can make sure our conda packages work on all the OSes we support.
>

Agreed too, use the right tool for the right purpose.


> You can if you want use our compilers in docker but it's pretty pointless
> (and routing conda package building thorough something like docker is a
> requirement the community, conda forge in particular does not need).
>

I don't want that I was asking question about Sebastian needs and certainly
not questioning the value of conda and in particular the conda compiler
work you did.
I know too well that having a "fully controlled compiler version" is
essential when you want to support a wide range of platforms [even various
linux distribution], precisely because you want to ensure that you can "at
least" have say C++17 on all your supported platform/distros, or common
runtime or homogeneous OpenMP support etc...


>
> I dream of a day when docker is seen as one great tool with lots of useful
> applications instead of the solution to everything but I don't see it
> coming anytime soon.
>

I really don't think docker is the solution to everything.
Again I'm sorry if my previous statement may have been understood otherwise.

Having conda/conda compiler/conda build work seamlessly working with CMake
is valuable and I'm sure you'll find the proper solution for that along
with Kitware
as already referred issue and PR indicates.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/090b81d0/attachment.html>

From eric.noulard at gmail.com  Wed Aug 15 06:18:12 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 15 Aug 2018 12:18:12 +0200
Subject: [CMake] Problem with creating shared library
In-Reply-To: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <CAPASGLqbpebOqycCGwjeZPRSNKSyAST2PAA8Navu=CJBQ_n=sQ@mail.gmail.com>

Le mer. 15 ao?t 2018 ? 10:32, Damir Porobic <damir_porobic at live.com> a
?crit :

> Hi Folks,
>
>
> I'm trying to write a shared library and run into an issue where I can't
> find any clues to where the problem is.
>
> I have a project with following structure:
>
>
> src/
>
>     dir1/
>
>         file1.h
>
>         file1.cpp
>
>     dir2/
>
>         file2.h
>         file2.cpp
>
>
>
> Now I have this CMakeList:
>
> cmake_minimum_required(VERSION 3.5)
>
> project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)
>
> ...
>
>
> add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
> target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> target_include_directories(${PROJECT_NAME} PUBLIC
> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES VERSION
> ${PROJECT_VERSION} SOVERSION 1)
>
> set(kimageannotator_CONFIG ${PROJECT_NAME}Config)
>
> install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
>         ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
> install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})
>
> install(EXPORT ${kimageannotator_CONFIG} DESTINATION
> share/${kimageannotator_CONFIG}/cmake)
>
> export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)
>
>
> In another test project, I add the library like this:
> ...
> find_package(kImageAnnotator REQUIRED)
>
> add_executable(testApp main.cpp)
> target_link_libraries(testApp Qt5::Widgets kImageAnnotator)
>
>
> Now when I try to build my test project, I get this:
>
> dporobic at linux ~/projects/testApp/build
> $ cmake .. && make
> -- Could not set up the appstream test. appstreamcli is missing.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/dporobic/projects/testApp/build
> [ 25%] Automatic moc for target testApp
> [ 25%] Built target testApp_automoc
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
> [ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
> [100%] Linking CXX executable testApp
> CMakeFiles/testApp.dir/main.cpp.o: In function `main':
> main.cpp:(.text+0x8e): undefined reference to
> `KImageAnnotator::KImageAnnotator(QPixmap const&)'
> collect2: error: ld returned 1 exit status
> CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
> make[2]: *** [testApp] Error 1
> CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all'
> failed
> make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
> Makefile:94: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Any idea how I could/should troubleshoot such issue?
>

Try to compile in verbose mode

make VERBOSE=1

and have a look at the culprit link line.
You should see the reference to your previously built shared lib.

Check whether this lib is where it should be (may be you didn't install it?)

then check which kImageAnnotatorConfig.cmake file is used by the testApp
project in order to see if any
[wrong and not up to date] test & trial version of this file is lying
around.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/0818259b/attachment.html>

From mingw.android at gmail.com  Wed Aug 15 06:44:35 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Wed, 15 Aug 2018 11:44:35 +0100
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
Message-ID: <CAOYw7duteAhJLgf=p1ZvCpAKxrOD4ZbBvfmXxozaSLc8r5kibA@mail.gmail.com>

Hi Sebasti?n,

Without having time to properly go through this, I feel I should
correct some technical inaccuracies, but *all* of your issues can be
sidestepped by using conda-build. Installation and RPATHs are always
very tricky for projects to get right so we side step any issues here
by running post-build fixups on these things. We ensure RPATHs have
the opportunity to add our own, uniquify them (I think!), and make
them fully relative on macOS and Linux.

WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
activation script *when run under conda-build*. If you want to fake
that so you get the exact same flags that are used to compile our
packages do: CONDA_BUILD=1 conda activate envname. If you don't set
CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
-L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.

If you want to use our compilers in their completely 'raw' form (of
course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
helpers for interfacing the raw compilers with conda-build (and
setting good default compilation flags for security and performance
reasons).

You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
this ever outside of development workflows. FWIW, we run into lots of
trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
utterly convinced that DT_RUNPATH is a huge mistake. We actually
consider detection of DT_RUNPATH in any of our DSOs or exes an error
condition and only allow DT_RPATH. We just had so many bugs due to the
wrong libs being used by end users due to this, for example there is
no way a Qt application linked against our Qt libs is going to be
happy with some random system Qt library that's been interposed.

For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
want to target). These old SDKs can be gotten from old Xcode builds
and also on github. Unfortunately the compilers are not compatible
with the new .tbd file format used in newer SDKs and by the newest
Apple system linker and the source to enable that has not been
released yet (there have been no new source drops for Apple's ld64 in
a while).

But please, just use conda-build! While we try to keep them working in
as many situations as we can, these tools are primarily focussed
around conda-build and the technical decisions we make with respect to
them will be from that perspective.

Hope this helps some?

 Fri, Aug 10, 2018 at 10:48 PM, Sebasti?n Mancilla <smancill at jlab.org> wrote:
> I am trying to use Conda as a package manager for isolated C++ development
> environments. But unfortunately, when using CMake with the Anaconda-provided
> compilers [1] (which are used to compile the binary packages in the Anaconda
> repositories), things do not work as expected.
>
> I have a small test case available here [2], with an executable calling a
> shared library and a third-party dependency installed with Conda.
>
> [1]:
> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>
> --------------------------------------------------
>
> First, when using the system compiler, all works fine (but I am not sure of
> the
> binary compatibility with the Conda packages, that's why I want to use the
> Anaconda compilers):
>
>     # create the environment and install XercesC
>     $ conda create -n test-system xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
>     ...
>     The following NEW packages will be INSTALLED:
>
>     icu:       58.2-h4b95b61_1
>     libcxx:    4.0.1-h579ed51_0
>     libcxxabi: 4.0.1-hebd6815_0
>     xerces-c:  3.2.1-h44e365a_0
>     ...
>
>     # activate the environment
>     $ conda activate test-system
>
>     $ mkdir build-osx-system
>     $ cd build-osx-system
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>     -- Check for working CXX compiler: /usr/bin/c++
>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>     /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>     ...
>
> The build directory (~/src/conda-test/build-osx-system) and the conda
> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
> are correctly added to the RPATH in the build tree by the link command:
>
>     $ ./bar
>     Hello, world!
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>             cmd LC_RPATH
>         cmdsize 56
>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>     --
>             cmd LC_RPATH
>         cmdsize 80
>             path
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>
> If I install the binary, it fails because I haven't configured CMake to set
> the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>
>     $ bar
>     dyld: Library not loaded: @rpath/libfoo.dylib
>       Referenced from:
> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>       Reason: image not found
>     [1]    84611 abort      bar
>
>     $ otool -L $CONDA_PREFIX/bin/bar
>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>     # empty
>
>     # deactivate the environment to start again
>     $ conda deactivate
>
> The same can be observed on Linux. Everything works as it should.
>
> --------------------------------------------------
>
> If I try to use Anaconda compilers on macOS, the build RPATH is not set
> properly anymore:
>
>     # create the environment and install the Anaconda compiler for macOS,
> and XercesC
>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         cctools:        895-h7512d6f_0
>         clang:          4.0.1-h662ec87_0
>         clang_osx-64:   4.0.1-h1ce6c1d_11
>         clangxx:        4.0.1-hc9b4283_0
>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>         compiler-rt:    4.0.1-h5487866_0
>         icu:            58.2-h4b95b61_1
>         ld64:           274.2-h7c2db76_0
>         libcxx:         4.0.1-h579ed51_0
>         libcxxabi:      4.0.1-hebd6815_0
>         llvm:           4.0.1-hc748206_0
>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>         xerces-c:       3.2.1-h44e365a_0
>     ...
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-osx-conda
>     $ cd build-osx-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is Clang 4.0.1
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> -fstack-protector-strong -O2 -pipe -stdlib=libc++
> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>     ...
>
> You can see that the environment lib path is not added to the RPATH by the
> link command,
> which in turns result in the executable not running from the build tree
> anymore:
>
>     $ ./bar
>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>       Reason: image not found
>     [1]    89350 abort      ./bar
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>           cmd LC_RPATH
>       cmdsize 56
>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> If I try the Anaconda compilers on Linux, there are strange results too:
>
>     # create the environment and install the Anaconda compiler for Linux,
> and XercesC
>     $ conda create -n test-conda gxx_linux-64 xerces-c
>     ...
>     environment location: /home/vagrant/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         binutils_impl_linux-64: 2.28.1-had2808c_3
>         binutils_linux-64:      7.2.0-had2808c_27
>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>         gcc_linux-64:           7.2.0-h550dcbe_27
>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>         gxx_linux-64:           7.2.0-h550dcbe_27
>         icu:                    58.2-h9c2bf20_1
>         libgcc-ng:              7.2.0-hdf63c60_3
>         libstdcxx-ng:           7.2.0-hdf63c60_3
>         xerces-c:               3.2.1-hac72e42_0
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-linux-conda
>     $ cd build-linux-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is GNU 7.2.0
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -- works
>     ...
>     -- Found XercesC:
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
> "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /vagrant/conda-test/build-linux-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>     ...
>
> You can see that the environment lib path is added to the RPATH by the link
> command (unlike macOS):
>
>     $ ./bar
>     Hello World!
>
> But when inspecting the dependencies, the environment lib path appears
> twice:
>
>     $ readelf -d ./bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>     ...
>
> Which is wrong. Now the build tree binary will pick first any old version of
> the foo library installed in the environment instead of the version in the
> build tree.
>
> It seems that the Anaconda toolchain is setting the environment lib path
> into
> the RPATH by its own. It is also set when installing the binaries, even when
> CMake is not configured to set the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>     -- Set runtime path of
> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>
>     $ bar
>     Hello World!
>
>     $ readelf -d $CONDA_PREFIX/bin/bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib]
>     ...
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> TL;DR I cannot get CMake and the Anaconda compilers and packages working
> correctly.
>
> - On macOS, the Conda environment library path is not added to the build
> RPATH.
> - On Linux, the Conda environment library path is always added to the RPATH
>   (in both build and install) independently of CMake.
>
> Any advice or workarounds?
>
> --
> Sebastian Mancilla
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>

From mingw.android at gmail.com  Wed Aug 15 06:45:49 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Wed, 15 Aug 2018 11:45:49 +0100
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAOYw7duteAhJLgf=p1ZvCpAKxrOD4ZbBvfmXxozaSLc8r5kibA@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CAOYw7duteAhJLgf=p1ZvCpAKxrOD4ZbBvfmXxozaSLc8r5kibA@mail.gmail.com>
Message-ID: <CAOYw7duD186sWjSpS81M9t4O-mgzLr9qK23NyYv1B8SH2-n0HA@mail.gmail.com>

Our compiler activation scripts (highlighting the bit of most interest
to you I hope) are here:
https://github.com/AnacondaRecipes/aggregate/blob/master/ctng-compilers-activation-feedstock/recipe/activate-gcc.sh#L84-L101

On Wed, Aug 15, 2018 at 11:44 AM, Ray Donnelly <mingw.android at gmail.com> wrote:
> Hi Sebasti?n,
>
> Without having time to properly go through this, I feel I should
> correct some technical inaccuracies, but *all* of your issues can be
> sidestepped by using conda-build. Installation and RPATHs are always
> very tricky for projects to get right so we side step any issues here
> by running post-build fixups on these things. We ensure RPATHs have
> the opportunity to add our own, uniquify them (I think!), and make
> them fully relative on macOS and Linux.
>
> WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
> activation script *when run under conda-build*. If you want to fake
> that so you get the exact same flags that are used to compile our
> packages do: CONDA_BUILD=1 conda activate envname. If you don't set
> CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
> -L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.
>
> If you want to use our compilers in their completely 'raw' form (of
> course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
> e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
> helpers for interfacing the raw compilers with conda-build (and
> setting good default compilation flags for security and performance
> reasons).
>
> You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
> this ever outside of development workflows. FWIW, we run into lots of
> trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
> LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
> utterly convinced that DT_RUNPATH is a huge mistake. We actually
> consider detection of DT_RUNPATH in any of our DSOs or exes an error
> condition and only allow DT_RPATH. We just had so many bugs due to the
> wrong libs being used by end users due to this, for example there is
> no way a Qt application linked against our Qt libs is going to be
> happy with some random system Qt library that's been interposed.
>
> For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
> macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
> want to target). These old SDKs can be gotten from old Xcode builds
> and also on github. Unfortunately the compilers are not compatible
> with the new .tbd file format used in newer SDKs and by the newest
> Apple system linker and the source to enable that has not been
> released yet (there have been no new source drops for Apple's ld64 in
> a while).
>
> But please, just use conda-build! While we try to keep them working in
> as many situations as we can, these tools are primarily focussed
> around conda-build and the technical decisions we make with respect to
> them will be from that perspective.
>
> Hope this helps some?
>
>  Fri, Aug 10, 2018 at 10:48 PM, Sebasti?n Mancilla <smancill at jlab.org> wrote:
>> I am trying to use Conda as a package manager for isolated C++ development
>> environments. But unfortunately, when using CMake with the Anaconda-provided
>> compilers [1] (which are used to compile the binary packages in the Anaconda
>> repositories), things do not work as expected.
>>
>> I have a small test case available here [2], with an executable calling a
>> shared library and a third-party dependency installed with Conda.
>>
>> [1]:
>> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>
>> --------------------------------------------------
>>
>> First, when using the system compiler, all works fine (but I am not sure of
>> the
>> binary compatibility with the Conda packages, that's why I want to use the
>> Anaconda compilers):
>>
>>     # create the environment and install XercesC
>>     $ conda create -n test-system xerces-c
>>     ...
>>     environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-system
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>     icu:       58.2-h4b95b61_1
>>     libcxx:    4.0.1-h579ed51_0
>>     libcxxabi: 4.0.1-hebd6815_0
>>     xerces-c:  3.2.1-h44e365a_0
>>     ...
>>
>>     # activate the environment
>>     $ conda activate test-system
>>
>>     $ mkdir build-osx-system
>>     $ cd build-osx-system
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>     -- Check for working CXX compiler: /usr/bin/c++
>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>     ...
>>     -- Found XercesC:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>> (found version "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /Users/smancill/src/conda-test/build-osx-system
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>     /usr/bin/c++   -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
>> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
>> libfoo.dylib
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>     ...
>>
>> The build directory (~/src/conda-test/build-osx-system) and the conda
>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>> are correctly added to the RPATH in the build tree by the link command:
>>
>>     $ ./bar
>>     Hello, world!
>>
>>     $ otool -L ./bar
>>     ./bar:
>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> version 400.9.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>             cmd LC_RPATH
>>         cmdsize 56
>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>     --
>>             cmd LC_RPATH
>>         cmdsize 80
>>             path
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>
>> If I install the binary, it fails because I haven't configured CMake to set
>> the install RPATH:
>>
>>     $ make install
>>     ...
>>     Install the project...
>>     -- Install configuration: ""
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>
>>     $ bar
>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>       Referenced from:
>> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>       Reason: image not found
>>     [1]    84611 abort      bar
>>
>>     $ otool -L $CONDA_PREFIX/bin/bar
>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> version 400.9.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>     # empty
>>
>>     # deactivate the environment to start again
>>     $ conda deactivate
>>
>> The same can be observed on Linux. Everything works as it should.
>>
>> --------------------------------------------------
>>
>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>> properly anymore:
>>
>>     # create the environment and install the Anaconda compiler for macOS,
>> and XercesC
>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>     ...
>>     environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>         cctools:        895-h7512d6f_0
>>         clang:          4.0.1-h662ec87_0
>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>         clangxx:        4.0.1-hc9b4283_0
>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>         compiler-rt:    4.0.1-h5487866_0
>>         icu:            58.2-h4b95b61_1
>>         ld64:           274.2-h7c2db76_0
>>         libcxx:         4.0.1-h579ed51_0
>>         libcxxabi:      4.0.1-hebd6815_0
>>         llvm:           4.0.1-hc748206_0
>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>         xerces-c:       3.2.1-h44e365a_0
>>     ...
>>
>>     # activate the environment (which sets the variables to use the Anaconda
>> compiler)
>>     $ conda activate test-conda
>>
>>     $ mkdir build-osx-conda
>>     $ cd build-osx-conda
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is Clang 4.0.1
>>     -- Check for working CXX compiler:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>     -- Check for working CXX compiler:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> -- works
>>     ...
>>     -- Found XercesC:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>> (found version "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /Users/smancill/src/conda-test/build-osx-conda
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
>> -fstack-protector-strong -O2 -pipe -stdlib=libc++
>> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
>> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>     ...
>>
>> You can see that the environment lib path is not added to the RPATH by the
>> link command,
>> which in turns result in the executable not running from the build tree
>> anymore:
>>
>>     $ ./bar
>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>       Reason: image not found
>>     [1]    89350 abort      ./bar
>>
>>     $ otool -L ./bar
>>     ./bar:
>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
>> 1.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>           cmd LC_RPATH
>>       cmdsize 56
>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>
>>     # deactivate the environment
>>     $ conda deactivate
>>
>> --------------------------------------------------
>>
>> If I try the Anaconda compilers on Linux, there are strange results too:
>>
>>     # create the environment and install the Anaconda compiler for Linux,
>> and XercesC
>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>     ...
>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>         binutils_linux-64:      7.2.0-had2808c_27
>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>         icu:                    58.2-h9c2bf20_1
>>         libgcc-ng:              7.2.0-hdf63c60_3
>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>         xerces-c:               3.2.1-hac72e42_0
>>
>>     # activate the environment (which sets the variables to use the Anaconda
>> compiler)
>>     $ conda activate test-conda
>>
>>     $ mkdir build-linux-conda
>>     $ cd build-linux-conda
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is GNU 7.2.0
>>     -- Check for working CXX compiler:
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>     -- Check for working CXX compiler:
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> -- works
>>     ...
>>     -- Found XercesC:
>> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
>> "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /vagrant/conda-test/build-linux-conda
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
>> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
>> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
>> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
>> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
>> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>     ...
>>
>> You can see that the environment lib path is added to the RPATH by the link
>> command (unlike macOS):
>>
>>     $ ./bar
>>     Hello World!
>>
>> But when inspecting the dependencies, the environment lib path appears
>> twice:
>>
>>     $ readelf -d ./bar
>>     ...
>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libxerces-c-3.2.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libstdc++.so.6]
>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>      0x000000000000000f (RPATH)              Library rpath:
>> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>     ...
>>
>> Which is wrong. Now the build tree binary will pick first any old version of
>> the foo library installed in the environment instead of the version in the
>> build tree.
>>
>> It seems that the Anaconda toolchain is setting the environment lib path
>> into
>> the RPATH by its own. It is also set when installing the binaries, even when
>> CMake is not configured to set the install RPATH:
>>
>>     $ make install
>>     ...
>>     Install the project...
>>     -- Install configuration: ""
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>     -- Set runtime path of
>> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>
>>     $ bar
>>     Hello World!
>>
>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>     ...
>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libxerces-c-3.2.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libstdc++.so.6]
>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>      0x000000000000000f (RPATH)              Library rpath:
>> [/home/vagrant/miniconda3/envs/test-conda/lib]
>>     ...
>>
>>     # deactivate the environment
>>     $ conda deactivate
>>
>> --------------------------------------------------
>>
>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>> correctly.
>>
>> - On macOS, the Conda environment library path is not added to the build
>> RPATH.
>> - On Linux, the Conda environment library path is always added to the RPATH
>>   (in both build and install) independently of CMake.
>>
>> Any advice or workarounds?
>>
>> --
>> Sebastian Mancilla
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>

From ian.james.cullen at gmail.com  Wed Aug 15 08:31:38 2018
From: ian.james.cullen at gmail.com (Ian Cullen)
Date: Wed, 15 Aug 2018 13:31:38 +0100
Subject: [CMake] Expected behaviour of #cmakedefine
Message-ID: <395a1a1e-730d-212e-227e-adb6c31756ea@gmail.com>

Hi,

I'm trying to create a header file containing version number details but 
am not sure if the following behaviour is expected or a bug.

Simplified example has 2 files

==> CMakeLists.txt <==
cmake_minimum_required(VERSION 3.11)
project (
 ? VersionTest
 ? VERSION 1.0.4
 ? )

configure_file (
 ? "${PROJECT_SOURCE_DIR}/config.h.in"
 ? "${PROJECT_BINARY_DIR}/config.h"
 ? @ONLY
 ? )

==> config.h.in <==
#cmakedefine VersionTest_VERSION_MAJOR @VersionTest_VERSION_MAJOR@
#cmakedefine VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
#define VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@


Running cmake creates the output file as required but it has the 
following contents

==> config.h <==
#define VersionTest_VERSION_MAJOR 1
/* #undef VersionTest_VERSION_MINOR */
#define VersionTest_VERSION_MINOR 0


Looking at the manual 
(https://cmake.org/cmake/help/v3.12/command/configure_file.html), this 
appears to be because the number '0' is considered false by the if() 
command, however '0' is valid within a version number, so perhaps should 
not be considered false in this context.

Is this a known issue? Is it recommended to use #define rather than 
#cmakedefine for these types of files?

Thanks


From calebwherry at gmail.com  Wed Aug 15 08:56:15 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Wed, 15 Aug 2018 08:56:15 -0400
Subject: [CMake] Expected behaviour of #cmakedefine
In-Reply-To: <395a1a1e-730d-212e-227e-adb6c31756ea@gmail.com>
References: <395a1a1e-730d-212e-227e-adb6c31756ea@gmail.com>
Message-ID: <CAJxY6XoXcKbQUbsgOMt=XkGA9f-Txo+3pz52PibE56oE2UXXDQ@mail.gmail.com>

I suppose it all depends on if there are situations where you don?t want
those variables set? To me, it doesn?t make sense to ever not have version
numbers set so I would use #define.

-Caleb

On Wed, Aug 15, 2018 at 8:32 AM Ian Cullen <ian.james.cullen at gmail.com>
wrote:

> Hi,
>
> I'm trying to create a header file containing version number details but
> am not sure if the following behaviour is expected or a bug.
>
> Simplified example has 2 files
>
> ==> CMakeLists.txt <==
> cmake_minimum_required(VERSION 3.11)
> project (
>    VersionTest
>    VERSION 1.0.4
>    )
>
> configure_file (
>    "${PROJECT_SOURCE_DIR}/config.h.in"
>    "${PROJECT_BINARY_DIR}/config.h"
>    @ONLY
>    )
>
> ==> config.h.in <==
> #cmakedefine VersionTest_VERSION_MAJOR @VersionTest_VERSION_MAJOR@
> #cmakedefine VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
> #define VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
>
>
> Running cmake creates the output file as required but it has the
> following contents
>
> ==> config.h <==
> #define VersionTest_VERSION_MAJOR 1
> /* #undef VersionTest_VERSION_MINOR */
> #define VersionTest_VERSION_MINOR 0
>
>
> Looking at the manual
> (https://cmake.org/cmake/help/v3.12/command/configure_file.html), this
> appears to be because the number '0' is considered false by the if()
> command, however '0' is valid within a version number, so perhaps should
> not be considered false in this context.
>
> Is this a known issue? Is it recommended to use #define rather than
> #cmakedefine for these types of files?
>
> Thanks
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/78a3043b/attachment-0001.html>

From smancill at jlab.org  Wed Aug 15 10:05:35 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Wed, 15 Aug 2018 11:05:35 -0300
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
 <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
 <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>
 <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>
Message-ID: <CAJPSwc00D7jBd1XQNNCV=1KFq5QzU=eEZ9a5uCHRA1yMKU2=wA@mail.gmail.com>

My 5c: Docker is just too annoying to work with if you are targeting users
to run your packages.

>From the point of view of the final user of your "binary distribution"
(some Docker image):

- You have to figure out / copy paste the proper docker command line to run
the container (mount volumes, open ports, set environment, etc)
- It runs on a virtual machine if you are not in Linux
- How to run some graphical application?
- In Linux if you need to write some output files in the mounted volumen,
they will have the wrong permissions, unless the image provides a fix for
it.
- What if you need some extra package? Now you have to create your own
image based on the distributed image.
- You are limited to the package versions available in the Linux
distribution in which the image is based

Now consider conda:

conda create -n myenv meta-package
conda activate myenv
# run all binaries natively, they are already on PATH, access your file
system, install extra packages, have all your command line tools and IDEs
at hand.

>From the point of view of doing development with Docker, my biggest gripe
is how to edit the code while running it in the container. Say I have Vim
in the host (or an IDE).
When editing the sources in the host, all dependencies and compilers are in
the container, so I lose linting and compilation errors and autocompletion.
I would also need to install again all my development tools in the
container (say tmux, ag, jq, fzf etc).

Trying to do development while inside a Conda environment is something I
think it should work, and I don't think conda-build is necessary until I am
ready to create a package.
Unfortunately I hit the issue of this thread.

I have had no issues creating packages with conda-build and CMake so far,
and I've packaged a few, including some Qt applications.

El mi?., 15 de ago. de 2018 a la(s) 05:29, Eric Noulard (
eric.noulard at gmail.com) escribi?:

>
>
> Le mar. 14 ao?t 2018 ? 20:38, Sebasti?n Mancilla <smancill at jlab.org> a
> ?crit :
>
>> I wanted to try Conda for normal day-to-day C++ development, while having
>> all the dependencies isolated from other projects and the base system.
>>
>> - Change the sources
>> - Build
>> - Run the tests
>> - Repeat
>>
>
> Hi Sebastian,
>
> Just curious on why you would prefer conda over "real" container
> technology like docker or rkt for the kind of usage you describe ?
> Do you ultimately want to distribute your software as conda packages?
>
> I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better
> isolation for the usage you describe.
> The side-effect being that inside your container cmake should behave like
> as expected.
> At least this is my own experience.
>
> Some people even try to automatize the container creation out of conda
> packaged software:
> https://github.com/BioContainers/mulled
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_BioContainers_mulled&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=JnhBTDKSV5WKFKq-JlZzEYG4bH3wOaTgi4q6IWG-UnQ&s=NRuZ8XLwEl8KxOeh-vu-2fNEO84SkWzS6ERdc2RhRak&e=>
> I have no experience with that whatsoever, I usually craft my own
> dockerfile and work with that.
>
> If your goal includes the distrubution of your software as conda package
> may be you can get in touch with people
> at conda-forge: https://conda-forge.org/#about
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__conda-2Dforge.org_-23about&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=JnhBTDKSV5WKFKq-JlZzEYG4bH3wOaTgi4q6IWG-UnQ&s=bGnXxli7E1vFPnu5D4px_yHm-fP7ll1zBy7vQ5XgbLU&e=>,
> I bet they build a lot of cmake-based projects in there and may
> have experienced same caveats with the conda compilers usage.
>
>
> --
> Eric
>


-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/b3307444/attachment.html>

From mingw.android at gmail.com  Wed Aug 15 10:19:03 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Wed, 15 Aug 2018 15:19:03 +0100
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAJPSwc00D7jBd1XQNNCV=1KFq5QzU=eEZ9a5uCHRA1yMKU2=wA@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CADFtqoonjjtD=LzdUfo=8EaoNeL9X-xUHtVS3DhNFuT+H1nKhQ@mail.gmail.com>
 <CADFtqorwsHmBta3F=UbELQHGZh9o4fULj3b3rTY2=jrx3rX9qg@mail.gmail.com>
 <CAJPSwc2Cm9Xp17M_pyAEFG70Wr1z0O8MAfrBmq4LUDePZ3q3Pw@mail.gmail.com>
 <CAOYw7dsj_H44942NENvNUiCtX__Lo_9iZavt251=pc_-_mAwqg@mail.gmail.com>
 <CAJPSwc0=N0+nvjeZxeHAcYD9UVfYccE3GWLOmecACo1SoLxOgw@mail.gmail.com>
 <CAPASGLqfNKF3CdnntFdM2eDEgMaQMR5OSRgeRmRqkZc2tj4qvg@mail.gmail.com>
 <CAJPSwc00D7jBd1XQNNCV=1KFq5QzU=eEZ9a5uCHRA1yMKU2=wA@mail.gmail.com>
Message-ID: <CAOYw7dvhOjN_1Li5PWGi_E1nd0oMN04326m81XTgLurYhFpi6Q@mail.gmail.com>

On Wed, Aug 15, 2018, 3:05 PM Sebasti?n Mancilla <smancill at jlab.org> wrote:

> My 5c: Docker is just too annoying to work with if you are targeting users
> to run your packages.
>
> From the point of view of the final user of your "binary distribution"
> (some Docker image):
>
> - You have to figure out / copy paste the proper docker command line to
> run the container (mount volumes, open ports, set environment, etc)
> - It runs on a virtual machine if you are not in Linux
> - How to run some graphical application?
> - In Linux if you need to write some output files in the mounted volumen,
> they will have the wrong permissions, unless the image provides a fix for
> it.
> - What if you need some extra package? Now you have to create your own
> image based on the distributed image.
> - You are limited to the package versions available in the Linux
> distribution in which the image is based
>
> Now consider conda:
>
> conda create -n myenv meta-package
> conda activate myenv
> # run all binaries natively, they are already on PATH, access your file
> system, install extra packages, have all your command line tools and IDEs
> at hand.
>
> From the point of view of doing development with Docker, my biggest gripe
> is how to edit the code while running it in the container. Say I have Vim
> in the host (or an IDE).
> When editing the sources in the host, all dependencies and compilers are
> in the container, so I lose linting and compilation errors and
> autocompletion. I would also need to install again all my development tools
> in the container (say tmux, ag, jq, fzf etc).
>
> Trying to do development while inside a Conda environment is something I
> think it should work, and I don't think conda-build is necessary until I am
> ready to create a package.
> Unfortunately I hit the issue of this thread.
>

I already explained how to workaround the issues you saw. The compilers do
work in most normal situations, i use them extensively, even for linking to
rust software (macOS and Linux), the only caveat being that you should
instead so conda cdt packages on Linux for system library dependencies and
on macOS you need to get an old SDK.

>
> I have had no issues creating packages with conda-build and CMake so far,
> and I've packaged a few, including some Qt applications.
>
> El mi?., 15 de ago. de 2018 a la(s) 05:29, Eric Noulard (
> eric.noulard at gmail.com) escribi?:
>
>>
>>
>> Le mar. 14 ao?t 2018 ? 20:38, Sebasti?n Mancilla <smancill at jlab.org> a
>> ?crit :
>>
>>> I wanted to try Conda for normal day-to-day C++ development, while
>>> having all the dependencies isolated from other projects and the base
>>> system.
>>>
>>> - Change the sources
>>> - Build
>>> - Run the tests
>>> - Repeat
>>>
>>
>> Hi Sebastian,
>>
>> Just curious on why you would prefer conda over "real" container
>> technology like docker or rkt for the kind of usage you describe ?
>> Do you ultimately want to distribute your software as conda packages?
>>
>> I'm not proficient in conda but AFAIK docker (or rkt) offers
>> easier/better isolation for the usage you describe.
>> The side-effect being that inside your container cmake should behave like
>> as expected.
>> At least this is my own experience.
>>
>> Some people even try to automatize the container creation out of conda
>> packaged software:
>> https://github.com/BioContainers/mulled
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_BioContainers_mulled&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=JnhBTDKSV5WKFKq-JlZzEYG4bH3wOaTgi4q6IWG-UnQ&s=NRuZ8XLwEl8KxOeh-vu-2fNEO84SkWzS6ERdc2RhRak&e=>
>> I have no experience with that whatsoever, I usually craft my own
>> dockerfile and work with that.
>>
>> If your goal includes the distrubution of your software as conda package
>> may be you can get in touch with people
>> at conda-forge: https://conda-forge.org/#about
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__conda-2Dforge.org_-23about&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=JnhBTDKSV5WKFKq-JlZzEYG4bH3wOaTgi4q6IWG-UnQ&s=bGnXxli7E1vFPnu5D4px_yHm-fP7ll1zBy7vQ5XgbLU&e=>,
>> I bet they build a lot of cmake-based projects in there and may
>> have experienced same caveats with the conda compilers usage.
>>
>>
>> --
>> Eric
>>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valpara?so, Chile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/2c776399/attachment.html>

From smancill at jlab.org  Wed Aug 15 10:33:08 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Wed, 15 Aug 2018 11:33:08 -0300
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAOYw7duteAhJLgf=p1ZvCpAKxrOD4ZbBvfmXxozaSLc8r5kibA@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CAOYw7duteAhJLgf=p1ZvCpAKxrOD4ZbBvfmXxozaSLc8r5kibA@mail.gmail.com>
Message-ID: <CAJPSwc3ARL=9qV+gPCKqFUvYgBqCb1GKkbTkFdGuR8V5QF+0Bw@mail.gmail.com>

I cannot use conda-build if I am developing. Consider that I will be
editing the sources, compiling and running tests constantly. Going through
the conda-build process every time I need to check some changes would be
too much overhead. conda-build does a lot of things, it creates multiple
new environments, and the build.sh script may run some commands that I only
need when packaging.

Am I getting conda-build wrong? Is there some kind of development mode?

Also, the "tests" listed in the meta.yaml run with the installed version of
the package. I need to run the unit tests. But unit tests are discouraged
from being run in the build.sh script, to avoid extra CPU time in the CI
servers when building the package (per conda-forge docs).

It would be great if CMake would not filter $CONDA_PREFIX from the build
RPATH.

Well, I just doing this as experiment. I really think that using Conda for
C++ development has a lot of potential, although it doesn't seem to have a
lot of traction. Almost no clear results in Google, (but plenty of "Conda
for Python" ofc). It seems to me that the main purpose of C++ packages is
to be called from some Python/R code.

Just to clarify, I am pointing to distribute packages to people that would
not only run the binaries. They will write some hundred lines of the
ugliest C++ code that they will want to compile against the packages, and
run from their tree ./my-code and get results. They don't need to create a
package for that, they just want to compile and run the code. Also some of
them would want to develop new packages to be part of the meta
distribution, so that's why I am trying to figure out how to do C++
development within a Conda environment.

P.S. I checked gcc_impl_linux-64. I see I would need to set CC, CXX, LD by
hand. Also, no clang_impl_osx-64 package.

El mi?., 15 de ago. de 2018 a la(s) 07:44, Ray Donnelly (
mingw.android at gmail.com) escribi?:

> Hi Sebasti?n,
>
> Without having time to properly go through this, I feel I should
> correct some technical inaccuracies, but *all* of your issues can be
> sidestepped by using conda-build. Installation and RPATHs are always
> very tricky for projects to get right so we side step any issues here
> by running post-build fixups on these things. We ensure RPATHs have
> the opportunity to add our own, uniquify them (I think!), and make
> them fully relative on macOS and Linux.
>
> WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
> activation script *when run under conda-build*. If you want to fake
> that so you get the exact same flags that are used to compile our
> packages do: CONDA_BUILD=1 conda activate envname. If you don't set
> CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
> -L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.
>
> If you want to use our compilers in their completely 'raw' form (of
> course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
> e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
> helpers for interfacing the raw compilers with conda-build (and
> setting good default compilation flags for security and performance
> reasons).
>
> You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
> this ever outside of development workflows. FWIW, we run into lots of
> trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
> LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
> utterly convinced that DT_RUNPATH is a huge mistake. We actually
> consider detection of DT_RUNPATH in any of our DSOs or exes an error
> condition and only allow DT_RPATH. We just had so many bugs due to the
> wrong libs being used by end users due to this, for example there is
> no way a Qt application linked against our Qt libs is going to be
> happy with some random system Qt library that's been interposed.
>
> For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
> macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
> want to target). These old SDKs can be gotten from old Xcode builds
> and also on github. Unfortunately the compilers are not compatible
> with the new .tbd file format used in newer SDKs and by the newest
> Apple system linker and the source to enable that has not been
> released yet (there have been no new source drops for Apple's ld64 in
> a while).
>
> But please, just use conda-build! While we try to keep them working in
> as many situations as we can, these tools are primarily focussed
> around conda-build and the technical decisions we make with respect to
> them will be from that perspective.
>
> Hope this helps some?
>
>  Fri, Aug 10, 2018 at 10:48 PM, Sebasti?n Mancilla <smancill at jlab.org>
> wrote:
> > I am trying to use Conda as a package manager for isolated C++
> development
> > environments. But unfortunately, when using CMake with the
> Anaconda-provided
> > compilers [1] (which are used to compile the binary packages in the
> Anaconda
> > repositories), things do not work as expected.
> >
> > I have a small test case available here [2], with an executable calling a
> > shared library and a third-party dependency installed with Conda.
> >
> > [1]:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__conda.io_docs_user-2Dguide_tasks_build-2Dpackages_compiler-2Dtools.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=9ibJ6jRrwBMZIKheWzEMloZyY7BC5CuzHHPAKWlL37Q&e=
> > [2]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_smancill_b28ca07ac11fdf285b4d559545a1630b&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=kyMaMU1dzC_OC1KzWIrkZoymXxkiWxELh37yJ4vd028&e=
> >
> > --------------------------------------------------
> >
> > First, when using the system compiler, all works fine (but I am not sure
> of
> > the
> > binary compatibility with the Conda packages, that's why I want to use
> the
> > Anaconda compilers):
> >
> >     # create the environment and install XercesC
> >     $ conda create -n test-system xerces-c
> >     ...
> >     environment location:
> > /Users/smancill/.local/share/miniconda3/envs/test-system
> >     ...
> >     The following NEW packages will be INSTALLED:
> >
> >     icu:       58.2-h4b95b61_1
> >     libcxx:    4.0.1-h579ed51_0
> >     libcxxabi: 4.0.1-hebd6815_0
> >     xerces-c:  3.2.1-h44e365a_0
> >     ...
> >
> >     # activate the environment
> >     $ conda activate test-system
> >
> >     $ mkdir build-osx-system
> >     $ cd build-osx-system
> >     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> > -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> >     -- The CXX compiler identification is AppleClang 9.0.0.9000039
> >     -- Check for working CXX compiler: /usr/bin/c++
> >     -- Check for working CXX compiler: /usr/bin/c++ -- works
> >     ...
> >     -- Found XercesC:
> >
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> > (found version "3.2.1")
> >     -- Configuring done
> >     -- Generating done
> >     -- Build files have been written to:
> > /Users/smancill/src/conda-test/build-osx-system
> >
> >     $ make -j1 VERBOSE=1
> >     ...
> >     [100%] Linking CXX executable bar
> >     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> > --verbose=1
> >     /usr/bin/c++   -isysroot
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> > -mmacosx-version-min=10.12 -Wl,-search_paths_first
> > -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> > -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> > -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> > libfoo.dylib
> >
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> >     ...
> >
> > The build directory (~/src/conda-test/build-osx-system) and the conda
> > environment lib directory
> (~/.local/share/miniconda3/envs/test-system/lib)
> > are correctly added to the RPATH in the build tree by the link command:
> >
> >     $ ./bar
> >     Hello, world!
> >
> >     $ otool -L ./bar
> >     ./bar:
> >         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
> > 0.0.0)
> >         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
> current
> > version 0.0.0)
> >         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> > version 400.9.0)
> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> > version 1252.0.0)
> >
> >     $ otool -l ./bar | grep -A2 LC_RPATH
> >             cmd LC_RPATH
> >         cmdsize 56
> >             path /Users/smancill/src/conda-test/build-osx-system (offset
> 12)
> >     --
> >             cmd LC_RPATH
> >         cmdsize 80
> >             path
> > /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
> >
> > If I install the binary, it fails because I haven't configured CMake to
> set
> > the install RPATH:
> >
> >     $ make install
> >     ...
> >     Install the project...
> >     -- Install configuration: ""
> >     -- Installing:
> > /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
> >     -- Installing:
> > /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
> >     -- Installing:
> > /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
> >
> >     $ bar
> >     dyld: Library not loaded: @rpath/libfoo.dylib
> >       Referenced from:
> > /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
> >       Reason: image not found
> >     [1]    84611 abort      bar
> >
> >     $ otool -L $CONDA_PREFIX/bin/bar
> >     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
> >         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> > 0.0.0)
> >         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
> current
> > version 0.0.0)
> >         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> > version 400.9.0)
> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> > version 1252.0.0)
> >
> >     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
> >     # empty
> >
> >     # deactivate the environment to start again
> >     $ conda deactivate
> >
> > The same can be observed on Linux. Everything works as it should.
> >
> > --------------------------------------------------
> >
> > If I try to use Anaconda compilers on macOS, the build RPATH is not set
> > properly anymore:
> >
> >     # create the environment and install the Anaconda compiler for macOS,
> > and XercesC
> >     $ conda create -n test-conda clangxx_osx-64 xerces-c
> >     ...
> >     environment location:
> > /Users/smancill/.local/share/miniconda3/envs/test-conda
> >     ...
> >     The following NEW packages will be INSTALLED:
> >
> >         cctools:        895-h7512d6f_0
> >         clang:          4.0.1-h662ec87_0
> >         clang_osx-64:   4.0.1-h1ce6c1d_11
> >         clangxx:        4.0.1-hc9b4283_0
> >         clangxx_osx-64: 4.0.1-h22b1bf0_11
> >         compiler-rt:    4.0.1-h5487866_0
> >         icu:            58.2-h4b95b61_1
> >         ld64:           274.2-h7c2db76_0
> >         libcxx:         4.0.1-h579ed51_0
> >         libcxxabi:      4.0.1-hebd6815_0
> >         llvm:           4.0.1-hc748206_0
> >         llvm-lto-tapi:  4.0.1-h6701bc3_0
> >         xerces-c:       3.2.1-h44e365a_0
> >     ...
> >
> >     # activate the environment (which sets the variables to use the
> Anaconda
> > compiler)
> >     $ conda activate test-conda
> >
> >     $ mkdir build-osx-conda
> >     $ cd build-osx-conda
> >     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> > -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> >     -- The CXX compiler identification is Clang 4.0.1
> >     -- Check for working CXX compiler:
> >
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> >     -- Check for working CXX compiler:
> >
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> > -- works
> >     ...
> >     -- Found XercesC:
> >
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> > (found version "3.2.1")
> >     -- Configuring done
> >     -- Generating done
> >     -- Build files have been written to:
> > /Users/smancill/src/conda-test/build-osx-conda
> >
> >     $ make -j1 VERBOSE=1
> >     ...
> >     [100%] Linking CXX executable bar
> >     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> > --verbose=1
> >
> >
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> > -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> > -fstack-protector-strong -O2 -pipe -stdlib=libc++
> > -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> > -mmacosx-version-min=10.12 -Wl,-search_paths_first
> > -Wl,-headerpad_max_install_names -Wl,-pie
> -Wl,-headerpad_max_install_names
> > -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> > -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> >
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> >     ...
> >
> > You can see that the environment lib path is not added to the RPATH by
> the
> > link command,
> > which in turns result in the executable not running from the build tree
> > anymore:
> >
> >     $ ./bar
> >     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
> >       Referenced from:
> /Users/smancill/src/conda-test/build-osx-conda/./bar
> >       Reason: image not found
> >     [1]    89350 abort      ./bar
> >
> >     $ otool -L ./bar
> >     ./bar:
> >         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> > 0.0.0)
> >         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
> current
> > version 0.0.0)
> >         @rpath/libc++.1.dylib (compatibility version 1.0.0, current
> version
> > 1.0.0)
> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> > version 1252.0.0)
> >
> >     $ otool -l ./bar | grep -A2 LC_RPATH
> >           cmd LC_RPATH
> >       cmdsize 56
> >          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
> >
> >     # deactivate the environment
> >     $ conda deactivate
> >
> > --------------------------------------------------
> >
> > If I try the Anaconda compilers on Linux, there are strange results too:
> >
> >     # create the environment and install the Anaconda compiler for Linux,
> > and XercesC
> >     $ conda create -n test-conda gxx_linux-64 xerces-c
> >     ...
> >     environment location: /home/vagrant/miniconda3/envs/test-conda
> >     ...
> >     The following NEW packages will be INSTALLED:
> >
> >         binutils_impl_linux-64: 2.28.1-had2808c_3
> >         binutils_linux-64:      7.2.0-had2808c_27
> >         gcc_impl_linux-64:      7.2.0-habb00fd_3
> >         gcc_linux-64:           7.2.0-h550dcbe_27
> >         gxx_impl_linux-64:      7.2.0-hdf63c60_3
> >         gxx_linux-64:           7.2.0-h550dcbe_27
> >         icu:                    58.2-h9c2bf20_1
> >         libgcc-ng:              7.2.0-hdf63c60_3
> >         libstdcxx-ng:           7.2.0-hdf63c60_3
> >         xerces-c:               3.2.1-hac72e42_0
> >
> >     # activate the environment (which sets the variables to use the
> Anaconda
> > compiler)
> >     $ conda activate test-conda
> >
> >     $ mkdir build-linux-conda
> >     $ cd build-linux-conda
> >     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> > -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> >     -- The CXX compiler identification is GNU 7.2.0
> >     -- Check for working CXX compiler:
> >
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> >     -- Check for working CXX compiler:
> >
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> > -- works
> >     ...
> >     -- Found XercesC:
> > /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found
> version
> > "3.2.1")
> >     -- Configuring done
> >     -- Generating done
> >     -- Build files have been written to:
> > /vagrant/conda-test/build-linux-conda
> >
> >     $ make -j1 VERBOSE=1
> >     ...
> >     [100%] Linking CXX executable bar
> >     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> > --verbose=1
> >
> >
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> > -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> > -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt
> -O2
> > -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
> -Wl,-z,now
> > CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> > /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> >
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
> >     ...
> >
> > You can see that the environment lib path is added to the RPATH by the
> link
> > command (unlike macOS):
> >
> >     $ ./bar
> >     Hello World!
> >
> > But when inspecting the dependencies, the environment lib path appears
> > twice:
> >
> >     $ readelf -d ./bar
> >     ...
> >      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
> >      0x0000000000000001 (NEEDED)             Shared library:
> > [libxerces-c-3.2.so]
> >      0x0000000000000001 (NEEDED)             Shared library:
> > [libstdc++.so.6]
> >      0x0000000000000001 (NEEDED)             Shared library:
> [libgcc_s.so.1]
> >      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
> >      0x000000000000000f (RPATH)              Library rpath:
> >
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
> >     ...
> >
> > Which is wrong. Now the build tree binary will pick first any old
> version of
> > the foo library installed in the environment instead of the version in
> the
> > build tree.
> >
> > It seems that the Anaconda toolchain is setting the environment lib path
> > into
> > the RPATH by its own. It is also set when installing the binaries, even
> when
> > CMake is not configured to set the install RPATH:
> >
> >     $ make install
> >     ...
> >     Install the project...
> >     -- Install configuration: ""
> >     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
> >     -- Installing:
> /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
> >     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
> >     -- Set runtime path of
> > "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
> >
> >     $ bar
> >     Hello World!
> >
> >     $ readelf -d $CONDA_PREFIX/bin/bar
> >     ...
> >      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
> >      0x0000000000000001 (NEEDED)             Shared library:
> > [libxerces-c-3.2.so]
> >      0x0000000000000001 (NEEDED)             Shared library:
> > [libstdc++.so.6]
> >      0x0000000000000001 (NEEDED)             Shared library:
> [libgcc_s.so.1]
> >      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
> >      0x000000000000000f (RPATH)              Library rpath:
> > [/home/vagrant/miniconda3/envs/test-conda/lib]
> >     ...
> >
> >     # deactivate the environment
> >     $ conda deactivate
> >
> > --------------------------------------------------
> >
> > TL;DR I cannot get CMake and the Anaconda compilers and packages working
> > correctly.
> >
> > - On macOS, the Conda environment library path is not added to the build
> > RPATH.
> > - On Linux, the Conda environment library path is always added to the
> RPATH
> >   (in both build and install) independently of CMake.
> >
> > Any advice or workarounds?
> >
> > --
> > Sebastian Mancilla
> >
> > --
> >
> > 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=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=GdelxyoZgjgUDZpZLYDRX5TB7K8bnH7ivyB0EBiNAoQ&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_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=QbSbBtc-GMz--7tKjKNG-nRFY53D4mceuDjrWNci7Sc&e=
> > CMake Consulting:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=LhGhXtC3-JaFI20UkcWMEw8QZpYNTDT5e2vJhuKjan4&e=
> > CMake Training Courses:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=oou7JfZWiRu6hUMB0_vo_Bjb_DLWjsmePAz_1CrVzQA&e=
> >
> > Visit other Kitware open-source projects at
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=3MJhnhS7Ki2a8XfbvcYt0oMlt0ctGc1FnXvv4ZBD_mE&e=
> >
> > Follow this link to subscribe/unsubscribe:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=W0QwY-pUUOH_XmHdxssgWgGDWsF6xuqD7UvjH8ApONc&e=
> >
>


-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/f7495d6f/attachment-0001.html>

From msarahan at gmail.com  Wed Aug 15 10:41:02 2018
From: msarahan at gmail.com (Michael Sarahan)
Date: Wed, 15 Aug 2018 09:41:02 -0500
Subject: [CMake] Issues trying to use the Anaconda compiler tools with
 CMake
In-Reply-To: <CAJPSwc3ARL=9qV+gPCKqFUvYgBqCb1GKkbTkFdGuR8V5QF+0Bw@mail.gmail.com>
References: <CAJPSwc31+kroYiHNYW7Z8P=n1ccq3Jh=8MPOJzMPwVoT58tXfQ@mail.gmail.com>
 <CAOYw7duteAhJLgf=p1ZvCpAKxrOD4ZbBvfmXxozaSLc8r5kibA@mail.gmail.com>
 <CAJPSwc3ARL=9qV+gPCKqFUvYgBqCb1GKkbTkFdGuR8V5QF+0Bw@mail.gmail.com>
Message-ID: <CAB9hrOofcJEqfn_ZsdQY0BkJUrNs3E-GZy_UYW6pOOMK=MAw-A@mail.gmail.com>

conda-build maintainer here.  I agree that having conda/conda-build as a
provisioner for general-purpose build environments would be helpful.  I'm
afraid I don't understand what's missing or otherwise needs to change here,
though.  If you have concrete suggestions (and better, PRs) for how to make
conda, conda-build, our compilers, or cmake work better in this capacity,
we'd be happy to talk more with you on our issue tracker.

https://github.com/conda/conda-build

On Wed, Aug 15, 2018 at 9:33 AM Sebasti?n Mancilla <smancill at jlab.org>
wrote:

> I cannot use conda-build if I am developing. Consider that I will be
> editing the sources, compiling and running tests constantly. Going through
> the conda-build process every time I need to check some changes would be
> too much overhead. conda-build does a lot of things, it creates multiple
> new environments, and the build.sh script may run some commands that I only
> need when packaging.
>
> Am I getting conda-build wrong? Is there some kind of development mode?
>
> Also, the "tests" listed in the meta.yaml run with the installed version
> of the package. I need to run the unit tests. But unit tests are
> discouraged from being run in the build.sh script, to avoid extra CPU time
> in the CI servers when building the package (per conda-forge docs).
>
> It would be great if CMake would not filter $CONDA_PREFIX from the build
> RPATH.
>
> Well, I just doing this as experiment. I really think that using Conda for
> C++ development has a lot of potential, although it doesn't seem to have a
> lot of traction. Almost no clear results in Google, (but plenty of "Conda
> for Python" ofc). It seems to me that the main purpose of C++ packages is
> to be called from some Python/R code.
>
> Just to clarify, I am pointing to distribute packages to people that would
> not only run the binaries. They will write some hundred lines of the
> ugliest C++ code that they will want to compile against the packages, and
> run from their tree ./my-code and get results. They don't need to create a
> package for that, they just want to compile and run the code. Also some of
> them would want to develop new packages to be part of the meta
> distribution, so that's why I am trying to figure out how to do C++
> development within a Conda environment.
>
> P.S. I checked gcc_impl_linux-64. I see I would need to set CC, CXX, LD by
> hand. Also, no clang_impl_osx-64 package.
>
> El mi?., 15 de ago. de 2018 a la(s) 07:44, Ray Donnelly (
> mingw.android at gmail.com) escribi?:
>
>> Hi Sebasti?n,
>>
>> Without having time to properly go through this, I feel I should
>> correct some technical inaccuracies, but *all* of your issues can be
>> sidestepped by using conda-build. Installation and RPATHs are always
>> very tricky for projects to get right so we side step any issues here
>> by running post-build fixups on these things. We ensure RPATHs have
>> the opportunity to add our own, uniquify them (I think!), and make
>> them fully relative on macOS and Linux.
>>
>> WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
>> activation script *when run under conda-build*. If you want to fake
>> that so you get the exact same flags that are used to compile our
>> packages do: CONDA_BUILD=1 conda activate envname. If you don't set
>> CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
>> -L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.
>>
>> If you want to use our compilers in their completely 'raw' form (of
>> course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
>> e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
>> helpers for interfacing the raw compilers with conda-build (and
>> setting good default compilation flags for security and performance
>> reasons).
>>
>> You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
>> this ever outside of development workflows. FWIW, we run into lots of
>> trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
>> LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
>> utterly convinced that DT_RUNPATH is a huge mistake. We actually
>> consider detection of DT_RUNPATH in any of our DSOs or exes an error
>> condition and only allow DT_RPATH. We just had so many bugs due to the
>> wrong libs being used by end users due to this, for example there is
>> no way a Qt application linked against our Qt libs is going to be
>> happy with some random system Qt library that's been interposed.
>>
>> For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
>> macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
>> want to target). These old SDKs can be gotten from old Xcode builds
>> and also on github. Unfortunately the compilers are not compatible
>> with the new .tbd file format used in newer SDKs and by the newest
>> Apple system linker and the source to enable that has not been
>> released yet (there have been no new source drops for Apple's ld64 in
>> a while).
>>
>> But please, just use conda-build! While we try to keep them working in
>> as many situations as we can, these tools are primarily focussed
>> around conda-build and the technical decisions we make with respect to
>> them will be from that perspective.
>>
>> Hope this helps some?
>>
>>  Fri, Aug 10, 2018 at 10:48 PM, Sebasti?n Mancilla <smancill at jlab.org>
>> wrote:
>> > I am trying to use Conda as a package manager for isolated C++
>> development
>> > environments. But unfortunately, when using CMake with the
>> Anaconda-provided
>> > compilers [1] (which are used to compile the binary packages in the
>> Anaconda
>> > repositories), things do not work as expected.
>> >
>> > I have a small test case available here [2], with an executable calling
>> a
>> > shared library and a third-party dependency installed with Conda.
>> >
>> > [1]:
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__conda.io_docs_user-2Dguide_tasks_build-2Dpackages_compiler-2Dtools.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=9ibJ6jRrwBMZIKheWzEMloZyY7BC5CuzHHPAKWlL37Q&e=
>> > [2]:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_smancill_b28ca07ac11fdf285b4d559545a1630b&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=kyMaMU1dzC_OC1KzWIrkZoymXxkiWxELh37yJ4vd028&e=
>> >
>> > --------------------------------------------------
>> >
>> > First, when using the system compiler, all works fine (but I am not
>> sure of
>> > the
>> > binary compatibility with the Conda packages, that's why I want to use
>> the
>> > Anaconda compilers):
>> >
>> >     # create the environment and install XercesC
>> >     $ conda create -n test-system xerces-c
>> >     ...
>> >     environment location:
>> > /Users/smancill/.local/share/miniconda3/envs/test-system
>> >     ...
>> >     The following NEW packages will be INSTALLED:
>> >
>> >     icu:       58.2-h4b95b61_1
>> >     libcxx:    4.0.1-h579ed51_0
>> >     libcxxabi: 4.0.1-hebd6815_0
>> >     xerces-c:  3.2.1-h44e365a_0
>> >     ...
>> >
>> >     # activate the environment
>> >     $ conda activate test-system
>> >
>> >     $ mkdir build-osx-system
>> >     $ cd build-osx-system
>> >     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> > -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>> >     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>> >     -- Check for working CXX compiler: /usr/bin/c++
>> >     -- Check for working CXX compiler: /usr/bin/c++ -- works
>> >     ...
>> >     -- Found XercesC:
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>> > (found version "3.2.1")
>> >     -- Configuring done
>> >     -- Generating done
>> >     -- Build files have been written to:
>> > /Users/smancill/src/conda-test/build-osx-system
>> >
>> >     $ make -j1 VERBOSE=1
>> >     ...
>> >     [100%] Linking CXX executable bar
>> >     /usr/local/bin/cmake -E cmake_link_script
>> CMakeFiles/bar.dir/link.txt
>> > --verbose=1
>> >     /usr/bin/c++   -isysroot
>> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> > -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> > -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> > -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
>> > -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
>> > libfoo.dylib
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>> >     ...
>> >
>> > The build directory (~/src/conda-test/build-osx-system) and the conda
>> > environment lib directory
>> (~/.local/share/miniconda3/envs/test-system/lib)
>> > are correctly added to the RPATH in the build tree by the link command:
>> >
>> >     $ ./bar
>> >     Hello, world!
>> >
>> >     $ otool -L ./bar
>> >     ./bar:
>> >         @rpath/libfoo.dylib (compatibility version 1.0.0, current
>> version
>> > 0.0.0)
>> >         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
>> current
>> > version 0.0.0)
>> >         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> > version 400.9.0)
>> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> > version 1252.0.0)
>> >
>> >     $ otool -l ./bar | grep -A2 LC_RPATH
>> >             cmd LC_RPATH
>> >         cmdsize 56
>> >             path /Users/smancill/src/conda-test/build-osx-system
>> (offset 12)
>> >     --
>> >             cmd LC_RPATH
>> >         cmdsize 80
>> >             path
>> > /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>> >
>> > If I install the binary, it fails because I haven't configured CMake to
>> set
>> > the install RPATH:
>> >
>> >     $ make install
>> >     ...
>> >     Install the project...
>> >     -- Install configuration: ""
>> >     -- Installing:
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>> >     -- Installing:
>> > /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>> >     -- Installing:
>> > /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>> >
>> >     $ bar
>> >     dyld: Library not loaded: @rpath/libfoo.dylib
>> >       Referenced from:
>> > /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>> >       Reason: image not found
>> >     [1]    84611 abort      bar
>> >
>> >     $ otool -L $CONDA_PREFIX/bin/bar
>> >     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>> >         @rpath/libfoo.dylib (compatibility version 0.0.0, current
>> version
>> > 0.0.0)
>> >         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
>> current
>> > version 0.0.0)
>> >         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> > version 400.9.0)
>> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> > version 1252.0.0)
>> >
>> >     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>> >     # empty
>> >
>> >     # deactivate the environment to start again
>> >     $ conda deactivate
>> >
>> > The same can be observed on Linux. Everything works as it should.
>> >
>> > --------------------------------------------------
>> >
>> > If I try to use Anaconda compilers on macOS, the build RPATH is not set
>> > properly anymore:
>> >
>> >     # create the environment and install the Anaconda compiler for
>> macOS,
>> > and XercesC
>> >     $ conda create -n test-conda clangxx_osx-64 xerces-c
>> >     ...
>> >     environment location:
>> > /Users/smancill/.local/share/miniconda3/envs/test-conda
>> >     ...
>> >     The following NEW packages will be INSTALLED:
>> >
>> >         cctools:        895-h7512d6f_0
>> >         clang:          4.0.1-h662ec87_0
>> >         clang_osx-64:   4.0.1-h1ce6c1d_11
>> >         clangxx:        4.0.1-hc9b4283_0
>> >         clangxx_osx-64: 4.0.1-h22b1bf0_11
>> >         compiler-rt:    4.0.1-h5487866_0
>> >         icu:            58.2-h4b95b61_1
>> >         ld64:           274.2-h7c2db76_0
>> >         libcxx:         4.0.1-h579ed51_0
>> >         libcxxabi:      4.0.1-hebd6815_0
>> >         llvm:           4.0.1-hc748206_0
>> >         llvm-lto-tapi:  4.0.1-h6701bc3_0
>> >         xerces-c:       3.2.1-h44e365a_0
>> >     ...
>> >
>> >     # activate the environment (which sets the variables to use the
>> Anaconda
>> > compiler)
>> >     $ conda activate test-conda
>> >
>> >     $ mkdir build-osx-conda
>> >     $ cd build-osx-conda
>> >     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> > -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>> >     -- The CXX compiler identification is Clang 4.0.1
>> >     -- Check for working CXX compiler:
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> >     -- Check for working CXX compiler:
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> > -- works
>> >     ...
>> >     -- Found XercesC:
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>> > (found version "3.2.1")
>> >     -- Configuring done
>> >     -- Generating done
>> >     -- Build files have been written to:
>> > /Users/smancill/src/conda-test/build-osx-conda
>> >
>> >     $ make -j1 VERBOSE=1
>> >     ...
>> >     [100%] Linking CXX executable bar
>> >     /usr/local/bin/cmake -E cmake_link_script
>> CMakeFiles/bar.dir/link.txt
>> > --verbose=1
>> >
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> > -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
>> > -fstack-protector-strong -O2 -pipe -stdlib=libc++
>> > -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
>> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> > -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> > -Wl,-headerpad_max_install_names -Wl,-pie
>> -Wl,-headerpad_max_install_names
>> > -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> > -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
>> >
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>> >     ...
>> >
>> > You can see that the environment lib path is not added to the RPATH by
>> the
>> > link command,
>> > which in turns result in the executable not running from the build tree
>> > anymore:
>> >
>> >     $ ./bar
>> >     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>> >       Referenced from:
>> /Users/smancill/src/conda-test/build-osx-conda/./bar
>> >       Reason: image not found
>> >     [1]    89350 abort      ./bar
>> >
>> >     $ otool -L ./bar
>> >     ./bar:
>> >         @rpath/libfoo.dylib (compatibility version 0.0.0, current
>> version
>> > 0.0.0)
>> >         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0,
>> current
>> > version 0.0.0)
>> >         @rpath/libc++.1.dylib (compatibility version 1.0.0, current
>> version
>> > 1.0.0)
>> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> > version 1252.0.0)
>> >
>> >     $ otool -l ./bar | grep -A2 LC_RPATH
>> >           cmd LC_RPATH
>> >       cmdsize 56
>> >          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>> >
>> >     # deactivate the environment
>> >     $ conda deactivate
>> >
>> > --------------------------------------------------
>> >
>> > If I try the Anaconda compilers on Linux, there are strange results too:
>> >
>> >     # create the environment and install the Anaconda compiler for
>> Linux,
>> > and XercesC
>> >     $ conda create -n test-conda gxx_linux-64 xerces-c
>> >     ...
>> >     environment location: /home/vagrant/miniconda3/envs/test-conda
>> >     ...
>> >     The following NEW packages will be INSTALLED:
>> >
>> >         binutils_impl_linux-64: 2.28.1-had2808c_3
>> >         binutils_linux-64:      7.2.0-had2808c_27
>> >         gcc_impl_linux-64:      7.2.0-habb00fd_3
>> >         gcc_linux-64:           7.2.0-h550dcbe_27
>> >         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>> >         gxx_linux-64:           7.2.0-h550dcbe_27
>> >         icu:                    58.2-h9c2bf20_1
>> >         libgcc-ng:              7.2.0-hdf63c60_3
>> >         libstdcxx-ng:           7.2.0-hdf63c60_3
>> >         xerces-c:               3.2.1-hac72e42_0
>> >
>> >     # activate the environment (which sets the variables to use the
>> Anaconda
>> > compiler)
>> >     $ conda activate test-conda
>> >
>> >     $ mkdir build-linux-conda
>> >     $ cd build-linux-conda
>> >     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> > -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>> >     -- The CXX compiler identification is GNU 7.2.0
>> >     -- Check for working CXX compiler:
>> >
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> >     -- Check for working CXX compiler:
>> >
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> > -- works
>> >     ...
>> >     -- Found XercesC:
>> > /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found
>> version
>> > "3.2.1")
>> >     -- Configuring done
>> >     -- Generating done
>> >     -- Build files have been written to:
>> > /vagrant/conda-test/build-linux-conda
>> >
>> >     $ make -j1 VERBOSE=1
>> >     ...
>> >     [100%] Linking CXX executable bar
>> >     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> > --verbose=1
>> >
>> >
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> > -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
>> > -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt
>> -O2
>> > -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
>> -Wl,-z,now
>> > CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
>> > /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
>> >
>> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>> >     ...
>> >
>> > You can see that the environment lib path is added to the RPATH by the
>> link
>> > command (unlike macOS):
>> >
>> >     $ ./bar
>> >     Hello World!
>> >
>> > But when inspecting the dependencies, the environment lib path appears
>> > twice:
>> >
>> >     $ readelf -d ./bar
>> >     ...
>> >      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>> >      0x0000000000000001 (NEEDED)             Shared library:
>> > [libxerces-c-3.2.so]
>> >      0x0000000000000001 (NEEDED)             Shared library:
>> > [libstdc++.so.6]
>> >      0x0000000000000001 (NEEDED)             Shared library:
>> [libgcc_s.so.1]
>> >      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>> >      0x000000000000000f (RPATH)              Library rpath:
>> >
>> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>> >     ...
>> >
>> > Which is wrong. Now the build tree binary will pick first any old
>> version of
>> > the foo library installed in the environment instead of the version in
>> the
>> > build tree.
>> >
>> > It seems that the Anaconda toolchain is setting the environment lib path
>> > into
>> > the RPATH by its own. It is also set when installing the binaries, even
>> when
>> > CMake is not configured to set the install RPATH:
>> >
>> >     $ make install
>> >     ...
>> >     Install the project...
>> >     -- Install configuration: ""
>> >     -- Installing:
>> /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>> >     -- Installing:
>> /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>> >     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>> >     -- Set runtime path of
>> > "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>> >
>> >     $ bar
>> >     Hello World!
>> >
>> >     $ readelf -d $CONDA_PREFIX/bin/bar
>> >     ...
>> >      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>> >      0x0000000000000001 (NEEDED)             Shared library:
>> > [libxerces-c-3.2.so]
>> >      0x0000000000000001 (NEEDED)             Shared library:
>> > [libstdc++.so.6]
>> >      0x0000000000000001 (NEEDED)             Shared library:
>> [libgcc_s.so.1]
>> >      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>> >      0x000000000000000f (RPATH)              Library rpath:
>> > [/home/vagrant/miniconda3/envs/test-conda/lib]
>> >     ...
>> >
>> >     # deactivate the environment
>> >     $ conda deactivate
>> >
>> > --------------------------------------------------
>> >
>> > TL;DR I cannot get CMake and the Anaconda compilers and packages working
>> > correctly.
>> >
>> > - On macOS, the Conda environment library path is not added to the build
>> > RPATH.
>> > - On Linux, the Conda environment library path is always added to the
>> RPATH
>> >   (in both build and install) independently of CMake.
>> >
>> > Any advice or workarounds?
>> >
>> > --
>> > Sebastian Mancilla
>> >
>> > --
>> >
>> > 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=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=GdelxyoZgjgUDZpZLYDRX5TB7K8bnH7ivyB0EBiNAoQ&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_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=QbSbBtc-GMz--7tKjKNG-nRFY53D4mceuDjrWNci7Sc&e=
>> > CMake Consulting:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=LhGhXtC3-JaFI20UkcWMEw8QZpYNTDT5e2vJhuKjan4&e=
>> > CMake Training Courses:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=oou7JfZWiRu6hUMB0_vo_Bjb_DLWjsmePAz_1CrVzQA&e=
>> >
>> > Visit other Kitware open-source projects at
>> >
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=3MJhnhS7Ki2a8XfbvcYt0oMlt0ctGc1FnXvv4ZBD_mE&e=
>> >
>> > Follow this link to subscribe/unsubscribe:
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=W0QwY-pUUOH_XmHdxssgWgGDWsF6xuqD7UvjH8ApONc&e=
>> >
>>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valpara?so, Chile
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/6dd78bbc/attachment-0001.html>

From robert.maynard at kitware.com  Wed Aug 15 10:48:24 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 15 Aug 2018 10:48:24 -0400
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
Message-ID: <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>

> cannot find CUDA likely as CUDA was not installed after 2017

The CUDA language support requires the CUDA MSBUILD extensions, which
will require you to run the CUDA installer again ( it only installs
the msbuild extensions for versions that are currently installed ).

>  I would like it to load 2013 after being told to generate Visual Studio 2013 project files.

 As Hendrik stated CMake defers to the windows shell/explorer for
opening solution files.
On Tue, Aug 14, 2018 at 7:27 PM Brian Davis <bitminer at gmail.com> wrote:
>
>
> It also cannot find CUDA likely as CUDA was not installed after 2017.  I would like it to load 2013 after being told to generate Visual Studio 2013 project files.  Is this difficult to ask fo Kitware?  I am sure there are certainly some shenanigans like path or VS2017 hooking calls to 2013 tools or the like all of which I am sure make sens to a cubite in the bowels of the MS machine.  VS loaded 2017 and vs 2013  proj files then promptly had problems searching files, compiling stale targets and the like.  So while VS2017 make "hook" 2013 tools it certainly can't do any thing useful with them IME.  Is there a Meta buld tool (goop generator) that will build goop for a target goop reader then call said target goop reader (of correct specified version) to read goop and compile my code?  sigh.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From roman.wueger at gmx.at  Wed Aug 15 11:01:32 2018
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Wed, 15 Aug 2018 17:01:32 +0200
Subject: [CMake] Android project with CMake and Visual Studio and
 without Nsight Tegra
In-Reply-To: <F29AC789-2AFE-4B76-923F-A64909F86DE9@gmx.at>
References: <F29AC789-2AFE-4B76-923F-A64909F86DE9@gmx.at>
Message-ID: <687DA6A7-7A6A-4F21-953E-2BA8E70F2399@gmx.at>

Why isn?t it enough to install the SDK and NDK?

Regards
Roman

> Am 09.08.2018 um 09:02 schrieb Roman W?ger <roman.wueger at gmx.at>:
> 
> Hello,
> 
> is it somehow possible to build an Android project with CMake and Visual Studio without the Nsight Tegra Visual Studio Edition? Because the installation of NVIDIA Nsight Tegra hangs during configuring the Visual Studio 2017 in a Virtual Machine.
> 
> Thanks in advance
> 
> Best Regards
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake


From eric.noulard at gmail.com  Wed Aug 15 11:13:25 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 15 Aug 2018 17:13:25 +0200
Subject: [CMake] Fwd:  Problem with creating shared library
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLqbpebOqycCGwjeZPRSNKSyAST2PAA8Navu=CJBQ_n=sQ@mail.gmail.com>
 <AM0PR0202MB3411600110C0BCC21770C493E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoU4QULc2zSnZ7vm=-Xf3Gh0+KvkSRwFKDWc8zxA15BYw@mail.gmail.com>
Message-ID: <CAPASGLqsT53xctVXR7Mp7-NufwDuYt_M1+3BEp-+0aKpJOTP=g@mail.gmail.com>

---------- Forwarded message ---------
From: Eric Noulard <eric.noulard at gmail.com>
Date: mer. 15 ao?t 2018 ? 17:13
Subject: Re: [CMake] Problem with creating shared library
To: <damir_porobic at live.com>


May be check the list of symbol in the lib.
KImageAnnotator::KImageAnnotator(QPixmap const&)
may really not be there (only declared in some header and not defined
anywhere).

Does the KImageAnnotator library have unit tests in its project?
If no executable linked to the ilb you won't discover the link error until
you try to link something to the lib.

This is a kind wild guess, don't take it personally :-)

Le mer. 15 ao?t 2018 ? 16:21, Damir Porobic <damir_porobic at live.com> a
?crit :

> Thanks for the feedback.
>
>
> It looks like this line is failing:
>
> /usr/bin/c++    -std=c++0x -fno-operator-names -fno-exceptions -Wall
> -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long
> -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual
> -Werror=return-type  -Wl,--enable-new-dtags
> CMakeFiles/testApp.dir/main.cpp.o
> CMakeFiles/testApp.dir/testApp_automoc.cpp.o  -o testApp
> /usr/local/lib64/libkImageAnnotator.so.0.0.1
> /usr/lib64/libKF5CoreAddons.so.5.32.0 /usr/lib64/libKF5I18n.so.5.32.0
> /usr/lib64/libKF5WidgetsAddons.so.5.32.0 /usr/lib64/libQt5Widgets.so.5.6.2
> /usr/lib64/libQt5Gui.so.5.6.2 /usr/lib64/libQt5Core.so.5.6.2
> -Wl,-rpath,/usr/local/lib64
>
> The lib at /usr/local/lib64/libkImageAnnotator.so.0.0.1 seems to be
> correct, according to the sudo make install output from the lib
>
>
> Install the project...
> -- Install configuration: "Debug"
> -- Installing: /usr/local/lib64/libkImageAnnotator.so.0.0.1
> -- Installing: /usr/local/lib64/libkImageAnnotator.so.1
> -- Set runtime path of "/usr/local/lib64/libkImageAnnotator.so.0.0.1" to
> "/usr/local/lib64"
> -- Installing: /usr/local/lib64/libkImageAnnotator.so
> ...
> -- Installing:
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake
> -- Installing:
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake
>
>
>
> Don't know if this is OK, but it looks like the debug and the non-debug
> cmake versions are used:
>
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(3):
> if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 2.5 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(6):
> cmake_policy(PUSH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(7):
> cmake_policy(VERSION 2.6 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(13):
> set(CMAKE_IMPORT_FILE_VERSION 1 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(16):
> set(_targetsDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(17):
> set(_targetsNotDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(18):
> set(_expectedTargets )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(19):
> foreach(_expectedTarget kImageAnnotator )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(20):
> list(APPEND _expectedTargets ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(21):
> if(NOT TARGET ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(22):
> list(APPEND _targetsNotDefined ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(24):
> if(TARGET ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(28):
> if(${_targetsDefined} STREQUAL ${_expectedTargets} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(36):
> if(NOT ${_targetsDefined} STREQUAL  )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(39):
> unset(_targetsDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(40):
> unset(_targetsNotDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(41):
> unset(_expectedTargets )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(45):
> get_filename_component(_IMPORT_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(46):
> get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(47):
> get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(48):
> get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(49):
> if(_IMPORT_PREFIX STREQUAL / )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(54):
> add_library(kImageAnnotator SHARED IMPORTED )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(56):
> set_target_properties(kImageAnnotator PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include
> INTERFACE_LINK_LIBRARIES
> Qt5::Widgets;KF5::CoreAddons;KF5::I18n;KF5::WidgetsAddons )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(61):
> if(CMAKE_VERSION VERSION_LESS 2.8.12 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(66):
> get_filename_component(_DIR ${CMAKE_CURRENT_LIST_FILE} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(67):
> file(GLOB CONFIG_FILES ${_DIR}/kImageAnnotatorConfig-*.cmake )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(68):
> foreach(f ${CONFIG_FILES} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(69):
> include(${f} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(6):
> set(CMAKE_IMPORT_FILE_VERSION 1 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(9):
> set_property(TARGET kImageAnnotator APPEND PROPERTY IMPORTED_CONFIGURATIONS
> DEBUG )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(10):
> set_target_properties(kImageAnnotator PROPERTIES IMPORTED_LOCATION_DEBUG
> ${_IMPORT_PREFIX}/lib64/libkImageAnnotator.so.0.0.1 IMPORTED_SONAME_DEBUG
> libkImageAnnotator.so.1 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(15):
> list(APPEND _IMPORT_CHECK_TARGETS kImageAnnotator )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(16):
> list(APPEND _IMPORT_CHECK_FILES_FOR_kImageAnnotator
> ${_IMPORT_PREFIX}/lib64/libkImageAnnotator.so.0.0.1 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(19):
> set(CMAKE_IMPORT_FILE_VERSION )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(73):
> set(_IMPORT_PREFIX )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(76):
> foreach(target ${_IMPORT_CHECK_TARGETS} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(77):
> foreach(file ${_IMPORT_CHECK_FILES_FOR_${target}} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(78):
> if(NOT EXISTS ${file} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(90):
> unset(_IMPORT_CHECK_FILES_FOR_${target} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(92):
> unset(_IMPORT_CHECK_TARGETS )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(98):
> set(CMAKE_IMPORT_FILE_VERSION )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(99):
> cmake_policy(POP )
>
> It looks like the correct cmake files are used.
>
> Any more ideas?
>
> Regards,
> Damir
>
> ------------------------------
> *From:* Eric Noulard <eric.noulard at gmail.com>
> *Sent:* Wednesday, August 15, 2018 12:18
> *To:* damir_porobic at live.com
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Problem with creating shared library
>
>
>
> Le mer. 15 ao?t 2018 ? 10:32, Damir Porobic <damir_porobic at live.com> a
> ?crit :
>
> Hi Folks,
>
>
> I'm trying to write a shared library and run into an issue where I can't
> find any clues to where the problem is.
>
> I have a project with following structure:
>
>
> src/
>
>     dir1/
>
>         file1.h
>
>         file1.cpp
>
>     dir2/
>
>         file2.h
>         file2.cpp
>
>
>
> Now I have this CMakeList:
>
> cmake_minimum_required(VERSION 3.5)
>
> project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)
>
> ...
>
>
> add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
> target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> target_include_directories(${PROJECT_NAME} PUBLIC
> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES VERSION
> ${PROJECT_VERSION} SOVERSION 1)
>
> set(kimageannotator_CONFIG ${PROJECT_NAME}Config)
>
> install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
>         ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
> install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})
>
> install(EXPORT ${kimageannotator_CONFIG} DESTINATION
> share/${kimageannotator_CONFIG}/cmake)
>
> export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)
>
>
> In another test project, I add the library like this:
> ...
> find_package(kImageAnnotator REQUIRED)
>
> add_executable(testApp main.cpp)
> target_link_libraries(testApp Qt5::Widgets kImageAnnotator)
>
>
> Now when I try to build my test project, I get this:
>
> dporobic at linux ~/projects/testApp/build
> $ cmake .. && make
> -- Could not set up the appstream test. appstreamcli is missing.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/dporobic/projects/testApp/build
> [ 25%] Automatic moc for target testApp
> [ 25%] Built target testApp_automoc
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
> [ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
> [100%] Linking CXX executable testApp
> CMakeFiles/testApp.dir/main.cpp.o: In function `main':
> main.cpp:(.text+0x8e): undefined reference to
> `KImageAnnotator::KImageAnnotator(QPixmap const&)'
> collect2: error: ld returned 1 exit status
> CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
> make[2]: *** [testApp] Error 1
> CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all'
> failed
> make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
> Makefile:94: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Any idea how I could/should troubleshoot such issue?
>
>
> Try to compile in verbose mode
>
> make VERBOSE=1
>
> and have a look at the culprit link line.
> You should see the reference to your previously built shared lib.
>
> Check whether this lib is where it should be (may be you didn't install
> it?)
>
> then check which kImageAnnotatorConfig.cmake file is used by the testApp
> project in order to see if any
> [wrong and not up to date] test & trial version of this file is lying
> around.
>
>
> --
> Eric
>


-- 
Eric


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/1e4eebdd/attachment-0001.html>

From bitminer at gmail.com  Wed Aug 15 11:45:46 2018
From: bitminer at gmail.com (Brian Davis)
Date: Wed, 15 Aug 2018 10:45:46 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
Message-ID: <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>

 Yes I know all about the bit about having to reinstall CUDA (been using it
since the 2.0 days) for 2017 (using VS since 2005).... if only I could get
CMake to call VS2013... ya know the version that already has cuda 8.0
installed and configured and the extensions from C:\Program Files\NVIDIA
GPU Computing Toolkit\CUDA\v8.0\extras\visual_studio_integration\MSBuildExtensions
that get installed

Can CMake defer to what the user ultimately wants? .. say the correct
version of VS.  I mean that is what I thought I specified.

I had thought when I upgraded to 3.8/3.9 or whatever at the time that ...
Oh great they now have an open project button... .maybe that will allow me
to not have to generate .bat scripts to load VS (mind you my .bat script
generation in CMake could actually tell me which correct version to load so
these kinds of things are possible) with the env vars I set and set them in
CMake and have CMake load VS (again correct version) with said env.  It
worked like a charm... well for a while anyway as it does with anything in
the tech world.  I certainly feel like I have upgraded.


On Wed, Aug 15, 2018 at 9:48 AM, Robert Maynard <robert.maynard at kitware.com>
wrote:

> > cannot find CUDA likely as CUDA was not installed after 2017
>
> The CUDA language support requires the CUDA MSBUILD extensions, which
> will require you to run the CUDA installer again ( it only installs
> the msbuild extensions for versions that are currently installed ).
>
> >  I would like it to load 2013 after being told to generate Visual Studio
> 2013 project files.
>
>  As Hendrik stated CMake defers to the windows shell/explorer for
> opening solution files.
> On Tue, Aug 14, 2018 at 7:27 PM Brian Davis <bitminer at gmail.com> wrote:
> >
> >
> > It also cannot find CUDA likely as CUDA was not installed after 2017.  I
> would like it to load 2013 after being told to generate Visual Studio 2013
> project files.  Is this difficult to ask fo Kitware?  I am sure there are
> certainly some shenanigans like path or VS2017 hooking calls to 2013 tools
> or the like all of which I am sure make sens to a cubite in the bowels of
> the MS machine.  VS loaded 2017 and vs 2013  proj files then promptly had
> problems searching files, compiling stale targets and the like.  So while
> VS2017 make "hook" 2013 tools it certainly can't do any thing useful with
> them IME.  Is there a Meta buld tool (goop generator) that will build goop
> for a target goop reader then call said target goop reader (of correct
> specified version) to read goop and compile my code?  sigh.
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
>



-- 
Brian J. Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/28dcc8af/attachment.html>

From damir_porobic at live.com  Wed Aug 15 11:51:21 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Wed, 15 Aug 2018 15:51:21 +0000
Subject: [CMake] Fwd:  Problem with creating shared library
In-Reply-To: <CAPASGLqsT53xctVXR7Mp7-NufwDuYt_M1+3BEp-+0aKpJOTP=g@mail.gmail.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLqbpebOqycCGwjeZPRSNKSyAST2PAA8Navu=CJBQ_n=sQ@mail.gmail.com>
 <AM0PR0202MB3411600110C0BCC21770C493E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoU4QULc2zSnZ7vm=-Xf3Gh0+KvkSRwFKDWc8zxA15BYw@mail.gmail.com>,
 <CAPASGLqsT53xctVXR7Mp7-NufwDuYt_M1+3BEp-+0aKpJOTP=g@mail.gmail.com>
Message-ID: <AM0PR0202MB3411D0FB5CA437567D2BBC05E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>

It does have unit tests and an executable which I use for testing, all that works fine.


I have the feeling that something with the CMakeList config is not alright. Is there any tutorial that explains how to correctly create a shared library?

________________________________
From: CMake <cmake-bounces at cmake.org> on behalf of Eric Noulard <eric.noulard at gmail.com>
Sent: Wednesday, August 15, 2018 17:13
To: CMake Mailinglist
Subject: [CMake] Fwd: Problem with creating shared library



---------- Forwarded message ---------
From: Eric Noulard <eric.noulard at gmail.com<mailto:eric.noulard at gmail.com>>
Date: mer. 15 ao?t 2018 ? 17:13
Subject: Re: [CMake] Problem with creating shared library
To: <damir_porobic at live.com<mailto:damir_porobic at live.com>>


May be check the list of symbol in the lib.
KImageAnnotator::KImageAnnotator(QPixmap const&)
may really not be there (only declared in some header and not defined anywhere).

Does the KImageAnnotator library have unit tests in its project?
If no executable linked to the ilb you won't discover the link error until you try to link something to the lib.

This is a kind wild guess, don't take it personally :-)

Le mer. 15 ao?t 2018 ? 16:21, Damir Porobic <damir_porobic at live.com<mailto:damir_porobic at live.com>> a ?crit :

Thanks for the feedback.


It looks like this line is failing:

/usr/bin/c++    -std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type  -Wl,--enable-new-dtags  CMakeFiles/testApp.dir/main.cpp.o CMakeFiles/testApp.dir/testApp_automoc.cpp.o  -o testApp /usr/local/lib64/libkImageAnnotator.so.0.0.1 /usr/lib64/libKF5CoreAddons.so.5.32.0 /usr/lib64/libKF5I18n.so.5.32.0 /usr/lib64/libKF5WidgetsAddons.so.5.32.0 /usr/lib64/libQt5Widgets.so.5.6.2 /usr/lib64/libQt5Gui.so.5.6.2 /usr/lib64/libQt5Core.so.5.6.2 -Wl,-rpath,/usr/local/lib64


The lib at /usr/local/lib64/libkImageAnnotator.so.0.0.1 seems to be correct, according to the sudo make install output from the lib


Install the project...
-- Install configuration: "Debug"
-- Installing: /usr/local/lib64/libkImageAnnotator.so.0.0.1
-- Installing: /usr/local/lib64/libkImageAnnotator.so.1
-- Set runtime path of "/usr/local/lib64/libkImageAnnotator.so.0.0.1" to "/usr/local/lib64"
-- Installing: /usr/local/lib64/libkImageAnnotator.so
...
-- Installing: /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake
-- Installing: /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake



Don't know if this is OK, but it looks like the debug and the non-debug cmake versions are used:

/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(3):  if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 2.5 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(6):  cmake_policy(PUSH )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(7):  cmake_policy(VERSION 2.6 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(13):  set(CMAKE_IMPORT_FILE_VERSION 1 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(16):  set(_targetsDefined )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(17):  set(_targetsNotDefined )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(18):  set(_expectedTargets )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(19):  foreach(_expectedTarget kImageAnnotator )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(20):  list(APPEND _expectedTargets ${_expectedTarget} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(21):  if(NOT TARGET ${_expectedTarget} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(22):  list(APPEND _targetsNotDefined ${_expectedTarget} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(24):  if(TARGET ${_expectedTarget} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(28):  if(${_targetsDefined} STREQUAL ${_expectedTargets} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(36):  if(NOT ${_targetsDefined} STREQUAL  )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(39):  unset(_targetsDefined )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(40):  unset(_targetsNotDefined )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(41):  unset(_expectedTargets )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(45):  get_filename_component(_IMPORT_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(46):  get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(47):  get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(48):  get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(49):  if(_IMPORT_PREFIX STREQUAL / )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(54):  add_library(kImageAnnotator SHARED IMPORTED )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(56):  set_target_properties(kImageAnnotator PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include INTERFACE_LINK_LIBRARIES Qt5::Widgets;KF5::CoreAddons;KF5::I18n;KF5::WidgetsAddons )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(61):  if(CMAKE_VERSION VERSION_LESS 2.8.12 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(66):  get_filename_component(_DIR ${CMAKE_CURRENT_LIST_FILE} PATH )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(67):  file(GLOB CONFIG_FILES ${_DIR}/kImageAnnotatorConfig-*.cmake )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(68):  foreach(f ${CONFIG_FILES} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(69):  include(${f} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(6):  set(CMAKE_IMPORT_FILE_VERSION 1 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(9):  set_property(TARGET kImageAnnotator APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(10):  set_target_properties(kImageAnnotator PROPERTIES IMPORTED_LOCATION_DEBUG ${_IMPORT_PREFIX}/lib64/libkImageAnnotator.so.0.0.1 IMPORTED_SONAME_DEBUG libkImageAnnotator.so.1 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(15):  list(APPEND _IMPORT_CHECK_TARGETS kImageAnnotator )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(16):  list(APPEND _IMPORT_CHECK_FILES_FOR_kImageAnnotator ${_IMPORT_PREFIX}/lib64/libkImageAnnotator.so.0.0.1 )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake(19):  set(CMAKE_IMPORT_FILE_VERSION )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(73):  set(_IMPORT_PREFIX )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(76):  foreach(target ${_IMPORT_CHECK_TARGETS} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(77):  foreach(file ${_IMPORT_CHECK_FILES_FOR_${target}} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(78):  if(NOT EXISTS ${file} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(90):  unset(_IMPORT_CHECK_FILES_FOR_${target} )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(92):  unset(_IMPORT_CHECK_TARGETS )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(98):  set(CMAKE_IMPORT_FILE_VERSION )
/usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(99):  cmake_policy(POP )

It looks like the correct cmake files are used.

Any more ideas?

Regards,
Damir

________________________________
From: Eric Noulard <eric.noulard at gmail.com<mailto:eric.noulard at gmail.com>>
Sent: Wednesday, August 15, 2018 12:18
To: damir_porobic at live.com<mailto:damir_porobic at live.com>
Cc: CMake Mailinglist
Subject: Re: [CMake] Problem with creating shared library



Le mer. 15 ao?t 2018 ? 10:32, Damir Porobic <damir_porobic at live.com<mailto:damir_porobic at live.com>> a ?crit :

Hi Folks,


I'm trying to write a shared library and run into an issue where I can't find any clues to where the problem is.

I have a project with following structure:


src/

    dir1/

        file1.h

        file1.cpp

    dir2/

        file2.h

        file2.cpp



Now I have this CMakeList:

cmake_minimum_required(VERSION 3.5)

project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)


...


add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons KF5::I18n KF5::WidgetsAddons)

target_include_directories(${PROJECT_NAME} PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)

set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION} SOVERSION 1)

set(kimageannotator_CONFIG ${PROJECT_NAME}Config)

install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
        ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})

install(EXPORT ${kimageannotator_CONFIG} DESTINATION share/${kimageannotator_CONFIG}/cmake)

export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)


In another test project, I add the library like this:
...
find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp Qt5::Widgets kImageAnnotator)


Now when I try to build my test project, I get this:

dporobic at linux ~/projects/testApp/build
$ cmake .. && make
-- Could not set up the appstream test. appstreamcli is missing.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dporobic/projects/testApp/build
[ 25%] Automatic moc for target testApp
[ 25%] Built target testApp_automoc
Scanning dependencies of target testApp
[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
[ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
[100%] Linking CXX executable testApp
CMakeFiles/testApp.dir/main.cpp.o: In function `main':
main.cpp:(.text+0x8e): undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
make[2]: *** [testApp] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all' failed
make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Any idea how I could/should troubleshoot such issue?

Try to compile in verbose mode

make VERBOSE=1

and have a look at the culprit link line.
You should see the reference to your previously built shared lib.

Check whether this lib is where it should be (may be you didn't install it?)

then check which kImageAnnotatorConfig.cmake file is used by the testApp project in order to see if any
[wrong and not up to date] test & trial version of this file is lying around.


--
Eric


--
Eric


--
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/0dd53ca1/attachment-0001.html>

From post at hendrik-sattler.de  Wed Aug 15 12:18:49 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 15 Aug 2018 18:18:49 +0200
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
Message-ID: <FEC9BFA4-90BD-4F96-9A79-BCE638AAD757@hendrik-sattler.de>



Am 15. August 2018 17:45:46 MESZ schrieb Brian Davis <bitminer at gmail.com>:
>Can CMake defer to what the user ultimately wants? .. say the correct
>version of VS.  I mean that is what I thought I specified.

Do you actually read the answers?
You can configure that in the Windows explorer like it you wanted to open the .sln file from there. Visual Studio install the right tool.

From bitminer at gmail.com  Wed Aug 15 12:30:26 2018
From: bitminer at gmail.com (Brian Davis)
Date: Wed, 15 Aug 2018 11:30:26 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
Message-ID: <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>

So here's some more odd bits.  Due to CMake (originally I only wanted to
upgrade VS)  I have now entered the version upgrade cascade and upgraded to
cuda 9.0 (yes the one with 4 patches, but the only one that works
TensorFlow on windows due to cuDNN.dll... sigh)  in hopes to get VS2017 to
work (hey why not right) and while I am at it why not upgrade CMake to
3.12.1 (latest) surely that will work like a charm.   So lets go through
the config chart:

using CMake 3.12.1 (delete cache each time / start from scratch)

Configure -> VS 2013 -> cuda=9.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project

I get:

The CXX compiler identification is MSVC 18.0.31101.0

The CUDA compiler identification is NVIDIA 9.0.176

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe -- works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v9.0/bin/nvcc.exe

Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v9.0/bin/nvcc.exe -- works

Detecting CUDA compiler ABI info

Detecting CUDA compiler ABI info - done

Found OpenGL: opengl32

FUORO4D_UTILITY_LIB_DEBUG =
C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib


and starts VS 2017 (now mind you *some* of those projects are loaded with
include_external_msproject (yeah I am guessing people may start to see the
problem here so loading the correct version of VS may well be important.)
and as such will be mixed mode cuda 8/9 surly to be a hoot in the future if
that path were continued.

so it successfully generates and loads something I cannot use at least
without resorting back to my .bat scripts with env vars set to load VS2013

So hey lets switch back to 8.0

Configure -> VS 2013 -> cuda=8.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project

The CXX compiler identification is MSVC 18.0.31101.0

The CUDA compiler identification is NVIDIA 8.0.60

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe -- works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v8.0/bin/nvcc.exe

Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v8.0/bin/nvcc.exe -- works

Detecting CUDA compiler ABI info

Detecting CUDA compiler ABI info - done

Found OpenGL: opengl32

FUORO4D_UTILITY_LIB_DEBUG =
C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib

Configuring done

VS2017 loads again and complains about one or more project files were not
loaded correctly.  No surprise there.


Configure -> VS 2017 -> cuda=8.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project

Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.

The CXX compiler identification is MSVC 19.14.26433.0

The CUDA compiler identification is unknown

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.

Hmm that ain't never going to work.  I installed 9.0 after VS2017 install
however.


Configure -> VS 2017 -> cuda=9.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project

Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.

The CXX compiler identification is MSVC 19.14.26433.0

The CUDA compiler identification is unknown

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.

Ditto for that attempt

Configure -> VS 2017 -> leave blank in desperate hope CMake will figure it
out  in (optional toolset to use (argument to -T)) ->Generate -> Open
Project


Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.

The CXX compiler identification is MSVC 19.14.26433.0

The CUDA compiler identification is unknown

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.

Ditto for that attempt

Aces! This sure is awesome.




On Wed, Aug 15, 2018 at 10:45 AM, Brian Davis <bitminer at gmail.com> wrote:

> Yes I know all about the bit about having to reinstall CUDA (been using it
> since the 2.0 days) for 2017 (using VS since 2005).... if only I could get
> CMake to call VS2013... ya know the version that already has cuda 8.0
> installed and configured and the extensions from C:\Program Files\NVIDIA
> GPU Computing Toolkit\CUDA\v8.0\extras\visual_studio_integration\MSBuildExtensions
> that get installed
>
> Can CMake defer to what the user ultimately wants? .. say the correct
> version of VS.  I mean that is what I thought I specified.
>
> I had thought when I upgraded to 3.8/3.9 or whatever at the time that ...
> Oh great they now have an open project button... .maybe that will allow me
> to not have to generate .bat scripts to load VS (mind you my .bat script
> generation in CMake could actually tell me which correct version to load so
> these kinds of things are possible) with the env vars I set and set them in
> CMake and have CMake load VS (again correct version) with said env.  It
> worked like a charm... well for a while anyway as it does with anything in
> the tech world.  I certainly feel like I have upgraded.
>
>
> On Wed, Aug 15, 2018 at 9:48 AM, Robert Maynard <
> robert.maynard at kitware.com> wrote:
>
>> > cannot find CUDA likely as CUDA was not installed after 2017
>>
>> The CUDA language support requires the CUDA MSBUILD extensions, which
>> will require you to run the CUDA installer again ( it only installs
>> the msbuild extensions for versions that are currently installed ).
>>
>> >  I would like it to load 2013 after being told to generate Visual
>> Studio 2013 project files.
>>
>>  As Hendrik stated CMake defers to the windows shell/explorer for
>> opening solution files.
>> On Tue, Aug 14, 2018 at 7:27 PM Brian Davis <bitminer at gmail.com> wrote:
>> >
>> >
>> > It also cannot find CUDA likely as CUDA was not installed after 2017.
>> I would like it to load 2013 after being told to generate Visual Studio
>> 2013 project files.  Is this difficult to ask fo Kitware?  I am sure there
>> are certainly some shenanigans like path or VS2017 hooking calls to 2013
>> tools or the like all of which I am sure make sens to a cubite in the
>> bowels of the MS machine.  VS loaded 2017 and vs 2013  proj files then
>> promptly had problems searching files, compiling stale targets and the
>> like.  So while VS2017 make "hook" 2013 tools it certainly can't do any
>> thing useful with them IME.  Is there a Meta buld tool (goop generator)
>> that will build goop for a target goop reader then call said target goop
>> reader (of correct specified version) to read goop and compile my code?
>> sigh.
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake community. For
>> more information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/support.html
>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >
>> > Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > https://cmake.org/mailman/listinfo/cmake
>>
>
>
>
> --
> Brian J. Davis
>



-- 
Brian J. Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/2a2de038/attachment-0001.html>

From robert.maynard at kitware.com  Wed Aug 15 12:58:32 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 15 Aug 2018 12:58:32 -0400
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
 <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
Message-ID: <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>

The MSVC / CUDA support recently has been very challenging to keep track
of. In general CUDA will only support a single patch release of MSVC, and
given how MSVC 2017 doesn't easily allow rollbacks and has a pretty
aggressive update policy ( compared to older MSVC versions ) causes lots of
pain. This in general has been a community wide MSVC+CUDA issue.

CUDA 8 has zero support for VS2017 (
https://docs.nvidia.com/cuda/archive/8.0/cuda-installation-guide-microsoft-windows/index.html
)
CUDA 9.0 and 9.1 only supports VS 2017 15.0 (
https://docs.nvidia.com/cuda/archive/9.0/cuda-installation-guide-microsoft-windows/index.html,
https://docs.nvidia.com/cuda/archive/9.1/cuda-installation-guide-microsoft-windows/index.html
)
CUDA 9.2 only supports VS 2017 15.0 and 15.6

When using MSVC 2017 and CUDA you will need to specify an explicit host
side compiler with -T version=15.## including the minor version (
https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).

On Wed, Aug 15, 2018 at 12:31 PM Brian Davis <bitminer at gmail.com> wrote:

> So here's some more odd bits.  Due to CMake (originally I only wanted to
> upgrade VS)  I have now entered the version upgrade cascade and upgraded to
> cuda 9.0 (yes the one with 4 patches, but the only one that works
> TensorFlow on windows due to cuDNN.dll... sigh)  in hopes to get VS2017 to
> work (hey why not right) and while I am at it why not upgrade CMake to
> 3.12.1 (latest) surely that will work like a charm.   So lets go through
> the config chart:
>
> using CMake 3.12.1 (delete cache each time / start from scratch)
>
> Configure -> VS 2013 -> cuda=9.0 in (optional toolset to use (argument to
> -T)) ->Generate -> Open Project
>
> I get:
>
> The CXX compiler identification is MSVC 18.0.31101.0
>
> The CUDA compiler identification is NVIDIA 9.0.176
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/x86_amd64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/x86_amd64/cl.exe -- works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
> Toolkit/CUDA/v9.0/bin/nvcc.exe
>
> Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
> Toolkit/CUDA/v9.0/bin/nvcc.exe -- works
>
> Detecting CUDA compiler ABI info
>
> Detecting CUDA compiler ABI info - done
>
> Found OpenGL: opengl32
>
> FUORO4D_UTILITY_LIB_DEBUG =
> C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib
>
>
> and starts VS 2017 (now mind you *some* of those projects are loaded with
> include_external_msproject (yeah I am guessing people may start to see the
> problem here so loading the correct version of VS may well be important.)
> and as such will be mixed mode cuda 8/9 surly to be a hoot in the future if
> that path were continued.
>
> so it successfully generates and loads something I cannot use at least
> without resorting back to my .bat scripts with env vars set to load VS2013
>
> So hey lets switch back to 8.0
>
> Configure -> VS 2013 -> cuda=8.0 in (optional toolset to use (argument to
> -T)) ->Generate -> Open Project
>
> The CXX compiler identification is MSVC 18.0.31101.0
>
> The CUDA compiler identification is NVIDIA 8.0.60
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/x86_amd64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/x86_amd64/cl.exe -- works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
> Toolkit/CUDA/v8.0/bin/nvcc.exe
>
> Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
> Toolkit/CUDA/v8.0/bin/nvcc.exe -- works
>
> Detecting CUDA compiler ABI info
>
> Detecting CUDA compiler ABI info - done
>
> Found OpenGL: opengl32
>
> FUORO4D_UTILITY_LIB_DEBUG =
> C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib
>
> Configuring done
>
> VS2017 loads again and complains about one or more project files were not
> loaded correctly.  No surprise there.
>
>
> Configure -> VS 2017 -> cuda=8.0 in (optional toolset to use (argument to
> -T)) ->Generate -> Open Project
>
> Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
>
> The CXX compiler identification is MSVC 19.14.26433.0
>
> The CUDA compiler identification is unknown
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
> works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> CMake Error at CMakeLists.txt:14 (PROJECT):
> No CMAKE_CUDA_COMPILER could be found.
>
> Hmm that ain't never going to work.  I installed 9.0 after VS2017 install
> however.
>
>
> Configure -> VS 2017 -> cuda=9.0 in (optional toolset to use (argument to
> -T)) ->Generate -> Open Project
>
> Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
>
> The CXX compiler identification is MSVC 19.14.26433.0
>
> The CUDA compiler identification is unknown
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
> works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> CMake Error at CMakeLists.txt:14 (PROJECT):
> No CMAKE_CUDA_COMPILER could be found.
>
> Ditto for that attempt
>
> Configure -> VS 2017 -> leave blank in desperate hope CMake will figure it
> out  in (optional toolset to use (argument to -T)) ->Generate -> Open
> Project
>
>
> Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
>
> The CXX compiler identification is MSVC 19.14.26433.0
>
> The CUDA compiler identification is unknown
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
> works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> CMake Error at CMakeLists.txt:14 (PROJECT):
> No CMAKE_CUDA_COMPILER could be found.
>
> Ditto for that attempt
>
> Aces! This sure is awesome.
>
>
>
>
> On Wed, Aug 15, 2018 at 10:45 AM, Brian Davis <bitminer at gmail.com> wrote:
>
>> Yes I know all about the bit about having to reinstall CUDA (been using
>> it since the 2.0 days) for 2017 (using VS since 2005).... if only I could
>> get CMake to call VS2013... ya know the version that already has cuda 8.0
>> installed and configured and the extensions from C:\Program Files\NVIDIA
>> GPU Computing
>> Toolkit\CUDA\v8.0\extras\visual_studio_integration\MSBuildExtensions that
>> get installed
>>
>> Can CMake defer to what the user ultimately wants? .. say the correct
>> version of VS.  I mean that is what I thought I specified.
>>
>> I had thought when I upgraded to 3.8/3.9 or whatever at the time that ...
>> Oh great they now have an open project button... .maybe that will allow me
>> to not have to generate .bat scripts to load VS (mind you my .bat script
>> generation in CMake could actually tell me which correct version to load so
>> these kinds of things are possible) with the env vars I set and set them in
>> CMake and have CMake load VS (again correct version) with said env.  It
>> worked like a charm... well for a while anyway as it does with anything in
>> the tech world.  I certainly feel like I have upgraded.
>>
>>
>> On Wed, Aug 15, 2018 at 9:48 AM, Robert Maynard <
>> robert.maynard at kitware.com> wrote:
>>
>>> > cannot find CUDA likely as CUDA was not installed after 2017
>>>
>>> The CUDA language support requires the CUDA MSBUILD extensions, which
>>> will require you to run the CUDA installer again ( it only installs
>>> the msbuild extensions for versions that are currently installed ).
>>>
>>> >  I would like it to load 2013 after being told to generate Visual
>>> Studio 2013 project files.
>>>
>>>  As Hendrik stated CMake defers to the windows shell/explorer for
>>> opening solution files.
>>> On Tue, Aug 14, 2018 at 7:27 PM Brian Davis <bitminer at gmail.com> wrote:
>>> >
>>> >
>>> > It also cannot find CUDA likely as CUDA was not installed after 2017.
>>> I would like it to load 2013 after being told to generate Visual Studio
>>> 2013 project files.  Is this difficult to ask fo Kitware?  I am sure there
>>> are certainly some shenanigans like path or VS2017 hooking calls to 2013
>>> tools or the like all of which I am sure make sens to a cubite in the
>>> bowels of the MS machine.  VS loaded 2017 and vs 2013  proj files then
>>> promptly had problems searching files, compiling stale targets and the
>>> like.  So while VS2017 make "hook" 2013 tools it certainly can't do any
>>> thing useful with them IME.  Is there a Meta buld tool (goop generator)
>>> that will build goop for a target goop reader then call said target goop
>>> reader (of correct specified version) to read goop and compile my code?
>>> sigh.
>>> >
>>> > --
>>> >
>>> > Powered by www.kitware.com
>>> >
>>> > Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>> >
>>> > Kitware offers various services to support the CMake community. For
>>> more information on each offering, please visit:
>>> >
>>> > CMake Support: http://cmake.org/cmake/help/support.html
>>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> > CMake Training Courses: http://cmake.org/cmake/help/training.html
>>> >
>>> > Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > https://cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> Brian J. Davis
>>
>
>
>
> --
> Brian J. Davis
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/ed0d98c4/attachment-0001.html>

From smancill at jlab.org  Wed Aug 15 15:48:39 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Wed, 15 Aug 2018 16:48:39 -0300
Subject: [CMake] Problem with creating shared library
In-Reply-To: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>

You are mixing the config file and the targets file.

The config file is a template that you normally put in cmake/
FooConfig.cmake.in

You copy the template into the binary dir:

    include(CMakePackageConfigHelpers)

    set(INSTALL_CONFIGDIR lib/cmake/Foo)

    configure_package_config_file(
      "${CMAKE_CURRENT_LIST_DIR}/cmake/FooConfig.cmake.in"
      "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
      INSTALL_DESTINATION ${INSTALL_CONFIGDIR}
    )

It is a good idea to create a version file:

    write_basic_package_version_file(
      "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
      VERSION ${PROJECT_VERSION}
      COMPATIBILITY SameMajorVersion
   )

And then install both:

    install(FILES
        "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
        "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
      DESTINATION ${INSTALL_CONFIGDIR}
      COMPONENT Devel
    )

For the targets is a different file. When you install the library you
should use

    install(TARGETS Foo EXPORT FooTargets ...)

And then export and install the targets:

    # Into the build tree
    export(EXPORT FooTargets
      FILE "${CMAKE_CURRENT_BINARY_DIR}/FooTargets.cmake"
      NAMESPACE Foo::
    )

    # Into PREFIX
    install(EXPORT FooTargets
      FILE FooTargets.cmake
      NAMESPACE Foo::
      DESTINATION ${INSTALL_CONFIGDIR}
      COMPONENT Devel
    )

Finally, your template FooConfig.cmake.in should look like this:

  include(CMakeFindDependencyMacro)

  @PACKAGE_INIT@

  # list your required dependencies here
  find_dependency(Threads)

  if(NOT TARGET Foo::Foo)
    include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake")
  endif()

All this is pretty much the same for any project. Here are the best links
explaining it:

https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
http://unclejimbo.github.io/2018/06/08/Modern-CMake-for-Library-Developers/




El mi?., 15 de ago. de 2018 a la(s) 05:32, Damir Porobic (
damir_porobic at live.com) escribi?:

> Hi Folks,
>
>
> I'm trying to write a shared library and run into an issue where I can't
> find any clues to where the problem is.
>
> I have a project with following structure:
>
>
> src/
>
>     dir1/
>
>         file1.h
>
>         file1.cpp
>
>     dir2/
>
>         file2.h
>         file2.cpp
>
>
>
> Now I have this CMakeList:
>
> cmake_minimum_required(VERSION 3.5)
>
> project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)
>
> ...
>
>
> add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
> target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> target_include_directories(${PROJECT_NAME} PUBLIC
> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES VERSION
> ${PROJECT_VERSION} SOVERSION 1)
>
> set(kimageannotator_CONFIG ${PROJECT_NAME}Config)
>
> install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
>         ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
> install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})
>
> install(EXPORT ${kimageannotator_CONFIG} DESTINATION
> share/${kimageannotator_CONFIG}/cmake)
>
> export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)
>
>
> In another test project, I add the library like this:
> ...
> find_package(kImageAnnotator REQUIRED)
>
> add_executable(testApp main.cpp)
> target_link_libraries(testApp Qt5::Widgets kImageAnnotator)
>
>
> Now when I try to build my test project, I get this:
>
> dporobic at linux ~/projects/testApp/build
> $ cmake .. && make
> -- Could not set up the appstream test. appstreamcli is missing.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/dporobic/projects/testApp/build
> [ 25%] Automatic moc for target testApp
> [ 25%] Built target testApp_automoc
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
> [ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
> [100%] Linking CXX executable testApp
> CMakeFiles/testApp.dir/main.cpp.o: In function `main':
> main.cpp:(.text+0x8e): undefined reference to
> `KImageAnnotator::KImageAnnotator(QPixmap const&)'
> collect2: error: ld returned 1 exit status
> CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
> make[2]: *** [testApp] Error 1
> CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all'
> failed
> make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
> Makefile:94: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Any idea how I could/should troubleshoot such issue?
>
> Thanks in advance!
>
> Regards,
> Damir
>
>
> --
>
> 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=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=JJ5RqPyjdlGGc3fT-5nQQM-JcJzwjBZU6ciOQlmEJVs&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_help_support.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=vUHQvc_7Ovi_5BDjy3JYFOIvTmihTSFOQNndNSpMOnA&e=
> CMake Consulting:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=91AJA3BxTfHAvsi0mAzkszAyUUmE2xfwbLgN_fYvFO4&e=
> CMake Training Courses:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=isQW6paMIqhUFaejOZ4qfUiSVwNiR1yxoQn4J91yb8o&e=
>
> Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=ose8YVW10s6tWkujUCq162vyyipCdlw-MW93qUlqdGk&e=
>
> Follow this link to subscribe/unsubscribe:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=KftR51q4EGgNERicS2QyHvzlrNaqb11IUwwbz1YTjVU&e=
>


-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/d4c9edb0/attachment.html>

From smancill at jlab.org  Wed Aug 15 16:13:50 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Wed, 15 Aug 2018 17:13:50 -0300
Subject: [CMake] Printing "Found <package>..." message in config mode
In-Reply-To: <C15005C5-5F77-4A96-872B-7F8EF4579AC2@hendrik-sattler.de>
References: <CAJPSwc3MncfeFEWE=M_KpfYQNx=srriv=OgJjTVxBR16sQUPRw@mail.gmail.com>
 <C15005C5-5F77-4A96-872B-7F8EF4579AC2@hendrik-sattler.de>
Message-ID: <CAJPSwc3+uegziVR8O-TmHGBxRY_FDowCXE8XZy=zX088dwmNPw@mail.gmail.com>

Ah, I see that FIND_PACKAGE_HANDLE_STANDARD_ARGS prints

   -- Find Foo: <path to FooConfig.cmake> (found version "<version>")

I guess my function is not necessary, I can just put inside FooConfig.cmake

    find_package_message(Foo
      "Found Foo: ${CMAKE_CURRENT_LIST_FILE} (found version
\"@PACKAGE_VERSION@\")"
      "[${CMAKE_CURRENT_LIST_FILE}][@PACKAGE_VERSION@]")


El mar., 14 de ago. de 2018 a la(s) 19:36, Hendrik Sattler (
post at hendrik-sattler.de) escribi?:

>
>
> Am 14. August 2018 22:08:36 MESZ schrieb "Sebasti?n Mancilla" <
> smancill at jlab.org>:
> >Normally, find modules call FIND_PACKAGE_HANDLE_STANDARD_ARGS, which in
> >turn calls FIND_PACKAGE_MESSAGE, to print a nice message about the
> >location
> >and version of the dependency.
>
> You can do that with FIND_PACKAGE_HANDLE_STANDARD_ARGS, just use module
> name and CONFIG_MODE as arguments.
>
> HS
> --
>
> 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=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=RJEEiZ1k-XIjXM_90_6kyZ5FMVIYsSAiyQRThYB3iJ8&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_help_support.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=LqUR8QOw8X5ya0FRtvJ3J9e40LyNK-gydGXOeaM80Ps&e=
> CMake Consulting:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=N5TtfB9fCMuIe6ZcnAzVHEk5w4MnGzNdZ8hI-zyiU5Y&e=
> CMake Training Courses:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=aBTzKuF0iyTKifZQ6madT0vT189WJsgYDDf8jDL_JxI&e=
>
> Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=Wu5CbQmwVaf6uE5Dp9OK_EASEZ6WS16W0hVEXN_3BAo&e=
>
> Follow this link to subscribe/unsubscribe:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=QViykHUMgtj8XqForeqtw7j16bUM3hAp3JTzSse90b8&e=
>


-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/a3a0b4d6/attachment-0001.html>

From roman.wueger at gmx.at  Thu Aug 16 08:07:52 2018
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 16 Aug 2018 14:07:52 +0200
Subject: [CMake] Translation for CPack.GenericWelcome.txt
Message-ID: <4DA2AF92-6F95-4250-B40F-3CED1E5A60C1@gmx.at>

Hello,

I use CPack and productbuild on Mac OS. When I run the Installer after creation, then the welcome message in the Installer is German, but I do not find a translation for the original english document. Where do the translation come from?

Thanks in advance

Regards
Roman

From cyril.boucher94260 at gmail.com  Thu Aug 16 08:24:00 2018
From: cyril.boucher94260 at gmail.com (Cyril Boucher)
Date: Thu, 16 Aug 2018 14:24:00 +0200
Subject: [CMake] Printing "Found <package>..." message in config mode
In-Reply-To: <CAJPSwc3+uegziVR8O-TmHGBxRY_FDowCXE8XZy=zX088dwmNPw@mail.gmail.com>
References: <CAJPSwc3MncfeFEWE=M_KpfYQNx=srriv=OgJjTVxBR16sQUPRw@mail.gmail.com>
 <C15005C5-5F77-4A96-872B-7F8EF4579AC2@hendrik-sattler.de>
 <CAJPSwc3+uegziVR8O-TmHGBxRY_FDowCXE8XZy=zX088dwmNPw@mail.gmail.com>
Message-ID: <CALYSiH4r-D4qMMvi8UGP1bgp5PEBijcTi6dn21Tu9=Vweu8jgQ@mail.gmail.com>

Hi Sebasti?n,

Your question got me thinking and I also figured that way of doing it works:

set(<package>_CONFIG ${CMAKE_CURRENT_LIST_FILE})
find_package_handle_standard_args(<package> CONFIG_MODE)

This allows you to keep most of the nice logic inside
FindPackageHandleStandardArgs.

Best regards,
Cyril

2018-08-15 22:13 GMT+02:00 Sebasti?n Mancilla <smancill at jlab.org>:

> Ah, I see that FIND_PACKAGE_HANDLE_STANDARD_ARGS prints
>
>    -- Find Foo: <path to FooConfig.cmake> (found version "<version>")
>
> I guess my function is not necessary, I can just put inside FooConfig.cmake
>
>     find_package_message(Foo
>       "Found Foo: ${CMAKE_CURRENT_LIST_FILE} (found version
> \"@PACKAGE_VERSION@\")"
>       "[${CMAKE_CURRENT_LIST_FILE}][@PACKAGE_VERSION@]")
>
>
> El mar., 14 de ago. de 2018 a la(s) 19:36, Hendrik Sattler (
> post at hendrik-sattler.de) escribi?:
>
>>
>>
>> Am 14. August 2018 22:08:36 MESZ schrieb "Sebasti?n Mancilla" <
>> smancill at jlab.org>:
>> >Normally, find modules call FIND_PACKAGE_HANDLE_STANDARD_ARGS, which in
>> >turn calls FIND_PACKAGE_MESSAGE, to print a nice message about the
>> >location
>> >and version of the dependency.
>>
>> You can do that with FIND_PACKAGE_HANDLE_STANDARD_ARGS, just use module
>> name and CONFIG_MODE as arguments.
>>
>> HS
>> --
>>
>> 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=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI
>> 4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_
>> cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=RJEEiZ1k-XIjXM_90_
>> 6kyZ5FMVIYsSAiyQRThYB3iJ8&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_help_support.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI
>> 4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_
>> cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=LqUR8QOw8X5ya0FRtvJ3J9e40LyNK-
>> gydGXOeaM80Ps&e=
>> CMake Consulting: https://urldefense.proofpoint.
>> com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIGaQ&c=
>> lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-
>> YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=
>> N5TtfB9fCMuIe6ZcnAzVHEk5w4MnGzNdZ8hI-zyiU5Y&e=
>> CMake Training Courses: https://urldefense.proofpoint.
>> com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIGaQ&c=
>> lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-
>> YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=
>> aBTzKuF0iyTKifZQ6madT0vT189WJsgYDDf8jDL_JxI&e=
>>
>> Visit other Kitware open-source projects at
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
>> kitware.com_opensource_opensource.html&d=DwIGaQ&c=
>> lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-
>> YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA
>> &s=Wu5CbQmwVaf6uE5Dp9OK_EASEZ6WS16W0hVEXN_3BAo&e=
>>
>> Follow this link to subscribe/unsubscribe:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.
>> org_mailman_listinfo_cmake&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI
>> 4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_
>> cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=QViykHUMgtj8XqForeqtw7j16bUM3h
>> Ap3JTzSse90b8&e=
>>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valpara?so, Chile
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/8928933d/attachment.html>

From stephan.menzel at gmail.com  Thu Aug 16 09:11:16 2018
From: stephan.menzel at gmail.com (Stephan Menzel)
Date: Thu, 16 Aug 2018 15:11:16 +0200
Subject: [CMake] Dependencies with static libraries
In-Reply-To: <CAEQ568vO+uY1HyXgdk_1tmOEuuvnXtHnrtDiAx5Z1CiJEECXOg@mail.gmail.com>
References: <CAEQ568vO+uY1HyXgdk_1tmOEuuvnXtHnrtDiAx5Z1CiJEECXOg@mail.gmail.com>
Message-ID: <CAEQ568uj0G6sHAdV67hv9nbKb21yvAnjC7B1POuHsVZ8dRoKMg@mail.gmail.com>

On Thu, Jun 28, 2018 at 4:07 PM Stephan Menzel <stephan.menzel at gmail.com>
wrote:

> I am observing a strange problem regarding dependencies to static libs in
> executables. I am not entirely sure but it seems this started since I
> upgraded to the 3.11 line. I am using Windows and MSVC14.
>
> Basically, my code base contains a number of static libraries that are
> linked together to a few executables. Very basic and down to earth. Like
> this:
>
> set(MY_SERVER_SRC
> ServerSource1.cpp
> ServerSource2.cpp
> )
>
> set(MY_SERVER_HDR
> ServerConfig.hpp
> Header1.hpp
> Header2.hpp
> )
>
> add_library(my_server STATIC ${MY_SERVER_SRC} ${MY_SERVER_HDR})
> target_link_libraries(my_server
> some_tools
> some_base
> ${Boost_LIBRARIES}
> ${OPENSSL_LIBRARIES}
> )
> add_executable(serverd main.cpp)
> target_link_libraries(serverd
> my_server
> some_tools
> some_base
>
> ${Boost_LIBRARIES}
> ${OPENSSL_LIBRARIES}
> )
>
> So a few big libs with the beef in them and then a small main.cpp
> containing executable. Nothing fancy.
>
> What gives me trouble now is that dependencies within that seem broken. In
> above example, when I edit ServerSource1.cpp and then hit "Build", I see
> ServerSource1.o being compiled and the library my_server being linked. Like
> expected. Problem is, serverd does not get linked. Or at least I see no
> hint of it being linked (In MSVC's output window).
> So, my question is: What could cause this? I there anything 3.11.x does
> differently which causes those dependecies to break? And how can I fix this?
>
> This is quickly turning into a major problem for us here as it means that
> we cannot reliably build anymore because whenever we change something and
> hit build we can't be sure we get a linked executable anymore unless we do
> a complete rebuild, which takes a long time (In fact, I wrote this message
> waiting for one).
>
>
I have a little update here in case anyone experiences the same. Since I
first noticed it when I posted here the problem was degrading. Back then I
thought I couldn't track it down because it wasn't always happening. What
led me to believe it was reproducible was the lack of any kind of output in
the console.

Unfortunately since then the problem has turned from a major nuisance into
a much bigger issue because right now it actually is always reproducible.
It never works anymore.

The only way to bring VS to re-link my executable is to delete the old one.
Any change in the lib 'my_server' leads to the lib being compiled and
linked fine but the server executable never is.

I have checked this many times using timestamps. Now I usually see the lib
with a 'right now' timestamp and the executable with a much older one.
Several other developers here in the team experience the same thing so I
don't think it is my computer or the installation or anything.
I have also tried updating to 3.12.1 and the issue is still there.

As for reasons I am still in the dark. My money would be on some kind of
race condition. When the problem gradually got worse I also occasionally
saw a linker error saying the "program database is already in use". Waiting
a few seconds and then clicking "Build Solution" again generally solved
that but still I suppose this should never happen unless the binary is
running or otherwise in use.

Also since then we gradually added rather template heavy code to that
static lib which (in Debug mode) is now 250M in size. My guess is that some
processes are still working on the lib when the linker tries to build the
executable out of it. The linker fails, lack of console output hides that
from me and with the lib growing this got more and more likely over time
and is now always the case.

I know, it's a long shot. Counter evidence against this hypothesis is the
fact that in Release mode the problem occurs just as much and there the
data is much smaller, only about 50M, with no pdbs.

Meanwhile I have also double checked all kinds of flags or defines we use
and did not find anything out of the ordinary. I have also verified the
dependencies as they are shown in the visual studio project properties.
They look very much like I expect them to look.

I am doubling down efforts into investigating this now as it has cost us
dearly the last couple of weeks as new developers stumbled into it without
knowing about it. Will post results here. Of course I also appreciate new
ideas about possible reasons.

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/c17e44ac/attachment-0001.html>

From quang.t.ha.20 at gmail.com  Thu Aug 16 10:50:02 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Thu, 16 Aug 2018 08:50:02 -0600
Subject: [CMake] set environment variables for ctest globally
Message-ID: <CAGfE9+PTYy+s03zzpz7PuWHrMZNM8aWDQzmmSvMmvFo-9qkhww@mail.gmail.com>

Hi all,

In our ctest script, we used a cmake files generated from building
third-party libraries, i.e.:

cmake -C"/path/to/third-parties/share/cmake/amanzi-tpl-config.cmake" [other
options]

Is there a way to pass all those configurations (i.e.
PATH/LD_LIBRARY_PATH/CPATH) into the ctest environment?

While we are also at that, how would one set PYTHONPATH for the environment
of all the test cases? I know you can do set_tests_properties for
individual ones, but is there like a global switch?

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/84276638/attachment.html>

From Philip.Tessier at Engility.com  Thu Aug 16 11:59:15 2018
From: Philip.Tessier at Engility.com (Tessier, Philip @ Engility)
Date: Thu, 16 Aug 2018 15:59:15 +0000
Subject: [CMake] Project referring to CSharp project generates
 incorrectly?
In-Reply-To: <1534280553005.48536@Engility.com>
References: <1534280553005.48536@Engility.com>
Message-ID: <1534435157010.19879@Engility.com>

All,

Thank you in advance,


I'm an experienced CMake user, in the C++ realm. I'm presently working outside that realm, porting a 200-project solution from Visual Studio (.vcxproj, .csproj) files to CMake. I'm very pleased that CMake has adopted CSharp! Thank you!


I seem to have uncovered a bug where one CSharp project depends on another.


The first CMakeLists.txt:

cmake_minimum_required(VERSION 3.12)
project(DockPanel CSharp)
...
add_library(DockPanel MODULE ${SOURCES_files_Compile} ${SOURCES_files_EmbeddedResource})
set_property(TARGET DockPanel APPEND PROPERTY VS_DOTNET_REFERENCES "System")


The second CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(CSharpFramework CSharp)
...
add_library(CSharpFramework MODULE ${SOURCES_files_Compile} ${SOURCES_files_EmbeddedResource})
target_link_libraries(CSharpFramework PUBLIC $<$<CONFIG:Debug>:DockPanel>  )
set_property(TARGET CSharpFramework APPEND PROPERTY VS_DOTNET_REFERENCES "System")

(I haven't shown everything, as I'm extracting these from a huge system, but I can elaborate if necessary...)

CMake configures and generates (to VS2015) without error. Things proceed as expected until it's time to link the second project.
Then, I get:
..\DockPanel\Debug\DockPanel.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x358

A bit of investigative work shows that the generated CSharpFramework.vcxproj contains, as expected:
    <ProjectReference Include="D:\Havok\hk2014_2_5_Simulation\Source\build-x64-msvc-v140-\Vision\Editor\vForge\DockPanel\DockPanel.vcxproj">
      <Project>{DCCB7EE9-726F-3D42-A673-D6CCB4EF6675}</Project>
      <Name>DockPanel</Name>
    </ProjectReference>

But, it also contains:
    <Link>
    <AdditionalDependencies>..\DockPanel\Release\DockPanel.dll; ...</AdditionalDependencies>
    ...
    </Link>

The inclusion of DockPanel.dll in the AdditionalDependencies section is, I believe, causing Visual Studio to try to open it as a '.lib', and failing. I expected the generated .vcxproj to contain only the ProjectReference section for DockPanel, and not include it in AdditionalDependencies.

Can you confirm that this is a bug?

Thank you,
Phil

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

From bitminer at gmail.com  Thu Aug 16 12:18:15 2018
From: bitminer at gmail.com (Brian Davis)
Date: Thu, 16 Aug 2018 11:18:15 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
 <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
 <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>
Message-ID: <CADsa1k3eS-CQNUXWitAqiNujD5TJAEZMMC=1rR8fFHQwVuUsCQ@mail.gmail.com>

On Wed, Aug 15, 2018 at 11:58 AM, Robert Maynard <robert.maynard at kitware.com
> wrote:

> The MSVC / CUDA support recently has been very challenging to keep track
> of. In general CUDA will only support a single patch release of MSVC, and
> given how MSVC 2017 doesn't easily allow rollbacks and has a pretty
> aggressive update policy ( compared to older MSVC versions ) causes lots of
> pain. This in general has been a community wide MSVC+CUDA issue.
>
> CUDA 8 has zero support for VS2017 ( https://docs.nvidia.com/
> cuda/archive/8.0/cuda-installation-guide-microsoft-windows/index.html )
> CUDA 9.0 and 9.1 only supports VS 2017 15.0 (https://docs.nvidia.com/cuda/
> archive/9.0/cuda-installation-guide-microsoft-windows/index.html,
> https://docs.nvidia.com/cuda/archive/9.1/cuda-installation-
> guide-microsoft-windows/index.html)
> CUDA 9.2 only supports VS 2017 15.0 and 15.6
>
> When using MSVC 2017 and CUDA you will need to specify an explicit host
> side compiler with -T version=15.## including the minor version (
> https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).
>


sigh... of course (though be careful with the term does not and cannot and
zero support - I am a thinkin I could get CMake to support CUDA 8 in VS2017
- if I realy wanted to - I mean it's not realy VS/MSVC doing the compiling
is it?-rhetorical).  This is making the case for what I had to do in the
2.8 days (well also again when NVIDIA could not decide on where to put
their.... stuff in the file system and CMake was always one version or so
behind) and roll my own CMake cuda support... yes this happened... and it
could again.  Time to look back into my old svn tree.  sweet... kickin it
with svn again the good old days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/c086fcfe/attachment.html>

From smancill at jlab.org  Thu Aug 16 14:48:37 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Thu, 16 Aug 2018 15:48:37 -0300
Subject: [CMake] Printing "Found <package>..." message in config mode
In-Reply-To: <CALYSiH4r-D4qMMvi8UGP1bgp5PEBijcTi6dn21Tu9=Vweu8jgQ@mail.gmail.com>
References: <CAJPSwc3MncfeFEWE=M_KpfYQNx=srriv=OgJjTVxBR16sQUPRw@mail.gmail.com>
 <C15005C5-5F77-4A96-872B-7F8EF4579AC2@hendrik-sattler.de>
 <CAJPSwc3+uegziVR8O-TmHGBxRY_FDowCXE8XZy=zX088dwmNPw@mail.gmail.com>
 <CALYSiH4r-D4qMMvi8UGP1bgp5PEBijcTi6dn21Tu9=Vweu8jgQ@mail.gmail.com>
Message-ID: <CAJPSwc1zJ-0VvUZvnFpCWaeMjQ3Rtg1Tbomx5oKO-2HTzFXRfw@mail.gmail.com>

Thanks, Cyril

I did try find_package_handle_standard_args but it failed. It didn't occur
to me that I needed to set <package_CONFIG before.

Now it is much better.

El jue., 16 de ago. de 2018 a la(s) 09:24, Cyril Boucher (
cyril.boucher94260 at gmail.com) escribi?:

> Hi Sebasti?n,
>
> Your question got me thinking and I also figured that way of doing it
> works:
>
> set(<package>_CONFIG ${CMAKE_CURRENT_LIST_FILE})
> find_package_handle_standard_args(<package> CONFIG_MODE)
>
> This allows you to keep most of the nice logic inside
> FindPackageHandleStandardArgs.
>
> Best regards,
> Cyril
>
> 2018-08-15 22:13 GMT+02:00 Sebasti?n Mancilla <smancill at jlab.org>:
>
>> Ah, I see that FIND_PACKAGE_HANDLE_STANDARD_ARGS prints
>>
>>    -- Find Foo: <path to FooConfig.cmake> (found version "<version>")
>>
>> I guess my function is not necessary, I can just put inside
>> FooConfig.cmake
>>
>>     find_package_message(Foo
>>       "Found Foo: ${CMAKE_CURRENT_LIST_FILE} (found version
>> \"@PACKAGE_VERSION@\")"
>>       "[${CMAKE_CURRENT_LIST_FILE}][@PACKAGE_VERSION@]")
>>
>>
>> El mar., 14 de ago. de 2018 a la(s) 19:36, Hendrik Sattler (
>> post at hendrik-sattler.de) escribi?:
>>
>>>
>>>
>>> Am 14. August 2018 22:08:36 MESZ schrieb "Sebasti?n Mancilla" <
>>> smancill at jlab.org>:
>>> >Normally, find modules call FIND_PACKAGE_HANDLE_STANDARD_ARGS, which in
>>> >turn calls FIND_PACKAGE_MESSAGE, to print a nice message about the
>>> >location
>>> >and version of the dependency.
>>>
>>> You can do that with FIND_PACKAGE_HANDLE_STANDARD_ARGS, just use module
>>> name and CONFIG_MODE as arguments.
>>>
>>> HS
>>> --
>>>
>>> Powered by www.kitware.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=phETEp6GuEap1tbRAb9bSduQrhEpdgeHQyC_5IzSJ3k&e=>
>>>
>>> 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=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=RJEEiZ1k-XIjXM_90_6kyZ5FMVIYsSAiyQRThYB3iJ8&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_help_support.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=LqUR8QOw8X5ya0FRtvJ3J9e40LyNK-gydGXOeaM80Ps&e=
>>> CMake Consulting:
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=N5TtfB9fCMuIe6ZcnAzVHEk5w4MnGzNdZ8hI-zyiU5Y&e=
>>> CMake Training Courses:
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=aBTzKuF0iyTKifZQ6madT0vT189WJsgYDDf8jDL_JxI&e=
>>>
>>> Visit other Kitware open-source projects at
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=Wu5CbQmwVaf6uE5Dp9OK_EASEZ6WS16W0hVEXN_3BAo&e=
>>>
>>> Follow this link to subscribe/unsubscribe:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=vNaw4PX_cjIs-mDa1mqBspuYYh8zccYAIC84tyoB0oA&s=QViykHUMgtj8XqForeqtw7j16bUM3hAp3JTzSse90b8&e=
>>>
>>
>>
>> --
>> Sebastian Mancilla Matta
>> CCTVal, UTFSM
>> Valpara?so, Chile
>>
>> --
>>
>> Powered by www.kitware.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=phETEp6GuEap1tbRAb9bSduQrhEpdgeHQyC_5IzSJ3k&e=>
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=H3T2l5bnM_hkcutx9EhoMYQ7u5sZ6crXyJVPqFdGK4Y&e=>
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=zwpFrBiEjfR7tUSgMW4TkgfIRoFpxaeNyyL8s16dMog&e=>
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=mwkHdq7RmuniRx_jjK9zRWBw4DDyjeClsgTAUVPIZeQ&e=>
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=jZkM0UUXLX67asxN3i1OARsPm2m_2evYMVyOOjPfVZo&e=>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=kON9K8r17vpuikT7ovaFvNEY3gCgHiGWOw-4j5muzjo&e=>
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=kUFvtJfJYSaKOycRuDd7Jlb2EeJcX38J2oKfx3DdrVw&s=wcLntce93Bzhp7583x4IZorEkbev8foF9n9C-cpQXOM&e=>
>>
>>
>

-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/33d65108/attachment-0001.html>

From d3ck0r at gmail.com  Thu Aug 16 15:31:21 2018
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 16 Aug 2018 12:31:21 -0700
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k3eS-CQNUXWitAqiNujD5TJAEZMMC=1rR8fFHQwVuUsCQ@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
 <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
 <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>
 <CADsa1k3eS-CQNUXWitAqiNujD5TJAEZMMC=1rR8fFHQwVuUsCQ@mail.gmail.com>
Message-ID: <CAA2GJqXGkVHC+Utc-GqwD1kJ2tHx0hepYURaEHNAxDL-78XO4A@mail.gmail.com>

On Thu, Aug 16, 2018 at 9:18 AM Brian Davis <bitminer at gmail.com> wrote:

>
>
> On Wed, Aug 15, 2018 at 11:58 AM, Robert Maynard <
> robert.maynard at kitware.com> wrote:
>
>> The MSVC / CUDA support recently has been very challenging to keep track
>> of. In general CUDA will only support a single patch release of MSVC, and
>> given how MSVC 2017 doesn't easily allow rollbacks and has a pretty
>> aggressive update policy ( compared to older MSVC versions ) causes lots of
>> pain. This in general has been a community wide MSVC+CUDA issue.
>>
>> CUDA 8 has zero support for VS2017 (
>> https://docs.nvidia.com/cuda/archive/8.0/cuda-installation-guide-microsoft-windows/index.html
>> )
>> CUDA 9.0 and 9.1 only supports VS 2017 15.0 (
>> https://docs.nvidia.com/cuda/archive/9.0/cuda-installation-guide-microsoft-windows/index.html,
>>
>> https://docs.nvidia.com/cuda/archive/9.1/cuda-installation-guide-microsoft-windows/index.html
>> )
>> CUDA 9.2 only supports VS 2017 15.0 and 15.6
>>
>> When using MSVC 2017 and CUDA you will need to specify an explicit host
>> side compiler with -T version=15.## including the minor version (
>> https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).
>>
>
>
> Can't that be set by passing the toolset with a -T ? like -T "v120_xp"
or -T "v120"

This is an article about side-by-side toolsets
https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/
but it looks like it only goes back to 2015...

(and sorry to ramble a bit)
Slightly off topic; but I ran into a feature of the new optimizer that
shuffles commands.... I had a critical section lock that it ended up
clearing the locking bit, before releasing the other value; can defiantly
see lots of code breaking from that; firefox wants to only build with 15.6
but community is only 15.5 or 15.8 preview...  (I fixed the codea dding
'volatile , and referencing the other value with a computation that
resulted with 0 instead.)

Sometimes code is in a certain order for specific reasons :) Sometims, it
can be shuffled ....   (a=1;b=2;) ~~ (b=2;a=1) (same result different order)




> sigh... of course (though be careful with the term does not and cannot and
> zero support - I am a thinkin I could get CMake to support CUDA 8 in VS2017
> - if I realy wanted to - I mean it's not realy VS/MSVC doing the compiling
> is it?-rhetorical).  This is making the case for what I had to do in the
> 2.8 days (well also again when NVIDIA could not decide on where to put
> their.... stuff in the file system and CMake was always one version or so
> behind) and roll my own CMake cuda support... yes this happened... and it
> could again.  Time to look back into my old svn tree.  sweet... kickin it
> with svn again the good old days.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/776bd218/attachment.html>

From robert.maynard at kitware.com  Thu Aug 16 15:54:54 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 16 Aug 2018 15:54:54 -0400
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CAA2GJqXGkVHC+Utc-GqwD1kJ2tHx0hepYURaEHNAxDL-78XO4A@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
 <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
 <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>
 <CADsa1k3eS-CQNUXWitAqiNujD5TJAEZMMC=1rR8fFHQwVuUsCQ@mail.gmail.com>
 <CAA2GJqXGkVHC+Utc-GqwD1kJ2tHx0hepYURaEHNAxDL-78XO4A@mail.gmail.com>
Message-ID: <CAFzjYVpdQ7mzCtLSrhXC-azLy4A5dsQTLZK8MKB=3gbSX2qR+g@mail.gmail.com>

> Can't that be set by passing the toolset with a -T

That is what I was trying to say with my last sentence. You will need
to use CMake 3.12 to have support for specifying the minor toolset
version though.
On Thu, Aug 16, 2018 at 3:31 PM J Decker <d3ck0r at gmail.com> wrote:
>
>
> On Thu, Aug 16, 2018 at 9:18 AM Brian Davis <bitminer at gmail.com> wrote:
>>
>>
>>
>> On Wed, Aug 15, 2018 at 11:58 AM, Robert Maynard <robert.maynard at kitware.com> wrote:
>>>
>>> The MSVC / CUDA support recently has been very challenging to keep track of. In general CUDA will only support a single patch release of MSVC, and given how MSVC 2017 doesn't easily allow rollbacks and has a pretty aggressive update policy ( compared to older MSVC versions ) causes lots of pain. This in general has been a community wide MSVC+CUDA issue.
>>>
>>> CUDA 8 has zero support for VS2017 ( https://docs.nvidia.com/cuda/archive/8.0/cuda-installation-guide-microsoft-windows/index.html )
>>> CUDA 9.0 and 9.1 only supports VS 2017 15.0 (https://docs.nvidia.com/cuda/archive/9.0/cuda-installation-guide-microsoft-windows/index.html, https://docs.nvidia.com/cuda/archive/9.1/cuda-installation-guide-microsoft-windows/index.html)
>>> CUDA 9.2 only supports VS 2017 15.0 and 15.6
>>>
>>> When using MSVC 2017 and CUDA you will need to specify an explicit host side compiler with -T version=15.## including the minor version ( https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).
>>
>>
>>
> Can't that be set by passing the toolset with a -T ? like -T "v120_xp"    or -T "v120"
>
> This is an article about side-by-side toolsets https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/  but it looks like it only goes back to 2015...
>
> (and sorry to ramble a bit)
> Slightly off topic; but I ran into a feature of the new optimizer that shuffles commands.... I had a critical section lock that it ended up clearing the locking bit, before releasing the other value; can defiantly see lots of code breaking from that; firefox wants to only build with 15.6 but community is only 15.5 or 15.8 preview...  (I fixed the codea dding 'volatile , and referencing the other value with a computation that resulted with 0 instead.)
>
> Sometimes code is in a certain order for specific reasons :) Sometims, it can be shuffled ....   (a=1;b=2;) ~~ (b=2;a=1) (same result different order)
>
>
>
>>
>> sigh... of course (though be careful with the term does not and cannot and zero support - I am a thinkin I could get CMake to support CUDA 8 in VS2017 - if I realy wanted to - I mean it's not realy VS/MSVC doing the compiling is it?-rhetorical).  This is making the case for what I had to do in the 2.8 days (well also again when NVIDIA could not decide on where to put their.... stuff in the file system and CMake was always one version or so behind) and roll my own CMake cuda support... yes this happened... and it could again.  Time to look back into my old svn tree.  sweet... kickin it with svn again the good old days.
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From craig.scott at crascit.com  Thu Aug 16 17:46:36 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 17 Aug 2018 07:46:36 +1000
Subject: [CMake] Project referring to CSharp project generates
 incorrectly?
In-Reply-To: <1534435157010.19879@Engility.com>
References: <1534280553005.48536@Engility.com>
 <1534435157010.19879@Engility.com>
Message-ID: <CA+dygYmOacqRa9jpHTO8Ta9FTQY9ZHoSUHLi1hY58xG-h3pCEg@mail.gmail.com>

Philip, thanks for the concise description of the problem. Would you be
willing to report this in CMake's gitlab as an issue so we can better track
it and refer to it in merge requests, etc.? You can report a new issue here:

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

Thanks


On Fri, Aug 17, 2018 at 1:59 AM, Tessier, Philip @ Engility via CMake <
cmake at cmake.org> wrote:

> All,
>
> Thank you in advance,
>
>
> I'm an experienced CMake user, in the C++ realm. I'm presently working
> outside that realm, porting a 200-project solution from Visual Studio
> (.vcxproj, .csproj) files to CMake. I'm very pleased that CMake has adopted
> CSharp! Thank you!
>
>
> I seem to have uncovered a bug where one CSharp project depends on another.
>
>
> The first CMakeLists.txt:
> cmake_minimum_required(VERSION 3.12)
> project(DockPanel CSharp)
> ...
> add_library(DockPanel MODULE ${SOURCES_files_Compile} ${SOURCES_files_
> EmbeddedResource})
> set_property(TARGET DockPanel APPEND PROPERTY VS_DOTNET_REFERENCES
> "System")
>
>
> The second CMakeLists.txt:
> cmake_minimum_required(VERSION 3.12)
> project(CSharpFramework CSharp)
> ...
> add_library(CSharpFramework MODULE ${SOURCES_files_Compile}
> ${SOURCES_files_EmbeddedResource})
> target_link_libraries(CSharpFramework PUBLIC $<$<CONFIG:Debug>:DockPanel>
>   )
> set_property(TARGET CSharpFramework APPEND PROPERTY VS_DOTNET_REFERENCES
> "System")
>
> (I haven't shown everything, as I'm extracting these from a huge system,
> but I can elaborate if necessary...)
>
> CMake configures and generates (to VS2015) without error. Things proceed
> as expected until it's time to link the second project.
> Then, I get:
> ..\DockPanel\Debug\DockPanel.dll : fatal error LNK1107: invalid or
> corrupt file: cannot read at 0x358
>
> A bit of investigative work shows that the generated
> CSharpFramework.vcxproj contains, as expected:
>     <ProjectReference Include="D:\Havok\hk2014_2_5_
> Simulation\Source\build-x64-msvc-v140-\Vision\Editor\
> vForge\DockPanel\DockPanel.vcxproj">
>       <Project>{DCCB7EE9-726F-3D42-A673-D6CCB4EF6675}</Project>
>       <Name>DockPanel</Name>
>     </ProjectReference>
>
> But, it also contains:
>     <Link>
>     <AdditionalDependencies>..\DockPanel\Release\DockPanel.dll;
> ...</AdditionalDependencies>
>     ...
>     </Link>
>
> The inclusion of DockPanel.dll in the AdditionalDependencies section is, I
> believe, causing Visual Studio to try to open it as a '.lib', and failing.
> I expected the generated .vcxproj to contain only the ProjectReference
> section for DockPanel, and not include it in AdditionalDependencies.
>
> Can you confirm that this is a bug?
>
> Thank you,
> Phil
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180817/cc37dfc9/attachment-0001.html>

From calebwherry at gmail.com  Thu Aug 16 18:55:24 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Thu, 16 Aug 2018 18:55:24 -0400
Subject: [CMake] Project referring to CSharp project generates
 incorrectly?
In-Reply-To: <CA+dygYmOacqRa9jpHTO8Ta9FTQY9ZHoSUHLi1hY58xG-h3pCEg@mail.gmail.com>
References: <1534280553005.48536@Engility.com>
 <1534435157010.19879@Engility.com>
 <CA+dygYmOacqRa9jpHTO8Ta9FTQY9ZHoSUHLi1hY58xG-h3pCEg@mail.gmail.com>
Message-ID: <CAJxY6XpY+KybvjJVA+jZcauk_4FD68TJ47499LUW8FqHi8dbUw@mail.gmail.com>

FWIW: I do almost this exact thing currently and have no issues (even mix
in Managed C++ wrappers around naive code). The only difference is that I
don?t compile any C# modules, only Shared libs. Not sure if that could be a
problem or not.

I?m using CMake 3.11 and VS 2015.

-Caleb

On Thu, Aug 16, 2018 at 5:46 PM Craig Scott <craig.scott at crascit.com> wrote:

> Philip, thanks for the concise description of the problem. Would you be
> willing to report this in CMake's gitlab as an issue so we can better track
> it and refer to it in merge requests, etc.? You can report a new issue here:
>
> https://gitlab.kitware.com/cmake/cmake/issues/new
>
> Thanks
>
>
> On Fri, Aug 17, 2018 at 1:59 AM, Tessier, Philip @ Engility via CMake <
> cmake at cmake.org> wrote:
>
>> All,
>>
>> Thank you in advance,
>>
>>
>> I'm an experienced CMake user, in the C++ realm. I'm presently working
>> outside that realm, porting a 200-project solution from Visual Studio
>> (.vcxproj, .csproj) files to CMake. I'm very pleased that CMake has adopted
>> CSharp! Thank you!
>>
>>
>> I seem to have uncovered a bug where one CSharp project depends on
>> another.
>>
>>
>> The first CMakeLists.txt:
>> cmake_minimum_required(VERSION 3.12)
>> project(DockPanel CSharp)
>> ...
>> add_library(DockPanel MODULE ${SOURCES_files_Compile}
>> ${SOURCES_files_EmbeddedResource})
>> set_property(TARGET DockPanel APPEND PROPERTY VS_DOTNET_REFERENCES
>> "System")
>>
>>
>> The second CMakeLists.txt:
>> cmake_minimum_required(VERSION 3.12)
>> project(CSharpFramework CSharp)
>> ...
>> add_library(CSharpFramework MODULE ${SOURCES_files_Compile}
>> ${SOURCES_files_EmbeddedResource})
>> target_link_libraries(CSharpFramework PUBLIC $<$<CONFIG:Debug>:DockPanel>
>>   )
>> set_property(TARGET CSharpFramework APPEND PROPERTY VS_DOTNET_REFERENCES
>> "System")
>>
>> (I haven't shown everything, as I'm extracting these from a huge system,
>> but I can elaborate if necessary...)
>>
>> CMake configures and generates (to VS2015) without error. Things proceed
>> as expected until it's time to link the second project.
>> Then, I get:
>> ..\DockPanel\Debug\DockPanel.dll : fatal error LNK1107: invalid or
>> corrupt file: cannot read at 0x358
>>
>> A bit of investigative work shows that the generated
>> CSharpFramework.vcxproj contains, as expected:
>>     <ProjectReference
>> Include="D:\Havok\hk2014_2_5_Simulation\Source\build-x64-msvc-v140-\Vision\Editor\vForge\DockPanel\DockPanel.vcxproj">
>>       <Project>{DCCB7EE9-726F-3D42-A673-D6CCB4EF6675}</Project>
>>       <Name>DockPanel</Name>
>>     </ProjectReference>
>>
>> But, it also contains:
>>     <Link>
>>     <AdditionalDependencies>..\DockPanel\Release\DockPanel.dll;
>> ...</AdditionalDependencies>
>>     ...
>>     </Link>
>>
>> The inclusion of DockPanel.dll in the AdditionalDependencies section is,
>> I believe, causing Visual Studio to try to open it as a '.lib', and
>> failing. I expected the generated .vcxproj to contain only the
>> ProjectReference section for DockPanel, and not include it in
>> AdditionalDependencies.
>>
>> Can you confirm that this is a bug?
>>
>> Thank you,
>> Phil
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
> <https://crascit.com/professional-cmake/>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/047cc2e9/attachment.html>

From calebwherry at gmail.com  Thu Aug 16 22:53:37 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Thu, 16 Aug 2018 22:53:37 -0400
Subject: [CMake] Project referring to CSharp project generates
 incorrectly?
In-Reply-To: <CAJxY6XpY+KybvjJVA+jZcauk_4FD68TJ47499LUW8FqHi8dbUw@mail.gmail.com>
References: <1534280553005.48536@Engility.com>
 <1534435157010.19879@Engility.com>
 <CA+dygYmOacqRa9jpHTO8Ta9FTQY9ZHoSUHLi1hY58xG-h3pCEg@mail.gmail.com>
 <CAJxY6XpY+KybvjJVA+jZcauk_4FD68TJ47499LUW8FqHi8dbUw@mail.gmail.com>
Message-ID: <CAJxY6Xo3OonNG1zwvESrBQyZoYUrzNLVBOCpE5hXadFR=TaiWQ@mail.gmail.com>

Also, this ticket seems to be very similar to what you are seeing if you
dig down a bit:

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

But again, I do this exact same thing with Shared instead of Module
libraries and it works. I would think that modules shouldn?t even be
allowed for C# targets as that is a specific notion to open native libs
with dlopen(). That ticket even hints at only allowing specific target
types, possible module was just overlooked?

-Caleb

On Thu, Aug 16, 2018 at 6:55 PM J. Caleb Wherry <calebwherry at gmail.com>
wrote:

> FWIW: I do almost this exact thing currently and have no issues (even mix
> in Managed C++ wrappers around naive code). The only difference is that I
> don?t compile any C# modules, only Shared libs. Not sure if that could be a
> problem or not.
>
> I?m using CMake 3.11 and VS 2015.
>
> -Caleb
>
> On Thu, Aug 16, 2018 at 5:46 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
>> Philip, thanks for the concise description of the problem. Would you be
>> willing to report this in CMake's gitlab as an issue so we can better track
>> it and refer to it in merge requests, etc.? You can report a new issue here:
>>
>> https://gitlab.kitware.com/cmake/cmake/issues/new
>>
>> Thanks
>>
>>
>> On Fri, Aug 17, 2018 at 1:59 AM, Tessier, Philip @ Engility via CMake <
>> cmake at cmake.org> wrote:
>>
>>> All,
>>>
>>> Thank you in advance,
>>>
>>>
>>> I'm an experienced CMake user, in the C++ realm. I'm presently working
>>> outside that realm, porting a 200-project solution from Visual Studio
>>> (.vcxproj, .csproj) files to CMake. I'm very pleased that CMake has adopted
>>> CSharp! Thank you!
>>>
>>>
>>> I seem to have uncovered a bug where one CSharp project depends on
>>> another.
>>>
>>>
>>> The first CMakeLists.txt:
>>> cmake_minimum_required(VERSION 3.12)
>>> project(DockPanel CSharp)
>>> ...
>>> add_library(DockPanel MODULE ${SOURCES_files_Compile}
>>> ${SOURCES_files_EmbeddedResource})
>>> set_property(TARGET DockPanel APPEND PROPERTY VS_DOTNET_REFERENCES
>>> "System")
>>>
>>>
>>> The second CMakeLists.txt:
>>> cmake_minimum_required(VERSION 3.12)
>>> project(CSharpFramework CSharp)
>>> ...
>>> add_library(CSharpFramework MODULE ${SOURCES_files_Compile}
>>> ${SOURCES_files_EmbeddedResource})
>>> target_link_libraries(CSharpFramework PUBLIC
>>> $<$<CONFIG:Debug>:DockPanel>  )
>>> set_property(TARGET CSharpFramework APPEND PROPERTY VS_DOTNET_REFERENCES
>>> "System")
>>>
>>> (I haven't shown everything, as I'm extracting these from a huge system,
>>> but I can elaborate if necessary...)
>>>
>>> CMake configures and generates (to VS2015) without error. Things proceed
>>> as expected until it's time to link the second project.
>>> Then, I get:
>>> ..\DockPanel\Debug\DockPanel.dll : fatal error LNK1107: invalid or
>>> corrupt file: cannot read at 0x358
>>>
>>> A bit of investigative work shows that the generated
>>> CSharpFramework.vcxproj contains, as expected:
>>>     <ProjectReference
>>> Include="D:\Havok\hk2014_2_5_Simulation\Source\build-x64-msvc-v140-\Vision\Editor\vForge\DockPanel\DockPanel.vcxproj">
>>>       <Project>{DCCB7EE9-726F-3D42-A673-D6CCB4EF6675}</Project>
>>>       <Name>DockPanel</Name>
>>>     </ProjectReference>
>>>
>>> But, it also contains:
>>>     <Link>
>>>     <AdditionalDependencies>..\DockPanel\Release\DockPanel.dll;
>>> ...</AdditionalDependencies>
>>>     ...
>>>     </Link>
>>>
>>> The inclusion of DockPanel.dll in the AdditionalDependencies section is,
>>> I believe, causing Visual Studio to try to open it as a '.lib', and
>>> failing. I expected the generated .vcxproj to contain only the
>>> ProjectReference section for DockPanel, and not include it in
>>> AdditionalDependencies.
>>>
>>> Can you confirm that this is a bug?
>>>
>>> Thank you,
>>> Phil
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>> New book released: Professional CMake: A Practical Guide
>> <https://crascit.com/professional-cmake/>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
> --
> Sent from my iPhone 4s
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180816/4cd23321/attachment-0001.html>

From ian.james.cullen at gmail.com  Fri Aug 17 07:36:52 2018
From: ian.james.cullen at gmail.com (Ian Cullen)
Date: Fri, 17 Aug 2018 12:36:52 +0100
Subject: [CMake] Expected behaviour of #cmakedefine
In-Reply-To: <CAJxY6XoXcKbQUbsgOMt=XkGA9f-Txo+3pz52PibE56oE2UXXDQ@mail.gmail.com>
References: <395a1a1e-730d-212e-227e-adb6c31756ea@gmail.com>
 <CAJxY6XoXcKbQUbsgOMt=XkGA9f-Txo+3pz52PibE56oE2UXXDQ@mail.gmail.com>
Message-ID: <fb3b622b-8a40-8071-dd30-d9d21af03eaa@gmail.com>

Agreed, version numbers will never not be set so #define is the better 
choice in this case. However this seems like an easy thing for users to 
trip-up on, particularly as only #cmakedefine is used in the 
configure_file() manual page.

Perhaps an additional example, or an INFO/WARNING section in the manual 
to highlight this 'issue'?


On 15/08/2018 13:56, J. Caleb Wherry wrote:
> I suppose it all depends on if there are situations where you don?t 
> want those variables set? To me, it doesn?t make sense to ever not 
> have version numbers set so I would use #define.
>
> -Caleb
>
> On Wed, Aug 15, 2018 at 8:32 AM Ian Cullen <ian.james.cullen at gmail.com 
> <mailto:ian.james.cullen at gmail.com>> wrote:
>
>     Hi,
>
>     I'm trying to create a header file containing version number
>     details but
>     am not sure if the following behaviour is expected or a bug.
>
>     Simplified example has 2 files
>
>     ==> CMakeLists.txt <==
>     cmake_minimum_required(VERSION 3.11)
>     project (
>     ?? VersionTest
>     ?? VERSION 1.0.4
>     ?? )
>
>     configure_file (
>     ?? "${PROJECT_SOURCE_DIR}/config.h.in <http://config.h.in>"
>     ?? "${PROJECT_BINARY_DIR}/config.h"
>     ?? @ONLY
>     ?? )
>
>     ==> config.h.in <http://config.h.in> <==
>     #cmakedefine VersionTest_VERSION_MAJOR @VersionTest_VERSION_MAJOR@
>     #cmakedefine VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
>     #define VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
>
>
>     Running cmake creates the output file as required but it has the
>     following contents
>
>     ==> config.h <==
>     #define VersionTest_VERSION_MAJOR 1
>     /* #undef VersionTest_VERSION_MINOR */
>     #define VersionTest_VERSION_MINOR 0
>
>
>     Looking at the manual
>     (https://cmake.org/cmake/help/v3.12/command/configure_file.html),
>     this
>     appears to be because the number '0' is considered false by the if()
>     command, however '0' is valid within a version number, so perhaps
>     should
>     not be considered false in this context.
>
>     Is this a known issue? Is it recommended to use #define rather than
>     #cmakedefine for these types of files?
>
>     Thanks
>
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>
> -- 
> Sent from my iPhone 4s

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

From bitminer at gmail.com  Fri Aug 17 12:05:01 2018
From: bitminer at gmail.com (Brian Davis)
Date: Fri, 17 Aug 2018 11:05:01 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CAFzjYVpdQ7mzCtLSrhXC-azLy4A5dsQTLZK8MKB=3gbSX2qR+g@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
 <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
 <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>
 <CADsa1k3eS-CQNUXWitAqiNujD5TJAEZMMC=1rR8fFHQwVuUsCQ@mail.gmail.com>
 <CAA2GJqXGkVHC+Utc-GqwD1kJ2tHx0hepYURaEHNAxDL-78XO4A@mail.gmail.com>
 <CAFzjYVpdQ7mzCtLSrhXC-azLy4A5dsQTLZK8MKB=3gbSX2qR+g@mail.gmail.com>
Message-ID: <CADsa1k1r0TbfRL3+owpJr2faJeWzet19UOxwRwe_0tc3d17X0w@mail.gmail.com>

> > Can't that be set by passing the toolset with a -T
>
> That is what I was trying to say with my last sentence. You will need
> to use CMake 3.12 to have support for specifying the minor toolset
> version though.
>




> >>>
> >>> The MSVC / CUDA support recently has been very challenging to keep
> track of. In general CUDA will only support a single patch release of MSVC,
> and given how MSVC 2017 doesn't easily allow rollbacks and has a pretty
> aggressive update policy ( compared to older MSVC versions ) causes lots of
> pain. This in general has been a community wide MSVC+CUDA issue.
> >>>
> >>> CUDA 8 has zero support for VS2017 ( https://docs.nvidia.com/cuda/
> archive/8.0/cuda-installation-guide-microsoft-windows/index.html )
> >>> CUDA 9.0 and 9.1 only supports VS 2017 15.0 (
> https://docs.nvidia.com/cuda/archive/9.0/cuda-installation-
> guide-microsoft-windows/index.html, https://docs.nvidia.com/cuda/
> archive/9.1/cuda-installation-guide-microsoft-windows/index.html)
> >>> CUDA 9.2 only supports VS 2017 15.0 and 15.6
> >>>
> >>> When using MSVC 2017 and CUDA you will need to specify an explicit
> host side compiler with -T version=15.## including the minor version (
> https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).
> >>
>
> > Can't that be set by passing the toolset with a -T ? like -T "v120_xp"
>   or -T "v120"
> >
> > This is an article about side-by-side toolsets
> https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-
> side-minor-version-msvc-toolsets-in-visual-studio-2017/  but it looks
> like it only goes back to 2015...
>

Between https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-
side-minor-version-msvc-toolsets-in-visual-studio-2017/ ,
https://docs.nvidia.com/cuda/archive/8.0/cuda-installation-
guide-microsoft-windows/index.html and https://cmake.org/cmake/help/
v3.12/release/3.12.html#id3  I am wondering if MS, NVIDIA, and CMake can
get together and make a super secret decoder ring set (1 CMake, 1 MS, and 1
NVIDIA - imagine the street cred I would have on the internet superhighway
if I had that kind of bling) Bluetooth enabled so as to activate the MS's
stated "escape hatch" (their words not mine) I am working to install in my
bit mine so as I can get quick egress to that when needed.  Also MS might
consider Bluetooth enabled accessory (shock collar)  when decoder ring is
put into versions they rather not support as would alleviate the necessity
to review the "VS servicing guidelines".  Then if when the decoder rings
are set to all the correct versions and with their powers combined I could
compile an application.  Great reads all.

So how do I get this to work?

PROJECT(PROJECT_NAME CXX CUDA )


and then for 2017 and CUDA 9.0 at the toolset -T line in GUI:

cuda=9.0 v141 ???


My -Bv in test app outputs:

1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\CL.exe:
Version 19.14.26433.0
1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\c1.dll:
Version 19.14.26433.0
1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\c1xx.dll:
Version 19.14.26433.0
1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\c2.dll:
Version 19.14.26433.0
1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\link.exe:
Version 14.14.26433.0
1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\mspdb140.dll:
Version 14.14.26433.0
1> C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\1033\clui.dll:
Version 19.14.26433.0

which if I interpret correctly (sadly with out my decoder rings) is not in
https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/

as last entry is:

VS2017, version 15.5     v141 in VS; version 14.12     1912

Also from above

When using MSVC 2017 and CUDA you will need to specify an explicit host
> side compiler with -T version=15.## including the minor version (
> https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).
>


would that be:

version=19.14

so putting it all together at -T line:

cuda=9.0 v141 version=19.14


?

Can we just skip to the future where we are defining compile settings in
genetic code sequences?

GCUACGGAGCUUCA


This is becoming a real monster anyway we may all want to just skip ahead
to the punchline.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180817/72c11bd4/attachment.html>

From cfsworks at gmail.com  Fri Aug 17 13:18:20 2018
From: cfsworks at gmail.com (Sam Edwards)
Date: Fri, 17 Aug 2018 11:18:20 -0600
Subject: [CMake] Best practice for configuration-dependent defaults?
Message-ID: <CAH5Ym4gVyTkPR+AD3Gat=O6BkCb1_PSqYiecx1BbAdteJFrReg@mail.gmail.com>

Hi all!

I have a project with some options that have different defaults depending
on the configuration used to build the project. For example, support for a
certain (easy to support, but relatively uncommon) file format should be on
by default, except when building in the MinSizeRel configuration. Or
inclusion of a certain optional troubleshooting feature should be on by
default only when building for Debug, and should default to off in all
other configurations.

For single-configuration generators, this is pretty easy: I just look at
the CMAKE_BUILD_TYPE variable and switch the option() defaults depending on
the selected build type, then generate my config.h once.

I'm trying to support multi-configuration now. My current plan is to
generate one config.h per build configuration (e.g. include/Debug/config.h,
include/MinSizeRel/config.h, ...) so that the options which the user hasn't
explicitly set can have different per-configuration values depending on
their per-configuration defaults.

However, where I'm getting stuck is in changing the default for an option
and having that default take precedence when the user hasn't overridden the
option explicitly. I can't just do something like:
option(FOO "This is foo" ON)
message("FOO is ${FOO}")
option(FOO "This is foo" OFF)
message("FOO is ${FOO}")

...because the first option(FOO ...) sets it to ON when it sees it isn't in
cache and isn't selected by the user, so the second option(FOO ...) thinks
it's already been set explicitly. Unless there's some way of distinguishing
"ON because it's the default" from "ON because the user explicitly
requested it" while having everything still show up correctly in the GUI,
this won't work.

Is this really the best practice for what I'm trying to do, or is there a
better "CMake way" to do this? How do you folks solve this problem in your
own projects?

Thanks,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180817/b34e9262/attachment.html>

From bitminer at gmail.com  Sat Aug 18 11:56:16 2018
From: bitminer at gmail.com (Brian Davis)
Date: Sat, 18 Aug 2018 10:56:16 -0500
Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013
 after installing 2017... sigh.
In-Reply-To: <CADsa1k1r0TbfRL3+owpJr2faJeWzet19UOxwRwe_0tc3d17X0w@mail.gmail.com>
References: <CADsa1k1Ca-ZG8AB0Y3pUMyv7diQUbZLSH1tHo7tgMN7cYG2VKw@mail.gmail.com>
 <CAA2GJqXSV1SWsuEyjd3SaWWmRx41JCWJ5kPDEuPYW0aPez9vDg@mail.gmail.com>
 <CADsa1k0YEq8Un8jMzt6WiJZWAFL2Ke1ycbNxPGznGh-fJA-e0Q@mail.gmail.com>
 <CAFzjYVqpETwKJJSCn5xLJz=wcyXS7fZTb=ihLdmh-8uPUWqLGg@mail.gmail.com>
 <CADsa1k0wnDJow88BTbuWWaVG_2fSGqpL+Oh9ssE_KRU_kZDvng@mail.gmail.com>
 <CADsa1k34WW_3RBwdsxw2DqXg=Jcxw3weJ+fkZTbqVGUV+JDswA@mail.gmail.com>
 <CAFzjYVqDWV6X6bY7OMjQKot36tWSNpsHFcrRtYX6f9kpO_6H=w@mail.gmail.com>
 <CADsa1k3eS-CQNUXWitAqiNujD5TJAEZMMC=1rR8fFHQwVuUsCQ@mail.gmail.com>
 <CAA2GJqXGkVHC+Utc-GqwD1kJ2tHx0hepYURaEHNAxDL-78XO4A@mail.gmail.com>
 <CAFzjYVpdQ7mzCtLSrhXC-azLy4A5dsQTLZK8MKB=3gbSX2qR+g@mail.gmail.com>
 <CADsa1k1r0TbfRL3+owpJr2faJeWzet19UOxwRwe_0tc3d17X0w@mail.gmail.com>
Message-ID: <CADsa1k3vS92ZJW60LE5bFWE9LBuhu_EeQSX6hLMLiSx3P=QEQA@mail.gmail.com>

With CUDA 8.0 and 9.0 installed and Visual Stuido 2013 (and god only knows
what versions of 2017 updated up grades with whatever tools versions)


CMake -> Visual Studio 12 2013 Win64 -> Optional toolset to use (arguments
to -T -> cuda=8.0

The CXX compiler identification is MSVC 18.0.31101.0

The CUDA compiler identification is NVIDIA 8.0.60

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe -- works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v8.0/bin/nvcc.exe

Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v8.0/bin/nvcc.exe -- works

Detecting CUDA compiler ABI info

Detecting CUDA compiler ABI info - done

Found OpenGL: opengl32


So, ok finds CUDA 8.0 nvcc


CMake -> Visual Studio 15 2017 Win64 -> Optional toolset to use (arguments
to -T -> cuda=8.0

Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.

The CXX compiler identification is MSVC 19.15.26726.0

The CUDA compiler identification is unknown

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx86/x64/cl.exe

Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx86/x64/cl.exe --
works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.


Though I am pretty sure it's there


Directory of c:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin

08/15/2018 06:47 PM <DIR> .
08/15/2018 06:47 PM <DIR> ..
09/02/2017 08:45 AM 163,840 bin2c.exe
08/15/2018 06:46 PM <DIR> crt
07/10/2018 04:50 PM 60,549,120 cublas64_90.dll
09/02/2017 08:45 AM 347,136 cuda-memcheck.exe
09/02/2017 08:45 AM 3,930,112 cudafe++.exe
09/02/2017 08:45 AM 4,226,048 cudafe.exe
09/02/2017 08:46 AM 299,520 cudart32_90.dll
09/02/2017 08:46 AM 373,760 cudart64_90.dll
08/15/2018 10:07 AM 288,159,744 cudnn64_7.dll
09/02/2017 08:46 AM 131,197,952 cufft64_90.dll
09/02/2017 08:46 AM 199,680 cufftw64_90.dll
09/02/2017 08:46 AM 3,575,808 cuinj32_90.dll
09/02/2017 08:46 AM 4,495,360 cuinj64_90.dll
09/02/2017 08:45 AM 1,411,072 cuobjdump.exe
09/02/2017 08:46 AM 48,057,344 curand64_90.dll
09/02/2017 08:46 AM 75,222,016 cusolver64_90.dll
09/02/2017 08:46 AM 54,782,464 cusparse64_90.dll
09/02/2017 08:45 AM 246,784 fatbinary.exe
09/02/2017 08:46 AM 1,274,880 gpu-library-advisor.exe
09/02/2017 08:46 AM 205,824 nppc64_90.dll
09/02/2017 08:46 AM 9,744,384 nppial64_90.dll
09/02/2017 08:46 AM 3,953,664 nppicc64_90.dll
09/02/2017 08:46 AM 1,035,264 nppicom64_90.dll
09/02/2017 08:46 AM 7,291,392 nppidei64_90.dll
09/02/2017 08:46 AM 55,641,088 nppif64_90.dll
09/02/2017 08:46 AM 26,491,904 nppig64_90.dll
09/02/2017 08:46 AM 4,767,232 nppim64_90.dll
09/02/2017 08:46 AM 14,943,232 nppist64_90.dll
09/02/2017 08:46 AM 179,200 nppisu64_90.dll
09/02/2017 08:46 AM 2,629,120 nppitc64_90.dll
09/02/2017 08:46 AM 9,024,512 npps64_90.dll
07/10/2018 04:49 PM 241,664 nvblas64_90.dll
*09/02/2017 08:45 AM 325,632 nvcc.exe*
09/02/2017 08:45 AM 328 nvcc.profile
09/02/2017 08:45 AM 16,261,120 nvdisasm.exe
09/02/2017 08:46 AM 15,747,584 nvgraph64_90.dll
09/02/2017 08:45 AM 7,202,304 nvlink.exe
09/02/2017 08:45 AM 4,005,376 nvprof.exe
09/02/2017 08:45 AM 181,248 nvprune.exe
09/02/2017 08:46 AM 3,182,592 nvrtc-builtins64_90.dll
09/02/2017 08:46 AM 17,302,016 nvrtc64_90.dll
09/02/2017 08:46 AM 53 nvvp.bat
05/16/2018 04:16 PM 7,082,496 ptxas.exe
42 File(s) 885,951,869 bytes
3 Dir(s) 675,381,178,368 bytes free


Dare I ask/look to see how CMake finds nvcc these days?


Dare I ask the question: Is CMake compatible/does it work with Visual
Studio and CUDA anymore? Have we entered the days where CMake is always x^N
versions behind VS and CUDA?


Is there a test case in CMake I can run to check to see if it works with my
VS Version (2017 15.1, 15.2, 15.3, 15.4, 15.5 (from MS web link above) +++
granted I am now running after update 15.8.1) and CUDA 8.0, 9.0, 9,1.


Is there a CMake compatibility chart some where I can plug in my versions
on a x/y table to see if it sunk my battle ship?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180818/89442c82/attachment-0001.html>

From rafael at sizeofvoid.org  Sun Aug 19 03:52:37 2018
From: rafael at sizeofvoid.org (Rafael Sadowski)
Date: Sun, 19 Aug 2018 09:52:37 +0200
Subject: [CMake] target_link_libraries generates -llibXX.so.0 ld call
Message-ID: <20180819075237.hgxgm66hug47g5z5@kubus.openhome.sizeofvoid.org>

Hi CMake-users,

I always run into the same CMmke/ld(1) issue with some KDE
Applications[1] on OpenBSD.

For example artikulate-17.12.3.

artikulatesound library in libsound/src/CMakeLists.txt[2]
-----------------------------------
# enable exceptions for this library
kde_enable_exceptions()

set(sound_LIB_SRCS
    backendinterface.cpp
    capturedevicecontroller.cpp
    outputdevicecontroller.cpp
    capturebackendinterface.cpp
    outputbackendinterface.cpp
    libsound_debug.cpp
)

add_library(artikulatesound SHARED ${sound_LIB_SRCS})
generate_export_header(artikulatesound BASE_NAME libsound)

target_link_libraries(
    artikulatesound
    LINK_PUBLIC
        KF5::CoreAddons
        KF5::I18n
)
# internal library without any API or ABI guarantee
set(GENERIC_LIB_VERSION "0")
set(GENERIC_LIB_SOVERSION "0")
set_target_properties(
    artikulatesound PROPERTIES
    VERSION ${GENERIC_LIB_VERSION}
    SOVERSION ${GENERIC_LIB_SOVERSION}
)

install(
    TARGETS artikulatesound
    ${INSTALL_TARGETS_DEFAULT_ARGS}
)
-----------------------------------

artikulatesound is used in
libsound/src/qtgstreamerbackend/CMakeLists.txt[3]:
-----------------------------------
add_library(qtgstreamerbackend MODULE ${qtgstreamerbackend_SRCS})

target_link_libraries(
    qtgstreamerbackend
    LINK_PUBLIC
        artikulatesound
        KF5::CoreAddons
        ${QTGLIB_LIBRARIES}
        ${QTGLIB_LIBRARY}
        ${QTGSTREAMER_LIBRARIES}
)

install(TARGETS qtgstreamerbackend DESTINATION ${PLUGIN_INSTALL_DIR}/artikulate/libsound)
-----------------------------------

This causes the following issue:
-----------------------------------
FAILED: libsound/src/qtmultimediabackend/qtmultimediabackend.so
: && /usr/ports/pobj/artikulate-17.12.3/bin/c++ -fPIC -O2 -pipe -std=c++0x -fno-operator-names
-Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual
-Werror=return-type -Wvla -Wdate-time -fdiagnostics-color=always -fexceptions -DNDEBUG
-Wl,--fatal-warnings -Wl,--enable-new-dtags -shared -o libsound/src/qtmultimediabackend/qtmultimediabackend.so
libsound/src/qtmultimediabackend/CMakeFiles/qtmultimediabackend.dir/qtmultimediabackend.cpp.o 
libsound/src/qtmultimediabackend/CMakeFiles/qtmultimediabackend.dir/qtmultimediacapturebackend.cpp.o
libsound/src/qtmultimediabackend/CMakeFiles/qtmultimediabackend.dir/qtmultimediaoutputbackend.cpp.o
libsound/src/qtmultimediabackend/CMakeFiles/qtmultimediabackend.dir/
/libsound_debug.cpp.o libsound/src/qtmultimediabackend/CMakeFiles/qtmultimediabackend.dir/qtmultimediabackend_autogen/mocs_compilation.cpp.o
-L/usr/ports/pobj/artikulate-17.12.3/build-amd64/libsound/src  -L/usr/local/lib/qt5/.  -L/usr/local/lib 
-Wl,-rpath,/usr/ports/pobj/artikulate-17.12.3/build-amd64/libsound/src:/usr/local/lib/qt5/.:/usr/local/lib:/usr/X11R6/lib:
-llibartikulatesound.so.0 -lQt5Multimedia -lKF5CoreAddons -lKF5I18n -lQt5Network -lQt5Gui -lQt5Core
-Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib && :

/usr/bin/ld: cannot find -llibartikulatesound.so.0
-----------------------------------

I don't think it's an artikulate/KDE issue much more an OpenBSD+CMake
issue.

$ cmake --version
cmake version 3.10.2

$ ninja --version
1.8.2

$  dmesg| head
OpenBSD 6.4-beta (GENERIC.MP) #206: Sun Aug 12 22:55:59 MDT 2018
    deraadt at amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

I am grateful for any kind of help.

Rafael Sadowski

[1]: https://www.kde.org/announcements/announce-applications-18.08.0.php
[2]: https://github.com/KDE/artikulate/blob/master/libsound/src/CMakeLists.txt
[3]: https://github.com/KDE/artikulate/blob/master/libsound/src/qtgstreamerbackend/CMakeLists.txt

From damir_porobic at live.com  Sun Aug 19 09:16:40 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Sun, 19 Aug 2018 13:16:40 +0000
Subject: [CMake] Problem with creating shared library
In-Reply-To: <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>,
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
Message-ID: <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Thanks Sebasti?n for providing those links!


I've followed the second link that you've provided but somehow I'm still running into issue.


I've changed the directory structure to this:

- kImageAnnotator
    - cmake
        - kImageAnnotator-config.cmake.in
    - example
        - main.cpp
        - CMakeLists.txt
    - include
        - kImageAnnotator
            - KImageAnnotator.h     // the main api header
    - src
        - KImageAnnotator.cpp
        - "And all other .cpp and .h files"
        - CMakeLists.txt
    - CMakeLists.txt

src/CMakeList.txt looks like this:
add_library(kImageAnnotator ${kimageannotator_SRCS} ${CMAKE_SOURCE_DIR}/include/kImageAnnotator/KImageAnnotator.h)

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

option(BUILD_SHARED_LIBS "Build shared library" ON)
include(GenerateExportHeader)

generate_export_header(kImageAnnotator
        EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
        EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
        )

target_include_directories(kImageAnnotator
        PUBLIC
        $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
        $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
        $<INSTALL_INTERFACE:include>
        PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR}
        )

set_target_properties(kImageAnnotator PROPERTIES
        ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
        LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
        RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin
        )

find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)

find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n WidgetsAddons)

target_link_libraries(kImageAnnotator Qt5::Widgets KF5::CoreAddons KF5::I18n KF5::WidgetsAddons)

include(GNUInstallDirs)

install(TARGETS kImageAnnotator
        EXPORT kImageAnnotator-targets
        ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
        RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
        INCLUDES DESTINATION ${LIBLEGACY_INCLUDE_DIRS}
)

install(DIRECTORY ${CMAKE_SOURCE_DIR}/include/kImageAnnotator
        DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)

install(EXPORT kImageAnnotator-targets
        FILE kImageAnnotator-targets.cmake
        NAMESPACE kImageAnnotator::
        DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
)


include(CMakePackageConfigHelpers)

configure_package_config_file(
        ${CMAKE_SOURCE_DIR}/cmake/kImageAnnotator-config.cmake.in
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
        INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
)

write_basic_package_version_file(
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
        VERSION ${PROJECT_VERSION}
        COMPATIBILITY AnyNewerVersion
)

install(FILES
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
        DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
)

export(EXPORT kImageAnnotator-targets
        FILE ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-targets.cmake
        NAMESPACE kImageAnnotator::
)



kImageAnnotator-config.cmake.in looks like this:

include(CMakeFindDependencyMacro)

@PACKAGE_INIT@

# find_dependency(Threads)
find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)

find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n WidgetsAddons)

if(NOT TARGET kImageAnnotator::kImageAnnotator)
  include("${CMAKE_CURRENT_LIST_DIR}/kImageAnnotator-targets.cmake")
endif()



example/CMakeLists.txt looks like this:

add_executable(kImageAnnotator-example ${CMAKE_CURRENT_SOURCE_DIR}/main.cpp)

target_link_libraries(kImageAnnotator-example PRIVATE kImageAnnotator::kImageAnnotator)



And example/main.cpp looks like this:

#include <QApplication>
#include <kImageAnnotator/KImageAnnotator.h>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QPixmap pixmap(QSize(500, 500));
    pixmap.fill(QColor(Qt::darkGreen));
    auto kImageAnnotator = new KImageAnnotator(pixmap);
    kImageAnnotator->show();

    return app.exec();
}



Still I'm getting following error when trying to build kImageAnnotator-example:

Scanning dependencies of target kImageAnnotator-example
[ 98%] Building CXX object example/CMakeFiles/kImageAnnotator-example.dir/main.cpp.o
[ 98%] Building CXX object example/CMakeFiles/kImageAnnotator-example.dir/kImageAnnotator-example_autogen/mocs_compilation.cpp.o
[100%] Linking CXX executable kImageAnnotator-example
CMakeFiles/kImageAnnotator-example.dir/main.cpp.o: In function `main':
/home/dporobic/projects/kImageAnnotator/example/main.cpp:29: undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
collect2: error: ld returned 1 exit status
example/CMakeFiles/kImageAnnotator-example.dir/build.make:98: recipe for target 'example/kImageAnnotator-example' failed

Any idea what I'm doing wrong? It looks like the same issue that I was having earlier.


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org>
Sent: Wednesday, August 15, 2018 21:48
To: damir_porobic at live.com
Cc: cmake at cmake.org
Subject: Re: [CMake] Problem with creating shared library

You are mixing the config file and the targets file.

The config file is a template that you normally put in cmake/FooConfig.cmake.in<http://FooConfig.cmake.in>

You copy the template into the binary dir:

    include(CMakePackageConfigHelpers)

    set(INSTALL_CONFIGDIR lib/cmake/Foo)

    configure_package_config_file(
      "${CMAKE_CURRENT_LIST_DIR}/cmake/FooConfig.cmake.in<http://FooConfig.cmake.in>"
      "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
      INSTALL_DESTINATION ${INSTALL_CONFIGDIR}
    )

It is a good idea to create a version file:

    write_basic_package_version_file(
      "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
      VERSION ${PROJECT_VERSION}
      COMPATIBILITY SameMajorVersion
   )

And then install both:

    install(FILES
        "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
        "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
      DESTINATION ${INSTALL_CONFIGDIR}
      COMPONENT Devel
    )

For the targets is a different file. When you install the library you should use

    install(TARGETS Foo EXPORT FooTargets ...)

And then export and install the targets:

    # Into the build tree
    export(EXPORT FooTargets
      FILE "${CMAKE_CURRENT_BINARY_DIR}/FooTargets.cmake"
      NAMESPACE Foo::
    )

    # Into PREFIX
    install(EXPORT FooTargets
      FILE FooTargets.cmake
      NAMESPACE Foo::
      DESTINATION ${INSTALL_CONFIGDIR}
      COMPONENT Devel
    )

Finally, your template FooConfig.cmake.in<http://FooConfig.cmake.in> should look like this:

  include(CMakeFindDependencyMacro)

  @PACKAGE_INIT@

  # list your required dependencies here
  find_dependency(Threads)

  if(NOT TARGET Foo::Foo)
    include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake")
  endif()

All this is pretty much the same for any project. Here are the best links explaining it:

https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
http://unclejimbo.github.io/2018/06/08/Modern-CMake-for-Library-Developers/




El mi?., 15 de ago. de 2018 a la(s) 05:32, Damir Porobic (damir_porobic at live.com<mailto:damir_porobic at live.com>) escribi?:

Hi Folks,


I'm trying to write a shared library and run into an issue where I can't find any clues to where the problem is.

I have a project with following structure:


src/

    dir1/

        file1.h

        file1.cpp

    dir2/

        file2.h

        file2.cpp



Now I have this CMakeList:

cmake_minimum_required(VERSION 3.5)

project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)


...


add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons KF5::I18n KF5::WidgetsAddons)

target_include_directories(${PROJECT_NAME} PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)

set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION} SOVERSION 1)

set(kimageannotator_CONFIG ${PROJECT_NAME}Config)

install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
        ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})

install(EXPORT ${kimageannotator_CONFIG} DESTINATION share/${kimageannotator_CONFIG}/cmake)

export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)


In another test project, I add the library like this:
...
find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp Qt5::Widgets kImageAnnotator)


Now when I try to build my test project, I get this:

dporobic at linux ~/projects/testApp/build
$ cmake .. && make
-- Could not set up the appstream test. appstreamcli is missing.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dporobic/projects/testApp/build
[ 25%] Automatic moc for target testApp
[ 25%] Built target testApp_automoc
Scanning dependencies of target testApp
[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
[ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
[100%] Linking CXX executable testApp
CMakeFiles/testApp.dir/main.cpp.o: In function `main':
main.cpp:(.text+0x8e): undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
make[2]: *** [testApp] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all' failed
make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Any idea how I could/should troubleshoot such issue?

Thanks in advance!

Regards,
Damir



--

Powered by www.kitware.com<http://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=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=JJ5RqPyjdlGGc3fT-5nQQM-JcJzwjBZU6ciOQlmEJVs&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_help_support.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=vUHQvc_7Ovi_5BDjy3JYFOIvTmihTSFOQNndNSpMOnA&e=
CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=91AJA3BxTfHAvsi0mAzkszAyUUmE2xfwbLgN_fYvFO4&e=
CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=isQW6paMIqhUFaejOZ4qfUiSVwNiR1yxoQn4J91yb8o&e=

Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=ose8YVW10s6tWkujUCq162vyyipCdlw-MW93qUlqdGk&e=

Follow this link to subscribe/unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=KftR51q4EGgNERicS2QyHvzlrNaqb11IUwwbz1YTjVU&e=


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180819/b58691c1/attachment-0001.html>

From eric.noulard at gmail.com  Sun Aug 19 16:44:25 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Sun, 19 Aug 2018 22:44:25 +0200
Subject: [CMake] Problem with creating shared library
In-Reply-To: <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>

Hi Damir,

May be the issue has nothing to do with the way you build the exported
<>Config.cmake files.
Since may be some nasty detail slipped in, could you tell us if the project
is public.
It looks like this one:
https://github.com/DamirPorobic/kImageAnnotator

may be you can push a branch that contains the exact thing that fails on
your side and it may be easier to review the detail?

on the master of this repo there does not seem to have any "example" dir.

However you already have hand written header file:
https://github.com/DamirPorobic/kImageAnnotator/blob/master/src/gui/KImageAnnotator.h

which has the very same name as the "exported header you generate":
generate_export_header(kImageAnnotator
        EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
        EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
        )

so may be
KImageAnnotator::KImageAnnotator(QPixmap const&)
is exposed by the hand-written file and not by the generated one so
that your unit test links ok but your "example" does not ?

Did you check the content of the generated header file?








Le dim. 19 ao?t 2018 ? 15:17, Damir Porobic <damir_porobic at live.com> a
?crit :

> Thanks Sebasti?n for providing those links!
>
>
> I've followed the second link that you've provided but somehow I'm still
> running into issue.
>
>
> I've changed the directory structure to this:
>
> - kImageAnnotator
>     - cmake
>         - kImageAnnotator-config.cmake.in
>     - example
>         - main.cpp
>         - CMakeLists.txt
>     - include
>         - kImageAnnotator
>             - KImageAnnotator.h     // the main api header
>     - src
>         - KImageAnnotator.cpp
>         - "And all other .cpp and .h files"
>         - CMakeLists.txt
>     - CMakeLists.txt
>
> src/CMakeList.txt looks like this:
> add_library(kImageAnnotator ${kimageannotator_SRCS}
> ${CMAKE_SOURCE_DIR}/include/kImageAnnotator/KImageAnnotator.h)
>
> add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)
>
> option(BUILD_SHARED_LIBS "Build shared library" ON)
> include(GenerateExportHeader)
>
> generate_export_header(kImageAnnotator
>         EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
>         EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
>         )
>
> target_include_directories(kImageAnnotator
>         PUBLIC
>         $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
>         $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
>         $<INSTALL_INTERFACE:include>
>         PRIVATE
>         ${CMAKE_CURRENT_SOURCE_DIR}
>         )
>
> set_target_properties(kImageAnnotator PROPERTIES
>         ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
>         LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
>         RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin
>         )
>
> find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)
>
> find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n
> WidgetsAddons)
>
> target_link_libraries(kImageAnnotator Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> include(GNUInstallDirs)
>
> install(TARGETS kImageAnnotator
>         EXPORT kImageAnnotator-targets
>         ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
>         INCLUDES DESTINATION ${LIBLEGACY_INCLUDE_DIRS}
> )
>
> install(DIRECTORY ${CMAKE_SOURCE_DIR}/include/kImageAnnotator
>         DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> )
>
> install(EXPORT kImageAnnotator-targets
>         FILE kImageAnnotator-targets.cmake
>         NAMESPACE kImageAnnotator::
>         DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
> )
>
>
> include(CMakePackageConfigHelpers)
>
> configure_package_config_file(
>         ${CMAKE_SOURCE_DIR}/cmake/kImageAnnotator-config.cmake.in
>         ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
>         INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
> )
>
> write_basic_package_version_file(
>         ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
>         VERSION ${PROJECT_VERSION}
>         COMPATIBILITY AnyNewerVersion
> )
>
> install(FILES
>         ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
>         ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
>         DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
> )
>
> export(EXPORT kImageAnnotator-targets
>         FILE ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-targets.cmake
>         NAMESPACE kImageAnnotator::
> )
>
>
> kImageAnnotator-config.cmake.in looks like this:
>
> include(CMakeFindDependencyMacro)
>
> @PACKAGE_INIT@
>
> # find_dependency(Threads)
> find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)
>
> find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n
> WidgetsAddons)
>
> if(NOT TARGET kImageAnnotator::kImageAnnotator)
>   include("${CMAKE_CURRENT_LIST_DIR}/kImageAnnotator-targets.cmake")
> endif()
>
>
>
> example/CMakeLists.txt looks like this:
>
> add_executable(kImageAnnotator-example
> ${CMAKE_CURRENT_SOURCE_DIR}/main.cpp)
>
> target_link_libraries(kImageAnnotator-example PRIVATE
> kImageAnnotator::kImageAnnotator)
>
>
>
> And example/main.cpp looks like this:
>
> #include <QApplication>
> #include <kImageAnnotator/KImageAnnotator.h>
>
> int main(int argc, char **argv)
> {
>     QApplication app(argc, argv);
>     QPixmap pixmap(QSize(500, 500));
>     pixmap.fill(QColor(Qt::darkGreen));
>     auto kImageAnnotator = new KImageAnnotator(pixmap);
>     kImageAnnotator->show();
>
>     return app.exec();
> }
>
>
>
> Still I'm getting following error when trying to build
> kImageAnnotator-example:
>
> Scanning dependencies of target kImageAnnotator-example
> [ 98%] Building CXX object
> example/CMakeFiles/kImageAnnotator-example.dir/main.cpp.o
> [ 98%] Building CXX object
> example/CMakeFiles/kImageAnnotator-example.dir/kImageAnnotator-example_autogen/mocs_compilation.cpp.o
> [100%] Linking CXX executable kImageAnnotator-example
> CMakeFiles/kImageAnnotator-example.dir/main.cpp.o: In function `main':
> /home/dporobic/projects/kImageAnnotator/example/main.cpp:29: undefined
> reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
> collect2: error: ld returned 1 exit status
> example/CMakeFiles/kImageAnnotator-example.dir/build.make:98: recipe for
> target 'example/kImageAnnotator-example' failed
>
> Any idea what I'm doing wrong? It looks like the same issue that I was
> having earlier.
>
>
> ------------------------------
> *From:* Sebasti?n Mancilla <smancill at jlab.org>
> *Sent:* Wednesday, August 15, 2018 21:48
> *To:* damir_porobic at live.com
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Problem with creating shared library
>
> You are mixing the config file and the targets file.
>
> The config file is a template that you normally put in cmake/
> FooConfig.cmake.in
>
> You copy the template into the binary dir:
>
>     include(CMakePackageConfigHelpers)
>
>     set(INSTALL_CONFIGDIR lib/cmake/Foo)
>
>     configure_package_config_file(
>       "${CMAKE_CURRENT_LIST_DIR}/cmake/FooConfig.cmake.in"
>       "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
>       INSTALL_DESTINATION ${INSTALL_CONFIGDIR}
>     )
>
> It is a good idea to create a version file:
>
>     write_basic_package_version_file(
>       "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
>       VERSION ${PROJECT_VERSION}
>       COMPATIBILITY SameMajorVersion
>    )
>
> And then install both:
>
>     install(FILES
>         "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
>         "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
>       DESTINATION ${INSTALL_CONFIGDIR}
>       COMPONENT Devel
>     )
>
> For the targets is a different file. When you install the library you
> should use
>
>     install(TARGETS Foo EXPORT FooTargets ...)
>
> And then export and install the targets:
>
>     # Into the build tree
>     export(EXPORT FooTargets
>       FILE "${CMAKE_CURRENT_BINARY_DIR}/FooTargets.cmake"
>       NAMESPACE Foo::
>     )
>
>     # Into PREFIX
>     install(EXPORT FooTargets
>       FILE FooTargets.cmake
>       NAMESPACE Foo::
>       DESTINATION ${INSTALL_CONFIGDIR}
>       COMPONENT Devel
>     )
>
> Finally, your template FooConfig.cmake.in should look like this:
>
>   include(CMakeFindDependencyMacro)
>
>   @PACKAGE_INIT@
>
>   # list your required dependencies here
>   find_dependency(Threads)
>
>   if(NOT TARGET Foo::Foo)
>     include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake")
>   endif()
>
> All this is pretty much the same for any project. Here are the best links
> explaining it:
>
> https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
> http://unclejimbo.github.io/2018/06/08/Modern-CMake-for-Library-Developers/
>
>
>
>
> El mi?., 15 de ago. de 2018 a la(s) 05:32, Damir Porobic (
> damir_porobic at live.com) escribi?:
>
> Hi Folks,
>
>
> I'm trying to write a shared library and run into an issue where I can't
> find any clues to where the problem is.
>
> I have a project with following structure:
>
>
> src/
>
>     dir1/
>
>         file1.h
>
>         file1.cpp
>
>     dir2/
>
>         file2.h
>         file2.cpp
>
>
>
> Now I have this CMakeList:
>
> cmake_minimum_required(VERSION 3.5)
>
> project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)
>
> ...
>
>
> add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
> target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> target_include_directories(${PROJECT_NAME} PUBLIC
> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES VERSION
> ${PROJECT_VERSION} SOVERSION 1)
>
> set(kimageannotator_CONFIG ${PROJECT_NAME}Config)
>
> install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
>         ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
>         RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
> install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})
>
> install(EXPORT ${kimageannotator_CONFIG} DESTINATION
> share/${kimageannotator_CONFIG}/cmake)
>
> export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)
>
>
> In another test project, I add the library like this:
> ...
> find_package(kImageAnnotator REQUIRED)
>
> add_executable(testApp main.cpp)
> target_link_libraries(testApp Qt5::Widgets kImageAnnotator)
>
>
> Now when I try to build my test project, I get this:
>
> dporobic at linux ~/projects/testApp/build
> $ cmake .. && make
> -- Could not set up the appstream test. appstreamcli is missing.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/dporobic/projects/testApp/build
> [ 25%] Automatic moc for target testApp
> [ 25%] Built target testApp_automoc
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
> [ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
> [100%] Linking CXX executable testApp
> CMakeFiles/testApp.dir/main.cpp.o: In function `main':
> main.cpp:(.text+0x8e): undefined reference to
> `KImageAnnotator::KImageAnnotator(QPixmap const&)'
> collect2: error: ld returned 1 exit status
> CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
> make[2]: *** [testApp] Error 1
> CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all'
> failed
> make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
> Makefile:94: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Any idea how I could/should troubleshoot such issue?
>
> Thanks in advance!
>
> Regards,
> Damir
>
>
> --
>
> 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=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=JJ5RqPyjdlGGc3fT-5nQQM-JcJzwjBZU6ciOQlmEJVs&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_help_support.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=vUHQvc_7Ovi_5BDjy3JYFOIvTmihTSFOQNndNSpMOnA&e=
> CMake Consulting:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=91AJA3BxTfHAvsi0mAzkszAyUUmE2xfwbLgN_fYvFO4&e=
> CMake Training Courses:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=isQW6paMIqhUFaejOZ4qfUiSVwNiR1yxoQn4J91yb8o&e=
>
> Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=ose8YVW10s6tWkujUCq162vyyipCdlw-MW93qUlqdGk&e=
>
> Follow this link to subscribe/unsubscribe:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=KftR51q4EGgNERicS2QyHvzlrNaqb11IUwwbz1YTjVU&e=
>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valpara?so, Chile
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180819/7962a3eb/attachment-0001.html>

From mailinglists at xgm.de  Mon Aug 20 10:24:07 2018
From: mailinglists at xgm.de (Florian Lindner)
Date: Mon, 20 Aug 2018 16:24:07 +0200
Subject: [CMake] MPI: Undefined symbol
Message-ID: <d90b0c8d-4117-43b0-a376-1a3f92c3679e@xgm.de>

Hello,

copied from a working MPI CMakeLists.txt:

find_package(MPI REQUIRED)
include_directories(${MPI_INCLUDE_PATH})
set(COMPILE_FLAGS  ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS})


add_executable(StructureSolverParallel
  "StructureSolver_Parallel/structureDataDisplay.cpp"
  "StructureSolver_Parallel/StructureSolver.cpp"
  "StructureSolver_Parallel/structureComputeSolution.cpp")

target_link_libraries(StructureSolverParallel PUBLIC ${PRECICE_LIBRARY})
target_link_libraries(StructureSolverParallel PUBLIC ${MPI_LBRARIES})

configuration runs smooth:

% cmake -DMPI_CXX_COMPILER=/opt/mpich/bin/mpicxx -DMPI_C_COMPILER=/opt/mpich/bin/mpicc . && make               
-- The CXX compiler identification is GNU 8.2.0
[...]
-- Found MPI_CXX: /opt/mpich/lib/libmpicxx.so (found version "3.1") 
-- Found MPI: TRUE (found version "3.1")  

make however:

[ 69%] Linking CXX executable StructureSolverParallel
/usr/bin/cmake -E cmake_link_script CMakeFiles/StructureSolverParallel.dir/link.txt --verbose=1
/usr/bin/c++   -Wall -Wextra -Wno-unused-parameter -g   CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureDataDisplay.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o  -o StructureSolverParallel /home/lindnefn/precice/build/last/libprecice.so 
/usr/bin/ld: CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o: undefined reference to symbol 'MPI_Init'
/usr/bin/ld: /opt/mpich/lib/libmpi.so.12: error adding symbols: DSO missing from command line

when I just take the last command line and -lmpi to it, it works.

What could be missing there in CMakeLists?

Thanks,
Florian


From rafael at sizeofvoid.org  Mon Aug 20 11:49:03 2018
From: rafael at sizeofvoid.org (Rafael Sadowski)
Date: Mon, 20 Aug 2018 17:49:03 +0200
Subject: [CMake] MPI: Undefined symbol
In-Reply-To: <d90b0c8d-4117-43b0-a376-1a3f92c3679e@xgm.de>
References: <d90b0c8d-4117-43b0-a376-1a3f92c3679e@xgm.de>
Message-ID: <20180820154903.vl6c2dknbghawj32@kubus.openhome.sizeofvoid.org>

On Mon Aug 20, 2018 at 04:24:07PM +0200, Florian Lindner wrote:
> Hello,
> 
> copied from a working MPI CMakeLists.txt:
> 
> find_package(MPI REQUIRED)

https://cmake.org/cmake/help/v3.0/module/FindMPI.html

MPI_<lang>_FOUND           TRUE if FindMPI found MPI flags for <lang>
MPI_<lang>_COMPILER        MPI Compiler wrapper for <lang>
MPI_<lang>_COMPILE_FLAGS   Compilation flags for MPI programs
MPI_<lang>_INCLUDE_PATH    Include path(s) for MPI header
MPI_<lang>_LINK_FLAGS      Linking flags for MPI programs
MPI_<lang>_LIBRARIES       All libraries to link MPI programs against

Looks like you forgot <lang>.

> include_directories(${MPI_INCLUDE_PATH})
> set(COMPILE_FLAGS  ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
> set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS})
> 
> 
> add_executable(StructureSolverParallel
>   "StructureSolver_Parallel/structureDataDisplay.cpp"
>   "StructureSolver_Parallel/StructureSolver.cpp"
>   "StructureSolver_Parallel/structureComputeSolution.cpp")
> 
> target_link_libraries(StructureSolverParallel PUBLIC ${PRECICE_LIBRARY})
> target_link_libraries(StructureSolverParallel PUBLIC ${MPI_LBRARIES})
> 
> configuration runs smooth:
> 
> % cmake -DMPI_CXX_COMPILER=/opt/mpich/bin/mpicxx -DMPI_C_COMPILER=/opt/mpich/bin/mpicc . && make               
> -- The CXX compiler identification is GNU 8.2.0
> [...]
> -- Found MPI_CXX: /opt/mpich/lib/libmpicxx.so (found version "3.1") 
> -- Found MPI: TRUE (found version "3.1")  
> 
> make however:
> 
> [ 69%] Linking CXX executable StructureSolverParallel
> /usr/bin/cmake -E cmake_link_script CMakeFiles/StructureSolverParallel.dir/link.txt --verbose=1
> /usr/bin/c++   -Wall -Wextra -Wno-unused-parameter -g   CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureDataDisplay.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o  -o StructureSolverParallel /home/lindnefn/precice/build/last/libprecice.so 
> /usr/bin/ld: CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o: undefined reference to symbol 'MPI_Init'
> /usr/bin/ld: /opt/mpich/lib/libmpi.so.12: error adding symbols: DSO missing from command line
> 
> when I just take the last command line and -lmpi to it, it works.
> 
> What could be missing there in CMakeLists?
> 
> Thanks,
> Florian
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From damir_porobic at live.com  Mon Aug 20 13:05:10 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Mon, 20 Aug 2018 17:05:10 +0000
Subject: [CMake] Problem with creating shared library
In-Reply-To: <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>,
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
Message-ID: <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Hi Eric,


yes, this is the project. I have pushed my current state to this branch https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch


I've tried also without the generate_export_headers (cleaned everything up before trying out) but I get the same result.


KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the handwritten file, that's true, I think I got something mixed up there and I don't actually need the generate_export_headers, but as said, even without the line, it's not working.


Cheers,

Damir

________________________________
From: Eric Noulard <eric.noulard at gmail.com>
Sent: Sunday, August 19, 2018 22:44
To: Damir Porobic
Cc: smancill at jlab.org; CMake Mailinglist
Subject: Re: [CMake] Problem with creating shared library

Hi Damir,

May be the issue has nothing to do with the way you build the exported <>Config.cmake files.
Since may be some nasty detail slipped in, could you tell us if the project is public.
It looks like this one:
https://github.com/DamirPorobic/kImageAnnotator

may be you can push a branch that contains the exact thing that fails on your side and it may be easier to review the detail?

on the master of this repo there does not seem to have any "example" dir.

However you already have hand written header file:
https://github.com/DamirPorobic/kImageAnnotator/blob/master/src/gui/KImageAnnotator.h

which has the very same name as the "exported header you generate":
generate_export_header(kImageAnnotator
        EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
        EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
        )

so may be
KImageAnnotator::KImageAnnotator(QPixmap const&)
is exposed by the hand-written file and not by the generated one so
that your unit test links ok but your "example" does not ?

Did you check the content of the generated header file?








Le dim. 19 ao?t 2018 ? 15:17, Damir Porobic <damir_porobic at live.com<mailto:damir_porobic at live.com>> a ?crit :

Thanks Sebasti?n for providing those links!


I've followed the second link that you've provided but somehow I'm still running into issue.


I've changed the directory structure to this:

- kImageAnnotator
    - cmake
        - kImageAnnotator-config.cmake.in<http://config.cmake.in>
    - example
        - main.cpp
        - CMakeLists.txt
    - include
        - kImageAnnotator
            - KImageAnnotator.h     // the main api header
    - src
        - KImageAnnotator.cpp
        - "And all other .cpp and .h files"
        - CMakeLists.txt
    - CMakeLists.txt

src/CMakeList.txt looks like this:
add_library(kImageAnnotator ${kimageannotator_SRCS} ${CMAKE_SOURCE_DIR}/include/kImageAnnotator/KImageAnnotator.h)

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

option(BUILD_SHARED_LIBS "Build shared library" ON)
include(GenerateExportHeader)

generate_export_header(kImageAnnotator
        EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
        EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
        )

target_include_directories(kImageAnnotator
        PUBLIC
        $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
        $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
        $<INSTALL_INTERFACE:include>
        PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR}
        )

set_target_properties(kImageAnnotator PROPERTIES
        ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
        LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
        RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin
        )

find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)

find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n WidgetsAddons)

target_link_libraries(kImageAnnotator Qt5::Widgets KF5::CoreAddons KF5::I18n KF5::WidgetsAddons)

include(GNUInstallDirs)

install(TARGETS kImageAnnotator
        EXPORT kImageAnnotator-targets
        ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
        RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
        INCLUDES DESTINATION ${LIBLEGACY_INCLUDE_DIRS}
)

install(DIRECTORY ${CMAKE_SOURCE_DIR}/include/kImageAnnotator
        DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)

install(EXPORT kImageAnnotator-targets
        FILE kImageAnnotator-targets.cmake
        NAMESPACE kImageAnnotator::
        DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
)


include(CMakePackageConfigHelpers)

configure_package_config_file(
        ${CMAKE_SOURCE_DIR}/cmake/kImageAnnotator-config.cmake.in<http://kImageAnnotator-config.cmake.in>
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
        INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
)

write_basic_package_version_file(
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
        VERSION ${PROJECT_VERSION}
        COMPATIBILITY AnyNewerVersion
)

install(FILES
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
        ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
        DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
)

export(EXPORT kImageAnnotator-targets
        FILE ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-targets.cmake
        NAMESPACE kImageAnnotator::
)



kImageAnnotator-config.cmake.in<http://kImageAnnotator-config.cmake.in> looks like this:

include(CMakeFindDependencyMacro)

@PACKAGE_INIT@

# find_dependency(Threads)
find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)

find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n WidgetsAddons)

if(NOT TARGET kImageAnnotator::kImageAnnotator)
  include("${CMAKE_CURRENT_LIST_DIR}/kImageAnnotator-targets.cmake")
endif()



example/CMakeLists.txt looks like this:

add_executable(kImageAnnotator-example ${CMAKE_CURRENT_SOURCE_DIR}/main.cpp)

target_link_libraries(kImageAnnotator-example PRIVATE kImageAnnotator::kImageAnnotator)



And example/main.cpp looks like this:

#include <QApplication>
#include <kImageAnnotator/KImageAnnotator.h>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QPixmap pixmap(QSize(500, 500));
    pixmap.fill(QColor(Qt::darkGreen));
    auto kImageAnnotator = new KImageAnnotator(pixmap);
    kImageAnnotator->show();

    return app.exec();
}



Still I'm getting following error when trying to build kImageAnnotator-example:

Scanning dependencies of target kImageAnnotator-example
[ 98%] Building CXX object example/CMakeFiles/kImageAnnotator-example.dir/main.cpp.o
[ 98%] Building CXX object example/CMakeFiles/kImageAnnotator-example.dir/kImageAnnotator-example_autogen/mocs_compilation.cpp.o
[100%] Linking CXX executable kImageAnnotator-example
CMakeFiles/kImageAnnotator-example.dir/main.cpp.o: In function `main':
/home/dporobic/projects/kImageAnnotator/example/main.cpp:29: undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
collect2: error: ld returned 1 exit status
example/CMakeFiles/kImageAnnotator-example.dir/build.make:98: recipe for target 'example/kImageAnnotator-example' failed

Any idea what I'm doing wrong? It looks like the same issue that I was having earlier.


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org<mailto:smancill at jlab.org>>
Sent: Wednesday, August 15, 2018 21:48
To: damir_porobic at live.com<mailto:damir_porobic at live.com>
Cc: cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Problem with creating shared library

You are mixing the config file and the targets file.

The config file is a template that you normally put in cmake/FooConfig.cmake.in<http://FooConfig.cmake.in>

You copy the template into the binary dir:

    include(CMakePackageConfigHelpers)

    set(INSTALL_CONFIGDIR lib/cmake/Foo)

    configure_package_config_file(
      "${CMAKE_CURRENT_LIST_DIR}/cmake/FooConfig.cmake.in<http://FooConfig.cmake.in>"
      "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
      INSTALL_DESTINATION ${INSTALL_CONFIGDIR}
    )

It is a good idea to create a version file:

    write_basic_package_version_file(
      "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
      VERSION ${PROJECT_VERSION}
      COMPATIBILITY SameMajorVersion
   )

And then install both:

    install(FILES
        "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake"
        "${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake"
      DESTINATION ${INSTALL_CONFIGDIR}
      COMPONENT Devel
    )

For the targets is a different file. When you install the library you should use

    install(TARGETS Foo EXPORT FooTargets ...)

And then export and install the targets:

    # Into the build tree
    export(EXPORT FooTargets
      FILE "${CMAKE_CURRENT_BINARY_DIR}/FooTargets.cmake"
      NAMESPACE Foo::
    )

    # Into PREFIX
    install(EXPORT FooTargets
      FILE FooTargets.cmake
      NAMESPACE Foo::
      DESTINATION ${INSTALL_CONFIGDIR}
      COMPONENT Devel
    )

Finally, your template FooConfig.cmake.in<http://FooConfig.cmake.in> should look like this:

  include(CMakeFindDependencyMacro)

  @PACKAGE_INIT@

  # list your required dependencies here
  find_dependency(Threads)

  if(NOT TARGET Foo::Foo)
    include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake")
  endif()

All this is pretty much the same for any project. Here are the best links explaining it:

https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
http://unclejimbo.github.io/2018/06/08/Modern-CMake-for-Library-Developers/




El mi?., 15 de ago. de 2018 a la(s) 05:32, Damir Porobic (damir_porobic at live.com<mailto:damir_porobic at live.com>) escribi?:

Hi Folks,


I'm trying to write a shared library and run into an issue where I can't find any clues to where the problem is.

I have a project with following structure:


src/

    dir1/

        file1.h

        file1.cpp

    dir2/

        file2.h

        file2.cpp



Now I have this CMakeList:

cmake_minimum_required(VERSION 3.5)

project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)


...


add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons KF5::I18n KF5::WidgetsAddons)

target_include_directories(${PROJECT_NAME} PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:include>)

set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION} SOVERSION 1)

set(kimageannotator_CONFIG ${PROJECT_NAME}Config)

install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
        ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
        RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})

install(EXPORT ${kimageannotator_CONFIG} DESTINATION share/${kimageannotator_CONFIG}/cmake)

export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)


In another test project, I add the library like this:
...
find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp Qt5::Widgets kImageAnnotator)


Now when I try to build my test project, I get this:

dporobic at linux ~/projects/testApp/build
$ cmake .. && make
-- Could not set up the appstream test. appstreamcli is missing.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dporobic/projects/testApp/build
[ 25%] Automatic moc for target testApp
[ 25%] Built target testApp_automoc
Scanning dependencies of target testApp
[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
[ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
[100%] Linking CXX executable testApp
CMakeFiles/testApp.dir/main.cpp.o: In function `main':
main.cpp:(.text+0x8e): undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
make[2]: *** [testApp] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all' failed
make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Any idea how I could/should troubleshoot such issue?

Thanks in advance!

Regards,
Damir



--

Powered by www.kitware.com<http://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=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=JJ5RqPyjdlGGc3fT-5nQQM-JcJzwjBZU6ciOQlmEJVs&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_help_support.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=vUHQvc_7Ovi_5BDjy3JYFOIvTmihTSFOQNndNSpMOnA&e=
CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=91AJA3BxTfHAvsi0mAzkszAyUUmE2xfwbLgN_fYvFO4&e=
CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=isQW6paMIqhUFaejOZ4qfUiSVwNiR1yxoQn4J91yb8o&e=

Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=ose8YVW10s6tWkujUCq162vyyipCdlw-MW93qUlqdGk&e=

Follow this link to subscribe/unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=1H4kXxGuNG-DAo1qM-u8bdF6AKKHkJoiCuqwZ4QLvtY&s=KftR51q4EGgNERicS2QyHvzlrNaqb11IUwwbz1YTjVU&e=


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
--

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

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


--
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180820/1323c32a/attachment-0001.html>

From eike at sf-mail.de  Mon Aug 20 13:15:38 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 20 Aug 2018 19:15:38 +0200
Subject: [CMake] [cmake-developers] RfD: deprecate link_directories()
 and link_libraries()
In-Reply-To: <7e9ba1fd-288c-8eed-90c5-9a2fded53c5f@kitware.com>
References: <2038850.cgMoPb54nq@daneel.sf-tec.de>
 <7e9ba1fd-288c-8eed-90c5-9a2fded53c5f@kitware.com>
Message-ID: <8578046.cJ9kk6BO8Y@daneel.sf-tec.de>

Am Montag, 20. August 2018, 19:10:57 CEST schrieb Brad King:
> On 08/15/2018 01:30 PM, Rolf Eike Beer wrote:
> > My dislike against these functions is probably known, and now I would like
> > to bring this to a new level: I would like to formally deprecate these
> > functions. I don't think they serve any useful purpose anymore, given
> > that now even the pkg-config module can (and does) return absolute paths
> > to the libraries.
> What harm does their presence cause?
> 
> Please ask on the user list to see if people are using them.
> 
> I suspect they may be used by some projects to link to special runtime
> libraries when cross-compiling.  We'd need to make sure there is a
> better way for all such use cases before deprecating the commands.

I have only seen this commands in failed attempts to convert Makefiles to 
CMake without using the proper methods of calling find_library(). And then 
showing up here or in #cmake and complaining that it breaks.

So, has anyone an example where these are still needed with CMake 3.12 for 
anything that _can't_ be done properly?

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake/attachments/20180820/ef01ea06/attachment.sig>

From rcdailey.lists at gmail.com  Mon Aug 20 13:47:53 2018
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 20 Aug 2018 12:47:53 -0500
Subject: [CMake] libc++ usage in CMake with Clang?
Message-ID: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>

Is the only way to use libc++ to muck with compile flags? Or is there
a proper find module for this or something? Is there a more
CMake-esque way of specifying the STL library to use with the
toolchain?

From sjm324 at cornell.edu  Mon Aug 20 22:03:44 2018
From: sjm324 at cornell.edu (Stephen McDowell)
Date: Mon, 20 Aug 2018 19:03:44 -0700
Subject: [CMake] libc++ usage in CMake with Clang?
In-Reply-To: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
Message-ID: <CAJGuVd-M4NKRUueNkNygF4AzMJWH8hCWvEDmYpsGKmEnmPRzxw@mail.gmail.com>

Good question. The only official thing I could find that is _somewhat_
related is this:
https://cmake.org/cmake/help/latest/variable/CMAKE_ANDROID_STL_TYPE.html#variable:CMAKE_ANDROID_STL_TYPE

Doesn't really help if you aren't targeting Android though....

On Mon, Aug 20, 2018, 10:48 AM Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> Is the only way to use libc++ to muck with compile flags? Or is there
> a proper find module for this or something? Is there a more
> CMake-esque way of specifying the STL library to use with the
> toolchain?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180820/33c759f7/attachment.html>

From kgt at lanl.gov  Mon Aug 20 23:05:45 2018
From: kgt at lanl.gov (Thompson, KT)
Date: Tue, 21 Aug 2018 03:05:45 +0000
Subject: [CMake] libc++ usage in CMake with Clang?
In-Reply-To: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
Message-ID: <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>

I'm also interested in the answer to Robert's question.  I've been using

  set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")

but it seems like there should be a more elegant approach.

-tk

-----Original Message-----
From: CMake <cmake-bounces at cmake.org> On Behalf Of Robert Dailey
Sent: Monday, August 20, 2018 11:48 AM
To: CMake <cmake at cmake.org>
Subject: [CMake] libc++ usage in CMake with Clang?

Is the only way to use libc++ to muck with compile flags? Or is there a proper find module for this or something? Is there a more CMake-esque way of specifying the STL library to use with the toolchain?
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

From mailinglists at xgm.de  Tue Aug 21 04:52:03 2018
From: mailinglists at xgm.de (Florian Lindner)
Date: Tue, 21 Aug 2018 10:52:03 +0200
Subject: [CMake] MPI: Undefined symbol
In-Reply-To: <20180820154903.vl6c2dknbghawj32@kubus.openhome.sizeofvoid.org>
References: <d90b0c8d-4117-43b0-a376-1a3f92c3679e@xgm.de>
 <20180820154903.vl6c2dknbghawj32@kubus.openhome.sizeofvoid.org>
Message-ID: <5d86cbcd-e486-319c-e880-6f1f559dc72f@xgm.de>

Hello,

Am 20.08.18 um 17:49 schrieb Rafael Sadowski:
> On Mon Aug 20, 2018 at 04:24:07PM +0200, Florian Lindner wrote:
>> Hello,
>>
>> copied from a working MPI CMakeLists.txt:
>>
>> find_package(MPI REQUIRED)
> 
> https://cmake.org/cmake/help/v3.0/module/FindMPI.html
> 
> MPI_<lang>_FOUND           TRUE if FindMPI found MPI flags for <lang>
> MPI_<lang>_COMPILER        MPI Compiler wrapper for <lang>
> MPI_<lang>_COMPILE_FLAGS   Compilation flags for MPI programs
> MPI_<lang>_INCLUDE_PATH    Include path(s) for MPI header
> MPI_<lang>_LINK_FLAGS      Linking flags for MPI programs
> MPI_<lang>_LIBRARIES       All libraries to link MPI programs against
> 
> Looks like you forgot <lang>.

Should also work, versions without LANG are deprecated, but still supported.

But still, I didn't know about the new version and updated my cmake file, but still getting the same error.

find_package(MPI REQUIRED
  COMPONENTS CXX)
include_directories(${MPI_CXX_INCLUDE_DIRS})
set(COMPILE_OPTIONS  ${COMPILE_FLAGS} ${MPI_CXX_COMPILE_OPTIONS})
set(LINK_FLAGS ${LINK_FLAGS} ${MPI_CXX_LINK_FLAGS})
add_definitions(${MPI_CXX_COMPILE_DEFINTIONS})

add_executable(StructureSolverParallel
  "StructureSolver_Parallel/structureDataDisplay.cpp"
  "StructureSolver_Parallel/StructureSolver.cpp"
  "StructureSolver_Parallel/structureComputeSolution.cpp")

target_link_libraries(StructureSolverParallel PUBLIC ${MPI_CXX_LBRARIES})


[ 61%] Building CXX object CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o
/usr/bin/c++   -I/home/lindnefn/precice/src -I/opt/mpich/include  -Wall -Wextra -Wno-unused-parameter -g   -std=gnu++11 -o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o -c /home/lindnefn/devel/elastictube1d/StructureSolver_Parallel/structureComputeSolution.cpp

[ 69%] Linking CXX executable StructureSolverParallel
/usr/bin/cmake -E cmake_link_script CMakeFiles/StructureSolverParallel.dir/link.txt --verbose=1
/usr/bin/c++   -Wall -Wextra -Wno-unused-parameter -g   CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureDataDisplay.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o  -o StructureSolverParallel /home/lindnefn/precice/build/last/libprecice.so

/usr/bin/ld: CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o: undefined reference to symbol 'MPI_Init'
/usr/bin/ld: /opt/mpich/lib/libmpi.so.12: error adding symbols: DSO missing from command line

It doesn't seem to put the MPI_CXX_LIBRARIES at the end. Again, just adding -lmpi to the final command does the trick.

Putting message(${MPI_CXX_LIBRARIES}) after the MPI block returns:

/opt/mpich/lib/libmpicxx.so/opt/mpich/lib/libmpi.so

Any more ideas?

Thanks,
Florian


> 
>> include_directories(${MPI_INCLUDE_PATH})
>> set(COMPILE_FLAGS  ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
>> set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS})
>>
>>
>> add_executable(StructureSolverParallel
>>   "StructureSolver_Parallel/structureDataDisplay.cpp"
>>   "StructureSolver_Parallel/StructureSolver.cpp"
>>   "StructureSolver_Parallel/structureComputeSolution.cpp")
>>
>> target_link_libraries(StructureSolverParallel PUBLIC ${PRECICE_LIBRARY})
>> target_link_libraries(StructureSolverParallel PUBLIC ${MPI_LBRARIES})
>>
>> configuration runs smooth:
>>
>> % cmake -DMPI_CXX_COMPILER=/opt/mpich/bin/mpicxx -DMPI_C_COMPILER=/opt/mpich/bin/mpicc . && make               
>> -- The CXX compiler identification is GNU 8.2.0
>> [...]
>> -- Found MPI_CXX: /opt/mpich/lib/libmpicxx.so (found version "3.1") 
>> -- Found MPI: TRUE (found version "3.1")  
>>
>> make however:
>>
>> [ 69%] Linking CXX executable StructureSolverParallel
>> /usr/bin/cmake -E cmake_link_script CMakeFiles/StructureSolverParallel.dir/link.txt --verbose=1
>> /usr/bin/c++   -Wall -Wextra -Wno-unused-parameter -g   CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureDataDisplay.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o  -o StructureSolverParallel /home/lindnefn/precice/build/last/libprecice.so 
>> /usr/bin/ld: CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o: undefined reference to symbol 'MPI_Init'
>> /usr/bin/ld: /opt/mpich/lib/libmpi.so.12: error adding symbols: DSO missing from command line
>>
>> when I just take the last command line and -lmpi to it, it works.
>>
>> What could be missing there in CMakeLists?
>>
>> Thanks,
>> Florian
>>
>> -- 
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake

From oystwa at gmail.com  Tue Aug 21 05:01:26 2018
From: oystwa at gmail.com (=?UTF-8?Q?=C3=98ystein_Walle?=)
Date: Tue, 21 Aug 2018 11:01:26 +0200
Subject: [CMake] Conflicting MSVC manifests
Message-ID: <CAFaJEqt0vJu_M9WGg8w1g8iMqondLyyi-MB9ikAkS1pxfV30ow@mail.gmail.com>

Hi,

I am experiencing an error when trying to require administrator privileges on
Windows. I have made a small test case[1] available to demonstrate the issue.
CMake generates its own manifest and at link time MSVC is unable to merge
CMake's and my own manifest, giving the following error:

    manifest authoring error c1010001: Values of attribute "level" not equal
    in different manifest snippets.

The error occurs both when generating a VS project and generating Ninja build
files with the MSVC toolchain with CMake 3.12.1.

This problem can be worked around by adding the following to CMakeLists.txt
instead using the manifest file (thanks to ngladitz at #cmake at freenode):

    set_property(TARGET ${PROJECT_NAME} PROPERTY
        LINK_FLAGS "/MANIFESTUAC:level='requireAdministrator'"
    )

However, CMake has had support for adding manifest files to the list of sources
since 3.4. Should this particular usage of a manifest file be an exception? If
so, are there any other potential conflicts?

If's desirable to rather fix the issue maybe the options I see are:

 - Use the user's manifest (if present) and discard CMake's own,
 - Configure MSVC to let one manifest file yield when conflicts are present
   (not sure if this is possible),
 - Do the merge in CMake itself (yuck, I guess...)

I'm new to the MSVC toolchain so there may be some obvious solutions I
am overlooking here...

Regards,
?sse

[1]: https://github.com/Osse/manifesttest

From bo.schwarzstein at gmail.com  Tue Aug 21 05:11:36 2018
From: bo.schwarzstein at gmail.com (Bo Zhou)
Date: Tue, 21 Aug 2018 18:11:36 +0900
Subject: [CMake] Conflicting MSVC manifests
In-Reply-To: <CAFaJEqt0vJu_M9WGg8w1g8iMqondLyyi-MB9ikAkS1pxfV30ow@mail.gmail.com>
References: <CAFaJEqt0vJu_M9WGg8w1g8iMqondLyyi-MB9ikAkS1pxfV30ow@mail.gmail.com>
Message-ID: <CAMX42NAcNEhSH+DkT-5Z6Ju4m7T5sZ5YXPV9+wpS-9gg+_4bKg@mail.gmail.com>

>From my personal experience, I suggest never touch the manifest, because
it's not a useful configuration to solve the DLL hell issue since Windows
XP.

Instead, once we know the exact version of Visual Studio with Update, the
distributor just ship the MSVC runtime installer with software, the
installer would install the required MSVCRuntime locally, so everything
almost exactly matches without touching the crazy configuration.

On MSVC, you should always use Visual Studio MSBuild rather than the other
build system, just use

cmake --build <build_dir> --target INSTALL --config Release


That's it.

Thank you very much.

On Tue, Aug 21, 2018 at 6:02 PM ?ystein Walle <oystwa at gmail.com> wrote:

> Hi,
>
> I am experiencing an error when trying to require administrator privileges
> on
> Windows. I have made a small test case[1] available to demonstrate the
> issue.
> CMake generates its own manifest and at link time MSVC is unable to merge
> CMake's and my own manifest, giving the following error:
>
>     manifest authoring error c1010001: Values of attribute "level" not
> equal
>     in different manifest snippets.
>
> The error occurs both when generating a VS project and generating Ninja
> build
> files with the MSVC toolchain with CMake 3.12.1.
>
> This problem can be worked around by adding the following to CMakeLists.txt
> instead using the manifest file (thanks to ngladitz at #cmake at freenode):
>
>     set_property(TARGET ${PROJECT_NAME} PROPERTY
>         LINK_FLAGS "/MANIFESTUAC:level='requireAdministrator'"
>     )
>
> However, CMake has had support for adding manifest files to the list of
> sources
> since 3.4. Should this particular usage of a manifest file be an
> exception? If
> so, are there any other potential conflicts?
>
> If's desirable to rather fix the issue maybe the options I see are:
>
>  - Use the user's manifest (if present) and discard CMake's own,
>  - Configure MSVC to let one manifest file yield when conflicts are present
>    (not sure if this is possible),
>  - Do the merge in CMake itself (yuck, I guess...)
>
> I'm new to the MSVC toolchain so there may be some obvious solutions I
> am overlooking here...
>
> Regards,
> ?sse
>
> [1]: https://github.com/Osse/manifesttest
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180821/c286b02b/attachment.html>

From rcdailey.lists at gmail.com  Tue Aug 21 09:41:06 2018
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 21 Aug 2018 08:41:06 -0500
Subject: [CMake] libc++ usage in CMake with Clang?
In-Reply-To: <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
 <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
Message-ID: <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>

I'll explain a bit why I'm asking. I noticed that for code bases that
work on Android plus other UNIX platforms, they unconditionally
specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
default, which uses gnu stl + gcc/clang. So  you get compiler errors.
There's no way for me to "search" a platform to see if it is eligible
for the libc++ flag, I simply have to either disable it completely or
conditionally include it based on target platform and/or toolchain.
None of these really address the root cause.

I'm not even really sure what a find module for this would do... but
typically find modules don't provide compiler flags, so I'm not sure
if that's the right tool for the job. Would love to hear from the
developers on this, so I've cross posted to the dev mailing list in
this reply.
On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT <kgt at lanl.gov> wrote:
>
> I'm also interested in the answer to Robert's question.  I've been using
>
>   set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
>
> but it seems like there should be a more elegant approach.
>
> -tk
>
> -----Original Message-----
> From: CMake <cmake-bounces at cmake.org> On Behalf Of Robert Dailey
> Sent: Monday, August 20, 2018 11:48 AM
> To: CMake <cmake at cmake.org>
> Subject: [CMake] libc++ usage in CMake with Clang?
>
> Is the only way to use libc++ to muck with compile flags? Or is there a proper find module for this or something? Is there a more CMake-esque way of specifying the STL library to use with the toolchain?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From haocheng.liu at kitware.com  Tue Aug 21 10:59:44 2018
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Tue, 21 Aug 2018 10:59:44 -0400
Subject: [CMake] MPI: Undefined symbol
In-Reply-To: <5d86cbcd-e486-319c-e880-6f1f559dc72f@xgm.de>
References: <d90b0c8d-4117-43b0-a376-1a3f92c3679e@xgm.de>
 <20180820154903.vl6c2dknbghawj32@kubus.openhome.sizeofvoid.org>
 <5d86cbcd-e486-319c-e880-6f1f559dc72f@xgm.de>
Message-ID: <CACbTE7N_ZCNjSo+OOF4AdAbiPDHNu5Lc+Mj7V9PR+_TDuf-70Q@mail.gmail.com>

This stackoverflow
<https://stackoverflow.com/questions/23163075/how-to-compile-an-mpi-included-c-program-using-cmake/45485419#45485419>
question might help you.

On Tue, Aug 21, 2018 at 4:52 AM Florian Lindner <mailinglists at xgm.de> wrote:

> Hello,
>
> Am 20.08.18 um 17:49 schrieb Rafael Sadowski:
> > On Mon Aug 20, 2018 at 04:24:07PM +0200, Florian Lindner wrote:
> >> Hello,
> >>
> >> copied from a working MPI CMakeLists.txt:
> >>
> >> find_package(MPI REQUIRED)
> >
> > https://cmake.org/cmake/help/v3.0/module/FindMPI.html
> >
> > MPI_<lang>_FOUND           TRUE if FindMPI found MPI flags for <lang>
> > MPI_<lang>_COMPILER        MPI Compiler wrapper for <lang>
> > MPI_<lang>_COMPILE_FLAGS   Compilation flags for MPI programs
> > MPI_<lang>_INCLUDE_PATH    Include path(s) for MPI header
> > MPI_<lang>_LINK_FLAGS      Linking flags for MPI programs
> > MPI_<lang>_LIBRARIES       All libraries to link MPI programs against
> >
> > Looks like you forgot <lang>.
>
> Should also work, versions without LANG are deprecated, but still
> supported.
>
> But still, I didn't know about the new version and updated my cmake file,
> but still getting the same error.
>
> find_package(MPI REQUIRED
>   COMPONENTS CXX)
> include_directories(${MPI_CXX_INCLUDE_DIRS})
> set(COMPILE_OPTIONS  ${COMPILE_FLAGS} ${MPI_CXX_COMPILE_OPTIONS})
> set(LINK_FLAGS ${LINK_FLAGS} ${MPI_CXX_LINK_FLAGS})
> add_definitions(${MPI_CXX_COMPILE_DEFINTIONS})
>
> add_executable(StructureSolverParallel
>   "StructureSolver_Parallel/structureDataDisplay.cpp"
>   "StructureSolver_Parallel/StructureSolver.cpp"
>   "StructureSolver_Parallel/structureComputeSolution.cpp")
>
> target_link_libraries(StructureSolverParallel PUBLIC ${MPI_CXX_LBRARIES})
>
>
> [ 61%] Building CXX object
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o
> /usr/bin/c++   -I/home/lindnefn/precice/src -I/opt/mpich/include  -Wall
> -Wextra -Wno-unused-parameter -g   -std=gnu++11 -o
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o
> -c
> /home/lindnefn/devel/elastictube1d/StructureSolver_Parallel/structureComputeSolution.cpp
>
> [ 69%] Linking CXX executable StructureSolverParallel
> /usr/bin/cmake -E cmake_link_script
> CMakeFiles/StructureSolverParallel.dir/link.txt --verbose=1
> /usr/bin/c++   -Wall -Wextra -Wno-unused-parameter -g
>  CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureDataDisplay.cpp.o
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o
> -o StructureSolverParallel /home/lindnefn/precice/build/last/libprecice.so
>
> /usr/bin/ld:
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o:
> undefined reference to symbol 'MPI_Init'
> /usr/bin/ld: /opt/mpich/lib/libmpi.so.12: error adding symbols: DSO
> missing from command line
>
> It doesn't seem to put the MPI_CXX_LIBRARIES at the end. Again, just
> adding -lmpi to the final command does the trick.
>
> Putting message(${MPI_CXX_LIBRARIES}) after the MPI block returns:
>
> /opt/mpich/lib/libmpicxx.so/opt/mpich/lib/libmpi.so
>
> Any more ideas?
>
> Thanks,
> Florian
>
>
> >
> >> include_directories(${MPI_INCLUDE_PATH})
> >> set(COMPILE_FLAGS  ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
> >> set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS})
> >>
> >>
> >> add_executable(StructureSolverParallel
> >>   "StructureSolver_Parallel/structureDataDisplay.cpp"
> >>   "StructureSolver_Parallel/StructureSolver.cpp"
> >>   "StructureSolver_Parallel/structureComputeSolution.cpp")
> >>
> >> target_link_libraries(StructureSolverParallel PUBLIC ${PRECICE_LIBRARY})
> >> target_link_libraries(StructureSolverParallel PUBLIC ${MPI_LBRARIES})
> >>
> >> configuration runs smooth:
> >>
> >> % cmake -DMPI_CXX_COMPILER=/opt/mpich/bin/mpicxx
> -DMPI_C_COMPILER=/opt/mpich/bin/mpicc . && make
> >> -- The CXX compiler identification is GNU 8.2.0
> >> [...]
> >> -- Found MPI_CXX: /opt/mpich/lib/libmpicxx.so (found version "3.1")
> >> -- Found MPI: TRUE (found version "3.1")
> >>
> >> make however:
> >>
> >> [ 69%] Linking CXX executable StructureSolverParallel
> >> /usr/bin/cmake -E cmake_link_script
> CMakeFiles/StructureSolverParallel.dir/link.txt --verbose=1
> >> /usr/bin/c++   -Wall -Wextra -Wno-unused-parameter -g
>  CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureDataDisplay.cpp.o
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/structureComputeSolution.cpp.o
> -o StructureSolverParallel /home/lindnefn/precice/build/last/libprecice.so
> >> /usr/bin/ld:
> CMakeFiles/StructureSolverParallel.dir/StructureSolver_Parallel/StructureSolver.cpp.o:
> undefined reference to symbol 'MPI_Init'
> >> /usr/bin/ld: /opt/mpich/lib/libmpi.so.12: error adding symbols: DSO
> missing from command line
> >>
> >> when I just take the last command line and -lmpi to it, it works.
> >>
> >> What could be missing there in CMakeLists?
> >>
> >> Thanks,
> >> Florian
> >>
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For
> more information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://cmake.org/mailman/listinfo/cmake
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <javascript:void(0);>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180821/dfbab4b9/attachment-0001.html>

From eric.noulard at gmail.com  Tue Aug 21 13:29:06 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 21 Aug 2018 19:29:06 +0200
Subject: [CMake] Problem with creating shared library
In-Reply-To: <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
 <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>

Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic <damir_porobic at live.com> a
?crit :

> Hi Eric,
>
>
> yes, this is the project. I have pushed my current state to this branch
> https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch
>
> I've tried also without the generate_export_headers (cleaned everything up
> before trying out) but I get the same result.
>
>
> KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the
> handwritten file, that's true, I think I got something mixed up there and I
> don't actually need the generate_export_headers, but as said, even
> without the line, it's not working.
>

I'm quite lost with the file layout.

in example/main.cpp you do:
#include <kImageAnnotator/KImageAnnotator.h>
so I guess you expect that
target_link_libraries(kImageAnnotator-example PRIVATE
kImageAnnotator::kImageAnnotator)

will bring you the include path to "kImageAnnotator/KImageAnnotator.h"
along with the [imported] target

in your main tree (not in example) there is a trick because you did:

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

and then in the test directory you do:

target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)

with

add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})

so AFAIU you compile your kImageAnnotator library twice. Once for building
the target you expect to use in example/ subdir
and another time as a STATIC lib for the unit test. So the unit test is not
linking to the same object lib at all ??

I am not used to KDE development but all this seems very fuzzy to me.

May be you could get more precise help from people who know better about
KDE dev and the specific CMake machinery that comes along
like ECM (https://github.com/KDE/extra-cmake-modules) you seems to be using.

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

From hobbes1069 at gmail.com  Tue Aug 21 15:18:54 2018
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Tue, 21 Aug 2018 14:18:54 -0500
Subject: [CMake] Build flags not applied during compiler testing on Ubuntu
Message-ID: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>

I have a cross platform project that I have building correctly for the
STM32 platform on Fedora but everyone using Ubuntu is having problems.

Basically, without --specs=nosys.specs applied during compiler testing,
cmake fails. I have reports of this happening on Ubuntu 14.x, 16,x and have
setup a virtual machine for 18.x.

The gory details are here:

https://bugs.launchpad.net/bugs/1787723

For the meantime, is there a way I can force cmake to apply the flags?

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180821/6580d153/attachment.html>

From craig.scott at crascit.com  Tue Aug 21 16:47:56 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 22 Aug 2018 06:47:56 +1000
Subject: [CMake] [cmake-developers]  libc++ usage in CMake with Clang?
In-Reply-To: <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
 <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
 <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>
Message-ID: <CA+dygY==y738DXaYLmyMGihpFsnfiTZ+vhrUJPYQg+P9ASAYYA@mail.gmail.com>

On Tue, Aug 21, 2018 at 11:41 PM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> I'll explain a bit why I'm asking. I noticed that for code bases that
> work on Android plus other UNIX platforms, they unconditionally
> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
> There's no way for me to "search" a platform to see if it is eligible
> for the libc++ flag, I simply have to either disable it completely or
> conditionally include it based on target platform and/or toolchain.
> None of these really address the root cause.
>
> I'm not even really sure what a find module for this would do... but
> typically find modules don't provide compiler flags, so I'm not sure
> if that's the right tool for the job. Would love to hear from the
> developers on this, so I've cross posted to the dev mailing list in
> this reply.
>


Excuse the brevity, but it sounds like you might be looking for the
CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
let me know why it isn't appropriate if so). See the following article for
a more complete overview of this and related properties:

https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/





> On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT <kgt at lanl.gov> wrote:
> >
> > I'm also interested in the answer to Robert's question.  I've been using
> >
> >   set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
> >
> > but it seems like there should be a more elegant approach.
> >
> > -tk
> >
> > -----Original Message-----
> > From: CMake <cmake-bounces at cmake.org> On Behalf Of Robert Dailey
> > Sent: Monday, August 20, 2018 11:48 AM
> > To: CMake <cmake at cmake.org>
> > Subject: [CMake] libc++ usage in CMake with Clang?
> >
> > Is the only way to use libc++ to muck with compile flags? Or is there a
> proper find module for this or something? Is there a more CMake-esque way
> of specifying the STL library to use with the toolchain?
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/c8a53c05/attachment.html>

From rcdailey.lists at gmail.com  Tue Aug 21 17:18:19 2018
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 21 Aug 2018 16:18:19 -0500
Subject: [CMake] [cmake-developers]  libc++ usage in CMake with Clang?
In-Reply-To: <CA+dygY==y738DXaYLmyMGihpFsnfiTZ+vhrUJPYQg+P9ASAYYA@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
 <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
 <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>
 <CA+dygY==y738DXaYLmyMGihpFsnfiTZ+vhrUJPYQg+P9ASAYYA@mail.gmail.com>
Message-ID: <CAHd499AqS2jEXyDu3BH5vRsthCHKtNFrrXwdJw=YwdkEcCceaw@mail.gmail.com>

On Tue, Aug 21, 2018 at 3:47 PM Craig Scott <craig.scott at crascit.com> wrote:
> Excuse the brevity, but it sounds like you might be looking for the CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, let me know why it isn't appropriate if so). See the following article for a more complete overview of this and related properties:
>
> https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/

Unfortunately that's not the same. Extensions manage C++ language
features and STL capabilities, but -stdlib is for selecting an STL
implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
to clang).

From smancill at jlab.org  Tue Aug 21 18:51:05 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Tue, 21 Aug 2018 19:51:05 -0300
Subject: [CMake] Problem with creating shared library
In-Reply-To: <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
 <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>
Message-ID: <CAJPSwc0XYgxVQHCwjofA2hARUAfXjc4J=Xb=v3u8Sz4khHNTOw@mail.gmail.com>

I fixed your problem. Get the attached patch and apply it with "git apply
<patch_file>".

The kImageAnnotator constructor was private to the library (I just learned
that Qt does that when creating shared libraries), and that's why you get
the undefined reference error. You could have checked it with:

nm lib/libkImageAnnotator.so | c++filt | grep ::KImage
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)

The "t" shows it is private.

You have to set the proper export macros to make it visible:

https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
http://doc.qt.io/qt-5/sharedlibrary.html

The patch does that, and now the example links with the library just fine.
The kImageAnnotatorExport.h header defines the macro, the compile
definition is set for the shared library target in the CMakeLists.txt. I
guess you'll  have to do the same for all classes used by the unit tests,
no sure of the Qt development practices.

I also reworked your CMake files a bit. I am sending a single patch,
though. Sorry.


El mar., 21 de ago. de 2018 a la(s) 14:29, Eric Noulard (
eric.noulard at gmail.com) escribi?:

>
>
> Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic <damir_porobic at live.com> a
> ?crit :
>
>> Hi Eric,
>>
>>
>> yes, this is the project. I have pushed my current state to this branch
>> https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DamirPorobic_kImageAnnotator_tree_sharedLibTestBranch&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=j_vYMAeNlkSJPzPWt5eGGRXiqm4RocWUGgyctA8SGE4&e=>
>>
>> I've tried also without the generate_export_headers (cleaned everything
>> up before trying out) but I get the same result.
>>
>>
>> KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the
>> handwritten file, that's true, I think I got something mixed up there and I
>> don't actually need the generate_export_headers, but as said, even
>> without the line, it's not working.
>>
>
> I'm quite lost with the file layout.
>
> in example/main.cpp you do:
> #include <kImageAnnotator/KImageAnnotator.h>
> so I guess you expect that
> target_link_libraries(kImageAnnotator-example PRIVATE
> kImageAnnotator::kImageAnnotator)
>
> will bring you the include path to "kImageAnnotator/KImageAnnotator.h"
> along with the [imported] target
>
> in your main tree (not in example) there is a trick because you did:
>
> add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)
>
> and then in the test directory you do:
>
> target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)
>
> with
>
> add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})
>
> so AFAIU you compile your kImageAnnotator library twice. Once for building
> the target you expect to use in example/ subdir
> and another time as a STATIC lib for the unit test. So the unit test is
> not linking to the same object lib at all ??
>
> I am not used to KDE development but all this seems very fuzzy to me.
>
> May be you could get more precise help from people who know better about
> KDE dev and the specific CMake machinery that comes along
> like ECM (https://github.com/KDE/extra-cmake-modules
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KDE_extra-2Dcmake-2Dmodules&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=LaNKLek4ewlsoy7ECnW4qRmkBAAVUeo6iTSFqsT9ACo&e=>)
> you seems to be using.
>
> --
> Eric
>


-- 
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180821/5e64f078/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kia.patch
Type: application/octet-stream
Size: 18882 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180821/5e64f078/attachment-0001.obj>

From craig.scott at crascit.com  Tue Aug 21 19:40:36 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 22 Aug 2018 09:40:36 +1000
Subject: [CMake] [cmake-developers]  libc++ usage in CMake with Clang?
In-Reply-To: <CAHd499AqS2jEXyDu3BH5vRsthCHKtNFrrXwdJw=YwdkEcCceaw@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
 <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
 <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>
 <CA+dygY==y738DXaYLmyMGihpFsnfiTZ+vhrUJPYQg+P9ASAYYA@mail.gmail.com>
 <CAHd499AqS2jEXyDu3BH5vRsthCHKtNFrrXwdJw=YwdkEcCceaw@mail.gmail.com>
Message-ID: <CA+dygYmMo9WWR11y98QVBnc7+k-qooYgsUtk+F_WdqW_p__CxQ@mail.gmail.com>

On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott <craig.scott at crascit.com>
> wrote:
> > Excuse the brevity, but it sounds like you might be looking for the
> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
> let me know why it isn't appropriate if so). See the following article for
> a more complete overview of this and related properties:
> >
> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
>
> Unfortunately that's not the same. Extensions manage C++ language
> features and STL capabilities, but -stdlib is for selecting an STL
> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
> to clang).
>

Sorry, yes I misunderstood your problem. After a little digging, it seems
like you probably shouldn't be using the -stdlib option on Linux
<https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for Android,
the roadmap
<https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md> is
converging on a single STL implementation too.

Regarding your earlier comment:

I'll explain a bit why I'm asking. I noticed that for code bases that
> work on Android plus other UNIX platforms, they unconditionally
> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
> There's no way for me to "search" a platform to see if it is eligible
> for the libc++ flag, I simply have to either disable it completely or
> conditionally include it based on target platform and/or toolchain.
> None of these really address the root cause.

If you are trying to control which STL to use for Android builds,
CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more
appropriate way to do that rather than hard-coding compiler flags.
This would also mean that non-Android builds won't be affected since
they would simply ignore that variable (and target properties it may
affect) and should then pick up the right STL implementation
automatically.The Android-specific variable would ideally be set in a
toolchain file rather than in the project itself.


-- 

Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/ee72875e/attachment.html>

From insertinterestingnamehere at gmail.com  Tue Aug 21 23:39:43 2018
From: insertinterestingnamehere at gmail.com (Ian Henriksen)
Date: Tue, 21 Aug 2018 22:39:43 -0500
Subject: [CMake] [cmake-developers] libc++ usage in CMake with Clang?
In-Reply-To: <CA+dygYmMo9WWR11y98QVBnc7+k-qooYgsUtk+F_WdqW_p__CxQ@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
 <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
 <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>
 <CA+dygY==y738DXaYLmyMGihpFsnfiTZ+vhrUJPYQg+P9ASAYYA@mail.gmail.com>
 <CAHd499AqS2jEXyDu3BH5vRsthCHKtNFrrXwdJw=YwdkEcCceaw@mail.gmail.com>
 <CA+dygYmMo9WWR11y98QVBnc7+k-qooYgsUtk+F_WdqW_p__CxQ@mail.gmail.com>
Message-ID: <CAPWbfpTy0w+0Ectfs+9=1H2H2CVAeE=Ppxv+eWakBce88nycuw@mail.gmail.com>

On Tue, Aug 21, 2018 at 6:40 PM Craig Scott <craig.scott at crascit.com> wrote:

>
> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey <rcdailey.lists at gmail.com>
> wrote:
>
>> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott <craig.scott at crascit.com>
>> wrote:
>> > Excuse the brevity, but it sounds like you might be looking for the
>> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
>> let me know why it isn't appropriate if so). See the following article for
>> a more complete overview of this and related properties:
>> >
>> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
>>
>> Unfortunately that's not the same. Extensions manage C++ language
>> features and STL capabilities, but -stdlib is for selecting an STL
>> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
>> to clang).
>>
>
> Sorry, yes I misunderstood your problem. After a little digging, it seems
> like you probably shouldn't be using the -stdlib option on Linux
> <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for Android,
> the roadmap
> <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md>
> is converging on a single STL implementation too.
>

All that first link says is that -stdlib is a flag that is specific to
clang and that it shouldn't be used with gcc. You can use clang on Linux
with either libstdc++ or libc++. I often use libc++ on Linux by setting
CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's
usually just to check if problems that come up are OS dependent, compiler
dependent, or standard library dependent. You have to be careful since
libstdc++ and libc++ have incompatible ABIs, but it's a useful feature.
That said, I have no idea if specifying the standard library implementation
merits handling at the CMake level since only clang supports switching
anyway.

Just my two cents though.

Best,

Ian


> Regarding your earlier comment:
>
> I'll explain a bit why I'm asking. I noticed that for code bases that
>> work on Android plus other UNIX platforms, they unconditionally
>> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
>> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
>> There's no way for me to "search" a platform to see if it is eligible
>> for the libc++ flag, I simply have to either disable it completely or
>> conditionally include it based on target platform and/or toolchain.
>> None of these really address the root cause.
>
> If you are trying to control which STL to use for Android builds, CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more appropriate way to do that rather than hard-coding compiler flags. This would also mean that non-Android builds won't be affected since they would simply ignore that variable (and target properties it may affect) and should then pick up the right STL implementation automatically.The Android-specific variable would ideally be set in a toolchain file rather than in the project itself.
>
>
> --
>
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
> <https://crascit.com/professional-cmake/>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180821/9fc43a6c/attachment.html>

From craig.scott at crascit.com  Wed Aug 22 05:05:53 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 22 Aug 2018 19:05:53 +1000
Subject: [CMake] [cmake-developers] libc++ usage in CMake with Clang?
In-Reply-To: <CAPWbfpTy0w+0Ectfs+9=1H2H2CVAeE=Ppxv+eWakBce88nycuw@mail.gmail.com>
References: <CAHd499B666UPAVg2z9z6oHeMZYSsQJa=Etug2D7PQOuMy23DWA@mail.gmail.com>
 <56e8f08e75e049bbb36bd84a4865329f@lanl.gov>
 <CAHd499CZrwZ+ZNOewRdT_A-rHthEV9tQP947LSk7a+n-w2DEeQ@mail.gmail.com>
 <CA+dygY==y738DXaYLmyMGihpFsnfiTZ+vhrUJPYQg+P9ASAYYA@mail.gmail.com>
 <CAHd499AqS2jEXyDu3BH5vRsthCHKtNFrrXwdJw=YwdkEcCceaw@mail.gmail.com>
 <CA+dygYmMo9WWR11y98QVBnc7+k-qooYgsUtk+F_WdqW_p__CxQ@mail.gmail.com>
 <CAPWbfpTy0w+0Ectfs+9=1H2H2CVAeE=Ppxv+eWakBce88nycuw@mail.gmail.com>
Message-ID: <CA+dygY=ixn4nfP1EQBwyx3fuE9OJvuPxwyFFvX+OnEA6x1YJAg@mail.gmail.com>

On Wed, Aug 22, 2018 at 1:39 PM, Ian Henriksen <
insertinterestingnamehere at gmail.com> wrote:

>
>
> On Tue, Aug 21, 2018 at 6:40 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
>>
>> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey <rcdailey.lists at gmail.com>
>> wrote:
>>
>>> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott <craig.scott at crascit.com>
>>> wrote:
>>> > Excuse the brevity, but it sounds like you might be looking for the
>>> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
>>> let me know why it isn't appropriate if so). See the following article for
>>> a more complete overview of this and related properties:
>>> >
>>> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
>>>
>>> Unfortunately that's not the same. Extensions manage C++ language
>>> features and STL capabilities, but -stdlib is for selecting an STL
>>> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
>>> to clang).
>>>
>>
>> Sorry, yes I misunderstood your problem. After a little digging, it seems
>> like you probably shouldn't be using the -stdlib option on Linux
>> <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for
>> Android, the roadmap
>> <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md>
>> is converging on a single STL implementation too.
>>
>
> All that first link says is that -stdlib is a flag that is specific to
> clang and that it shouldn't be used with gcc. You can use clang on Linux
> with either libstdc++ or libc++. I often use libc++ on Linux by setting
> CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's
> usually just to check if problems that come up are OS dependent, compiler
> dependent, or standard library dependent. You have to be careful since
> libstdc++ and libc++ have incompatible ABIs, but it's a useful feature.
> That said, I have no idea if specifying the standard library implementation
> merits handling at the CMake level since only clang supports switching
> anyway.
>


Good clarification, thanks. I was only thinking GCC on Linux and wasn't
considering clang (which was a bit dumb on my part - blame the lack of
coffee early in the morning ;) ).

Getting back to Robert's original query, the only part of the CMake code
base that I can see attempting to account for a -stdlib option is for
detection of gcc include paths, and this is only for Eclipse and CodeBlocks
generators (according to the comments in
Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake). It
doesn't seem to be related to providing any support for manipulating it in
a project. The only other place -stdlib seems to be mentioned is in the
setup of the macOS release build of CMake itself, which isn't relevant to
the discussion here.

If CMake were to offer direct support for -stdlib, it sounds like it would
be a clang-specific feature, so a clang-specific target property and/or
variable may be a way forward, analogous to the way it is done for Android.
Alternatively, maybe it could be done with generator expressions, but it
would be a bit verbose and harder to ensure the same -stdlib was used
consistently throughout if many targets were involved. But maybe just a
fairly simple check is good enough here, something like this (using
directory properties instead of variables):

if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT ANDROID)
    add_compile_options(-stdlib=libc++)
    # Presumably need the above for linking too, maybe other options
missing as well
    add_link_options(-stdlib=libc++)   # New command on CMake master, not
in 3.12 release
endif()

The linking comments above are in response to discussions in a recent issue
<https://gitlab.kitware.com/cmake/cmake/issues/18275> also related to the
-stdlib option. One down side of the above is no transitive dependency
details, something that a target property could achieve. I'll pause here
and see what others think.




>
> Just my two cents though.
>
> Best,
>
> Ian
>
>
>> Regarding your earlier comment:
>>
>> I'll explain a bit why I'm asking. I noticed that for code bases that
>>> work on Android plus other UNIX platforms, they unconditionally
>>> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
>>> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
>>> There's no way for me to "search" a platform to see if it is eligible
>>> for the libc++ flag, I simply have to either disable it completely or
>>> conditionally include it based on target platform and/or toolchain.
>>> None of these really address the root cause.
>>
>> If you are trying to control which STL to use for Android builds, CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more appropriate way to do that rather than hard-coding compiler flags. This would also mean that non-Android builds won't be affected since they would simply ignore that variable (and target properties it may affect) and should then pick up the right STL implementation automatically.The Android-specific variable would ideally be set in a toolchain file rather than in the project itself.
>>
>>
>> --
>>
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>> New book released: Professional CMake: A Practical Guide
>> <https://crascit.com/professional-cmake/>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/
>> opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/3f5dc479/attachment-0001.html>

From raphael.grimm at kit.edu  Wed Aug 22 09:57:55 2018
From: raphael.grimm at kit.edu (Raphael Grimm)
Date: Wed, 22 Aug 2018 15:57:55 +0200
Subject: [CMake] Export a custom property of a target
Message-ID: <cfbb11fa-49b0-cdab-79eb-3bc87209a4cc@kit.edu>

Hi,

I added a custom target property via 'define_property' 
(https://cmake.org/cmake/help/latest/command/define_property.html).

When using this target in a different cmake project the property is not 
found by cmake and the meta information stored in the target property is 
lost.

Is there a way to also export custom target properties?

Regards

Raphael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5205 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/d1037643/attachment.bin>

From marc.chevrier at gmail.com  Wed Aug 22 10:03:24 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Wed, 22 Aug 2018 16:03:24 +0200
Subject: [CMake] Export a custom property of a target
In-Reply-To: <cfbb11fa-49b0-cdab-79eb-3bc87209a4cc@kit.edu>
References: <cfbb11fa-49b0-cdab-79eb-3bc87209a4cc@kit.edu>
Message-ID: <CAHKTGrewWsZk2MowNeRSf77wiaNsX=7_8GnLmCdVi8Qk7Xa+-Q@mail.gmail.com>

'define_property' is nearly useless except for documentation.

Export of custom properties is managed through target property
'EXPORT_PROPERTIES'.


Le mer. 22 ao?t 2018 ? 15:58, Raphael Grimm <raphael.grimm at kit.edu> a
?crit :

> Hi,
>
> I added a custom target property via 'define_property'
> (https://cmake.org/cmake/help/latest/command/define_property.html).
>
> When using this target in a different cmake project the property is not
> found by cmake and the meta information stored in the target property is
> lost.
>
> Is there a way to also export custom target properties?
>
> Regards
>
> Raphael
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/75a93845/attachment.html>

From brad.king at kitware.com  Wed Aug 22 14:51:43 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 22 Aug 2018 14:51:43 -0400
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
Message-ID: <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>

On 08/21/2018 03:18 PM, Richard Shaw wrote:
> without --specs=nosys.specs applied during compiler testing, cmake fails.

How is this flag specified when invoking CMake?

> https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1787723

According to that discussion it works on Fedora but not on Ubuntu.
Please try an upstream version of CMake to compare behavior.

-Brad

From hobbes1069 at gmail.com  Wed Aug 22 15:49:19 2018
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Wed, 22 Aug 2018 14:49:19 -0500
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
Message-ID: <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>

On Wed, Aug 22, 2018 at 1:51 PM Brad King <brad.king at kitware.com> wrote:

> On 08/21/2018 03:18 PM, Richard Shaw wrote:
> > without --specs=nosys.specs applied during compiler testing, cmake fails.
>
> How is this flag specified when invoking CMake?
>

Initially I tried setting the flags before invoking "project" and that
seemed to be enough for Fedora. I've tried other things as well that I've
probably forgotten but one other method I tried was:

set(CMAKE_REQUIRED_DEFINITIONS "--specs=nosys.specs")

but nothing seems to work. I even tried passiting the toolchain option on
the command line with the same result.



> > https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1787723
>
> According to that discussion it works on Fedora but not on Ubuntu.
> Please try an upstream version of CMake to compare behavior.


I'll see what I can do but I'm not very Ubuntu knowledgeable. I try
download the linux binary gz file from cmake.org.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/a427bc38/attachment.html>

From brad.king at kitware.com  Wed Aug 22 16:02:40 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 22 Aug 2018 16:02:40 -0400
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
Message-ID: <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>

On 08/22/2018 03:49 PM, Richard Shaw wrote:
> Initially I tried setting the flags before invoking "project" and that seemed
> to be enough for Fedora. I've tried other things as well that I've probably
> forgotten but one other method I tried was:
> 
> set(CMAKE_REQUIRED_DEFINITIONS "--specs=nosys.specs")

That's only used by Check* modules.  It does not affect flags in general.

>From the ubuntu issue:

> The target system is: Generic - 1 - arm
> The host system is: Linux - 4.15.0-32-generic - x86_64

You're cross-compiling.  What is your CMAKE_TOOLCHAIN_FILE?

-Brad

From damir_porobic at live.com  Wed Aug 22 16:08:18 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Wed, 22 Aug 2018 20:08:18 +0000
Subject: [CMake] Problem with creating shared library
In-Reply-To: <CAJPSwc0XYgxVQHCwjofA2hARUAfXjc4J=Xb=v3u8Sz4khHNTOw@mail.gmail.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
 <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>,
 <CAJPSwc0XYgxVQHCwjofA2hARUAfXjc4J=Xb=v3u8Sz4khHNTOw@mail.gmail.com>
Message-ID: <AM0PR0202MB3411B5060BE2347A67379D4AE5300@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Thanks you Sebasti?n for finding the issue and fixing the CMake, probably would have never found out that it was set to private.


The kImageAnnotator-example is working now as expected. Do I need something else, except installing the lib, in order to use it in different projects? I've created a second project which is identical to the kImageAnnotator-example but I get following when I try to build it:


[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
In file included from /home/dporobic/projects/testApp/main.cpp:2:0:
/usr/local/include/kImageAnnotator/KImageAnnotator.h:31:35: fatal error: KImageAnnotatorExport.h: No such file or directory
 #include <KImageAnnotatorExport.h>
                                   ^
compilation terminated.


The includes look like this:

#include <QApplication>
#include <kImageAnnotator/KImageAnnotator.h>


And the CMake looks like this:

find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp kImageAnnotator)


Am I missing something again?


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org>
Sent: Wednesday, August 22, 2018 00:51
To: Eric Noulard
Cc: Damir Porobic; cmake at cmake.org
Subject: Re: [CMake] Problem with creating shared library

I fixed your problem. Get the attached patch and apply it with "git apply <patch_file>".

The kImageAnnotator constructor was private to the library (I just learned that Qt does that when creating shared libraries), and that's why you get the undefined reference error. You could have checked it with:

nm lib/libkImageAnnotator.so | c++filt | grep ::KImage
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)

The "t" shows it is private.

You have to set the proper export macros to make it visible:

https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
http://doc.qt.io/qt-5/sharedlibra
<http://doc.qt.io/qt-5/sharedlibrary.html>
How to create a library with Qt and use it in an application<https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application>
wiki.qt.io
This tutorial illustrates different approaches for using a custom library in your application on Windows. The first part explains how to create a shared library and how to link against it in your application. The second part is about creating and using a static library. Creating a shared library ...

ry.html

The patch does that, and now the example links with the library just fine. The kImageAnnotatorExport.h header defines the macro, the compile definition is set for the shared library target in the CMakeLists.txt. I guess you'll  have to do the same for all classes used by the unit tests, no sure of the Qt development practices.

I also reworked your CMake files a bit. I am sending a single patch, though. Sorry.


El mar., 21 de ago. de 2018 a la(s) 14:29, Eric Noulard (eric.noulard at gmail.com<mailto:eric.noulard at gmail.com>) escribi?:


Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic <damir_porobic at live.com<mailto:damir_porobic at live.com>> a ?crit :

Hi Eric,


yes, this is the project. I have pushed my current state to this branch https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DamirPorobic_kImageAnnotator_tree_sharedLibTestBranch&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=j_vYMAeNlkSJPzPWt5eGGRXiqm4RocWUGgyctA8SGE4&e=>


I've tried also without the generate_export_headers (cleaned everything up before trying out) but I get the same result.


KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the handwritten file, that's true, I think I got something mixed up there and I don't actually need the generate_export_headers, but as said, even without the line, it's not working.

I'm quite lost with the file layout.

in example/main.cpp you do:
#include <kImageAnnotator/KImageAnnotator.h>
so I guess you expect that
target_link_libraries(kImageAnnotator-example PRIVATE kImageAnnotator::kImageAnnotator)

will bring you the include path to "kImageAnnotator/KImageAnnotator.h" along with the [imported] target

in your main tree (not in example) there is a trick because you did:

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

and then in the test directory you do:

target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)

with

add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})

so AFAIU you compile your kImageAnnotator library twice. Once for building the target you expect to use in example/ subdir
and another time as a STATIC lib for the unit test. So the unit test is not linking to the same object lib at all ??

I am not used to KDE development but all this seems very fuzzy to me.

May be you could get more precise help from people who know better about KDE dev and the specific CMake machinery that comes along
like ECM (https://github.com/KDE/extra-cmake-modules<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KDE_extra-2Dcmake-2Dmodules&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=LaNKLek4ewlsoy7ECnW4qRmkBAAVUeo6iTSFqsT9ACo&e=>) you seems to be using.

--
Eric


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/fb846565/attachment-0001.html>

From hobbes1069 at gmail.com  Wed Aug 22 16:23:47 2018
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Wed, 22 Aug 2018 15:23:47 -0500
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
 <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
Message-ID: <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>

On Wed, Aug 22, 2018 at 3:02 PM Brad King <brad.king at kitware.com> wrote:

> On 08/22/2018 03:49 PM, Richard Shaw wrote:
> > Initially I tried setting the flags before invoking "project" and that
> seemed
> > to be enough for Fedora. I've tried other things as well that I've
> probably
> > forgotten but one other method I tried was:
> >
> > set(CMAKE_REQUIRED_DEFINITIONS "--specs=nosys.specs")
>
> That's only used by Check* modules.  It does not affect flags in general.
>

Good to know, I can remove that.



> From the ubuntu issue:
>
> > The target system is: Generic - 1 - arm
> > The host system is: Linux - 4.15.0-32-generic - x86_64
>
> You're cross-compiling.  What is your CMAKE_TOOLCHAIN_FILE?
>

Yes, I could have worded it better but I have tried passing the toolchain
file on the command line with the same result. Currently I'm using an
"include" of the toolchain file prior to calling "project" since 100% of
development happens on a PC instead of having to pass the
CMAKE_TOOLCHAIN_FILE option every time.

Here's the contents:

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSTEM_VERSION 1)


# specify the cross compiler
set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-cpp)

set(CMAKE_EXE_LINKER_FLAGS "-T${CMAKE_SOURCE_DIR}/stm32_flash.ld")
set(CMAKE_EXECUTABLE_SUFFIX_C ".elf")
set(CMAKE_EXECUTABLE_SUFFIX_CXX ".elf")
set(CMAKE_EXECUTABLE_SUFFIX_ASM ".elf")

# Macro for elf->bin
macro(elf2bin target)
    add_custom_command(TARGET ${target}
    POST_BUILD COMMAND ${CMAKE_OBJCOPY} -O binary ${target}.elf
${target}.bin
    COMMENT "Creating binary for ${target}")
endmacro()

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/16decfa1/attachment.html>

From brad.king at kitware.com  Wed Aug 22 16:32:18 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 22 Aug 2018 16:32:18 -0400
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
 <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
 <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>
Message-ID: <21e3f070-06ff-12f9-039a-6613ce6e4bfc@kitware.com>

On 08/22/2018 04:23 PM, Richard Shaw wrote:
> Currently I'm using an "include" of the toolchain file prior to calling
> "project" since 100% of development happens on a PC instead of having
> to pass the CMAKE_TOOLCHAIN_FILE option every time.

CMAKE_TOOLCHAIN_FILE must be used in order to be properly included
by try_compile projects and such.  One can't just include() it
manually.

> Here's the contents:
> 
> set(CMAKE_SYSTEM_NAME Generic)
> set(CMAKE_SYSTEM_PROCESSOR arm)
> set(CMAKE_SYSTEM_VERSION 1)
> 
> # specify the cross compiler
> set(CMAKE_C_COMPILER arm-none-eabi-gcc)
> set(CMAKE_CXX_COMPILER arm-none-eabi-cpp)

Add

```
set(CMAKE_C_FLAGS_INIT "--specs=nosys.specs")
set(CMAKE_CXX_FLAGS_INIT "--specs=nosys.specs")
```

and be sure to use CMake 3.7 or higher.

-Brad

From smeenai at fb.com  Wed Aug 22 17:01:53 2018
From: smeenai at fb.com (Shoaib Meenai)
Date: Wed, 22 Aug 2018 21:01:53 +0000
Subject: [CMake] Why does pkg_check_modules not use CMAKE_SYSTEM_PREFIX_PATH?
Message-ID: <E62D8DC6-31CE-404F-BE42-B8F25BC34F03@fb.com>

Hi,

I'm using CMake for cross-compilation, and I have a toolchain file which sets CMAKE_SYSTEM_PREFIX_PATH accordingly. I'm running into issues with pkg_check_modules not finding some modules because it only searches inside CMAKE_PREFIX_PATH and not CMAKE_SYSTEM_PREFIX_PATH (where my *.pc files are located).

I'm wondering why this is the case. From my understanding, CMAKE_SYSTEM_PREFIX_PATH is intended to contain prefixes for the system, and CMAKE_PREFIX_PATH is intended to contain prefixes for the project. In this case, since I'm cross-compiling (which defines my "system"), it seems appropriate to set CMAKE_SYSTEM_PREFIX_PATH inside my toolchain file, but then that doesn't end up influencing the pkg-config search as I would like.

Should I be setting CMAKE_PREFIX_PATH inside my toolchain file, either instead of or in addition to CMAKE_SYSTEM_PREFIX_PATH, or should pkg_check_modules also honor CMAKE_SYSTEM_PREFIX_PATH? I suppose another option would be to set the PKG_CONFIG_PATH environment variable inside my toolchain file directly, but that seems kinda ugly.

Thanks,
Shoaib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180822/924833b2/attachment.html>

From petr.kmoch at gmail.com  Thu Aug 23 06:01:47 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 23 Aug 2018 12:01:47 +0200
Subject: [CMake] Is cmake failed with any Error message?
In-Reply-To: <CAMi=NdJFFfQ9Was1OhO_8uE=0nK5PCApKF12QNLz6qzpaM_=8A@mail.gmail.com>
References: <CAMi=NdJFFfQ9Was1OhO_8uE=0nK5PCApKF12QNLz6qzpaM_=8A@mail.gmail.com>
Message-ID: <CAKohaZf4axchjZh_0EC=w=bc5YoMWLJ4NZRny40iT_ZQT1mmfA@mail.gmail.com>

Hi Maomao.

The output includes this line:

  Configuring incomplete, errors occurred!

This means that indeed, CMake has failed to configure the project. Which
means no Makefile (or oher buildsystem) was generated and therefore the
project cannot be built.

A successful run of CMake ends with output like this:

  Configuring done
  Generating done
  Build files have been written to ...

Petr

On Mon, 13 Aug 2018 at 09:13, maomao <maomaowyh at gmail.com> wrote:

> Dear admin,
>
> I am trying to build a project that is a open source and have a package on
> the website.
> The required binaries are installed by macports on my macbook pro with
> OSX10.13.6 (High Sierra).
> When I tried to cmake the project, I got the output message as:
>
> es2039:build maomao$ cmake ..
>
> -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
>
> -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
> OpenMP_CXX_LIB_NAMES)
>
> -- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND)
>
> -- HDF5: Using hdf5 compiler wrapper to determine C configuration
>
> CMake Error at /opt/local/share/cmake-3.12/Modules/UseSWIG.cmake:509
> (message):
>
>   SWIG_ADD_LIBRARY: python;quakelib.i: unexpected arguments
>
> Call Stack (most recent call first):
>
>   quakelib/python/CMakeLists.txt:10 (SWIG_ADD_LIBRARY)
>
>
>
> -- Configuring incomplete, errors occurred!
>
> See also "/Users/maomao/VirtualTaiwan/build/CMakeFiles/CMakeOutput.log".
>
> and failed when I proceeded to make.
> So, the question is:
> Is the project configured or not with any error message like that?
> What kind output should I see when I succeed to configure the project by
> cmake?
> If cmake is failed to configure project, the code could not be build by
> make anyway?
>
> Best,
> Maomao
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180823/ee3b32c7/attachment-0001.html>

From george.p.f at mail.com  Thu Aug 23 06:57:16 2018
From: george.p.f at mail.com (George PF)
Date: Thu, 23 Aug 2018 12:57:16 +0200
Subject: [CMake] Adding an individual define to each source file of a library
Message-ID: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>

Hello,

following "modern cmake" conventions I want to create a library where every single file is compiled with an individual define (-D_fileX_, required for a macro which integrates code into every translation unit).

So following this

    add_library(mylib SHARED file1.c file2.c)
    target_link_libraries(mylib PUBLIC otherlib)

I'd like to iterate over all "mylib" source file targets and modify them so that the compiler is called like this:

    cc -c -o file1.o file1.cc -D_file1_define_
    cc -c -o file1.o file2.cc -D_file2_define_
    etc.

Is this possible?


Regards

GPF

From djobet at tower-research.com  Thu Aug 23 07:50:14 2018
From: djobet at tower-research.com (David Jobet)
Date: Thu, 23 Aug 2018 12:50:14 +0100
Subject: [CMake] protobuf and imports relative to root (and --proto_path)
Message-ID: <CAAV-JT4+MKTDDud-w8j3YTVbm-5htp014VWDTOjbBswhwY9n6A@mail.gmail.com>

Hello,

I'm trying to port an existing project from premake to cmake.
I'm trying to avoid modifying the source files while doing so.

Right now, we have several libraries (read in different directories) using
proto files with imports between them.
All imports are made relative to the root of the project.

e.g :
work/lib1/sublib1/a.proto
work/lib1/sublib1/b.proto

with a.proto having a link to b.proto like this "import
lib1/sublib1/b.proto"

If I compile this with an unchanged FindProtobuf.cmake, I do this :

protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
add_library(...)

the problem being that it looks like the "namespaces" generated by protoc
in b.proto do not match the one used in a.proto : it does not compile.

Is there a way to make this work ?

Otherwise, I made the patch below which solves my problem. Do you think it
could be included in cmake ?
it defines a new option PROTO_PATH, so the decl above becomes
protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
a.proto b.proto)

With regards

David

$ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
share/cmake-3.10/Modules/FindProtobuf.cmake
123c123
<   cmake_parse_arguments(protobuf "" "EXPORT_MACRO;DESCRIPTORS" "" ${ARGN})
---
>   cmake_parse_arguments(protobuf "" "PROTO_PATH;EXPORT_MACRO;DESCRIPTORS"
"" ${ARGN})
130a131,139
>   set(EXTRA_ARGS "")
>   set(OUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
>   if(protobuf_PROTO_PATH)
>     get_filename_component(ABS_PROTO_PATH ${protobuf_PROTO_PATH} ABSOLUTE)
>     set(EXTRA_ARGS "--proto_path=${ABS_PROTO_PATH}")
>     file(RELATIVE_PATH PROTO_REL_PATH ${CMAKE_SOURCE_DIR}
${ABS_PROTO_PATH})
>     set(OUT_PATH ${CMAKE_BINARY_DIR}/${PROTO_REL_PATH})
>   endif()
>
198c207,208
<                "--cpp_out=${DLL_EXPORT_DECL}${CMAKE_CURRENT_BINARY_DIR}"
---
>                ${EXTRA_ARGS}
>                "--cpp_out=${DLL_EXPORT_DECL}${OUT_PATH}"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180823/cbad2f44/attachment.html>

From raphael.grimm at kit.edu  Thu Aug 23 08:03:15 2018
From: raphael.grimm at kit.edu (Raphael Grimm)
Date: Thu, 23 Aug 2018 14:03:15 +0200
Subject: [CMake] Export a custom property of a target
In-Reply-To: <CAHKTGrewWsZk2MowNeRSf77wiaNsX=7_8GnLmCdVi8Qk7Xa+-Q@mail.gmail.com>
References: <cfbb11fa-49b0-cdab-79eb-3bc87209a4cc@kit.edu>
 <CAHKTGrewWsZk2MowNeRSf77wiaNsX=7_8GnLmCdVi8Qk7Xa+-Q@mail.gmail.com>
Message-ID: <0abec528-8962-226e-a4ea-779a37233938@kit.edu>

I am using it for passing meta-data between my projects.

Is there a way to do this with cmake 3.10.2 (I am on Ubuntu 18)?


On 22.08.2018 16:03, Marc CHEVRIER wrote:
> 'define_property' is nearly useless except for documentation.
>
> Export of custom properties is managed through target property 
> 'EXPORT_PROPERTIES'.
>
>
> Le?mer. 22 ao?t 2018 ??15:58, Raphael Grimm <raphael.grimm at kit.edu 
> <mailto:raphael.grimm at kit.edu>> a ?crit?:
>
>     Hi,
>
>     I added a custom target property via 'define_property'
>     (https://cmake.org/cmake/help/latest/command/define_property.html).
>
>     When using this target in a different cmake project the property
>     is not
>     found by cmake and the meta information stored in the target
>     property is
>     lost.
>
>     Is there a way to also export custom target properties?
>
>     Regards
>
>     Raphael
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180823/95ddac51/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5205 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://cmake.org/pipermail/cmake/attachments/20180823/95ddac51/attachment.bin>

From roman.wueger at gmx.at  Thu Aug 23 08:36:59 2018
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 23 Aug 2018 14:36:59 +0200
Subject: [CMake] Android project with CMake and Visual Studio and
 without Nsight Tegra
In-Reply-To: <687DA6A7-7A6A-4F21-953E-2BA8E70F2399@gmx.at>
References: <F29AC789-2AFE-4B76-923F-A64909F86DE9@gmx.at>
 <687DA6A7-7A6A-4F21-953E-2BA8E70F2399@gmx.at>
Message-ID: <E78BC3ED-3D9B-4376-802E-B1F1FE9C93C4@gmx.at>

No one?

> Am 15.08.2018 um 17:01 schrieb Roman W?ger <roman.wueger at gmx.at>:
> 
> Why isn?t it enough to install the SDK and NDK?
> 
> Regards
> Roman
> 
>> Am 09.08.2018 um 09:02 schrieb Roman W?ger <roman.wueger at gmx.at>:
>> 
>> Hello,
>> 
>> is it somehow possible to build an Android project with CMake and Visual Studio without the Nsight Tegra Visual Studio Edition? Because the installation of NVIDIA Nsight Tegra hangs during configuring the Visual Studio 2017 in a Virtual Machine.
>> 
>> Thanks in advance
>> 
>> Best Regards
>> -- 
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake


From eric.noulard at gmail.com  Thu Aug 23 08:39:41 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 23 Aug 2018 14:39:41 +0200
Subject: [CMake] Adding an individual define to each source file of a
 library
In-Reply-To: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
References: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
Message-ID: <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>

Le jeu. 23 ao?t 2018 ? 13:02, George PF <george.p.f at mail.com> a ?crit :

> Hello,
>
> following "modern cmake" conventions I want to create a library where
> every single file is compiled with an individual define (-D_fileX_,
> required for a macro which integrates code into every translation unit).
>
> So following this
>
>     add_library(mylib SHARED file1.c file2.c)
>     target_link_libraries(mylib PUBLIC otherlib)
>
> I'd like to iterate over all "mylib" source file targets and modify them
> so that the compiler is called like this:
>
>     cc -c -o file1.o file1.cc -D_file1_define_
>     cc -c -o file1.o file2.cc -D_file2_define_
>     etc.
>
> Is this possible?
>

You can retrieve the sources associated with a target using SOURCES
properties.
https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

then
https://cmake.org/cmake/help/latest/command/foreach.html
with
https://cmake.org/cmake/help/latest/command/set_property.html
or
https://cmake.org/cmake/help/latest/command/set_source_files_properties.html

for setting property:
https://cmake.org/cmake/help/latest/prop_sf/COMPILE_DEFINITIONS.html

on each source file.

not sure why you want to do that you know that compiler already defined
many "standard" macro for you, like __FILE__
https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros
?

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

From george.p.f at mail.com  Thu Aug 23 12:31:38 2018
From: george.p.f at mail.com (George PF)
Date: Thu, 23 Aug 2018 18:31:38 +0200
Subject: [CMake] Adding an individual define to each source file of a
 library
In-Reply-To: <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>
References: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
 <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>
Message-ID: <trinity-e387669c-a358-41dd-b8f5-4ca57016d539-1535041898800@3c-app-mailcom-lxa13>

Thank you for the precise pointers, I added to the same CMakeLists.txt:
 
    get_property(mysrcs TARGET mylib PROPERTY SOURCES)

    foreach(x IN LISTS mysrcs)
        message("at ${x}")
        set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")
    #    set_source_files_properties(x PROPERTIES COMPILE_DEFINITIONS "TEST1;TEST2;") # also not working
    endforeach(x)

However, whatever I write into 'set_property()' - no APPEND, single entry, not quoted - does not end up 
on the compiler command line. Is there a type mismatch which is silently ignored?

As to __FILE__ or similar, the define is used as a variable, i.e. the .c suffix would have to be removed 
via the c processor. The current directory is also used. I think replacing .c and appending the name of 
the current directory will be easier in cmake.


> Le jeu. 23 ao?t 2018 ? 13:02, George PF <george.p.f at mail.com> a ?crit :
> 
> > Hello,
> >
> > following "modern cmake" conventions I want to create a library where
> > every single file is compiled with an individual define (-D_fileX_,
> > required for a macro which integrates code into every translation unit).
> >
> > So following this
> >
> >     add_library(mylib SHARED file1.c file2.c)
> >     target_link_libraries(mylib PUBLIC otherlib)
> >
> > I'd like to iterate over all "mylib" source file targets and modify them
> > so that the compiler is called like this:
> >
> >     cc -c -o file1.o file1.cc -D_file1_define_
> >     cc -c -o file1.o file2.cc -D_file2_define_
> >     etc.
> >
> > Is this possible?
> >
> 
> You can retrieve the sources associated with a target using SOURCES
> properties.
> https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html
> 
> then
> https://cmake.org/cmake/help/latest/command/foreach.html
> with
> https://cmake.org/cmake/help/latest/command/set_property.html
> or
> https://cmake.org/cmake/help/latest/command/set_source_files_properties.html
> 
> for setting property:
> https://cmake.org/cmake/help/latest/prop_sf/COMPILE_DEFINITIONS.html
> 
> on each source file.
> 
> not sure why you want to do that you know that compiler already defined
> many "standard" macro for you, like __FILE__
> https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros
> ?
> 
> -- 
> Eric

From eric.noulard at gmail.com  Thu Aug 23 12:47:38 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 23 Aug 2018 18:47:38 +0200
Subject: [CMake] Adding an individual define to each source file of a
 library
In-Reply-To: <trinity-e387669c-a358-41dd-b8f5-4ca57016d539-1535041898800@3c-app-mailcom-lxa13>
References: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
 <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>
 <trinity-e387669c-a358-41dd-b8f5-4ca57016d539-1535041898800@3c-app-mailcom-lxa13>
Message-ID: <CAPASGLoQPdpK2xs30RXM_AkzwqJbSKvNR+oB4xBWgDSom3wR0w@mail.gmail.com>

Le jeu. 23 ao?t 2018 ? 18:31, George PF <george.p.f at mail.com> a ?crit :

> Thank you for the precise pointers, I added to the same CMakeLists.txt:
>
>     get_property(mysrcs TARGET mylib PROPERTY SOURCES)
>
>     foreach(x IN LISTS mysrcs)
>         message("at ${x}")
>         set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS
> "TEST1;TEST2;")
>     #    set_source_files_properties(x PROPERTIES COMPILE_DEFINITIONS
> "TEST1;TEST2;") # also not working
>     endforeach(x)
>
> However, whatever I write into 'set_property()' - no APPEND, single entry,
> not quoted - does not end up
> on the compiler command line. Is there a type mismatch which is silently
> ignored?
>

Or you are doing this in a directory which is not the one where the target
is defined and from the doc:
$ cmake --help-command set_property

...
``SOURCE``
  Scope may name zero or more source files.  Note that source
  file properties are visible only to targets added in the same
  directory (CMakeLists.txt).

...


> As to __FILE__ or similar, the define is used as a variable, i.e. the .c
> suffix would have to be removed
> via the c processor. The current directory is also used. I think replacing
> .c and appending the name of
> the current directory will be easier in cmake.
>
>
> > Le jeu. 23 ao?t 2018 ? 13:02, George PF <george.p.f at mail.com> a
> ?crit :
> >
> > > Hello,
> > >
> > > following "modern cmake" conventions I want to create a library where
> > > every single file is compiled with an individual define (-D_fileX_,
> > > required for a macro which integrates code into every translation
> unit).
> > >
> > > So following this
> > >
> > >     add_library(mylib SHARED file1.c file2.c)
> > >     target_link_libraries(mylib PUBLIC otherlib)
> > >
> > > I'd like to iterate over all "mylib" source file targets and modify
> them
> > > so that the compiler is called like this:
> > >
> > >     cc -c -o file1.o file1.cc -D_file1_define_
> > >     cc -c -o file1.o file2.cc -D_file2_define_
> > >     etc.
> > >
> > > Is this possible?
> > >
> >
> > You can retrieve the sources associated with a target using SOURCES
> > properties.
> > https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html
> >
> > then
> > https://cmake.org/cmake/help/latest/command/foreach.html
> > with
> > https://cmake.org/cmake/help/latest/command/set_property.html
> > or
> >
> https://cmake.org/cmake/help/latest/command/set_source_files_properties.html
> >
> > for setting property:
> > https://cmake.org/cmake/help/latest/prop_sf/COMPILE_DEFINITIONS.html
> >
> > on each source file.
> >
> > not sure why you want to do that you know that compiler already defined
> > many "standard" macro for you, like __FILE__
> >
> https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros
> > ?
> >
> > --
> > Eric
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


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

From brad.king at kitware.com  Thu Aug 23 12:58:44 2018
From: brad.king at kitware.com (Brad King)
Date: Thu, 23 Aug 2018 12:58:44 -0400
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <21e3f070-06ff-12f9-039a-6613ce6e4bfc@kitware.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
 <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
 <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>
 <21e3f070-06ff-12f9-039a-6613ce6e4bfc@kitware.com>
Message-ID: <4bffbf80-f08b-cedd-23e4-d17a457170fe@kitware.com>

On 08/22/2018 04:23 PM, Richard Shaw wrote:
> Here's the contents:
>
> set(CMAKE_EXECUTABLE_SUFFIX_C ".elf")
> set(CMAKE_EXECUTABLE_SUFFIX_CXX ".elf")
> set(CMAKE_EXECUTABLE_SUFFIX_ASM ".elf")
[snip]
On 08/22/2018 05:05 PM, Richard Shaw wrote:
> One step closer:
> ...me forcing the binary output to have a .elf extension is confusing cmake:
>
> Unable to find the executable at any of:
>   /home/richard/build/stm32/CMakeFiles/CMakeTmp/cmTC_64527
>   /home/richard/build/stm32/CMakeFiles/CMakeTmp/Debug/cmTC_64527
>   /home/richard/build/stm32/CMakeFiles/CMakeTmp/Development/cmTC_64527

Ah, that's a bug.  I've just opened this issue:

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

Meanwhile you can use just

  set(CMAKE_EXECUTABLE_SUFFIX ".elf")

instead.

-Brad

From george.p.f at mail.com  Thu Aug 23 13:18:32 2018
From: george.p.f at mail.com (George PF)
Date: Thu, 23 Aug 2018 19:18:32 +0200
Subject: [CMake] Adding an individual define to each source file of a
 library
In-Reply-To: <CAPASGLoQPdpK2xs30RXM_AkzwqJbSKvNR+oB4xBWgDSom3wR0w@mail.gmail.com>
References: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
 <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>
 <trinity-e387669c-a358-41dd-b8f5-4ca57016d539-1535041898800@3c-app-mailcom-lxa13>
 <CAPASGLoQPdpK2xs30RXM_AkzwqJbSKvNR+oB4xBWgDSom3wR0w@mail.gmail.com>
Message-ID: <trinity-3ea6deeb-0870-4d8b-ae39-1953ed9ddf07-1535044712334@3c-app-mailcom-lxa13>

> > However, whatever I write into 'set_property()' - no APPEND, single entry,
> > not quoted - does not end up
> > on the compiler command line. Is there a type mismatch which is silently
> > ignored?
> >
> 
> Or you are doing this in a directory which is not the one where the target
> is defined and from the doc:
> $ cmake --help-command set_property
> 
> ...
> ``SOURCE``
>   Scope may name zero or more source files.  Note that source
>   file properties are visible only to targets added in the same
>   directory (CMakeLists.txt).
> 
> ...

This is all in the same directory, full setup and test:

    % cmake --version
    cmake version 3.12.0   [..]
    % mkdir mylib && cd mylib
    mylib% touch file1.c file2.c
    mylib% cat > CMakeLists.txt

    cmake_minimum_required(VERSION 3.12)
    
    add_library(mylib SHARED file1.c file2.c)
    
    get_property(mysrcs TARGET mylib PROPERTY SOURCES)
    foreach(x IN LISTS mysrcs)
        message("at ${x}")
        set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")
    endforeach(x)
    # ^D

    mylib% mkdir build && cd build && cmake ..
    [..]
    at file1.c
    at file2.c
    -- Configuring done
    [..]
    mylibs/build% grep -r TEST1 . || echo no TEST1
    no TEST1

and 'make VERBOSE=1' also shows no extra -DTEST1 compiler arguments.

From mike.jackson at bluequartz.net  Thu Aug 23 13:47:18 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 23 Aug 2018 13:47:18 -0400
Subject: [CMake] Copy file from Source to Build dir based on CMAKE_CFG_INTDIR
Message-ID: <16627E00-B5FA-40D1-BFB4-AD08A939614F@bluequartz.net>

I would like to copy some files from my source dir into my binary RUNTIME_DIR based on the current configuration being compiled. For generators like ?makefiles? and ?ninja? this is easy and straight forward. I am having an issue getting my head wrapped around how to use CMAKE_CFG_INTDIR properly.

 

I know I can?t do this a cmake time so I tried the following:

 

During CMake time write out another CMake file:

 

? file(APPEND "${PYSIMPL_SCRIPT_COPY_RULE}" 

????"execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different

????? \"${SIMPLPyBind11_SOURCE_DIR}/../Testing/${script}\" 

??????\"${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/\${CMAKE_CFG_INTDIR}/python/site-packages/${script}\")\n"

? )

 

Which creates entries like this in the written .cmake file:

 

execute_process(COMMAND C:/DREAM3D_SDK/cmake-3.12.0-rc2-win64-x64/bin/cmake.exe -E copy_if_different

????? "C:/Users/mjackson/DREAM3D-Dev/DREAM3D/ExternalProjects/SIMPL/Wrapping/Python/Pybind11/../Testing/AbstractFilterTest.py" 

??????"C:/Users/mjackson/DREAM3D-Dev/DREAM3D-Builds/x64/Bin/${CMAKE_CFG_INTDIR}/python/site-packages/AbstractFilterTest.py")

 

Which does not work. The files end up in ${BUILD_DIR}/Bin/python/site-packages/. I need them to end up in ${BUILD_DIR}/Bin/Release/python/site-packages for a Release build. Same for Debug?

 

Could someone tell me what I am doing wrong or the proper way to go about this? I am about ready to write a simple C++ program to do the copy for me (which seems ludicrous to have to do..)

--

Michael Jackson | Owner, President

      BlueQuartz Software

[e] mike.jackson at bluequartz.net

[w] www.bluequartz.net

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

From robert.maynard at kitware.com  Thu Aug 23 13:58:28 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 23 Aug 2018 13:58:28 -0400
Subject: [CMake] Copy file from Source to Build dir based on
 CMAKE_CFG_INTDIR
In-Reply-To: <16627E00-B5FA-40D1-BFB4-AD08A939614F@bluequartz.net>
References: <16627E00-B5FA-40D1-BFB4-AD08A939614F@bluequartz.net>
Message-ID: <CAFzjYVrVraQv0eNkNhi7jsgnh1d4T0cWXAiXzy5bLfDfvhBOPA@mail.gmail.com>

You can use `file(GENERATE` and the `$<CONFIG>` generator expression.

Here is an example:
https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Tests/CudaOnly/ExportPTX/CMakeLists.txt#L13
On Thu, Aug 23, 2018 at 1:47 PM Michael Jackson
<mike.jackson at bluequartz.net> wrote:
>
> I would like to copy some files from my source dir into my binary RUNTIME_DIR based on the current configuration being compiled. For generators like ?makefiles? and ?ninja? this is easy and straight forward. I am having an issue getting my head wrapped around how to use CMAKE_CFG_INTDIR properly.
>
>
>
> I know I can?t do this a cmake time so I tried the following:
>
>
>
> During CMake time write out another CMake file:
>
>
>
>   file(APPEND "${PYSIMPL_SCRIPT_COPY_RULE}"
>
>     "execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different
>
>       \"${SIMPLPyBind11_SOURCE_DIR}/../Testing/${script}\"
>
>       \"${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/\${CMAKE_CFG_INTDIR}/python/site-packages/${script}\")\n"
>
>   )
>
>
>
> Which creates entries like this in the written .cmake file:
>
>
>
> execute_process(COMMAND C:/DREAM3D_SDK/cmake-3.12.0-rc2-win64-x64/bin/cmake.exe -E copy_if_different
>
>       "C:/Users/mjackson/DREAM3D-Dev/DREAM3D/ExternalProjects/SIMPL/Wrapping/Python/Pybind11/../Testing/AbstractFilterTest.py"
>
>       "C:/Users/mjackson/DREAM3D-Dev/DREAM3D-Builds/x64/Bin/${CMAKE_CFG_INTDIR}/python/site-packages/AbstractFilterTest.py")
>
>
>
> Which does not work. The files end up in ${BUILD_DIR}/Bin/python/site-packages/. I need them to end up in ${BUILD_DIR}/Bin/Release/python/site-packages for a Release build. Same for Debug?
>
>
>
> Could someone tell me what I am doing wrong or the proper way to go about this? I am about ready to write a simple C++ program to do the copy for me (which seems ludicrous to have to do..)
>
> --
>
> Michael Jackson | Owner, President
>
>       BlueQuartz Software
>
> [e] mike.jackson at bluequartz.net
>
> [w] www.bluequartz.net
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From eric.noulard at gmail.com  Thu Aug 23 14:58:23 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 23 Aug 2018 20:58:23 +0200
Subject: [CMake] Adding an individual define to each source file of a
 library
In-Reply-To: <trinity-3ea6deeb-0870-4d8b-ae39-1953ed9ddf07-1535044712334@3c-app-mailcom-lxa13>
References: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
 <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>
 <trinity-e387669c-a358-41dd-b8f5-4ca57016d539-1535041898800@3c-app-mailcom-lxa13>
 <CAPASGLoQPdpK2xs30RXM_AkzwqJbSKvNR+oB4xBWgDSom3wR0w@mail.gmail.com>
 <trinity-3ea6deeb-0870-4d8b-ae39-1953ed9ddf07-1535044712334@3c-app-mailcom-lxa13>
Message-ID: <CAPASGLqfx1rcTyzaJU4=H+BOcXidRXUtjqzYps5F9VWGA+kBzA@mail.gmail.com>

Le jeu. 23 ao?t 2018 ? 19:18, George PF <george.p.f at mail.com> a ?crit :

> > > However, whatever I write into 'set_property()' - no APPEND, single
> entry,
> > > not quoted - does not end up
> > > on the compiler command line. Is there a type mismatch which is
> silently
> > > ignored?
> > >
> >
> > Or you are doing this in a directory which is not the one where the
> target
> > is defined and from the doc:
> > $ cmake --help-command set_property
> >
> > ...
> > ``SOURCE``
> >   Scope may name zero or more source files.  Note that source
> >   file properties are visible only to targets added in the same
> >   directory (CMakeLists.txt).
> >
> > ...
>
> This is all in the same directory, full setup and test:
>
>     % cmake --version
>     cmake version 3.12.0   [..]
>     % mkdir mylib && cd mylib
>     mylib% touch file1.c file2.c
>     mylib% cat > CMakeLists.txt
>
>     cmake_minimum_required(VERSION 3.12)
>
>     add_library(mylib SHARED file1.c file2.c)
>
>     get_property(mysrcs TARGET mylib PROPERTY SOURCES)
>     foreach(x IN LISTS mysrcs)
>         message("at ${x}")
>         set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS
> "TEST1;TEST2;")
>

almost there but you forgot to take value of 'x'

set_property(SOURCE ${x} APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")

works for me.





>     endforeach(x)
>     # ^D
>
>     mylib% mkdir build && cd build && cmake ..
>     [..]
>     at file1.c
>     at file2.c
>     -- Configuring done
>     [..]
>     mylibs/build% grep -r TEST1 . || echo no TEST1
>     no TEST1
>
> and 'make VERBOSE=1' also shows no extra -DTEST1 compiler arguments.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180823/670367b7/attachment.html>

From mike.jackson at bluequartz.net  Thu Aug 23 14:59:57 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 23 Aug 2018 14:59:57 -0400
Subject: [CMake] Copy file from Source to Build dir based on
 CMAKE_CFG_INTDIR
In-Reply-To: <CAFzjYVrVraQv0eNkNhi7jsgnh1d4T0cWXAiXzy5bLfDfvhBOPA@mail.gmail.com>
References: <16627E00-B5FA-40D1-BFB4-AD08A939614F@bluequartz.net>
 <CAFzjYVrVraQv0eNkNhi7jsgnh1d4T0cWXAiXzy5bLfDfvhBOPA@mail.gmail.com>
Message-ID: <9B13DDAE-9FDF-47F3-A79C-42B010B677DC@bluequartz.net>

Hmm, That works great for MSVC compiles but not so great when I use ninja or makefiles (any of the single config generators). I was looking through the generator expressions on the Cmake doc site but didn't really come across anything that seems like it would get me what is needed. I guess I just put in:

If(MSVC or Xcode)
  Do this
Else()
  Do that
Endif().

Seems like this should just not be needed...

--
Mike Jackson 

?On 8/23/18, 1:59 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:

    You can use `file(GENERATE` and the `$<CONFIG>` generator expression.
    
    Here is an example:
    https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Tests/CudaOnly/ExportPTX/CMakeLists.txt#L13
    On Thu, Aug 23, 2018 at 1:47 PM Michael Jackson
    <mike.jackson at bluequartz.net> wrote:
    >
    > I would like to copy some files from my source dir into my binary RUNTIME_DIR based on the current configuration being compiled. For generators like ?makefiles? and ?ninja? this is easy and straight forward. I am having an issue getting my head wrapped around how to use CMAKE_CFG_INTDIR properly.
    >
    >
    >
    > I know I can?t do this a cmake time so I tried the following:
    >
    >
    >
    > During CMake time write out another CMake file:
    >
    >
    >
    >   file(APPEND "${PYSIMPL_SCRIPT_COPY_RULE}"
    >
    >     "execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different
    >
    >       \"${SIMPLPyBind11_SOURCE_DIR}/../Testing/${script}\"
    >
    >       \"${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/\${CMAKE_CFG_INTDIR}/python/site-packages/${script}\")\n"
    >
    >   )
    >
    >
    >
    > Which creates entries like this in the written .cmake file:
    >
    >
    >
    > execute_process(COMMAND C:/DREAM3D_SDK/cmake-3.12.0-rc2-win64-x64/bin/cmake.exe -E copy_if_different
    >
    >       "C:/Users/mjackson/DREAM3D-Dev/DREAM3D/ExternalProjects/SIMPL/Wrapping/Python/Pybind11/../Testing/AbstractFilterTest.py"
    >
    >       "C:/Users/mjackson/DREAM3D-Dev/DREAM3D-Builds/x64/Bin/${CMAKE_CFG_INTDIR}/python/site-packages/AbstractFilterTest.py")
    >
    >
    >
    > Which does not work. The files end up in ${BUILD_DIR}/Bin/python/site-packages/. I need them to end up in ${BUILD_DIR}/Bin/Release/python/site-packages for a Release build. Same for Debug?
    >
    >
    >
    > Could someone tell me what I am doing wrong or the proper way to go about this? I am about ready to write a simple C++ program to do the copy for me (which seems ludicrous to have to do..)
    >
    > --
    >
    > Michael Jackson | Owner, President
    >
    >       BlueQuartz Software
    >
    > [e] mike.jackson at bluequartz.net
    >
    > [w] www.bluequartz.net
    >
    > --
    >
    > Powered by www.kitware.com
    >
    > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
    >
    > Kitware offers various services to support the CMake community. For more information on each offering, please visit:
    >
    > CMake Support: http://cmake.org/cmake/help/support.html
    > CMake Consulting: http://cmake.org/cmake/help/consulting.html
    > CMake Training Courses: http://cmake.org/cmake/help/training.html
    >
    > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
    >
    > Follow this link to subscribe/unsubscribe:
    > https://cmake.org/mailman/listinfo/cmake
    



From smancill at jlab.org  Thu Aug 23 16:13:38 2018
From: smancill at jlab.org (=?UTF-8?Q?Sebasti=C3=A1n_Mancilla?=)
Date: Thu, 23 Aug 2018 17:13:38 -0300
Subject: [CMake] Problem with creating shared library
In-Reply-To: <AM0PR0202MB3411B5060BE2347A67379D4AE5300@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
 <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>
 <CAJPSwc0XYgxVQHCwjofA2hARUAfXjc4J=Xb=v3u8Sz4khHNTOw@mail.gmail.com>
 <AM0PR0202MB3411B5060BE2347A67379D4AE5300@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <CAJPSwc2bsJVNPV5fPsQS_O-geLMZLmHoLqOGT66RWmYLZCgVMQ@mail.gmail.com>

I forgot to update the include path in the patch I sent you.

It should be like this (note that it contains just "include", not
"include/kImageAnnotator"):

target_include_directories(kImageAnnotator
        PUBLIC
        $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
        $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
        $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
        )

And kImageAnnotator.h should change the export include to:

#include "kImageAnnotatorExport.h"


You still have a bigger problem, though. kImageAnnotator.h is including
private headers

#include "../../src/gui/VisibilitySwitcher.h"
#include "../../src/annotations/core/AnnotationArea.h"
#include "../../src/backend/Config.h"
#include "../../src/widgets/ToolPicker.h"
#include "../../src/widgets/ColorPicker.h"
#include "../../src/widgets/SizePicker.h"
#include "../../src/widgets/FillPicker.h"

If those are required by your clients, then they should be in the
"include/kImageAnnotator" directory and installed along with
"kImageAnnotator.h".
Otherwise, consider using the pimpl idiom and remove the includes from the
public header.


El mi?., 22 de ago. de 2018 a la(s) 17:08, Damir Porobic (
damir_porobic at live.com) escribi?:

> Thanks you Sebasti?n for finding the issue and fixing the CMake, probably
> would have never found out that it was set to private.
>
>
> The kImageAnnotator-example is working now as expected. Do I need
> something else, except installing the lib, in order to use it in different
> projects? I've created a second project which is identical to the
> kImageAnnotator-example but I get following when I try to build it:
>
>
> [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
> In file included from /home/dporobic/projects/testApp/main.cpp:2:0:
> /usr/local/include/kImageAnnotator/KImageAnnotator.h:31:35: fatal error:
> KImageAnnotatorExport.h: No such file or directory
>  #include <KImageAnnotatorExport.h>
>                                    ^
> compilation terminated.
>
> The includes look like this:
>
> #include <QApplication>
> #include <kImageAnnotator/KImageAnnotator.h>
>
>
> And the CMake looks like this:
>
> find_package(kImageAnnotator REQUIRED)
>
> add_executable(testApp main.cpp)
> target_link_libraries(testApp kImageAnnotator)
>
>
> Am I missing something again?
>
>
>
> ------------------------------
> *From:* Sebasti?n Mancilla <smancill at jlab.org>
> *Sent:* Wednesday, August 22, 2018 00:51
> *To:* Eric Noulard
> *Cc:* Damir Porobic; cmake at cmake.org
> *Subject:* Re: [CMake] Problem with creating shared library
>
> I fixed your problem. Get the attached patch and apply it with "git apply
> <patch_file>".
>
> The kImageAnnotator constructor was private to the library (I just learned
> that Qt does that when creating shared libraries), and that's why you get
> the undefined reference error. You could have checked it with:
>
> nm lib/libkImageAnnotator.so | c++filt | grep ::KImage
> 00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)
> 00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)
>
> The "t" shows it is private.
>
> You have to set the proper export macros to make it visible:
>
>
> https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qt.io_How-5Fto-5Fcreate-5Fa-5Flibrary-5Fwith-5FQt-5Fand-5Fuse-5Fit-5Fin-5Fan-5Fapplication&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=WmSjv8Q5QDreoWKNX4mS9hZm6lMR1pfhmDpjVug9nKU&e=>
> http://doc.qt.io/qt-5/sharedlibra
> How to create a library with Qt and use it in an application
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qt.io_How-5Fto-5Fcreate-5Fa-5Flibrary-5Fwith-5FQt-5Fand-5Fuse-5Fit-5Fin-5Fan-5Fapplication&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=WmSjv8Q5QDreoWKNX4mS9hZm6lMR1pfhmDpjVug9nKU&e=>
> wiki.qt.io
> This tutorial illustrates different approaches for using a custom library
> in your application on Windows. The first part explains how to create a
> shared library and how to link against it in your application. The second
> part is about creating and using a static library. Creating a shared
> library ...
> ry.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__doc.qt.io_qt-2D5_sharedlibrary.html&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=I_GD4gkI-8u5o_gjXOD-wZKguDdfF2Gu4YG3Swst3hY&e=>
>
> The patch does that, and now the example links with the library just fine.
> The kImageAnnotatorExport.h header defines the macro, the compile
> definition is set for the shared library target in the CMakeLists.txt. I
> guess you'll  have to do the same for all classes used by the unit tests,
> no sure of the Qt development practices.
>
> I also reworked your CMake files a bit. I am sending a single patch,
> though. Sorry.
>
>
> El mar., 21 de ago. de 2018 a la(s) 14:29, Eric Noulard (
> eric.noulard at gmail.com) escribi?:
>
>
>
> Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic <damir_porobic at live.com> a
> ?crit :
>
> Hi Eric,
>
>
> yes, this is the project. I have pushed my current state to this branch
> https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DamirPorobic_kImageAnnotator_tree_sharedLibTestBranch&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=j_vYMAeNlkSJPzPWt5eGGRXiqm4RocWUGgyctA8SGE4&e=>
>
> I've tried also without the generate_export_headers (cleaned everything up
> before trying out) but I get the same result.
>
>
> KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the
> handwritten file, that's true, I think I got something mixed up there and I
> don't actually need the generate_export_headers, but as said, even
> without the line, it's not working.
>
>
> I'm quite lost with the file layout.
>
> in example/main.cpp you do:
> #include <kImageAnnotator/KImageAnnotator.h>
> so I guess you expect that
> target_link_libraries(kImageAnnotator-example PRIVATE
> kImageAnnotator::kImageAnnotator)
>
> will bring you the include path to "kImageAnnotator/KImageAnnotator.h"
> along with the [imported] target
>
> in your main tree (not in example) there is a trick because you did:
>
> add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)
>
> and then in the test directory you do:
>
> target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)
>
> with
>
> add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})
>
> so AFAIU you compile your kImageAnnotator library twice. Once for building
> the target you expect to use in example/ subdir
> and another time as a STATIC lib for the unit test. So the unit test is
> not linking to the same object lib at all ??
>
> I am not used to KDE development but all this seems very fuzzy to me.
>
> May be you could get more precise help from people who know better about
> KDE dev and the specific CMake machinery that comes along
> like ECM (https://github.com/KDE/extra-cmake-modules
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KDE_extra-2Dcmake-2Dmodules&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=LaNKLek4ewlsoy7ECnW4qRmkBAAVUeo6iTSFqsT9ACo&e=>)
> you seems to be using.
>
> --
> Eric
>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valpara?so, Chile
>


-- 
Sebastian Mancilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180823/a37cb44e/attachment.html>

From neundorf at kde.org  Thu Aug 23 16:36:01 2018
From: neundorf at kde.org (Alexander Neundorf)
Date: Thu, 23 Aug 2018 22:36:01 +0200
Subject: [CMake] protobuf and imports relative to root (and --proto_path)
In-Reply-To: <CAAV-JT4+MKTDDud-w8j3YTVbm-5htp014VWDTOjbBswhwY9n6A@mail.gmail.com>
References: <CAAV-JT4+MKTDDud-w8j3YTVbm-5htp014VWDTOjbBswhwY9n6A@mail.gmail.com>
Message-ID: <4057870.Fgg1o8KiqT@linux-l7nd>

On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> Hello,
> 
> I'm trying to port an existing project from premake to cmake.
> I'm trying to avoid modifying the source files while doing so.
> 
> Right now, we have several libraries (read in different directories) using
> proto files with imports between them.
> All imports are made relative to the root of the project.
> 
> e.g :
> work/lib1/sublib1/a.proto
> work/lib1/sublib1/b.proto
> 
> with a.proto having a link to b.proto like this "import
> lib1/sublib1/b.proto"
> 
> If I compile this with an unchanged FindProtobuf.cmake, I do this :
> 
> protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
> add_library(...)
> 
> the problem being that it looks like the "namespaces" generated by protoc
> in b.proto do not match the one used in a.proto : it does not compile.

do you mean protoc fails, or that the C++ compiler fails when compiling the 
generated file ?
I'm also using proto files with imports between them and don't have problems 
with finding them.
Are you setting the PROTOBUF_IMPORT_DIRS variable ?

What I do have a problem is rerunning protoc automatically on proto-files which 
import proto files that have been modified.
How do you handle this ?

> Is there a way to make this work ?
> 
> Otherwise, I made the patch below which solves my problem. Do you think it
> could be included in cmake ?
> it defines a new option PROTO_PATH, so the decl above becomes
> protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
> a.proto b.proto)
> 
> With regards
> 
> David
> 
> $ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
> share/cmake-3.10/Modules/FindProtobuf.cmake

can you please use diff -bup ?
This makes the patch easier to read.

Thanks
Alex


From petr.kmoch at gmail.com  Fri Aug 24 02:29:31 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Fri, 24 Aug 2018 08:29:31 +0200
Subject: [CMake] Best practice for configuration-dependent defaults?
In-Reply-To: <CAH5Ym4gVyTkPR+AD3Gat=O6BkCb1_PSqYiecx1BbAdteJFrReg@mail.gmail.com>
References: <CAH5Ym4gVyTkPR+AD3Gat=O6BkCb1_PSqYiecx1BbAdteJFrReg@mail.gmail.com>
Message-ID: <CAKohaZf5d_ke+p1RXBGE+e2zxP0E+kO6G4ST=GTN-mOBCFpaCQ@mail.gmail.com>

Hi Sam,

it seems to me that your user-facing option is not actually Boolean, but
tri-state: On vs. Off vs. Use_default. So I would represent it accordingly:
present the user with a string variable (with suitable STRINGS property
https://cmake.org/cmake/help/latest/prop_cache/STRINGS.html), and then
control my internal CMake logic like this:

if(FOO STREQUAL "USE_DEFAULT")
  # ...
elseif(FOO)
  # user turned FOO on
else()
  # user turned FOO off
endif()

Petr

On Fri, 17 Aug 2018 at 19:18, Sam Edwards <cfsworks at gmail.com> wrote:

> Hi all!
>
> I have a project with some options that have different defaults depending
> on the configuration used to build the project. For example, support for a
> certain (easy to support, but relatively uncommon) file format should be on
> by default, except when building in the MinSizeRel configuration. Or
> inclusion of a certain optional troubleshooting feature should be on by
> default only when building for Debug, and should default to off in all
> other configurations.
>
> For single-configuration generators, this is pretty easy: I just look at
> the CMAKE_BUILD_TYPE variable and switch the option() defaults depending on
> the selected build type, then generate my config.h once.
>
> I'm trying to support multi-configuration now. My current plan is to
> generate one config.h per build configuration (e.g. include/Debug/config.h,
> include/MinSizeRel/config.h, ...) so that the options which the user hasn't
> explicitly set can have different per-configuration values depending on
> their per-configuration defaults.
>
> However, where I'm getting stuck is in changing the default for an option
> and having that default take precedence when the user hasn't overridden the
> option explicitly. I can't just do something like:
> option(FOO "This is foo" ON)
> message("FOO is ${FOO}")
> option(FOO "This is foo" OFF)
> message("FOO is ${FOO}")
>
> ...because the first option(FOO ...) sets it to ON when it sees it isn't
> in cache and isn't selected by the user, so the second option(FOO ...)
> thinks it's already been set explicitly. Unless there's some way of
> distinguishing "ON because it's the default" from "ON because the user
> explicitly requested it" while having everything still show up correctly in
> the GUI, this won't work.
>
> Is this really the best practice for what I'm trying to do, or is there a
> better "CMake way" to do this? How do you folks solve this problem in your
> own projects?
>
> Thanks,
> Sam
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180824/83902f0a/attachment.html>

From post at lespocky.de  Fri Aug 24 06:01:24 2018
From: post at lespocky.de (Alexander Dahl)
Date: Fri, 24 Aug 2018 12:01:24 +0200
Subject: [CMake] Using ExternalProject with find_library and find_path
Message-ID: <20180824100123.dls3fm5ifmbn4p2l@falbala.home.lespocky.de>

Hei hei,

for a standalone build without system libraries I was experimenting
with the ExternalProject module today. My goal is to have some top
level build project which includes several CMake projects and some
external projects without relying on dev libraries installed on the
system (reason are basically incompatible library versions). However
those CMake projects should not be altered and should also be capable
of building against dev libs from the system or in a cross compile
environment like ptxdist. I created a simple example project to build
OpenSSL with the ExternalProject module, and link either that or the
OpenSSL lib from the system:

https://github.com/LeSpocky/effective-succotash

(Note: using MD5 inside this example program is really just a very
simple example, the real application will use more of OpenSSL, so that
one is really needed, please no suggestions for alternatives. ;-) )

(Also note: some things were inspired by the FindOpenSSL.cmake coming
with CMake 3.9).

This works in general with one minor flaw. When building OpenSSL as
external project, I have to run the build twice, because find_library
and find_path obviously fail to find OpenSSL in the build tree before
it is built. I could set those paths by hand with a priori knowledge
were the OpenSSL build will put its output, but that seems like an
unelegant solution to me.

Any hints on that topic? What I found on the web was basically things
from several years ago, I would appreciate a more modern CMake
approach with imported targets. ;-)

Greets
Alex

-- 
/"\ ASCII RIBBON | ?With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.?
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180824/014f56b9/attachment.sig>

From petr.kmoch at gmail.com  Fri Aug 24 07:31:59 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Fri, 24 Aug 2018 13:31:59 +0200
Subject: [CMake] Using ExternalProject with find_library and find_path
In-Reply-To: <20180824100123.dls3fm5ifmbn4p2l@falbala.home.lespocky.de>
References: <20180824100123.dls3fm5ifmbn4p2l@falbala.home.lespocky.de>
Message-ID: <CAKohaZfqQJNqkbeqTMrNOyTAc0bi6jwviBfATd4La061ZvZiag@mail.gmail.com>

Hi Alex,

the standard solution to this is to use a Superbuild approach, in which the
top-level CMakeList contains *only* ExternalProject calls. That means your
actual project becomes just another "external" project in this superbuild,
which allows you set up all build dependencies etc. as necessary. Then, you
proceed like this:

* First generate and build the Superbuild
* Then switch to your real project within the superbuild infrastructure,
and do all further development there. You're guaranteed all your
dependencies are already available by them having been built as part of the
Superbuild step above.

Googling for "CMake ExternalProject superbuild" should give you more info.

Petr

On Fri, 24 Aug 2018 at 12:06, Alexander Dahl <post at lespocky.de> wrote:

> Hei hei,
>
> for a standalone build without system libraries I was experimenting
> with the ExternalProject module today. My goal is to have some top
> level build project which includes several CMake projects and some
> external projects without relying on dev libraries installed on the
> system (reason are basically incompatible library versions). However
> those CMake projects should not be altered and should also be capable
> of building against dev libs from the system or in a cross compile
> environment like ptxdist. I created a simple example project to build
> OpenSSL with the ExternalProject module, and link either that or the
> OpenSSL lib from the system:
>
> https://github.com/LeSpocky/effective-succotash
>
> (Note: using MD5 inside this example program is really just a very
> simple example, the real application will use more of OpenSSL, so that
> one is really needed, please no suggestions for alternatives. ;-) )
>
> (Also note: some things were inspired by the FindOpenSSL.cmake coming
> with CMake 3.9).
>
> This works in general with one minor flaw. When building OpenSSL as
> external project, I have to run the build twice, because find_library
> and find_path obviously fail to find OpenSSL in the build tree before
> it is built. I could set those paths by hand with a priori knowledge
> were the OpenSSL build will put its output, but that seems like an
> unelegant solution to me.
>
> Any hints on that topic? What I found on the web was basically things
> from several years ago, I would appreciate a more modern CMake
> approach with imported targets. ;-)
>
> Greets
> Alex
>
> --
> /"\ ASCII RIBBON | ?With the first link, the chain is forged. The first
> \ / CAMPAIGN     | speech censured, the first thought forbidden, the
>  X  AGAINST      | first freedom denied, chains us all irrevocably.?
> / \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180824/661697e5/attachment.html>

From george.p.f at mail.com  Fri Aug 24 08:40:11 2018
From: george.p.f at mail.com (George PF)
Date: Fri, 24 Aug 2018 14:40:11 +0200
Subject: [CMake] Adding an individual define to each source file of a
 library
In-Reply-To: <CAPASGLqfx1rcTyzaJU4=H+BOcXidRXUtjqzYps5F9VWGA+kBzA@mail.gmail.com>
References: <trinity-a2b6c446-5cab-456c-8f7b-e817614444db-1535021836348@3c-app-mailcom-lxa13>
 <CAPASGLpDhQeA4jSsEtfO=PrHUTTd3T3=wzKpWDDokMxijxeYiQ@mail.gmail.com>
 <trinity-e387669c-a358-41dd-b8f5-4ca57016d539-1535041898800@3c-app-mailcom-lxa13>
 <CAPASGLoQPdpK2xs30RXM_AkzwqJbSKvNR+oB4xBWgDSom3wR0w@mail.gmail.com>
 <trinity-3ea6deeb-0870-4d8b-ae39-1953ed9ddf07-1535044712334@3c-app-mailcom-lxa13>
 <CAPASGLqfx1rcTyzaJU4=H+BOcXidRXUtjqzYps5F9VWGA+kBzA@mail.gmail.com>
Message-ID: <trinity-688b56fc-8ef3-4cb3-8598-4efb38d3b76c-1535114411572@3c-app-mailcom-lxa11>

>>     foreach(x IN LISTS mysrcs)
>>         message("at ${x}")
>>         set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")
>
> almost there but you forgot to take value of 'x'
>
> set_property(SOURCE ${x} APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")
>
> works for me.

Thank you very much, now it indeed works.


FTR, extracted into a separate 'add_library_with_defs' function in the toplevel CMakeLists.txt


    function(add_library_with_defs libname libtype)
        math(EXPR endindex "${ARGC}-1")
        set(files)
        foreach(index RANGE 2 ${endindex})
            list(GET ARGV ${index} arg)
            list(APPEND files ${arg})
        endforeach()
    
        add_library("${libname}" "${libtype}" "${files}")
    
        get_property(mysrcs TARGET "${libname}" PROPERTY SOURCES)
        foreach(x IN LISTS mysrcs)
            # message("${libname}: at ${x}")
            set_property(SOURCE ${x} APPEND PROPERTY COMPILE_DEFINITIONS TEST1 TEST2)
        endforeach()
    endfunction()


so now it is simplified to: add_library_with_defs(mylib SHARED file1.c file2.c)

From damir_porobic at live.com  Fri Aug 24 15:37:30 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Fri, 24 Aug 2018 19:37:30 +0000
Subject: [CMake] Problem with creating shared library
In-Reply-To: <CAJPSwc2bsJVNPV5fPsQS_O-geLMZLmHoLqOGT66RWmYLZCgVMQ@mail.gmail.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
 <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>
 <CAJPSwc0XYgxVQHCwjofA2hARUAfXjc4J=Xb=v3u8Sz4khHNTOw@mail.gmail.com>
 <AM0PR0202MB3411B5060BE2347A67379D4AE5300@AM0PR0202MB3411.eurprd02.prod.outlook.com>,
 <CAJPSwc2bsJVNPV5fPsQS_O-geLMZLmHoLqOGT66RWmYLZCgVMQ@mail.gmail.com>
Message-ID: <AM0PR0202MB341180B6EC9305848EB5AA38E5360@AM0PR0202MB3411.eurprd02.prod.outlook.com>

I've fixed both issues, the second by implementing the pimpl idiom but still I can't used the library in the other project, again I get the error with undefined reference to the constructor (and a method that I've added):


[ 75%] Linking CXX executable testApp
CMakeFiles/testApp.dir/main.cpp.o: In function `main':
/home/dporobic/projects/testApp/main.cpp:9: undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
/home/dporobic/projects/testApp/main.cpp:11: undefined reference to `KImageAnnotator::testMethod()'
collect2: error: ld returned 1 exit status

But the constructor and the method don't seem to be private anymore:

dporobic at linux ~/projects/kImageAnnotator/build (sharedLibTestBranch)
$ nm -g lib/libkImageAnnotator.so | c++filt | grep "::testMethod\|::KImage"
0000000000014f08 T KImageAnnotator::testMethod()
0000000000014b18 T KImageAnnotator::KImageAnnotator(QPixmap const&)
0000000000014b18 T KImageAnnotator::KImageAnnotator(QPixmap const&)

Also, after the constructor call and before the call to the test method in my test project, there is a call to an inherited method (show()) from QWidget and the linker is not complaining about this one:

auto kImageAnnotator = new KImageAnnotator(pixmap);
kImageAnnotator->show();
kImageAnnotator->testMethod();


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org>
Sent: Thursday, August 23, 2018 22:13
To: Damir Porobic
Cc: cmake at cmake.org
Subject: Re: [CMake] Problem with creating shared library

I forgot to update the include path in the patch I sent you.

It should be like this (note that it contains just "include", not "include/kImageAnnotator"):

target_include_directories(kImageAnnotator
        PUBLIC
        $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
        $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
        $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
        )

And kImageAnnotator.h should change the export include to:

#include "kImageAnnotatorExport.h"


You still have a bigger problem, though. kImageAnnotator.h is including private headers

#include "../../src/gui/VisibilitySwitcher.h"
#include "../../src/annotations/core/AnnotationArea.h"
#include "../../src/backend/Config.h"
#include "../../src/widgets/ToolPicker.h"
#include "../../src/widgets/ColorPicker.h"
#include "../../src/widgets/SizePicker.h"
#include "../../src/widgets/FillPicker.h"

If those are required by your clients, then they should be in the "include/kImageAnnotator" directory and installed along with "kImageAnnotator.h".
Otherwise, consider using the pimpl idiom and remove the includes from the public header.


El mi?., 22 de ago. de 2018 a la(s) 17:08, Damir Porobic (damir_porobic at live.com<mailto:damir_porobic at live.com>) escribi?:

Thanks you Sebasti?n for finding the issue and fixing the CMake, probably would have never found out that it was set to private.


The kImageAnnotator-example is working now as expected. Do I need something else, except installing the lib, in order to use it in different projects? I've created a second project which is identical to the kImageAnnotator-example but I get following when I try to build it:


[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
In file included from /home/dporobic/projects/testApp/main.cpp:2:0:
/usr/local/include/kImageAnnotator/KImageAnnotator.h:31:35: fatal error: KImageAnnotatorExport.h: No such file or directory
 #include <KImageAnnotatorExport.h>
                                   ^
compilation terminated.


The includes look like this:

#include <QApplication>
#include <kImageAnnotator/KImageAnnotator.h>


And the CMake looks like this:

find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp kImageAnnotator)


Am I missing something again?


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org<mailto:smancill at jlab.org>>
Sent: Wednesday, August 22, 2018 00:51
To: Eric Noulard
Cc: Damir Porobic; cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Problem with creating shared library

I fixed your problem. Get the attached patch and apply it with "git apply <patch_file>".

The kImageAnnotator constructor was private to the library (I just learned that Qt does that when creating shared libraries), and that's why you get the undefined reference error. You could have checked it with:

nm lib/libkImageAnnotator.so | c++filt | grep ::KImage
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)

The "t" shows it is private.

You have to set the proper export macros to make it visible:

https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qt.io_How-5Fto-5Fcreate-5Fa-5Flibrary-5Fwith-5FQt-5Fand-5Fuse-5Fit-5Fin-5Fan-5Fapplication&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=WmSjv8Q5QDreoWKNX4mS9hZm6lMR1pfhmDpjVug9nKU&e=>
http://doc.qt.io/qt-5/sharedlibra
<https://urldefense.proofpoint.com/v2/url?u=http-3A__doc.qt.io_qt-2D5_sharedlibrary.html&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=I_GD4gkI-8u5o_gjXOD-wZKguDdfF2Gu4YG3Swst3hY&e=>
How to create a library with Qt and use it in an application<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qt.io_How-5Fto-5Fcreate-5Fa-5Flibrary-5Fwith-5FQt-5Fand-5Fuse-5Fit-5Fin-5Fan-5Fapplication&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=WmSjv8Q5QDreoWKNX4mS9hZm6lMR1pfhmDpjVug9nKU&e=>
wiki.qt.io
This tutorial illustrates different approaches for using a custom library in your application on Windows. The first part explains how to create a shared library and how to link against it in your application. The second part is about creating and using a static library. Creating a shared library ...

ry.html

The patch does that, and now the example links with the library just fine. The kImageAnnotatorExport.h header defines the macro, the compile definition is set for the shared library target in the CMakeLists.txt. I guess you'll  have to do the same for all classes used by the unit tests, no sure of the Qt development practices.

I also reworked your CMake files a bit. I am sending a single patch, though. Sorry.


El mar., 21 de ago. de 2018 a la(s) 14:29, Eric Noulard (eric.noulard at gmail.com<mailto:eric.noulard at gmail.com>) escribi?:


Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic <damir_porobic at live.com<mailto:damir_porobic at live.com>> a ?crit :

Hi Eric,


yes, this is the project. I have pushed my current state to this branch https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DamirPorobic_kImageAnnotator_tree_sharedLibTestBranch&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=j_vYMAeNlkSJPzPWt5eGGRXiqm4RocWUGgyctA8SGE4&e=>


I've tried also without the generate_export_headers (cleaned everything up before trying out) but I get the same result.


KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the handwritten file, that's true, I think I got something mixed up there and I don't actually need the generate_export_headers, but as said, even without the line, it's not working.

I'm quite lost with the file layout.

in example/main.cpp you do:
#include <kImageAnnotator/KImageAnnotator.h>
so I guess you expect that
target_link_libraries(kImageAnnotator-example PRIVATE kImageAnnotator::kImageAnnotator)

will bring you the include path to "kImageAnnotator/KImageAnnotator.h" along with the [imported] target

in your main tree (not in example) there is a trick because you did:

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

and then in the test directory you do:

target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)

with

add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})

so AFAIU you compile your kImageAnnotator library twice. Once for building the target you expect to use in example/ subdir
and another time as a STATIC lib for the unit test. So the unit test is not linking to the same object lib at all ??

I am not used to KDE development but all this seems very fuzzy to me.

May be you could get more precise help from people who know better about KDE dev and the specific CMake machinery that comes along
like ECM (https://github.com/KDE/extra-cmake-modules<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KDE_extra-2Dcmake-2Dmodules&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=LaNKLek4ewlsoy7ECnW4qRmkBAAVUeo6iTSFqsT9ACo&e=>) you seems to be using.

--
Eric


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile


--
Sebastian Mancilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180824/74a30be3/attachment-0001.html>

From pnavarro at netflix.com  Fri Aug 24 20:19:56 2018
From: pnavarro at netflix.com (Pedro Navarro)
Date: Fri, 24 Aug 2018 17:19:56 -0700
Subject: [CMake] Handling of generated files in POST_BUILD custom commands
Message-ID: <CAFSk+f6QHT1pZXeaWMz+rFkr5UXBRnDdct+i3zcbNyPe+sQfYA@mail.gmail.com>

Hi all,

I'm trying to build an executable that has its debug symbols in a separate
file. I implemented that with a POST_BUILD custom command:

add_executable(foo a.cpp)
add_custom_command(TARGET foo
    POST_BUILD
    COMMAND ${CMAKE_OBJCOPY} --only-keep-debug foo foo.sym
    COMMAND ${CMAKE_OBJCOPY} --add-gnu-debuglink=foo.sym foo
    COMMAND ${CMAKE_STRIP} --strip-debug foo
    BYPRODUCTS foo.sym
    COMMENT "Creating symbols"
)

The problem is that if I delete foo.sym, in order for it to be created
again it's not enough with running the custom command steps as we have
stripped the file and the debug symbols are gone: we need to relink the
executable so the debug information is available again.

The ninja generator makes this situation possible with the use of
byproducts. By adding BYPRODUCTS foo.sym to the custom command if I change
foo.sym the target is relinked. Unfortunately the GNU Makefiles generator
ignores byproducts, so I want to relink the executable I need to remove it.
Also the byproducts are added to ninja's clean target, but not for GNU
Makefiles.

I have tried to achieve the same result with a custom command:

add_custom_command(OUTPUT foo
    DEPENDS foo
    COMMAND ${CMAKE_OBJCOPY} --only-keep-debug foo foo.sym
    COMMAND ${CMAKE_OBJCOPY} --add-gnu-debuglink=foo.sym foo
    COMMAND ${CMAKE_STRIP} --strip-debug foo
    BYPRODUCTS foo.sym
    COMMENT "Creating symbols"
    USES_TERMINAL
)

add_custom_target(foo_symbols ALL
    DEPENDS foo.sym
)

But I get the same results, the target does not get relinked. Also, it
seems that there is an issue of some sort because every time I type make
the steps to create the file foo.sym are executed, resulting in an error
message from objcopy ('debuglink section already exists'). If I touch the
CMakeLists.txt file (by adding a space, removing it and saving), make after
that correctly does not execute the steps to create foo.sym. I understand
that targets created by add_custom_target are always out of date, but I
thought there shouldn't be a need to re-run the custom command.

*lgux-pnavarro4 ~/tests/cm2/b $ cmake --version*
cmake version 3.10.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
*lgux-pnavarro4 ~/tests/cm2/b $ rm -rf * && cmake -DCMAKE_BUILD_TYPE=Debug
..*
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/local/bin/cc
-- Check for working C compiler: /usr/local/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/bin/c++
-- Check for working CXX compiler: /usr/local/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pnavarro/tests/cm2/b
*lgux-pnavarro4 ~/tests/cm2/b $ make*
make: Entering directory '/home/pnavarro/tests/cm2/b'
make[1]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
Scanning dependencies of target foo
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
[ 33%] Building CXX object CMakeFiles/foo.dir/a.cpp.o
[ 66%] Linking CXX executable foo
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
[ 66%] Built target foo
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
Scanning dependencies of target foo_symbols
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
[100%] Creating symbols
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
[100%] Built target foo_symbols
make[1]: Leaving directory '/home/pnavarro/tests/cm2/b'
make: Leaving directory '/home/pnavarro/tests/cm2/b'
*lgux-pnavarro4 ~/tests/cm2/b $ make*
make: Entering directory '/home/pnavarro/tests/cm2/b'
make[1]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
[ 66%] Built target foo
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
[100%] Creating symbols
/usr/bin/objcopy: stkkJQMo: debuglink section already exists
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
[100%] Built target foo_symbols
make[1]: Leaving directory '/home/pnavarro/tests/cm2/b'
make: Leaving directory '/home/pnavarro/tests/cm2/b'
*lgux-pnavarro4 ~/tests/cm2/b $ *

*<touch CMakeLists.txt>*

*lgux-pnavarro4 ~/tests/cm2/b $ make*
make: Entering directory '/home/pnavarro/tests/cm2/b'
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pnavarro/tests/cm2/b
make[1]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
[ 66%] Built target foo
make[2]: Entering directory '/home/pnavarro/tests/cm2/b'
make[2]: Leaving directory '/home/pnavarro/tests/cm2/b'
[100%] Built target foo_symbols
make[1]: Leaving directory '/home/pnavarro/tests/cm2/b'
make: Leaving directory '/home/pnavarro/tests/cm2/b'


This leads me to the following questions:
1) Is is possible to achieve what I want (relink the target if a file
created after POST_BUILD is deleted) with GNU Make files?
2) As the documentation says that byproducts are ignored but the files
marked as GENERATED, shouldn't GENERATED files created by POST_BUILD be
added as a trigger for a new link?
3) Byproducts are added to the clean target in ninja, but in GNU Makefiles
you need to add them to ADDITIONAL_MAKE_CLEAN_FILES. Shouldn't GENERATED
files in POST_BUILD be automatically added to the make clean target? At
least it will give parity between ninja and make's behaviors.
4) Is my issue with foo_symbols not being executed after touching
CMakelists.txt a bug?

Thanks!
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180824/5cbcef9a/attachment.html>

From s.textor at ditec-gmbh.de  Fri Aug 24 21:01:12 2018
From: s.textor at ditec-gmbh.de (=?iso-8859-1?Q?S=F6ren_Textor?=)
Date: Sat, 25 Aug 2018 03:01:12 +0200
Subject: [CMake] Abwesenheitsnachricht: Handling of generated files in
 POST_BUILD custom commands
Message-ID: <3952A1004D504F2F9AFD00F25A093D08@ditec-gmbh.de>

Derzeit bin ich nicht im Hause Ihre E-Mail wird nicht weitergeleitet.
 
In dringenden F?llen bitte support at ditec-gmbh.de oder Telefonhotline +49-6221-31698-110 oder die Zentrale +49-6221-31698-0 kontaktieren.

-----------------------------------------------
DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH
 
Im Breitspiel 19 | 69126 Heidelberg | Germany
 
Handelsregister | Mannheim | HRB 341229
 
Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielf?ltigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdr?cklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere f?r den Fall der Schutzrechtsanmeldung.
 
This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180825/03d40420/attachment-0001.html>

From hobbes1069 at gmail.com  Sat Aug 25 17:48:53 2018
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Sat, 25 Aug 2018 16:48:53 -0500
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <4bffbf80-f08b-cedd-23e4-d17a457170fe@kitware.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
 <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
 <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>
 <21e3f070-06ff-12f9-039a-6613ce6e4bfc@kitware.com>
 <4bffbf80-f08b-cedd-23e4-d17a457170fe@kitware.com>
Message-ID: <CAN3TeO2sxtoPUhta=ov+vqJbn5tgFRQ2ezQAHKvQVTzXTC=v0A@mail.gmail.com>

On Thu, Aug 23, 2018 at 11:58 AM Brad King <brad.king at kitware.com> wrote:

> On 08/22/2018 04:23 PM, Richard Shaw wrote:
>
> Meanwhile you can use just
>
>   set(CMAKE_EXECUTABLE_SUFFIX ".elf")
>

Ok, interestingly that had no effect, but if I moved the
set(CMAKE_EXECUTABLE_SUFFIX_<LANG>) to the main CMakeFiles.txt file below
the project() call it worked.

On Fedora, when I commented out the include for the toolchain file and
applied it on the command line I ran into an issue where it seems like
cmake doesn't understand the source directory as it no longer looked in the
right place for the linker script. In the toolchain file it's set to a
sub-directory of the source dir but it's looking in the binary dir:

set(CMAKE_EXE_LINKER_FLAGS "-T${CMAKE_SOURCE_DIR}/stm32_flash.ld")

Output:
    Linking C executable cmTC_51be3.elf
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_51be3.dir/link.txt
--verbose=1
    /usr/lib64/ccache/arm-none-eabi-gcc  -Wall -std=gnu11 -mlittle-endian
-mthumb -mthumb-interwork -nostartfiles -mcpu=cortex-m4
-fsingle-precision-constant -Wdouble-promotion -mfpu=fpv4-sp-d16
-mfloat-abi=hard -D__FPU_PRESENT=1 -D__FPU_USED=1 --specs=nosys.specs
 -T/home/build/build/stm32/CMakeFiles/CMakeTmp/stm32_flash.ld
CMakeFiles/cmTC_51be3.dir/testCCompiler.c.obj  -o cmTC_51be3.elf
    /usr/lib/gcc/arm-none-eabi/7.1.0/../../../../arm-none-eabi/bin/ld:
cannot open linker script file
/home/build/build/stm32/CMakeFiles/CMakeTmp/stm32_flash.ld: No such file or
directory

The build dir is the binary directory, not the source directory...

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180825/80a6ce5f/attachment.html>

From paul at mad-scientist.net  Sat Aug 25 20:19:31 2018
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 25 Aug 2018 20:19:31 -0400
Subject: [CMake] Can I build targets during all but NOT during install?
In-Reply-To: <1514848344.2717.604.camel@mad-scientist.net>
References: <1514848344.2717.604.camel@mad-scientist.net>
Message-ID: <c50796fd6b65c2e0e97ea7d3c4c3a14aa2f572a7.camel@mad-scientist.net>

On Mon, 2018-01-01 at 18:12 -0500, Paul Smith wrote:
> What I hoped is for the default build with no targets specified to
> build everything ("all"), but if I invoke the build with the
> "install" target it builds only the things that are to be installed,
> not my test programs.
> 
> Unfortunately it doesn't seem like this is possible; at least when I
> examine the Makefiles generated by the CMake Unix Makefiles
> generator, the install target depends on the preinstall target which
> depends on all.  Is this true in general or is there something in my
> CMake setup that causes it?

FYI I'm using CMake 3.11.3 on GNU/Linux, MacOS, and Windows with Visual
Studio.

Thanks to Oleksii Vilchanskyi <oleksii.vilchanskyi at gmail.com> for
pointing me to CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.

This appears (not tested completely yet) to do half of what I'd like,
by keeping the "install" target from depending on "all".


The other half is that I want to have the "all" target depend on
"install", instead: all should build all the installation targets AND
also build all the extra testing stuff that is not needed during
install.

I can't seem to figure out how to do that; add_dependencies()
explicitly says that I can't use it with "install" and I don't see any
other way to add dependencies to a target.

Is this possible?  Or do I need to go around to all my "all"
dependencies and explicitly add them to "install" as well?


Then the next step after that is I'd like my "install" target to have
dependencies which are built during installation but don't actually
copy any files anywhere: they are just built and left as-is when I run
the "install" rule (e.g., "make install" or whatever).

I can't come up with a way to modify the dependencies of the "install"
target without using the install() rule.

The manual says that the DESTINATION option in install() is optional,
but if I leave it out I get errors.

Is that possible?

From damir_porobic at live.com  Sun Aug 26 07:50:07 2018
From: damir_porobic at live.com (Damir Porobic)
Date: Sun, 26 Aug 2018 11:50:07 +0000
Subject: [CMake] Problem with creating shared library
In-Reply-To: <AM0PR0202MB341180B6EC9305848EB5AA38E5360@AM0PR0202MB3411.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3411C666D7AAE233F31ADCC6E53F0@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAJPSwc048GO18NUAD-gDOOyNBb3xmgxoHGpR4oWL1GkPGr5gvA@mail.gmail.com>
 <AM0PR0202MB341112BE1AEB464B426C87D8E5330@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoWBxn3u+Un-6r=H8VPpS=pROWF_FWmAph5huHTw4X=PA@mail.gmail.com>
 <AM0PR0202MB341160D51166F1B4597C5CC7E5320@AM0PR0202MB3411.eurprd02.prod.outlook.com>
 <CAPASGLoyZ754AFagbxOZ2yoTKteHfKehw8idhkD_GWFbKKgO3w@mail.gmail.com>
 <CAJPSwc0XYgxVQHCwjofA2hARUAfXjc4J=Xb=v3u8Sz4khHNTOw@mail.gmail.com>
 <AM0PR0202MB3411B5060BE2347A67379D4AE5300@AM0PR0202MB3411.eurprd02.prod.outlook.com>,
 <CAJPSwc2bsJVNPV5fPsQS_O-geLMZLmHoLqOGT66RWmYLZCgVMQ@mail.gmail.com>,
 <AM0PR0202MB341180B6EC9305848EB5AA38E5360@AM0PR0202MB3411.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB34117B578ECCFCE35F39C43FE5340@AM0PR0202MB3411.eurprd02.prod.outlook.com>

Ok, I've found the issue for the latest problem but I'm not sure how to fix it in the CMake file. The make was using an old version of /usr/local/lib64/libkImageAnnotator.so.0.0.1 so I removed everything with kImageAnnotato in its name from this directory and run again the sudo make install which gave me this output


-- Install configuration: "Debug"
-- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-config.cmake
-- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-config-version.cmake
-- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-targets.cmake
-- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-targets-debug.cmake
-- Installing: /usr/local/lib64/libkImageAnnotator.so
-- Set runtime path of "/usr/local/lib64/libkImageAnnotator.so" to "/usr/local/lib64"
-- Up-to-date: /usr/local/include/kImageAnnotator
-- Up-to-date: /usr/local/include/kImageAnnotator/KImageAnnotator.h
-- Up-to-date: /usr/local/include/kImageAnnotator/KImageAnnotatorExport.h


So only libkImageAnnotator.so is created and installed, but not the one with the version at the end which cmake seems to expect: in my test project

CMake Error at /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake:79 (message):
  The imported target "kImageAnnotator" references the file

     "/usr/local/lib64/libkImageAnnotator.so.0.0.1"

  but this file does not exist.

When I manually create a link to the installed file:

$ sudo ln -s /usr/local/lib64/libkImageAnnotator.so /usr/local/lib64/libkImageAnnotator.so.0.0.1

Everything finally works, but I need to fix this final issue with the missing link. This was working earlier I think.


________________________________
From: Damir Porobic <damir_porobic at live.com>
Sent: Friday, August 24, 2018 9:37:30 PM
To: Sebasti?n Mancilla
Cc: cmake at cmake.org
Subject: Re: [CMake] Problem with creating shared library


I've fixed both issues, the second by implementing the pimpl idiom but still I can't used the library in the other project, again I get the error with undefined reference to the constructor (and a method that I've added):


[ 75%] Linking CXX executable testApp
CMakeFiles/testApp.dir/main.cpp.o: In function `main':
/home/dporobic/projects/testApp/main.cpp:9: undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)'
/home/dporobic/projects/testApp/main.cpp:11: undefined reference to `KImageAnnotator::testMethod()'
collect2: error: ld returned 1 exit status

But the constructor and the method don't seem to be private anymore:

dporobic at linux ~/projects/kImageAnnotator/build (sharedLibTestBranch)
$ nm -g lib/libkImageAnnotator.so | c++filt | grep "::testMethod\|::KImage"
0000000000014f08 T KImageAnnotator::testMethod()
0000000000014b18 T KImageAnnotator::KImageAnnotator(QPixmap const&)
0000000000014b18 T KImageAnnotator::KImageAnnotator(QPixmap const&)

Also, after the constructor call and before the call to the test method in my test project, there is a call to an inherited method (show()) from QWidget and the linker is not complaining about this one:

auto kImageAnnotator = new KImageAnnotator(pixmap);
kImageAnnotator->show();
kImageAnnotator->testMethod();


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org>
Sent: Thursday, August 23, 2018 22:13
To: Damir Porobic
Cc: cmake at cmake.org
Subject: Re: [CMake] Problem with creating shared library

I forgot to update the include path in the patch I sent you.

It should be like this (note that it contains just "include", not "include/kImageAnnotator"):

target_include_directories(kImageAnnotator
        PUBLIC
        $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
        $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
        $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
        )

And kImageAnnotator.h should change the export include to:

#include "kImageAnnotatorExport.h"


You still have a bigger problem, though. kImageAnnotator.h is including private headers

#include "../../src/gui/VisibilitySwitcher.h"
#include "../../src/annotations/core/AnnotationArea.h"
#include "../../src/backend/Config.h"
#include "../../src/widgets/ToolPicker.h"
#include "../../src/widgets/ColorPicker.h"
#include "../../src/widgets/SizePicker.h"
#include "../../src/widgets/FillPicker.h"

If those are required by your clients, then they should be in the "include/kImageAnnotator" directory and installed along with "kImageAnnotator.h".
Otherwise, consider using the pimpl idiom and remove the includes from the public header.


El mi?., 22 de ago. de 2018 a la(s) 17:08, Damir Porobic (damir_porobic at live.com<mailto:damir_porobic at live.com>) escribi?:

Thanks you Sebasti?n for finding the issue and fixing the CMake, probably would have never found out that it was set to private.


The kImageAnnotator-example is working now as expected. Do I need something else, except installing the lib, in order to use it in different projects? I've created a second project which is identical to the kImageAnnotator-example but I get following when I try to build it:


[ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
In file included from /home/dporobic/projects/testApp/main.cpp:2:0:
/usr/local/include/kImageAnnotator/KImageAnnotator.h:31:35: fatal error: KImageAnnotatorExport.h: No such file or directory
 #include <KImageAnnotatorExport.h>
                                   ^
compilation terminated.


The includes look like this:

#include <QApplication>
#include <kImageAnnotator/KImageAnnotator.h>


And the CMake looks like this:

find_package(kImageAnnotator REQUIRED)

add_executable(testApp main.cpp)
target_link_libraries(testApp kImageAnnotator)


Am I missing something again?


________________________________
From: Sebasti?n Mancilla <smancill at jlab.org<mailto:smancill at jlab.org>>
Sent: Wednesday, August 22, 2018 00:51
To: Eric Noulard
Cc: Damir Porobic; cmake at cmake.org<mailto:cmake at cmake.org>
Subject: Re: [CMake] Problem with creating shared library

I fixed your problem. Get the attached patch and apply it with "git apply <patch_file>".

The kImageAnnotator constructor was private to the library (I just learned that Qt does that when creating shared libraries), and that's why you get the undefined reference error. You could have checked it with:

nm lib/libkImageAnnotator.so | c++filt | grep ::KImage
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)
00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&)

The "t" shows it is private.

You have to set the proper export macros to make it visible:

https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qt.io_How-5Fto-5Fcreate-5Fa-5Flibrary-5Fwith-5FQt-5Fand-5Fuse-5Fit-5Fin-5Fan-5Fapplication&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=WmSjv8Q5QDreoWKNX4mS9hZm6lMR1pfhmDpjVug9nKU&e=>
http://doc.qt.io/qt-5/sharedlibra
<https://urldefense.proofpoint.com/v2/url?u=http-3A__doc.qt.io_qt-2D5_sharedlibrary.html&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=I_GD4gkI-8u5o_gjXOD-wZKguDdfF2Gu4YG3Swst3hY&e=>
How to create a library with Qt and use it in an application<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qt.io_How-5Fto-5Fcreate-5Fa-5Flibrary-5Fwith-5FQt-5Fand-5Fuse-5Fit-5Fin-5Fan-5Fapplication&d=DwMFAw&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=y6-B01YTd3TICi74QxO0LfDQVtz1m7fckmS3ItKkAmE&s=WmSjv8Q5QDreoWKNX4mS9hZm6lMR1pfhmDpjVug9nKU&e=>
wiki.qt.io
This tutorial illustrates different approaches for using a custom library in your application on Windows. The first part explains how to create a shared library and how to link against it in your application. The second part is about creating and using a static library. Creating a shared library ...

ry.html

The patch does that, and now the example links with the library just fine. The kImageAnnotatorExport.h header defines the macro, the compile definition is set for the shared library target in the CMakeLists.txt. I guess you'll  have to do the same for all classes used by the unit tests, no sure of the Qt development practices.

I also reworked your CMake files a bit. I am sending a single patch, though. Sorry.


El mar., 21 de ago. de 2018 a la(s) 14:29, Eric Noulard (eric.noulard at gmail.com<mailto:eric.noulard at gmail.com>) escribi?:


Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic <damir_porobic at live.com<mailto:damir_porobic at live.com>> a ?crit :

Hi Eric,


yes, this is the project. I have pushed my current state to this branch https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DamirPorobic_kImageAnnotator_tree_sharedLibTestBranch&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=j_vYMAeNlkSJPzPWt5eGGRXiqm4RocWUGgyctA8SGE4&e=>


I've tried also without the generate_export_headers (cleaned everything up before trying out) but I get the same result.


KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the handwritten file, that's true, I think I got something mixed up there and I don't actually need the generate_export_headers, but as said, even without the line, it's not working.

I'm quite lost with the file layout.

in example/main.cpp you do:
#include <kImageAnnotator/KImageAnnotator.h>
so I guess you expect that
target_link_libraries(kImageAnnotator-example PRIVATE kImageAnnotator::kImageAnnotator)

will bring you the include path to "kImageAnnotator/KImageAnnotator.h" along with the [imported] target

in your main tree (not in example) there is a trick because you did:

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

and then in the test directory you do:

target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)

with

add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})

so AFAIU you compile your kImageAnnotator library twice. Once for building the target you expect to use in example/ subdir
and another time as a STATIC lib for the unit test. So the unit test is not linking to the same object lib at all ??

I am not used to KDE development but all this seems very fuzzy to me.

May be you could get more precise help from people who know better about KDE dev and the specific CMake machinery that comes along
like ECM (https://github.com/KDE/extra-cmake-modules<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KDE_extra-2Dcmake-2Dmodules&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=r4LA5jjr_jrRNhddqyy5IsuqRRwHEPCwRMFbxoU1ChI&s=LaNKLek4ewlsoy7ECnW4qRmkBAAVUeo6iTSFqsT9ACo&e=>) you seems to be using.

--
Eric


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valpara?so, Chile


--
Sebastian Mancilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180826/a71048e2/attachment-0001.html>

From quang.t.ha.20 at gmail.com  Mon Aug 27 11:39:54 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Mon, 27 Aug 2018 09:39:54 -0600
Subject: [CMake] CMake specify using either NVCC or host compilers with
 add_executable
Message-ID: <CAGfE9+P_4jkCVsbpBPoDjEL6hDT0QEUiZytacF5wByaMvFb1eQ@mail.gmail.com>

Hi all,

With the new way CMake is treating CUDA codes, now we can do:

project(foo LANGUAGES CXX CUDA)

and can do:

add_executable(foo_cuda foo.cu) # will use NVCC
add_executable(foo_cpp foo.cpp) # will use host compilers

Now since CUDA can take *.cpp files as extension (see
https://stackoverflow.com/questions/26208784/cuda-cpp-files), is there a
away to flip the compiler using one single source files? Something along
the line of:

if(CUDA_FOUND)
  add_executable_with_nvcc(foo_cuda foo.cpp) # of course this doesn't exist
else(CUDA_FOUND)
  add_executable_with_cpp(foo_cpp foo.cpp) # neither does this
endif(CUDA_FOUND)

Or would anyone suggest a work-around? With the help of add_definitions, I
can manually compile a host and device executable - just need to integrate
this final step into the project.

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180827/1612ffc9/attachment.html>

From petr.kmoch at gmail.com  Mon Aug 27 11:48:30 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 27 Aug 2018 17:48:30 +0200
Subject: [CMake] CMake specify using either NVCC or host compilers with
 add_executable
In-Reply-To: <CAGfE9+P_4jkCVsbpBPoDjEL6hDT0QEUiZytacF5wByaMvFb1eQ@mail.gmail.com>
References: <CAGfE9+P_4jkCVsbpBPoDjEL6hDT0QEUiZytacF5wByaMvFb1eQ@mail.gmail.com>
Message-ID: <CAKohaZdFTa14Y_2q6Fa2Ccwbwgk2HsJGgpZTc8EnbiCJp2Viwg@mail.gmail.com>

Hi Quang,

I believe this should be doable with setting the source file's LANGUAGE
property ( https://cmake.org/cmake/help/latest/prop_sf/LANGUAGE.html ):

add_executable(foo_cuda foo.cpp)
set_property(SOURCE foo.cpp PROPERTY LANGUAGE CUDA)

Petr

On Mon, 27 Aug 2018 at 17:40, Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> Hi all,
>
> With the new way CMake is treating CUDA codes, now we can do:
>
> project(foo LANGUAGES CXX CUDA)
>
> and can do:
>
> add_executable(foo_cuda foo.cu) # will use NVCC
> add_executable(foo_cpp foo.cpp) # will use host compilers
>
> Now since CUDA can take *.cpp files as extension (see
> https://stackoverflow.com/questions/26208784/cuda-cpp-files), is there a
> away to flip the compiler using one single source files? Something along
> the line of:
>
> if(CUDA_FOUND)
>   add_executable_with_nvcc(foo_cuda foo.cpp) # of course this doesn't exist
> else(CUDA_FOUND)
>   add_executable_with_cpp(foo_cpp foo.cpp) # neither does this
> endif(CUDA_FOUND)
>
> Or would anyone suggest a work-around? With the help of add_definitions, I
> can manually compile a host and device executable - just need to integrate
> this final step into the project.
>
> Thanks,
> Quang
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180827/8c4daedf/attachment.html>

From brad.king at kitware.com  Mon Aug 27 13:43:16 2018
From: brad.king at kitware.com (Brad King)
Date: Mon, 27 Aug 2018 13:43:16 -0400
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <CAN3TeO2sxtoPUhta=ov+vqJbn5tgFRQ2ezQAHKvQVTzXTC=v0A@mail.gmail.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
 <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
 <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>
 <21e3f070-06ff-12f9-039a-6613ce6e4bfc@kitware.com>
 <4bffbf80-f08b-cedd-23e4-d17a457170fe@kitware.com>
 <CAN3TeO2sxtoPUhta=ov+vqJbn5tgFRQ2ezQAHKvQVTzXTC=v0A@mail.gmail.com>
Message-ID: <feacb992-bbd3-b669-4399-2574920d8a51@kitware.com>

On 08/25/2018 05:48 PM, Richard Shaw wrote:
> set(CMAKE_EXE_LINKER_FLAGS "-T${CMAKE_SOURCE_DIR}/stm32_flash.ld")
> 
> The build dir is the binary directory, not the source directory...

Toolchain files cannot reference variables like CMAKE_SOURCE_DIR
that depend on the source and build tree locations.  They are loaded
inside try_compile projects in addition to the main project, and those
have their own source and build trees.

-Brad

From ke.gao.ut at gmail.com  Tue Aug 28 02:33:08 2018
From: ke.gao.ut at gmail.com (Ke Gao)
Date: Tue, 28 Aug 2018 00:33:08 -0600
Subject: [CMake] Find parent of ${PROJECT_SOURCE_DIR}
Message-ID: <CAMd10VYjv_3fxgPWrmb05ivGBX1Ewfn5+7kRAV+dTmm6435oUw@mail.gmail.com>

Hi,

I tried different way of using GET_FILENAME_COMPONENT to find the parent
path of PROJECT_SOURCE_DIR, or another path relative to the parent of
PROJECT_SOURCE_DIR, never succeeded.

Can anybody help, thank you very much.

None of the following works. I'm using Cmake 2.8.12
GET_FILENAME_COMPONENT(SRC_DIR ${PROJECT_SOURCE_DIR}/../source/ PATH)
GET_FILENAME_COMPONENT(SRC_DIR ${PROJECT_SOURCE_DIR}/../source/ ABSOLUTE)
GET_FILENAME_COMPONENT(ANA_ROOT_DIR ${PROJECT_SOURCE_DIR} ABSOLUTE)
-- 
..............................................................................................................................................
Ke Gao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/e8d4c9ed/attachment.html>

From petr.kmoch at gmail.com  Tue Aug 28 03:00:26 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 28 Aug 2018 09:00:26 +0200
Subject: [CMake] Find parent of ${PROJECT_SOURCE_DIR}
In-Reply-To: <CAMd10VYjv_3fxgPWrmb05ivGBX1Ewfn5+7kRAV+dTmm6435oUw@mail.gmail.com>
References: <CAMd10VYjv_3fxgPWrmb05ivGBX1Ewfn5+7kRAV+dTmm6435oUw@mail.gmail.com>
Message-ID: <CAKohaZeq4YVT0d6JSka9MmStiXQxap2amFn+Z0Ac504OjLsc1g@mail.gmail.com>

Hi,

can you elaborate on how the commands you've shown "don't work?" What do
they do and how does it differ from what you need?

Petr

On Tue, 28 Aug 2018 at 08:33, Ke Gao <ke.gao.ut at gmail.com> wrote:

> Hi,
>
> I tried different way of using GET_FILENAME_COMPONENT to find the parent
> path of PROJECT_SOURCE_DIR, or another path relative to the parent of
> PROJECT_SOURCE_DIR, never succeeded.
>
> Can anybody help, thank you very much.
>
> None of the following works. I'm using Cmake 2.8.12
> GET_FILENAME_COMPONENT(SRC_DIR ${PROJECT_SOURCE_DIR}/../source/ PATH)
> GET_FILENAME_COMPONENT(SRC_DIR ${PROJECT_SOURCE_DIR}/../source/ ABSOLUTE)
> GET_FILENAME_COMPONENT(ANA_ROOT_DIR ${PROJECT_SOURCE_DIR} ABSOLUTE)
> --
>
> ..............................................................................................................................................
> Ke Gao
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/34cf6f8b/attachment.html>

From djobet at tower-research.com  Tue Aug 28 09:26:57 2018
From: djobet at tower-research.com (David Jobet)
Date: Tue, 28 Aug 2018 14:26:57 +0100
Subject: [CMake] protobuf and imports relative to root (and --proto_path)
In-Reply-To: <4057870.Fgg1o8KiqT@linux-l7nd>
References: <CAAV-JT4+MKTDDud-w8j3YTVbm-5htp014VWDTOjbBswhwY9n6A@mail.gmail.com>
 <4057870.Fgg1o8KiqT@linux-l7nd>
Message-ID: <CAAV-JT71MpkVJuu+RhZxaVxRu9m-zPxzeSGrCiyYuy3KYgVH8w@mail.gmail.com>

Hello, thanks for your answer.

Here's a mockup :
projectroot/lib1
projectroot/lib1/CMakeLists.txt
projectroot/lib1/a.proto
projectroot/lib1/b.proto
projectroot/lib1/test.cc

See below for the content of the files.

Here's the cmake output :
$ cmake --build build
[0/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: XXX/temp/build
[1/3] Building CXX object lib1/CMakeFiles/protolib1.dir/a.pb.cc.o
FAILED: lib1/CMakeFiles/protolib1.dir/a.pb.cc.o
XXX/bin/g++   -I. -isystem XXX/include -std=c++14 -Wall   -std=c++14
-MD -MT lib1/CMakeFiles/protolib1.dir/a.pb.cc.o -MF
lib1/CMakeFiles/protolib1.dir/a.pb.cc.o.d -o lib1/CMakeFiles/protoli
b1.dir/a.pb.cc.o -c lib1/a.pb.cc
lib1/a.pb.cc: In function 'void protobuf_AddDesc_a_2eproto()':
lib1/a.pb.cc:79:3: error: '::protobuf_AddDesc_lib1_2fb_2eproto' has
not been declared
  ::protobuf_AddDesc_lib1_2fb_2eproto();
  ^~
ninja: build stopped: subcommand failed.

Here's what's generated from b.proto :
$ cat build/lib1/b.pb.h | grep AddDesc
void  protobuf_AddDesc_b_2eproto();
 friend void  protobuf_AddDesc_b_2eproto();


If I remove the PROTOBUF_IMPORT_DIRS and add "PROTO_PATH
${CMAKE_SOURCE_DIR}" on protobuf_generate_cpp to use my patch (this
injects --proto_path on protoc command line), everything works.
e.g :
#set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR})
protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH
${CMAKE_SOURCE_DIR} a.proto b.proto)

And indeed, the namespace is now correct :
$ cat build/lib1/b.pb.h | grep AddDesc
void  protobuf_AddDesc_lib1_2fb_2eproto();
 friend void  protobuf_AddDesc_lib1_2fb_2eproto();

Again, does anyone know how to make this works without the patch ?
If not, how do someone proposes a patch on cmake ? (posting to the
developper mailing list ?)

David


File contents

-----

$ cat lib1/CMakeLists.txt
project(lib1 LANGUAGES CXX C)

find_package(Protobuf REQUIRED)

set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR})
protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
add_library(protolib1 STATIC ${PROTO_SRCS} ${PROTO_HRDS})
target_include_directories(protolib1 PUBLIC ${CMAKE_BINARY_DIR})
target_link_libraries(protolib1 PUBLIC protobuf::libprotobuf)

add_library(lib1 test.cc)
target_include_directories(lib1 PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(lib1 PRIVATE protolib1)

-----

$ cat lib1/a.proto
import "lib1/b.proto";

message A
{
 optional string toto = 1;
 optional BType  type = 2;
}

-----

$ cat lib1/b.proto
message BType
{
   optional double d = 1;
}

-----

$ cat lib1/test.cc
// Protocol buffer
#include <google/protobuf/text_format.h>
#include "lib1/a.pb.h"
On Thu, Aug 23, 2018 at 9:36 PM Alexander Neundorf <neundorf at kde.org> wrote:
>
> On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> > Hello,
> >
> > I'm trying to port an existing project from premake to cmake.
> > I'm trying to avoid modifying the source files while doing so.
> >
> > Right now, we have several libraries (read in different directories) using
> > proto files with imports between them.
> > All imports are made relative to the root of the project.
> >
> > e.g :
> > work/lib1/sublib1/a.proto
> > work/lib1/sublib1/b.proto
> >
> > with a.proto having a link to b.proto like this "import
> > lib1/sublib1/b.proto"
> >
> > If I compile this with an unchanged FindProtobuf.cmake, I do this :
> >
> > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
> > add_library(...)
> >
> > the problem being that it looks like the "namespaces" generated by protoc
> > in b.proto do not match the one used in a.proto : it does not compile.
>
> do you mean protoc fails, or that the C++ compiler fails when compiling the
> generated file ?
> I'm also using proto files with imports between them and don't have problems
> with finding them.
> Are you setting the PROTOBUF_IMPORT_DIRS variable ?
>
> What I do have a problem is rerunning protoc automatically on proto-files which
> import proto files that have been modified.
> How do you handle this ?
>
> > Is there a way to make this work ?
> >
> > Otherwise, I made the patch below which solves my problem. Do you think it
> > could be included in cmake ?
> > it defines a new option PROTO_PATH, so the decl above becomes
> > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
> > a.proto b.proto)
> >
> > With regards
> >
> > David
> >
> > $ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
> > share/cmake-3.10/Modules/FindProtobuf.cmake
>
> can you please use diff -bup ?
> This makes the patch easier to read.
>
> Thanks
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From george.p.f at mail.com  Tue Aug 28 09:39:45 2018
From: george.p.f at mail.com (George PF)
Date: Tue, 28 Aug 2018 15:39:45 +0200
Subject: [CMake] Iterating over a generator expression list,
 specifically $<TARGET_OBJECTS:objlib> of an OBJECT library
Message-ID: <trinity-2da63bb1-bdb1-4666-a780-14afb7d213e3-1535463585209@3c-app-mailcom-lxa10>

Hello,

how can e.g. $<TARGET_OBJECTS:objlib> be iterated over in cmake?

This builds the lib, but the loop is never run:

    add_library(objlib12 OBJECT lib1.c lib2.c)
    foreach(o IN LISTS $<TARGET_OBJECTS:objlib12>)
        message("obj ${o}")
    endforeach()

But the $<TARGET_OBJECTS:objlib12> variable is set correctly, as this builds a shared library:

    add_library(lib12 SHARED $<TARGET_OBJECTS:objlib12>)

And the ;-separated list is visible when running this custom command via the 'test12' target:

    add_custom_command(OUTPUT libtest.cc
        COMMAND bash -c "echo '$<TARGET_OBJECTS:objlib12>'; echo > libtest.cc"
        VERBATIM)
    add_library(test12 SHARED libtest.cc)


Why does the for loop completely ignore this variable?


Regards

GPF

From eric.noulard at gmail.com  Tue Aug 28 09:48:12 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 28 Aug 2018 15:48:12 +0200
Subject: [CMake] Iterating over a generator expression list,
 specifically $<TARGET_OBJECTS:objlib> of an OBJECT library
In-Reply-To: <trinity-2da63bb1-bdb1-4666-a780-14afb7d213e3-1535463585209@3c-app-mailcom-lxa10>
References: <trinity-2da63bb1-bdb1-4666-a780-14afb7d213e3-1535463585209@3c-app-mailcom-lxa10>
Message-ID: <CAPASGLqdBWKbmhiz9iGxqq-mpAeNvf378bpqaz=_GkX+hoMS7g@mail.gmail.com>

Le mar. 28 ao?t 2018 ? 15:39, George PF <george.p.f at mail.com> a ?crit :

> Hello,
>
> how can e.g. $<TARGET_OBJECTS:objlib> be iterated over in cmake?
>
> This builds the lib, but the loop is never run:
>
>     add_library(objlib12 OBJECT lib1.c lib2.c)
>     foreach(o IN LISTS $<TARGET_OBJECTS:objlib12>)
>         message("obj ${o}")
>     endforeach()
>
> But the $<TARGET_OBJECTS:objlib12> variable is set correctly, as this
> builds a shared library:
>
>     add_library(lib12 SHARED $<TARGET_OBJECTS:objlib12>)
>
> And the ;-separated list is visible when running this custom command via
> the 'test12' target:
>
>     add_custom_command(OUTPUT libtest.cc
>         COMMAND bash -c "echo '$<TARGET_OBJECTS:objlib12>'; echo >
> libtest.cc"
>         VERBATIM)
>     add_library(test12 SHARED libtest.cc)
>
>
> Why does the for loop completely ignore this variable?
>

Because generator expressions are not handled in every cmake construct:

https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html

genex is probably not handled in foreach.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/4ff4c3cb/attachment.html>

From eric.noulard at gmail.com  Tue Aug 28 10:39:59 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 28 Aug 2018 16:39:59 +0200
Subject: [CMake] Iterating over a generator expression list,
 specifically $<TARGET_OBJECTS:objlib> of an OBJECT library
In-Reply-To: <trinity-7344d436-d878-4dc8-be92-06b46d296789-1535465909432@3c-app-mailcom-lxa10>
References: <trinity-2da63bb1-bdb1-4666-a780-14afb7d213e3-1535463585209@3c-app-mailcom-lxa10>
 <CAPASGLqdBWKbmhiz9iGxqq-mpAeNvf378bpqaz=_GkX+hoMS7g@mail.gmail.com>
 <trinity-7344d436-d878-4dc8-be92-06b46d296789-1535465909432@3c-app-mailcom-lxa10>
Message-ID: <CAPASGLo9g-y=NZQ68JiTi+Ub1JP70oRxBgWPHu11eZVpURw3xQ@mail.gmail.com>

I cc the list because I think you drop it inadvertently.

Le mar. 28 ao?t 2018 ? 16:18, George PF <george.p.f at mail.com> a ?crit :

> > Because generator expressions are not handled in every cmake construct:
> >
> https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html
> >
> > genex is probably not handled in foreach.
>
> That is a harsh limitation, set() or list() also does not expand this
> expression.
>

genex are evaluated during "Generation time" i.e. when CMake
produces/generates the specific build system
files (makefile, [build|rules].ninja, MSVC solution etc...). This is
convenient because some (most of) genex informations
may be generator specific (library file name, build artefact location,
etc...)

https://stackoverflow.com/questions/46206495/cmake-generator-expressions

set() , list(), foreach() are "running" at "CMake time" i.e. when cmake
runs and processes CMakeLists.txt and other cmake scripts
that is before "Generation time".


And the variable XYZ, when set via this indirection to TARGET_OBJECTS,
>
>     add_library(lib12 SHARED $<TARGET_OBJECTS:objlib12>)
>     get_property(XYZ TARGET lib12 PROPERTY SOURCES)
>
> is also not expanded yet. Is there a workaround regarding the generator
> expressions, or
> another way to get the TARGET_OBJECTS of an object library (and why is
> this hidden
> behind a generator and not available as a property)?
>

My opinion (but I may be proven wrong by others) is that genex contains
generator specific bits that cannot be **evaluated**
until the build system is generated.  Properties (on target, or directory,
or files) contains informations that is available as soon
as the corresponding CMakeLists.txt part defining the object has been
processed.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/79f78c74/attachment.html>

From quang.t.ha.20 at gmail.com  Tue Aug 28 13:06:58 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Tue, 28 Aug 2018 11:06:58 -0600
Subject: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via
 project LANGUAGE?
Message-ID: <CAGfE9+Nr3V8mUtCdnKDVROx6y3KU5j=C0pJQ-qrX=7ionLFieQ@mail.gmail.com>

Hi all,

So this question is again about project(foo LANGUAGES CXX CUDA). Is it
possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
something along the line:

if (CUDA_FOUND)
  set_language_to_CUDA_and_CXX
else(CUDA_FOUND)
  set_language_to_CXX_only
endif(CUDA_FOUND)

The main reason is I don't want CMake to fail when CUDA compiler isn't
available. Rather, it should continue to compile the source files using CPP
compilers instead.

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/9b54983c/attachment.html>

From eric.noulard at gmail.com  Tue Aug 28 13:28:38 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 28 Aug 2018 19:28:38 +0200
Subject: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via
 project LANGUAGE?
In-Reply-To: <CAGfE9+Nr3V8mUtCdnKDVROx6y3KU5j=C0pJQ-qrX=7ionLFieQ@mail.gmail.com>
References: <CAGfE9+Nr3V8mUtCdnKDVROx6y3KU5j=C0pJQ-qrX=7ionLFieQ@mail.gmail.com>
Message-ID: <CAPASGLoLufxZ=ji6T6d05cY2kdfiWfDYY-WX5XLd_zN9dxnSxg@mail.gmail.com>

Le mar. 28 ao?t 2018 ? 19:07, Quang Ha <quang.t.ha.20 at gmail.com> a ?crit :

> Hi all,
>
> So this question is again about project(foo LANGUAGES CXX CUDA). Is it
> possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
> something along the line:
>

May be you can only:

  project(foo LANGUAGES CXX)

then

include(CheckLanguage)
check_language(CUDA)
if(CMAKE_CUDA_COMPILER)
  enable_language(CUDA)
else()
  message(STATUS "No CUDA compiler found")
endif()

see doc:
https://cmake.org/cmake/help/latest/module/CheckLanguage.html


Eric


> if (CUDA_FOUND)
>   set_language_to_CUDA_and_CXX
> else(CUDA_FOUND)
>   set_language_to_CXX_only
> endif(CUDA_FOUND)
>
> The main reason is I don't want CMake to fail when CUDA compiler isn't
> available. Rather, it should continue to compile the source files using CPP
> compilers instead.
>
> Thanks,
> Quang
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/5f1a25a2/attachment.html>

From robert.maynard at kitware.com  Tue Aug 28 14:36:39 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 28 Aug 2018 11:36:39 -0700
Subject: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via
 project LANGUAGE?
In-Reply-To: <CAPASGLoLufxZ=ji6T6d05cY2kdfiWfDYY-WX5XLd_zN9dxnSxg@mail.gmail.com>
References: <CAGfE9+Nr3V8mUtCdnKDVROx6y3KU5j=C0pJQ-qrX=7ionLFieQ@mail.gmail.com>
 <CAPASGLoLufxZ=ji6T6d05cY2kdfiWfDYY-WX5XLd_zN9dxnSxg@mail.gmail.com>
Message-ID: <CAFzjYVrXnVLOojh+U+ASKEn8ShsUmZRXJL41diDtvrGpEkyE_A@mail.gmail.com>

The way Eric suggest with check_language is what I use when I want to
conditionally support CUDA.

On Tue, Aug 28, 2018 at 10:28 AM Eric Noulard <eric.noulard at gmail.com>
wrote:

>
>
> Le mar. 28 ao?t 2018 ? 19:07, Quang Ha <quang.t.ha.20 at gmail.com> a ?crit :
>
>> Hi all,
>>
>> So this question is again about project(foo LANGUAGES CXX CUDA). Is it
>> possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
>> something along the line:
>>
>
> May be you can only:
>
>   project(foo LANGUAGES CXX)
>
> then
>
> include(CheckLanguage)
> check_language(CUDA)
> if(CMAKE_CUDA_COMPILER)
>   enable_language(CUDA)
> else()
>   message(STATUS "No CUDA compiler found")
> endif()
>
> see doc:
> https://cmake.org/cmake/help/latest/module/CheckLanguage.html
>
>
> Eric
>
>
>> if (CUDA_FOUND)
>>   set_language_to_CUDA_and_CXX
>> else(CUDA_FOUND)
>>   set_language_to_CXX_only
>> endif(CUDA_FOUND)
>>
>> The main reason is I don't want CMake to fail when CUDA compiler isn't
>> available. Rather, it should continue to compile the source files using CPP
>> compilers instead.
>>
>> Thanks,
>> Quang
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
>
> --
> Eric
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/c3fd9026/attachment.html>

From quang.t.ha.20 at gmail.com  Tue Aug 28 14:52:44 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Tue, 28 Aug 2018 12:52:44 -0600
Subject: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via
 project LANGUAGE?
In-Reply-To: <CAFzjYVrXnVLOojh+U+ASKEn8ShsUmZRXJL41diDtvrGpEkyE_A@mail.gmail.com>
References: <CAGfE9+Nr3V8mUtCdnKDVROx6y3KU5j=C0pJQ-qrX=7ionLFieQ@mail.gmail.com>
 <CAPASGLoLufxZ=ji6T6d05cY2kdfiWfDYY-WX5XLd_zN9dxnSxg@mail.gmail.com>
 <CAFzjYVrXnVLOojh+U+ASKEn8ShsUmZRXJL41diDtvrGpEkyE_A@mail.gmail.com>
Message-ID: <CAGfE9+OYpKtNrB-2XS2gAyWeouu070qmQONBuu7qNx0OWfq37Q@mail.gmail.com>

It works perfectly - thanks!

QT

On Tue, 28 Aug 2018 at 12:37, Robert Maynard <robert.maynard at kitware.com>
wrote:

> The way Eric suggest with check_language is what I use when I want to
> conditionally support CUDA.
>
> On Tue, Aug 28, 2018 at 10:28 AM Eric Noulard <eric.noulard at gmail.com>
> wrote:
>
>>
>>
>> Le mar. 28 ao?t 2018 ? 19:07, Quang Ha <quang.t.ha.20 at gmail.com> a
>> ?crit :
>>
>>> Hi all,
>>>
>>> So this question is again about project(foo LANGUAGES CXX CUDA). Is it
>>> possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
>>> something along the line:
>>>
>>
>> May be you can only:
>>
>>   project(foo LANGUAGES CXX)
>>
>> then
>>
>> include(CheckLanguage)
>> check_language(CUDA)
>> if(CMAKE_CUDA_COMPILER)
>>   enable_language(CUDA)
>> else()
>>   message(STATUS "No CUDA compiler found")
>> endif()
>>
>> see doc:
>> https://cmake.org/cmake/help/latest/module/CheckLanguage.html
>>
>>
>> Eric
>>
>>
>>> if (CUDA_FOUND)
>>>   set_language_to_CUDA_and_CXX
>>> else(CUDA_FOUND)
>>>   set_language_to_CXX_only
>>> endif(CUDA_FOUND)
>>>
>>> The main reason is I don't want CMake to fail when CUDA compiler isn't
>>> available. Rather, it should continue to compile the source files using CPP
>>> compilers instead.
>>>
>>> Thanks,
>>> Quang
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>> --
>> Eric
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180828/57a91e28/attachment-0001.html>

From george.p.f at mail.com  Wed Aug 29 08:43:51 2018
From: george.p.f at mail.com (George PF)
Date: Wed, 29 Aug 2018 14:43:51 +0200
Subject: [CMake] Iterating over a generator expression list,
 specifically $<TARGET_OBJECTS:objlib> of an OBJECT library
In-Reply-To: <CAPASGLo9g-y=NZQ68JiTi+Ub1JP70oRxBgWPHu11eZVpURw3xQ@mail.gmail.com>
References: <trinity-2da63bb1-bdb1-4666-a780-14afb7d213e3-1535463585209@3c-app-mailcom-lxa10>
 <CAPASGLqdBWKbmhiz9iGxqq-mpAeNvf378bpqaz=_GkX+hoMS7g@mail.gmail.com>
 <trinity-7344d436-d878-4dc8-be92-06b46d296789-1535465909432@3c-app-mailcom-lxa10>
 <CAPASGLo9g-y=NZQ68JiTi+Ub1JP70oRxBgWPHu11eZVpURw3xQ@mail.gmail.com>
Message-ID: <trinity-9b62a1c4-66a9-40d3-9409-7f571761ef62-1535546631204@3c-app-mailcom-lxa06>

> I cc the list because I think you drop it inadvertently.

Ah, thanks. I'll pay more attention to that now.

> Le mar. 28 ao?t 2018 ? 16:18, George PF <george.p.f at mail.com> a ?crit :
> 
> > > Because generator expressions are not handled in every cmake construct:
> > >
> > https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html
> > >
> > > genex is probably not handled in foreach.
> >
> > That is a harsh limitation, set() or list() also does not expand this
> > expression.
> >
> 
> genex are evaluated during "Generation time" i.e. when CMake
> produces/generates the specific build system
> files (makefile, [build|rules].ninja, MSVC solution etc...). This is
> convenient because some (most of) genex informations
> may be generator specific (library file name, build artefact location,
> etc...)
> 
> https://stackoverflow.com/questions/46206495/cmake-generator-expressions
> 
> set() , list(), foreach() are "running" at "CMake time" i.e. when cmake
> runs and processes CMakeLists.txt and other cmake scripts
> that is before "Generation time".
> 
> 
> And the variable XYZ, when set via this indirection to TARGET_OBJECTS,
> >
> >     add_library(lib12 SHARED $<TARGET_OBJECTS:objlib12>)
> >     get_property(XYZ TARGET lib12 PROPERTY SOURCES)
> >
> > is also not expanded yet. Is there a workaround regarding the generator
> > expressions, or
> > another way to get the TARGET_OBJECTS of an object library (and why is
> > this hidden
> > behind a generator and not available as a property)?
> >
> 
> My opinion (but I may be proven wrong by others) is that genex contains
> generator specific bits that cannot be **evaluated**
> until the build system is generated.  Properties (on target, or directory,
> or files) contains informations that is available as soon
> as the corresponding CMakeLists.txt part defining the object has been
> processed.

That seems more like an internal cmake limitation. Though maybe on purpose so 
the scripts can not be tailored for just one backend.
 
And the documentation says quite optimistically: "Generator expressions are allowed 
in the context of many target properties", a more restrictive phrasing - "only works 
with X / Y for reasons Z" would help there.

From eric.noulard at gmail.com  Wed Aug 29 09:48:45 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 29 Aug 2018 15:48:45 +0200
Subject: [CMake] Iterating over a generator expression list,
 specifically $<TARGET_OBJECTS:objlib> of an OBJECT library
In-Reply-To: <trinity-9b62a1c4-66a9-40d3-9409-7f571761ef62-1535546631204@3c-app-mailcom-lxa06>
References: <trinity-2da63bb1-bdb1-4666-a780-14afb7d213e3-1535463585209@3c-app-mailcom-lxa10>
 <CAPASGLqdBWKbmhiz9iGxqq-mpAeNvf378bpqaz=_GkX+hoMS7g@mail.gmail.com>
 <trinity-7344d436-d878-4dc8-be92-06b46d296789-1535465909432@3c-app-mailcom-lxa10>
 <CAPASGLo9g-y=NZQ68JiTi+Ub1JP70oRxBgWPHu11eZVpURw3xQ@mail.gmail.com>
 <trinity-9b62a1c4-66a9-40d3-9409-7f571761ef62-1535546631204@3c-app-mailcom-lxa06>
Message-ID: <CAPASGLrxW8jgEojBKrXX3EciD7r1fW2tQ_91QEr29Xv0UUqT8A@mail.gmail.com>

Le mer. 29 ao?t 2018 ? 14:44, George PF <george.p.f at mail.com> a ?crit :

>
> >
> > My opinion (but I may be proven wrong by others) is that genex contains
> > generator specific bits that cannot be **evaluated**
> > until the build system is generated.  Properties (on target, or
> directory,
> > or files) contains informations that is available as soon
> > as the corresponding CMakeLists.txt part defining the object has been
> > processed.
>
> That seems more like an internal cmake limitation. Though maybe on purpose
> so
> the scripts can not be tailored for just one backend.
>

I think this was a design choice thus the name "Generator" expression they
are evaluated at generation time
not configuration time and I don't think it's an internal cmake limitation,
I think (but I may be wrong) that this
"generation step" would happen for any generative build system.

And there is more than that about "when" you'll know some var values.
Some generators are supporting "multiple build configuration" like MSVC and
Xcode so that
the build output dir is "mangled" with a prefix **at build time** (since
you can switch configuration after you have generated your project files).
see e.g.
https://cmake.org/cmake/help/latest/variable/CMAKE_CFG_INTDIR.html

And the documentation says quite optimistically: "Generator expressions are
> allowed
> in the context of many target properties", a more restrictive phrasing -
> "only works
> with X / Y for reasons Z" would help there.


I agree this could be clearer.
Having a possibly exhaustive description of where genex may be used would
be nice.
May be it's worth a bug report with a proposal doc update?

Genex support is added in places where it is useful (and possible I guess):
https://gitlab.kitware.com/cmake/cmake/issues/15374
https://gitlab.kitware.com/cmake/cmake/issues/15785

And concerning having them "at configure time", there is open issue
about "configuration expression":
https://gitlab.kitware.com/cmake/cmake/issues/17962


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180829/1512a87d/attachment.html>

From daniel.eiband at brainlab.com  Thu Aug 30 06:31:42 2018
From: daniel.eiband at brainlab.com (Daniel Eiband)
Date: Thu, 30 Aug 2018 10:31:42 +0000
Subject: [CMake] Specify extra files for display in IDE
Message-ID: <bfbc68865e744f92952e3de376620525@despmsx01.brainlab.net>

Hi,

I'm currently migrating a code base from a proprietary MSBuild based generator to CMake 3.11 which is shipped with Visual Studio. There are two aspects to this task:

1) Integration of custom build steps
2) Presentation in the IDE

The first aspect of integrating all of our custom build steps as custom commands works really well. At one point I use an object library to be able to use the object files as input to such a custom tool and to link a shared library. Both the object library and the shared library are from the programmers perspective one logical unit. The object library is just an implementation detail. However, as for the second point, the source files are displayed with the object library target in the IDE while the shared library has no sources. This makes sense from the build targets point of view, but surprises the developers.
My approach is to hide all targets which are sort of implementation detail into a folder.  To make this work I would like to display the sources with the shared library which consumes the object files of the object library. Currently this seems to be impossible.

Another inconsistency I noticed regarding the second point is the following: I implemented header only libraries as interface libraries in CMake. This works fine from the build perspective. Interface libraries however don't allow me to list sources, not even headers. As a result, the headers of this header only library are not displayed anywhere in the IDE. This is odd, because in executable targets for example I can list all headers even if they don't contribute to the build process directly and they are displayed in the IDE. Using empty custom targets to present the header files works, but they are not displayed as C++ libraries in Visual Studio any longer. This also litters the solution with lots of extra empty targets.

I'm going to rephrase both described presentation problems into one more fundamental question, solutions or workarounds for either of both presentation problems are of course welcome: Can I specify sources used for builds and files used for display in IDEs separately? I think they are two different things. For my use case it would also be sufficient to be able to add extra files for display in IDEs to any target.

Regards,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180830/d84ebc4a/attachment.html>

From eric.noulard at gmail.com  Thu Aug 30 08:40:06 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 30 Aug 2018 14:40:06 +0200
Subject: [CMake] Specify extra files for display in IDE
In-Reply-To: <bfbc68865e744f92952e3de376620525@despmsx01.brainlab.net>
References: <bfbc68865e744f92952e3de376620525@despmsx01.brainlab.net>
Message-ID: <CAPASGLreimOvKL1fpvMgAA_FnQXBCBh9L7DFC97+7gMR4+sx_g@mail.gmail.com>

Le jeu. 30 ao?t 2018 ? 12:32, Daniel Eiband <daniel.eiband at brainlab.com> a
?crit :

> Hi,
>
>
>
> I?m currently migrating a code base from a proprietary MSBuild based
> generator to CMake 3.11 which is shipped with Visual Studio. There are two
> aspects to this task:
>
>
>
> 1) Integration of custom build steps
>
> 2) Presentation in the IDE
>
>
>
> The first aspect of integrating all of our custom build steps as custom
> commands works really well. At one point I use an object library to be able
> to use the object files as input to such a custom tool and to link a shared
> library. Both the object library and the shared library are from the
> programmers perspective one logical unit. The object library is just an
> implementation detail. However, as for the second point, the source files
> are displayed with the object library target in the IDE while the shared
> library has no sources. This makes sense from the build targets point of
> view, but surprises the developers.
>
> My approach is to hide all targets which are sort of implementation detail
> into a folder.  To make this work I would like to display the sources with
> the shared library which consumes the object files of the object library.
> Currently this seems to be impossible.
>
>
>
> Another inconsistency I noticed regarding the second point is the
> following: I implemented header only libraries as interface libraries in
> CMake. This works fine from the build perspective. Interface libraries
> however don?t allow me to list sources, not even headers. As a result, the
> headers of this header only library are not displayed anywhere in the IDE.
> This is odd, because in executable targets for example I can list all
> headers even if they don?t contribute to the build process directly and
> they are displayed in the IDE. Using empty custom targets to present the
> header files works, but they are not displayed as C++ libraries in Visual
> Studio any longer. This also litters the solution with lots of extra empty
> targets.
>
>
>
> I?m going to rephrase both described presentation problems into one more
> fundamental question, solutions or workarounds for either of both
> presentation problems are of course welcome: Can I specify sources used for
> builds and files used for display in IDEs separately? I think they are two
> different things. For my use case it would also be sufficient to be able to
> add extra files for display in IDEs to any target.
>

I'm afraid that your question may be generator-specific and I'm no sure
Visual Studio generator behaves in the same way as others I'm using.
I do very often add non source file (like README.md) to any targets
(add_executable, add_library, add_custom_target) in order to make them
editable in the IDE.
Since those file are guessed as not being compilable they inherit the
HEADER_FILE_ONLY  (
https://cmake.org/cmake/help/v3.11/prop_sf/HEADER_FILE_ONLY.html)
automatically
and they show up in IDE just fine.

My particular IDE being either qtcreator, vscode+cmaketools or eclipse and
this works well for those.

Moreover, in qtcreator (for example) header only libraries appear on their
own with editable header file AND as subdir of every other targets their
are used by. This subdir contains the headers.
This is not the case with object libraries though :-(

Concerning the visual grouping you must already being using source_group (
https://cmake.org/cmake/help/latest/command/source_group.html) source_group
does not seems
to have any effect in my favorite IDEs...

In the end I don't know if there is currently any ways to do what you want.

At least the "never displayed" header only library looks like a bug of the
Visual Studio generator to me.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180830/546703a6/attachment.html>

From hobbes1069 at gmail.com  Thu Aug 30 08:46:27 2018
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Thu, 30 Aug 2018 07:46:27 -0500
Subject: [CMake] Build flags not applied during compiler testing on
 Ubuntu
In-Reply-To: <feacb992-bbd3-b669-4399-2574920d8a51@kitware.com>
References: <CAN3TeO1oHp0uanEY8Wz8PcTKzfTxFXnrj6UWET18E2h-jaHPNw@mail.gmail.com>
 <651b367e-7717-674a-71a5-a2b536917e5f@kitware.com>
 <CAN3TeO05DioMF131E_Ak8fdb5o3artc846oLjGAp67sPDw=Knw@mail.gmail.com>
 <bb46b969-96dc-b579-155c-06ae05276070@kitware.com>
 <CAN3TeO2hNmF9au07H3h3MEYZJRsdWCjVnMvhY8fVDcQ9ShSC+A@mail.gmail.com>
 <21e3f070-06ff-12f9-039a-6613ce6e4bfc@kitware.com>
 <4bffbf80-f08b-cedd-23e4-d17a457170fe@kitware.com>
 <CAN3TeO2sxtoPUhta=ov+vqJbn5tgFRQ2ezQAHKvQVTzXTC=v0A@mail.gmail.com>
 <feacb992-bbd3-b669-4399-2574920d8a51@kitware.com>
Message-ID: <CAN3TeO2foEz4XaRmcrMHQyG=eS5YTA07to+7BjefNNXp8TSErw@mail.gmail.com>

On Mon, Aug 27, 2018 at 12:43 PM Brad King <brad.king at kitware.com> wrote:

> On 08/25/2018 05:48 PM, Richard Shaw wrote:
> > set(CMAKE_EXE_LINKER_FLAGS "-T${CMAKE_SOURCE_DIR}/stm32_flash.ld")
> >
> > The build dir is the binary directory, not the source directory...
>
> Toolchain files cannot reference variables like CMAKE_SOURCE_DIR
> that depend on the source and build tree locations.  They are loaded
> inside try_compile projects in addition to the main project, and those
> have their own source and build trees.
>

Ok, fixed but it's really a PITA to have to type -DCMAKE_TOOLCHAIN_FILE=..
so often when 100% of the people on this project are cross-compiling.

And I'm still being bit by differences between Fedora and Ubuntu...

Compiling is working fine again on Fedora but on Ubuntu it's failing to
find the STM32 library. I quite clearly specify its in the BINARY directory
but on Ubuntu it's still looking for it in the SOURCE directory...

set(PERIPHLIBVER    1.8.0)
set(PERIPHLIBNAME   STM32F4xx_DSP_StdPeriph_Lib_V)
set(PERIPHLIBDIR    ${CMAKE_BINARY_DIR}/${PERIPHLIBNAME}${PERIPHLIBVER})
set(CMSIS           ${PERIPHLIBDIR}/Libraries/CMSIS)
set(STM32F4LIB      ${PERIPHLIBDIR}/Libraries/STM32F4xx_StdPeriph_Driver)
set(STM32F4TEMPLATE ${PERIPHLIBDIR}/Project/STM32F4xx_StdPeriph_Templates)
set(DSPLIB          ${PERIPHLIBDIR}/Libraries/CMSIS/DSP_Lib)

Output on Ubuntu:

 cmake -DCMAKE_TOOLCHAIN_FILE=STM32_Toolchain.cmake
~/svn/freetel/codec2-dev/stm32/-- Configuring done
CMake Error at CMakeLists.txt:134 (add_executable):
  Cannot find source file:


/home/richard/svn/freetel/codec2-dev/stm32/STM32F4xx_DSP_StdPeriph_Lib_V1.8.0/Libraries/CMSIS/DSP_Lib/Examples/arm_fft_bin_example/GCC/arm_fft_bin_data.c

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180830/64e479c2/attachment-0001.html>

From daniel.eiband at brainlab.com  Thu Aug 30 09:46:48 2018
From: daniel.eiband at brainlab.com (Daniel Eiband)
Date: Thu, 30 Aug 2018 13:46:48 +0000
Subject: [CMake] Specify extra files for display in IDE
In-Reply-To: <CAPASGLreimOvKL1fpvMgAA_FnQXBCBh9L7DFC97+7gMR4+sx_g@mail.gmail.com>
References: <bfbc68865e744f92952e3de376620525@despmsx01.brainlab.net>
 <CAPASGLreimOvKL1fpvMgAA_FnQXBCBh9L7DFC97+7gMR4+sx_g@mail.gmail.com>
Message-ID: <ed905480536346ef8d5331f667cc9a01@despmsx01.brainlab.net>

Hi Eric,



Thank you for your answers! Visual Studio supports the source_group command, but it cannot be used to add sources. It only controls where source files of targets are displayed.



> I do very often add non source file (like README.md) to any targets



This is what I also do for non-build related files such as readme files. It works except for interface libraries (read below). In the object library case I can add non-build related files, but for let's say 'logical' reasons I would like to show the build related files such as cpp files also in the shared library target which links to the object library.



> At least the "never displayed" header only library looks like a bug of the Visual Studio generator to me.



The situation for interface libraries (header only) is different: CMake won't allow me to add any sources to the target, not even headers. As a result configure fails with an error. I'm pretty sure if I could add headers to interface libraries then they will show up in Visual Studio with this target. So I think it's not a generator bug, but a short-coming of CMake itself.



Daniel


From: Eric Noulard [mailto:eric.noulard at gmail.com]
Sent: Donnerstag, 30. August 2018 14:40
To: Daniel Eiband <daniel.eiband at brainlab.com>
Cc: CMake Mailinglist <cmake at cmake.org>
Subject: Re: [CMake] Specify extra files for display in IDE


Le jeu. 30 ao?t 2018 ? 12:32, Daniel Eiband <daniel.eiband at brainlab.com<mailto:daniel.eiband at brainlab.com>> a ?crit :
Hi,

I?m currently migrating a code base from a proprietary MSBuild based generator to CMake 3.11 which is shipped with Visual Studio. There are two aspects to this task:

1) Integration of custom build steps
2) Presentation in the IDE

The first aspect of integrating all of our custom build steps as custom commands works really well. At one point I use an object library to be able to use the object files as input to such a custom tool and to link a shared library. Both the object library and the shared library are from the programmers perspective one logical unit. The object library is just an implementation detail. However, as for the second point, the source files are displayed with the object library target in the IDE while the shared library has no sources. This makes sense from the build targets point of view, but surprises the developers.
My approach is to hide all targets which are sort of implementation detail into a folder.  To make this work I would like to display the sources with the shared library which consumes the object files of the object library. Currently this seems to be impossible.

Another inconsistency I noticed regarding the second point is the following: I implemented header only libraries as interface libraries in CMake. This works fine from the build perspective. Interface libraries however don?t allow me to list sources, not even headers. As a result, the headers of this header only library are not displayed anywhere in the IDE. This is odd, because in executable targets for example I can list all headers even if they don?t contribute to the build process directly and they are displayed in the IDE. Using empty custom targets to present the header files works, but they are not displayed as C++ libraries in Visual Studio any longer. This also litters the solution with lots of extra empty targets.

I?m going to rephrase both described presentation problems into one more fundamental question, solutions or workarounds for either of both presentation problems are of course welcome: Can I specify sources used for builds and files used for display in IDEs separately? I think they are two different things. For my use case it would also be sufficient to be able to add extra files for display in IDEs to any target.

I'm afraid that your question may be generator-specific and I'm no sure Visual Studio generator behaves in the same way as others I'm using.
I do very often add non source file (like README.md) to any targets (add_executable, add_library, add_custom_target) in order to make them editable in the IDE.
Since those file are guessed as not being compilable they inherit the HEADER_FILE_ONLY  (https://cmake.org/cmake/help/v3.11/prop_sf/HEADER_FILE_ONLY.html) automatically
and they show up in IDE just fine.

My particular IDE being either qtcreator, vscode+cmaketools or eclipse and this works well for those.

Moreover, in qtcreator (for example) header only libraries appear on their own with editable header file AND as subdir of every other targets their are used by. This subdir contains the headers.
This is not the case with object libraries though :-(

Concerning the visual grouping you must already being using source_group (https://cmake.org/cmake/help/latest/command/source_group.html) source_group does not seems
to have any effect in my favorite IDEs...

In the end I don't know if there is currently any ways to do what you want.

At least the "never displayed" header only library looks like a bug of the Visual Studio generator to me.


--
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180830/9a8c76f9/attachment.html>

From george.p.f at mail.com  Thu Aug 30 12:00:51 2018
From: george.p.f at mail.com (George PF)
Date: Thu, 30 Aug 2018 18:00:51 +0200
Subject: [CMake] find_package with COMPONENTS never honors REQUIRED
Message-ID: <trinity-b82bc488-4eb9-4cb4-9b1e-91c2a79dc1a1-1535644851294@3c-app-mailcom-lxa05>

Hi,

once COMPONENTS is added to a find_package statement, any REQUIRED statement ceases to have an effect:

    cmake_minimum_required(VERSION 3.12)

    # find_package(FailsCorrectly REQUIRED)
    
    find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ REQUIRED)
    find_package(Qt REQUIRED COMPONENTS          Qt5XYZ         )
    find_package(Qt          COMPONENTS REQUIRED Qt5XYZ         )
    find_package(Qt          COMPONENTS          Qt5XYZ REQUIRED)
    find_package(Qt          COMPONENTS REQUIRED Qt5XYZ REQUIRED)
    find_package(Qt REQUIRED COMPONENTS          Qt5XYZ REQUIRED)
    find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ         )
    

This CMakeLists.txt runs, despite Qt5XYZ not existing. How can this be made to fail as it should, why 
else would there be OPTIONAL_COMPONENTS as well?

Regards

GPF

From eric.noulard at gmail.com  Thu Aug 30 12:16:23 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 30 Aug 2018 18:16:23 +0200
Subject: [CMake] find_package with COMPONENTS never honors REQUIRED
In-Reply-To: <trinity-b82bc488-4eb9-4cb4-9b1e-91c2a79dc1a1-1535644851294@3c-app-mailcom-lxa05>
References: <trinity-b82bc488-4eb9-4cb4-9b1e-91c2a79dc1a1-1535644851294@3c-app-mailcom-lxa05>
Message-ID: <CAPASGLrt5t+MvCiH1-A808pMFMAecDqMQPDdJ8tE3fzE16z+OQ@mail.gmail.com>

Le jeu. 30 ao?t 2018 ? 18:01, George PF <george.p.f at mail.com> a ?crit :

> Hi,
>
> once COMPONENTS is added to a find_package statement, any REQUIRED
> statement ceases to have an effect:
>
>     cmake_minimum_required(VERSION 3.12)
>
>     # find_package(FailsCorrectly REQUIRED)
>
>     find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ REQUIRED)
>     find_package(Qt REQUIRED COMPONENTS          Qt5XYZ         )
>     find_package(Qt          COMPONENTS REQUIRED Qt5XYZ         )
>     find_package(Qt          COMPONENTS          Qt5XYZ REQUIRED)
>     find_package(Qt          COMPONENTS REQUIRED Qt5XYZ REQUIRED)
>     find_package(Qt REQUIRED COMPONENTS          Qt5XYZ REQUIRED)
>     find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ         )
>
>
> This CMakeLists.txt runs, despite Qt5XYZ not existing. How can this be
> made to fail as it should, why
> else would there be OPTIONAL_COMPONENTS as well?
>

The documentation is intriguing about REQUIRED COMPONENTS interaction....

"A package-specific list of required components may be listed after the
``COMPONENTS`` option (or after the ``REQUIRED`` option if present).
Additional optional components may be listed after
``OPTIONAL_COMPONENTS``."

and....

"Available components and their influence on
whether a package is considered to be found are defined by the target
package."

and later on:

"In Config mode ``find_package`` handles ``REQUIRED``, ``QUIET``, and
``[version]`` options automatically but leaves it to the package
configuration file to handle components in a way that makes sense
for the package.  The package configuration file may set
``<package>_FOUND`` to false to tell ``find_package`` that component
requirements are not satisfied."

So it is possible that the failure behavior when specifying COMPONENTS is
up to the module...

Do you see this only with Qt or do other packages with components (may be
Boost) behave like this?
I guess that Qt5 should be running in config mode, whereas boost must be in
module mode though.

By the way for Qt5 the doc says you shouldn't be using find_package(Qt):
https://cmake.org/cmake/help/latest/module/FindQt.html

But probably directly:
find_package(Qt5)

see example here: https://blog.kitware.com/cmake-finding-qt5-the-right-way/
-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180830/c3f1cf4a/attachment.html>

From george.p.f at mail.com  Thu Aug 30 14:03:44 2018
From: george.p.f at mail.com (George PF)
Date: Thu, 30 Aug 2018 20:03:44 +0200
Subject: [CMake] find_package with COMPONENTS never honors REQUIRED
In-Reply-To: <CAPASGLrt5t+MvCiH1-A808pMFMAecDqMQPDdJ8tE3fzE16z+OQ@mail.gmail.com>
References: <trinity-b82bc488-4eb9-4cb4-9b1e-91c2a79dc1a1-1535644851294@3c-app-mailcom-lxa05>
 <CAPASGLrt5t+MvCiH1-A808pMFMAecDqMQPDdJ8tE3fzE16z+OQ@mail.gmail.com>
Message-ID: <trinity-b723fbf6-746e-4071-af95-2df43a3c5ad7-1535652224536@3c-app-mailcom-lxa05>

> The documentation is intriguing about REQUIRED COMPONENTS interaction....

That's... one way to put it.
 
> "A package-specific list of required components may be listed after the
> ``COMPONENTS`` option (or after the ``REQUIRED`` option if present).
> Additional optional components may be listed after
> ``OPTIONAL_COMPONENTS``."
>  
> and....
>  
> "Available components and their influence on
> whether a package is considered to be found are defined by the target
> package."
>  
> and later on:
>  
> "In Config mode ``find_package`` handles ``REQUIRED``, ``QUIET``, and
> ``[version]`` options automatically but leaves it to the package
> configuration file to handle components in a way that makes sense
> for the package.  The package configuration file may set
> ``<package>_FOUND`` to false to tell ``find_package`` that component
> requirements are not satisfied."
>  
> So it is possible that the failure behavior when specifying COMPONENTS is up to the module...

I admit I was not reading the docs in that depth, but REQUIRED can only mean one thing and should
not need second guessing the documentation. Sadly, someone thought otherwise.

> Do you see this only with Qt or do other packages with components (may be Boost) behave like this?
> I guess that Qt5 should be running in config mode, whereas boost must be in module mode though. 

I was debugging an older cmake project and wondered why it was not finding the non-standard Qt location, 
that's when I stumbled upon this issue.

GPF

From eric.noulard at gmail.com  Thu Aug 30 14:32:17 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 30 Aug 2018 20:32:17 +0200
Subject: [CMake] find_package with COMPONENTS never honors REQUIRED
In-Reply-To: <trinity-b723fbf6-746e-4071-af95-2df43a3c5ad7-1535652224536@3c-app-mailcom-lxa05>
References: <trinity-b82bc488-4eb9-4cb4-9b1e-91c2a79dc1a1-1535644851294@3c-app-mailcom-lxa05>
 <CAPASGLrt5t+MvCiH1-A808pMFMAecDqMQPDdJ8tE3fzE16z+OQ@mail.gmail.com>
 <trinity-b723fbf6-746e-4071-af95-2df43a3c5ad7-1535652224536@3c-app-mailcom-lxa05>
Message-ID: <CAPASGLoVhS_E7B-6Hjb0JrZviDWGs6km5F43qXSvSsvz6_xm0Q@mail.gmail.com>

Le jeu. 30 ao?t 2018 ? 20:03, George PF <george.p.f at mail.com> a ?crit :

> > The documentation is intriguing about REQUIRED COMPONENTS interaction....
>
> That's... one way to put it.
>

Yeah you know. Kind of ironic here :-)


> > So it is possible that the failure behavior when specifying COMPONENTS
> is up to the module...
>
> I admit I was not reading the docs in that depth, but REQUIRED can only
> mean one thing and should
> not need second guessing the documentation. Sadly, someone thought
> otherwise.
>

I guess there is no one to blame here.
The doc is too-realistic about the state of find modules.
At least Config mode should do it right I hope.
Module mode is historically for hand-written module maintained by
volunteers:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/dev/Module-Maintainers

> Do you see this only with Qt or do other packages with components (may be
> Boost) behave like this?
> > I guess that Qt5 should be running in config mode, whereas boost must be
> in module mode though.
>
> I was debugging an older cmake project and wondered why it was not finding
> the non-standard Qt location,
> that's when I stumbled upon this issue.
>

I see. I think something could/should be done for Config mode, for Module
mode It would certainly depends on the module maintainer.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180830/259b5520/attachment.html>

From mario at emmenlauer.de  Thu Aug 30 18:32:03 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Fri, 31 Aug 2018 00:32:03 +0200
Subject: [CMake] are target_compile_definitions not transitive in cmake
 3.12.1?
Message-ID: <9f05ce41-8511-5dae-d830-0074a93fd717@emmenlauer.de>


Sorry if this has been discussed before, I searched the mailing
list and google but could not find this exact issue (only [1] and
[2] that refer to library dependencies).

I have a case where it seems target_compile_definitions() is not
transitive (it is not passed down via libraries), is that possible?
I have a project that sets a PUBLIC definition on libA, and during
the build of libB that links libA the definition is applied. But the
definition does not pass down to executables linking libB. This is
confusing for me because library dependencies and includes seem to
be transitive (linking libB also links libA automatically).

Is it by design that target_compile_definitions() is not transitive
in cmake 3.12.1? Or am I doing something wrong?

[2] https://gitlab.kitware.com/cmake/cmake/issues/17633
[1] https://gitlab.kitware.com/cmake/cmake/issues/12435

All the best,

    Mario Emmenlauer


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

From post at hendrik-sattler.de  Fri Aug 31 04:34:20 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Fri, 31 Aug 2018 08:34:20 +0000
Subject: [CMake] CMake 3.12 and changes in Visual Studio
Message-ID: <20180831083420.Horde.cwefIYnzZaTMRgXjPGs6mUZ@mail.hendrik-sattler.de>

Hi,

in CMake <= 3.11, the CMakeLists.txt file that contains the  
target-creating call, e.g. add_library(), was automatically added to  
the target as visible file in the Solution Explorer.

With CMake 3.12, this is suddenly not the case anymore.
Anybody knows what happened? On purpose or on accident?

Regards,

HS



From post at hendrik-sattler.de  Fri Aug 31 05:21:11 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Fri, 31 Aug 2018 09:21:11 +0000
Subject: [CMake] CMake 3.12 and changes in Visual Studio
In-Reply-To: <20180831083420.Horde.cwefIYnzZaTMRgXjPGs6mUZ@mail.hendrik-sattler.de>
Message-ID: <20180831092111.Horde.MgjXIYStfA-wLIM-t31Pf5_@mail.hendrik-sattler.de>


Zitat von Hendrik Sattler <post at hendrik-sattler.de>:
> Hi,
>
> in CMake <= 3.11, the CMakeLists.txt file that contains the  
> target-creating call, e.g. add_library(), was automatically added to  
> the target as visible file in the Solution Explorer.
>
> With CMake 3.12, this is suddenly not the case anymore.
> Anybody knows what happened? On purpose or on accident?

They can be found at in <targetName>_autogen projects :-/
Something went wrong in CMake 3.12, I'll file a bug report.

Regards,

HS



From sancelot at numalliance.com  Fri Aug 31 09:10:27 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Fri, 31 Aug 2018 15:10:27 +0200
Subject: [CMake] creating a library from other one
Message-ID: <d7acc36e-b332-18bc-afe4-b6b44f4698f3@numalliance.com>

Hi,

I have got some static libraries generated, that? I would like to put in 
a common one.

how can I proceed ?

Regards,

S.Ancelot


From eric.noulard at gmail.com  Fri Aug 31 09:24:37 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 31 Aug 2018 15:24:37 +0200
Subject: [CMake] creating a library from other one
In-Reply-To: <d7acc36e-b332-18bc-afe4-b6b44f4698f3@numalliance.com>
References: <d7acc36e-b332-18bc-afe4-b6b44f4698f3@numalliance.com>
Message-ID: <CAPASGLpw81r-rBbT=nN0u9Ho4rtM5UdAfLdzzC2N9bnBoVYxew@mail.gmail.com>

First create OBJECT libraries instead of static
Then create as many STATIC libraries as you want that includes as many
OBJECT libraries content as you want.


Le ven. 31 ao?t 2018 ? 15:17, St?phane Ancelot <sancelot at numalliance.com> a
?crit :

> Hi,
>
> I have got some static libraries generated, that  I would like to put in
> a common one.
>
> how can I proceed ?
>
> Regards,
>
> S.Ancelot
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


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

From sancelot at numalliance.com  Fri Aug 31 09:59:35 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Fri, 31 Aug 2018 15:59:35 +0200
Subject: [CMake] creating a library from other one
In-Reply-To: <CAPASGLpw81r-rBbT=nN0u9Ho4rtM5UdAfLdzzC2N9bnBoVYxew@mail.gmail.com>
References: <d7acc36e-b332-18bc-afe4-b6b44f4698f3@numalliance.com>
 <CAPASGLpw81r-rBbT=nN0u9Ho4rtM5UdAfLdzzC2N9bnBoVYxew@mail.gmail.com>
Message-ID: <d9fda0ea-880f-5da7-ed3c-a6059d91b5c8@numalliance.com>

I ended with :

add_custom_target(combined ALL
 ?? COMMAND ${CMAKE_AR} rc libcombined.a $<TARGET_FILE:lib1> 
$<TARGET_FILE:lib2>)


Le 31/08/2018 ? 15:24, Eric Noulard a ?crit?:
> First create OBJECT libraries instead of static
> Then create as many STATIC libraries as you want that includes as many 
> OBJECT libraries content as you want.
>
>
> Le?ven. 31 ao?t 2018 ??15:17, St?phane Ancelot 
> <sancelot at numalliance.com <mailto:sancelot at numalliance.com>> a ?crit?:
>
>     Hi,
>
>     I have got some static libraries generated, that? I would like to
>     put in
>     a common one.
>
>     how can I proceed ?
>
>     Regards,
>
>     S.Ancelot
>
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>
>
>
> -- 
> Eric

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

From eric.noulard at gmail.com  Fri Aug 31 10:31:04 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 31 Aug 2018 16:31:04 +0200
Subject: [CMake] creating a library from other one
In-Reply-To: <d9fda0ea-880f-5da7-ed3c-a6059d91b5c8@numalliance.com>
References: <d7acc36e-b332-18bc-afe4-b6b44f4698f3@numalliance.com>
 <CAPASGLpw81r-rBbT=nN0u9Ho4rtM5UdAfLdzzC2N9bnBoVYxew@mail.gmail.com>
 <d9fda0ea-880f-5da7-ed3c-a6059d91b5c8@numalliance.com>
Message-ID: <CAPASGLqZ5+AO8iUncMJP6cHAGKs6DBsFXqbQ-EB8kSBtx=jdYA@mail.gmail.com>

Le ven. 31 ao?t 2018 ? 15:59, St?phane Ancelot <sancelot at numalliance.com> a
?crit :

> I ended with :
>
> add_custom_target(combined ALL
>    COMMAND ${CMAKE_AR} rc libcombined.a $<TARGET_FILE:lib1> $<TARGET_
> FILE:lib2>)
>

Quick & dirty :-)
There is the "thin" option of ar as well:
https://stackoverflow.com/questions/3821916/how-to-merge-two-ar-static-libraries-into-one
if you know the content of lib1 and lib2 don't have name clash.

However libcombined.a is not a proper library target for CMake now.

And by the way does this work on Window too ? Or may be you don't care ?



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180831/69edc477/attachment.html>

From sancelot at numalliance.com  Fri Aug 31 10:41:37 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Fri, 31 Aug 2018 16:41:37 +0200
Subject: [CMake] creating a library from other one
In-Reply-To: <CAPASGLqZ5+AO8iUncMJP6cHAGKs6DBsFXqbQ-EB8kSBtx=jdYA@mail.gmail.com>
References: <d7acc36e-b332-18bc-afe4-b6b44f4698f3@numalliance.com>
 <CAPASGLpw81r-rBbT=nN0u9Ho4rtM5UdAfLdzzC2N9bnBoVYxew@mail.gmail.com>
 <d9fda0ea-880f-5da7-ed3c-a6059d91b5c8@numalliance.com>
 <CAPASGLqZ5+AO8iUncMJP6cHAGKs6DBsFXqbQ-EB8kSBtx=jdYA@mail.gmail.com>
Message-ID: <cec871ca-c8c0-2355-85fc-b4b5df1f6899@numalliance.com>



Le 31/08/2018 ? 16:31, Eric Noulard a ?crit?:
>
>
> Le?ven. 31 ao?t 2018 ??15:59, St?phane Ancelot 
> <sancelot at numalliance.com <mailto:sancelot at numalliance.com>> a ?crit?:
>
>     I ended with :
>
>     add_custom_target(combined ALL
>     ?? COMMAND ${CMAKE_AR} rc libcombined.a $<TARGET_FILE:lib1>
>     $<TARGET_FILE:lib2>)
>
>
> Quick & dirty :-)
> There is the "thin" option of ar as well: 
> https://stackoverflow.com/questions/3821916/how-to-merge-two-ar-static-libraries-into-one
> if you know the content of lib1 and lib2 don't have name clash.
>
> However libcombined.a is not a proper library target for CMake now.
>
> And by the way does this work on Window too ? Or may be you don't care ?
>
>
>
This is on linux and i will take care of windows too.
> -- 
> Eric

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

From bill.hoffman at kitware.com  Fri Aug 31 14:33:32 2018
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Fri, 31 Aug 2018 14:33:32 -0400
Subject: [CMake] Happy Birthday CMake!
Message-ID: <32cb836d-d4cf-83da-6c75-5b7958d9f1a8@kitware.com>

http://public.kitware.com/pipermail/insight-developers/2000-August/024248.html

Thanks to everyone that has contributed or used CMake!

-Bill


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

From sethg at geographika.co.uk  Fri Aug 31 17:37:57 2018
From: sethg at geographika.co.uk (Seth G)
Date: Fri, 31 Aug 2018 23:37:57 +0200
Subject: [CMake] CMake and manylinux Python Wheels
Message-ID: <1535751477.3569623.1493020728.63FFC992@webmail.messagingengine.com>

Hi list,

I'm in the process of updating some SWIG Python bindings for the opensource project MapServer. This uses CMake for the 
build process, and my latest version of CMakeLists can be seen at: https://github.com/geographika/mapserver/blob/python-mapscript-build2/mapscript/python/CMakeLists.txt

I'm trying to automate the creation of Python Wheels for Linux, using the manylinux project (https://www.python.org/dev/peps/pep-0571/). In order to create Wheels that work on 
many different versions of Linux Python (libpython27.so) can't be linked to the Python extension - Python symbols need to be resolved at run-time. I'm not which compiler flags to add, or how to add them using CMake. From many searches I have found the following links are the closely related:

https://github.com/pybind/pybind11/issues/623
https://github.com/scikit-build/scikit-build/pull/47

However both projects are very complex so I'm unable to find exactly how they resolved it. Any hints on how to achieve this are appreciated. 
Please keep in mind both CMake and SWIG are fairly new to me. Any other suggestions/improvements to the CMakeLists file are very welcome. 

Regards,

Seth

--
web:http://geographika.co.uk
twitter: @geographika