From post at hendrik-sattler.de  Sun Jul  1 04:36:59 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Sun, 01 Jul 2018 10:36:59 +0200
Subject: [CMake] Changes to cmake_minimum_required() for 3.12
In-Reply-To: <CA+dygYkN+sN2Mu5=4OWJt7c3uFrr71UKKf3z==L0SWihNOS=QA@mail.gmail.com>
References: <CA+dygYkN+sN2Mu5=4OWJt7c3uFrr71UKKf3z==L0SWihNOS=QA@mail.gmail.com>
Message-ID: <0B6A2E42-C201-4CFD-BE00-BF6E6BD39633@hendrik-sattler.de>

Thanks for the link.
The backwards compatibility is something worth mentioning in the release notes, so that people can use it right away.


Am 1. Juli 2018 00:12:19 MESZ schrieb Craig Scott <craig.scott at crascit.com>:
>(Subject changed to be specific to this discussion)
>
>On Sat, Jun 30, 2018 at 3:13 PM, Hendrik Sattler
><post at hendrik-sattler.de>
>wrote:
>
>> It would actually make even more sense to rename
>cmake_minimum_required()
>> to cmake_version_required() with the new syntax or something similar.
>Users
>> of the old function cannot use the new syntax in older cmake versions
>and
>> the old name does not actually fit the new functionality.
>>
>
>Actually older versions can use the new syntax and this is indeed the
>specific reason why the new syntax is the way it is. Older CMake
>versions
>will see the extra dots as being version component separators and will
>end
>up effectively ignoring the max part. The nett result is that older
>versions will continue to treat the min version as the policy setting
>just
>like they have been to date. Newer versions of CMake will be able to
>take
>advantage of the extra information provided by the max part to allow
>newer
>policies to be enforced.
>
>Regarding the renaming, a very similar discussion took place in the
>merge
>request itself, so I'll refer you to there for details:
>
>https://gitlab.kitware.com/cmake/cmake/merge_requests/1864#note_389157
>
>
>
>
>>
>> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" <
>> irwin at beluga.phys.uvic.ca>:
>> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
>> >[...]
>> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
>> >>  commands now accept a version range using the form
>> >>  "<min>[...<max>]". The "<min>" version is required but policies
>are
>> >>  set based on the "<max>" version.  This allows projects to
>specify a
>> >>  range of versions for which they have been updated and avoid
>> >>  explicit policy settings.
>> >[...]
>> >
>> >I suggest the following change to the above description:
>> >
>> >but policies are set based on the "<max>" version.
>> >
>> >==>
>> >
>> >but policies are set based on the minimum of the running CMake and
>> >"<max>" versions.
>> >
>> >I prefer the latter because it immediately answers the question
>implied
>> >by the former, i.e.,
>> >what happens if the running version is less than max?
>>
>
>Seems reasonable. I've created a MR with a slight tweak to your wording
>for
>this here <https://gitlab.kitware.com/cmake/cmake/merge_requests/2180>.
>
>-- 
>Craig Scott
>Melbourne, Australia
>https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180701/b40e2d6a/attachment.html>

From bram at cocamware.com  Sun Jul  1 18:11:13 2018
From: bram at cocamware.com (Bram de Greve)
Date: Mon, 2 Jul 2018 00:11:13 +0200
Subject: [CMake] how to deprecate a target?
In-Reply-To: <CAFzjYVrorfVn6xpFFv0=gRzUmKisBMW3T52twyANR59mesHGOw@mail.gmail.com>
References: <0f86eea1-1b42-087b-8386-c1b9a36c4bad@cocamware.com>
 <CAFzjYVrorfVn6xpFFv0=gRzUmKisBMW3T52twyANR59mesHGOw@mail.gmail.com>
Message-ID: <5154c6ad-c9aa-9b78-8c91-6bb298ca4f77@cocamware.com>

That is unfortunate ... do you know any not-so-nice ways?

So, what would you recommend here?

I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES 
and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do 
that nicely with variable watches.

But what about the target names?? If I want to guarantee a seamless 
transition period, I should opt to keep using the "foo" target names.? 
But then there's no way to "upgrade" to "Foo::foo" targets without 
breakage, since there's no deprecation strategy. And I can't use target 
aliases, since that is not allowed on imported targets.

To answer my own question, I think the best thing is to move to the 
"Foo::foo" targets right now.? There's at least one downstream package 
that will be hurt by this, but the damage is less than waiting for 
everyone to have moved to the "foo" target first.

Best,

Bram.


On 6/29/2018 20:22, Robert Maynard wrote:
> I am not aware of a nice way to setup CMake to error out if a user
> links to `foo` instead of `Foo::foo`.
> On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <bram at cocamware.com> wrote:
>> Hi all,
>>
>> Consider this situation.  I'm building a Foo packaged, to be used by a
>> Bar project.
>>
>> Foo used to export its target as simply foo.
>> Now it exports its target as Foo::foo.
>>
>> Bar contains this:
>> add_library(bar ...)
>> target_link_libraries(bar foo)
>>
>> This of course must now be:
>> add_library(bar ...)
>> target_link_libraries(bar Foo::foo)
>>
>> But if bar still links to the foo instead of Foo::foo, then CMake
>> doesn't really complain.  foo doesn't exist, but configures and
>> generates just fine.  Of course, you'll face strange build errors, from
>> which it isn't immediately apparent what's causing this ...
>>
>> How can I make sure CMake will complain loudly when bar still links to foo?
>>
>> Thanks,
>> Bram.
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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 espakm at gmail.com  Sun Jul  1 18:17:59 2018
From: espakm at gmail.com (Miklos Espak)
Date: Sun, 1 Jul 2018 23:17:59 +0100
Subject: [CMake] ccmake command missing from 3.12.0 RC releases
Message-ID: <CAOVq=oMdsuhQ9Nk0iQvux4a86CnvgHFhpcnwf9x8FFiAN+=qCw@mail.gmail.com>

Hi,

the 'ccmake' command seems to be missing from the linux tarballs from
3.12.0 RC1 and RC2. Not sure if you are aware of that.

The release notes does not mention that it should be removed, so I hope the
final release is going to have it. :)

Maybe the curses dev package isn't installed on the build machine?

Cheers,
Miklos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180701/c02eb434/attachment.html>

From craig.scott at crascit.com  Sun Jul  1 18:43:57 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 2 Jul 2018 08:43:57 +1000
Subject: [CMake] Changes to cmake_minimum_required() for 3.12
In-Reply-To: <nycvar.QRO.7.76.1807011037180.1815@zreyva.zlyna.ubzr>
References: <CA+dygYkN+sN2Mu5=4OWJt7c3uFrr71UKKf3z==L0SWihNOS=QA@mail.gmail.com>
 <nycvar.QRO.7.76.1807011037180.1815@zreyva.zlyna.ubzr>
Message-ID: <CA+dygY=ZoHhqL8vpunp8bjg73dydFHUFHSaGv=2G10HUjVJUJg@mail.gmail.com>

On Mon, Jul 2, 2018 at 4:04 AM, Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
wrote:

> On 2018-07-01 08:12+1000 Craig Scott wrote:
>
> Older CMake versions
>> will see the extra dots as being version component separators and will end
>> up effectively ignoring the max part.
>>
>
> This explanation of how "..." will be interpreted by older CMake
> versions makes sense, but it wasn't obvious to me without that
> explanation.  And I suspect other build-system developers/maintainers
> would also benefit from the explanation.  Therefore, please explicitly
> include the above explanation in the latest documentation of both the
> cmake_minimum_required and cmake_policy commands.
>

I've updated the merge request to incorporate this feedback.

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

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

From petr.kmoch at gmail.com  Mon Jul  2 03:27:28 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 2 Jul 2018 09:27:28 +0200
Subject: [CMake] how to deprecate a target?
In-Reply-To: <5154c6ad-c9aa-9b78-8c91-6bb298ca4f77@cocamware.com>
References: <0f86eea1-1b42-087b-8386-c1b9a36c4bad@cocamware.com>
 <CAFzjYVrorfVn6xpFFv0=gRzUmKisBMW3T52twyANR59mesHGOw@mail.gmail.com>
 <5154c6ad-c9aa-9b78-8c91-6bb298ca4f77@cocamware.com>
Message-ID: <CAKohaZd0jWgq5LDg-VcazeU1UBeScbj7EvEDM_bizVvGp7YMyA@mail.gmail.com>

Hi Bram.

Wild idea: could you also define a non-namespaced target `foo` and craft it
such that linking against it generates a linker warning? Something like
"Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined
twice, ignoring weak definition."

Petr

On 2 July 2018 at 00:11, Bram de Greve <bram at cocamware.com> wrote:

> That is unfortunate ... do you know any not-so-nice ways?
>
> So, what would you recommend here?
>
> I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES
> and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that
> nicely with variable watches.
>
> But what about the target names?  If I want to guarantee a seamless
> transition period, I should opt to keep using the "foo" target names.  But
> then there's no way to "upgrade" to "Foo::foo" targets without breakage,
> since there's no deprecation strategy. And I can't use target aliases,
> since that is not allowed on imported targets.
>
> To answer my own question, I think the best thing is to move to the
> "Foo::foo" targets right now.  There's at least one downstream package that
> will be hurt by this, but the damage is less than waiting for everyone to
> have moved to the "foo" target first.
>
> Best,
>
> Bram.
>
>
>
> On 6/29/2018 20:22, Robert Maynard wrote:
>
>> I am not aware of a nice way to setup CMake to error out if a user
>> links to `foo` instead of `Foo::foo`.
>> On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <bram at cocamware.com> wrote:
>>
>>> Hi all,
>>>
>>> Consider this situation.  I'm building a Foo packaged, to be used by a
>>> Bar project.
>>>
>>> Foo used to export its target as simply foo.
>>> Now it exports its target as Foo::foo.
>>>
>>> Bar contains this:
>>> add_library(bar ...)
>>> target_link_libraries(bar foo)
>>>
>>> This of course must now be:
>>> add_library(bar ...)
>>> target_link_libraries(bar Foo::foo)
>>>
>>> But if bar still links to the foo instead of Foo::foo, then CMake
>>> doesn't really complain.  foo doesn't exist, but configures and
>>> generates just fine.  Of course, you'll face strange build errors, from
>>> which it isn't immediately apparent what's causing this ...
>>>
>>> How can I make sure CMake will complain loudly when bar still links to
>>> foo?
>>>
>>> Thanks,
>>> Bram.
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/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/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/20180702/632137b3/attachment.html>

From marc.chevrier at gmail.com  Mon Jul  2 04:20:52 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Mon, 2 Jul 2018 10:20:52 +0200
Subject: [CMake] how to deprecate a target?
In-Reply-To: <CAKohaZd0jWgq5LDg-VcazeU1UBeScbj7EvEDM_bizVvGp7YMyA@mail.gmail.com>
References: <0f86eea1-1b42-087b-8386-c1b9a36c4bad@cocamware.com>
 <CAFzjYVrorfVn6xpFFv0=gRzUmKisBMW3T52twyANR59mesHGOw@mail.gmail.com>
 <5154c6ad-c9aa-9b78-8c91-6bb298ca4f77@cocamware.com>
 <CAKohaZd0jWgq5LDg-VcazeU1UBeScbj7EvEDM_bizVvGp7YMyA@mail.gmail.com>
Message-ID: <CAHKTGrcDYuVcfbjUMNvGKS6HLgF3F3JRR0yvvS_XN+PQZnqW4w@mail.gmail.com>

FYI: Starting with CMake 3.11, it is now possible to define an alias of an
imported target.

Le lun. 2 juil. 2018 ? 09:27, Petr Kmoch <petr.kmoch at gmail.com> a ?crit :

> Hi Bram.
>
> Wild idea: could you also define a non-namespaced target `foo` and craft
> it such that linking against it generates a linker warning? Something like
> "Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined
> twice, ignoring weak definition."
>
> Petr
>
> On 2 July 2018 at 00:11, Bram de Greve <bram at cocamware.com> wrote:
>
>> That is unfortunate ... do you know any not-so-nice ways?
>>
>> So, what would you recommend here?
>>
>> I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES
>> and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that
>> nicely with variable watches.
>>
>> But what about the target names?  If I want to guarantee a seamless
>> transition period, I should opt to keep using the "foo" target names.  But
>> then there's no way to "upgrade" to "Foo::foo" targets without breakage,
>> since there's no deprecation strategy. And I can't use target aliases,
>> since that is not allowed on imported targets.
>>
>> To answer my own question, I think the best thing is to move to the
>> "Foo::foo" targets right now.  There's at least one downstream package that
>> will be hurt by this, but the damage is less than waiting for everyone to
>> have moved to the "foo" target first.
>>
>> Best,
>>
>> Bram.
>>
>>
>>
>> On 6/29/2018 20:22, Robert Maynard wrote:
>>
>>> I am not aware of a nice way to setup CMake to error out if a user
>>> links to `foo` instead of `Foo::foo`.
>>> On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <bram at cocamware.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Consider this situation.  I'm building a Foo packaged, to be used by a
>>>> Bar project.
>>>>
>>>> Foo used to export its target as simply foo.
>>>> Now it exports its target as Foo::foo.
>>>>
>>>> Bar contains this:
>>>> add_library(bar ...)
>>>> target_link_libraries(bar foo)
>>>>
>>>> This of course must now be:
>>>> add_library(bar ...)
>>>> target_link_libraries(bar Foo::foo)
>>>>
>>>> But if bar still links to the foo instead of Foo::foo, then CMake
>>>> doesn't really complain.  foo doesn't exist, but configures and
>>>> generates just fine.  Of course, you'll face strange build errors, from
>>>> which it isn't immediately apparent what's causing this ...
>>>>
>>>> How can I make sure CMake will complain loudly when bar still links to
>>>> foo?
>>>>
>>>> Thanks,
>>>> Bram.
>>>>
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/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
>>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180702/8afe4799/attachment-0001.html>

From patrick.boettcher at posteo.de  Mon Jul  2 06:08:16 2018
From: patrick.boettcher at posteo.de (Patrick Boettcher)
Date: Mon, 2 Jul 2018 12:08:16 +0200
Subject: [CMake] .def files since CMake 3.10 in Linux
Message-ID: <20180702120816.30ba4e49@yaise-pc1>

Hi,

I (and someone else) stumbled upon a problem when using the Azure IOTHUB
SDK for C on a Linux platform using cmake 3.10+:

https://github.com/Azure/azure-iot-sdk-c/issues/505

The problem seems to be triggered by having two .def-files as
add_library()-source-files.

During the build cmake generates a command which does:

  cmake -E __create_def

This fails as unknown to cmake.

Is this a cmake-bug or is Azure using .def-files the wrong way?

A quick additional test show that the problem is coming from having
2 .def-files as sources. Having just one is OK.

--
Patrick.




From johannes.zarl-zierl at jku.at  Mon Jul  2 06:43:38 2018
From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl)
Date: Mon, 02 Jul 2018 12:43:38 +0200
Subject: [CMake] Changes to cmake_minimum_required() for 3.12
In-Reply-To: <CA+dygY=ZoHhqL8vpunp8bjg73dydFHUFHSaGv=2G10HUjVJUJg@mail.gmail.com>
References: <CA+dygYkN+sN2Mu5=4OWJt7c3uFrr71UKKf3z==L0SWihNOS=QA@mail.gmail.com>
 <nycvar.QRO.7.76.1807011037180.1815@zreyva.zlyna.ubzr>
 <CA+dygY=ZoHhqL8vpunp8bjg73dydFHUFHSaGv=2G10HUjVJUJg@mail.gmail.com>
Message-ID: <2262448.DDFd0KWYbY@ersa>

Hi,

Just giving my 2 cents:
If the preferred solution is the "POLICY_NEW_UNTIL" wording, then why not make 
this accepted as well? This way, you can deprecate the backwards-compatible 
version in a few years and remove it some time thereafter. In the end, you'll 
get a cleaner solution...

Cheers,
  Johannes


On Montag, 2. Juli 2018 08:43:57 CEST Craig Scott wrote:
> On Mon, Jul 2, 2018 at 4:04 AM, Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
> 
> wrote:
> > On 2018-07-01 08:12+1000 Craig Scott wrote:
> > 
> > Older CMake versions
> > 
> >> will see the extra dots as being version component separators and will
> >> end
> >> up effectively ignoring the max part.
> > 
> > This explanation of how "..." will be interpreted by older CMake
> > versions makes sense, but it wasn't obvious to me without that
> > explanation.  And I suspect other build-system developers/maintainers
> > would also benefit from the explanation.  Therefore, please explicitly
> > include the above explanation in the latest documentation of both the
> > cmake_minimum_required and cmake_policy commands.
> 
> I've updated the merge request to incorporate this feedback.
> 
> https://gitlab.kitware.com/cmake/cmake/merge_requests/2180



-- 
Johannes Zarl-Zierl
Information management

JOHANNES KEPLER UNIVERSITY LINZ
Altenberger Stra?e 69
4040 Linz, Austria
P +43 732 2468 3898
johannes.zarl-zierl at jku.at
www.jku.at

From robert.maynard at kitware.com  Mon Jul  2 08:43:52 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 2 Jul 2018 08:43:52 -0400
Subject: [CMake] ccmake command missing from 3.12.0 RC releases
In-Reply-To: <CAOVq=oMdsuhQ9Nk0iQvux4a86CnvgHFhpcnwf9x8FFiAN+=qCw@mail.gmail.com>
References: <CAOVq=oMdsuhQ9Nk0iQvux4a86CnvgHFhpcnwf9x8FFiAN+=qCw@mail.gmail.com>
Message-ID: <CAFzjYVo2UQGW=tGMrHkbX0o4aWSYbTXP_b9XrvtMo-9iO99oFA@mail.gmail.com>

Thanks for reporting this. I am looking into it.
On Sun, Jul 1, 2018 at 6:18 PM Miklos Espak <espakm at gmail.com> wrote:
>
> Hi,
>
> the 'ccmake' command seems to be missing from the linux tarballs from 3.12.0 RC1 and RC2. Not sure if you are aware of that.
>
> The release notes does not mention that it should be removed, so I hope the final release is going to have it. :)
>
> Maybe the curses dev package isn't installed on the build machine?
>
> Cheers,
> Miklos
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 Jul  2 08:45:50 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 2 Jul 2018 08:45:50 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
In-Reply-To: <0B07540A-39A4-44F3-8FF0-903268A164DB@hendrik-sattler.de>
References: <CAFzjYVqqzGz84JP_2YkNbKkJ9bK4=1Gk9emwB1AKn2-Fatu7tQ@mail.gmail.com>
 <nycvar.QRO.7.76.1806291452430.1815@zreyva.zlyna.ubzr>
 <0B07540A-39A4-44F3-8FF0-903268A164DB@hendrik-sattler.de>
Message-ID: <CAFzjYVqarzns0Ktwmtc=19d3V+ToKsoCi7NuWfst09U13iUSgQ@mail.gmail.com>

> Users of the old function cannot use the new syntax in older cmake versions

The new cmake_minimum_required syntax of MIN...POLICY_MAX is entirely
backwards compatible and will just be ignored by cmake < 3.12.
On Sat, Jun 30, 2018 at 1:14 AM Hendrik Sattler <post at hendrik-sattler.de> wrote:
>
> It would actually make even more sense to rename cmake_minimum_required() to cmake_version_required() with the new syntax or something similar. Users of the old function cannot use the new syntax in older cmake versions and the old name does not actually fit the new functionality.
>
>
> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
> >[...]
> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
> >>  commands now accept a version range using the form
> >>  "<min>[...<max>]". The "<min>" version is required but policies are
> >>  set based on the "<max>" version.  This allows projects to specify a
> >>  range of versions for which they have been updated and avoid
> >>  explicit policy settings.
> >[...]
> >
> >I suggest the following change to the above description:
> >
> >but policies are set based on the "<max>" version.
> >
> >==>
> >
> >but policies are set based on the minimum of the running CMake and
> >"<max>" versions.
> >
> >I prefer the latter because it immediately answers the question implied
> >by the former, i.e.,
> >what happens if the running version is less than max?
> >
> >Alan
> >__________________________
> >Alan W. Irwin
> >
> >Programming affiliations with the FreeEOS equation-of-state
> >implementation for stellar interiors (freeeos.sf.net); the Time
> >Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> >software package (plplot.sf.net); the libLASi project
> >(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> >and the Linux Brochure Project (lbproject.sf.net).
> >__________________________
> >
> >Linux-powered Science
> >__________________________
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From cannysiska at gmail.com  Mon Jul  2 09:39:34 2018
From: cannysiska at gmail.com (canny georgina)
Date: Mon, 2 Jul 2018 20:39:34 +0700
Subject: [CMake] [Error] While compiling as a pre requirement of a software
Message-ID: <CA+fiH=U7GkATivnGG_Gqi_n3edk9UjUR4rg3bQVhcntYz2hvFg@mail.gmail.com>

Dear all,
I've been trying to use a factorization software (CADO-NFS), before I
can use it, I need to compile it, but in order to successfully compile
it, i need Cmake as pre requirement (CADO-NFS developer said that it's
mandatory to have it (Cmake) perfectly installed and compiled). When i
try to compile the CADO-NFS, because i don't have cmake installed, the
software took the initiative to download suitable Cmake and compile by
itself. However, as i face it, there are unexpected error when Cmake
is being compiled. For your information, i installed Cmake on Virtual
Machine (with ubuntu desktop 16.04 as an OS) with 2 GB as RAM. As for
the error information, i got this:

root at ubuntu:/home/chunnie/Desktop/Math3/cado-nfs# make
CMake not found
I am about to download and compile a compatible version of Cmake.
Do you want to continue ? (y/n)
y
Need to get cmake first -- this takes long !
installing cmake 2.8.12 in /home/chunnie/Desktop/Math3/cado-nfs/cmake-installed
--2018-07-02 02:51:01--  http://www.cmake.org/files/v2.8/cmake-2.8.12.tar.gz
Resolving www.cmake.org (www.cmake.org)... 66.194.253.19
Connecting to www.cmake.org (www.cmake.org)|66.194.253.19|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cmake.org/files/v2.8/cmake-2.8.12.tar.gz [following]
--2018-07-02 02:51:03--  http://cmake.org/files/v2.8/cmake-2.8.12.tar.gz
Resolving cmake.org (cmake.org)... 66.194.253.19
Reusing existing connection to www.cmake.org:80.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://cmake.org/files/v2.8/cmake-2.8.12.tar.gz [following]
--2018-07-02 02:51:04--  https://cmake.org/files/v2.8/cmake-2.8.12.tar.gz
Connecting to cmake.org (cmake.org)|66.194.253.19|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6064138 (5.8M) [application/x-gzip]
Saving to: ?cmake-2.8.12.tar.gz?

cmake-2.8.12.tar.gz 100%[===================>]   5.78M  4.06KB/s    in 13m 11s

2018-07-02 03:04:39 (7.49 KB/s) - ?cmake-2.8.12.tar.gz? saved [6064138/6064138]

---------------------------------------------
CMake 2.8.12, Copyright 2000-2012 Kitware, Inc.
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: make
g++ is GNU compiler
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has STL in std:: namespace
g++ has ANSI streams
g++ has streams in std:: namespace
g++ has sstream
g++ has operator!=(string, char*)
g++ has stl iterator_traits
g++ has standard template allocator
g++ has allocator<>::rebind<>
g++ does not have non-standard allocator<>::max_size argument
g++ has stl containers supporting allocator objects
g++ has header cstddef
g++ requires template friends to use <>
g++ supports member templates
g++ has standard template specialization syntax
g++ has argument dependent lookup
g++ has struct stat with st_mtim member
g++ has ios::binary openmode
g++ has ANSI for scoping
---------------------------------------------
make[1]: Entering directory
'/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmStandardIncludes.cxx
-o cmStandardIncludes.o
g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx -o cmake.o
In file included from
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmSystemTools.h:17:0,
                 from /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.h:16,
                 from
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx:12:
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmsys/SystemTools.hxx:633:5:
internal compiler error: Illegal instruction
     double percent_bin = 0.05);
     ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
Makefile:6: recipe for target 'cmake.o' failed
make[1]: *** [cmake.o] Error 1
make[1]: Leaving directory
'/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
---------------------------------------------
Error when bootstrapping CMake:
Problem while running make
---------------------------------------------
Log of errors: /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------
make[1]: Entering directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
make[1]: Entering directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
make[1]: *** No rule to make target 'install'.  Stop.
make[1]: Leaving directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
./scripts/call_cmake.sh: line 152:
/home/chunnie/Desktop/Math3/cado-nfs/cmake-installed/bin/cmake: No
such file or directory
Makefile:7: recipe for target 'all' failed
make: *** [all] Error 1


As for the main information that indicates error on the Cmake is this:

make[1]: Entering directory
'/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmStandardIncludes.cxx
-o cmStandardIncludes.o
g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
-I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx -o cmake.o
In file included from
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmSystemTools.h:17:0,
                 from /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.h:16,
                 from
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx:12:
/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmsys/SystemTools.hxx:633:5:
internal compiler error: Illegal instruction
     double percent_bin = 0.05);
     ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
Makefile:6: recipe for target 'cmake.o' failed
make[1]: *** [cmake.o] Error 1
make[1]: Leaving directory
'/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
---------------------------------------------
Error when bootstrapping CMake:
Problem while running make
---------------------------------------------
Log of errors: /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------

I hope those information help. Thank you.

Best,

Canny Georgina

From alaitsev at gmail.com  Mon Jul  2 09:45:27 2018
From: alaitsev at gmail.com (Innokentiy Alaytsev)
Date: Mon, 2 Jul 2018 06:45:27 -0700 (MST)
Subject: [CMake] [Error] While compiling as a pre requirement of a
 software
In-Reply-To: <CA+fiH=U7GkATivnGG_Gqi_n3edk9UjUR4rg3bQVhcntYz2hvFg@mail.gmail.com>
References: <CA+fiH=U7GkATivnGG_Gqi_n3edk9UjUR4rg3bQVhcntYz2hvFg@mail.gmail.com>
Message-ID: <1530539127111-0.post@n2.nabble.com>

Hello!

Did you try just to install CMake in your virtual machine?

Best regards,
Innokentiy Alaytsev



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

From brad.king at kitware.com  Mon Jul  2 11:40:48 2018
From: brad.king at kitware.com (Brad King)
Date: Mon, 2 Jul 2018 11:40:48 -0400
Subject: [CMake] ccmake command missing from 3.12.0 RC releases
In-Reply-To: <CAFzjYVo2UQGW=tGMrHkbX0o4aWSYbTXP_b9XrvtMo-9iO99oFA@mail.gmail.com>
References: <CAOVq=oMdsuhQ9Nk0iQvux4a86CnvgHFhpcnwf9x8FFiAN+=qCw@mail.gmail.com>
 <CAFzjYVo2UQGW=tGMrHkbX0o4aWSYbTXP_b9XrvtMo-9iO99oFA@mail.gmail.com>
Message-ID: <9426a398-353c-61bd-be01-51432aad2268@kitware.com>

On 07/02/2018 08:43 AM, Robert Maynard wrote:
> On Sun, Jul 1, 2018 at 6:18 PM Miklos Espak wrote:
>> the 'ccmake' command seems to be missing from the linux tarballs
>> from 3.12.0 RC1 and RC2. Not sure if you are aware of that.
>
> Thanks for reporting this. I am looking into it.

Thanks for the report.  See fix and explanation here:

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

-Brad

From espakm at gmail.com  Mon Jul  2 11:54:05 2018
From: espakm at gmail.com (Miklos Espak)
Date: Mon, 2 Jul 2018 16:54:05 +0100
Subject: [CMake] ccmake command missing from 3.12.0 RC releases
In-Reply-To: <9426a398-353c-61bd-be01-51432aad2268@kitware.com>
References: <CAOVq=oMdsuhQ9Nk0iQvux4a86CnvgHFhpcnwf9x8FFiAN+=qCw@mail.gmail.com>
 <CAFzjYVo2UQGW=tGMrHkbX0o4aWSYbTXP_b9XrvtMo-9iO99oFA@mail.gmail.com>
 <9426a398-353c-61bd-be01-51432aad2268@kitware.com>
Message-ID: <CAOVq=oPS=WKurGdZoiwUy00Hv+Otg9OPzcSyBW6eHoa0P=XFFg@mail.gmail.com>

Thanks!

On Mon, 2 Jul 2018 at 16:40, Brad King <brad.king at kitware.com> wrote:

> On 07/02/2018 08:43 AM, Robert Maynard wrote:
> > On Sun, Jul 1, 2018 at 6:18 PM Miklos Espak wrote:
> >> the 'ccmake' command seems to be missing from the linux tarballs
> >> from 3.12.0 RC1 and RC2. Not sure if you are aware of that.
> >
> > Thanks for reporting this. I am looking into it.
>
> Thanks for the report.  See fix and explanation here:
>
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/2186
>
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180702/da0a2b16/attachment.html>

From haocheng.liu at kitware.com  Mon Jul  2 12:09:09 2018
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Mon, 2 Jul 2018 12:09:09 -0400
Subject: [CMake] [Error] While compiling as a pre requirement of a
 software
In-Reply-To: <CA+fiH=U7GkATivnGG_Gqi_n3edk9UjUR4rg3bQVhcntYz2hvFg@mail.gmail.com>
References: <CA+fiH=U7GkATivnGG_Gqi_n3edk9UjUR4rg3bQVhcntYz2hvFg@mail.gmail.com>
Message-ID: <CACbTE7M9eafbt=jouiH4cfyTJKHOEciBFng8jkWbXDxYBeC1CQ@mail.gmail.com>

You need a binary CMake to compile CMake from source code. `apt-get install
cmake` should be more appropriate here...

Btw, CMake 2.8 is a pretty old version. If possible, you should use CMake
>= 3.0.

On Mon, Jul 2, 2018 at 9:39 AM canny georgina <cannysiska at gmail.com> wrote:

> Dear all,
> I've been trying to use a factorization software (CADO-NFS), before I
> can use it, I need to compile it, but in order to successfully compile
> it, i need Cmake as pre requirement (CADO-NFS developer said that it's
> mandatory to have it (Cmake) perfectly installed and compiled). When i
> try to compile the CADO-NFS, because i don't have cmake installed, the
> software took the initiative to download suitable Cmake and compile by
> itself. However, as i face it, there are unexpected error when Cmake
> is being compiled. For your information, i installed Cmake on Virtual
> Machine (with ubuntu desktop 16.04 as an OS) with 2 GB as RAM. As for
> the error information, i got this:
>
> root at ubuntu:/home/chunnie/Desktop/Math3/cado-nfs# make
> CMake not found
> I am about to download and compile a compatible version of Cmake.
> Do you want to continue ? (y/n)
> y
> Need to get cmake first -- this takes long !
> installing cmake 2.8.12 in
> /home/chunnie/Desktop/Math3/cado-nfs/cmake-installed
> --2018-07-02 02:51:01--
> http://www.cmake.org/files/v2.8/cmake-2.8.12.tar.gz
> Resolving www.cmake.org (www.cmake.org)... 66.194.253.19
> Connecting to www.cmake.org (www.cmake.org)|66.194.253.19|:80...
> connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: http://cmake.org/files/v2.8/cmake-2.8.12.tar.gz [following]
> --2018-07-02 02:51:03--  http://cmake.org/files/v2.8/cmake-2.8.12.tar.gz
> Resolving cmake.org (cmake.org)... 66.194.253.19
> Reusing existing connection to www.cmake.org:80.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://cmake.org/files/v2.8/cmake-2.8.12.tar.gz [following]
> --2018-07-02 02:51:04--  https://cmake.org/files/v2.8/cmake-2.8.12.tar.gz
> Connecting to cmake.org (cmake.org)|66.194.253.19|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 6064138 (5.8M) [application/x-gzip]
> Saving to: ?cmake-2.8.12.tar.gz?
>
> cmake-2.8.12.tar.gz 100%[===================>]   5.78M  4.06KB/s    in 13m
> 11s
>
> 2018-07-02 03:04:39 (7.49 KB/s) - ?cmake-2.8.12.tar.gz? saved
> [6064138/6064138]
>
> ---------------------------------------------
> CMake 2.8.12, Copyright 2000-2012 Kitware, Inc.
> Found GNU toolchain
> C compiler on this system is: gcc
> C++ compiler on this system is: g++
> Makefile processor on this system is: make
> g++ is GNU compiler
> g++ has setenv
> g++ has unsetenv
> g++ does not have environ in stdlib.h
> g++ has STL in std:: namespace
> g++ has ANSI streams
> g++ has streams in std:: namespace
> g++ has sstream
> g++ has operator!=(string, char*)
> g++ has stl iterator_traits
> g++ has standard template allocator
> g++ has allocator<>::rebind<>
> g++ does not have non-standard allocator<>::max_size argument
> g++ has stl containers supporting allocator objects
> g++ has header cstddef
> g++ requires template friends to use <>
> g++ supports member templates
> g++ has standard template specialization syntax
> g++ has argument dependent lookup
> g++ has struct stat with st_mtim member
> g++ has ios::binary openmode
> g++ has ANSI for scoping
> ---------------------------------------------
> make[1]: Entering directory
> '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
> g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmStandardIncludes.cxx
> -o cmStandardIncludes.o
> g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx -o cmake.o
> In file included from
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmSystemTools.h:17:0,
>                  from
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.h:16,
>                  from
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx:12:
>
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmsys/SystemTools.hxx:633:5:
> internal compiler error: Illegal instruction
>      double percent_bin = 0.05);
>      ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
> Makefile:6: recipe for target 'cmake.o' failed
> make[1]: *** [cmake.o] Error 1
> make[1]: Leaving directory
> '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
> ---------------------------------------------
> Error when bootstrapping CMake:
> Problem while running make
> ---------------------------------------------
> Log of errors:
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmake_bootstrap.log
> ---------------------------------------------
> make[1]: Entering directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
> make[1]: *** No targets specified and no makefile found.  Stop.
> make[1]: Leaving directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
> make[1]: Entering directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
> make[1]: *** No rule to make target 'install'.  Stop.
> make[1]: Leaving directory '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12'
> ./scripts/call_cmake.sh: line 152:
> /home/chunnie/Desktop/Math3/cado-nfs/cmake-installed/bin/cmake: No
> such file or directory
> Makefile:7: recipe for target 'all' failed
> make: *** [all] Error 1
>
>
> As for the main information that indicates error on the Cmake is this:
>
> make[1]: Entering directory
> '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
> g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmStandardIncludes.cxx
> -o cmStandardIncludes.o
> g++  -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source
> -I/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk -c
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx -o cmake.o
> In file included from
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmSystemTools.h:17:0,
>                  from
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.h:16,
>                  from
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Source/cmake.cxx:12:
>
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmsys/SystemTools.hxx:633:5:
> internal compiler error: Illegal instruction
>      double percent_bin = 0.05);
>      ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
> Makefile:6: recipe for target 'cmake.o' failed
> make[1]: *** [cmake.o] Error 1
> make[1]: Leaving directory
> '/tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk'
> ---------------------------------------------
> Error when bootstrapping CMake:
> Problem while running make
> ---------------------------------------------
> Log of errors:
> /tmp/cmake-build.CZc7zfVj/cmake-2.8.12/Bootstrap.cmk/cmake_bootstrap.log
> ---------------------------------------------
>
> I hope those information help. Thank you.
>
> Best,
>
> Canny Georgina
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180702/fe7ec73e/attachment.html>

From me at pedro-vicente.net  Mon Jul  2 22:41:45 2018
From: me at pedro-vicente.net (Pedro Vicente)
Date: Mon, 2 Jul 2018 22:41:45 -0400
Subject: [CMake] CMake, Visual Studio, do not generate absolute paths
Message-ID: <mailman.0.1530586982.2702.cmake@cmake.org>

So, it seems it is not possible to have CMake NOT to use absolute paths

Quote

?CMake does always use absolute paths. It's part of the concept.?

https://stackoverflow.com/questions/45856955/how-to-tell-cmake-to-use-relative-paths

One use case:

1) I have a Cmake script and I generate a Visual Studio project on machine 1
2) I have another high security computer, machine 2,  where I don?t have administrator privileges
To install software and CMake is on the list of ?not approved? software.
3) I can copy the generated Visual Studio project from machine 1 to machine 2?
But ?alas, all miserably fails to compile because the paths are all wrong


One solution I have used in the past for small projects, like
1 project file, was to manually edit the .vcxproj Visual Studio file


For example replace this

<AdditionalIncludeDirectories>F:\wt.leaflet\wt-4.0.1\src\3rdparty\gason\src;

With a relative path

<AdditionalIncludeDirectories>..\..\..\3rdparty\gason\src;


Which works perfectly (also remove all the CMake generated things, it?s really not needed after the project is made), but for projects where the number of generated projects
Is more than 40, this is not a good way to spend our time

Of course , doing a dedicated program that does this replacement for us
Would be ideal

So, question, does anyone know of the existence of this program?

Also, this post circa 2008 says there was a ?CMAKE_USE_RELATIVE_PATHS?
That seems to have been deprecated


?If you set CMAKE_SUPPRESS_REGENERATION 
to true, and CMAKE_USE_RELATIVE_PATHS to true, you might get things to 
work for a small project. ?


would this work? Of course I would have to travel back in time to 2008, but that?s another problem


https://cmake.org/pipermail/cmake/2008-March/020629.html

I quote here the original post on this thread,

?I cant help but comment that this is unnecessarily complicated when
all that is desired is simply compiling without the Cmake dependency.
Conceptually it should not be this hard.
?

Yes, it should not be this hard for Cmake to have an *OPTION* to use relative paths, maybe ?


http://pedro-vicente.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180702/7ae16069/attachment.html>

From konstantin at podsvirov.pro  Tue Jul  3 01:27:02 2018
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 03 Jul 2018 08:27:02 +0300
Subject: [CMake] Who want find_package(ImGui)?
Message-ID: <4501791530595622@web7o.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/2c10227c/attachment.html>

From andrew.white at audinate.com  Tue Jul  3 02:04:45 2018
From: andrew.white at audinate.com (Andrew White)
Date: Tue, 3 Jul 2018 06:04:45 +0000
Subject: [CMake] Different INSTALL target settings per project
Message-ID: <0A7D70A3-05FF-43AA-BB69-280C120A6256@audinatedante.onmicrosoft.com>

We have a number of project?s that include other projects.  Some of the parent projects are cross-compile projects with various odd settings.

Example project:

	add_subdirectory(a)
	add_subdirectory(b)

I want to go:
	Install(TARGETS target_a program_b
		RUNTIME DESTINATION other-bin
	)

If I put it in the root CMakeLists.txt, CMake complains that the targets are not defined in this context.  But if I put an install() command in subdirs A and B, then the 'other-bin' output path will apply to all projects, not just this one.

Is there an easy way to specify custom install paths for targets in subdirectories without directly hacking the environment variables?

Thanks

--
Andrew


From marc.chevrier at gmail.com  Tue Jul  3 02:44:52 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Tue, 3 Jul 2018 08:44:52 +0200
Subject: [CMake] Different INSTALL target settings per project
In-Reply-To: <0A7D70A3-05FF-43AA-BB69-280C120A6256@audinatedante.onmicrosoft.com>
References: <0A7D70A3-05FF-43AA-BB69-280C120A6256@audinatedante.onmicrosoft.com>
Message-ID: <CAHKTGrfmQAknrF+FS+Ub4deCuZYRNvSCTMRsW1xy1NY6PGZ9tg@mail.gmail.com>

FYI, next release (3.13) will relaxing this contraint so you will be able
to apply this strategy.


Le mar. 3 juil. 2018 ? 08:05, Andrew White <andrew.white at audinate.com> a
?crit :

> We have a number of project?s that include other projects.  Some of the
> parent projects are cross-compile projects with various odd settings.
>
> Example project:
>
>         add_subdirectory(a)
>         add_subdirectory(b)
>
> I want to go:
>         Install(TARGETS target_a program_b
>                 RUNTIME DESTINATION other-bin
>         )
>
> If I put it in the root CMakeLists.txt, CMake complains that the targets
> are not defined in this context.  But if I put an install() command in
> subdirs A and B, then the 'other-bin' output path will apply to all
> projects, not just this one.
>
> Is there an easy way to specify custom install paths for targets in
> subdirectories without directly hacking the environment variables?
>
> Thanks
>
> --
> Andrew
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180703/7597529d/attachment.html>

From jan.svitok at gmail.com  Tue Jul  3 03:33:25 2018
From: jan.svitok at gmail.com (Jano Svitok)
Date: Tue, 3 Jul 2018 09:33:25 +0200
Subject: [CMake] CMake, Visual Studio, do not generate absolute paths
In-Reply-To: <20180703030302.5B42411DFF6@public.kitware.com>
References: <20180703030302.5B42411DFF6@public.kitware.com>
Message-ID: <CAN2u-c6Kb7WToJzTS0xXWF9r4dHVjwE_GfFSNOZZZckwQ2OV7g@mail.gmail.com>

Can you create the tree on the machine 1 so it looks the same as on machine
2 and thus the absolute paths would be the same?
For example
- by using SUBST to create virtual drive at the source root,
- by creating whole virtual machine on machine 1

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst

Jano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/2dcf4c5c/attachment.html>

From petr.kmoch at gmail.com  Tue Jul  3 04:44:29 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 3 Jul 2018 10:44:29 +0200
Subject: [CMake] CMake, Visual Studio, do not generate absolute paths
In-Reply-To: <CAN2u-c6Kb7WToJzTS0xXWF9r4dHVjwE_GfFSNOZZZckwQ2OV7g@mail.gmail.com>
References: <20180703030302.5B42411DFF6@public.kitware.com>
 <CAN2u-c6Kb7WToJzTS0xXWF9r4dHVjwE_GfFSNOZZZckwQ2OV7g@mail.gmail.com>
Message-ID: <CAKohaZeYOp0zGhmsoJFZU1Sd4-JZTK6XcjC+k4SANemeZ7N79Q@mail.gmail.com>

I was going to suggest SUBST as well.

However, note that CMake doesn't need to be installed using a
system-recognised installer, you can just unzip a distribution anywhere you
do have write access. In all seriousness, Visual Studio is a much more
dangerous program than CMake will ever be, as it (= VS) allows you to run
arbitrary code.

Petr

On 3 July 2018 at 09:33, Jano Svitok <jan.svitok at gmail.com> wrote:

> Can you create the tree on the machine 1 so it looks the same as on
> machine 2 and thus the absolute paths would be the same?
> For example
> - by using SUBST to create virtual drive at the source root,
> - by creating whole virtual machine on machine 1
>
> https://docs.microsoft.com/en-us/windows-server/administration/windows-
> commands/subst
>
> Jano
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/39f0f3d1/attachment.html>

From dbegun at protonmail.com  Tue Jul  3 08:58:27 2018
From: dbegun at protonmail.com (dbegun)
Date: Tue, 03 Jul 2018 08:58:27 -0400
Subject: [CMake] CMAKE_SYSROOT
Message-ID: <H6-E68m41QJKyjDdZ_xSpb3dJ9fZM5njx0w50TZ2W47pipHmwpKyfJg-NIX8JusapR1cpOmL0G9v96gGfv70-B0yBdsoIhHwbJaQHqq1DtA=@protonmail.com>

I am cross-compiling some code for ARM on an x86 host with cmake 3.5.1. The code has multiple dependencies, and I placed relevant cross-compiled libraries in /home/dev/arm_build. I was hoping that specifying CMAKE_SYSROOT=/home/dev/arm_build in my CMAKE_TOOLCHAIN_FILE would prefix it to the search path of the find_* commands, so I won't have to modify existing Find*.cmake files. However, when I do that, cmake is unable to locate the compiler's libc files (my compiler also resides in /home/dev/arm_build) and is unable to compile a test program, not finding crt1.o, crti.o etc. Without specifying CMAKE_SYSROOT things work, it's just that I have to edit the Find*.cmake files. I can live with that, but any suggestions?

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/a9d69c3f/attachment-0001.html>

From nilsgladitz at gmail.com  Tue Jul  3 09:11:00 2018
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Tue, 3 Jul 2018 15:11:00 +0200
Subject: [CMake] CMAKE_SYSROOT
In-Reply-To: <H6-E68m41QJKyjDdZ_xSpb3dJ9fZM5njx0w50TZ2W47pipHmwpKyfJg-NIX8JusapR1cpOmL0G9v96gGfv70-B0yBdsoIhHwbJaQHqq1DtA=@protonmail.com>
References: <H6-E68m41QJKyjDdZ_xSpb3dJ9fZM5njx0w50TZ2W47pipHmwpKyfJg-NIX8JusapR1cpOmL0G9v96gGfv70-B0yBdsoIhHwbJaQHqq1DtA=@protonmail.com>
Message-ID: <CAEbDRx15XgTfZYJcKfF-BcKJBnvjEZ5qCWXPrNBKuN=bxOwtLw@mail.gmail.com>

On Tue, Jul 3, 2018 at 3:06 PM dbegun via CMake <cmake at cmake.org> wrote:

> I am cross-compiling some code for ARM on an x86 host with cmake 3.5.1.
> The code has multiple dependencies, and I placed relevant cross-compiled
> libraries in /home/dev/arm_build. I was hoping that
> specifying CMAKE_SYSROOT=/home/dev/arm_build in my CMAKE_TOOLCHAIN_FILE
> would prefix it to the search path of the find_* commands, so I won't have
> to modify existing Find*.cmake files. However, when I do that, cmake is
> unable to locate the compiler's libc files (my compiler also resides in
> /home/dev/arm_build) and is unable to compile a test program, not finding
> crt1.o, crti.o etc. Without specifying CMAKE_SYSROOT things work, it's just
> that I have to edit the Find*.cmake files. I can live with that, but any
> suggestions?
>

It sounds like what you'd want is:
https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH.html

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

From craig.scott at crascit.com  Tue Jul  3 09:15:22 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 3 Jul 2018 23:15:22 +1000
Subject: [CMake] CMAKE_SYSROOT
In-Reply-To: <H6-E68m41QJKyjDdZ_xSpb3dJ9fZM5njx0w50TZ2W47pipHmwpKyfJg-NIX8JusapR1cpOmL0G9v96gGfv70-B0yBdsoIhHwbJaQHqq1DtA=@protonmail.com>
References: <H6-E68m41QJKyjDdZ_xSpb3dJ9fZM5njx0w50TZ2W47pipHmwpKyfJg-NIX8JusapR1cpOmL0G9v96gGfv70-B0yBdsoIhHwbJaQHqq1DtA=@protonmail.com>
Message-ID: <CA+dygYnUTDCW6e_ByY+6eYnwBfuCHdiOm7N1LPg8vvcbLSzT0w@mail.gmail.com>

Perhaps you are looking for CMAKE_FIND_ROOT_PATH
<https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH.html>,
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
<https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH_MODE_LIBRARY.html>
and
friends?

On Tue, Jul 3, 2018 at 10:58 PM, dbegun via CMake <cmake at cmake.org> wrote:

> I am cross-compiling some code for ARM on an x86 host with cmake 3.5.1.
> The code has multiple dependencies, and I placed relevant cross-compiled
> libraries in /home/dev/arm_build. I was hoping that
> specifying CMAKE_SYSROOT=/home/dev/arm_build in my CMAKE_TOOLCHAIN_FILE
> would prefix it to the search path of the find_* commands, so I won't have
> to modify existing Find*.cmake files. However, when I do that, cmake is
> unable to locate the compiler's libc files (my compiler also resides in
> /home/dev/arm_build) and is unable to compile a test program, not finding
> crt1.o, crti.o etc. Without specifying CMAKE_SYSROOT things work, it's just
> that I have to edit the Find*.cmake files. I can live with that, but any
> suggestions?
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/6de026a7/attachment.html>

From dbegun at protonmail.com  Tue Jul  3 09:29:27 2018
From: dbegun at protonmail.com (dbegun)
Date: Tue, 03 Jul 2018 09:29:27 -0400
Subject: [CMake] CMAKE_SYSROOT
In-Reply-To: <CA+dygYnUTDCW6e_ByY+6eYnwBfuCHdiOm7N1LPg8vvcbLSzT0w@mail.gmail.com>
References: <H6-E68m41QJKyjDdZ_xSpb3dJ9fZM5njx0w50TZ2W47pipHmwpKyfJg-NIX8JusapR1cpOmL0G9v96gGfv70-B0yBdsoIhHwbJaQHqq1DtA=@protonmail.com>
 <CA+dygYnUTDCW6e_ByY+6eYnwBfuCHdiOm7N1LPg8vvcbLSzT0w@mail.gmail.com>
Message-ID: <X-WTkTuOuWdA_9HZ6Nv2FQumI1wQ3r20SUTEGFqESYxYNS2afGdjiI7F8zSW3QIDgFoGpSzD8xEPRh_uVJycsoBBcPw4YUZuZ69q0Fj_ssg=@protonmail.com>

Nils, Craig - thanks, yes, that helps.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

??????? Original Message ???????
On July 3, 2018 4:15 PM, Craig Scott <craig.scott at crascit.com> wrote:

> Perhaps you are looking for [CMAKE_FIND_ROOT_PATH](https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH.html), [CMAKE_FIND_ROOT_PATH_MODE_LIBRARY](https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH_MODE_LIBRARY.html) and friends?
>
> On Tue, Jul 3, 2018 at 10:58 PM, dbegun via CMake <cmake at cmake.org> wrote:
>
>> I am cross-compiling some code for ARM on an x86 host with cmake 3.5.1. The code has multiple dependencies, and I placed relevant cross-compiled libraries in /home/dev/arm_build. I was hoping that specifying CMAKE_SYSROOT=/home/dev/arm_build in my CMAKE_TOOLCHAIN_FILE would prefix it to the search path of the find_* commands, so I won't have to modify existing Find*.cmake files. However, when I do that, cmake is unable to locate the compiler's libc files (my compiler also resides in /home/dev/arm_build) and is unable to compile a test program, not finding crt1.o, crti.o etc. Without specifying CMAKE_SYSROOT things work, it's just that I have to edit the Find*.cmake files. I can live with that, but any suggestions?
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/69ac0102/attachment.html>

From jim.petak at keithley.com  Tue Jul  3 14:27:27 2018
From: jim.petak at keithley.com (Petak, Jim)
Date: Tue, 3 Jul 2018 18:27:27 +0000
Subject: [CMake] CMake triggers Windows Defender
Message-ID: <DM6PR12MB26843A2FDCBD685AACD317B195420@DM6PR12MB2684.namprd12.prod.outlook.com>

I'm wondering if anyone has followed up on the issue regarding cmake triggering Windows Defender using the MinGW compiler.  It's a problem that I'm running into as well.
________________________________

Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/a68c4e7e/attachment.html>

From hobbes1069 at gmail.com  Tue Jul  3 16:10:51 2018
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Tue, 3 Jul 2018 15:10:51 -0500
Subject: [CMake] Set flags for compiler check
Message-ID: <CAN3TeO0Yh6J3RdRDOPxisb_1exwhdEhNTDWKROKjmpAX8=7GHw@mail.gmail.com>

I'm working on a cross-compiling project for the STM32F4 arm processor and
on my Fedora 28 system everything is working fine (cmake 3.11.2) but others
trying to configure are running into problems with the compiler check
failing.

Since I'm cross-compiling as far as I know I need "--specs=nosys.specs"
flag added for the compiler check to work which it is for me (relevant
output from CMakeOutput.log):

Building C object CMakeFiles/cmTC_2ac2b.dir/testCCompiler.c.o
/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    -o
CMakeFiles/cmTC_2ac2b.dir/testCCompiler.c.o   -c
/home/build/build/stm32/CMakeFiles/CMakeTmp/testCCompiler.c

But others have no flags being applied (cmake 3.9.1 on Ubuntu):

Building C object CMakeFiles/cmTC_01cf5.dir/testCCompiler.c.obj
/usr/bin/arm-none-eabi-gcc    -o
CMakeFiles/cmTC_01cf5.dir/testCCompiler.c.obj   -c
/home/david/codec2-dev/build_stm32b/CMakeFiles/CMakeTmp/testCCompiler.c

What is the right way to make sure flags are passed to the compiler check?

I assume I could use CMakeForceCompiler but that seems like a last resort...

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180703/c0ccfe23/attachment.html>

From andrew.white at audinate.com  Tue Jul  3 21:33:33 2018
From: andrew.white at audinate.com (Andrew White)
Date: Wed, 4 Jul 2018 01:33:33 +0000
Subject: [CMake] Adding a target to 'all' that was previously excluded
Message-ID: <9DC04ED2-6902-4551-95A6-B94F5F8452AC@audinatedante.onmicrosoft.com>

How do I add an excluded (executable) target to the build.  I know that if I add a library EXCLUDE_FROM_ALL and then create a dependency on that library then that the library will be built anyway.  How do I trigger similar behaviour from an executable target?

Example:

Directory A contains a CMakeLists.txt that builds half a dozen utilities.? As part of my project, I want to add a single target from that list.

I can include the build info without auto-adding all targets by going:

	Add_subdirectory(blah EXCLUDE_FROM_ALL)

How do I then add target blah_X to my 'all' build?  Or is there another way to approach this?

Thanks

--
Andrew


From andrew.white at audinate.com  Tue Jul  3 22:27:58 2018
From: andrew.white at audinate.com (Andrew White)
Date: Wed, 4 Jul 2018 02:27:58 +0000
Subject: [CMake] Changing link flags for one target
Message-ID: <48420D4B-5E32-423C-AA53-3F505A21C126@audinatedante.onmicrosoft.com>

In my cross-compile environment for an embedded platform, I need to set the stack size for each executable.  The linker flag to set the stack size is (for example) "-Wl,-elf2flt='-s 20000'".

Is there an easy way to set this flag for every executable except one, for which I set "-Wl,-elf2flt='-s 40000'"?  Obviously I can call
	Set_target_properties(<target> PROPERTIES LINK_FLAGS "-Wl,-elf2flt='-s 20000'")
on each target, but is there a mechanism to make this the default and then set a different value on a single target?

If necessary, I suspect "-Wl,-elf2flt='-s 20000' -Wl,-elf2flt='-s 40000'" will produce the correct result.
* can I avoid doing it like this?
* how can I be sure that the more specific option will follow the general one?

(Assume all the targets are added via add_subdirectory commands that are common across multiple platforms, and that I'm adding platform-specific build rules in the project CMakeLists.txt)

Thanks

--
Andrew


From post at hendrik-sattler.de  Tue Jul  3 23:06:03 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 04 Jul 2018 05:06:03 +0200
Subject: [CMake] Changing link flags for one target
In-Reply-To: <48420D4B-5E32-423C-AA53-3F505A21C126@audinatedante.onmicrosoft.com>
References: <48420D4B-5E32-423C-AA53-3F505A21C126@audinatedante.onmicrosoft.com>
Message-ID: <278950C4-57E4-4183-9801-71E6D37C8BDC@hendrik-sattler.de>

You could try a generator expression with a custom target property.

Am 4. Juli 2018 04:27:58 MESZ schrieb Andrew White <andrew.white at audinate.com>:
>In my cross-compile environment for an embedded platform, I need to set
>the stack size for each executable.  The linker flag to set the stack
>size is (for example) "-Wl,-elf2flt='-s 20000'".
>
>Is there an easy way to set this flag for every executable except one,
>for which I set "-Wl,-elf2flt='-s 40000'"?  Obviously I can call
>	Set_target_properties(<target> PROPERTIES LINK_FLAGS "-Wl,-elf2flt='-s
>20000'")
>on each target, but is there a mechanism to make this the default and
>then set a different value on a single target?
>
>If necessary, I suspect "-Wl,-elf2flt='-s 20000' -Wl,-elf2flt='-s
>40000'" will produce the correct result.
>* can I avoid doing it like this?
>* how can I be sure that the more specific option will follow the
>general one?
>
>(Assume all the targets are added via add_subdirectory commands that
>are common across multiple platforms, and that I'm adding
>platform-specific build rules in the project CMakeLists.txt)
>
>Thanks
>
>--
>Andrew

From marc.chevrier at gmail.com  Wed Jul  4 02:45:04 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Wed, 4 Jul 2018 08:45:04 +0200
Subject: [CMake] Changing link flags for one target
In-Reply-To: <278950C4-57E4-4183-9801-71E6D37C8BDC@hendrik-sattler.de>
References: <48420D4B-5E32-423C-AA53-3F505A21C126@audinatedante.onmicrosoft.com>
 <278950C4-57E4-4183-9801-71E6D37C8BDC@hendrik-sattler.de>
Message-ID: <CAHKTGreqrB6ibbghwLSj3O2Qe9EvBpam76pvabEznFECQtybBw@mail.gmail.com>

LINK_FLAGS property do not support generator expressions.

In CMake 3.13, directory and target properties LINK_OPTIONS, supporting
generator expressions, managed by commands add_link_options and
target_link_options are introduced, .

For earlier versions you can use global variables to set flags for all
targets (CMAKE_*_LINKER_FLAGS) and use target property LINK_FLAGS to
override default settings (options specified by LINK_FLAGS are defined
*after* those coming from global variable).


Le mer. 4 juil. 2018 ? 05:06, Hendrik Sattler <post at hendrik-sattler.de> a
?crit :

> You could try a generator expression with a custom target property.
>
> Am 4. Juli 2018 04:27:58 MESZ schrieb Andrew White <
> andrew.white at audinate.com>:
> >In my cross-compile environment for an embedded platform, I need to set
> >the stack size for each executable.  The linker flag to set the stack
> >size is (for example) "-Wl,-elf2flt='-s 20000'".
> >
> >Is there an easy way to set this flag for every executable except one,
> >for which I set "-Wl,-elf2flt='-s 40000'"?  Obviously I can call
> >       Set_target_properties(<target> PROPERTIES LINK_FLAGS
> "-Wl,-elf2flt='-s
> >20000'")
> >on each target, but is there a mechanism to make this the default and
> >then set a different value on a single target?
> >
> >If necessary, I suspect "-Wl,-elf2flt='-s 20000' -Wl,-elf2flt='-s
> >40000'" will produce the correct result.
> >* can I avoid doing it like this?
> >* how can I be sure that the more specific option will follow the
> >general one?
> >
> >(Assume all the targets are added via add_subdirectory commands that
> >are common across multiple platforms, and that I'm adding
> >platform-specific build rules in the project CMakeLists.txt)
> >
> >Thanks
> >
> >--
> >Andrew
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180704/5492d799/attachment.html>

From marc.chevrier at gmail.com  Wed Jul  4 02:48:21 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Wed, 4 Jul 2018 08:48:21 +0200
Subject: [CMake] Adding a target to 'all' that was previously excluded
In-Reply-To: <9DC04ED2-6902-4551-95A6-B94F5F8452AC@audinatedante.onmicrosoft.com>
References: <9DC04ED2-6902-4551-95A6-B94F5F8452AC@audinatedante.onmicrosoft.com>
Message-ID: <CAHKTGrfd21=n__4jOjJWUVJG_cdCZDYztkJJA5bgHmqhAb5Mgg@mail.gmail.com>

You can use a new target, built by all, depending on your initial target:

add_custom_target(build_blah_X ALL)
add_dependencies(build_blah_X blah_X)


Le mer. 4 juil. 2018 ? 03:33, Andrew White <andrew.white at audinate.com> a
?crit :

> How do I add an excluded (executable) target to the build.  I know that if
> I add a library EXCLUDE_FROM_ALL and then create a dependency on that
> library then that the library will be built anyway.  How do I trigger
> similar behaviour from an executable target?
>
> Example:
>
> Directory A contains a CMakeLists.txt that builds half a dozen utilities.?
> As part of my project, I want to add a single target from that list.
>
> I can include the build info without auto-adding all targets by going:
>
>         Add_subdirectory(blah EXCLUDE_FROM_ALL)
>
> How do I then add target blah_X to my 'all' build?  Or is there another
> way to approach this?
>
> Thanks
>
> --
> Andrew
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180704/5a72c49f/attachment.html>

From petr.kmoch at gmail.com  Wed Jul  4 03:35:09 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 4 Jul 2018 09:35:09 +0200
Subject: [CMake] Adding a target to 'all' that was previously excluded
In-Reply-To: <CAHKTGrfd21=n__4jOjJWUVJG_cdCZDYztkJJA5bgHmqhAb5Mgg@mail.gmail.com>
References: <9DC04ED2-6902-4551-95A6-B94F5F8452AC@audinatedante.onmicrosoft.com>
 <CAHKTGrfd21=n__4jOjJWUVJG_cdCZDYztkJJA5bgHmqhAb5Mgg@mail.gmail.com>
Message-ID: <CAKohaZeSZPc0R9cqK9wZVR-n1oSrZ-x2gkhhqGi+5xiKYDiS2g@mail.gmail.com>

Hi Andrew.

All that the EXCLUDE_FROM_ALL argument of add_executable() does is set that
target's property EXCLUDE_FROM_ALL to TRUE. So all you need to do is set
that property to false again:

  set_property(TARGET blah PROPERTY EXCLUDE_FROM_ALL FALSE)

Petr

On 4 July 2018 at 08:48, Marc CHEVRIER <marc.chevrier at gmail.com> wrote:

> You can use a new target, built by all, depending on your initial target:
>
> add_custom_target(build_blah_X ALL)
> add_dependencies(build_blah_X blah_X)
>
>
> Le mer. 4 juil. 2018 ? 03:33, Andrew White <andrew.white at audinate.com> a
> ?crit :
>
>> How do I add an excluded (executable) target to the build.  I know that
>> if I add a library EXCLUDE_FROM_ALL and then create a dependency on that
>> library then that the library will be built anyway.  How do I trigger
>> similar behaviour from an executable target?
>>
>> Example:
>>
>> Directory A contains a CMakeLists.txt that builds half a dozen
>> utilities.? As part of my project, I want to add a single target from that
>> list.
>>
>> I can include the build info without auto-adding all targets by going:
>>
>>         Add_subdirectory(blah EXCLUDE_FROM_ALL)
>>
>> How do I then add target blah_X to my 'all' build?  Or is there another
>> way to approach this?
>>
>> Thanks
>>
>> --
>> Andrew
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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/20180704/07df10b5/attachment.html>

From Jens.Trillmann at governikus.de  Wed Jul  4 06:30:56 2018
From: Jens.Trillmann at governikus.de (Trillmann, Jens)
Date: Wed, 4 Jul 2018 10:30:56 +0000
Subject: [CMake] CMAKE_SYSTEM_FRAMEWORK_PATH is not considered when
 generating iOS XCode SYSTEM_FRAMEWORK_SEARCH_PATH
Message-ID: <af544dc4-9503-aace-f184-3cb689f0af36@governikus.de>

Hi,

I'm not sure if this is a bug or if I have misunderstood something. I'm 
linking against Qt-Frameworks on iOS. CMake automatically adds the 
base-path of these Frameworks to the includes of my targets. Because 
there are warnings in the header files and I am building with -Werror, 
these Frameworks have to be linked with -Fsystem. This means for XCode, 
that the SYSTEM_FRAMEWORK_SEARCH_PATH variable must include the base-path.

Using INCLUDE_DIRECTORIES(SYSTEM ${BASE_PATH}) globally for all targets 
works, but destroys any kind of modularization I have built in my project.

Alternatively the CMAKE_SYSTEM_FRAMEWORK_PATH from the CMake Toolchain 
file variable could be used for this. My problem is that the variable is 
not considered in cmGlocalXcodeGenerator.cpp when deciding between 
FRAMEWORK_SEARCH_PATH and SYSTEM_FRAMEWORK_SEARCH_PATH. Is this is 
intended behaviour? Is there maybe another way to solve this?

Thanks in advance,

Jens Trillmann

From francis.giraldeau at gmail.com  Wed Jul  4 10:02:25 2018
From: francis.giraldeau at gmail.com (Francis Giraldeau)
Date: Wed, 4 Jul 2018 10:02:25 -0400
Subject: [CMake] How to specify library dir for imported interface?
Message-ID: <CAC6yHM5ELZ6VoAwiqu0vFPTOPVK5zV8QYGHOuJg1fu65rC-aTw@mail.gmail.com>

> However, it seems no property exists to actually specify the library dir
> of imported target, nor the linker flags to pass when using the
> imported target.
>
> What would be the best way to specify the library dir for an imported
> library?

My workarround at the moment is to add a global link_directories(). It is
not clean, as it lacks the transitivity for library users, but at least it
works.

Cheers,

Francis
-- 
Francis Giraldeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180704/ee3b93e4/attachment.html>

From marc.chevrier at gmail.com  Wed Jul  4 10:43:00 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Wed, 4 Jul 2018 16:43:00 +0200
Subject: [CMake] How to specify library dir for imported interface?
In-Reply-To: <CAC6yHM5ELZ6VoAwiqu0vFPTOPVK5zV8QYGHOuJg1fu65rC-aTw@mail.gmail.com>
References: <CAC6yHM5ELZ6VoAwiqu0vFPTOPVK5zV8QYGHOuJg1fu65rC-aTw@mail.gmail.com>
Message-ID: <CAHKTGrd1i2F703ZFE-K_kZHAE-GihujXoa_fm_B4vzB3M5Cq6w@mail.gmail.com>

Next version of CMake (3.13) will supports properties LINK_OPTIONS as well
as INTERFACE_LINK_OPTIONS.

Le mer. 4 juil. 2018 ? 16:02, Francis Giraldeau <francis.giraldeau at gmail.com>
a ?crit :

> > However, it seems no property exists to actually specify the library dir
> > of imported target, nor the linker flags to pass when using the
> > imported target.
> >
> > What would be the best way to specify the library dir for an imported
> > library?
>
> My workarround at the moment is to add a global link_directories(). It is
> not clean, as it lacks the transitivity for library users, but at least it
> works.
>
> Cheers,
>
> Francis
> --
> Francis Giraldeau
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180704/db3f484f/attachment.html>

From bram at cocamware.com  Wed Jul  4 16:08:34 2018
From: bram at cocamware.com (Bram de Greve)
Date: Wed, 4 Jul 2018 22:08:34 +0200
Subject: [CMake] how to deprecate a target?
In-Reply-To: <CAHKTGrcDYuVcfbjUMNvGKS6HLgF3F3JRR0yvvS_XN+PQZnqW4w@mail.gmail.com>
References: <0f86eea1-1b42-087b-8386-c1b9a36c4bad@cocamware.com>
 <CAFzjYVrorfVn6xpFFv0=gRzUmKisBMW3T52twyANR59mesHGOw@mail.gmail.com>
 <5154c6ad-c9aa-9b78-8c91-6bb298ca4f77@cocamware.com>
 <CAKohaZd0jWgq5LDg-VcazeU1UBeScbj7EvEDM_bizVvGp7YMyA@mail.gmail.com>
 <CAHKTGrcDYuVcfbjUMNvGKS6HLgF3F3JRR0yvvS_XN+PQZnqW4w@mail.gmail.com>
Message-ID: <922bd8e6-13f9-0f99-b5d4-a90cdada0d10@cocamware.com>

Hi Petr, Marc,

I guess I could generate a linker warning, it's indeed not-so-nice, but 
might do the trick ...

It seems aliases are only possible on global imported targets. Mine 
aren't (which is by default I guess). It's probably not a great idea to 
make them global ...

Thanks for the suggestions!
Bram

On 7/2/2018 10:20, Marc CHEVRIER wrote:
> FYI: Starting with CMake 3.11, it is now possible to define an alias 
> of an imported target.
>
> Le?lun. 2 juil. 2018 ??09:27, Petr Kmoch <petr.kmoch at gmail.com 
> <mailto:petr.kmoch at gmail.com>> a ?crit?:
>
>     Hi Bram.
>
>     Wild idea: could you also define a non-namespaced target `foo` and
>     craft it such that linking against it generates a linker warning?
>     Something like "Warning: symbol
>     `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined twice,
>     ignoring weak definition."
>
>     Petr
>
>     On 2 July 2018 at 00:11, Bram de Greve <bram at cocamware.com
>     <mailto:bram at cocamware.com>> wrote:
>
>         That is unfortunate ... do you know any not-so-nice ways?
>
>         So, what would you recommend here?
>
>         I'm deprecating the old ways to use the Foo package (using
>         Foo_LIBRARIES and Foo_INCLUDE_DIRS. You know, the cmake 2.x
>         way of things). I can do that nicely with variable watches.
>
>         But what about the target names?? If I want to guarantee a
>         seamless transition period, I should opt to keep using the
>         "foo" target names.? But then there's no way to "upgrade" to
>         "Foo::foo" targets without breakage, since there's no
>         deprecation strategy. And I can't use target aliases, since
>         that is not allowed on imported targets.
>
>         To answer my own question, I think the best thing is to move
>         to the "Foo::foo" targets right now.? There's at least one
>         downstream package that will be hurt by this, but the damage
>         is less than waiting for everyone to have moved to the "foo"
>         target first.
>
>         Best,
>
>         Bram.
>
>
>
>         On 6/29/2018 20:22, Robert Maynard wrote:
>
>             I am not aware of a nice way to setup CMake to error out
>             if a user
>             links to `foo` instead of `Foo::foo`.
>             On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve
>             <bram at cocamware.com <mailto:bram at cocamware.com>> wrote:
>
>                 Hi all,
>
>                 Consider this situation.? I'm building a Foo packaged,
>                 to be used by a
>                 Bar project.
>
>                 Foo used to export its target as simply foo.
>                 Now it exports its target as Foo::foo.
>
>                 Bar contains this:
>                 add_library(bar ...)
>                 target_link_libraries(bar foo)
>
>                 This of course must now be:
>                 add_library(bar ...)
>                 target_link_libraries(bar Foo::foo)
>
>                 But if bar still links to the foo instead of Foo::foo,
>                 then CMake
>                 doesn't really complain.? foo doesn't exist, but
>                 configures and
>                 generates just fine.? Of course, you'll face strange
>                 build errors, from
>                 which it isn't immediately apparent what's causing
>                 this ...
>
>                 How can I make sure CMake will complain loudly when
>                 bar still links to foo?
>
>                 Thanks,
>                 Bram.
>
>                 --
>
>                 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
>
>
>         -- 
>
>         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
>
>
>     -- 
>
>     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
>

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

From williamjswebster at hotmail.co.uk  Thu Jul  5 13:02:32 2018
From: williamjswebster at hotmail.co.uk (William Webster)
Date: Thu, 5 Jul 2018 17:02:32 +0000
Subject: [CMake] Help: All resources failing to load upon building SFML
 project with CMake
Message-ID: <AM0PR0502MB38577687755D1C7CB4A3AF0090400@AM0PR0502MB3857.eurprd05.prod.outlook.com>

This is my first time attempting to build/package my game with CMake, so apologies if this is a dumb questions/not the place to ask this. In short, i've been following the steps on this (https://github.com/SFML/SFML/wiki/Tutorial%3A-Build-your-SFML-project-with-CMake) tutorial up til now. However, once it came to the very final steps ("cmake CMakeLists.txt", "cmake --build .") my build appears to have failed loading any of my assets. This includes, pictures, sounds & fonts, while all SFML assets appear to be drawing as usual, I cant seem to figure it out. I've attempted to directly reference their file paths in the CMakeLists.txt file, in the hopes that even one variation of the different file paths would work, but no luck. It might go without saying, but run from within my IDE (CLion) the project runs perfectly. Just incase it's relevant (and as there's not really much code I can show here), I've included my CMakeLists.txt code, just incase that might help:

cmake_minimum_required(VERSION 3.8)

# Enable debug symbols by default
if(NOT CMAKE_BUILD_TYPE)
    set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build (Debug or Release)" FORCE)
endif()

project(SK_IVER)

set(CMAKE_CXX_STANDARD 11)

# Set version information in a config.h file
set(SK_IVER_VERSION_MAJOR 1)
set(SK_IVER_VERSION_MINOR 0)
configure_file(
        "${PROJECT_SOURCE_DIR}/config.h.in"
        "${PROJECT_BINARY_DIR}/config.h"
)
include_directories("${PROJECT_BINARY_DIR}")


set(SOURCE_FILES
        main.cpp
        Diver.cpp
        Diver.h
        Ring.cpp Ring.h HandleEvents.cpp HandleEvents.h Background.cpp Background.h Particle.cpp Particle.h Particles.cpp Particles.h Game.cpp Game.h)

# Define sources and executable
set(EXECUTABLE_NAME "SK_IVER")
add_executable(${EXECUTABLE_NAME} ${SOURCE_FILES})

# Detect and add SFML
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})
find_package(SFML REQUIRED system window graphics network audio)
if (SFML_FOUND)
    include_directories(${SFML_INCLUDE_DIR})
    target_link_libraries(SK_IVER ${SFML_LIBRARIES})
endif()

# Install target
install(TARGETS ${EXECUTABLE_NAME} DESTINATION bin)

# CPack packaging
include(InstallRequiredSystemLibraries)
set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/COPYING")
set(CPACK_PACKAGE_VERSION_MAJOR "${myproject_VERSION_MAJOR}")
set(CPACK_PACKAGE_VERSION_MINOR "${myproject_VERSION_MINOR}")
include(CPack)

I've been reading about symbolic links, and have considered that this might be what's needed, have had no luck with implement one up til now. All the files in my project, are stored in a 'Resources/' folder alongside the project files and are all directly referenced using relative paths within my code, such as:

if(!font.loadFromFile("Resources/Font/Arial_Unicode.ttf"))
    std::cout << "ERROR: Could not load font file." << std::endl;

(which loads and runs perfectly from within my IDE)

Thanks in advance for any help or pointers on the matter,
Will.

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

From isaiah.norton at gmail.com  Thu Jul  5 17:01:36 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Thu, 5 Jul 2018 17:01:36 -0400
Subject: [CMake] CMake triggers Windows Defender
In-Reply-To: <DM6PR12MB26843A2FDCBD685AACD317B195420@DM6PR12MB2684.namprd12.prod.outlook.com>
References: <DM6PR12MB26843A2FDCBD685AACD317B195420@DM6PR12MB2684.namprd12.prod.outlook.com>
Message-ID: <CADFtqop3Sjf5P+Ck+gJ6ihqQTU4_MCMy0XbGp9qNc0Ojw0CLTA@mail.gmail.com>

I don't know what the turn-around time is, but you and others might
consider submitting the exe as a false positive:

https://www.microsoft.com/en-us/wdsi/filesubmission

(If you are blocked by this issue, try adding an exclusion rule:
https://support.microsoft.com/en-au/help/4028485/windows-10-add-an-exclusion-to-windows-defender-antivirus
)

On Tue, Jul 3, 2018 at 2:27 PM Petak, Jim <jim.petak at keithley.com> wrote:

> I?m wondering if anyone has followed up on the issue regarding cmake
> triggering Windows Defender using the MinGW compiler.  It?s a problem that
> I?m running into as well.
> ------------------------------
>
> Please be advised that this email may contain confidential information. If
> you are not the intended recipient, please notify us by email by replying
> to the sender and delete this message. The sender disclaims that the
> content of this email constitutes an offer to enter into, or the acceptance
> of, any agreement; provided that the foregoing does not invalidate the
> binding effect of any digital or other electronic reproduction of a manual
> signature that is included in any attachment.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180705/ee4d5cdc/attachment.html>

From sfogoros at att.net  Thu Jul  5 21:17:10 2018
From: sfogoros at att.net (Steve)
Date: Thu, 5 Jul 2018 20:17:10 -0500
Subject: [CMake] CMake triggers Windows Defender
In-Reply-To: <CADFtqop3Sjf5P+Ck+gJ6ihqQTU4_MCMy0XbGp9qNc0Ojw0CLTA@mail.gmail.com>
References: <DM6PR12MB26843A2FDCBD685AACD317B195420@DM6PR12MB2684.namprd12.prod.outlook.com>
 <CADFtqop3Sjf5P+Ck+gJ6ihqQTU4_MCMy0XbGp9qNc0Ojw0CLTA@mail.gmail.com>
Message-ID: <3cb70c2f-c6a0-3abb-80bf-ebd408e136d4@att.net>

I posted the following on 6/18/18, but failed to set the reply-to to 
include the cmake list server.

Thanks for replying.

After I posted to this list I wondered if it was an issue with MinGW. I 
hadn't had any issues with MinGW before but compiled a quick 'hello 
world' to check. Worked fine, no Windows Defender trigger.

'gcc --version' reported 6.3.0, but I went ahead and ran 'mingw-get 
update' and 'mingw-get upgrade' anyway. After upgrade CMake no longer 
triggered Windows Defender during the compiler identification phase.

So, false positive caused by older version of MinGW.

I tried to find the actual version of gcc before and after, but 'gcc 
--version' reported 6.3.0 for both. I found a web site that listed 
MinGW-w64 gcc releases as v5.0.3 2017-11-04 and v5.0.4 2018-06-04. I 
last updated MinGW December 2017, so it's likely I was running v5.0.3 
and got lucky the latest update was 10 days before I started using CMake.

Thank you again Mr. King,

Steve

On 7/5/2018 4:01 PM, Isaiah Norton wrote:
> I don't know what the turn-around time is, but you and others might 
> consider submitting the exe as a false positive:
>
>     https://www.microsoft.com/en-us/wdsi/filesubmission
>
> (If you are blocked by this issue, try adding an exclusion rule: 
> https://support.microsoft.com/en-au/help/4028485/windows-10-add-an-exclusion-to-windows-defender-antivirus)
>
> On Tue, Jul 3, 2018 at 2:27 PM Petak, Jim <jim.petak at keithley.com 
> <mailto:jim.petak at keithley.com>> wrote:
>
>     I?m wondering if anyone has followed up on the issue regarding
>     cmake triggering Windows Defender using the MinGW compiler.? It?s
>     a problem that I?m running into as well.
>
>     ------------------------------------------------------------------------
>
>     Please be advised that this email may contain confidential
>     information. If you are not the intended recipient, please notify
>     us by email by replying to the sender and delete this message. The
>     sender disclaims that the content of this email constitutes an
>     offer to enter into, or the acceptance of, any agreement; provided
>     that the foregoing does not invalidate the binding effect of any
>     digital or other electronic reproduction of a manual signature
>     that is included in any attachment.
>
>     -- 
>
>     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
>
>
>

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

From quang.t.ha.20 at gmail.com  Fri Jul  6 00:01:30 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Thu, 5 Jul 2018 22:01:30 -0600
Subject: [CMake] Using CMake to link C++ and CUDA Object file
Message-ID: <CAGfE9+OPGQ5GyOUyd_i6WdXDeq17FYt9gnuRGcoNQOE4-FaCVw@mail.gmail.com>

Hi all,

Following upon how to perform code linking between CUDA and C++ (here at
https://devblogs.nvidia.com/separate-compilation-linking-cuda-device-code/),
I have successfully come up with a Makefile that is currently working for
my test case:

##################################Makefile###############
##################################
main_objects = main.o
host_objects = host.o
device_objects = device.o

all: $(main_objects) $(host_objects) $(device_objects)
        g++ -O3 -fopenmp $(main_objects) $(host_objects) $(device_objects)
-L/usr/local/cuda/lib64 -lcudart -o main

$(main_objects): $(main_objects:.o=.cpp)
        g++ -O3 -I/usr/local/cuda/include -c $< -o $@

$(host_objects): $(host_objects:.o=.cpp)
        g++ -O3 -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -fopenmp -c $<
-o $@

$(device_objects): $(device_objects:.o=.cu)
        nvcc -O3 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -c $< -o
$@

clean:
        rm -f *.o main
####################################################################
##################################

Now, I am trying to write a CMake for this, my current attempt is as
followed:

##############################################CMakeLists.txt############################################
cmake_minimum_required(VERSION 3.8)
project(MyTest LANGUAGES CXX CUDA)

# check requirements
find_package(CUDA REQUIRED)
find_package(OpenMP)

if (CUDA_FOUND AND OPENMP_FOUND)
    # OpenMP
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
${OpenMP_EXE_LINKER_FLAGS}")

    # CUDA
    include_directories(${CUDA_INCLUDE_DIRS})
    set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
${CUDA_cublas_LIBRARY})
    set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
    set(CUDA_SEPARABLE_COMPILATION OFF)
    set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)

    set(OMP_SOURCES host.cpp)
    add_library(Host_OMP SHARED ${OMP_SOURCES})
    set_target_properties(Host_OMP PROPERTIES COMPILE_FLAGS
"-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP")
    set(LIBS ${LIBS} ${Host_OMP})

    set(CUDA_SOURCES device.cu)
    cuda_add_library(Device_CUDA SHARED ${CUDA_SOURCES})
    set_target_properties(Device_CUDA PROPERTIES COMPILE_FLAGS
"-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
    set_target_properties(Device_CUDA PROPERTIES CUDA_SEPERABLE_COMPILATION
ON)
    set(LIBS ${LIBS} ${Device_CUDA})

    add_executable(main main.cpp)
    target_link_libraries(main ${LIBS})

endif(CUDA_FOUND AND OPENMP_FOUND)
####################################################################
##################################

It is still, unfortunately, not working. If I commented out the
add_executable line, the object code for Host_OMP and Device_CUDA is
compiled. I can then use the terminal and link them with main.cpp using gcc
and generate the executable - i.e. using the final command in the Makefile
above.

What am I doing wrong here? It seems to be very fundamental, but I can't
seem to get it right...

Any suggestions would be greatly appreciated!!

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180705/13087b00/attachment.html>

From james.weir at wesio.co.uk  Fri Jul  6 03:21:25 2018
From: james.weir at wesio.co.uk (James Weir)
Date: Fri, 6 Jul 2018 08:21:25 +0100
Subject: [CMake] Equivalent of fixup_bundle for frameworks?
Message-ID: <02F3AB6D-82F7-4F0C-81F0-6D37FF9ABE66@wesio.co.uk>

Hi All,

Before I set of on lots of custom functionality is there an equivalent to fixup_bundle for frameworks for iOS/macOS? The task is roughly the same, gather the required dylibs, copy them to the frameworks (in the case of iOS) folder, adjust rpaths?.

Thanks in advance!

Kind Regards, James

From temp1 at andreasen.cc  Fri Jul  6 06:25:40 2018
From: temp1 at andreasen.cc (Mads Andreasen)
Date: Fri, 6 Jul 2018 12:25:40 +0200
Subject: [CMake] CMAKE_ARGS for FetchContent
Message-ID: <CAHbn=FN73G=8zMCka8FzSeCNL=QTfQ6zSzMf8us_yqbvOfA2aw@mail.gmail.com>

Hi,

I am trying to work with FetchContent in cmake 3.11.
I want to use the jsoncpp library and use FetchContent to get and build it.

I also want to configure the jsoncpp build with some cmake arguments and I
can't seem to get that right.

My CMakeLists.txt looks like this:
**************************************************************
cmake_minimum_required(VERSION 3.11)
project(Foo)

include(FetchContent)

FetchContent_Declare(jsoncpp
  URL "c:/project/jsoncpp-src"
    CMAKE_ARGS
"-DJSONCPP_WITH_CMAKE_PACKAGE=ON;-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
)

FetchContent_Populate(jsoncpp)

add_executable(Foo main.cpp)
**************************************************************


FetchContent downloads and configures the jsoncpp as an ExternalProject.
That part looks like this:
*********************************************
ExternalProject_Add(jsoncpp-populate
                     "UPDATE_DISCONNECTED" "False" "URL"
"c:/project/jsoncpp-src" "CMAKE_ARGS" "-DJSONCPP_WITH_CMAKE_PACKAGE=ON"
"-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
                    SOURCE_DIR
"C:/temp/foo/build/_deps/jsoncpp-src"
                    BINARY_DIR
"C:/temp/foo/build/_deps/jsoncpp-build"
                    CONFIGURE_COMMAND   ""
                    BUILD_COMMAND       ""
                    INSTALL_COMMAND     ""
                    TEST_COMMAND        ""
)
*******************************************************

For the external project - the CMAKE_ARGS are no longer a list, but
individual arguments.

I have tried different things, like escaping the ; with \\; and stuff like
that, and I can't get it to work.
I'm thinking there is something obvious I am missing?

Best regards,
Mads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180706/73c04ab4/attachment.html>

From craig.scott at crascit.com  Fri Jul  6 06:41:46 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 6 Jul 2018 20:41:46 +1000
Subject: [CMake] CMAKE_ARGS for FetchContent
In-Reply-To: <CAHbn=FN73G=8zMCka8FzSeCNL=QTfQ6zSzMf8us_yqbvOfA2aw@mail.gmail.com>
References: <CAHbn=FN73G=8zMCka8FzSeCNL=QTfQ6zSzMf8us_yqbvOfA2aw@mail.gmail.com>
Message-ID: <CA+dygY=3fJv8JQDzLUMF-X7+Obq-B7JbPcZFcZ0=VjxCk=adkA@mail.gmail.com>

On Fri, Jul 6, 2018 at 8:25 PM, Mads Andreasen <temp1 at andreasen.cc> wrote:

> Hi,
>
> I am trying to work with FetchContent in cmake 3.11.
> I want to use the jsoncpp library and use FetchContent to get and build it.
>

FetchContent can only download it. You need to build it as a separate step
(you should avoid building things during the configure phase as much as
possible). The expected pattern is to add the downloaded contents to your
existing build via add_subdirectory(). If you want to keep the build
isolated from your main build, then use ExternalProject directly rather
than FetchContent.



>
> I also want to configure the jsoncpp build with some cmake arguments and I
> can't seem to get that right.
>
> My CMakeLists.txt looks like this:
> **************************************************************
> cmake_minimum_required(VERSION 3.11)
> project(Foo)
>
> include(FetchContent)
>
> FetchContent_Declare(jsoncpp
>   URL "c:/project/jsoncpp-src"
>     CMAKE_ARGS "-DJSONCPP_WITH_CMAKE_PACKAGE=ON;-DJSONCPP_WITH_PKGCONFIG_
> SUPPORT=OFF"
> )
>
> FetchContent_Populate(jsoncpp)
>
> add_executable(Foo main.cpp)
> **************************************************************
>

The configure, build, test and install steps of ExternalProject do not
apply to FetchContent, that's why CMAKE_ARGS has no effect.





>
>
> FetchContent downloads and configures the jsoncpp as an ExternalProject.
>

No, it only downloads, not configures.



> That part looks like this:
> *********************************************
> ExternalProject_Add(jsoncpp-populate
>                      "UPDATE_DISCONNECTED" "False" "URL"
> "c:/project/jsoncpp-src" "CMAKE_ARGS" "-DJSONCPP_WITH_CMAKE_PACKAGE=ON"
> "-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
>                     SOURCE_DIR          "C:/temp/foo/build/_deps/
> jsoncpp-src"
>                     BINARY_DIR          "C:/temp/foo/build/_deps/
> jsoncpp-build"
>                     CONFIGURE_COMMAND   ""
>                     BUILD_COMMAND       ""
>                     INSTALL_COMMAND     ""
>                     TEST_COMMAND        ""
> )
> *******************************************************
>
> For the external project - the CMAKE_ARGS are no longer a list, but
> individual arguments.
>
> I have tried different things, like escaping the ; with \\; and stuff like
> that, and I can't get it to work.
> I'm thinking there is something obvious I am missing?
>

Assuming jsoncpp doesn't assume it is a top level project (I haven't
checked), the canonical pattern as explained in the docs
<https://cmake.org/cmake/help/latest/module/FetchContent.html#overview>
would be:

FetchContent_Declare(jsoncpp
   URL "c:/project/jsoncpp-src"
)

FetchContent_GetProperties(jsoncpp)

if(NOT jsoncpp_POPULATED)

  FetchContent_Populate(jsoncpp)

  add_subdirectory(${jsoncpp_SOURCE_DIR} ${jsoncpp_BINARY_DIR})

endif()


The reason why FetchContent has all but download steps disabled is the
projects should avoid doing time-consuming things during the configure
stage. A configure stage will be inherently non-parallel as well, so it
hurts you twice. Build steps should be deferred to the build stage as much
as possible. If you find yourself wanting to pull some external project's
build earlier into the configure stage, chances are you really should be
using a superbuild if you truly need a build to be complete before the
configure logic of a different project is executed.

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

From temp1 at andreasen.cc  Fri Jul  6 07:49:56 2018
From: temp1 at andreasen.cc (Mads Andreasen)
Date: Fri, 6 Jul 2018 13:49:56 +0200
Subject: [CMake] CMAKE_ARGS for FetchContent
In-Reply-To: <CA+dygY=3fJv8JQDzLUMF-X7+Obq-B7JbPcZFcZ0=VjxCk=adkA@mail.gmail.com>
References: <CAHbn=FN73G=8zMCka8FzSeCNL=QTfQ6zSzMf8us_yqbvOfA2aw@mail.gmail.com>
 <CA+dygY=3fJv8JQDzLUMF-X7+Obq-B7JbPcZFcZ0=VjxCk=adkA@mail.gmail.com>
Message-ID: <CAHbn=FNooUT31HRY1=FWO_m48hBzBYT6Kag+L6_utAmmAH5BUw@mail.gmail.com>

Hi Craig

Thanks for getting back to me.
I was hoping to be able to build the library with fetch content, so that
the FindXXX would automatically work.

If I use your proposed approach:

if(NOT jsoncpp_POPULATED)

  FetchContent_Populate(jsoncpp)

  add_subdirectory(${jsoncpp_SOURCE_DIR} ${jsoncpp_BINARY_DIR})

endif()


Should I then set the -DJSONCPP_XXX options when running the main cmake
configure?

Best regards,
Mads


On Fri, Jul 6, 2018 at 12:41 PM Craig Scott <craig.scott at crascit.com> wrote:

>
>
> On Fri, Jul 6, 2018 at 8:25 PM, Mads Andreasen <temp1 at andreasen.cc> wrote:
>
>> Hi,
>>
>> I am trying to work with FetchContent in cmake 3.11.
>> I want to use the jsoncpp library and use FetchContent to get and build
>> it.
>>
>
> FetchContent can only download it. You need to build it as a separate step
> (you should avoid building things during the configure phase as much as
> possible). The expected pattern is to add the downloaded contents to your
> existing build via add_subdirectory(). If you want to keep the build
> isolated from your main build, then use ExternalProject directly rather
> than FetchContent.
>
>
>
>>
>> I also want to configure the jsoncpp build with some cmake arguments and
>> I can't seem to get that right.
>>
>> My CMakeLists.txt looks like this:
>> **************************************************************
>> cmake_minimum_required(VERSION 3.11)
>> project(Foo)
>>
>> include(FetchContent)
>>
>> FetchContent_Declare(jsoncpp
>>   URL "c:/project/jsoncpp-src"
>>     CMAKE_ARGS
>> "-DJSONCPP_WITH_CMAKE_PACKAGE=ON;-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
>> )
>>
>> FetchContent_Populate(jsoncpp)
>>
>> add_executable(Foo main.cpp)
>> **************************************************************
>>
>
> The configure, build, test and install steps of ExternalProject do not
> apply to FetchContent, that's why CMAKE_ARGS has no effect.
>
>
>
>
>
>>
>>
>> FetchContent downloads and configures the jsoncpp as an ExternalProject.
>>
>
> No, it only downloads, not configures.
>
>
>
>> That part looks like this:
>> *********************************************
>> ExternalProject_Add(jsoncpp-populate
>>                      "UPDATE_DISCONNECTED" "False" "URL"
>> "c:/project/jsoncpp-src" "CMAKE_ARGS" "-DJSONCPP_WITH_CMAKE_PACKAGE=ON"
>> "-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
>>                     SOURCE_DIR
>> "C:/temp/foo/build/_deps/jsoncpp-src"
>>                     BINARY_DIR
>> "C:/temp/foo/build/_deps/jsoncpp-build"
>>                     CONFIGURE_COMMAND   ""
>>                     BUILD_COMMAND       ""
>>                     INSTALL_COMMAND     ""
>>                     TEST_COMMAND        ""
>> )
>> *******************************************************
>>
>> For the external project - the CMAKE_ARGS are no longer a list, but
>> individual arguments.
>>
>> I have tried different things, like escaping the ; with \\; and stuff
>> like that, and I can't get it to work.
>> I'm thinking there is something obvious I am missing?
>>
>
> Assuming jsoncpp doesn't assume it is a top level project (I haven't
> checked), the canonical pattern as explained in the docs
> <https://cmake.org/cmake/help/latest/module/FetchContent.html#overview>
> would be:
>
> FetchContent_Declare(jsoncpp
>    URL "c:/project/jsoncpp-src"
> )
>
> FetchContent_GetProperties(jsoncpp)
>
> if(NOT jsoncpp_POPULATED)
>
>   FetchContent_Populate(jsoncpp)
>
>   add_subdirectory(${jsoncpp_SOURCE_DIR} ${jsoncpp_BINARY_DIR})
>
> endif()
>
>
> The reason why FetchContent has all but download steps disabled is the
> projects should avoid doing time-consuming things during the configure
> stage. A configure stage will be inherently non-parallel as well, so it
> hurts you twice. Build steps should be deferred to the build stage as much
> as possible. If you find yourself wanting to pull some external project's
> build earlier into the configure stage, chances are you really should be
> using a superbuild if you truly need a build to be complete before the
> configure logic of a different project is executed.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180706/d3f4ec29/attachment.html>

From craig.scott at crascit.com  Fri Jul  6 07:53:03 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 6 Jul 2018 21:53:03 +1000
Subject: [CMake] CMAKE_ARGS for FetchContent
In-Reply-To: <CAHbn=FNooUT31HRY1=FWO_m48hBzBYT6Kag+L6_utAmmAH5BUw@mail.gmail.com>
References: <CAHbn=FN73G=8zMCka8FzSeCNL=QTfQ6zSzMf8us_yqbvOfA2aw@mail.gmail.com>
 <CA+dygY=3fJv8JQDzLUMF-X7+Obq-B7JbPcZFcZ0=VjxCk=adkA@mail.gmail.com>
 <CAHbn=FNooUT31HRY1=FWO_m48hBzBYT6Kag+L6_utAmmAH5BUw@mail.gmail.com>
Message-ID: <CA+dygYk6D-EMLJkjCKSMiG82BCqGAkZ5Hfhtm-aCKmFwq_zBOA@mail.gmail.com>

On Fri, Jul 6, 2018 at 9:49 PM, Mads Andreasen <temp1 at andreasen.cc> wrote:

> Hi Craig
>
> Thanks for getting back to me.
> I was hoping to be able to build the library with fetch content, so that
> the FindXXX would automatically work.
>

If you want to use FindXXX, you need to use ExternalProject and a
superbuild structure. The things that FindXXX modules look for don't exist
until after they have been built. It sounds like a superbuild is really
what you should be doing here.

If you choose to incorporate jsoncpp via add_subdirectory() instead, then
instead of using FindXXX modules you can refer directly to the CMake target
names that jsoncpp defines. This is one of the main reasons for
FetchContent and using add_subdirectory(), since you can directly refer to
things that CMake knows about instead of having to find anything.




>
> If I use your proposed approach:
>
> if(NOT jsoncpp_POPULATED)
>
>   FetchContent_Populate(jsoncpp)
>
>   add_subdirectory(${jsoncpp_SOURCE_DIR} ${jsoncpp_BINARY_DIR})
>
> endif()
>
>
> Should I then set the -DJSONCPP_XXX options when running the main cmake
> configure?
>
> Best regards,
> Mads
>
>
> On Fri, Jul 6, 2018 at 12:41 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
>>
>>
>> On Fri, Jul 6, 2018 at 8:25 PM, Mads Andreasen <temp1 at andreasen.cc>
>> wrote:
>>
>>> Hi,
>>>
>>> I am trying to work with FetchContent in cmake 3.11.
>>> I want to use the jsoncpp library and use FetchContent to get and build
>>> it.
>>>
>>
>> FetchContent can only download it. You need to build it as a separate
>> step (you should avoid building things during the configure phase as much
>> as possible). The expected pattern is to add the downloaded contents to
>> your existing build via add_subdirectory(). If you want to keep the build
>> isolated from your main build, then use ExternalProject directly rather
>> than FetchContent.
>>
>>
>>
>>>
>>> I also want to configure the jsoncpp build with some cmake arguments and
>>> I can't seem to get that right.
>>>
>>> My CMakeLists.txt looks like this:
>>> **************************************************************
>>> cmake_minimum_required(VERSION 3.11)
>>> project(Foo)
>>>
>>> include(FetchContent)
>>>
>>> FetchContent_Declare(jsoncpp
>>>   URL "c:/project/jsoncpp-src"
>>>     CMAKE_ARGS "-DJSONCPP_WITH_CMAKE_PACKAGE=
>>> ON;-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
>>> )
>>>
>>> FetchContent_Populate(jsoncpp)
>>>
>>> add_executable(Foo main.cpp)
>>> **************************************************************
>>>
>>
>> The configure, build, test and install steps of ExternalProject do not
>> apply to FetchContent, that's why CMAKE_ARGS has no effect.
>>
>>
>>
>>
>>
>>>
>>>
>>> FetchContent downloads and configures the jsoncpp as an ExternalProject.
>>>
>>
>> No, it only downloads, not configures.
>>
>>
>>
>>> That part looks like this:
>>> *********************************************
>>> ExternalProject_Add(jsoncpp-populate
>>>                      "UPDATE_DISCONNECTED" "False" "URL"
>>> "c:/project/jsoncpp-src" "CMAKE_ARGS" "-DJSONCPP_WITH_CMAKE_PACKAGE=ON"
>>> "-DJSONCPP_WITH_PKGCONFIG_SUPPORT=OFF"
>>>                     SOURCE_DIR          "C:/temp/foo/build/_deps/
>>> jsoncpp-src"
>>>                     BINARY_DIR          "C:/temp/foo/build/_deps/
>>> jsoncpp-build"
>>>                     CONFIGURE_COMMAND   ""
>>>                     BUILD_COMMAND       ""
>>>                     INSTALL_COMMAND     ""
>>>                     TEST_COMMAND        ""
>>> )
>>> *******************************************************
>>>
>>> For the external project - the CMAKE_ARGS are no longer a list, but
>>> individual arguments.
>>>
>>> I have tried different things, like escaping the ; with \\; and stuff
>>> like that, and I can't get it to work.
>>> I'm thinking there is something obvious I am missing?
>>>
>>
>> Assuming jsoncpp doesn't assume it is a top level project (I haven't
>> checked), the canonical pattern as explained in the docs
>> <https://cmake.org/cmake/help/latest/module/FetchContent.html#overview>
>> would be:
>>
>> FetchContent_Declare(jsoncpp
>>    URL "c:/project/jsoncpp-src"
>> )
>>
>> FetchContent_GetProperties(jsoncpp)
>>
>> if(NOT jsoncpp_POPULATED)
>>
>>   FetchContent_Populate(jsoncpp)
>>
>>   add_subdirectory(${jsoncpp_SOURCE_DIR} ${jsoncpp_BINARY_DIR})
>>
>> endif()
>>
>>
>> The reason why FetchContent has all but download steps disabled is the
>> projects should avoid doing time-consuming things during the configure
>> stage. A configure stage will be inherently non-parallel as well, so it
>> hurts you twice. Build steps should be deferred to the build stage as much
>> as possible. If you find yourself wanting to pull some external project's
>> build earlier into the configure stage, chances are you really should be
>> using a superbuild if you truly need a build to be complete before the
>> configure logic of a different project is executed.
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>


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

From robert.maynard at kitware.com  Fri Jul  6 08:38:15 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 6 Jul 2018 08:38:15 -0400
Subject: [CMake] Using CMake to link C++ and CUDA Object file
In-Reply-To: <CAGfE9+OPGQ5GyOUyd_i6WdXDeq17FYt9gnuRGcoNQOE4-FaCVw@mail.gmail.com>
References: <CAGfE9+OPGQ5GyOUyd_i6WdXDeq17FYt9gnuRGcoNQOE4-FaCVw@mail.gmail.com>
Message-ID: <CAFzjYVqwQBo-R4wMzHgZmPHrOkFabsaX0pAh=6Sh=_Br5xhuLw@mail.gmail.com>

if you are using the new first class cuda language, as seen by `project(MyTest
LANGUAGES CXX CUDA)` you shouldn't use the old find cuda package or the
associated cuda_add_library calls. When using the first class cuda language
simply use add_library.

The other difference I notice is that you makefile example is not building
shared libraries but object files, so to the same in CMake you need to use
'add_library' with the OBJECT keyword not the SHARED keyword.



On Fri, Jul 6, 2018 at 12:01 AM Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> Hi all,
>
> Following upon how to perform code linking between CUDA and C++ (here at
> https://devblogs.nvidia.com/separate-compilation-linking-cuda-device-code/),
> I have successfully come up with a Makefile that is currently working for
> my test case:
>
> ##################################Makefile###############
> ##################################
> main_objects = main.o
> host_objects = host.o
> device_objects = device.o
>
> all: $(main_objects) $(host_objects) $(device_objects)
>         g++ -O3 -fopenmp $(main_objects) $(host_objects) $(device_objects)
> -L/usr/local/cuda/lib64 -lcudart -o main
>
> $(main_objects): $(main_objects:.o=.cpp)
>         g++ -O3 -I/usr/local/cuda/include -c $< -o $@
>
> $(host_objects): $(host_objects:.o=.cpp)
>         g++ -O3 -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -fopenmp -c $<
> -o $@
>
> $(device_objects): $(device_objects:.o=.cu)
>         nvcc -O3 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -c $< -o
> $@
>
> clean:
>         rm -f *.o main
> ####################################################################
> ##################################
>
> Now, I am trying to write a CMake for this, my current attempt is as
> followed:
>
>
> ##############################################CMakeLists.txt############################################
> cmake_minimum_required(VERSION 3.8)
> project(MyTest LANGUAGES CXX CUDA)
>
> # check requirements
> find_package(CUDA REQUIRED)
> find_package(OpenMP)
>
> if (CUDA_FOUND AND OPENMP_FOUND)
>     # OpenMP
>     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
>     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
>     set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
> ${OpenMP_EXE_LINKER_FLAGS}")
>
>     # CUDA
>     include_directories(${CUDA_INCLUDE_DIRS})
>     set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
> ${CUDA_cublas_LIBRARY})
>     set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
>     set(CUDA_SEPARABLE_COMPILATION OFF)
>     set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
>
>     set(OMP_SOURCES host.cpp)
>     add_library(Host_OMP SHARED ${OMP_SOURCES})
>     set_target_properties(Host_OMP PROPERTIES COMPILE_FLAGS
> "-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP")
>     set(LIBS ${LIBS} ${Host_OMP})
>
>     set(CUDA_SOURCES device.cu)
>     cuda_add_library(Device_CUDA SHARED ${CUDA_SOURCES})
>     set_target_properties(Device_CUDA PROPERTIES COMPILE_FLAGS
> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
>     set_target_properties(Device_CUDA PROPERTIES
> CUDA_SEPERABLE_COMPILATION ON)
>     set(LIBS ${LIBS} ${Device_CUDA})
>
>     add_executable(main main.cpp)
>     target_link_libraries(main ${LIBS})
>
> endif(CUDA_FOUND AND OPENMP_FOUND)
> ####################################################################
> ##################################
>
> It is still, unfortunately, not working. If I commented out the
> add_executable line, the object code for Host_OMP and Device_CUDA is
> compiled. I can then use the terminal and link them with main.cpp using gcc
> and generate the executable - i.e. using the final command in the Makefile
> above.
>
> What am I doing wrong here? It seems to be very fundamental, but I can't
> seem to get it right...
>
> Any suggestions would be greatly appreciated!!
>
> 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/20180706/33eb8da5/attachment.html>

From quang.t.ha.20 at gmail.com  Fri Jul  6 11:29:55 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Fri, 6 Jul 2018 09:29:55 -0600
Subject: [CMake] Using CMake to link C++ and CUDA Object file
In-Reply-To: <CAFzjYVqwQBo-R4wMzHgZmPHrOkFabsaX0pAh=6Sh=_Br5xhuLw@mail.gmail.com>
References: <CAGfE9+OPGQ5GyOUyd_i6WdXDeq17FYt9gnuRGcoNQOE4-FaCVw@mail.gmail.com>
 <CAFzjYVqwQBo-R4wMzHgZmPHrOkFabsaX0pAh=6Sh=_Br5xhuLw@mail.gmail.com>
Message-ID: <CAGfE9+PWrSZAhjzqpdzTRS8QPEOeZCwGFSrikvZHmUU0sy9OJA@mail.gmail.com>

Thanks for your response, Robert. If I don't use find_package(CUDA), I run
into the following problem:

 fatal error: thrust/host_vector.h: No such file or directory

I guess this is needed if I am using Thrust/CUDA?

Thanks,
Quang

On Fri, 6 Jul 2018 at 06:38, Robert Maynard <robert.maynard at kitware.com>
wrote:

> if you are using the new first class cuda language, as seen by `project(MyTest
> LANGUAGES CXX CUDA)` you shouldn't use the old find cuda package or the
> associated cuda_add_library calls. When using the first class cuda
> language simply use add_library.
>
> The other difference I notice is that you makefile example is not building
> shared libraries but object files, so to the same in CMake you need to use
> 'add_library' with the OBJECT keyword not the SHARED keyword.
>
>
>
> On Fri, Jul 6, 2018 at 12:01 AM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>
>> Hi all,
>>
>> Following upon how to perform code linking between CUDA and C++ (here at
>> https://devblogs.nvidia.com/separate-compilation-linking-cuda-device-code/),
>> I have successfully come up with a Makefile that is currently working for
>> my test case:
>>
>> ##################################Makefile###############
>> ##################################
>> main_objects = main.o
>> host_objects = host.o
>> device_objects = device.o
>>
>> all: $(main_objects) $(host_objects) $(device_objects)
>>         g++ -O3 -fopenmp $(main_objects) $(host_objects)
>> $(device_objects) -L/usr/local/cuda/lib64 -lcudart -o main
>>
>> $(main_objects): $(main_objects:.o=.cpp)
>>         g++ -O3 -I/usr/local/cuda/include -c $< -o $@
>>
>> $(host_objects): $(host_objects:.o=.cpp)
>>         g++ -O3 -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -fopenmp -c
>> $< -o $@
>>
>> $(device_objects): $(device_objects:.o=.cu)
>>         nvcc -O3 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -c $<
>> -o $@
>>
>> clean:
>>         rm -f *.o main
>> ####################################################################
>> ##################################
>>
>> Now, I am trying to write a CMake for this, my current attempt is as
>> followed:
>>
>>
>> ##############################################CMakeLists.txt############################################
>> cmake_minimum_required(VERSION 3.8)
>> project(MyTest LANGUAGES CXX CUDA)
>>
>> # check requirements
>> find_package(CUDA REQUIRED)
>> find_package(OpenMP)
>>
>> if (CUDA_FOUND AND OPENMP_FOUND)
>>     # OpenMP
>>     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
>>     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
>>     set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
>> ${OpenMP_EXE_LINKER_FLAGS}")
>>
>>     # CUDA
>>     include_directories(${CUDA_INCLUDE_DIRS})
>>     set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
>> ${CUDA_cublas_LIBRARY})
>>     set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
>>     set(CUDA_SEPARABLE_COMPILATION OFF)
>>     set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
>>
>>     set(OMP_SOURCES host.cpp)
>>     add_library(Host_OMP SHARED ${OMP_SOURCES})
>>     set_target_properties(Host_OMP PROPERTIES COMPILE_FLAGS
>> "-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP")
>>     set(LIBS ${LIBS} ${Host_OMP})
>>
>>     set(CUDA_SOURCES device.cu)
>>     cuda_add_library(Device_CUDA SHARED ${CUDA_SOURCES})
>>     set_target_properties(Device_CUDA PROPERTIES COMPILE_FLAGS
>> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
>>     set_target_properties(Device_CUDA PROPERTIES
>> CUDA_SEPERABLE_COMPILATION ON)
>>     set(LIBS ${LIBS} ${Device_CUDA})
>>
>>     add_executable(main main.cpp)
>>     target_link_libraries(main ${LIBS})
>>
>> endif(CUDA_FOUND AND OPENMP_FOUND)
>> ####################################################################
>> ##################################
>>
>> It is still, unfortunately, not working. If I commented out the
>> add_executable line, the object code for Host_OMP and Device_CUDA is
>> compiled. I can then use the terminal and link them with main.cpp using gcc
>> and generate the executable - i.e. using the final command in the Makefile
>> above.
>>
>> What am I doing wrong here? It seems to be very fundamental, but I can't
>> seem to get it right...
>>
>> Any suggestions would be greatly appreciated!!
>>
>> 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/20180706/1091543c/attachment-0001.html>

From robert.maynard at kitware.com  Fri Jul  6 11:40:24 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 6 Jul 2018 11:40:24 -0400
Subject: [CMake] Using CMake to link C++ and CUDA Object file
In-Reply-To: <CAGfE9+PWrSZAhjzqpdzTRS8QPEOeZCwGFSrikvZHmUU0sy9OJA@mail.gmail.com>
References: <CAGfE9+OPGQ5GyOUyd_i6WdXDeq17FYt9gnuRGcoNQOE4-FaCVw@mail.gmail.com>
 <CAFzjYVqwQBo-R4wMzHgZmPHrOkFabsaX0pAh=6Sh=_Br5xhuLw@mail.gmail.com>
 <CAGfE9+PWrSZAhjzqpdzTRS8QPEOeZCwGFSrikvZHmUU0sy9OJA@mail.gmail.com>
Message-ID: <CAFzjYVqB2jLAASPpG_9x_4Uwdz7JdENMLh6koE7Lcf+Y-2bzYQ@mail.gmail.com>

To be clear the FindCUDA module currently does two things it finds the
location of the CUDA SDK and it also adds the 'cuda_' commands.

In your case you might still need to use FindCUDA to find the location of
the thrust include directory, or you can find the location yourself by
using find_path like:

```
find_path(CUDA_TOOLKIT_INCLUDE
  device_functions.h # Header included in toolkit
  PATHS ${CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES}
  PATH_SUFFIXES include ../include
  NO_DEFAULT_PATH
  )
```


On Fri, Jul 6, 2018 at 11:30 AM Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> Thanks for your response, Robert. If I don't use find_package(CUDA), I run
> into the following problem:
>
>  fatal error: thrust/host_vector.h: No such file or directory
>
> I guess this is needed if I am using Thrust/CUDA?
>
> Thanks,
> Quang
>
> On Fri, 6 Jul 2018 at 06:38, Robert Maynard <robert.maynard at kitware.com>
> wrote:
>
>> if you are using the new first class cuda language, as seen by `project(MyTest
>> LANGUAGES CXX CUDA)` you shouldn't use the old find cuda package or the
>> associated cuda_add_library calls. When using the first class cuda
>> language simply use add_library.
>>
>> The other difference I notice is that you makefile example is not
>> building shared libraries but object files, so to the same in CMake you
>> need to use 'add_library' with the OBJECT keyword not the SHARED keyword.
>>
>>
>>
>> On Fri, Jul 6, 2018 at 12:01 AM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Following upon how to perform code linking between CUDA and C++ (here at
>>> https://devblogs.nvidia.com/separate-compilation-linking-cuda-device-code/),
>>> I have successfully come up with a Makefile that is currently working for
>>> my test case:
>>>
>>> ##################################Makefile###############
>>> ##################################
>>> main_objects = main.o
>>> host_objects = host.o
>>> device_objects = device.o
>>>
>>> all: $(main_objects) $(host_objects) $(device_objects)
>>>         g++ -O3 -fopenmp $(main_objects) $(host_objects)
>>> $(device_objects) -L/usr/local/cuda/lib64 -lcudart -o main
>>>
>>> $(main_objects): $(main_objects:.o=.cpp)
>>>         g++ -O3 -I/usr/local/cuda/include -c $< -o $@
>>>
>>> $(host_objects): $(host_objects:.o=.cpp)
>>>         g++ -O3 -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -fopenmp -c
>>> $< -o $@
>>>
>>> $(device_objects): $(device_objects:.o=.cu)
>>>         nvcc -O3 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -c $<
>>> -o $@
>>>
>>> clean:
>>>         rm -f *.o main
>>> ####################################################################
>>> ##################################
>>>
>>> Now, I am trying to write a CMake for this, my current attempt is as
>>> followed:
>>>
>>>
>>> ##############################################CMakeLists.txt############################################
>>> cmake_minimum_required(VERSION 3.8)
>>> project(MyTest LANGUAGES CXX CUDA)
>>>
>>> # check requirements
>>> find_package(CUDA REQUIRED)
>>> find_package(OpenMP)
>>>
>>> if (CUDA_FOUND AND OPENMP_FOUND)
>>>     # OpenMP
>>>     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
>>>     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
>>>     set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
>>> ${OpenMP_EXE_LINKER_FLAGS}")
>>>
>>>     # CUDA
>>>     include_directories(${CUDA_INCLUDE_DIRS})
>>>     set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
>>> ${CUDA_cublas_LIBRARY})
>>>     set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
>>>     set(CUDA_SEPARABLE_COMPILATION OFF)
>>>     set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
>>>
>>>     set(OMP_SOURCES host.cpp)
>>>     add_library(Host_OMP SHARED ${OMP_SOURCES})
>>>     set_target_properties(Host_OMP PROPERTIES COMPILE_FLAGS
>>> "-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP")
>>>     set(LIBS ${LIBS} ${Host_OMP})
>>>
>>>     set(CUDA_SOURCES device.cu)
>>>     cuda_add_library(Device_CUDA SHARED ${CUDA_SOURCES})
>>>     set_target_properties(Device_CUDA PROPERTIES COMPILE_FLAGS
>>> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
>>>     set_target_properties(Device_CUDA PROPERTIES
>>> CUDA_SEPERABLE_COMPILATION ON)
>>>     set(LIBS ${LIBS} ${Device_CUDA})
>>>
>>>     add_executable(main main.cpp)
>>>     target_link_libraries(main ${LIBS})
>>>
>>> endif(CUDA_FOUND AND OPENMP_FOUND)
>>> ####################################################################
>>> ##################################
>>>
>>> It is still, unfortunately, not working. If I commented out the
>>> add_executable line, the object code for Host_OMP and Device_CUDA is
>>> compiled. I can then use the terminal and link them with main.cpp using gcc
>>> and generate the executable - i.e. using the final command in the Makefile
>>> above.
>>>
>>> What am I doing wrong here? It seems to be very fundamental, but I can't
>>> seem to get it right...
>>>
>>> Any suggestions would be greatly appreciated!!
>>>
>>> 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/20180706/531fd1f4/attachment.html>

From thomas.l.clune at nasa.gov  Fri Jul  6 16:34:04 2018
From: thomas.l.clune at nasa.gov (Clune, Thomas L. (GSFC-6101))
Date: Fri, 6 Jul 2018 20:34:04 +0000
Subject: [CMake] specifying path for license file for commercial compiler?
Message-ID: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>

To use the Intel compiler, one must use an environment variable that specifies the path to the license file.  E.g.,

    export INTEL_LICENSE_FILE=/usr/local/intel/license

Other commercial compilers use a very similar mechanism.    I had hoped to capture such information in a cache file so that I could avoid polluting the shell where I am invoking cmake:

    % cmake -C my-cache <src-dir>

Such a cache file could  look like:

    set(CMAKE_Fortran_COMPILER "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" CACHE path "Fortran compiler")
    set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel license")


Unfortunately, the compiler is not ?seeing? the env variable and complains that there is no license.     Is there a solution to this, or am I forced to set the env variable each time I try to build?








From marc.chevrier at gmail.com  Sat Jul  7 01:49:25 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Sat, 7 Jul 2018 07:49:25 +0200
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
Message-ID: <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>

May be using a toolchain file is more appropriate. See
https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html


Le ven. 6 juil. 2018 ? 22:59, Clune, Thomas L. (GSFC-6101) <
thomas.l.clune at nasa.gov> a ?crit :

> To use the Intel compiler, one must use an environment variable that
> specifies the path to the license file.  E.g.,
>
>     export INTEL_LICENSE_FILE=/usr/local/intel/license
>
> Other commercial compilers use a very similar mechanism.    I had hoped to
> capture such information in a cache file so that I could avoid polluting
> the shell where I am invoking cmake:
>
>     % cmake -C my-cache <src-dir>
>
> Such a cache file could  look like:
>
>     set(CMAKE_Fortran_COMPILER
> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
> CACHE path "Fortran compiler")
>     set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
> "Intel license")
>
>
> Unfortunately, the compiler is not ?seeing? the env variable and complains
> that there is no license.     Is there a solution to this, or am I forced
> to set the env variable each time I try to build?
>
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180707/27b30451/attachment.html>

From sjm324 at cornell.edu  Sat Jul  7 02:25:39 2018
From: sjm324 at cornell.edu (Stephen McDowell)
Date: Fri, 6 Jul 2018 23:25:39 -0700
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
Message-ID: <CAJGuVd_4jOH2y-4XWj8FigxdXcN9xEVCqZmokNL8V4jCNRDiEA@mail.gmail.com>

I agree that a toolchain file is more appropriate, noting that typically
modifying the environment variables is much more common for there's
compilers (particularly using environment modules).

However, since you've started clearly you would rather not set the
environment variables, there may be an easier "hack".

Intel also looks in /opt/intel/licenses for any .lic files. So if you want,
you can just create a symbolic link or copy your license file there :)

On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER <marc.chevrier at gmail.com> wrote:

> May be using a toolchain file is more appropriate. See
> https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
>
>
> Le ven. 6 juil. 2018 ? 22:59, Clune, Thomas L. (GSFC-6101) <
> thomas.l.clune at nasa.gov> a ?crit :
>
>> To use the Intel compiler, one must use an environment variable that
>> specifies the path to the license file.  E.g.,
>>
>>     export INTEL_LICENSE_FILE=/usr/local/intel/license
>>
>> Other commercial compilers use a very similar mechanism.    I had hoped
>> to capture such information in a cache file so that I could avoid polluting
>> the shell where I am invoking cmake:
>>
>>     % cmake -C my-cache <src-dir>
>>
>> Such a cache file could  look like:
>>
>>     set(CMAKE_Fortran_COMPILER
>> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
>> CACHE path "Fortran compiler")
>>     set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
>> "Intel license")
>>
>>
>> Unfortunately, the compiler is not ?seeing? the env variable and
>> complains that there is no license.     Is there a solution to this, or am
>> I forced to set the env variable each time I try to build?
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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/20180706/6807746b/attachment.html>

From fifteenknots505 at gmail.com  Sat Jul  7 13:09:18 2018
From: fifteenknots505 at gmail.com (Martin Weber)
Date: Sat, 07 Jul 2018 19:09:18 +0200
Subject: [CMake] Eclipse CDT4 - Unix Makefiles / Ninja Generator
Message-ID: <3040101.FW4RXYlS4o@linux>

Hi all,

FYI, according to this [1], those generators do no longer work with the new 
core build introduced in CDT 9.5.

Martin

[1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg33066.html

-- 
Cd wrttn wtht vwls s mch trsr.



From Alan.W.Irwin1234 at gmail.com  Sun Jul  8 16:51:54 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Sun, 8 Jul 2018 13:51:54 -0700 (PDT)
Subject: [CMake] groups of ascii nul ('\0) characters inserted into make
 output but this just occurs for parallel builds
Message-ID: <nycvar.QRO.7.76.1807081302570.9795@zreyva.zlyna.ubzr>

My parallel builds on my Linux OS (currently Debian Buster, but this
also happened for Debian Jessie so this is a long-standing problem)
have ascii null ('\0) characters inserted in the output while the
corresponding non-parallel build does not have those extra characters.
For example, for the PLplot case and proceeding from a clean start
by configuring PLplot in an initially empty build tree:

software at merlin> make -j16 test_noninteractive >& test_noninteractive.out
software at merlin> od -c test_noninteractive.out |grep '\\0'
0713660   g   r   a   d   i   e   n   t   .  \n  \n  \0  \0  \0  \0  \0
0713700  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0717000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0717540  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   O   u   t
0722160   1   4   f   .   f   9   0   .   o  \n  \0  \0  \0  \0  \0  \0
0722200  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0722740  \0  \0  \0  \0  \0  \0  \0   O   u   t   p   u   t       f   i

Note the test_noninteractive target has been configured by the PLplot
build system to build all non-interactive test command prerequisties
and then runs those test commands.  (Note, these test commands are
just executables that I build and are not formal CMake test commands
that, for example, are run by ctest.)  Also note those '\0' characters
occur in groups, and there are three such groups in the output, but
because parallel builds mix target outputs together it is impossible
to tell which target is generating the '\0' characters.  And if I drop
the parallel build (-j16) option, the issue goes away.

Note, there is a chance this is an operating system problem rather
than a CMake problem.  For example, my shell (bash) might not properly
handle the case where many different applications are simultaneously
outputting to stdout.  But if so, it is a difficult issue to
replicate.  For example, I implemented a simple Makefile where the all
target had 10 different prerequisites, and each of those prerequisites
used the the cat command to output the UTF-8 contents of the same file
where the file was long enough (in this case ~10000 characters) so the
different outputs were mixed together for the parallel build case.
But that test failed to replicate the issue because the parallel and
non-parallel builds produced output with the same number of characters
(which was 10 times the number of characters in the file), and further
evaluation using "od -c" showed no instances of "\0" in either the
parallel or non-parallel output.

So two questions for those who are lurking here:

1. Have you ever experienced this problem when building a target with
large numbers of prerequisites in parallel with CMake, and if so, what
was the fix?

2. It is possible (although I cannot imagine how the symptoms would
just be limited to emission of extra '\0' characters) this issue could
be the symptom of a parallel build race condition for the PLplot build
system.  To help eliminate or confirm this possibility what is the most
fool-proof method to diagnose whether such a race exists?

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From neundorf at kde.org  Sun Jul  8 17:17:27 2018
From: neundorf at kde.org (Alexander Neundorf)
Date: Sun, 08 Jul 2018 23:17:27 +0200
Subject: [CMake] Eclipse CDT4 - Unix Makefiles / Ninja Generator
In-Reply-To: <3040101.FW4RXYlS4o@linux>
References: <3040101.FW4RXYlS4o@linux>
Message-ID: <5554997.4vZYSjESvk@linux-l7nd>

On 2018 M07 7, Sat 19:09:18 CEST Martin Weber wrote:
> Hi all,
> 
> FYI, according to this [1], those generators do no longer work with the new
> core build introduced in CDT 9.5.
> 
> Martin
> 
> [1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg33066.html

do you know whether the new build system of CDT is documented somewhere ?
I found this, but this is far from enough.
http://www.eclipse.org/org/langsymp/CDT%20Managed%20Build%20System.pdf

Alex


From nuquaquaraqua at gmail.com  Sun Jul  8 17:34:40 2018
From: nuquaquaraqua at gmail.com (=?UTF-8?Q?Quaquaraqu=c3=a0?=)
Date: Sun, 8 Jul 2018 23:34:40 +0200
Subject: [CMake] find_package: keyword REQUIRED ignored
Message-ID: <005b95d8-0cc0-89f2-4222-0150984ea181@gmail.com>

Hi there,

I'm using a custom script [1] to look for the library sqlite3. However, 
the keyword "REQUIRED" (as quietly) is ignored by find_package. That is 
even if the library is not found, the script continues is processing:

// CMakeLists.txt

cmake_minimum_required(VERSION 3.10)project(hello_world)list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build-aux/")
find_package(SQLite3 REQUIRED)

// output:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang 
-DCMAKE_CXX_COMPILER=clang++ -G "CodeBlocks - Unix Makefiles" ../
-- Could NOT find SQLITE3 (missing: SQLITE3_LIBRARY)
-- Configuring done
-- Generating done
-- Build files have been written to: ...


Any idea what is wrong here?


[1] 
https://github.com/LuaDist/libsqlite3/blob/master/cmake/FindSQLite3.cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180708/6fe845f7/attachment.html>

From thomas.l.clune at nasa.gov  Sun Jul  8 21:32:44 2018
From: thomas.l.clune at nasa.gov (Clune, Thomas L. (GSFC-6101))
Date: Mon, 9 Jul 2018 01:32:44 +0000
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
Message-ID: <C0779532-5F9F-410A-840C-2C86AF5CF3C5@nasa.gov>

Marc,

Thank you for the suggestion.  Unfortunately, I?m a bit confused by the documentation and not at all sure how to proceed.   Further help would be appreciated.

In particular, I do not see how to capture the existing Fortran, C and CXX toolchains and then provide the minor extension of setting this one environment variable.   In fact, at the moment, I don?t even see a simple way to cut-and-paste the cmake built-in toolchains into a file to use as my baseline for extension.

Am I correct in assuming that once the above issues are solved, then a simple line of the form

set(ENV(INTEL_LICENSE_FILE) ???)

will then ensure that the compiler ?sees? that env variable?   Or do I need to wrap the compiler in a script which just raises many more issues as I need my project to be able to build with many different versions of the  Intel compiler.

Thanks in advance,


  *   Tom



From: Marc CHEVRIER <marc.chevrier at gmail.com>
Date: Saturday, July 7, 2018 at 1:49 AM
To: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>
Cc: CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] specifying path for license file for commercial compiler?

May be using a toolchain file is more appropriate. See
https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html


Le ven. 6 juil. 2018 ? 22:59, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov<mailto:thomas.l.clune at nasa.gov>> a ?crit :
To use the Intel compiler, one must use an environment variable that specifies the path to the license file.  E.g.,

    export INTEL_LICENSE_FILE=/usr/local/intel/license

Other commercial compilers use a very similar mechanism.    I had hoped to capture such information in a cache file so that I could avoid polluting the shell where I am invoking cmake:

    % cmake -C my-cache <src-dir>

Such a cache file could  look like:

    set(CMAKE_Fortran_COMPILER "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" CACHE path "Fortran compiler")
    set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel license")


Unfortunately, the compiler is not ?seeing? the env variable and complains that there is no license.     Is there a solution to this, or am I forced to set the env variable each time I try to build?







--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/66de3798/attachment-0001.html>

From thomas.l.clune at nasa.gov  Sun Jul  8 21:41:17 2018
From: thomas.l.clune at nasa.gov (Clune, Thomas L. (GSFC-6101))
Date: Mon, 9 Jul 2018 01:41:17 +0000
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <CAJGuVd_4jOH2y-4XWj8FigxdXcN9xEVCqZmokNL8V4jCNRDiEA@mail.gmail.com>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
 <CAJGuVd_4jOH2y-4XWj8FigxdXcN9xEVCqZmokNL8V4jCNRDiEA@mail.gmail.com>
Message-ID: <83F77C62-1027-4A48-9425-A2B0660B0CC1@nasa.gov>

Unfortunately, I cannot dictate where the sysadmins are putting the license file.     I can of course put a copy in  /home/<user>/Licenses which is another location that Intel looks by default.   And if there is no better solution, I will provide instructions to all of our developers on making copies themselves on our various development platforms.    Or at that point I?ll just ask them all to set the environment variable in their shell startup files.

I?m still a bit astonished that something as simple as this is essentially unsupported.    It is particularly frustrating as try_run() successfully exercises the compiler while the run-of-the-mill compiler invocations under make do not.   Sort of makes sense though.  CMake launches try_run() in a subshell and therefore it sees the env variable I am setting with set(ENV?).   OTOH, the subsequent make commands are not subshells and therefore need a separate mechanism to see that env variable.


From: Stephen McDowell <sjm324 at cornell.edu>
Date: Saturday, July 7, 2018 at 2:25 AM
To: Marc CHEVRIER <marc.chevrier at gmail.com>
Cc: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>, CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] specifying path for license file for commercial compiler?

I agree that a toolchain file is more appropriate, noting that typically modifying the environment variables is much more common for there's compilers (particularly using environment modules).

However, since you've started clearly you would rather not set the environment variables, there may be an easier "hack".

Intel also looks in /opt/intel/licenses for any .lic files. So if you want, you can just create a symbolic link or copy your license file there :)

On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER <marc.chevrier at gmail.com<mailto:marc.chevrier at gmail.com>> wrote:
May be using a toolchain file is more appropriate. See
https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html


Le ven. 6 juil. 2018 ? 22:59, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov<mailto:thomas.l.clune at nasa.gov>> a ?crit :
To use the Intel compiler, one must use an environment variable that specifies the path to the license file.  E.g.,

    export INTEL_LICENSE_FILE=/usr/local/intel/license

Other commercial compilers use a very similar mechanism.    I had hoped to capture such information in a cache file so that I could avoid polluting the shell where I am invoking cmake:

    % cmake -C my-cache <src-dir>

Such a cache file could  look like:

    set(CMAKE_Fortran_COMPILER "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" CACHE path "Fortran compiler")
    set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel license")


Unfortunately, the compiler is not ?seeing? the env variable and complains that there is no license.     Is there a solution to this, or am I forced to set the env variable each time I try to build?







--

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/8d3ef3d0/attachment.html>

From juan.e.sanchez at gmail.com  Sun Jul  8 22:32:04 2018
From: juan.e.sanchez at gmail.com (Juan E. Sanchez)
Date: Sun, 8 Jul 2018 21:32:04 -0500
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <83F77C62-1027-4A48-9425-A2B0660B0CC1@nasa.gov>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
 <CAJGuVd_4jOH2y-4XWj8FigxdXcN9xEVCqZmokNL8V4jCNRDiEA@mail.gmail.com>
 <83F77C62-1027-4A48-9425-A2B0660B0CC1@nasa.gov>
Message-ID: <3d4e2fcf-f981-5131-4925-9cd3148a59a9@gmail.com>

Hi,

Could you create a simple compiler wrapper script, and point the 
CMAKE_*_COMPILER variables there:

#!/bin/bash
export INTEL_LICENSE_FILE=/usr/local/intel/license
/path/to/ifort "$@"

Regards,

Juan


On 7/8/18 8:41 PM, Clune, Thomas L. (GSFC-6101) wrote:
> Unfortunately, I cannot dictate where the sysadmins are putting the 
> license file.???? I can of course put a copy in ?/home/<user>/Licenses 
> which is another location that Intel looks by default.?? And if there is 
> no better solution, I will provide instructions to all of our developers 
> on making copies themselves on our various development platforms.??? Or 
> at that point I?ll just ask them all to set the environment variable in 
> their shell startup files.
> 
> I?m still a bit astonished that something as simple as this is 
> essentially unsupported.??? It is particularly frustrating as try_run() 
> successfully exercises the compiler while the run-of-the-mill compiler 
> invocations under make do not. Sort of makes sense though.? CMake 
> launches try_run() in a subshell and therefore it sees the env variable 
> I am setting with set(ENV?).?? OTOH, the subsequent make commands are 
> not subshells and therefore need a separate mechanism to see that env 
> variable.
> 
> *From: *Stephen McDowell <sjm324 at cornell.edu>
> *Date: *Saturday, July 7, 2018 at 2:25 AM
> *To: *Marc CHEVRIER <marc.chevrier at gmail.com>
> *Cc: *"Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>, CMake 
> MailingList <cmake at cmake.org>
> *Subject: *Re: [CMake] specifying path for license file for commercial 
> compiler?
> 
> I agree that a toolchain file is more appropriate, noting that typically 
> modifying the environment variables is much more common for there's 
> compilers (particularly using environment modules).
> 
> However, since you've started clearly you would rather not set the 
> environment variables, there may be an easier "hack".
> 
> Intel also looks in /opt/intel/licenses for any .lic files. So if you 
> want, you can just create a symbolic link or copy your license file there :)
> 
> On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER <marc.chevrier at gmail.com 
> <mailto:marc.chevrier at gmail.com>> wrote:
> 
>     May be using a toolchain file is more appropriate. See
> 
>     https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
> 
>     Le?ven. 6 juil. 2018 ? 22:59, Clune, Thomas L. (GSFC-6101)
>     <thomas.l.clune at nasa.gov <mailto:thomas.l.clune at nasa.gov>> a ?crit?:
> 
>         To use the Intel compiler, one must use an environment variable
>         that specifies the path to the license file.? E.g.,
> 
>          ? ? export INTEL_LICENSE_FILE=/usr/local/intel/license
> 
>         Other commercial compilers use a very similar mechanism.? ? I
>         had hoped to capture such information in a cache file so that I
>         could avoid polluting the shell where I am invoking cmake:
> 
>          ? ? % cmake -C my-cache <src-dir>
> 
>         Such a cache file could? look like:
> 
>          ? ? set(CMAKE_Fortran_COMPILER
>         "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
>         CACHE path "Fortran compiler")
>          ? ? set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license"
>         CACHE path "Intel license")
> 
> 
>         Unfortunately, the compiler is not ?seeing? the env variable and
>         complains that there is no license.? ? ?Is there a solution to
>         this, or am I forced to set the env variable each time I try to
>         build?
> 
> 
> 
> 
> 
> 
> 
>         -- 
> 
>         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
> 
>     -- 
> 
>     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
> 
> 
> 


From post at hendrik-sattler.de  Sun Jul  8 23:13:51 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Mon, 09 Jul 2018 05:13:51 +0200
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
Message-ID: <656FAC68-55F9-475A-97D8-EF009385E55E@hendrik-sattler.de>

You  could user "cmake -E env ...." in combination with https://cmake.org/cmake/help/v3.12/prop_gbl/RULE_LAUNCH_COMPILE.html and maybe https://cmake.org/cmake/help/v3.12/prop_gbl/RULE_LAUNCH_LINK.html if needed.


Am 6. Juli 2018 22:34:04 MESZ schrieb "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>:
>To use the Intel compiler, one must use an environment variable that
>specifies the path to the license file.  E.g.,
>
>    export INTEL_LICENSE_FILE=/usr/local/intel/license
>
>Other commercial compilers use a very similar mechanism.    I had hoped
>to capture such information in a cache file so that I could avoid
>polluting the shell where I am invoking cmake:
>
>    % cmake -C my-cache <src-dir>
>
>Such a cache file could  look like:
>
>set(CMAKE_Fortran_COMPILER
>"/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
>CACHE path "Fortran compiler")
>set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
>"Intel license")
>
>
>Unfortunately, the compiler is not ?seeing? the env variable and
>complains that there is no license.     Is there a solution to this, or
>am I forced to set the env variable each time I try to build?
>
>
>
>
>
>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at:
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For
>more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/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 Alan.W.Irwin1234 at gmail.com  Mon Jul  9 01:04:22 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Sun, 8 Jul 2018 22:04:22 -0700 (PDT)
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
Message-ID: <nycvar.QRO.7.76.1807082041450.9795@zreyva.zlyna.ubzr>

On 2018-07-06 20:34-0000 Clune, Thomas L. (GSFC-6101) wrote:

> To use the Intel compiler, one must use an environment variable that specifies the path to the license file.  E.g.,
>
>    export INTEL_LICENSE_FILE=/usr/local/intel/license
>
> Other commercial compilers use a very similar mechanism.    I had hoped to capture such information in a cache file so that I could avoid polluting the shell where I am invoking cmake:
>
>    % cmake -C my-cache <src-dir>
>
> Such a cache file could  look like:
>
>    set(CMAKE_Fortran_COMPILER "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" CACHE path "Fortran compiler")
>    set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel license")
>
>
> Unfortunately, the compiler is not ?seeing? the env variable and complains that there is no license.     Is there a solution to this, or am I forced to set the env variable each time I try to build?

Hi Thomas:

I only skimmed responses so someone else may have said this as well,
but you will need a valid license both at cmake time (since cmake
typically tests the compiler to see if it works) and also at build
time when you obviously also have to use the compiler.  In both cases
to answer your concern about polluting your normal environment
variable setup, I would advocate simply setting the environment
variable *just* for the command, e.g.,

env INTEL_LICENSE_FILE=/usr/local/intel/license cmake ....
env INTEL_LICENSE_FILE=/usr/local/intel/license make ...

rather than doing anything more complex.

I also have to ask is ifort really a necessity for you?  There are
two reasons I have asked this question.

* Licensing infrastructure you need with proprietary compilers was
just plain annoying to me in the past.  In the old days in a shared
environment I often had to wait to get work done until a compiler
license became available from someone else who was using it.  So our
institution kept buying more licenses, but it was never enough.  And
also in the old days when Sourceforge had a compile farm including
licensed compilers from Sun, that licensing software was semi-broken
and would often make it impossible to use the Sun part of the compile
farm.  Maybe licensing infrastructure is much better implemented now,
but those bad old days completely radicalized me about licensing
infrastructure annoyances, and as a result I have been content for
years to compile fortran code with gfortran which has no licensing
infrastructure annoyances and virtually always produces reliable
results for me.

* ifort reliability was not impressive the one time I had some
(indirect) experience with it.  For that case, I had a colleague who
wasted a month of both his time and my time trying to use ifort to
compile lapack as well as one of my software projects that required
lapack to solve some linear equations.  ifort didn't complain at all,
but simply produced bad results at run time (i.e., the linear
equations were not being solved correctly.)  After a lot of hair
pulling we discovered that this guy's habit (he was a strict fortran
traditionalist who would have no truck with new-fangled ideas such as
cmake!) of concatanating all fortran code into one giant file before
compiling it was the cause of the issue; ifort quietly produced bad
code whenever it had to process too many source lines!  I hope ifort
is much more reliable now, but it sure gave me a bad first impression
in that regard.

Hope you don't mind these old war stories.... :-)

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From anoopcs at autistici.org  Mon Jul  9 00:49:57 2018
From: anoopcs at autistici.org (Anoop C S)
Date: Mon, 09 Jul 2018 10:19:57 +0530
Subject: [CMake] ENOEXEC exit code from ctest on FreeBSD
Message-ID: <1dda7f826fe442609008e3208b2bfa4e105b95a6.camel@autistici.org>

Hi all,

While running tests from a wip branch[1] for socket_wrapper project I noticed the following output
on FreeBSD:

# make test
Running tests...
Test project /root/build
      Start  1: test_ioctl
 1/25 Test  #1: test_ioctl .............................   Passed    0.03 sec
      Start  2: test_tcp_listen
 2/25 Test  #2: test_tcp_listen ........................   Passed    0.03 sec
      Start  3: test_tcp_dup2
 3/25 Test  #3: test_tcp_dup2 ..........................   Passed    0.03 sec
      Start  4: test_fcntl
 4/25 Test  #4: test_fcntl .............................   Passed    0.03 sec
      Start  5: test_echo_tcp_connect
 5/25 Test  #5: test_echo_tcp_connect ..................   Passed    0.07 sec
      Start  6: test_echo_tcp_bind
 6/25 Test  #6: test_echo_tcp_bind .....................   Passed    0.34 sec
      Start  7: test_echo_tcp_socket_options
 7/25 Test  #7: test_echo_tcp_socket_options ...........   Passed    0.23 sec
      Start  8: test_echo_tcp_sendmsg_recvmsg
 8/25 Test  #8: test_echo_tcp_sendmsg_recvmsg ..........   Passed    0.19 sec
      Start  9: test_echo_tcp_write_read
 9/25 Test  #9: test_echo_tcp_write_read ...............   Passed    0.13 sec
      Start 10: test_echo_tcp_writev_readv
10/25 Test #10: test_echo_tcp_writev_readv .............   Passed    0.16 sec
      Start 11: test_echo_tcp_get_peer_sock_name
11/25 Test #11: test_echo_tcp_get_peer_sock_name .......   Passed    0.28 sec
      Start 12: test_echo_udp_sendto_recvfrom
12/25 Test #12: test_echo_udp_sendto_recvfrom ..........   Passed    0.23 sec
      Start 13: test_echo_udp_send_recv
13/25 Test #13: test_echo_udp_send_recv ................   Passed    0.12 sec
      Start 14: test_echo_udp_sendmsg_recvmsg
14/25 Test #14: test_echo_udp_sendmsg_recvmsg ..........   Passed    0.28 sec
      Start 15: test_swrap_unit
15/25 Test #15: test_swrap_unit ........................   Passed    0.00 sec
      Start 16: test_max_sockets
16/25 Test #16: test_max_sockets .......................   Passed    0.01 sec
      Start 17: test_close_failure
17/25 Test #17: test_close_failure .....................   Passed    0.03 sec
      Start 18: test_fork_thread_deadlock
18/25 Test #18: test_fork_thread_deadlock ..............   Passed    0.00 sec
      Start 19: test_tcp_socket_overwrite
19/25 Test #19: test_tcp_socket_overwrite ..............   Passed    0.03 sec
      Start 20: test_thread_sockets
20/25 Test #20: test_thread_sockets ....................   Passed    0.02 sec
      Start 21: test_thread_echo_tcp_connect
21/25 Test #21: test_thread_echo_tcp_connect ...........***Failed    0.07 sec
      Start 22: test_thread_echo_tcp_write_read
22/25 Test #22: test_thread_echo_tcp_write_read ........***Failed    0.07 sec
      Start 23: test_thread_echo_tcp_sendmsg_recvmsg
23/25 Test #23: test_thread_echo_tcp_sendmsg_recvmsg ...***Failed    0.07 sec
      Start 24: test_thread_echo_udp_send_recv
24/25 Test #24: test_thread_echo_udp_send_recv .........   Passed    0.08 sec
      Start 25: test_sendmsg_recvmsg_fd
25/25 Test #25: test_sendmsg_recvmsg_fd ................   Passed    0.00 sec

88% tests passed, 3 tests failed out of 25

Total Test time (real) =   2.54 sec

The following tests FAILED:
         21 - test_thread_echo_tcp_connect (Failed)
         22 - test_thread_echo_tcp_write_read (Failed)
         23 - test_thread_echo_tcp_sendmsg_recvmsg (Failed)
Errors while running CTest
*** Error code 8

Stop.
make: stopped in /root/build

Following that I ran one among the failed tests from the above list using `ctest`:

# ctest -R test_thread_echo_tcp_connect
Test project /root/build
    Start 21: test_thread_echo_tcp_connect
1/1 Test #21: test_thread_echo_tcp_connect .....***Failed    0.07 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.07 sec

The following tests FAILED:
         21 - test_thread_echo_tcp_connect (Failed)
Errors while running CTest

# echo $?
8

# uname -a
FreeBSD bazinga.localdomain 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC
2017     root at releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

# cmake --version
cmake version 3.10.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

I couldn't see any genuine errors from the test logs as such. Am I missing something? Since I am a
newbie to FreeBSD(and also to cmake) I would require some help to debug the reason for ENOEXEC exit
code.

Note:- The failed test cases uses threads.

[1] https://git.cryptomilk.org/users/asn/socket_wrapper.git/log/?h=master-fix


Thanks,
Anoop C S.

From eric.noulard at gmail.com  Mon Jul  9 02:14:37 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 9 Jul 2018 08:14:37 +0200
Subject: [CMake] ENOEXEC exit code from ctest on FreeBSD
In-Reply-To: <1dda7f826fe442609008e3208b2bfa4e105b95a6.camel@autistici.org>
References: <1dda7f826fe442609008e3208b2bfa4e105b95a6.camel@autistici.org>
Message-ID: <CAPASGLpNdqCHLj8kDxEwE2yFeR=vv8L=GXt+BkLGdfDKA2LQdQ@mail.gmail.com>

Le lun. 9 juil. 2018 ? 07:14, Anoop C S <anoopcs at autistici.org> a ?crit :

> Hi all,
>
> While running tests from a wip branch[1] for socket_wrapper project I
> noticed the following output
> on FreeBSD:
>
>
Your issue seems more related with the "socker wrapper" project than with
CMake/CTest but...


> Following that I ran one among the failed tests from the above list using
> `ctest`:
>
> # ctest -R test_thread_echo_tcp_connect
> Test project /root/build
>     Start 21: test_thread_echo_tcp_connect
> 1/1 Test #21: test_thread_echo_tcp_connect .....***Failed    0.07 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.07 sec
>
> The following tests FAILED:
>          21 - test_thread_echo_tcp_connect (Failed)
> Errors while running CTest
>

If you want to have more verbose output from ctest you an run:

ctest -R test_thread_echo_tcp_connect -VV

and ctest will spit out whatever output "test_thread_echo_tcp_connect" is
giving.
otherwise did you try to run the test "manually" without ctest:

from
https://git.cryptomilk.org/users/asn/socket_wrapper.git/tree/tests/CMakeLists.txt?h=master-fix
it looks like the test executable is:

test_thread_echo_tcp_connect

so try running:

./test_thread_echo_tcp_connect

and whether it fails or not.



> # uname -a
> FreeBSD bazinga.localdomain 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309:
> Fri Jul 21 02:08:28 UTC
> 2017     root at releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>
>
You seem to be compiling and running your tests as 'root' user. This is
usually not a good idea
(even if it may not have anything to do with your failure).


> I couldn't see any genuine errors from the test logs as such. Am I missing
> something? Since I am a
> newbie to FreeBSD(and also to cmake) I would require some help to debug
> the reason for ENOEXEC exit
> code.
>

Try running in verbose mode, you may even debug into the test if you run
the test without ctest.


>
> Note:- The failed test cases uses threads.
> [1]
> https://git.cryptomilk.org/users/asn/socket_wrapper.git/log/?h=master-fix
>
>
Then I suggest you ask on the project mailing list what may make this test
fail.

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

From eike at sf-mail.de  Mon Jul  9 03:01:14 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 09 Jul 2018 09:01:14 +0200
Subject: [CMake] find_package: keyword REQUIRED ignored
In-Reply-To: <005b95d8-0cc0-89f2-4222-0150984ea181@gmail.com>
References: <005b95d8-0cc0-89f2-4222-0150984ea181@gmail.com>
Message-ID: <182ea97e736f8a6a5f76bcf0951e9dca@sf-mail.de>

Am 2018-07-08 23:34, schrieb Quaquaraqu?:
> Hi there,
> 
> I'm using a custom script [1] to look for the library sqlite3.
> However, the keyword "REQUIRED" (as quietly) is ignored by
> find_package. That is even if the library is not found, the script
> continues is processing:
> 
> // CMakeLists.txt
> 
> cmake_minimum_required(VERSION 3.10)project(hello_world)list(APPEND
> CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build-aux/")
> find_package(SQLite3 REQUIRED)
> 
> // output:
> 
> cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang
> -DCMAKE_CXX_COMPILER=clang++ -G "CodeBlocks - Unix Makefiles" ../
> -- Could NOT find SQLITE3 (missing: SQLITE3_LIBRARY)
> -- Configuring done
> -- Generating done
> -- Build files have been written to: ...
> 
> 
> Any idea what is wrong here?
> 
> 
> [1] 
> https://github.com/LuaDist/libsqlite3/blob/master/cmake/FindSQLite3.cmake

Try:

find_package_handle_standard_args(SQLite3 ?

i.e. use the same case for the prefix as your file is called. And maybe 
use the second function signature of FPHSA.

Greetings,

Eike
-- 

From nilsgladitz at gmail.com  Mon Jul  9 03:10:11 2018
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Mon, 9 Jul 2018 09:10:11 +0200
Subject: [CMake] groups of ascii nul ('\0) characters inserted into make
 output but this just occurs for parallel builds
In-Reply-To: <nycvar.QRO.7.76.1807081302570.9795@zreyva.zlyna.ubzr>
References: <nycvar.QRO.7.76.1807081302570.9795@zreyva.zlyna.ubzr>
Message-ID: <CAEbDRx1Q1cYOgKA+-Ehb4FUJKWf3YYa0aP2-nLiP4rAFzTKdPA@mail.gmail.com>

On Sun, Jul 8, 2018 at 11:00 PM Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
wrote:

> My parallel builds on my Linux OS (currently Debian Buster, but this
> also happened for Debian Jessie so this is a long-standing problem)
> have ascii null ('\0) characters inserted in the output while the
> corresponding non-parallel build does not have those extra characters.
>

I narrowed it down with Ninja which buffers command outputs in parallel
builds which makes it easier to match output to specific commands.
Alternatively I think CTest launchers might have helped with this too.
CMake uses them to redirect build command outputs to distinct files for
CTest submissions.

I see null bytes coming from the "cat test.error" in the script file
generated from
https://sourceforge.net/p/plplot/plplot/ci/master/tree/plplot_test/test_c.sh.in

If this only shows up in parallel builds perhaps multiple processes are
reading/writing the same test.error file in parallel?
Haven't looked closer than that. You probably know better where to look
from there.

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

From mark.dewit at iesve.com  Mon Jul  9 03:45:25 2018
From: mark.dewit at iesve.com (Mark De Wit)
Date: Mon, 9 Jul 2018 07:45:25 +0000
Subject: [CMake] find_package: keyword REQUIRED ignored
In-Reply-To: <005b95d8-0cc0-89f2-4222-0150984ea181@gmail.com>
References: <005b95d8-0cc0-89f2-4222-0150984ea181@gmail.com>
Message-ID: <8572c1668e504e72a1494033a385a147@iesve.com>

I thought that the find script itself was responsible for checking the required flag?

Our own find scripts do something along the lines of (note that we named ours sqlite, not sqlite3!)

if(NOT sqlite_FIND_QUIETLY)
  MESSAGE(STATUS "Looking for sqlite...")
endif()

?  look for package here

? if not found and required, signal fatal error:
      if(sqlite_FIND_REQUIRED)
        message(FATAL_ERROR "Looking for sqlite... - Not found")
      endif()


From the CMake documentation on find_package:

When loading a find module or package configuration file find_package defines variables to provide information about the call arguments (and restores their original state before returning):
?
<package>_FIND_REQUIRED
true if REQUIRED option was given
<package>_FIND_QUIETLY
true if QUIET option was given

In Module mode the loaded find module is responsible to honor the request detailed by these variables; see the find module for details. In Config mode find_package handles REQUIRED, QUIET, and [version] options automatically

Mark

From: CMake <cmake-bounces at cmake.org> On Behalf Of Quaquaraqu?
Sent: 08 July 2018 22:35
To: Cmake Mailing List <cmake at cmake.org>
Subject: [CMake] find_package: keyword REQUIRED ignored


Hi there,

I'm using a custom script [1] to look for the library sqlite3. However, the keyword "REQUIRED" (as quietly) is ignored by find_package. That is even if the library is not found, the script continues is processing:

// CMakeLists.txt

cmake_minimum_required(VERSION 3.10)

project(hello_world)

list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build-aux/")

find_package(SQLite3 REQUIRED)

// output:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -G "CodeBlocks - Unix Makefiles" ../
-- Could NOT find SQLITE3 (missing: SQLITE3_LIBRARY)
-- Configuring done
-- Generating done
-- Build files have been written to: ...



Any idea what is wrong here?



[1] https://github.com/LuaDist/libsqlite3/blob/master/cmake/FindSQLite3.cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/b13f78c1/attachment.html>

From marc.chevrier at gmail.com  Mon Jul  9 04:40:40 2018
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Mon, 9 Jul 2018 10:40:40 +0200
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <C0779532-5F9F-410A-840C-2C86AF5CF3C5@nasa.gov>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
 <C0779532-5F9F-410A-840C-2C86AF5CF3C5@nasa.gov>
Message-ID: <CAHKTGrdi3vE4Vs_zXviu0AWMCiZZN_ZD3+WqD4L_Z7HmZF=O9g@mail.gmail.com>

You have just to put set command (not cache) for your compiler
(CMAKE_Fortran_COMPILER) and environment variable in a file and specify
this file on cmake command line with option
-DCMAKE_TOOLCHAIN_FILE=your-file.

Le lun. 9 juil. 2018 ? 03:32, Clune, Thomas L. (GSFC-6101) <
thomas.l.clune at nasa.gov> a ?crit :

> Marc,
>
>
>
> Thank you for the suggestion.  Unfortunately, I?m a bit confused by the
> documentation and not at all sure how to proceed.   Further help would be
> appreciated.
>
>
>
> In particular, I do not see how to capture the existing Fortran, C and CXX
> toolchains and then provide the minor extension of setting this one
> environment variable.   In fact, at the moment, I don?t even see a simple
> way to cut-and-paste the cmake built-in toolchains into a file to use as my
> baseline for extension.
>
>
>
> Am I correct in assuming that once the above issues are solved, then a
> simple line of the form
>
>
>
> set(ENV(INTEL_LICENSE_FILE) ???)
>
>
>
> will then ensure that the compiler ?sees? that env variable?   Or do I
> need to wrap the compiler in a script which just raises many more issues as
> I need my project to be able to build with many different versions of the
> Intel compiler.
>
>
>
> Thanks in advance,
>
>
>
>    - Tom
>
>
>
>
>
> *From: *Marc CHEVRIER <marc.chevrier at gmail.com>
> *Date: *Saturday, July 7, 2018 at 1:49 AM
> *To: *"Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>
> *Cc: *CMake MailingList <cmake at cmake.org>
> *Subject: *Re: [CMake] specifying path for license file for commercial
> compiler?
>
>
>
> May be using a toolchain file is more appropriate. See
>
> https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
>
>
>
>
>
> Le ven. 6 juil. 2018 ? 22:59, Clune, Thomas L. (GSFC-6101) <
> thomas.l.clune at nasa.gov> a ?crit :
>
> To use the Intel compiler, one must use an environment variable that
> specifies the path to the license file.  E.g.,
>
>     export INTEL_LICENSE_FILE=/usr/local/intel/license
>
> Other commercial compilers use a very similar mechanism.    I had hoped to
> capture such information in a cache file so that I could avoid polluting
> the shell where I am invoking cmake:
>
>     % cmake -C my-cache <src-dir>
>
> Such a cache file could  look like:
>
>     set(CMAKE_Fortran_COMPILER
> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
> CACHE path "Fortran compiler")
>     set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
> "Intel license")
>
>
> Unfortunately, the compiler is not ?seeing? the env variable and complains
> that there is no license.     Is there a solution to this, or am I forced
> to set the env variable each time I try to build?
>
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180709/b674ac7a/attachment-0001.html>

From thomas.l.clune at nasa.gov  Mon Jul  9 08:48:38 2018
From: thomas.l.clune at nasa.gov (Clune, Thomas L. (GSFC-6101))
Date: Mon, 9 Jul 2018 12:48:38 +0000
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <nycvar.QRO.7.76.1807082041450.9795@zreyva.zlyna.ubzr>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <nycvar.QRO.7.76.1807082041450.9795@zreyva.zlyna.ubzr>
Message-ID: <1C78E55C-6E8A-499F-8885-A690DFABA280@nasa.gov>



> On Jul 9, 2018, at 1:04 AM, Alan W. Irwin <Alan.W.Irwin1234 at gmail.com> wrote:
> 
> On 2018-07-06 20:34-0000 Clune, Thomas L. (GSFC-6101) wrote:
> 
>> To use the Intel compiler, one must use an environment variable that specifies the path to the license file.  E.g.,
>> 
>>   export INTEL_LICENSE_FILE=/usr/local/intel/license
>> 
>> Other commercial compilers use a very similar mechanism.    I had hoped to capture such information in a cache file so that I could avoid polluting the shell where I am invoking cmake:
>> 
>>   % cmake -C my-cache <src-dir>
>> 
>> Such a cache file could  look like:
>> 
>>   set(CMAKE_Fortran_COMPILER "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" CACHE path "Fortran compiler")
>>   set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel license")
>> 
>> 
>> Unfortunately, the compiler is not ?seeing? the env variable and complains that there is no license.     Is there a solution to this, or am I forced to set the env variable each time I try to build?
> 
> Hi Thomas:
> 
> I only skimmed responses so someone else may have said this as well,
> but you will need a valid license both at cmake time (since cmake
> typically tests the compiler to see if it works) and also at build
> time when you obviously also have to use the compiler.  In both cases
> to answer your concern about polluting your normal environment
> variable setup, I would advocate simply setting the environment
> variable *just* for the command, e.g.,
> 
> env INTEL_LICENSE_FILE=/usr/local/intel/license cmake ....
> env INTEL_LICENSE_FILE=/usr/local/intel/license make ?

I agree that this will work, but I?m trying to make things as easy as possible on our ?developers?.  (Our developers are largely scientists with little interest learning any new details about our build system, and I?m the one forcing them towards cmake.)   Currently _every_ other setting in the configuration is captured in the generated make system and their remains a danger that someone will login the next morning and forget to make the extra step.    It really is not that big of a deal, but the difference is glaring given nothing else needs this.


> 
> rather than doing anything more complex.
> 
> I also have to ask is ifort really a necessity for you?  There are
> two reasons I have asked this question.
> 
> * Licensing infrastructure you need with proprietary compilers was
> just plain annoying to me in the past.  In the old days in a shared
> environment I often had to wait to get work done until a compiler
> license became available from someone else who was using it.  So our
> institution kept buying more licenses, but it was never enough.  

Our computing centers have what is in essence an unlimited license, so this is not an issue for us.   (Helps when you buy thousands of cores each year.)   

There are several issues here.    We try to keep our model as portable as possible.   In practice this means gfortran, ifort, and PGI, with plans for others.   Intel remains the workhorse for the scientists because it generates faster code  (10%-25% depending on the configuration.)    Any given version of the model is intended therefore to default to a specific version of the Intel compiler.   The core team needs the ability to explore variant versions of the compiler as we introduce new features that break older compilers.    In theory, and aside from this license file issue,  all of the pertinent information can be set on the command line for cmake and then subsequent make commands are very simple ?make install?.     

I?ve not yet exposed the scientists to the cmake build system, and they are still using a well-designed but idiosyncratic set of GNUmake + env setup scripts.   I would like to capture the details for the variant builds so that the typical scientist can simply type:

% cmake  <src-dir>
% make -j 10 install

while the core team can do variants with

% cmake  <some-flags-to-point-to-gfortran-8.3>  <src-dir>
or
% cmake <some-flags-to-point-to ifort-version++> <src-dir>

Currently I am using environment modules  (mod and lmod) to load the path for the compiler and license files.   This is workable, but I thought I could go one step further and eliminate the need for setting up an environment for the ?make? step.    


> And
> also in the old days when Sourceforge had a compile farm including
> licensed compilers from Sun, that licensing software was semi-broken
> and would often make it impossible to use the Sun part of the compile
> farm.  Maybe licensing infrastructure is much better implemented now,
> but those bad old days completely radicalized me about licensing
> infrastructure annoyances, and as a result I have been content for
> years to compile fortran code with gfortran which has no licensing
> infrastructure annoyances and virtually always produces reliable
> results for me.

While we technically do not have a mandate to support our compiler for external developers, we do maintain gfortran capabilities for various reasons including the ones you mention above.


> 
> * ifort reliability was not impressive the one time I had some
> (indirect) experience with it.  For that case, I had a colleague who
> wasted a month of both his time and my time trying to use ifort to
> compile lapack as well as one of my software projects that required
> lapack to solve some linear equations.  ifort didn't complain at all,
> but simply produced bad results at run time (i.e., the linear
> equations were not being solved correctly.)  After a lot of hair
> pulling we discovered that this guy's habit (he was a strict fortran
> traditionalist who would have no truck with new-fangled ideas such as
> cmake!) of concatanating all fortran code into one giant file before
> compiling it was the cause of the issue; ifort quietly produced bad
> code whenever it had to process too many source lines!  I hope ifort
> is much more reliable now, but it sure gave me a bad first impression
> in that regard.
> 
> Hope you don't mind these old war stories.... :-)

Based upon conversations with colleagues in other institutions, the most frustrating compiler is always the one you don?t do your development with.     Because of my clients, I mostly start with Intel and then get frustrated when a design discovers defects in gfortran.   But others that primarily work with gfortran say the same about Intel.   My conclusion as that we subconsciously develop a coding style this is (mostly) robust within our native environment.      When the situation permits, I mostly develop with the NAG fortran compiler.   The generated code is not particularly fast, but the compiler is very strict and very robust.   

Cheers,

- Tom



> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________


From thomas.l.clune at nasa.gov  Mon Jul  9 09:36:03 2018
From: thomas.l.clune at nasa.gov (Clune, Thomas L. (GSFC-6101))
Date: Mon, 9 Jul 2018 13:36:03 +0000
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <CAHKTGrdi3vE4Vs_zXviu0AWMCiZZN_ZD3+WqD4L_Z7HmZF=O9g@mail.gmail.com>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <CAHKTGrf=ynXRZ6yQLdpedbf-S6n9=74rAq9Fr9ssBr6RxQeQ3A@mail.gmail.com>
 <C0779532-5F9F-410A-840C-2C86AF5CF3C5@nasa.gov>
 <CAHKTGrdi3vE4Vs_zXviu0AWMCiZZN_ZD3+WqD4L_Z7HmZF=O9g@mail.gmail.com>
Message-ID: <43D2AF36-2B7C-49D8-B0D8-45E8D62FCC77@nasa.gov>

Mark and Juan,

Thanks!   Between your two suggestions I was able to make something work.    My first attempt at using -DCMAKE_TOOLCHAIN_FILE resulted in some error messages that I completely misinterpreted as needing to ?re-teach?  CMAKE about the Intel compiler.    A simple wrapper for the compiler does exactly what was desired.





> On Jul 9, 2018, at 4:40 AM, Marc CHEVRIER <marc.chevrier at gmail.com> wrote:
> 
> You have just to put set command (not cache) for your compiler (CMAKE_Fortran_COMPILER) and environment variable in a file and specify this file on cmake command line with option -DCMAKE_TOOLCHAIN_FILE=your-file.



> On Jul 8, 2018, at 10:32 PM, Juan E. Sanchez <juan.e.sanchez at gmail.com> wrote:
> 
> Hi,
> 
> Could you create a simple compiler wrapper script, and point the CMAKE_*_COMPILER variables there:
> 
> #!/bin/bash
> export INTEL_LICENSE_FILE=/usr/local/intel/license
> /path/to/ifort "$@"
> 
> Regards,
> 
> Juan
> 


From quang.t.ha.20 at gmail.com  Mon Jul  9 09:51:57 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Mon, 9 Jul 2018 07:51:57 -0600
Subject: [CMake] CMake tried to pass all flags from gcc into nvcc when
 trying to add CUDA extension to current CPP project
Message-ID: <CAGfE9+PG2LxDV=vmNPUFos91DixWoKF7fqX9ey8Qp9+h7ATVTA@mail.gmail.com>

Hi all,

The situation I am currently in is as followed. This is the directory for
my project:

project
|----------CMakeLists.txt
|----------app
|            |--------CMakeLists.txt
|            |--------test_cuda
|                          |--------CMakeLists.txt
|                          |--------test_cuda.cu
|----------src
|----------test
|----------doc

Inside project/app/CMakeLists.txt, it looks like this:
##
add_subdirectory(test_cuda)
##
and then inside project/app/test_cuda/CMakeLists.txt, it is:
##
find_package(CUDA REQUIRED)

if (CUDA_FOUND)
    # CUDA falgs
    include_directories(${CUDA_INCLUDE_DIRS})
    set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
${CUDA_cublas_LIBRARY})
    set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
    set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
    # set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
arch=compute_70,code=sm_70)

    # Link to executable
    cuda_add_executable(test_cuda test_cuda.cu)
    # set_target_properties(test_cuda PROPERTIES COMPILE_FLAGS
"-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
    set_target_properties(test_cuda PROPERTIES CUDA_SEPARABLE_COMPILATION
ON)
    set_target_properties(test_cuda PROPERTIES CUDA_PROPAGATE_HOST_FLAGS
OFF)
    target_link_libraries(test_cuda ${LIBS} ${EXTRA_LIBS})
endif()
##

There is nothing special inside test_cuda.cu - since I just want to test
cmake integration:
##
#include <stdio.h>
#include <fstream>

__global__
void kernel (void){
}

int main(void ) {
  kernel<<<1,1>>>();
  return 0;
}
##

I got an error when running cmake with this:

###
[ 75%] Building NVCC (Device) object
app/test_cuda/CMakeFiles/test_cuda.dir/test_cuda_generated_test_cuda.cu.o
/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(200):
error: statement may not appear in a constexpr function

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(202):
error: a constexpr function must contain exactly one return statement

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(224):
error: statement may not appear in a constexpr function

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(226):
error: a constexpr function must contain exactly one return statement

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(246):
error: statement may not appear in a constexpr function

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(248):
error: a constexpr function must contain exactly one return statement

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(268):
error: statement may not appear in a constexpr function

/projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(270):
error: a constexpr function must contain exactly one return statement

8 errors detected in the compilation of
"/tmp/tmpxft_00003241_00000000-4_test_cuda.cpp4.ii".
CMake Error at test_cuda_generated_test_cuda.cu.o.Release.cmake:279
(message):
  Error generating file

/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
###

Checking with make VERBOSE=1:

##
[ 75%] Building NVCC (Device) object
app/test_cuda/CMakeFiles/test_cuda.dir/test_cuda_generated_test_cuda.cu.o
cd /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir
&& /projects/opt/centos7/cmake/3.11.1/bin/cmake -E make_directory
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//.
cd /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir
&& /projects/opt/centos7/cmake/3.11.1/bin/cmake -D verbose:BOOL=1 -D
build_configuration:STRING=Release -D
generated_file:STRING=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
-D
generated_cubin_file:STRING=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o.cubin.txt
-P
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.Release.cmake
-- Removing
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E remove
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
-- Generating dependency file:
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
/projects/opt/centos7/cuda/9.1/bin/nvcc -M -D__CUDACC__
/home/qth20/develop/project/app/test_cuda/test_cuda.cu -o
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
-ccbin /projects/opt/centos7/gcc/6.4.0/bin/gcc -m64 -DTHRUST
-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP
-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
"-DCUDA_CALLABLE=\"__host__ __device__\"" -Xcompiler
,\"-std=c++14\",\"-O3\",\"-DNDEBUG\" --std=c++11 --expt-relaxed-constexpr
-Xcompiler -fPIC --maxrregcount 32 -DNVCC
-I/projects/opt/centos7/cuda/9.1/include -I/home/qth20/develop/project
-I/home/qth20/develop/project/build
-I/home/qth20/develop/project/cinch/logging
-I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include    /UnitTest++
-- Generating temporary cmake readable file:
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
/projects/opt/centos7/cmake/3.11.1/bin/cmake -D
input_file:FILEPATH=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
-D
output_file:FILEPATH=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
-D verbose=1 -P
/projects/opt/centos7/cmake/3.11.1/share/cmake-3.11/Modules/FindCUDA/make2cmake.cmake
-- Copy if different
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
to
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E copy_if_different
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend
-- Removing
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
and
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E remove
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
-- Generating
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
/projects/opt/centos7/cuda/9.1/bin/nvcc
/home/qth20/develop/project/app/test_cuda/test_cuda.cu -c -o
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
-ccbin /projects/opt/centos7/gcc/6.4.0/bin/gcc -m64 -DTHRUST
-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP
-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
"-DCUDA_CALLABLE=\"__host__ __device__\"" -Xcompiler
,\"-std=c++14\",\"-O3\",\"-DNDEBUG\" --std=c++11 --expt-relaxed-constexpr
-Xcompiler -fPIC --maxrregcount 32 -DNVCC
-I/projects/opt/centos7/cuda/9.1/include -I/home/qth20/develop/project
-I/home/qth20/develop/project/build
-I/home/qth20/develop/project/cinch/logging
-I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include    /UnitTest++
[Error]
##

It looks like all the flags used in gcc is passed directly into nvcc. Is
there a way to turn this off?

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/804a0b82/attachment-0001.html>

From petar at brainsciencetools.com  Mon Jul  9 10:58:23 2018
From: petar at brainsciencetools.com (Petar Petrov)
Date: Mon, 9 Jul 2018 16:58:23 +0200
Subject: [CMake] wix msi csharp dotnet project type
Message-ID: <CABKY7vFME28Hhhhd3FEBpmwGkOE+toLeC2Z2tUtx3w6qm_c9gA@mail.gmail.com>

I have gone through the cmake wix docs and in particular anything special
about dotnet csharp projects, however I failed to find anything related to
influencing the 'Output Type' of project's settings window inside visual
studio!

The options are: 'Console Application, Windows Application and Class
Library', the generator defaults to Console Application while I do have a
WPF windows only app, so I have an annoying console/terminal window in
addition to the main-win. There are plenty of possible hack to influence
the generated project file directly (which just a xml) but it is truly a
job of the wix generator and I expected to be an easy straightforward way
of setting it.

Any tips and suggestions are welcomed!

Thanks in advance,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/972c4ea2/attachment.html>

From calebwherry at gmail.com  Mon Jul  9 11:03:18 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Mon, 9 Jul 2018 11:03:18 -0400
Subject: [CMake] wix msi csharp dotnet project type
In-Reply-To: <CABKY7vFME28Hhhhd3FEBpmwGkOE+toLeC2Z2tUtx3w6qm_c9gA@mail.gmail.com>
References: <CABKY7vFME28Hhhhd3FEBpmwGkOE+toLeC2Z2tUtx3w6qm_c9gA@mail.gmail.com>
Message-ID: <CAJxY6XqvP8UKEFfRsA5k3eKM903PX16Fw18wsfX9PMpcJ6x7mg@mail.gmail.com>

If you set the WIN32_EXECUTABLE property on your WPF target then it will
have the behavior you are looking for.

-Caleb

On Mon, Jul 9, 2018 at 10:58 AM Petar Petrov <petar at brainsciencetools.com>
wrote:

> I have gone through the cmake wix docs and in particular anything special
> about dotnet csharp projects, however I failed to find anything related to
> influencing the 'Output Type' of project's settings window inside visual
> studio!
>
> The options are: 'Console Application, Windows Application and Class
> Library', the generator defaults to Console Application while I do have a
> WPF windows only app, so I have an annoying console/terminal window in
> addition to the main-win. There are plenty of possible hack to influence
> the generated project file directly (which just a xml) but it is truly a
> job of the wix generator and I expected to be an easy straightforward way
> of setting it.
>
> Any tips and suggestions are welcomed!
>
> Thanks in advance,
> Peter
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
>


-- 
J. Caleb Wherry
*Scientific Software Engineer*

<http://www.calebwherry.com>
http://www.calebwherry.com
+1 (615) 708-5651
calebwherry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/d81e0f6f/attachment.html>

From robert.maynard at kitware.com  Mon Jul  9 11:54:29 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 9 Jul 2018 11:54:29 -0400
Subject: [CMake] CMake tried to pass all flags from gcc into nvcc when
 trying to add CUDA extension to current CPP project
In-Reply-To: <CAGfE9+PG2LxDV=vmNPUFos91DixWoKF7fqX9ey8Qp9+h7ATVTA@mail.gmail.com>
References: <CAGfE9+PG2LxDV=vmNPUFos91DixWoKF7fqX9ey8Qp9+h7ATVTA@mail.gmail.com>
Message-ID: <CAFzjYVoWh5PO3Q7HKiw4-wgFLixSQW5NBPU1AJF-LdhwKK28FQ@mail.gmail.com>

The `CUDA_PROPAGATE_HOST_FLAGS` and `CUDA_SEPARABLE_COMPILATION` are global
variables ( use `set` ) not a target properties. You can find more
documentation on the legacy cuda support variable in the find cuda module (
https://cmake.org/cmake/help/latest/module/FindCUDA.html ).

On Mon, Jul 9, 2018 at 9:52 AM Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> Hi all,
>
> The situation I am currently in is as followed. This is the directory for
> my project:
>
> project
> |----------CMakeLists.txt
> |----------app
> |            |--------CMakeLists.txt
> |            |--------test_cuda
> |                          |--------CMakeLists.txt
> |                          |--------test_cuda.cu
> |----------src
> |----------test
> |----------doc
>
> Inside project/app/CMakeLists.txt, it looks like this:
> ##
> add_subdirectory(test_cuda)
> ##
> and then inside project/app/test_cuda/CMakeLists.txt, it is:
> ##
> find_package(CUDA REQUIRED)
>
> if (CUDA_FOUND)
>     # CUDA falgs
>     include_directories(${CUDA_INCLUDE_DIRS})
>     set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
> ${CUDA_cublas_LIBRARY})
>     set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
>     set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
>     # set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
> arch=compute_70,code=sm_70)
>
>     # Link to executable
>     cuda_add_executable(test_cuda test_cuda.cu)
>     # set_target_properties(test_cuda PROPERTIES COMPILE_FLAGS
> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
>     set_target_properties(test_cuda PROPERTIES CUDA_SEPARABLE_COMPILATION
> ON)
>     set_target_properties(test_cuda PROPERTIES CUDA_PROPAGATE_HOST_FLAGS
> OFF)
>     target_link_libraries(test_cuda ${LIBS} ${EXTRA_LIBS})
> endif()
> ##
>
> There is nothing special inside test_cuda.cu - since I just want to test
> cmake integration:
> ##
> #include <stdio.h>
> #include <fstream>
>
> __global__
> void kernel (void){
> }
>
> int main(void ) {
>   kernel<<<1,1>>>();
>   return 0;
> }
> ##
>
> I got an error when running cmake with this:
>
> ###
> [ 75%] Building NVCC (Device) object
> app/test_cuda/CMakeFiles/test_cuda.dir/test_cuda_generated_test_cuda.cu.o
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(200):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(202):
> error: a constexpr function must contain exactly one return statement
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(224):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(226):
> error: a constexpr function must contain exactly one return statement
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(246):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(248):
> error: a constexpr function must contain exactly one return statement
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(268):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(270):
> error: a constexpr function must contain exactly one return statement
>
> 8 errors detected in the compilation of
> "/tmp/tmpxft_00003241_00000000-4_test_cuda.cpp4.ii".
> CMake Error at test_cuda_generated_test_cuda.cu.o.Release.cmake:279
> (message):
>   Error generating file
>
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> ###
>
> Checking with make VERBOSE=1:
>
> ##
> [ 75%] Building NVCC (Device) object
> app/test_cuda/CMakeFiles/test_cuda.dir/test_cuda_generated_test_cuda.cu.o
> cd
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E make_directory
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//.
> cd
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -D verbose:BOOL=1 -D
> build_configuration:STRING=Release -D
> generated_file:STRING=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> -D
> generated_cubin_file:STRING=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o.cubin.txt
> -P
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.Release.cmake
> -- Removing
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E remove
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> -- Generating dependency file:
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
> /projects/opt/centos7/cuda/9.1/bin/nvcc -M -D__CUDACC__
> /home/qth20/develop/project/app/test_cuda/test_cuda.cu -o
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
> -ccbin /projects/opt/centos7/gcc/6.4.0/bin/gcc -m64 -DTHRUST
> -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP
> -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
> "-DCUDA_CALLABLE=\"__host__ __device__\"" -Xcompiler
> ,\"-std=c++14\",\"-O3\",\"-DNDEBUG\" --std=c++11 --expt-relaxed-constexpr
> -Xcompiler -fPIC --maxrregcount 32 -DNVCC
> -I/projects/opt/centos7/cuda/9.1/include -I/home/qth20/develop/project
> -I/home/qth20/develop/project/build
> -I/home/qth20/develop/project/cinch/logging
> -I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include    /UnitTest++
> -- Generating temporary cmake readable file:
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -D
> input_file:FILEPATH=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
> -D
> output_file:FILEPATH=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
> -D verbose=1 -P
> /projects/opt/centos7/cmake/3.11.1/share/cmake-3.11/Modules/FindCUDA/make2cmake.cmake
> -- Copy if different
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
> to
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E copy_if_different
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend
> -- Removing
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
> and
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E remove
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.depend.tmp
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
> -- Generating
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> /projects/opt/centos7/cuda/9.1/bin/nvcc
> /home/qth20/develop/project/app/test_cuda/test_cuda.cu -c -o
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> -ccbin /projects/opt/centos7/gcc/6.4.0/bin/gcc -m64 -DTHRUST
> -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP
> -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
> "-DCUDA_CALLABLE=\"__host__ __device__\"" -Xcompiler
> ,\"-std=c++14\",\"-O3\",\"-DNDEBUG\" --std=c++11 --expt-relaxed-constexpr
> -Xcompiler -fPIC --maxrregcount 32 -DNVCC
> -I/projects/opt/centos7/cuda/9.1/include -I/home/qth20/develop/project
> -I/home/qth20/develop/project/build
> -I/home/qth20/develop/project/cinch/logging
> -I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include    /UnitTest++
> [Error]
> ##
>
> It looks like all the flags used in gcc is passed directly into nvcc. Is
> there a way to turn this off?
>
> 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/20180709/7185f89d/attachment-0001.html>

From robert.maynard at kitware.com  Mon Jul  9 12:11:45 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 9 Jul 2018 12:11:45 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.12.0-rc3 is ready for testing
Message-ID: <CAFzjYVq6zi_JvZf7JUat--SW0-f6V-7bRCaKCH=EoRa8E-+uiA@mail.gmail.com>

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

The first two 3.12.0 release candidates included a change to allow
the target_link_libraries command to modify targets created outside
the current directory. This has been reverted in rc3 due to
problems with visibility of the linked targets. See issue 17943.

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

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

Some of the more significant changes in CMake 3.12 are:

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

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

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel [<jobs>]" and "-j [<jobs>]" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "<min>[...<max>]". The "<min>" version is required but policies are
  set based on the "<max>" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* A new "$<GENEX_EVAL:...>" and "$<TARGET_GENEX_EVAL:target,...>"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$<TARGET_EXISTS:...>" "generator expression" has been
  added.

* A new "$<TARGET_NAME_IF_EXISTS:...>" "generator expression" has
  been added.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.


CMake 3.12 Release Notes
************************

Changes made since CMake 3.11 include the following.


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


Generators
----------

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.


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

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel [<jobs>]" and "-j [<jobs>]" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.


Commands
--------

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "<min>[...<max>]". The "<min>" version is required but policies are
  set based on the "<max>" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "file(TOUCH)" and "file(TOUCH_NOCREATE)" commands were added
  to expose "TOUCH" functionality without having to use CMake's
  command- line tool mode with "execute_process()".

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* The "install()" command learned an optional "NAMELINK_COMPONENT"
  parameter, which allows you to change the component for a shared
  library's namelink. If none is specified, the value of "COMPONENT"
  is used by default.

* The "list()" command learned a "JOIN" sub-command to concatenate
  list's elements separated by a glue string.

* The "list()" command learned a "SUBLIST" sub-command to get a
  sublist of the list.

* The "list()" command learned a "TRANSFORM" sub-command to apply
  various string transformation to list's elements.

* The "project()" command learned an optional "HOMEPAGE_URL"
  parameter which has the effect of setting variables like
  "PROJECT_HOMEPAGE_URL", "<PROJECT-NAME>_HOMEPAGE_URL" and
  "CMAKE_PROJECT_HOMEPAGE_URL".

* The "string()" command learned a "JOIN" sub-command to concatenate
  input strings separated by a glue string.

* "target_compile_options()" and "add_compile_options()" commands
  gained a "SHELL:" prefix to specify a group of related options using
  shell-like quoting.

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.


Variables
---------

* The "CMAKE_FOLDER" variable was added to initialize the "FOLDER"
  property on all targets.

* The "CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION" variable was defined
  to initialize all "DOTNET_TARGET_FRAMEWORK_VERSION" target
  properties.

* "CMAKE_PROJECT_VERSION*" variables have been introduced:

  * "CMAKE_PROJECT_VERSION"

  * "CMAKE_PROJECT_VERSION_MAJOR"

  * "CMAKE_PROJECT_VERSION_MINOR"

  * "CMAKE_PROJECT_VERSION_PATCH"

  * "CMAKE_PROJECT_VERSION_TWEAK"

* The "CMAKE_SUPPRESS_REGENERATION" variable was extended to support
  the "Ninja" and Makefile Generators. It is also now documented.

* "CMAKE_VS_SDK_*_DIRECTORIES" variables were defined to tell Visual
  Studio Generators for VS 2010 and above how to populate fields in
  ".vcxproj" files that specify SDK directories.  The variables are:

  * "CMAKE_VS_SDK_EXCLUDE_DIRECTORIES"

  * "CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES"

  * "CMAKE_VS_SDK_INCLUDE_DIRECTORIES"

  * "CMAKE_VS_SDK_LIBRARY_DIRECTORIES"

  * "CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES"

  * "CMAKE_VS_SDK_REFERENCE_DIRECTORIES"

  * "CMAKE_VS_SDK_SOURCE_DIRECTORIES"

* A "MSVC_TOOLSET_VERSION" variable was added to provide the MSVC
  toolset version associated with the current MSVC compiler version in
  "MSVC_VERSION".


Properties
----------

* The "COMMON_LANGUAGE_RUNTIME" target property was introduced to
  configure the use of managed C++ for Visual Studio Generators for VS
  2010 and above. A corresponding "IMPORTED_COMMON_LANGUAGE_RUNTIME"
  target property was added to support "C++/CLI" for imported targets.

* The "DOTNET_TARGET_FRAMEWORK_VERSION" target property was
  introduced as replacement for "VS_DOTNET_TARGET_FRAMEWORK_VERSION",
  which is considered deprecated now.

* An "EXPORT_PROPERTIES" target property was added to specify a
  custom list of target properties to include in targets exported by
  the "install(EXPORT)" and "export()" commands.

* The "PDB_OUTPUT_DIRECTORY" property learned to support "generator
  expressions".

* A "TESTS" directory property was added to hold the list of tests
  defined by the "add_test()" command.

* A "VS_DEBUGGER_COMMAND" target property was created to set the
  debugging command line with Visual Studio Generators for VS 2010 and
  above.

* HLSL source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and
  "VS_SHADER_ENABLE_DEBUG" gained support for generator expressions.

* HLSL source file property "VS_SHADER_OBJECT_FILE_NAME" has been
  added to the Visual Studio Generators for VS 2010 and above. The
  property specifies the file name of the compiled shader object.


Modules
-------

* The "FindALSA" module now provides imported targets.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* The "FindLibXml2" module now provides imported targets.

* The "FindMatlab" module now supports the Matlab Runtime Compiler
  (MCR) for compiling and linking matlab extensions.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* The "FindPkgConfig" module has learned to export the found
  libraries with full path for direct consumption with the
  "target_link_libraries()" command.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.

* The "UseSWIG" module gained a whole refresh and is now more
  consistent with standard CMake commands to generate libraries and is
  fully configurable through properties.

* The "UseSWIG" module learned to manage multiple behaviors through
  "UseSWIG_MODULE_VERSION" variable to ensure legacy support as well
  as more robust handling of "SWIG" advanced features (like
  "%template").

* The "UseSWIG" module learned to support CSHARP variant wrapper
  files.

* The "WriteCompilerDetectionHeader" module gained a "BARE_FEATURES"
  option to add a compatibility define for the exact keyword of a new
  language feature.


Generator Expressions
---------------------

* A new "$<GENEX_EVAL:...>" and "$<TARGET_GENEX_EVAL:target,...>"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$<IN_LIST:...>" "generator expression" has been added.

* A new "$<TARGET_EXISTS:...>" "generator expression" has been
  added.

* A new "$<TARGET_NAME_IF_EXISTS:...>" "generator expression" has
  been added.


CTest
-----

* The "ctest_start()" command has been reworked so that you can
  simply call "ctest_start(APPEND)" and it will read all the needed
  information from the TAG file. The argument parsing has also been
  relaxed so that the order of the arguments is less significant.

* A "PROCESSOR_AFFINITY" test property was added to request that
  CTest run a test with CPU affinity for a set of processors disjoint
  from other concurrently running tests with the property set.


CPack
-----

* The "CPack" module now uses variables
  "CMAKE_PROJECT_VERSION_MAJOR", "CMAKE_PROJECT_VERSION_MINOR" and
  "CMAKE_PROJECT_VERSION_PATCH" to initialize corresponding CPack
  variables.

* "cpack(1)" gained basic support for NuGet. See the "CPackNuGet"
  module.


Other
-----

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

* The "Compile Features" functionality is now aware of the
  availability of C features in MSVC since VS 2010.

* The "Compile Features" functionality is now aware of C language
  standards supported by Texas Instruments C compilers.


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

* The "Visual Studio 8 2005" generator has been removed.

* CMake no longer produces "<tgt>_LIB_DEPENDS" cache entries for
  library targets.  See policy "CMP0073".


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

* Include flags for directories marked as "SYSTEM" are now moved
  after non-system directories.  The "-isystem" flag does this
  automatically, so moving them explicitly to the end makes the
  behavior consistent on compilers that do not have any "-isystem"
  flag.

* Fortran dependency scanning now supports dependencies implied by
  Fortran Submodules.

* The existence and functionality of the file
  "${CMAKE_BINARY_DIR}/cmake_install.cmake" has now been documented in
  the "install()" documentation so that external packaging software
  can take advantage of CPack-style component installs.

* The "CheckIncludeFile" module "check_include_file" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "CheckIncludeFileCXX" module "check_include_file_cxx" macro
  learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "CheckIncludeFiles" module "check_include_files" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "cmake(1)" "-E copy_directory" tool now fails when the source
  directory does not exist.  Previously it succeeded by creating an
  empty destination directory.

* The "UseSWIG" module "swig_add_library()" command (and legacy
  "swig_add_module" command) now set the prefix of Java modules to
  """" for MINGW, MSYS, and CYGWIN environments.

----------------------------------------------------------------------------
Changes made since CMake 3.12.0-rc2:

Adriaan de Groot (1):
      FindLua: Set CMP0012 to NEW for the revised search code

Andrew Fuller (1):
      CPack/Deb: Restore setting of root as the owner of files

Brad King (2):
      Revert "target_link_libraries: Allow use with targets in other
directories"
      CMake 3.12.0-rc3

Craig Scott (1):
      Help: Clarify ...<max> behavior for policy-related commands

Marc Chevrier (2):
      UseSWIG: reintroduce legacy target name management
      Help: fix add_compile_definitions() documentation

Robert Dailey (1):
      VS: Only link cs files when they're not in binary dir

From eike at sf-mail.de  Mon Jul  9 12:30:04 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 09 Jul 2018 18:30:04 +0200
Subject: [CMake] find_package: keyword REQUIRED ignored
In-Reply-To: <8572c1668e504e72a1494033a385a147@iesve.com>
References: <005b95d8-0cc0-89f2-4222-0150984ea181@gmail.com>
 <8572c1668e504e72a1494033a385a147@iesve.com>
Message-ID: <5937432.WyeI6IyGuR@daneel.sf-tec.de>

Am Montag, 9. Juli 2018, 09:45:25 CEST schrieb Mark De Wit:
> I thought that the find script itself was responsible for checking the
> required flag?

That's what find_package_handle_standard_args() does.

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/20180709/fe89813c/attachment.sig>

From Alan.W.Irwin1234 at gmail.com  Mon Jul  9 13:07:48 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Mon, 9 Jul 2018 10:07:48 -0700 (PDT)
Subject: [CMake] specifying path for license file for commercial
 compiler?
In-Reply-To: <1C78E55C-6E8A-499F-8885-A690DFABA280@nasa.gov>
References: <9A6F8353-4B83-436C-9A46-2DBE9CD786B6@nasa.gov>
 <nycvar.QRO.7.76.1807082041450.9795@zreyva.zlyna.ubzr>
 <1C78E55C-6E8A-499F-8885-A690DFABA280@nasa.gov>
Message-ID: <nycvar.QRO.7.76.1807090823460.9795@zreyva.zlyna.ubzr>

On 2018-07-09 12:48-0000 Clune, Thomas L. (GSFC-6101) wrote:

[...]
> Based upon conversations with colleagues in other institutions, the
   most frustrating compiler is always the one you don?t do your
   development with.  Because of my clients, I mostly start with Intel
   and then get frustrated when a design discovers defects in gfortran.
   But others that primarily work with gfortran say the same about
   Intel.  My conclusion as that we subconsciously develop a coding
   style this is (mostly) robust within our native environment.

I agree with your overall conclusion (and many other interesting
points you made which I didn't quote).

> When the situation permits, I mostly develop with the NAG fortran
   compiler.  The generated code is not particularly fast, but the
   compiler is very strict and very robust.

I have no experience with that compiler myself, but a colleague has
taken advantage of its well-known strictness to make sure the Fortran
binding of the PLplot C library (which is implemented using the
iso_c_binding module) is fully compliant with the Fortran 2003
standard with run-time results that pass our Fortran tests (which
demand that our standard set of 33 plot examples written in Fortran
2003 give identical results to the corresponding C examples).  He has
also achieved similar testing success with ifort, and I have done the
same with gfortran.  So with PLplot, those three Fortran compilers
give perfect test results and although we haven't yet had the time to
look at other Fortran compilers presumably most of them will also
produce perfect test results (since most Fortran vendors report they
have correctly implemented all parts of the iso_c_binding module).

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From fifteenknots505 at gmail.com  Mon Jul  9 14:09:32 2018
From: fifteenknots505 at gmail.com (Martin Weber)
Date: Mon, 09 Jul 2018 20:09:32 +0200
Subject: [CMake] Eclipse CDT4 - Unix Makefiles / Ninja Generator
In-Reply-To: <5554997.4vZYSjESvk@linux-l7nd>
References: <3040101.FW4RXYlS4o@linux> <5554997.4vZYSjESvk@linux-l7nd>
Message-ID: <2025104.oWqsmt2stG@linux>

Am Sonntag, 8. Juli 2018, 23:17:27 CEST schrieb Alexander Neundorf:
> On 2018 M07 7, Sat 19:09:18 CEST Martin Weber wrote:
> > Hi all,
> > 
> > FYI, according to this [1], those generators do no longer work with the
> > new
> > core build introduced in CDT 9.5.
> > 
> > Martin
> > 
> > [1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg33066.html
> 
> do you know whether the new build system of CDT is documented somewhere ?
> I found this, but this is far from enough.
> http://www.eclipse.org/org/langsymp/CDT%20Managed%20Build%20System.pdf

All I found is here <http://dev.eclipse.org/mhonarc/lists/cdt-dev/
msg32845.html>

I also browsed through the new code, but the javadocs are close to non-
existent.

If the cmake devs plan to remove the CDT4 generator, I think that would be OK. 
In 2013, I started an eclipse plugin that automatically runs cmake from 
Eclipse. It's also in the marketplace, so cmake users have an escape.

Martin

-- 
Cd wrttn wtht vwls s mch trsr.



From razvan.maris10 at yahoo.com  Mon Jul  9 14:21:14 2018
From: razvan.maris10 at yahoo.com (Razvan Maris)
Date: Mon, 9 Jul 2018 18:21:14 +0000 (UTC)
Subject: [CMake] When is the TARGET_NAME generator expression necessary?
References: <238218157.1514409.1531160474030.ref@mail.yahoo.com>
Message-ID: <238218157.1514409.1531160474030@mail.yahoo.com>

Hello,

I was reading the CMake documentation regarding generator expressions, and I found the following:

"$<TARGET_NAME:...>
Marks ... as being the name of a target. This is required if exporting targets to multiple dependent export sets. The ... must be a literal name of a target- it may not contain generator expressions."

>From that I understand that if some targets from an export set depend on other targets from other export set, the dependencies should be specified using $<TARGET_NAME:...> instead of the targets' names.
I found the thread (this message specifically:?https://www.mail-archive.com/cmake-developers at cmake.org/msg05498.html)?that is responsible for the introduction of the TARGET_NAME generator expression, however I cannot find an example for its use.

I believe it has something to do with adding the correct namespace to the "required library".

I tried an example of dependent export sets in which I do not use $<TARGET_NAME:...>, I even use the target's name inside another generator expression, but no error is generated and the output files contain the correct "imported" targets (with the correct namespaces):

"project(target_name)
add_library(a a.cpp)
add_library(b b.cpp)

target_link_libraries(b $<$<EQUAL:1,1>:a>)


export(TARGETS
? ? ? ?a
? ? ? ?NAMESPACE foo_
? ? ? ?FILE a_config.cmake
)
?
export(TARGETS
? ? ? ?b
? ? ? ?NAMESPACE bar_
? ? ? ?FILE b_config.cmake
)"

When are we required to use the TARGET_NAME generator expression?


Thank you,
Razvan

From francis.giraldeau at gmail.com  Mon Jul  9 14:37:22 2018
From: francis.giraldeau at gmail.com (Francis Giraldeau)
Date: Mon, 9 Jul 2018 14:37:22 -0400
Subject: [CMake] How to specify library dir for imported interface?
In-Reply-To: <CAHKTGrd1i2F703ZFE-K_kZHAE-GihujXoa_fm_B4vzB3M5Cq6w@mail.gmail.com>
References: <CAC6yHM5ELZ6VoAwiqu0vFPTOPVK5zV8QYGHOuJg1fu65rC-aTw@mail.gmail.com>
 <CAHKTGrd1i2F703ZFE-K_kZHAE-GihujXoa_fm_B4vzB3M5Cq6w@mail.gmail.com>
Message-ID: <CAC6yHM6SGPtz3c_XRME4OU-iLdc5VJsOSu8sGuky5kc3JavoVQ@mail.gmail.com>

Le mer. 4 juil. 2018 ? 10:43, Marc CHEVRIER <marc.chevrier at gmail.com> a
?crit :

> Next version of CMake (3.13) will supports properties LINK_OPTIONS as well
> as INTERFACE_LINK_OPTIONS.
>

Interesting, will it fix the issue with pkg-config? When installed in a
non-standard directory, pkg-config will return the library dir. Here is an
example with libsodium:

$ PKG_CONFIG_PATH=/tmp/bidon/lib/pkgconfig pkg-config --libs libsodium
-L/tmp/bidon/lib -lsodium

At first, the property INTERFACE_LINK_DIRECTORIES would make sens. Would
there be some drawbacks to specify link directories for imported targets?

Cheers,

Francis
-- 
Francis Giraldeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180709/01082c7f/attachment.html>

From Alan.W.Irwin1234 at gmail.com  Mon Jul  9 15:14:42 2018
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Mon, 9 Jul 2018 12:14:42 -0700 (PDT)
Subject: [CMake] groups of ascii nul ('\0) characters inserted into make
 output but this just occurs for parallel builds (SOLVED)
In-Reply-To: <CAEbDRx1Q1cYOgKA+-Ehb4FUJKWf3YYa0aP2-nLiP4rAFzTKdPA@mail.gmail.com>
References: <nycvar.QRO.7.76.1807081302570.9795@zreyva.zlyna.ubzr>
 <CAEbDRx1Q1cYOgKA+-Ehb4FUJKWf3YYa0aP2-nLiP4rAFzTKdPA@mail.gmail.com>
Message-ID: <nycvar.QRO.7.76.1807091021490.9795@zreyva.zlyna.ubzr>

On 2018-07-09 09:10+0200 Nils Gladitz wrote:

> On Sun, Jul 8, 2018 at 11:00 PM Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
> wrote:
>
>> My parallel builds on my Linux OS (currently Debian Buster, but this
>> also happened for Debian Jessie so this is a long-standing problem)
>> have ascii null ('\0) characters inserted in the output while the
>> corresponding non-parallel build does not have those extra characters.
>>
>
> I narrowed it down with Ninja which buffers command outputs in parallel
> builds which makes it easier to match output to specific commands.
> Alternatively I think CTest launchers might have helped with this too.
> CMake uses them to redirect build command outputs to distinct files for
> CTest submissions.
>
> I see null bytes coming from the "cat test.error" in the script file
> generated from
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/plplot_test/test_c.sh.in
>
> If this only shows up in parallel builds perhaps multiple processes are
> reading/writing the same test.error file in parallel?
> Haven't looked closer than that. You probably know better where to look
> from there.

Hi Nils:

Many thanks for going "above and beyond" with this issue.  Indeed,
many of the language test scripts in plplot_test write to "test.error"
and then output it after the command has been run with "cat
test.error".  Many of those test.error files are in the same directory
so this constitutes a many-way name clash and therefore a set of clear race
condition for parallel builds that has existed for at least the last
decade in PLplot.  UGH!

I fixed those nameclashes with PLplot commit a4bada004 (see that log
message for additional commentary), and the extra '\0' characters in
parallel output are now gone.  I have no idea why the symptom of the
race is the extra '\0' characters, but I am just happy to have these
symptoms as well as the race conditions fixed!

Thanks for your key help in leading me to the solution of
this long-standing PLplot build-system issue.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From jason.heeris at gmail.com  Mon Jul  9 18:49:34 2018
From: jason.heeris at gmail.com (Jason Heeris)
Date: Tue, 10 Jul 2018 08:49:34 +1000
Subject: [CMake] Cannot prevent import library from being created with VS
 generator
Message-ID: <CA+Zd3FewZG_iVmEby7zSqdjEkuq0ibWENLqtO6xsvpWkGsNsZA@mail.gmail.com>

I'm using CMake 3.12-rc1 on Windows 10. I have the following
`CMakeLists.txt`:

cmake_minimum_required(VERSION 3.8)
project(cmake_test)
unset(CMAKE_IMPORT_LIBRARY_SUFFIX)
add_library(main MODULE "main.c")

The generator is Visual Studio 15 2017.

I would like to suppress the "/IMPLIB" argument created for the "main"
library. In my real project, I have static and shared libraries named the
same. This works fine, because they have different extensions (lib vs dll),
but a problem arises when the linker tries to create an import library for
"something.dll" named "something.lib", while also trying to link against a
static library named "something.lib".

The import library is not needed though; in CMake terminology the DLL is a
"module" ie. loaded via DllOpen(). The documentation suggested that calling
"add_library()" with "MODULE" was what I needed here. Unfortunately the
resulting VS project still contains an import library flag for the linker.

A Stackoverflow answer[1] suggested unsetting "CMAKE_IMPORT_LIBRARY_SUFFIX"
because the source indicates[2] this will stop the flag from appearing. But
all this seems to do is drop the filename from the generated project; it
still contains this now-incorrect flag that references a directory instead
of a full path:

<ImportLibrary>C:/Users/heerij/Code/cmake-ex-2/build/Debug/</ImportLibrary>

How do I prevent the import library creation?

- Jason

  [1]
https://stackoverflow.com/questions/34575066/how-to-prevent-cmake-from-issuing-implib
  [2]
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmComputeLinkInformation.cxx#L271
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180710/9c288ff9/attachment.html>

From calebwherry at gmail.com  Mon Jul  9 19:57:31 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Mon, 9 Jul 2018 19:57:31 -0400
Subject: [CMake] Cannot prevent import library from being created with
 VS generator
In-Reply-To: <CA+Zd3FewZG_iVmEby7zSqdjEkuq0ibWENLqtO6xsvpWkGsNsZA@mail.gmail.com>
References: <CA+Zd3FewZG_iVmEby7zSqdjEkuq0ibWENLqtO6xsvpWkGsNsZA@mail.gmail.com>
Message-ID: <CAJxY6XqzP_t2OKsn7u4JUrOWBtHGCrJWuC2KPkG-V6NgBm9Gcw@mail.gmail.com>

I?m also interested in this.

Side note 1: Things like this eventually lead me to have a post process (a
python script) on all my VS project files to ?fix? any issues like this. If
I can?t figure out a way to do something specific in a VS project, I just
add it to my post process until I eventually have time to dig in and figure
it out. For this specific issue, I just match a regex for the line and
remove it. I know this shouldn?t be neccessary but sometimes I just don?t
have the time to figure out a specific generator problem.

Side note 2: I also used this process at one point to make relocatable VS
solutions/projects. It worked quite well and is a quick way to get around
short comings in how CMake creates VS artifacts.

-Caleb

On Mon, Jul 9, 2018 at 6:49 PM Jason Heeris <jason.heeris at gmail.com> wrote:

> I'm using CMake 3.12-rc1 on Windows 10. I have the following
> `CMakeLists.txt`:
>
> cmake_minimum_required(VERSION 3.8)
> project(cmake_test)
> unset(CMAKE_IMPORT_LIBRARY_SUFFIX)
> add_library(main MODULE "main.c")
>
> The generator is Visual Studio 15 2017.
>
> I would like to suppress the "/IMPLIB" argument created for the "main"
> library. In my real project, I have static and shared libraries named the
> same. This works fine, because they have different extensions (lib vs dll),
> but a problem arises when the linker tries to create an import library for
> "something.dll" named "something.lib", while also trying to link against a
> static library named "something.lib".
>
> The import library is not needed though; in CMake terminology the DLL is a
> "module" ie. loaded via DllOpen(). The documentation suggested that calling
> "add_library()" with "MODULE" was what I needed here. Unfortunately the
> resulting VS project still contains an import library flag for the linker.
>
> A Stackoverflow answer[1] suggested unsetting
> "CMAKE_IMPORT_LIBRARY_SUFFIX" because the source indicates[2] this will
> stop the flag from appearing. But all this seems to do is drop the filename
> from the generated project; it still contains this now-incorrect flag that
> references a directory instead of a full path:
>
> <ImportLibrary>C:/Users/heerij/Code/cmake-ex-2/build/Debug/</ImportLibrary>
>
> How do I prevent the import library creation?
>
> - Jason
>
>   [1]
> https://stackoverflow.com/questions/34575066/how-to-prevent-cmake-from-issuing-implib
>   [2]
> https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmComputeLinkInformation.cxx#L271
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180709/5c6e8efe/attachment.html>

From jason.heeris at gmail.com  Mon Jul  9 20:12:02 2018
From: jason.heeris at gmail.com (Jason Heeris)
Date: Tue, 10 Jul 2018 10:12:02 +1000
Subject: [CMake] Cannot prevent import library from being created with
 VS generator
In-Reply-To: <CAJxY6XqzP_t2OKsn7u4JUrOWBtHGCrJWuC2KPkG-V6NgBm9Gcw@mail.gmail.com>
References: <CA+Zd3FewZG_iVmEby7zSqdjEkuq0ibWENLqtO6xsvpWkGsNsZA@mail.gmail.com>
 <CAJxY6XqzP_t2OKsn7u4JUrOWBtHGCrJWuC2KPkG-V6NgBm9Gcw@mail.gmail.com>
Message-ID: <CA+Zd3Ff7ucsS-sw4Dy+HcSDAKevpT7in6_aZAkoNxTiD0eboCw@mail.gmail.com>

On Tue, 10 Jul 2018 at 09:57, J. Caleb Wherry <calebwherry at gmail.com> wrote:
> Side note 1: Things like this eventually lead me to have a post process
(a python script) on all my VS project files to ?fix? any issues like this.

It might interest you to know that I've worked around it a bit by tweaking
the IMPORT_PREFIX property:

    set_target_properties(
        ${modname_dll}
        PROPERTIES
        OUTPUT_NAME
            ${module_name}
        # Required to work around the fact that we rename our shared
libraries
        # to have the same name as our static libraries, so when Visual
Studio's
        # linker tries to create an export library, it clashes with an input
        # library.
        IMPORT_PREFIX
            "import_"
    )

Cheers,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180710/70708adf/attachment-0001.html>

From ocroquette at free.fr  Tue Jul 10 03:21:50 2018
From: ocroquette at free.fr (Olivier Croquette)
Date: Tue, 10 Jul 2018 09:21:50 +0200
Subject: [CMake] Lib prefix: Windows vs. Unix/MinGW convention
Message-ID: <58f3ab0f-f24e-eb6a-8a97-e028e6d39336@free.fr>

Hello,

some projects I am working on are built using CMake and MinGW on 
Windows. It works fine, unfortunately there are come inconsistencies 
regarding the names of the generated libraries. Some are prefixed with 
"lib" like on Unix systems, some are not, like usual on Windows.

It seems that this can be controlled easily by adding the following 
lines in the top CMakeLists.txt:

if(MINGW)
 ? set(CMAKE_SHARED_LIBRARY_PREFIX "")
 ? set(CMAKE_STATIC_LIBRARY_PREFIX "")
endif()

As a CMake beginner, I still have some questions though:

1. Are there some side-effects? For instance, can it cause libraries not 
to be found when using them across projects?

2. Should I use if(WIN32) rather than if(MINGW)?

3. Why isn't CMake doing that by default? The convention of the target 
platform should prevail over the convention of the toolchain, shouldn't it?

Thanks!

Olivier



From craig.scott at crascit.com  Tue Jul 10 09:11:09 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 10 Jul 2018 23:11:09 +1000
Subject: [CMake] New CMake book released
Message-ID: <CA+dygYk-NnvXqUOtGx88kqvvn0kQb6=W-3VU-Z_7jLgcXQabjw@mail.gmail.com>

Hi all, please forgive the shameless self-promotion, but I figured this is
the right community of people to inform. ;)

I've just released a new book which aims to fill the gap for those wanting
to learn CMake and its latest best practices. Hopefully this is helpful for
those of you wanting a more structured guide or some real world advice on
using CMake in anger. I'll spare you all the rest of the spiel, you can get
all the details including a free sample chapter from the following link:

https://crascit.com/professional-cmake/

And yes, before you ask, I do use CMake to drive the build that produces
the digital copy. :P

Enjoy!

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

From sstallion at gmail.com  Tue Jul 10 09:27:00 2018
From: sstallion at gmail.com (Steven Stallion)
Date: Tue, 10 Jul 2018 08:27:00 -0500
Subject: [CMake] New CMake book released
In-Reply-To: <CA+dygYk-NnvXqUOtGx88kqvvn0kQb6=W-3VU-Z_7jLgcXQabjw@mail.gmail.com>
References: <CA+dygYk-NnvXqUOtGx88kqvvn0kQb6=W-3VU-Z_7jLgcXQabjw@mail.gmail.com>
Message-ID: <CAGGHmKGoNDDekArvV5fSH4D0paG533XmXJ6nZLZnc=BPJ18GDg@mail.gmail.com>

Nice Job! I've spent an inordinate amount of time helping folks come
up to speed on some of the darker corners of CMake the last few years
and it's great to have something to point to rather than my
hodge-podge of collected notes.

On Tue, Jul 10, 2018 at 8:11 AM, Craig Scott <craig.scott at crascit.com> wrote:
> Hi all, please forgive the shameless self-promotion, but I figured this is
> the right community of people to inform. ;)
>
> I've just released a new book which aims to fill the gap for those wanting
> to learn CMake and its latest best practices. Hopefully this is helpful for
> those of you wanting a more structured guide or some real world advice on
> using CMake in anger. I'll spare you all the rest of the spiel, you can get
> all the details including a free sample chapter from the following link:
>
> https://crascit.com/professional-cmake/
>
> And yes, before you ask, I do use CMake to drive the build that produces the
> digital copy. :P
>
> Enjoy!
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>

From w.clodius at icloud.com  Tue Jul 10 13:39:26 2018
From: w.clodius at icloud.com (William Clodius)
Date: Tue, 10 Jul 2018 11:39:26 -0600
Subject: [CMake] Make clean infelicity for Fortran submodules
Message-ID: <BACA4E0A-08BE-4A03-9778-85A25E08562E@icloud.com>

CMAKE 3.12.0-rc3 claims to be able to handle Fortran submodules, and my limited testing of it suggest that it is doing an adequate job. One minor ?feature? however is that make clean with the generated Makefile does not remove generated *.smod files. While their presence does not affect subsequent compilations, i.e., they are replaced if the corresponding *.mod files are absent, it would.d be nice if they were removed to reduce file storage.

From w.clodius at icloud.com  Tue Jul 10 14:47:10 2018
From: w.clodius at icloud.com (William Clodius)
Date: Tue, 10 Jul 2018 12:47:10 -0600
Subject: [CMake] CMAKE fortran mod directories search paths awkwardness
Message-ID: <0EDCFD43-7E48-40C6-8745-2FFA6F08EDA2@icloud.com>

I have had a boggle involving cmake that took several days to resolve. I had originally testing Fortran code with modules (and submodules) using gfortran exclusively. This used a directory structure roughly of the form

?/source/CMakeCache.txt
?/source/CMakeFiles/*
?/source/CmakeLists.txt
?/source/...
?/source/mod_dir/*
?/source/?

Where mod_dir was intended to be there depository for the *.mod and *.smod files. I then decided  to also test with the fort compiler and went to the directory structure

?/source/CmakeLists.txt
...
?/source/gfortran_test/CMakeCache.txt
?/source/gfortran_test/CMakeFiles/*
?/source/gfortran_test/?
?/source/gfortran_test/mod_dir/*
?/source/gfortran_test/?
?/source...
?/source/ifort_test/CMakeCache.txt
?/source/ifort_test/CMakeFiles/*
?/source/ifort_test/?
?/source/ifort_test/mod_dir/*
?/source/ifort_test/?
?/source...
?/source/mod_dir/*
?
 where ?/source/gfortran_test/mod_dir/ and ?/source/ifort_test/mod_dir/ were intended to be the repositories for the *.mod and *.smod files when the source code in ?/source is compiled using gfortran and ifort, respectively. Note that I failed to delete ?/source/mod_dir and its files in going to this structure. 

This structure initially worked with no problems. I was able to compile and execute code with both gfortran and ifort. Then working in ifort I added an overloaded function in one of my modules. When I went to testing with gfortran in ?/source/gfortran_test/, however, compilation would stop claiming that the new overloaded function did not have an explicit interface. I was finally able to fix the problem by eliminating the ?/source/mod_dir and its associated files. As near as I can tell the Makefile generated by make in the ?/source/gfortran_test/ directory was telling gfortran to write its *.mod and *.smod files to ?/source/gfortran_test/mod_dir/ and applying clean to that directory, but having ?/source/mod_dir/ as one of the directories on its search path (and apparently the default directory searched for *.mod files) and NOT applying make clean to that directory. As a result gfortran was finding older *.mod and *.smod files in ?/source/mod_dir/ that did not define the new overloaded function, and assumed that those files were the proper files to use for the explicit interfaces. I don?t know if ifort was also searching that directory, but not using the *.mod and *.smod files as they did not have the expected ifort structure.




From robert.maynard at kitware.com  Tue Jul 10 17:26:38 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 10 Jul 2018 17:26:38 -0400
Subject: [CMake] Lib prefix: Windows vs. Unix/MinGW convention
In-Reply-To: <58f3ab0f-f24e-eb6a-8a97-e028e6d39336@free.fr>
References: <58f3ab0f-f24e-eb6a-8a97-e028e6d39336@free.fr>
Message-ID: <CAFzjYVpUEC4E_VgcjqOy-2UPU3m_Hj5bOjywNPStK=06SEKbEA@mail.gmail.com>

>Why isn't CMake doing that by default? The convention of the target
platform should prevail over the convention of the toolchain, shouldn't it?'

CMake considers the target platform to be composed of the OS, and the
compilation toolchain. Therefore MINGW uses the 'lib' prefix.

> 2. Should I use if(WIN32) rather than if(MINGW)?

No if you are using a Microsoft compiler/toolchain than the prefix is
already empty.

On Tue, Jul 10, 2018 at 3:27 AM Olivier Croquette <ocroquette at free.fr>
wrote:

> Hello,
>
> some projects I am working on are built using CMake and MinGW on
> Windows. It works fine, unfortunately there are come inconsistencies
> regarding the names of the generated libraries. Some are prefixed with
> "lib" like on Unix systems, some are not, like usual on Windows.
>
> It seems that this can be controlled easily by adding the following
> lines in the top CMakeLists.txt:
>
> if(MINGW)
>    set(CMAKE_SHARED_LIBRARY_PREFIX "")
>    set(CMAKE_STATIC_LIBRARY_PREFIX "")
> endif()
>
> As a CMake beginner, I still have some questions though:
>
> 1. Are there some side-effects? For instance, can it cause libraries not
> to be found when using them across projects?
>
> 2. Should I use if(WIN32) rather than if(MINGW)?
>
> 3. Why isn't CMake doing that by default? The convention of the target
> platform should prevail over the convention of the toolchain, shouldn't it?
>
> Thanks!
>
> Olivier
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180710/019c7758/attachment.html>

From alfred at huji.fr  Wed Jul 11 04:40:04 2018
From: alfred at huji.fr (Alfred Sawaya)
Date: Wed, 11 Jul 2018 10:40:04 +0200
Subject: [CMake] New CMake book released
In-Reply-To: <CA+dygYk-NnvXqUOtGx88kqvvn0kQb6=W-3VU-Z_7jLgcXQabjw@mail.gmail.com>
Message-ID: <4mc1hf8otogi6g742ceisori.1531298404723@huji.fr>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180711/960c7cee/attachment.html>

From matteo.settenvini at here.com  Wed Jul 11 08:54:09 2018
From: matteo.settenvini at here.com (Settenvini, Matteo)
Date: Wed, 11 Jul 2018 12:54:09 +0000
Subject: [CMake] Cannot import a project twice when cross compiling (as
 host-tool and for the target arch)
Message-ID: <AM0PR04MB40501CFC93113DF61E6A12C1825A0@AM0PR04MB4050.eurprd04.prod.outlook.com>

Dear all,

I have the following problem which I don't know how to best solve.
Any help is appreciated.

============== Use Case ==============

Consider the following use case:

* We are cross-compiling.
* A certain project A depends on project B in two different ways:
  - it uses an executable target from B to generate some files, e.g. a compiler.
  - one of its libraries links against a library of B.

We would like to be able to do (not possible with CMake at the moment):


  find_package(B REQUIRED)
  # use B::lib normally. When crosscompiling, it will be the one compiled for the target.

  find_package(B REQUIRED NO_CMAKE_FIND_ROOT_PATH)
  # use B::exe knowing that it will always run from the host system.


This is for instance a use case we have for flatbuffers / protobuf.

IMPORTED and ALIAS targets should not be global, or it should be
possible to override them. Or else, it should be possible to
dynamically specify a namespace when importing targets through
find_package().

I opened a bug at https://gitlab.kitware.com/cmake/cmake/issues/18169,
but it got closed as there are no plans to change the way CMake works.

The issue contains also a test case, if you'd like to try it out.

============== Problem ==============

The user cannot import a project twice to get the appropriate targets
when cross-compiling: once for the host architecture and once for the
target architecture.

Right now, the user needs to manually use e.g. find_program() instead
of relying on installed locations, which can be annoying if the
binaries are installed outside the environment PATH. This can be
worked around, but we would like to use targets in place of
find_program() or find_library() calls.

The problem is much more apparent in big superbuilds where you have
hundreds of projects brought together in one build and no control over
components outside your own. It is too hard to ensure a stable
configuration order (so that find_package() is always called for the
host version before the target version, or vice-versa).

============== Help needed ==============

How would you solve the issue, so that different targets are available
for both the version built for the host and target architectures?

Note that sometimes these external projects are not under our control,
and they come directly from upstream as git submodules. So we would
like to touch them as little as possible.

Bests,
Matteo Settenvini

From patrick.boettcher at posteo.de  Wed Jul 11 11:39:07 2018
From: patrick.boettcher at posteo.de (Patrick Boettcher)
Date: Wed, 11 Jul 2018 17:39:07 +0200
Subject: [CMake] .def files since CMake 3.10 in Linux
In-Reply-To: <20180702120816.30ba4e49@yaise-pc1>
References: <20180702120816.30ba4e49@yaise-pc1>
Message-ID: <20180711173907.0d81cb4b@posteo.de>

On Mon, 2 Jul 2018 12:08:16 +0200
Patrick Boettcher <patrick.boettcher at posteo.de> wrote:

> Hi,
> 
> I (and someone else) stumbled upon a problem when using the Azure
> IOTHUB SDK for C on a Linux platform using cmake 3.10+:
> 
> https://github.com/Azure/azure-iot-sdk-c/issues/505
> 
> The problem seems to be triggered by having two .def-files as
> add_library()-source-files.
> 
> During the build cmake generates a command which does:
> 
>   cmake -E __create_def
> 
> This fails as unknown to cmake.
> 
> Is this a cmake-bug or is Azure using .def-files the wrong way?
> 
> A quick additional test show that the problem is coming from having
> 2 .def-files as sources. Having just one is OK.

The issue is no more present with CMake 3.12.0-rc1. It seems to be
fixed with

  https://gitlab.kitware.com/cmake/cmake/commit/1ac042aa67c0e0ab531cd38977cb2f65fd96ed4b

. This bug-fix is not included in 3.11.3 .

--
Patrick.

From espakm at gmail.com  Wed Jul 11 12:22:01 2018
From: espakm at gmail.com (Miklos Espak)
Date: Wed, 11 Jul 2018 17:22:01 +0100
Subject: [CMake] include dirs from EPs not added to project for in-source
 builds on windows
Message-ID: <CAOVq=oNgj87OvvQUaFyj1RDS1n=fmMZu7U4-8mJbNUXqyDcCug@mail.gmail.com>

Hi,

I have a "superbuild" project which builds two external projects (EP) and
then my actual project. It builds fine on linux and mac. On windows,
however, the build fails if the build directory is *inside* the source
folder.

Let's say e.g. that the sources are in "c:/src/myproject". If the build is
in "c:/src/myproject-build", it succeeds, but if it is in
"c:/src/myproject/build", it fails. (It took me a while until I discovered
the connection between the failures and the build dir path.)

With the build dir inside the source dir, I get compilation error because
header files are not found. In fact, if I open the "*.vcxproj" file of the
same target in the two types of builds, the
"<AdditionalIncludeDirectories>" elements are different. The include dirs
of the EPs are missing from it in the "in-source" build and they are there
in the "out-source" build.

This is how far I got with my debugging, and I'm not sure how to go on.

Unfortunately, I'd need to keep the build folder inside the sources because
the GitLab CI runners assume this.

Any help would be much appreciated.

I used CMake 3.11.4 and 3.12.0RC3.

Kind regards,
Miklos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180711/261d4ea4/attachment.html>

From espakm at gmail.com  Wed Jul 11 13:33:36 2018
From: espakm at gmail.com (Miklos Espak)
Date: Wed, 11 Jul 2018 18:33:36 +0100
Subject: [CMake] include dirs from EPs not added to project for
 in-source builds on windows
In-Reply-To: <CAOVq=oNgj87OvvQUaFyj1RDS1n=fmMZu7U4-8mJbNUXqyDcCug@mail.gmail.com>
References: <CAOVq=oNgj87OvvQUaFyj1RDS1n=fmMZu7U4-8mJbNUXqyDcCug@mail.gmail.com>
Message-ID: <CAOVq=oNZFFKneVAhEtQfxZfMgSdS_g=TJt+oerynsUbeGJ9xFg@mail.gmail.com>

G

On Wed, 11 Jul 2018 at 17:22, Miklos Espak <espakm at gmail.com> wrote:

> Hi,
>
> I have a "superbuild" project which builds two external projects (EP) and
> then my actual project. It builds fine on linux and mac. On windows,
> however, the build fails if the build directory is *inside* the source
> folder.
>
> Let's say e.g. that the sources are in "c:/src/myproject". If the build is
> in "c:/src/myproject-build", it succeeds, but if it is in
> "c:/src/myproject/build", it fails. (It took me a while until I discovered
> the connection between the failures and the build dir path.)
>
> With the build dir inside the source dir, I get compilation error because
> header files are not found. In fact, if I open the "*.vcxproj" file of the
> same target in the two types of builds, the
> "<AdditionalIncludeDirectories>" elements are different. The include dirs
> of the EPs are missing from it in the "in-source" build and they are there
> in the "out-source" build.
>
> This is how far I got with my debugging, and I'm not sure how to go on.
>
> Unfortunately, I'd need to keep the build folder inside the sources
> because the GitLab CI runners assume this.
>
> Any help would be much appreciated.
>
> I used CMake 3.11.4 and 3.12.0RC3.
>
> Kind regards,
> Miklos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180711/d15d3f22/attachment.html>

From espakm at gmail.com  Wed Jul 11 13:34:43 2018
From: espakm at gmail.com (Miklos Espak)
Date: Wed, 11 Jul 2018 18:34:43 +0100
Subject: [CMake] include dirs from EPs not added to project for
 in-source builds on windows
In-Reply-To: <CAOVq=oNgj87OvvQUaFyj1RDS1n=fmMZu7U4-8mJbNUXqyDcCug@mail.gmail.com>
References: <CAOVq=oNgj87OvvQUaFyj1RDS1n=fmMZu7U4-8mJbNUXqyDcCug@mail.gmail.com>
Message-ID: <CAOVq=oM2r5YNWZRBVU6Owd5S72sCUztqJMYLeUWL7PKS-UwsVg@mail.gmail.com>

It was this generator: "Visual Studio 15 2017 Win64"

On Wed, 11 Jul 2018 at 17:22, Miklos Espak <espakm at gmail.com> wrote:

> Hi,
>
> I have a "superbuild" project which builds two external projects (EP) and
> then my actual project. It builds fine on linux and mac. On windows,
> however, the build fails if the build directory is *inside* the source
> folder.
>
> Let's say e.g. that the sources are in "c:/src/myproject". If the build is
> in "c:/src/myproject-build", it succeeds, but if it is in
> "c:/src/myproject/build", it fails. (It took me a while until I discovered
> the connection between the failures and the build dir path.)
>
> With the build dir inside the source dir, I get compilation error because
> header files are not found. In fact, if I open the "*.vcxproj" file of the
> same target in the two types of builds, the
> "<AdditionalIncludeDirectories>" elements are different. The include dirs
> of the EPs are missing from it in the "in-source" build and they are there
> in the "out-source" build.
>
> This is how far I got with my debugging, and I'm not sure how to go on.
>
> Unfortunately, I'd need to keep the build folder inside the sources
> because the GitLab CI runners assume this.
>
> Any help would be much appreciated.
>
> I used CMake 3.11.4 and 3.12.0RC3.
>
> Kind regards,
> Miklos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180711/fe15e1f8/attachment.html>

From craig.scott at crascit.com  Wed Jul 11 18:00:18 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 12 Jul 2018 08:00:18 +1000
Subject: [CMake] Cannot import a project twice when cross compiling (as
 host-tool and for the target arch)
In-Reply-To: <AM0PR04MB40501CFC93113DF61E6A12C1825A0@AM0PR04MB4050.eurprd04.prod.outlook.com>
References: <AM0PR04MB40501CFC93113DF61E6A12C1825A0@AM0PR04MB4050.eurprd04.prod.outlook.com>
Message-ID: <CA+dygY=J8=SdMbPiqXk1yKEEDbToJAeyWsD-U+h_0Nr7cB21LQ@mail.gmail.com>

Not quite sure if it fits your use case, but we use a technique at work
basically as described in the following:

https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run

Your case sounds more complicated, but maybe the above technique might help
if you can organise things that way.



On Wed, Jul 11, 2018 at 10:54 PM, Settenvini, Matteo <
matteo.settenvini at here.com> wrote:

> Dear all,
>
> I have the following problem which I don't know how to best solve.
> Any help is appreciated.
>
> ============== Use Case ==============
>
> Consider the following use case:
>
> * We are cross-compiling.
> * A certain project A depends on project B in two different ways:
>   - it uses an executable target from B to generate some files, e.g. a
> compiler.
>   - one of its libraries links against a library of B.
>
> We would like to be able to do (not possible with CMake at the moment):
>
>
>   find_package(B REQUIRED)
>   # use B::lib normally. When crosscompiling, it will be the one compiled
> for the target.
>
>   find_package(B REQUIRED NO_CMAKE_FIND_ROOT_PATH)
>   # use B::exe knowing that it will always run from the host system.
>
>
> This is for instance a use case we have for flatbuffers / protobuf.
>
> IMPORTED and ALIAS targets should not be global, or it should be
> possible to override them. Or else, it should be possible to
> dynamically specify a namespace when importing targets through
> find_package().
>
> I opened a bug at https://gitlab.kitware.com/cmake/cmake/issues/18169,
> but it got closed as there are no plans to change the way CMake works.
>
> The issue contains also a test case, if you'd like to try it out.
>
> ============== Problem ==============
>
> The user cannot import a project twice to get the appropriate targets
> when cross-compiling: once for the host architecture and once for the
> target architecture.
>
> Right now, the user needs to manually use e.g. find_program() instead
> of relying on installed locations, which can be annoying if the
> binaries are installed outside the environment PATH. This can be
> worked around, but we would like to use targets in place of
> find_program() or find_library() calls.
>
> The problem is much more apparent in big superbuilds where you have
> hundreds of projects brought together in one build and no control over
> components outside your own. It is too hard to ensure a stable
> configuration order (so that find_package() is always called for the
> host version before the target version, or vice-versa).
>
> ============== Help needed ==============
>
> How would you solve the issue, so that different targets are available
> for both the version built for the host and target architectures?
>
> Note that sometimes these external projects are not under our control,
> and they come directly from upstream as git submodules. So we would
> like to touch them as little as possible.
>
> Bests,
> Matteo Settenvini
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180712/eb38aa4d/attachment-0001.html>

From m.tmatma at gmail.com  Wed Jul 11 18:57:00 2018
From: m.tmatma at gmail.com (masaru tsuchiyama)
Date: Thu, 12 Jul 2018 07:57:00 +0900
Subject: [CMake] New CMake book released
In-Reply-To: <CA+dygYk-NnvXqUOtGx88kqvvn0kQb6=W-3VU-Z_7jLgcXQabjw@mail.gmail.com>
References: <CA+dygYk-NnvXqUOtGx88kqvvn0kQb6=W-3VU-Z_7jLgcXQabjw@mail.gmail.com>
Message-ID: <CAKQP9eeaLQZf0=i30Lv=u1iEwiy3NASvdBh7XpB5wyztcua_Tw@mail.gmail.com>

Hello Craig

Will it be available at https://www.safaribooksonline.com/ ?
If you have no plan to support it, could you consider to do?

Regards.
Masaru.




2018?7?10?(?) 22:11 Craig Scott <craig.scott at crascit.com>:

> Hi all, please forgive the shameless self-promotion, but I figured this is
> the right community of people to inform. ;)
>
> I've just released a new book which aims to fill the gap for those wanting
> to learn CMake and its latest best practices. Hopefully this is helpful for
> those of you wanting a more structured guide or some real world advice on
> using CMake in anger. I'll spare you all the rest of the spiel, you can get
> all the details including a free sample chapter from the following link:
>
> https://crascit.com/professional-cmake/
>
> And yes, before you ask, I do use CMake to drive the build that produces
> the digital copy. :P
>
> Enjoy!
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180712/43bfda78/attachment.html>

From ocroquette at free.fr  Thu Jul 12 01:53:21 2018
From: ocroquette at free.fr (Olivier Croquette)
Date: Thu, 12 Jul 2018 07:53:21 +0200
Subject: [CMake] Concurrency issues with copy_if_different
Message-ID: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr>

Hello,

in one of our projects, we use copy_if_different to copy some DLLs 
required by the runtime. It's called as post-build action. The problem 
is that several targets want to copy the same DLLs, and when using 
parallelized builds, the different "cmake -E copy_if_different" can 
conflict, leading the whole build to fail.

I see two options to fix this:

1. don't use copy_if_different, but a custom tool that can deal with the 
concurrency

2. instead of adding post-build actions to different targets, fill up a 
list containing all the files required, and add a single post-build 
action to a single target that copies all the required files in one go

What do you think?

Cheers
Olivier



From gavin.wheeler at kcl.ac.uk  Thu Jul 12 06:10:16 2018
From: gavin.wheeler at kcl.ac.uk (Wheeler, Gavin)
Date: Thu, 12 Jul 2018 10:10:16 +0000
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
Message-ID: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>

Hello! First the short version...

Can anyone give me a set of instructions to download, build and setup the latest Boost (currently 1.67) on Windows 10 for VS 2017 64bit such that the following will work...

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

Including...

- Steps to follow when building and installing Boost
- What environment variables to set and what to set them to, e.g. boost, boost library, boost include directories
- What to set in the CMake file so that Boost will be correctly included

I ask about building Boost as well as CMake because it seems to me that unless Boost is built in a way that matches CMake expectations it just won't work.

Some background...

I've inherited a project with the above in, along with depndencies on ITK, VTK and zlib - all of which I have set up in CMake OK. However, Boost appears to be immune to working with CMake. There are various suggestions on the web, but nothing consistent, and nothing I've found whcih will work.

I've spent 2 days building Boost (this isn't solely due to CMake, the Boost build instructions are all over the place and their latest installer contains a trojan according to Windows defender) and configuring CMake in various ways, getting frustrated setting various environmental variables, and the nebulous target that is a Boost source install.

I can fix this by manually setting all of the library paths and doing some fixing up in the resultant project files, but I shouldn't really have to.

Surely it shouldn't be this difficult! Hopefully if there is a clear set of instructions from start to finish it will save others future anguish.

For building Boost I ended up using b2 and the following steps install (based on https://www.boost.org/doc/libs/1_67_0/more/getting_started/windows.html) and having tried following the instructions to the letter I ended up with...

- Download Boost, e.g. from https://dl.bintray.com/boostorg/release/1.67.0/source/boost_1_67_0.7z
- Extract to e.g. C:\thirdparty\boost\boost_1_67_0
- Build the bootstrapper, as per section 5.2.1 in https://www.boost.org/doc/libs/1_67_0/more/getting_started/windows.html
- Build the binaries, simlar to section 5.2.2 in the above, but using
    - b2 --build-dir=C:\thirdparty\boost-install\boost_1_67_0 toolset=msvc --build-type=complete install
- Why the change?
    - Building the Boost build tools didn't seem to affect the building of the install
    - The inital install command in their instructions didn't seem to actually install the headers and libs
    - Using stage only seems to collect the lib files together, not the headers
    - So I end up with a libs folder and an include folder

I then try to set the following environment variables (as system ones, rather than as user ones)

- BOOST_ROOT - to the boost folder of the downloaded and extracted boost
- BOOST_INCLUDEDIR - to the include folder of the installed boost
- BOOST_LIBRARYDIR - the the lib folder of the installed boost

As well as lots of other directories which seemed like they might work.

Then in the CMake (based upon suggestions from the web) I've tried things like...

set(Boost_USE_STATIC_LIBS        ON)
set(Boost_USE_MULTITHREADED      ON)
set(Boost_USE_STATIC_RUNTIME    OFF)

...and...

SET(Boost_ADDITIONAL_VERSIONS "1.67" "1.67.0")

...and...

set (Boost_DETAILED_FAILURE_MSG ON)
set (BOOST_DEBUG ON)

... to no avail






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180712/80a6dd16/attachment.html>

From alaitsev at gmail.com  Thu Jul 12 06:29:25 2018
From: alaitsev at gmail.com (Innokentiy Alaytsev)
Date: Thu, 12 Jul 2018 03:29:25 -0700 (MST)
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
Message-ID: <1531391365828-0.post@n2.nabble.com>

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

From robert.maynard at kitware.com  Thu Jul 12 08:37:00 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 12 Jul 2018 08:37:00 -0400
Subject: [CMake] Concurrency issues with copy_if_different
In-Reply-To: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr>
References: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr>
Message-ID: <CAFzjYVp0WRSH7Vmhx1ksV1K6moHXoKSiRuQ9+xa1-kVhKvSLKw@mail.gmail.com>

Personally would go with option number 2

On Thu, Jul 12, 2018 at 1:58 AM Olivier Croquette <ocroquette at free.fr>
wrote:

> Hello,
>
> in one of our projects, we use copy_if_different to copy some DLLs
> required by the runtime. It's called as post-build action. The problem
> is that several targets want to copy the same DLLs, and when using
> parallelized builds, the different "cmake -E copy_if_different" can
> conflict, leading the whole build to fail.
>
> I see two options to fix this:
>
> 1. don't use copy_if_different, but a custom tool that can deal with the
> concurrency
>
> 2. instead of adding post-build actions to different targets, fill up a
> list containing all the files required, and add a single post-build
> action to a single target that copies all the required files in one go
>
> What do you think?
>
> Cheers
> Olivier
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180712/ae4c7f7d/attachment-0001.html>

From thomas.l.clune at nasa.gov  Thu Jul 12 09:03:13 2018
From: thomas.l.clune at nasa.gov (Clune, Thomas L. (GSFC-6101))
Date: Thu, 12 Jul 2018 13:03:13 +0000
Subject: [CMake] FindMPI  and version
Message-ID: <62E68FF0-C84C-4D0B-BEF7-9053FE6057E6@nasa.gov>

It appears that MPI_<LANG>_VERSION is returning the version of the MPI _standard_ that is supported by the chosen MPI.   While I am sure this is useful in some contexts, it?s actually not what I want/need for my project and it is quite inconsistent with analogous versions such as CMAKE_<LANG>_COMPILER_VERSION.   E.g., CMAKE_Fortran_COMPILER_VERSION returns something like 18.0.3.xxxxx for my current Intel compiler whereas the Fortran language standard that it nominally supports is 2008.

Our project has dependencies on external libraries that in turn have dependencies on MPI.   We would like to ensure that we choose the external library that was compiled with  the same vendor version of MPI used in our project.    In theory such information can be derived from MPI_<LANG>_LIBRARY_VERSION,   but it is nontrivial and some conventions need to be established.    The proper home for such logic is FindMPI.cmake.

I would not think that we are the only project facing this frustration, but given that MPI_<LANG>_LIBRARY_VERSION is only in the very latest release of cmake, others must have found other means to compensate for this?






From calebwherry at gmail.com  Thu Jul 12 09:16:07 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Thu, 12 Jul 2018 09:16:07 -0400
Subject: [CMake] Concurrency issues with copy_if_different
In-Reply-To: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr>
References: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr>
Message-ID: <CAJxY6Xo3oEkuF2AR96cyM14VCGVUS3pmbteGUF_onLu2_CXUEA@mail.gmail.com>

Had the same problem and went with #2

-Caleb

On Thu, Jul 12, 2018 at 1:58 AM Olivier Croquette <ocroquette at free.fr>
wrote:

> Hello,
>
> in one of our projects, we use copy_if_different to copy some DLLs
> required by the runtime. It's called as post-build action. The problem
> is that several targets want to copy the same DLLs, and when using
> parallelized builds, the different "cmake -E copy_if_different" can
> conflict, leading the whole build to fail.
>
> I see two options to fix this:
>
> 1. don't use copy_if_different, but a custom tool that can deal with the
> concurrency
>
> 2. instead of adding post-build actions to different targets, fill up a
> list containing all the files required, and add a single post-build
> action to a single target that copies all the required files in one go
>
> What do you think?
>
> Cheers
> Olivier
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180712/70eefe1c/attachment.html>

From r030t1 at gmail.com  Thu Jul 12 14:22:22 2018
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 12 Jul 2018 13:22:22 -0500
Subject: [CMake] Development Workflow with CMake and VS2017
Message-ID: <CAAD4mYi7BL-rxEVm3aAyZeRZFmZUW03ouP1ADMU2u8zdbP3-bw@mail.gmail.com>

Hello list,

I apologize if this is slightly offtopic, but I have not yet found a
good way to manage dependencies on Windows. On Linux the dependencies
can be installed system wide, but on Windows this is typically not the
case.

I did see some CMake scripts that would download and install things
recursively, but I am not sure (badly) recreating a package manager is
a good idea. But is it the best way for now? What alternatives are
there?

As a usecase, imagine I just want to make a simple program that uses
e.g. FreeType2. I would also like to know of options where there is
either not a CMake build script, or when the library must be compiled
with MinGW.

It seems to me I should just stick to Cygwin or MSYS2.

Cheers,
    R0b0t1

From alaitsev at gmail.com  Thu Jul 12 14:43:55 2018
From: alaitsev at gmail.com (Innokentiy Alaytsev)
Date: Thu, 12 Jul 2018 11:43:55 -0700 (MST)
Subject: [CMake] Development Workflow with CMake and VS2017
In-Reply-To: <CAAD4mYi7BL-rxEVm3aAyZeRZFmZUW03ouP1ADMU2u8zdbP3-bw@mail.gmail.com>
References: <CAAD4mYi7BL-rxEVm3aAyZeRZFmZUW03ouP1ADMU2u8zdbP3-bw@mail.gmail.com>
Message-ID: <1531421035216-0.post@n2.nabble.com>

Hello!

I usually just download prebuild binaries if they are available or build the
required dependency from sources. There are some libraries (and other
software) that are not Windows-friendly (These products are still considered
cross-platform and usually are free in the way fanatics from FSF understand
freedom, i.e. freedom is the thing that should be enforced). In the case
where it is impossible or hard to build something on Windows with MSVC, I
try to find some alternative.

The reason for trying to build everything with MSVC is simple -
unfortunately, it is the official compiler for the platform and some things
can only be built with it for Windows.

Sticking to Cygwin or MSYS2 may be fine unless you need some things like Qt
with WebEngine support or, probably, CUDA (I am not sure if it officially
works with anything else but MSVC).



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

From matteo.settenvini at here.com  Fri Jul 13 04:31:03 2018
From: matteo.settenvini at here.com (Settenvini, Matteo)
Date: Fri, 13 Jul 2018 08:31:03 +0000
Subject: [CMake] Cannot import a project twice when cross compiling (as
 host-tool and for the target arch)
In-Reply-To: <CA+dygY=J8=SdMbPiqXk1yKEEDbToJAeyWsD-U+h_0Nr7cB21LQ@mail.gmail.com>
References: <AM0PR04MB40501CFC93113DF61E6A12C1825A0@AM0PR04MB4050.eurprd04.prod.outlook.com>,
 <CA+dygY=J8=SdMbPiqXk1yKEEDbToJAeyWsD-U+h_0Nr7cB21LQ@mail.gmail.com>
Message-ID: <AM0PR04MB4050D19BC2130AC5786BD64982580@AM0PR04MB4050.eurprd04.prod.outlook.com>

Thanks Craig,


we are already doing roughly that, plus some custom logic we built around options to be able to forward them to the second CMake process.

It's a bit more complex for us, but the concepts are the same.


The problem is just being able to use targets for the version of the executables compiled for the host, instead of using find_program or hardcoding paths like you do at step (e) in your StackOverflow answer.


It wouldn't be that important if all people using our internal CMake API were also CMake experts, but unfortunately we have lots of baffled developers by having to call "find_program()" and then variables, instead of "find_package(pkg REQUIRED NO_CMAKE_FIND_ROOT_PATH)" and then use an imported target. Also, this is asymmetrical when non-crosscompiling, which adds more logic than necessary in several places.


Cheers,

Matteo Settenvini

________________________________
From: Craig Scott <craig.scott at crascit.com>
Sent: Thursday, July 12, 2018 12:00:18 AM
To: Settenvini, Matteo
Cc: cmake at cmake.org
Subject: Re: [CMake] Cannot import a project twice when cross compiling (as host-tool and for the target arch)

Not quite sure if it fits your use case, but we use a technique at work basically as described in the following:

https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F36084785%2Fbuilding-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=xJ%2FHdGlj4O%2FRulWQNQY6nWhpodk3sBpiDM6EucQJXZk%3D&reserved=0>

Your case sounds more complicated, but maybe the above technique might help if you can organise things that way.



On Wed, Jul 11, 2018 at 10:54 PM, Settenvini, Matteo <matteo.settenvini at here.com<mailto:matteo.settenvini at here.com>> wrote:
Dear all,

I have the following problem which I don't know how to best solve.
Any help is appreciated.

============== Use Case ==============

Consider the following use case:

* We are cross-compiling.
* A certain project A depends on project B in two different ways:
  - it uses an executable target from B to generate some files, e.g. a compiler.
  - one of its libraries links against a library of B.

We would like to be able to do (not possible with CMake at the moment):


  find_package(B REQUIRED)
  # use B::lib normally. When crosscompiling, it will be the one compiled for the target.

  find_package(B REQUIRED NO_CMAKE_FIND_ROOT_PATH)
  # use B::exe knowing that it will always run from the host system.


This is for instance a use case we have for flatbuffers / protobuf.

IMPORTED and ALIAS targets should not be global, or it should be
possible to override them. Or else, it should be possible to
dynamically specify a namespace when importing targets through
find_package().

I opened a bug at https://gitlab.kitware.com/cmake/cmake/issues/18169<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fissues%2F18169&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=O2F%2BX4iOCnF7HYxPFBkSobsrqxkyTIhkcFJ3fjeP81k%3D&reserved=0>,
but it got closed as there are no plans to change the way CMake works.

The issue contains also a test case, if you'd like to try it out.

============== Problem ==============

The user cannot import a project twice to get the appropriate targets
when cross-compiling: once for the host architecture and once for the
target architecture.

Right now, the user needs to manually use e.g. find_program() instead
of relying on installed locations, which can be annoying if the
binaries are installed outside the environment PATH. This can be
worked around, but we would like to use targets in place of
find_program() or find_library() calls.

The problem is much more apparent in big superbuilds where you have
hundreds of projects brought together in one build and no control over
components outside your own. It is too hard to ensure a stable
configuration order (so that find_package() is always called for the
host version before the target version, or vice-versa).

============== Help needed ==============

How would you solve the issue, so that different targets are available
for both the version built for the host and target architectures?

Note that sometimes these external projects are not under our control,
and they come directly from upstream as git submodules. So we would
like to touch them as little as possible.

Bests,
Matteo Settenvini
--

Powered by www.kitware.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=Kii%2Bk7gLL8hCJ1ekpXIKmzjgSU1Gu76eciezF1YX8Yw%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%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=VEtz1dYyQ3I82TmCoFiKFodBsgpirKbi6fHL9TePiGc%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%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=vPD2YmT%2FnYsPmE7qZgv7jJVWyZu%2FtyzbGREeajdz8HM%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%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=WswwDS4Qm2H4%2ByA1xn5QyqZFoEaQmqXAw2lOEk1gC5Q%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%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=ZGAGTZ33EWW3H5ZPxC1iYekX0NSJJwIWXmR0ewrzUgE%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%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=jEPvMIis0QoqujH%2BAJ%2F8enyVInFAFAkDl%2FVw4QYJI2k%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%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=WeNcJxyEZQw8kw2ifdsDbW6uVBlNVSs2pmV%2BieHstnY%3D&reserved=0>



--
Craig Scott
Melbourne, Australia
https://crascit.com<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrascit.com&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=HZ7nPd1P%2Fgd8SrsysnKG%2BHa5sxd1H5BDJWfiqt%2FJvNg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180713/6234bddc/attachment-0001.html>

From kornel at lyx.org  Fri Jul 13 05:54:45 2018
From: kornel at lyx.org (Kornel Benko)
Date: Fri, 13 Jul 2018 11:54:45 +0200
Subject: [CMake] Babel Frage
In-Reply-To: <c4cb237a414c6d7f54451a72b9786f509a329bde.camel@lyx.org>
References: <3981607.54b7WjbDWL@amd64> <4496546.q9kzjQBY79@amd64>
 <c4cb237a414c6d7f54451a72b9786f509a329bde.camel@lyx.org>
Message-ID: <51053971.yJCQ1XBbfQ@amd64>

Am Donnerstag, 12. Juli 2018 17:06:17 CEST schrieb J?rgen Spitzm?ller <spitz at lyx.org>:
...
> >
> > Ja, das steht in der Doku, stimmt aber nicht ganz. Akzeptiert wird
> > z.B auch ngerman.
> 
> Das ?bersetzt aber nicht die internen Makros. Siehe sr-vorl.cls:

A-ha.  Schade.

	Gru?
		Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake/attachments/20180713/0e91e426/attachment.sig>

From kornel at lyx.org  Fri Jul 13 05:58:20 2018
From: kornel at lyx.org (Kornel Benko)
Date: Fri, 13 Jul 2018 11:58:20 +0200
Subject: [CMake] Babel Frage
In-Reply-To: <51053971.yJCQ1XBbfQ@amd64>
References: <3981607.54b7WjbDWL@amd64>
 <c4cb237a414c6d7f54451a72b9786f509a329bde.camel@lyx.org>
 <51053971.yJCQ1XBbfQ@amd64>
Message-ID: <3337038.Y8kJL03T7m@amd64>

Am Freitag, 13. Juli 2018 11:54:45 CEST schrieb Kornel Benko <kornel at lyx.org>:
> Am Donnerstag, 12. Juli 2018 17:06:17 CEST schrieb J?rgen Spitzm?ller <spitz at lyx.org>:
> ...
> > >
> > > Ja, das steht in der Doku, stimmt aber nicht ganz. Akzeptiert wird
> > > z.B auch ngerman.
> > 
> > Das ?bersetzt aber nicht die internen Makros. Siehe sr-vorl.cls:
> 
> A-ha.  Schade.
> 
> 	Gru?
> 		Kornel
> 

Sorry, wrong list.

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake/attachments/20180713/e22f14a3/attachment.sig>

From johnb003 at gmail.com  Fri Jul 13 14:31:55 2018
From: johnb003 at gmail.com (John Butterfield)
Date: Fri, 13 Jul 2018 11:31:55 -0700
Subject: [CMake] structuring installation folders for relocatable
 multi-platform installations
Message-ID: <CAJ2ZDLK5KW8ZTipnH1=JFEDdd0a9FSaJ6+BEEmezQSMBWC0eAw@mail.gmail.com>

What is the recommended way to structure installation folders for a
relocatable installation for multiple platforms?

I'm looking for a structure that works with find_package module mode and
config mode; something like this:

    <install_prefix>/
      include/
        foo/
          foo.h
      lib/
        <PLAT x ARCH x CONFIG>/
          cmake/
            foo/
              FooConfig.cmake
          libFoo.a

Goal is:

 * libs can be co-installed for different platforms, architectures and
configs
 * includes can be shared
 * finding the includes should work in typical module mode searches
 * should just work with vanilla find_package(Foo REQUIRED), but for the
appropriate platform and arch.

Considering I'd be installing mostly 3rd party libraries here, if this can
be done by overriding the vars from GNUInstallDirs, it'd probably work for
many libraries. The rest I guess would either have to be edited or I just
give up and use separate installation dirs that include platform and arch.

I also cross posted on Stack Overflow:
https://stackoverflow.com/questions/51112173/whats-the-ideal-cmake-installation-directory-structure-for-a-relocatable-multip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180713/5cfe833c/attachment.html>

From bram at cocamware.com  Sat Jul 14 16:15:03 2018
From: bram at cocamware.com (Bram de Greve)
Date: Sat, 14 Jul 2018 22:15:03 +0200
Subject: [CMake] FindPython.cmake in older CMake version
Message-ID: <c7fb9eda-c19e-0bba-0a72-9766abc47520@cocamware.com>

Hi,

I'm testing out CMake 3.12, and I very much like the new 
FindPython.cmake. Being able to use targets for the Python libraries 
means I can much easier package my own library without hardcoded paths.

The only thing is that I want to be compatible with older CMakes >= 
3.0.? Therefore I came up with following approach: write a 
FindPythonCompat.cmake that forwards to FindPython.cmake if CMake >= 
3.12, and uses FindPythonInterp.cmake and FindPythonLibs.cmake to mimic 
the new FindPython.cmake if CMake < 3.12.

You can find that file attached.

Instead of calling this:

find_package(Python 2.7 EXACT REQUIRED COMPONENTS Interpreter 
OPTIONAL_COMPONENTS Development)

I now do this:

list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}/cmake) # 
contains FindPythonInterp.cmake
find_package(PythonCompat 2.7 EXACT REQUIRED COMPONENTS Interpreter 
OPTIONAL_COMPONENTS Development)

The resulting targets and variables are the same as the ones from 
FindPython.cmake.

Another approached I consider is a bit more cunning: add a 
PythonConfig.cmake and PythonConfigVersion.cmake to CMAKE_PREFIX_PATH.? 
PythonConfig.cmake would not contain the forward to FindPython.cmake, 
but it would instead rely on the fallback from MODULE to CONFIG mode 
when FindPython.cmake cannot be found in CMake < 3.12. I would then 
still be calling find_package(Python) but I extend CMAKE_PREFIX_PATH:

list(APPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR}/cmake) # 
contains PythonConfig.cmake
find_package(Python 2.7 EXACT REQUIRED COMPONENTS Interpreter 
OPTIONAL_COMPONENTS Development)

In both cases it is of course required that I install this 
FindPythonCompat.cmake or PythonConfig.cmake next to my own library's 
FooConfig.cmake.

Also, in the compatibility mode, it's not my goal to get a 1-on-1 match 
with FindPython.cmake. For my needs, I only require what 
FindInterp.cmake and FindLibs.cmake can deliver.

Now my questions to you are:
- What do you think of these approaches?
- What's the most CMake-esque approach?
- How can I improve this?
- Any better names for FindPythonCompat.cmake? FindPythonShim.cmake?? 
FindPythonForward.cmake?

Thanks for your feedback,
Bram


-------------- next part --------------
unset(_PythonCompat_ARGS)
if(PythonCompat_FIND_VERSION)
    list(APPEND _PythonCompat_ARGS ${PythonCompat_FIND_VERSION})
endif()
if(PythonCompat_FIND_VERSION_EXACT)
    list(APPEND _PythonCompat_ARGS EXACT)
endif()
if(PythonCompat_FIND_QUIETLY)
    list(APPEND _PythonCompat_ARGS QUIET)
endif()

if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.12)
    # Cmake 3.12 has FindPython.cmake, so we can simply forward to it
    unset(_PythonCompat_COMPONENTS)
    unset(_PythonCompat_OPTIONAL_COMPONENTS)
    foreach(_PythonCompat_COMPONENT ${PythonCompat_FIND_COMPONENTS})
        if(PythonCompat_FIND_REQUIRED_${_PythonCompat_COMPONENT})
            list(APPEND _PythonCompat_COMPONENTS "${_PythonCompat_COMPONENT}")
        else()
            list(APPEND _PythonCompat_OPTIONAL_COMPONENTS "${_PythonCompat_COMPONENT}")
        endif()
    endforeach()

    find_package(Python ${_PythonCompat_ARGS}
        COMPONENTS ${_PythonCompat_COMPONENTS}
        OPTIONAL_COMPONENTS ${_PythonCompat_OPTIONAL_COMPONENTS})

    set(PythonCompat_FOUND ${Python_FOUND})
    return()
endif()


if(NOT PythonCompat_FIND_COMPONENTS)
  set(PythonCompat_FIND_COMPONENTS Interpreter)
  set(PythonCompat_FIND_REQUIRED_Interpreter TRUE)
endif()

set(_PythonCompat_REQUIRED_VARS)

if(DEFINED PythonCompat_FIND_REQUIRED_Interpreter)
    if(Python_EXECUTABLE AND NOT PYTHON_EXECUTABLE)
        set(PYTHON_EXECUTABLE ${Python_EXECUTABLE} CACHE FILEPATH
            "Path to a program." FORCE)
    endif()

    find_package(PythonInterp ${_PythonCompat_ARGS})

    set(Python_Interpreter_FOUND ${PYTHONINTERP_FOUND})
    set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
    set(Python_VERSION ${PYTHON_VERSION_STRING})
    set(Python_VERSION_MAJOR ${PYTHON_VERSION_MAJOR})
    set(Python_VERSION_MINOR ${PYTHON_VERSION_MINOR})
    set(Python_VERSION_PATCH ${PYTHON_VERSION_PATCH})

    if(TARGET Python::Interpreter AND PYTHONINTERP_FOUND)
        add_executable (Python::Interpreter IMPORTED)
        set_property(TARGET Python::Interpreter PROPERTY
            IMPORTED_LOCATION "${PYTHON_EXECUTABLE}")
    endif()

    if(PythonCompat_FIND_REQUIRED_Interpreter)
        list(APPEND _PythonCompat_REQUIRED_VARS PYTHON_EXECUTABLE)
    endif()
endif()

if(DEFINED PythonCompat_FIND_REQUIRED_Development)
    find_package(PythonLibs ${_PythonCompat_ARGS})

    set(Python_Development_FOUND ${PYTHONLIBS_FOUND})
    set(Python_INCLUDE_DIRS ${PYTHON_INCLUDE_DIRS})
    set(Python_LIBRARIES ${PYTHON_LIBRARIES})
    #set(Python_LIBRARY_DIRS ${PYTHON_EXECUTABLE})
    #set(Python_RUNTIME_LIBRARY_DIRS ${PYTHON_EXECUTABLE})

    set(Python_INCLUDE_DIR ${PYTHON_INCLUDE_DIR})
    set(Python_LIBRARY_RELEASE ${PYTHON_LIBRARY_RELEASE})
    set(Python_LIBRARY_DEBUG ${PYTHON_DEBUG_LIBRARY})

    if(NOT TARGET Python::Python AND PYTHONLIBS_FOUND)
        if(PYTHON_LIBRARY MATCHES "${CMAKE_SHARED_LIBRARY_SUFFIX}$" OR
           PYTHON_DEBUG_LIBRARY MATCHES "${CMAKE_SHARED_LIBRARY_SUFFIX}$")
            set(_PythonCompat_LIBRARY_TYPE SHARED)
        else()
            set(_PythonCompat_LIBRARY_TYPE UNKNOWN)
        endif()
        add_library(Python::Python "${_PythonCompat_LIBRARY_TYPE}" IMPORTED)
        set_property(TARGET Python::Python PROPERTY
            INTERFACE_INCLUDE_DIRECTORIES "${PYTHON_INCLUDE_DIRS}")
        if(PYTHON_DEBUG_LIBRARY)
            set_property(TARGET Python::Python APPEND PROPERTY
                IMPORTED_CONFIGURATIONS RELEASE)
            set_target_properties(Python::Python PROPERTIES
                IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C"
                IMPORTED_LOCATION_RELEASE "${PYTHON_LIBRARY_RELEASE}")
            set_property(TARGET Python::Python APPEND PROPERTY
                IMPORTED_CONFIGURATIONS DEBUG)
            set_target_properties(Python::Python PROPERTIES
                IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
                IMPORTED_LOCATION_DEBUG "${PYTHON_DEBUG_LIBRARY}")
        else()
            set_target_properties(Python::Python PROPERTIES
                IMPORTED_LINK_INTERFACE_LANGUAGES "C"
                IMPORTED_LOCATION "${PYTHON_LIBRARY}")
        endif()
    endif()

    if(PythonCompat_FIND_REQUIRED_Development)
        list(APPEND _PythonCompat_REQUIRED_VARS PYTHON_LIBRARIES
                                                PYTHON_INCLUDE_DIRS)
    endif()
endif()

include(FindPackageHandleStandardArgs)
set(Python_FIND_COMPONENTS ${PythonCompat_FIND_COMPONENTS})
find_package_handle_standard_args(Python
    REQUIRED_VARS ${_PythonCompat_REQUIRED_VARS}
    VERSION_VAR Python_VERSION
    HANDLE_COMPONENTS)
set(PythonCompat_FOUND ${Python_FOUND})

From Dvir.Yitzchaki at ceva-dsp.com  Sun Jul 15 03:26:47 2018
From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki)
Date: Sun, 15 Jul 2018 07:26:47 +0000
Subject: [CMake] Boost + CMake + Windows + Sanity -> Possible?
In-Reply-To: <1531391365828-0.post@n2.nabble.com>
References: <DB7PR03MB34986CF95ED19AE020E78591BF590@DB7PR03MB3498.eurprd03.prod.outlook.com>
 <1531391365828-0.post@n2.nabble.com>
Message-ID: <d2030d6749ad418ea1634e1590e8e72c@ceva-dsp.com>

I recommend using Hunter package manager:

https://docs.hunter.sh/en/latest/quick-start/boost-components.html



Regards,

Dvir



-----Original Message-----
From: CMake <cmake-bounces at cmake.org> On Behalf Of Innokentiy Alaytsev
Sent: Thursday, July 12, 2018 13:29
To: 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/>  . 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/

--



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180715/6a4bc4e4/attachment.html>

From Dvir.Yitzchaki at ceva-dsp.com  Sun Jul 15 03:29:04 2018
From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki)
Date: Sun, 15 Jul 2018 07:29:04 +0000
Subject: [CMake] Development Workflow with CMake and VS2017
In-Reply-To: <1531421035216-0.post@n2.nabble.com>
References: <CAAD4mYi7BL-rxEVm3aAyZeRZFmZUW03ouP1ADMU2u8zdbP3-bw@mail.gmail.com>
 <1531421035216-0.post@n2.nabble.com>
Message-ID: <d080334ced93423d840b8b0bd77286e6@ceva-dsp.com>

I recommend using Hunter package manager:

https://docs.hunter.sh/en/latest/quick-start/boost-components.html



It has support for FreeType as well:

https://docs.hunter.sh/en/latest/packages/pkg/freetype.html



Regards,

Dvir



-----Original Message-----
From: CMake <cmake-bounces at cmake.org> On Behalf Of Innokentiy Alaytsev
Sent: Thursday, July 12, 2018 21:44
To: cmake at cmake.org
Subject: Re: [CMake] Development Workflow with CMake and VS2017



Hello!



I usually just download prebuild binaries if they are available or build the required dependency from sources. There are some libraries (and other

software) that are not Windows-friendly (These products are still considered cross-platform and usually are free in the way fanatics from FSF understand freedom, i.e. freedom is the thing that should be enforced). In the case where it is impossible or hard to build something on Windows with MSVC, I try to find some alternative.



The reason for trying to build everything with MSVC is simple - unfortunately, it is the official compiler for the platform and some things can only be built with it for Windows.



Sticking to Cygwin or MSYS2 may be fine unless you need some things like Qt with WebEngine support or, probably, CUDA (I am not sure if it officially works with anything else but MSVC).







--

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

--



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



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



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



CMake Support: http://cmake.org/cmake/help/support.html

CMake Consulting: http://cmake.org/cmake/help/consulting.html

CMake Training Courses: http://cmake.org/cmake/help/training.html



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



Follow this link to subscribe/unsubscribe:

https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180715/73142b6b/attachment-0001.html>

From mateusz at loskot.net  Sun Jul 15 13:35:54 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Sun, 15 Jul 2018 19:35:54 +0200
Subject: [CMake] Development Workflow with CMake and VS2017
In-Reply-To: <d080334ced93423d840b8b0bd77286e6@ceva-dsp.com>
References: <CAAD4mYi7BL-rxEVm3aAyZeRZFmZUW03ouP1ADMU2u8zdbP3-bw@mail.gmail.com>
 <1531421035216-0.post@n2.nabble.com>
 <d080334ced93423d840b8b0bd77286e6@ceva-dsp.com>
Message-ID: <CABUeae-DsRanLdsa2-ghxxEvg--GpPFB_d--b0Aj=qezQn1QFw@mail.gmail.com>

I recommend vcpkg and Conan.
You may check Boost.GIL configuration for CMake that uses both as
alternatives.
Conan can automatically pulls libpng etc.

https://github.com/boostorg/gil

Mateusz Loskot, mateusz at loskot.net
(Sent from mobile)

On Sun, 15 Jul 2018, 09:44 Dvir Yitzchaki, <Dvir.Yitzchaki at ceva-dsp.com>
wrote:

> I recommend using Hunter package manager:
>
> https://docs.hunter.sh/en/latest/quick-start/boost-components.html
>
>
>
> It has support for FreeType as well:
>
> https://docs.hunter.sh/en/latest/packages/pkg/freetype.html
>
>
>
> Regards,
>
> Dvir
>
>
>
> -----Original Message-----
> From: CMake <cmake-bounces at cmake.org> On Behalf Of Innokentiy Alaytsev
> Sent: Thursday, July 12, 2018 21:44
> To: cmake at cmake.org
> Subject: Re: [CMake] Development Workflow with CMake and VS2017
>
>
>
> Hello!
>
>
>
> I usually just download prebuild binaries if they are available or build
> the required dependency from sources. There are some libraries (and other
>
> software) that are not Windows-friendly (These products are still
> considered cross-platform and usually are free in the way fanatics from FSF
> understand freedom, i.e. freedom is the thing that should be enforced). In
> the case where it is impossible or hard to build something on Windows with
> MSVC, I try to find some alternative.
>
>
>
> The reason for trying to build everything with MSVC is simple -
> unfortunately, it is the official compiler for the platform and some things
> can only be built with it for Windows.
>
>
>
> Sticking to Cygwin or MSYS2 may be fine unless you need some things like
> Qt with WebEngine support or, probably, CUDA (I am not sure if it
> officially works with anything else but MSVC).
>
>
>
>
>
>
>
> --
>
> Sent from: http://cmake.3232098.n2.nabble.com/
>
> --
>
>
>
> Powered by www.kitware.com
>
>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
>
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
>
>
> CMake Support: http://cmake.org/cmake/help/support.html
>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
>
>
> Follow this link to subscribe/unsubscribe:
>
> 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/20180715/d835431d/attachment.html>

From r030t1 at gmail.com  Sun Jul 15 23:00:16 2018
From: r030t1 at gmail.com (R0b0t1)
Date: Sun, 15 Jul 2018 22:00:16 -0500
Subject: [CMake] Development Workflow with CMake and VS2017
In-Reply-To: <1531421035216-0.post@n2.nabble.com>
References: <CAAD4mYi7BL-rxEVm3aAyZeRZFmZUW03ouP1ADMU2u8zdbP3-bw@mail.gmail.com>
 <1531421035216-0.post@n2.nabble.com>
Message-ID: <CAAD4mYjYqg9C59N6RA7pqEYbNCmnCKG1X902WbSWGQHQpr2zwQ@mail.gmail.com>

On Thu, Jul 12, 2018 at 1:43 PM, Innokentiy Alaytsev <alaitsev at gmail.com> wrote:
> Hello!
>
> I usually just download prebuild binaries if they are available or build the
> required dependency from sources. There are some libraries (and other
> software) that are not Windows-friendly (These products are still considered
> cross-platform and usually are free in the way fanatics from FSF understand
> freedom, i.e. freedom is the thing that should be enforced). In the case
> where it is impossible or hard to build something on Windows with MSVC, I
> try to find some alternative.
>
> The reason for trying to build everything with MSVC is simple -
> unfortunately, it is the official compiler for the platform and some things
> can only be built with it for Windows.
>
> Sticking to Cygwin or MSYS2 may be fine unless you need some things like Qt
> with WebEngine support or, probably, CUDA (I am not sure if it officially
> works with anything else but MSVC).
>

Very nearly everything *does* work with MinGW save for those things
which are provided via a C++ API and driver development.

I have done this for a while, but it is especially problematic with
things which have many dependencies.


Someone privately suggested vcpkg. I tried it and it seems to work
rather well. Perhaps it is what I will be using for the foreseeable
future. I do not like how it is tied to MSVC and how it is fairly
naive.

I also found build2 but it has been rather hard to use. I am not quite
sure how to set it to compile with a 64 bit MinGW toolchain. I suppose
I will need to follow the manual instructions when I have more time;
they are a bit rough.

The other suggestions are welcome, I will try to get back to the list
with my thoughts in a few days.

Cheers,
     R0b0t1

From robert.maynard at kitware.com  Tue Jul 17 10:29:18 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 17 Jul 2018 10:29:18 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.12.0 available for download
Message-ID: <CAFzjYVoMo-M0A-juVe1PNsxBDTCRAuSyy8=SjtzyFB+FTN8euA@mail.gmail.com>

I am happy to announce that CMake 3.12.0 is now available for download at:
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.12 are:

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

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

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel [<jobs>]" and "-j [<jobs>]" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "<min>[...<max>]". The "<min>" version is required but policies are
  set based on the "<max>" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* A new "$<GENEX_EVAL:...>" and "$<TARGET_GENEX_EVAL:target,...>"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$<TARGET_EXISTS:...>" "generator expression" has been
  added.

* A new "$<TARGET_NAME_IF_EXISTS:...>" "generator expression" has
  been added.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.


CMake 3.12 Release Notes
************************

Changes made since CMake 3.11 include the following.


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


Generators
----------

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.


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

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel [<jobs>]" and "-j [<jobs>]" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.


Commands
--------

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "<min>[...<max>]". The "<min>" version is required but policies are
  set based on the "<max>" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "file(TOUCH)" and "file(TOUCH_NOCREATE)" commands were added
  to expose "TOUCH" functionality without having to use CMake's
  command- line tool mode with "execute_process()".

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* The "install()" command learned an optional "NAMELINK_COMPONENT"
  parameter, which allows you to change the component for a shared
  library's namelink. If none is specified, the value of "COMPONENT"
  is used by default.

* The "list()" command learned a "JOIN" sub-command to concatenate
  list's elements separated by a glue string.

* The "list()" command learned a "SUBLIST" sub-command to get a
  sublist of the list.

* The "list()" command learned a "TRANSFORM" sub-command to apply
  various string transformation to list's elements.

* The "project()" command learned an optional "HOMEPAGE_URL"
  parameter which has the effect of setting variables like
  "PROJECT_HOMEPAGE_URL", "<PROJECT-NAME>_HOMEPAGE_URL" and
  "CMAKE_PROJECT_HOMEPAGE_URL".

* The "string()" command learned a "JOIN" sub-command to concatenate
  input strings separated by a glue string.

* "target_compile_options()" and "add_compile_options()" commands
  gained a "SHELL:" prefix to specify a group of related options using
  shell-like quoting.

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.


Variables
---------

* The "CMAKE_FOLDER" variable was added to initialize the "FOLDER"
  property on all targets.

* The "CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION" variable was defined
  to initialize all "DOTNET_TARGET_FRAMEWORK_VERSION" target
  properties.

* "CMAKE_PROJECT_VERSION*" variables have been introduced:

  * "CMAKE_PROJECT_VERSION"

  * "CMAKE_PROJECT_VERSION_MAJOR"

  * "CMAKE_PROJECT_VERSION_MINOR"

  * "CMAKE_PROJECT_VERSION_PATCH"

  * "CMAKE_PROJECT_VERSION_TWEAK"

* The "CMAKE_SUPPRESS_REGENERATION" variable was extended to support
  the "Ninja" and Makefile Generators. It is also now documented.

* "CMAKE_VS_SDK_*_DIRECTORIES" variables were defined to tell Visual
  Studio Generators for VS 2010 and above how to populate fields in
  ".vcxproj" files that specify SDK directories.  The variables are:

  * "CMAKE_VS_SDK_EXCLUDE_DIRECTORIES"

  * "CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES"

  * "CMAKE_VS_SDK_INCLUDE_DIRECTORIES"

  * "CMAKE_VS_SDK_LIBRARY_DIRECTORIES"

  * "CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES"

  * "CMAKE_VS_SDK_REFERENCE_DIRECTORIES"

  * "CMAKE_VS_SDK_SOURCE_DIRECTORIES"

* A "MSVC_TOOLSET_VERSION" variable was added to provide the MSVC
  toolset version associated with the current MSVC compiler version in
  "MSVC_VERSION".


Properties
----------

* The "COMMON_LANGUAGE_RUNTIME" target property was introduced to
  configure the use of managed C++ for Visual Studio Generators for VS
  2010 and above. A corresponding "IMPORTED_COMMON_LANGUAGE_RUNTIME"
  target property was added to support "C++/CLI" for imported targets.

* The "DOTNET_TARGET_FRAMEWORK_VERSION" target property was
  introduced as replacement for "VS_DOTNET_TARGET_FRAMEWORK_VERSION",
  which is considered deprecated now.

* An "EXPORT_PROPERTIES" target property was added to specify a
  custom list of target properties to include in targets exported by
  the "install(EXPORT)" and "export()" commands.

* The "PDB_OUTPUT_DIRECTORY" property learned to support "generator
  expressions".

* A "TESTS" directory property was added to hold the list of tests
  defined by the "add_test()" command.

* A "VS_DEBUGGER_COMMAND" target property was created to set the
  debugging command line with Visual Studio Generators for VS 2010 and
  above.

* HLSL source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and
  "VS_SHADER_ENABLE_DEBUG" gained support for generator expressions.

* HLSL source file property "VS_SHADER_OBJECT_FILE_NAME" has been
  added to the Visual Studio Generators for VS 2010 and above. The
  property specifies the file name of the compiled shader object.


Modules
-------

* The "FindALSA" module now provides imported targets.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* The "FindLibXml2" module now provides imported targets.

* The "FindMatlab" module now supports the Matlab Runtime Compiler
  (MCR) for compiling and linking matlab extensions.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* The "FindPkgConfig" module has learned to export the found
  libraries with full path for direct consumption with the
  "target_link_libraries()" command.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.

* The "UseSWIG" module gained a whole refresh and is now more
  consistent with standard CMake commands to generate libraries and is
  fully configurable through properties.

* The "UseSWIG" module learned to manage multiple behaviors through
  "UseSWIG_MODULE_VERSION" variable to ensure legacy support as well
  as more robust handling of "SWIG" advanced features (like
  "%template").

* The "UseSWIG" module learned to support CSHARP variant wrapper
  files.

* The "WriteCompilerDetectionHeader" module gained a "BARE_FEATURES"
  option to add a compatibility define for the exact keyword of a new
  language feature.


Generator Expressions
---------------------

* A new "$<GENEX_EVAL:...>" and "$<TARGET_GENEX_EVAL:target,...>"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$<IN_LIST:...>" "generator expression" has been added.

* A new "$<TARGET_EXISTS:...>" "generator expression" has been
  added.

* A new "$<TARGET_NAME_IF_EXISTS:...>" "generator expression" has
  been added.


CTest
-----

* The "ctest_start()" command has been reworked so that you can
  simply call "ctest_start(APPEND)" and it will read all the needed
  information from the TAG file. The argument parsing has also been
  relaxed so that the order of the arguments is less significant.

* A "PROCESSOR_AFFINITY" test property was added to request that
  CTest run a test with CPU affinity for a set of processors disjoint
  from other concurrently running tests with the property set.


CPack
-----

* The "CPack" module now uses variables
  "CMAKE_PROJECT_VERSION_MAJOR", "CMAKE_PROJECT_VERSION_MINOR" and
  "CMAKE_PROJECT_VERSION_PATCH" to initialize corresponding CPack
  variables.

* "cpack(1)" gained basic support for NuGet. See the "CPackNuGet"
  module.


Other
-----

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

* The "Compile Features" functionality is now aware of the
  availability of C features in MSVC since VS 2010.

* The "Compile Features" functionality is now aware of C language
  standards supported by Texas Instruments C compilers.


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

* The "Visual Studio 8 2005" generator has been removed.

* CMake no longer produces "<tgt>_LIB_DEPENDS" cache entries for
  library targets.  See policy "CMP0073".


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

* Include flags for directories marked as "SYSTEM" are now moved
  after non-system directories.  The "-isystem" flag does this
  automatically, so moving them explicitly to the end makes the
  behavior consistent on compilers that do not have any "-isystem"
  flag.

* Fortran dependency scanning now supports dependencies implied by
  Fortran Submodules.

* The existence and functionality of the file
  "${CMAKE_BINARY_DIR}/cmake_install.cmake" has now been documented in
  the "install()" documentation so that external packaging software
  can take advantage of CPack-style component installs.

* The "CheckIncludeFile" module "check_include_file" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "CheckIncludeFileCXX" module "check_include_file_cxx" macro
  learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "CheckIncludeFiles" module "check_include_files" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "cmake(1)" "-E copy_directory" tool now fails when the source
  directory does not exist.  Previously it succeeded by creating an
  empty destination directory.

* The "UseSWIG" module "swig_add_library()" command (and legacy
  "swig_add_module" command) now set the prefix of Java modules to
  """" for MINGW, MSYS, and CYGWIN environments.

----------------------------------------------------------------------------
Changes made since CMake 3.12.0-rc3:

Brad King (2):
      Help: Mention IMPORTED_OBJECTS in add_library docs
      CMake 3.12.0

Christian Pfeiffer (1):
      Intel: Fix incorrectly documented extension flags

Cristian Adam (1):
      QNX: Fix autogen compiler predefines detection

Robert Maynard (1):
      Help: Add OBJECT_LIBRARY to TYPE target property documentation

Roger Leigh (2):
      FindBoost: Add support for Boost 1.68 beta1
      FindBoost: Change context header used

From ardillasdelmonte at gmail.com  Wed Jul 18 05:31:50 2018
From: ardillasdelmonte at gmail.com (ardi)
Date: Wed, 18 Jul 2018 11:31:50 +0200
Subject: [CMake] Querying project dependencies from the UNIX command-line
Message-ID: <CA+fZqCUYbsVSuA=AQFnJU7+Lc9W-Y=P5c-uWSQ=_Y+wAFXVheQ@mail.gmail.com>

Hi!

I've never used CMake (well, I'm continuously using it but as a user
only, for building projects, not for maintaining them) . It's quite
possible that I'll adopt CMake for maintaining my projects (I'm in the
process of locating good references for learning "Modern CMake" --I
want to start directly at Modern CMake, and avoiding as much
old-fashioned practices as possible).

However, before learning and adopting CMake, there's a feature that I
need, and I don't know if CMake provides it, or if I'll need to use an
additional tool for it. And that feature is querying dependencies.

For example, I'd like to type "somecommand /path/to/someproject" at
the UNIX command line, and get this output:

Project /path/to/someproject requires the following to be built:
wxWidgets >= 3.0.0
CUDA >= 7.0.0
OpenCV >= 3.3

Furthermore, if another command could show optional requisites, it
would be really great: "anothercommand /path/to/someproject"

Project /path/to/someproject can optionally use the following when being built:
libtiff >= 4.0.0
libzip >= 1.5.0

So, can I get this functionality from plain CMake/CPack ? Or would I
need additional tools (Note: I know about Hunter, but first I'd like
to know if plain CMake does already offer this feature).

Thanks!

ardi

From mike.jackson at bluequartz.net  Wed Jul 18 08:48:47 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 18 Jul 2018 08:48:47 -0400
Subject: [CMake] CMake 3.12 rc2 to rc3 Regression
Message-ID: <9A135CAC-E202-4387-A80B-3A106F7EF2AB@bluequartz.net>

There was a regression between 3.12-rc2 and 3.12-rc3 where we can no longer add files to a target unless it was built in the directory that is currently being cmaked? Hard to explain, I'll let my error message help out:

In CMake 3.12-rc3 and the 3.12 Official Release I get the following:

-- TransformationPhase [ENABLED] 3 Filters
-- Plugin: Defining UCSBUtilities_SOURCE_DIR to /Users/mjackson/DREAM3D-Dev/DREAM3D/ExternalProjects/Plugins/UCSBUtilities
CMake Error at ExternalProjects/SIMPL/Wrapping/Python/Pybind11/cmake/WrappingFunctions.cmake:144 (target_link_libraries):
? Attempt to add link library "UCSBUtilitiesServer" to target "dream3d_py"
? which is not built in this directory.
Call Stack (most recent call first):
? ExternalProjects/Plugins/UCSBUtilities/CMakeLists.txt:242 (CreatePybind11Module)

In CMake 3.12 rc2 and earlier I don't get the error message. I was trying to keep up with the RCs but just got back from travel to test the release. We were counting on that new feature for a few aspects of our project. Was the feature pulled due to bugs?

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



From mike.jackson at bluequartz.net  Wed Jul 18 09:04:42 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 18 Jul 2018 09:04:42 -0400
Subject: [CMake] CMake 3.12 rc2 to rc3 Regression
In-Reply-To: <9A135CAC-E202-4387-A80B-3A106F7EF2AB@bluequartz.net>
References: <9A135CAC-E202-4387-A80B-3A106F7EF2AB@bluequartz.net>
Message-ID: <0FBE22F4-9E93-410E-A6E2-8A630DCDAD13@bluequartz.net>

Searching the mailing list archives for the RC3 announcement I scrolled to the bottom and found:

Brad King (2):
      Revert "target_link_libraries: Allow use with targets in other
directories"
      CMake 3.12.0-rc3

Just curious what caused the issue to revert the change?

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

?On 7/18/18, 8:48 AM, "Michael Jackson" <mike.jackson at bluequartz.net> wrote:

    There was a regression between 3.12-rc2 and 3.12-rc3 where we can no longer add files to a target unless it was built in the directory that is currently being cmaked? Hard to explain, I'll let my error message help out:
    
    In CMake 3.12-rc3 and the 3.12 Official Release I get the following:
    
    -- TransformationPhase [ENABLED] 3 Filters
    -- Plugin: Defining UCSBUtilities_SOURCE_DIR to /Users/mjackson/DREAM3D-Dev/DREAM3D/ExternalProjects/Plugins/UCSBUtilities
    CMake Error at ExternalProjects/SIMPL/Wrapping/Python/Pybind11/cmake/WrappingFunctions.cmake:144 (target_link_libraries):
      Attempt to add link library "UCSBUtilitiesServer" to target "dream3d_py"
      which is not built in this directory.
    Call Stack (most recent call first):
      ExternalProjects/Plugins/UCSBUtilities/CMakeLists.txt:242 (CreatePybind11Module)
    
    In CMake 3.12 rc2 and earlier I don't get the error message. I was trying to keep up with the RCs but just got back from travel to test the release. We were counting on that new feature for a few aspects of our project. Was the feature pulled due to bugs?
    
    --
    Michael Jackson | Owner, President
          BlueQuartz Software
    [e] mike.jackson at bluequartz.net
    [w] www.bluequartz.net <http://www.bluequartz.net>
    
    
    



From craig.scott at crascit.com  Wed Jul 18 09:40:30 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 18 Jul 2018 23:40:30 +1000
Subject: [CMake] CMake 3.12 rc2 to rc3 Regression
In-Reply-To: <0FBE22F4-9E93-410E-A6E2-8A630DCDAD13@bluequartz.net>
References: <9A135CAC-E202-4387-A80B-3A106F7EF2AB@bluequartz.net>
 <0FBE22F4-9E93-410E-A6E2-8A630DCDAD13@bluequartz.net>
Message-ID: <CA+dygYnWEmzSx3wUTg1gRnQX5QR8Qy_0=Uu7yQwMFzjiErX-Aw@mail.gmail.com>

On Wed, Jul 18, 2018 at 11:04 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> Searching the mailing list archives for the RC3 announcement I scrolled to
> the bottom and found:
>
> Brad King (2):
>       Revert "target_link_libraries: Allow use with targets in other
> directories"
>       CMake 3.12.0-rc3
>
> Just curious what caused the issue to revert the change?
>


The original problem report was on the dev mailing list:

https://cmake.org/pipermail/cmake-developers/2018-June/030740.html


The longer history of how the feature evolved and was then reverted can be
found here:

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


-- 
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/20180718/76702265/attachment.html>

From briansdeveloper at gmail.com  Wed Jul 18 09:49:47 2018
From: briansdeveloper at gmail.com (Brian S)
Date: Wed, 18 Jul 2018 09:49:47 -0400
Subject: [CMake] Using Different Computers for cmake and ctest
Message-ID: <CAA5VmpuJsmg1uaP4uzeM5T2e29TRLRJ8k+3PrqU_nZ9B1BoGUQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180718/55d7fd95/attachment.html>

From michal.wozniak at caboma.com  Wed Jul 18 12:05:31 2018
From: michal.wozniak at caboma.com (Michal Wozniak)
Date: Wed, 18 Jul 2018 16:05:31 +0000
Subject: [CMake] CTEST_CUSTOM_ERROR_MATCH not working ?
Message-ID: <BL2PR15MB09639695D17D80EA382A29E6F5530@BL2PR15MB0963.namprd15.prod.outlook.com>

Hi,


I'm using ctest to build and test my project.  I trying to use CTEST_CUSTOM_ERROR_MATCH to find a different type of errors but it is always defaulting back to "ERROR:".   I am setting this variable in my CTestConfig.cmake.


set(CTEST_CUSTOM_ERROR_MATCH
    "error1"
    "error2"
    "error3"
    )

when I print the value, everything seems to be set correctly, but then on my CDash, i  getting the default regex "Error regular expression found in output. Regex=[(<br /> |^)ERROR: ]"

Is this the correct way to change the default error regular expression?

thanks

Michal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180718/06e4740e/attachment.html>

From moseymoose at protonmail.com  Wed Jul 18 14:27:05 2018
From: moseymoose at protonmail.com (moseymoose)
Date: Wed, 18 Jul 2018 14:27:05 -0400
Subject: [CMake] Transcriber AG
Message-ID: <PgdUZiy4sCiBHWnIH4KRta8iitd0dGNTPD0BGABWyOrQ1R94ZNqohoc-27IFDtKWg3Alrpx8hBgBmRZ30XN6hh2qX4GcXT4s0UxvRVgrUls=@protonmail.com>

Hi. I am a complete beginner at this but here goes. I'm trying to compile files to make Transcriber AG. I downloaded the prerequisite files including gtk, xerces, etc. Now what do I do? Thank you for your help.

Warmly,
Larry

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180718/9de1735d/attachment.html>

From dmitry at parallel-computing.pro  Wed Jul 18 15:02:13 2018
From: dmitry at parallel-computing.pro (Dmitry Mikushin)
Date: Wed, 18 Jul 2018 22:02:13 +0300
Subject: [CMake] Transcriber AG
In-Reply-To: <PgdUZiy4sCiBHWnIH4KRta8iitd0dGNTPD0BGABWyOrQ1R94ZNqohoc-27IFDtKWg3Alrpx8hBgBmRZ30XN6hh2qX4GcXT4s0UxvRVgrUls=@protonmail.com>
References: <PgdUZiy4sCiBHWnIH4KRta8iitd0dGNTPD0BGABWyOrQ1R94ZNqohoc-27IFDtKWg3Alrpx8hBgBmRZ30XN6hh2qX4GcXT4s0UxvRVgrUls=@protonmail.com>
Message-ID: <CAJoDaPZpT9N1ZDo6JAMcCed8NwfH4tfdisC8BzEyiitxEMSKHA@mail.gmail.com>

Prerequisites must be installed or placed appropriately, according with
instructions for specific program.

Regarding the further steps, typically you should locate CMakeListst.txt
file, create subfolder "build" in the same folder, change to "build" folder
and run "cmake .." from it. Upon successful run, a Makefile or other type
of build config will be created, which you then should execute separately.

Kind regards,
- Dmitry.


2018-07-18 21:27 GMT+03:00 moseymoose via CMake <cmake at cmake.org>:

> Hi. I am a complete beginner at this but here goes. I'm trying to compile
> files to make Transcriber AG. I downloaded the prerequisite files including
> gtk, xerces, etc. Now what do I do? Thank you for your help.
>
>
> Warmly,
> Larry
>
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180718/b2e114f3/attachment.html>

From johannes at zarl-zierl.at  Wed Jul 18 16:04:05 2018
From: johannes at zarl-zierl.at (Johannes Zarl-Zierl)
Date: Wed, 18 Jul 2018 22:04:05 +0200
Subject: [CMake] Querying project dependencies from the UNIX command-line
In-Reply-To: <CA+fZqCUYbsVSuA=AQFnJU7+Lc9W-Y=P5c-uWSQ=_Y+wAFXVheQ@mail.gmail.com>
References: <CA+fZqCUYbsVSuA=AQFnJU7+Lc9W-Y=P5c-uWSQ=_Y+wAFXVheQ@mail.gmail.com>
Message-ID: <4508371.rsHKcPBH81@mani>

Hi Ardi,

Am Mittwoch, 18. Juli 2018, 11:31:50 CEST schrieb ardi:
> For example, I'd like to type "somecommand /path/to/someproject" at
> the UNIX command line, and get this output:
> [...]
> Furthermore, if another command could show optional requisites, it
> would be really great: "anothercommand /path/to/someproject"
> 
> Project /path/to/someproject can optionally use the following when being
> built: 
> [...]
> So, can I get this functionality from plain CMake/CPack ? Or would I
> need additional tools (Note: I know about Hunter, but first I'd like
> to know if plain CMake does already offer this feature).

I don't think there's something that gives you exactly what you described, 
especially not for a random CMake project.

If you can add some commands to the CMakeLists.txt, though, then the 
FeatureSummary module may suit your needs.

Basically, you include the module an then add a cmake command like this:
feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)

When you run cmake, you'll get a summary of which packages have been found/not 
found, and the required version if you supplied one for the corresponding 
find_package command.

Cheers,
  Johannes




From ufuk.turuncoglu at itu.edu.tr  Thu Jul 19 05:03:01 2018
From: ufuk.turuncoglu at itu.edu.tr (Ufuk Turuncoglu)
Date: Thu, 19 Jul 2018 12:03:01 +0300
Subject: [CMake] problem in finding netcdf library with cmake
Message-ID: <6f0b99bc-708f-860f-9daf-63aeaad8bda0@itu.edu.tr>

Hi,

First of all, i am new to cmake and i would like to use it in my current 
project. So, i need to use netcdf library in my project and i am using 
VTK's FindNetCDF.cmake for it. The content of my CMakeLists.txt file as 
follows,

cmake_minimum_required (VERSION 2.6)

# The project name
project (REGESM)

# The version number
set (REGESM_VERSION_MAJOR 2)
set (REGESM_VERSION_MINOR 0)

# Add bld/ directory to cmake module path
set(REGESM_CMAKE_DIR "${REGESM_SOURCE_DIR}/bld")
set(CMAKE_MODULE_PATH ${REGESM_CMAKE_DIR} ${CMAKE_MODULE_PATH})

# Use VTK's NetCDF interface
find_package (NetCDF COMPONENTS F90)
include_directories(${NETCDF_F90_INCLUDE_DIRS})

but when i run the cmake command, i am getting following error,

-- Failed to find NetCDF interface for F90
-- Could NOT find NetCDF (missing: NETCDF_LIBRARIES NETCDF_INCLUDE_DIRS 
NETCDF_HAS_INTERFACES)
CMake Error: The following variables are used in this project, but they 
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the 
CMake files:
NETCDF_F90_INCLUDE_DIR (ADVANCED)
 ?? used as include directory in directory /RS/users/turuncu/DEV/RegESM2
 ?? used as include directory in directory /RS/users/turuncu/DEV/RegESM2

in my case the netcdf library is installed and i could use it externally 
without any problem. i don't think but to be sure, is it necessary to 
install netcdf with special options to use it under cmake. i also define 
a set of environment variables but it could not help.

NETCDF_LIBRARY=/RS/progs/netcdf/4.4.0/intel/2017u5/lib
NETCDF_HOME=/RS/progs/netcdf/4.4.0/intel/2017u5
NETCDF_ROOT=/RS/progs/netcdf/4.4.0/intel/2017u5
NETCDF_INCLUDE_DIR=/RS/progs/netcdf/4.4.0/intel/2017u5/include
NETCDF4_ROOT=/RS/progs/netcdf/4.4.0/intel/2017u5
NETCDF=/RS/progs/netcdf/4.4.0/intel/2017u5

So, any suggestion will help to me at this point.

Best Regards,

--ufuk


From mike.jackson at bluequartz.net  Thu Jul 19 08:04:20 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 19 Jul 2018 08:04:20 -0400
Subject: [CMake] CMake 3.12 rc2 to rc3 Regression
In-Reply-To: <CA+dygYnWEmzSx3wUTg1gRnQX5QR8Qy_0=Uu7yQwMFzjiErX-Aw@mail.gmail.com>
References: <9A135CAC-E202-4387-A80B-3A106F7EF2AB@bluequartz.net>
 <0FBE22F4-9E93-410E-A6E2-8A630DCDAD13@bluequartz.net>
 <CA+dygYnWEmzSx3wUTg1gRnQX5QR8Qy_0=Uu7yQwMFzjiErX-Aw@mail.gmail.com>
Message-ID: <9CE315D8-80AE-4323-BCD2-A9031D2FCFA0@bluequartz.net>

Thank you for the links. 

 

After reading through all the various discussions is there a time line of when the feature will be added back to CMake? Is it a matter of having somebody to work the problem? Is the problem solvable?

--

Michael Jackson | Owner, President

      BlueQuartz Software

[e] mike.jackson at bluequartz.net

[w] www.bluequartz.net

 

From: Craig Scott <craig.scott at crascit.com>
Date: Wednesday, July 18, 2018 at 9:40 AM
To: Michael Jackson <mike.jackson at bluequartz.net>
Cc: CMake <cmake at cmake.org>
Subject: Re: [CMake] CMake 3.12 rc2 to rc3 Regression

 

 

 

On Wed, Jul 18, 2018 at 11:04 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:

Searching the mailing list archives for the RC3 announcement I scrolled to the bottom and found:

Brad King (2):
      Revert "target_link_libraries: Allow use with targets in other
directories"
      CMake 3.12.0-rc3

Just curious what caused the issue to revert the change?

 

 

The original problem report was on the dev mailing list:

 

https://cmake.org/pipermail/cmake-developers/2018-June/030740.html

 

 

The longer history of how the feature evolved and was then reverted can be found here:

 

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

 

 

-- 

Craig Scott

Melbourne, Australia

https://crascit.com

 

New book released: Professional CMake: A Practical Guide

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

From robert.maynard at kitware.com  Thu Jul 19 10:25:20 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 19 Jul 2018 10:25:20 -0400
Subject: [CMake] CMake 3.12 rc2 to rc3 Regression
In-Reply-To: <9CE315D8-80AE-4323-BCD2-A9031D2FCFA0@bluequartz.net>
References: <9A135CAC-E202-4387-A80B-3A106F7EF2AB@bluequartz.net>
 <0FBE22F4-9E93-410E-A6E2-8A630DCDAD13@bluequartz.net>
 <CA+dygYnWEmzSx3wUTg1gRnQX5QR8Qy_0=Uu7yQwMFzjiErX-Aw@mail.gmail.com>
 <9CE315D8-80AE-4323-BCD2-A9031D2FCFA0@bluequartz.net>
Message-ID: <CAFzjYVrG6Pd7q=foC8tRhH985ST+W0pDhx5Gc+mkCReoU5_CBQ@mail.gmail.com>

The original author of the feature is looking at how to solve this
problem. The author has a post on the developer boards on some of the
changes needed to get everything to work:
https://cmake.org/pipermail/cmake-developers/2018-July/030760.html
On Thu, Jul 19, 2018 at 8:04 AM Michael Jackson
<mike.jackson at bluequartz.net> wrote:
>
> Thank you for the links.
>
>
>
> After reading through all the various discussions is there a time line of when the feature will be added back to CMake? Is it a matter of having somebody to work the problem? Is the problem solvable?
>
> --
>
> Michael Jackson | Owner, President
>
>       BlueQuartz Software
>
> [e] mike.jackson at bluequartz.net
>
> [w] www.bluequartz.net
>
>
>
> From: Craig Scott <craig.scott at crascit.com>
> Date: Wednesday, July 18, 2018 at 9:40 AM
> To: Michael Jackson <mike.jackson at bluequartz.net>
> Cc: CMake <cmake at cmake.org>
> Subject: Re: [CMake] CMake 3.12 rc2 to rc3 Regression
>
>
>
>
>
>
>
> On Wed, Jul 18, 2018 at 11:04 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
>
> Searching the mailing list archives for the RC3 announcement I scrolled to the bottom and found:
>
> Brad King (2):
>       Revert "target_link_libraries: Allow use with targets in other
> directories"
>       CMake 3.12.0-rc3
>
> Just curious what caused the issue to revert the change?
>
>
>
>
>
> The original problem report was on the dev mailing list:
>
>
>
> https://cmake.org/pipermail/cmake-developers/2018-June/030740.html
>
>
>
>
>
> The longer history of how the feature evolved and was then reverted can be found here:
>
>
>
> https://gitlab.kitware.com/cmake/cmake/issues/17943
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
>
> New book released: Professional CMake: A Practical Guide
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 rcdailey.lists at gmail.com  Thu Jul 19 11:05:06 2018
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 19 Jul 2018 10:05:06 -0500
Subject: [CMake] Parallel builds and auto generated header files
Message-ID: <CAHd499BfCB97An7ctUTMP=DgL8Xwe5Y3+KCprfjs442m9zHdAQ@mail.gmail.com>

I have a Version.hpp file that I have a custom command tied to which
basically runs CMake in script mode to perform configure_file() on it
during build time. The reason it does this is because it builds
Version.hpp using dynamic information, such as defining a macro with
the current SHA1 being built, etc.

I notice in parallel builds, this header file gets built too late,
because of parallel builds. What if a file includes the header and its
translation unit is built before Version.hpp is generated by the
custom command? Would it be better/simpler to do configure_file() at
configuration time instead of at build time as a custom command?
Here's the logic (some variables are defined elsewhere, but should
give you the gist):


set( generated_source_dir ${CMAKE_CURRENT_BINARY_DIR}/Source )
set( version_file_in  ${CMAKE_CURRENT_SOURCE_DIR}/Version.cpp.in )
set( version_file_out ${generated_source_dir}/Main/Version.cpp )

add_custom_command(
    OUTPUT ${version_file_out}
    COMMAND ${CMAKE_COMMAND}
        -D IN_FILE=${version_file_in}
        -D OUT_FILE=${version_file_out}
        -D GIT_EXECUTABLE=${GIT_EXECUTABLE}
        -D BUILD_VERSION=${ZIOSK_BUILD_VERSION}
        -P ${CMAKE_CURRENT_SOURCE_DIR}/build_version_header.cmake
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
)

source_group( Generated FILES ${version_file_out} )
list( APPEND source_files ${version_file_out} )

From Harry.Mallon at codex.online  Thu Jul 19 12:02:51 2018
From: Harry.Mallon at codex.online (Harry Mallon)
Date: Thu, 19 Jul 2018 16:02:51 +0000
Subject: [CMake] Packaging dylibs into app bundles
References: <c66d987b-bcc0-4df9-ae56-2ce2a5d908fd.854106ff-8da6-450b-a6ca-cb1b00d13cdf.164c3768-423a-46e8-a4aa-1b9d34a3ad1e@emailsignatures365.codetwo.com>
Message-ID: <1F542A5B-15A9-43CC-958A-3ED6296AD1A3@codex.online>

Hello all,

Is there a good tutorial/article on getting CMake to package required dylibs and frameworks into an app bundle for you on mac. We have a lot of custom stuff to do it and it is fragile and breaks a lot.

Thanks,
Harry

Harry Mallon

Senior Software Engineer

[http://codex.online/?action=asset&id=E3D62C3D-A12C-447D-87A5-F36E7C2AA9A4]<https://codex.online/>

T +44 203 7000 989<callto:+44%20203%207000%20989>

60 Poland Street | London | England | W1F 7NT

[http://codex.online/?action=asset&id=6F42BDF2-3C6D-4054-A5D2-277E0E535942]
Three Billboards        Blade Runner 2049        I, Tonya


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180719/1658081c/attachment.html>

From dbegun at protonmail.com  Thu Jul 19 12:00:13 2018
From: dbegun at protonmail.com (dbegun)
Date: Thu, 19 Jul 2018 12:00:13 -0400
Subject: [CMake] CPack multiple packages
Message-ID: <9TYGReAt2eRbxIpuUuF5AFtXfTpZkvUE_CUWHKgG8TN1a533LLWPfU6-hL-RdXNLoCJ0vS2KE2W6BDTQb1rH67I8v-HM9B_DaiuRg3ToO5Q=@protonmail.com>

I have a project where a lib and a binary requiring the lib are built in separate subdirs of the project root. Each dir contains its own CMakeLists.txt with build/install targets, and there is also a top level one, which mainly just adds subdirectories etc.
I want to add .deb package generation with cpack. When I place the following in either of the inner CMakeLists, a package containing the binary is built.

set(CPACK_BINARY_DEB "ON")
set(CPACK_GENERATOR "DEB")
set(CPACK_PACKAGE_NAME ${CMAKE_PROJECT_NAME})
set(CPACK_PACKAGE_VERSION ${PROJ_VERSION})
set(CPACK_PACKAGE_CONTACT "Denis Begun [dbegun at protonmail.](mailto:dbegun at allmonitoring.ru)com")
set(CPACK_PACKAGE_DESCRIPTION "proj")
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
include(CPack)

If I place it in both inner lists, nothing changes. If I place it in the top level CMakeList.txt, nothing is generated. The problem is that the package doesn't contain the library, so the binary can't run after installation.

What's the right direction to look in?

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180719/b4f6095f/attachment.html>

From bucknerj at umich.edu  Thu Jul 19 12:12:05 2018
From: bucknerj at umich.edu (Joshua Buckner)
Date: Thu, 19 Jul 2018 12:12:05 -0400
Subject: [CMake] Fortran and cmake_depends
Message-ID: <FAB42AFD-AC46-4E0F-A8FB-51FE6B79C436@umich.edu>

The command
/usr/bin/cmake -E cmake_depends "Unix Makefiles?
is taking 15 to 20 minutes to complete when I organize my Fortran 90 source files into subdirectories under a root directory with a single CMakeLists.txt file.

When the same F90 files are copied into a single directory on the same file system, cmake_depends takes no more than 30 seconds.

There are about 900,000 lines of F90 code organized into 700 files in 50 subdirectories.

Is there a way to use ?Unix Makefiles?, preserve the subdirectory structure and speed up cmake_depends?


From sjm324 at cornell.edu  Thu Jul 19 12:35:26 2018
From: sjm324 at cornell.edu (Stephen McDowell)
Date: Thu, 19 Jul 2018 09:35:26 -0700
Subject: [CMake] Packaging dylibs into app bundles
In-Reply-To: <1F542A5B-15A9-43CC-958A-3ED6296AD1A3@codex.online>
References: <c66d987b-bcc0-4df9-ae56-2ce2a5d908fd.854106ff-8da6-450b-a6ca-cb1b00d13cdf.164c3768-423a-46e8-a4aa-1b9d34a3ad1e@emailsignatures365.codetwo.com>
 <1F542A5B-15A9-43CC-958A-3ED6296AD1A3@codex.online>
Message-ID: <CAJGuVd8rjXUtO6SYQ-D44UHPk35mxeqYuqzk8=c8nT7GbPHnuQ@mail.gmail.com>

Hi Harry,

I don't know how useful this will be, but the Instant Meshes application
creates an app bundle that has always worked reliably for me. Looking at
the code, it doesn't appear like there's much custom stuff going on either.
It starts here

https://github.com/wjakob/instant-meshes/blob/011fa44ab72037cbc16535090a63ead41963c1e5/CMakeLists.txt#L151

And there's an if APPLE block below that appears to be the core.

Hope that is useful :) I've never actually done this for any of my own
projects though. And I'm pretty sure them setting the underlying GUI
library and TBB to be static (as opposed to shared) is skirting around the
issue that you are trying to solve (dylib stuff)...

-Stephen

On Thu, Jul 19, 2018, 9:03 AM Harry Mallon <Harry.Mallon at codex.online>
wrote:

> Hello all,
>
>
>
> Is there a good tutorial/article on getting CMake to package required
> dylibs and frameworks into an app bundle for you on mac. We have a lot of
> custom stuff to do it and it is fragile and breaks a lot.
>
>
>
> Thanks,
>
> Harry
>
> Harry Mallon
>
> Senior Software Engineer
>
> <https://codex.online/>
>
> T +44 203 7000 989 <callto:+44%20203%207000%20989>
>
> 60 Poland Street | London | England | W1F 7NT
> Three Billboards Blade Runner 2049  I, Tonya
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180719/f0f9fa4f/attachment.html>

From Harry.Mallon at codex.online  Thu Jul 19 14:04:01 2018
From: Harry.Mallon at codex.online (Harry Mallon)
Date: Thu, 19 Jul 2018 18:04:01 +0000
Subject: [CMake] Packaging dylibs into app bundles
In-Reply-To: <CAJGuVd8rjXUtO6SYQ-D44UHPk35mxeqYuqzk8=c8nT7GbPHnuQ@mail.gmail.com>
References: <c66d987b-bcc0-4df9-ae56-2ce2a5d908fd.854106ff-8da6-450b-a6ca-cb1b00d13cdf.164c3768-423a-46e8-a4aa-1b9d34a3ad1e@emailsignatures365.codetwo.com>
 <1F542A5B-15A9-43CC-958A-3ED6296AD1A3@codex.online>
 <CAJGuVd8rjXUtO6SYQ-D44UHPk35mxeqYuqzk8=c8nT7GbPHnuQ@mail.gmail.com>
Message-ID: <AAD8712F-8802-4F0F-9241-6F2A3D510AED@codex.online>

Hi,

I have been messing arounds with fixup_bundle (which seems to be the correct function). It worked for a small test case, but only if the dylibs required had otool ids of their full path. Ours currently have rpath based ones (e.g. @rpath/libcrypto.dylib). So I get a lot of:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: '@rpath/ libcrypto.dylib?: No such file or directory

Hmm, seems like the stuff is there somewhere to make this work?

Best,
Harry

From: Stephen McDowell <sjm324 at cornell.edu>
Date: Thursday, 19 July 2018 at 17:35
To: Harry Mallon <Harry.Mallon at codex.online>
Cc: CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] Packaging dylibs into app bundles

Hi Harry,

I don't know how useful this will be, but the Instant Meshes application creates an app bundle that has always worked reliably for me. Looking at the code, it doesn't appear like there's much custom stuff going on either. It starts here

https://github.com/wjakob/instant-meshes/blob/011fa44ab72037cbc16535090a63ead41963c1e5/CMakeLists.txt#L151

And there's an if APPLE block below that appears to be the core.

Hope that is useful :) I've never actually done this for any of my own projects though. And I'm pretty sure them setting the underlying GUI library and TBB to be static (as opposed to shared) is skirting around the issue that you are trying to solve (dylib stuff)...

-Stephen

On Thu, Jul 19, 2018, 9:03 AM Harry Mallon <Harry.Mallon at codex.online> wrote:
Hello all,

Is there a good tutorial/article on getting CMake to package required dylibs and frameworks into an app bundle for you on mac. We have a lot of custom stuff to do it and it is fragile and breaks a lot.

Thanks,
Harry

Harry Mallon

Senior Software Engineer

[Image removed by sender.]<https://codex.online/>

T +44 203 7000 989<callto:+44%20203%207000%20989>

60 Poland Street | London | England | W1F 7NT
[Image removed by sender.]

Three Billboards

Blade Runner 2049

 I, Tonya


--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180719/043193fd/attachment-0001.html>

From domen.vrankar at gmail.com  Thu Jul 19 18:40:11 2018
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 20 Jul 2018 00:40:11 +0200
Subject: [CMake] CPack multiple packages
In-Reply-To: <9TYGReAt2eRbxIpuUuF5AFtXfTpZkvUE_CUWHKgG8TN1a533LLWPfU6-hL-RdXNLoCJ0vS2KE2W6BDTQb1rH67I8v-HM9B_DaiuRg3ToO5Q=@protonmail.com>
References: <9TYGReAt2eRbxIpuUuF5AFtXfTpZkvUE_CUWHKgG8TN1a533LLWPfU6-hL-RdXNLoCJ0vS2KE2W6BDTQb1rH67I8v-HM9B_DaiuRg3ToO5Q=@protonmail.com>
Message-ID: <CAKgx6BJKOwqLHqCho9Ohh0qFyvG9v0u-rxSf_2BrAnSfzkHuJw@mail.gmail.com>

2018-07-19 18:00 GMT+02:00 dbegun via CMake <cmake at cmake.org>:

> I have a project where a lib and a binary requiring the lib are built in
> separate subdirs of the project root. Each dir contains its own
> CMakeLists.txt with build/install targets, and there is also a top level
> one, which mainly just adds subdirectories etc.
> I want to add .deb package generation with cpack. When I place the
> following in either of the inner CMakeLists, a package containing the
> binary is built.
>
> set(CPACK_BINARY_DEB "ON")
> set(CPACK_GENERATOR "DEB")
> set(CPACK_PACKAGE_NAME ${CMAKE_PROJECT_NAME})
> set(CPACK_PACKAGE_VERSION ${PROJ_VERSION})
> set(CPACK_PACKAGE_CONTACT "Denis Begun dbegun at protonmail.
> <dbegun at allmonitoring.ru>com")
> set(CPACK_PACKAGE_DESCRIPTION "proj")
> set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
> include(CPack)
>
> If I place it in both inner lists, nothing changes. If I place it in the
> top level CMakeList.txt, nothing is generated. The problem is that the
> package doesn't contain the library, so the binary can't run after
> installation.
>
> What's the right direction to look in?
>

Have you tried placing the include(CPack) at the bottom of the top level
CMakeLists.txt after the rest of the CMakeLists.txt files have been
included?

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180720/1b2bbb02/attachment.html>

From mike.jackson at bluequartz.net  Thu Jul 19 22:13:47 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 19 Jul 2018 22:13:47 -0400
Subject: [CMake] Packaging dylibs into app bundles
In-Reply-To: <AAD8712F-8802-4F0F-9241-6F2A3D510AED@codex.online>
References: <c66d987b-bcc0-4df9-ae56-2ce2a5d908fd.854106ff-8da6-450b-a6ca-cb1b00d13cdf.164c3768-423a-46e8-a4aa-1b9d34a3ad1e@emailsignatures365.codetwo.com>
 <1F542A5B-15A9-43CC-958A-3ED6296AD1A3@codex.online>
 <CAJGuVd8rjXUtO6SYQ-D44UHPk35mxeqYuqzk8=c8nT7GbPHnuQ@mail.gmail.com>
 <AAD8712F-8802-4F0F-9241-6F2A3D510AED@codex.online>
Message-ID: <17642ACC-46A8-457B-8874-34D386D8BD56@bluequartz.net>

You need to pass in more paths to the ?fixup_bundle()? method. Those paths are the paths where the libraries are located so CMake has somewhere else to look in case the absolute path is not encoded in the dylib itself. I could point you to our project but it is pretty scary in there. We use a custom generated CMake script that does a bunch of extra stuff that Qt requires (qt.conf) and stuff like that. Does work reliably for use once we got it setup.

 

https://github.com/BlueQuartzSoftware/CMP/tree/develop/OSX_Tools

https://github.com/BlueQuartzSoftware/CMP/blob/develop/OSX_Tools/CompleteBundle.cmake.in

https://github.com/BlueQuartzSoftware/CMP/blob/develop/OSX_Tools/MacOSXBundleInfo.plist.in

 

They probably are not an ?exemplar? of how to do things as they were created when CMake 3.1 was new so there are probably better ways to get the same thing done but this works in our environment. I have a whole separate bash script that lets us create a signed .dmg file.

 

--

Mike Jackson

 

On 7/19/18, 2:04 PM, "CMake on behalf of Harry Mallon" <cmake-bounces at cmake.org on behalf of Harry.Mallon at codex.online> wrote:

 

Hi,

 

I have been messing arounds with fixup_bundle (which seems to be the correct function). It worked for a small test case, but only if the dylibs required had otool ids of their full path. Ours currently have rpath based ones (e.g. @rpath/libcrypto.dylib). So I get a lot of:

 

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: '@rpath/ libcrypto.dylib?: No such file or directory  

 

Hmm, seems like the stuff is there somewhere to make this work?

 

Best,

Harry

 

From: Stephen McDowell <sjm324 at cornell.edu>
Date: Thursday, 19 July 2018 at 17:35
To: Harry Mallon <Harry.Mallon at codex.online>
Cc: CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] Packaging dylibs into app bundles

 

Hi Harry, 

 

I don't know how useful this will be, but the Instant Meshes application creates an app bundle that has always worked reliably for me. Looking at the code, it doesn't appear like there's much custom stuff going on either. It starts here

 

https://github.com/wjakob/instant-meshes/blob/011fa44ab72037cbc16535090a63ead41963c1e5/CMakeLists.txt#L151

 

And there's an if APPLE block below that appears to be the core.

 

Hope that is useful :) I've never actually done this for any of my own projects though. And I'm pretty sure them setting the underlying GUI library and TBB to be static (as opposed to shared) is skirting around the issue that you are trying to solve (dylib stuff)...

 

-Stephen

 

On Thu, Jul 19, 2018, 9:03 AM Harry Mallon <Harry.Mallon at codex.online> wrote:

Hello all,

 

Is there a good tutorial/article on getting CMake to package required dylibs and frameworks into an app bundle for you on mac. We have a lot of custom stuff to do it and it is fragile and breaks a lot.

 

Thanks,

Harry

Harry Mallon

Senior Software Engineer

T +44 203 7000 989 

60 Poland Street | London | England | W1F 7NT 

Three BillboardsBlade Runner 2049  I, Tonya

 

-- 

Powered by www.kitware.com

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

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

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

From raphael.grimm at kit.edu  Fri Jul 20 01:39:41 2018
From: raphael.grimm at kit.edu (Raphael Grimm)
Date: Fri, 20 Jul 2018 07:39:41 +0200
Subject: [CMake] CMake all_object_files target
Message-ID: <1f0ebb28-4ed1-f4d7-a30c-b5e6adcab590@kit.edu>

Hi,

I want to create a CMake target to build all object files. To do this, I 
first modified all targets to build an object file lib and link against it:

 ??? add_library(exe_object_files OBJECT ${sources})
 ??? set(ARMARX_EXE_OBJECT_FILES $<TARGET_OBJECTS:exe_object_files>)
 ??? add_executable(exe $<TARGET_OBJECTS:exe_object_files>)

Since I have multiple executables, I added a target for all object files 
and added the targets for each executable as dependency:

 ??? add_custom_target(all_exe_object_files)
 ??? add_dependencies(all_exe_object_files exe_object_files)

This adds a all_exe_object_files target I can make, but making the 
target does nothing.
Then I tried adding the object files as sources:

 ??? get_target_property(all_exe_object_files_sources 
all_exe_object_files SOURCES)
 ??? if(NOT all_exe_object_files_sources)
 ??????? set(all_exe_object_files_sources)
 ??? endif()
 ??? list(APPEND all_exe_object_files_sources 
$<TARGET_OBJECTS:exe_object_files>)
 ??? set_target_properties(all_exe_object_files PROPERTIES SOURCES 
"${all_exe_object_files_sources}")

This did not help.

I guess the reason is that add_library(... OBJECT ...) behaves similar 
to add_custom_command and the files are only build if a target uses them 
(and my custom target probably does not count as using the generated files).

What am I doing wrong and how can I create a target to build all object 
files?

Thanks for all hints.
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/20180720/6dfb9b7f/attachment-0001.bin>

From ardillasdelmonte at gmail.com  Fri Jul 20 06:12:13 2018
From: ardillasdelmonte at gmail.com (ardi)
Date: Fri, 20 Jul 2018 12:12:13 +0200
Subject: [CMake] Querying project dependencies from the UNIX command-line
In-Reply-To: <4508371.rsHKcPBH81@mani>
References: <CA+fZqCUYbsVSuA=AQFnJU7+Lc9W-Y=P5c-uWSQ=_Y+wAFXVheQ@mail.gmail.com>
 <4508371.rsHKcPBH81@mani>
Message-ID: <CA+fZqCVnwft3zGC88BA9cBTw+3Qw9j7zfO57cEMhd2xKD5monQ@mail.gmail.com>

On Wed, Jul 18, 2018 at 10:04 PM, Johannes Zarl-Zierl
<johannes at zarl-zierl.at> wrote:
> Hi Ardi,
>
> Am Mittwoch, 18. Juli 2018, 11:31:50 CEST schrieb ardi:
>> For example, I'd like to type "somecommand /path/to/someproject" at
>> the UNIX command line, and get this output:
>> [...]
>> Furthermore, if another command could show optional requisites, it
>> would be really great: "anothercommand /path/to/someproject"
>>
>> Project /path/to/someproject can optionally use the following when being
>> built:
>> [...]
>> So, can I get this functionality from plain CMake/CPack ? Or would I
>> need additional tools (Note: I know about Hunter, but first I'd like
>> to know if plain CMake does already offer this feature).
>
> I don't think there's something that gives you exactly what you described,
> especially not for a random CMake project.
>
> If you can add some commands to the CMakeLists.txt, though, then the
> FeatureSummary module may suit your needs.
>
> Basically, you include the module an then add a cmake command like this:
> feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)
>
> When you run cmake, you'll get a summary of which packages have been found/not
> found, and the required version if you supplied one for the corresponding
> find_package command.
>
> Cheers,
>   Johannes

Thanks a lot, Johannes!! I was talking about querying such info
without tweaking the CMakeLists.txt, just taking it as it comes from
each project developer. Anyway, the info about required and optional
dependencies is within the CMakeLists.txt of every project, and of
course CMake gets all that info when building a project, so I'm
guessing that, even if there's currently no command-line flag for
telling CMake to dump to stdout the required or the optional
dependencies, it shouldn't be hard to patch CMake for adding such
flag, or alternatively writing a simple utility that does the job,
linked with a small part of the CMake source code.

Thanks!

ardi

From Harry.Mallon at codex.online  Fri Jul 20 07:41:57 2018
From: Harry.Mallon at codex.online (Harry Mallon)
Date: Fri, 20 Jul 2018 11:41:57 +0000
Subject: [CMake] Packaging dylibs into app bundles
In-Reply-To: <AAD8712F-8802-4F0F-9241-6F2A3D510AED@codex.online>
References: <c66d987b-bcc0-4df9-ae56-2ce2a5d908fd.854106ff-8da6-450b-a6ca-cb1b00d13cdf.164c3768-423a-46e8-a4aa-1b9d34a3ad1e@emailsignatures365.codetwo.com>
 <1F542A5B-15A9-43CC-958A-3ED6296AD1A3@codex.online>
 <CAJGuVd8rjXUtO6SYQ-D44UHPk35mxeqYuqzk8=c8nT7GbPHnuQ@mail.gmail.com>
 <AAD8712F-8802-4F0F-9241-6F2A3D510AED@codex.online>
Message-ID: <5D0A8680-4956-49DD-A5F3-9C030276999E@codex.online>

Hi all,

Fixup_bundle works very well for app bundles and seems to be the way to go! The problem I was previously seeing was fixed by setting CMAKE_INSTALL_RPATH_USE_LINK_PATH to True. This fills in the rpath on the installed executable with enough paths to resolve all the dylibs.

I also added a merge request to cmake to fail more obviously if the file cannot be found as in previous message.

My next question is: Is there a way to do a fixup bundle without a bundle?

i.e. I want to fixup (copy required dylibs, fix otool ids and rpaths etc) a structure like this:

/usr/local/myapp/bin/myapp
/usr/local/myapp/lib/libA.dylib
/usr/local/myapp/lib/libB.dylib # etc


Is there a sensible way to do this without rewriting a lot of Bundle Utilities?

Best,
Harry


From: Harry Mallon <Harry.Mallon at codex.online>
Date: Thursday, 19 July 2018 at 19:04
To: Stephen McDowell <sjm324 at cornell.edu>
Cc: CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] Packaging dylibs into app bundles

Hi,

I have been messing arounds with fixup_bundle (which seems to be the correct function). It worked for a small test case, but only if the dylibs required had otool ids of their full path. Ours currently have rpath based ones (e.g. @rpath/libcrypto.dylib). So I get a lot of:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: '@rpath/ libcrypto.dylib?: No such file or directory

Hmm, seems like the stuff is there somewhere to make this work?

Best,
Harry

From: Stephen McDowell <sjm324 at cornell.edu>
Date: Thursday, 19 July 2018 at 17:35
To: Harry Mallon <Harry.Mallon at codex.online>
Cc: CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] Packaging dylibs into app bundles

Hi Harry,

I don't know how useful this will be, but the Instant Meshes application creates an app bundle that has always worked reliably for me. Looking at the code, it doesn't appear like there's much custom stuff going on either. It starts here

https://github.com/wjakob/instant-meshes/blob/011fa44ab72037cbc16535090a63ead41963c1e5/CMakeLists.txt#L151

And there's an if APPLE block below that appears to be the core.

Hope that is useful :) I've never actually done this for any of my own projects though. And I'm pretty sure them setting the underlying GUI library and TBB to be static (as opposed to shared) is skirting around the issue that you are trying to solve (dylib stuff)...

-Stephen

On Thu, Jul 19, 2018, 9:03 AM Harry Mallon <Harry.Mallon at codex.online> wrote:
Hello all,

Is there a good tutorial/article on getting CMake to package required dylibs and frameworks into an app bundle for you on mac. We have a lot of custom stuff to do it and it is fragile and breaks a lot.

Thanks,
Harry

Harry Mallon

Senior Software Engineer

[Image removed by sender.]<https://codex.online/>

T +44 203 7000 989<callto:+44%20203%207000%20989>

60 Poland Street | London | England | W1F 7NT
[Image removed by sender.]

Three Billboards

Blade Runner 2049

 I, Tonya


--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180720/84e09011/attachment-0001.html>

From James.Buster at transunion.com  Fri Jul 20 11:48:01 2018
From: James.Buster at transunion.com (Buster, James)
Date: Fri, 20 Jul 2018 15:48:01 +0000
Subject: [CMake] Is this an intended change to cmake behavior in cmake 3.12?
Message-ID: <32af6d80ad574bd09e19be8f90a4709d@transunion.com>

CMakeLists.txt:
cmake_minimum_required(VERSION 3.7 FATAL_ERROR)

list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR})

include(foo)

#macro(test_project2 name target)
#    project(${name} ${ARGN})
#endmacro(test_project2)

test_project(runtime TRUE VERSION 1.0)

foo.cmake:
macro(test_project name target)
    project(${name} ${ARGN})
endmacro(test_project)

The test:
Save the two files then run "cmake ." on this CMakeLists.txt twice in succession.

Using cmake 3.11 or earlier: no problems
Using cmake 3.12: the second "cmake ." issues the following warning:
CMake Warning (dev) in CMakeLists.txt:
  Policy CMP0048 is not set: project() command manages VERSION variables.
  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The following variable(s) would be set to empty:

    CMAKE_PROJECT_VERSION
    CMAKE_PROJECT_VERSION_MAJOR
    CMAKE_PROJECT_VERSION_MINOR

That by itself is weird, but it gets better. See the "test_project2" macro in CMakeLists.txt? Simply uncomment it.
Even though it isn't called, uncommenting that macro causes the "Policy CMP0048" warning to disappear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180720/2e1725be/attachment-0001.html>

From afuller at teradici.com  Mon Jul 23 14:50:06 2018
From: afuller at teradici.com (Andrew Fuller)
Date: Mon, 23 Jul 2018 18:50:06 +0000
Subject: [CMake] Parallel builds and auto generated header files
In-Reply-To: <CAHd499BfCB97An7ctUTMP=DgL8Xwe5Y3+KCprfjs442m9zHdAQ@mail.gmail.com>
References: <CAHd499BfCB97An7ctUTMP=DgL8Xwe5Y3+KCprfjs442m9zHdAQ@mail.gmail.com>
Message-ID: <BYAPR02MB4904717E8CE2E482ECE685ABD5560@BYAPR02MB4904.namprd02.prod.outlook.com>

Using configure_file() at CMake time will appear to work at first glance, but you'll wind up with stale information when you change revisions without any CMake change.  CMake won't re-run automatically and thus your header file won't get updated.  You'll need to do it at build time to ensure it's always up-to-date.

How do the translation units obtain the generated header?  There needs to be some form of dependency between the generated header and the consumer(s).  If you add the generated header as an input to another target, then CMake should ensure the file is generated before processing the dependant target.

Also note that AFAICT add_custom_command will not re-run if the output file already exists (unless invalidated by a dependency).  Since you're grabbing dynamic information like the commit hash, then you likely want it to run _every_ time.  add_custom_target might be better suited for your needs.
________________________________
From: CMake <cmake-bounces at cmake.org> on behalf of Robert Dailey <rcdailey.lists at gmail.com>
Sent: July 19, 2018 8:05:06 AM
To: CMake
Subject: [CMake] Parallel builds and auto generated header files

I have a Version.hpp file that I have a custom command tied to which
basically runs CMake in script mode to perform configure_file() on it
during build time. The reason it does this is because it builds
Version.hpp using dynamic information, such as defining a macro with
the current SHA1 being built, etc.

I notice in parallel builds, this header file gets built too late,
because of parallel builds. What if a file includes the header and its
translation unit is built before Version.hpp is generated by the
custom command? Would it be better/simpler to do configure_file() at
configuration time instead of at build time as a custom command?
Here's the logic (some variables are defined elsewhere, but should
give you the gist):


set( generated_source_dir ${CMAKE_CURRENT_BINARY_DIR}/Source )
set( version_file_in  ${CMAKE_CURRENT_SOURCE_DIR}/Version.cpp.in )
set( version_file_out ${generated_source_dir}/Main/Version.cpp )

add_custom_command(
    OUTPUT ${version_file_out}
    COMMAND ${CMAKE_COMMAND}
        -D IN_FILE=${version_file_in}
        -D OUT_FILE=${version_file_out}
        -D GIT_EXECUTABLE=${GIT_EXECUTABLE}
        -D BUILD_VERSION=${ZIOSK_BUILD_VERSION}
        -P ${CMAKE_CURRENT_SOURCE_DIR}/build_version_header.cmake
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
)

source_group( Generated FILES ${version_file_out} )
list( APPEND source_files ${version_file_out} )
--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180723/8df4c00f/attachment.html>

From isaiah.norton at gmail.com  Tue Jul 24 10:03:37 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Tue, 24 Jul 2018 10:03:37 -0400
Subject: [CMake] Parallel builds and auto generated header files
In-Reply-To: <BYAPR02MB4904717E8CE2E482ECE685ABD5560@BYAPR02MB4904.namprd02.prod.outlook.com>
References: <CAHd499BfCB97An7ctUTMP=DgL8Xwe5Y3+KCprfjs442m9zHdAQ@mail.gmail.com>
 <BYAPR02MB4904717E8CE2E482ECE685ABD5560@BYAPR02MB4904.namprd02.prod.outlook.com>
Message-ID: <CADFtqoo2-tqysNuaG=H5xyyniLnM_1HBEq9AwcSWn_dj82OWxw@mail.gmail.com>

I use essentially the technique in the answer below, except with
`add_custom_target` instead of `add_custom_command`, so that the
hash-generation is always run regardless of whether the temp file is
successfully deleted:

https://stackoverflow.com/a/41750028/508431

I also use a dummy `add_custom_command` which depends on GITVER_FILE as in
the above. IIRC the reason was that in my use case GITVER_FILE is passed as
part of a sources list to a macro, and defining the custom command was the
only way I could find to properly enforce an ordering dependency in
parallel builds:

# dummy output so we can depend on it in the external macro, because CMake.
add_custom_command(OUTPUT "${GITVER_FILE}"
                                      DEPENDS _GEN_GITVER)

(I think it was fine running `add_executable`/`add_library` directly in the
current CMakeList, but ordering didn't work when passing to a macro -- at
least in the version of cmake where I developed this)

On Mon, Jul 23, 2018 at 2:50 PM Andrew Fuller <afuller at teradici.com> wrote:

> Using configure_file() at CMake time will appear to work at first glance,
> but you'll wind up with stale information when you change revisions without
> any CMake change.  CMake won't re-run automatically and thus your header
> file won't get updated.  You'll need to do it at build time to ensure it's
> always up-to-date.
>
> How do the translation units obtain the generated header?  There needs to
> be some form of dependency between the generated header and the
> consumer(s).  If you add the generated header as an input to another
> target, then CMake should ensure the file is generated before processing
> the dependant target.
>
> Also note that AFAICT add_custom_command will not re-run if the output
> file already exists (unless invalidated by a dependency).  Since you're
> grabbing dynamic information like the commit hash, then you likely want it
> to run _every_ time.  add_custom_target might be better suited for your
> needs.
> ------------------------------
> *From:* CMake <cmake-bounces at cmake.org> on behalf of Robert Dailey <
> rcdailey.lists at gmail.com>
> *Sent:* July 19, 2018 8:05:06 AM
> *To:* CMake
> *Subject:* [CMake] Parallel builds and auto generated header files
>
> I have a Version.hpp file that I have a custom command tied to which
> basically runs CMake in script mode to perform configure_file() on it
> during build time. The reason it does this is because it builds
> Version.hpp using dynamic information, such as defining a macro with
> the current SHA1 being built, etc.
>
> I notice in parallel builds, this header file gets built too late,
> because of parallel builds. What if a file includes the header and its
> translation unit is built before Version.hpp is generated by the
> custom command? Would it be better/simpler to do configure_file() at
> configuration time instead of at build time as a custom command?
> Here's the logic (some variables are defined elsewhere, but should
> give you the gist):
>
>
> set( generated_source_dir ${CMAKE_CURRENT_BINARY_DIR}/Source )
> set( version_file_in  ${CMAKE_CURRENT_SOURCE_DIR}/Version.cpp.in )
> set( version_file_out ${generated_source_dir}/Main/Version.cpp )
>
> add_custom_command(
>     OUTPUT ${version_file_out}
>     COMMAND ${CMAKE_COMMAND}
>         -D IN_FILE=${version_file_in}
>         -D OUT_FILE=${version_file_out}
>         -D GIT_EXECUTABLE=${GIT_EXECUTABLE}
>         -D BUILD_VERSION=${ZIOSK_BUILD_VERSION}
>         -P ${CMAKE_CURRENT_SOURCE_DIR}/build_version_header.cmake
>     WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
> )
>
> source_group( Generated FILES ${version_file_out} )
> list( APPEND source_files ${version_file_out} )
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180724/1bc50a1c/attachment-0001.html>

From brad.king at kitware.com  Tue Jul 24 10:28:05 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 24 Jul 2018 10:28:05 -0400
Subject: [CMake] Is this an intended change to cmake behavior in cmake
 3.12?
In-Reply-To: <32af6d80ad574bd09e19be8f90a4709d@transunion.com>
References: <32af6d80ad574bd09e19be8f90a4709d@transunion.com>
Message-ID: <f930ca4e-e752-4039-f49a-3220d28ad015@kitware.com>

On 07/20/2018 11:48 AM, Buster, James wrote:
> Using cmake 3.12: the second ?cmake .? issues the following warning:
> CMake Warning (dev) in CMakeLists.txt:
> ? Policy CMP0048 is not set: project() command manages VERSION variables.

Thanks.  I opened an issue for it:

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

Please see that issue for further discussion.

> See the ?test_project2? macro in CMakeLists.txt? Simply uncomment it.
> Even though it isn?t called, uncommenting that macro causes the
> ?Policy CMP0048? warning to disappear.

If no project() command appears anywhere in the top-level CMakeLists.txt
file then one is injected on line zero.  That is the one that causes
the warning.  When it is present in the inline macro then no injection
is done.  It's strange but that's how things evolved.

-Brad

From brad.king at kitware.com  Tue Jul 24 10:34:20 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 24 Jul 2018 10:34:20 -0400
Subject: [CMake] Is this an intended change to cmake behavior in cmake
 3.12?
In-Reply-To: <f930ca4e-e752-4039-f49a-3220d28ad015@kitware.com>
References: <32af6d80ad574bd09e19be8f90a4709d@transunion.com>
 <f930ca4e-e752-4039-f49a-3220d28ad015@kitware.com>
Message-ID: <8d43108b-629f-879c-ff78-167c7aabce4e@kitware.com>

On 07/24/2018 10:28 AM, Brad King wrote:
> If no project() command appears anywhere in the top-level CMakeLists.txt
> file then one is injected on line zero.

FWIW, see this note in the project command docs:

  https://cmake.org/cmake/help/v3.12/command/project.html

"The top-level CMakeLists.txt file for a project must contain a literal,
 direct call to the project() command..."

While we can look into the issue, please also update your project
to follow this recommendation.

-Brad

From quang.t.ha.20 at gmail.com  Tue Jul 24 16:47:57 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Tue, 24 Jul 2018 14:47:57 -0600
Subject: [CMake] CMAKE doesn't pass NVCC flags?
Message-ID: <CAGfE9+M0KouWihAN5f+j0i00rFoTuUUxAoq0DxZwkdggmU=trA@mail.gmail.com>

So, it doesn't seem that my setting in NVCC flags is being used:

In CMakeLists.txt:

project(tangram LANGUAGES CXX CUDA)
[...]

    FIND_PACKAGE(CUDA REQUIRED)
    if(CUDA_FOUND)
      add_definitions(-DCUDA_CALLABLE="__host__ __device__")
      set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-Xcompiler="-fopenmp -fPIC")
      set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--std=c++11
--expt-relaxed-constexpr)
      set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
arch=compute_70,code=sm_70)
      set(CUDA_PROPAGATE_HOST_FLAGS ON)
      set(CUDA_SEPARABLE_COMPILATION OFF)
      message(STATUS "CUDA include directories ${CUDA_INCLUDE_DIRS}")
      message(STATUS "Overwriting THRUST_DIR to point to
${CUDA_INCLUDE_DIRS}/thrust")
      set(THRUST_DIR "${CUDA_INCLUDE_DIRS}")
      set(EXTRA_LIBS ${CUDA_LIBRARIES})
      message("CUDA flags" ${CUDA_NVCC_FLAGS})
    else(CUDA_FOUND)
      message(FATAL "CUDA not found")
    endif(CUDA_FOUND)
[...]

Then, at cmake stage:
[...]
-- Overwriting THRUST_DIR to point to
/projects/opt/centos7/cuda/9.0/include/thrust
CUDA flags-Xcompiler="-fopenmp
-fPIC"--std=c++11--expt-relaxed-constexpr-gencodearch=compute_70,code=sm_70
-- Adding application directory app
[...]

But then, build fail, and when I do make VERBOSE=1:
[...]
[ 60%] Building CUDA object
app/simple-vfgen-cuda/CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
cd /home/qth20/develop/tangram/build/app/simple-vfgen-cuda &&
/projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__
__device__\"" -DHAVE_LAPACKE -DTHRUST
-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -I/home/qth20/develop/tangram
-I/home/qth20/develop/tangram/build
-I/home/qth20/develop/tangram/cinch/logging
-I/home/qth20/installed/jali/include
-I/home/qth20/installed/jali-tpls/include
-I/home/qth20/installed/jali-tpls/trilinos-12-10-1/include
-I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include
-I/home/qth20/installed/jali-tpls/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
-I/home/qth20/installed/jali-tpls/include/UnitTest++ -I/usr/include/lapacke
-I/home/qth20/installed/xmof2d/include
-I/projects/opt/centos7/cuda/9.0/include  -O3 -DNDEBUG   -std=c++11 -x cu
-c /home/qth20/develop/tangram/app/simple-vfgen-cuda/simple-vfgen-cuda.cu
-o CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
[...]

None of the flags was passed into nvcc. This is with cmake/3.11.1. Does
upgrading to 3.12 recommended to solve the issue?

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180724/aecccec5/attachment.html>

From sjm324 at cornell.edu  Tue Jul 24 17:55:45 2018
From: sjm324 at cornell.edu (Stephen McDowell)
Date: Tue, 24 Jul 2018 14:55:45 -0700
Subject: [CMake] CMAKE doesn't pass NVCC flags?
In-Reply-To: <CAGfE9+M0KouWihAN5f+j0i00rFoTuUUxAoq0DxZwkdggmU=trA@mail.gmail.com>
References: <CAGfE9+M0KouWihAN5f+j0i00rFoTuUUxAoq0DxZwkdggmU=trA@mail.gmail.com>
Message-ID: <CAJGuVd-h=dMn9hqSDs4hkaCM3Z6z=uJzgCo=08Br_8D82+E-4g@mail.gmail.com>

I think you are mixing old and new approaches. Since you have enabled the
CUDA language (via your project(...) call), you should be using either
CUDAFLAGS or CMAKE_CUDA_FLAGS.

I think CUDA_NVCC_FLAGS is only used for the old cuda_add_library or
executable functions.

Note that finding the cuda package should no longer be necessary. If you
support non-CUDA builds you should use CheckLanguage and
enable_language(CUDA), and remove CUDA from the project(...) call.
Currently if nvcc is not found, configuration will fail because you have
CUDA in the project command which makes it required.

Hope that helps!

-Stephen

On Tue, Jul 24, 2018, 1:48 PM Quang Ha <quang.t.ha.20 at gmail.com> wrote:

> So, it doesn't seem that my setting in NVCC flags is being used:
>
> In CMakeLists.txt:
>
> project(tangram LANGUAGES CXX CUDA)
> [...]
>
>     FIND_PACKAGE(CUDA REQUIRED)
>     if(CUDA_FOUND)
>       add_definitions(-DCUDA_CALLABLE="__host__ __device__")
>       set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-Xcompiler="-fopenmp -fPIC")
>       set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--std=c++11
> --expt-relaxed-constexpr)
>       set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
> arch=compute_70,code=sm_70)
>       set(CUDA_PROPAGATE_HOST_FLAGS ON)
>       set(CUDA_SEPARABLE_COMPILATION OFF)
>       message(STATUS "CUDA include directories ${CUDA_INCLUDE_DIRS}")
>       message(STATUS "Overwriting THRUST_DIR to point to
> ${CUDA_INCLUDE_DIRS}/thrust")
>       set(THRUST_DIR "${CUDA_INCLUDE_DIRS}")
>       set(EXTRA_LIBS ${CUDA_LIBRARIES})
>       message("CUDA flags" ${CUDA_NVCC_FLAGS})
>     else(CUDA_FOUND)
>       message(FATAL "CUDA not found")
>     endif(CUDA_FOUND)
> [...]
>
> Then, at cmake stage:
> [...]
> -- Overwriting THRUST_DIR to point to
> /projects/opt/centos7/cuda/9.0/include/thrust
> CUDA flags-Xcompiler="-fopenmp
> -fPIC"--std=c++11--expt-relaxed-constexpr-gencodearch=compute_70,code=sm_70
> -- Adding application directory app
> [...]
>
> But then, build fail, and when I do make VERBOSE=1:
> [...]
> [ 60%] Building CUDA object
> app/simple-vfgen-cuda/CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
> cd /home/qth20/develop/tangram/build/app/simple-vfgen-cuda &&
> /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__
> __device__\"" -DHAVE_LAPACKE -DTHRUST
> -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
> -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -I/home/qth20/develop/tangram
> -I/home/qth20/develop/tangram/build
> -I/home/qth20/develop/tangram/cinch/logging
> -I/home/qth20/installed/jali/include
> -I/home/qth20/installed/jali-tpls/include
> -I/home/qth20/installed/jali-tpls/trilinos-12-10-1/include
> -I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include
> -I/home/qth20/installed/jali-tpls/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
> -I/home/qth20/installed/jali-tpls/include/UnitTest++ -I/usr/include/lapacke
> -I/home/qth20/installed/xmof2d/include
> -I/projects/opt/centos7/cuda/9.0/include  -O3 -DNDEBUG   -std=c++11 -x cu
> -c /home/qth20/develop/tangram/app/simple-vfgen-cuda/simple-vfgen-cuda.cu
> -o CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
> [...]
>
> None of the flags was passed into nvcc. This is with cmake/3.11.1. Does
> upgrading to 3.12 recommended to solve the issue?
>
> 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/20180724/5de48b59/attachment.html>

From jason.heeris at gmail.com  Wed Jul 25 02:09:20 2018
From: jason.heeris at gmail.com (Jason Heeris)
Date: Wed, 25 Jul 2018 16:09:20 +1000
Subject: [CMake] How do I use install() with targets that might not be built?
Message-ID: <CA+Zd3Ff1+tXSv225f+NN+9m_C52eYzys5TU3V-5XBkiJCzPhpw@mail.gmail.com>

My project consists of a lot of "module" style targets (static libraries,
more or less), but only a few top-level targets that a user would actually
want to build. The "all" target is empty, that is, every target has
"EXCLUDE_FROM_ALL" set. The user will, at compile time, decide to build
whichever target they need. A single target may depend on a couple of
others, so the end result of a single target being built might be eg. an
exe file plus a dll plus a couple of other things.

But I also want to provide installation capabilities, so users don't have
to hunt down exes and libs scattered throughout CMake's build tree. I might
want to create installers using CPack at some point too.

How do I do this if all of my targets are EXCLUDE_FROM_ALL? According to
the documentation, even if I use the OPTIONAL flag in install(), the
behaviour is undefined. Better not do that.

The only other option I see is to create custom commands (POST_BUILD style)
for every target that copies it to some designated output directory. But
then I can't take advantage of CMake's other installation capabilities, and
I think that would be invisible to CPack.

Is there some other way?

I'm using CMake 3.12 on Windows 10/Ubuntu 18.04, if that's relevant.

Cheers,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180725/ea6e5204/attachment.html>

From michael.hennebry at rivieranexus.com  Wed Jul 25 18:47:14 2018
From: michael.hennebry at rivieranexus.com (Michael Hennebry)
Date: Wed, 25 Jul 2018 17:47:14 -0500
Subject: [CMake] GLOB_RECURSE
Message-ID: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>

Emphasis on curse.

from CMakeLists.txt:

file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)

message("apps:;${apps};:apps")
message("ards:;${ards};:ards")

Both lists have ArduinoCore and SensorUnit sources.
They both have precisely 57 entries.
They both have three entries from sb-build.

What is going on?

>From the siblings' parent:
$ ls -F
ArduinoCore/    SensorUnit/              generic-gcc-avr.cmake
CMakeLists.txt  from-build-directory.sh  sb-build/

I tried RELATIVE.
I tried replacing the dot with ${CMAKE_SOURCE_DIR}.
All to no avail.

I'm stumped.

From frodak17 at gmail.com  Wed Jul 25 20:02:23 2018
From: frodak17 at gmail.com (frodak)
Date: Wed, 25 Jul 2018 20:02:23 -0400
Subject: [CMake] GLOB_RECURSE
In-Reply-To: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
Message-ID: <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>

 I think you want to try for absolute paths:
file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)

relative paths from those directories:
file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
./SensorUnit/*.c)



On Wed, Jul 25, 2018 at 6:47 PM, Michael Hennebry <
michael.hennebry at rivieranexus.com> wrote:

> Emphasis on curse.
>
> from CMakeLists.txt:
>
> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)
>
> message("apps:;${apps};:apps")
> message("ards:;${ards};:ards")
>
> Both lists have ArduinoCore and SensorUnit sources.
> They both have precisely 57 entries.
> They both have three entries from sb-build.
>
> What is going on?
>
> From the siblings' parent:
> $ ls -F
> ArduinoCore/    SensorUnit/              generic-gcc-avr.cmake
> CMakeLists.txt  from-build-directory.sh  sb-build/
>
> I tried RELATIVE.
> I tried replacing the dot with ${CMAKE_SOURCE_DIR}.
> All to no avail.
>
> I'm stumped.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180725/54c5777a/attachment.html>

From michael.hennebry at rivieranexus.com  Wed Jul 25 21:02:09 2018
From: michael.hennebry at rivieranexus.com (Michael Hennebry)
Date: Wed, 25 Jul 2018 20:02:09 -0500
Subject: [CMake] GLOB_RECURSE
In-Reply-To: <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
 <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>
Message-ID: <CAAJOWOpW8dTSYjB4ogrp-tdEdJD-yt7BumKhR6hWdZJOJT4KSw@mail.gmail.com>

frodak wrote:
I think you want to try for absolute paths:
file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)

relative paths from those directories:
file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
./SensorUnit/*.c)
:frodak

I do not understand either your constructions or mine.
I do not know how cmake interprets any of them,
nor how anyone would know.
What documentation I can find, cmake.org, has not been helpful..

Mike


On Wed, Jul 25, 2018 at 7:02 PM, frodak <frodak17 at gmail.com> wrote:
> I think you want to try for absolute paths:
> file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
>
> relative paths from those directories:
> file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/ ./ArduinoCore/src/*.cpp
> ./ArduinoCore/src/*.c)
> file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
> ./SensorUnit/*.c)
>
>
>
> On Wed, Jul 25, 2018 at 6:47 PM, Michael Hennebry
> <michael.hennebry at rivieranexus.com> wrote:
>>
>> Emphasis on curse.
>>
>> from CMakeLists.txt:
>>
>> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
>> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)
>>
>> message("apps:;${apps};:apps")
>> message("ards:;${ards};:ards")
>>
>> Both lists have ArduinoCore and SensorUnit sources.
>> They both have precisely 57 entries.
>> They both have three entries from sb-build.
>>
>> What is going on?
>>
>> From the siblings' parent:
>> $ ls -F
>> ArduinoCore/    SensorUnit/              generic-gcc-avr.cmake
>> CMakeLists.txt  from-build-directory.sh  sb-build/
>>
>> I tried RELATIVE.
>> I tried replacing the dot with ${CMAKE_SOURCE_DIR}.
>> All to no avail.
>>
>> I'm stumped.
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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 Jul 25 21:19:08 2018
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Wed, 25 Jul 2018 21:19:08 -0400
Subject: [CMake] GLOB_RECURSE
In-Reply-To: <CAAJOWOpW8dTSYjB4ogrp-tdEdJD-yt7BumKhR6hWdZJOJT4KSw@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
 <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>
 <CAAJOWOpW8dTSYjB4ogrp-tdEdJD-yt7BumKhR6hWdZJOJT4KSw@mail.gmail.com>
Message-ID: <CACJ51z3_L0RuQ1yevCPuZzdRiL4f1ChJ2a203pKqS+zrKibZKg@mail.gmail.com>

Michael,

It's not clear what you're asking. You need to say what you're trying to
achieve, your expected result, and the result that you believe incorrect.

On Wed, Jul 25, 2018, 9:02 PM Michael Hennebry <
michael.hennebry at rivieranexus.com> wrote:

> frodak wrote:
> I think you want to try for absolute paths:
> file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
>
> relative paths from those directories:
> file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
> ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
> ./SensorUnit/*.c)
> :frodak
>
> I do not understand either your constructions or mine.
> I do not know how cmake interprets any of them,
> nor how anyone would know.
> What documentation I can find, cmake.org, has not been helpful..
>
> Mike
>
>
> On Wed, Jul 25, 2018 at 7:02 PM, frodak <frodak17 at gmail.com> wrote:
> > I think you want to try for absolute paths:
> > file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> > file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
> >
> > relative paths from those directories:
> > file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
> ./ArduinoCore/src/*.cpp
> > ./ArduinoCore/src/*.c)
> > file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
> > ./SensorUnit/*.c)
> >
> >
> >
> > On Wed, Jul 25, 2018 at 6:47 PM, Michael Hennebry
> > <michael.hennebry at rivieranexus.com> wrote:
> >>
> >> Emphasis on curse.
> >>
> >> from CMakeLists.txt:
> >>
> >> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
> >> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)
> >>
> >> message("apps:;${apps};:apps")
> >> message("ards:;${ards};:ards")
> >>
> >> Both lists have ArduinoCore and SensorUnit sources.
> >> They both have precisely 57 entries.
> >> They both have three entries from sb-build.
> >>
> >> What is going on?
> >>
> >> From the siblings' parent:
> >> $ ls -F
> >> ArduinoCore/    SensorUnit/              generic-gcc-avr.cmake
> >> CMakeLists.txt  from-build-directory.sh  sb-build/
> >>
> >> I tried RELATIVE.
> >> I tried replacing the dot with ${CMAKE_SOURCE_DIR}.
> >> All to no avail.
> >>
> >> I'm stumped.
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> >> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For more
> >> information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/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/20180725/15c4e203/attachment-0001.html>

From michael.hennebry at rivieranexus.com  Wed Jul 25 21:57:17 2018
From: michael.hennebry at rivieranexus.com (Michael Hennebry)
Date: Wed, 25 Jul 2018 20:57:17 -0500
Subject: [CMake] Fwd:  GLOB_RECURSE
In-Reply-To: <CAAJOWOpWqDP88pOUqbYBgRKRG2zJJHVXni28JbaziYza7Uv_nQ@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
 <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>
 <CAAJOWOpW8dTSYjB4ogrp-tdEdJD-yt7BumKhR6hWdZJOJT4KSw@mail.gmail.com>
 <CACJ51z3_L0RuQ1yevCPuZzdRiL4f1ChJ2a203pKqS+zrKibZKg@mail.gmail.com>
 <CAAJOWOpWqDP88pOUqbYBgRKRG2zJJHVXni28JbaziYza7Uv_nQ@mail.gmail.com>
Message-ID: <CAAJOWOpHp0mzJssjNNo+EJ-Q2kCV5eFeM7ZfizUwsMcm_AFiPA@mail.gmail.com>

---------- Forwarded message ----------
From: Michael Hennebry <michael.hennebry at rivieranexus.com>
Date: Wed, Jul 25, 2018 at 8:55 PM
Subject: Re: [CMake] GLOB_RECURSE
To: Andrew Bell <andrew.bell.ia at gmail.com>


I'd thought I was clear.
I want two lists of files, one from each of two directory trees.
Maybe GLOB_RECURSE does not do that.
If not, I can live without.

What does it do?

Maybe you have used cmake long enough for the answer to be obvious.
I have to read documentation or ask people.
The former has not been all that helpful.

What I have been getting is what appears to be the same list twice.
It includes files from three directory trees.

On Wed, Jul 25, 2018 at 8:19 PM, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
> Michael,
>
> It's not clear what you're asking. You need to say what you're trying to
> achieve, your expected result, and the result that you believe incorrect.
>
> On Wed, Jul 25, 2018, 9:02 PM Michael Hennebry
> <michael.hennebry at rivieranexus.com> wrote:
>>
>> frodak wrote:
>> I think you want to try for absolute paths:
>> file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
>> file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
>>
>> relative paths from those directories:
>> file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
>> ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
>> file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
>> ./SensorUnit/*.c)
>> :frodak
>>
>> I do not understand either your constructions or mine.
>> I do not know how cmake interprets any of them,
>> nor how anyone would know.
>> What documentation I can find, cmake.org, has not been helpful..
>>
>> Mike
>>
>>
>> On Wed, Jul 25, 2018 at 7:02 PM, frodak <frodak17 at gmail.com> wrote:
>> > I think you want to try for absolute paths:
>> > file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
>> > file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
>> >
>> > relative paths from those directories:
>> > file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
>> > ./ArduinoCore/src/*.cpp
>> > ./ArduinoCore/src/*.c)
>> > file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
>> > ./SensorUnit/*.c)
>> >
>> >
>> >
>> > On Wed, Jul 25, 2018 at 6:47 PM, Michael Hennebry
>> > <michael.hennebry at rivieranexus.com> wrote:
>> >>
>> >> Emphasis on curse.
>> >>
>> >> from CMakeLists.txt:
>> >>
>> >> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
>> >> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)
>> >>
>> >> message("apps:;${apps};:apps")
>> >> message("ards:;${ards};:ards")
>> >>
>> >> Both lists have ArduinoCore and SensorUnit sources.
>> >> They both have precisely 57 entries.
>> >> They both have three entries from sb-build.
>> >>
>> >> What is going on?
>> >>
>> >> From the siblings' parent:
>> >> $ ls -F
>> >> ArduinoCore/    SensorUnit/              generic-gcc-avr.cmake
>> >> CMakeLists.txt  from-build-directory.sh  sb-build/
>> >>
>> >> I tried RELATIVE.
>> >> I tried replacing the dot with ${CMAKE_SOURCE_DIR}.
>> >> All to no avail.
>> >>
>> >> I'm stumped.
>> >> --
>> >>
>> >> Powered by www.kitware.com
>> >>
>> >> Please keep messages on-topic and check the CMake FAQ at:
>> >> http://www.cmake.org/Wiki/CMake_FAQ
>> >>
>> >> Kitware offers various services to support the CMake community. For
>> >> more
>> >> information on each offering, please visit:
>> >>
>> >> CMake Support: http://cmake.org/cmake/help/support.html
>> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >> CMake Training Courses: http://cmake.org/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 calebwherry at gmail.com  Wed Jul 25 22:48:16 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Wed, 25 Jul 2018 22:48:16 -0400
Subject: [CMake] Fwd: GLOB_RECURSE
In-Reply-To: <CAAJOWOpHp0mzJssjNNo+EJ-Q2kCV5eFeM7ZfizUwsMcm_AFiPA@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
 <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>
 <CAAJOWOpW8dTSYjB4ogrp-tdEdJD-yt7BumKhR6hWdZJOJT4KSw@mail.gmail.com>
 <CACJ51z3_L0RuQ1yevCPuZzdRiL4f1ChJ2a203pKqS+zrKibZKg@mail.gmail.com>
 <CAAJOWOpWqDP88pOUqbYBgRKRG2zJJHVXni28JbaziYza7Uv_nQ@mail.gmail.com>
 <CAAJOWOpHp0mzJssjNNo+EJ-Q2kCV5eFeM7ZfizUwsMcm_AFiPA@mail.gmail.com>
Message-ID: <CAJxY6XoJ0Vy_J_L4CcHTdHzC-CGT1yDhyxfKHHNhVtwaH1DGhw@mail.gmail.com>

Latest CMake documentation can be found here:

https://cmake.org/cmake/help/latest/

Searching for GLOB_RECURSE there leads to this page:

https://cmake.org/cmake/help/latest/command/file.html

Which is the command you are using. Docs for the command and option you are
using are here:

https://cmake.org/cmake/help/latest/command/file.html?highlight=glob_recurse#glob-recurse

As for your issue, you are misunderstanding the purpose of RELATIVE. That
means the paths you get path will be relative to that path, not that it
searches from that path. So you are just searching for ?*.cpp? and ?*.c? in
the CURRENT directory. That is why you are getting files in all the
subdirs. As @frodak pointed out in his first example, you need to remove
the RELATIVE and put the dir name you want like ?./dir/*.cpp?.

Once you do that, you should be good to go. All of the above is explained
pretty clearly in the linked docs.

-Caleb

On Wed, Jul 25, 2018 at 9:57 PM Michael Hennebry <
michael.hennebry at rivieranexus.com> wrote:

> ---------- Forwarded message ----------
> From: Michael Hennebry <michael.hennebry at rivieranexus.com>
> Date: Wed, Jul 25, 2018 at 8:55 PM
> Subject: Re: [CMake] GLOB_RECURSE
> To: Andrew Bell <andrew.bell.ia at gmail.com>
>
>
> I'd thought I was clear.
> I want two lists of files, one from each of two directory trees.
> Maybe GLOB_RECURSE does not do that.
> If not, I can live without.
>
> What does it do?
>
> Maybe you have used cmake long enough for the answer to be obvious.
> I have to read documentation or ask people.
> The former has not been all that helpful.
>
> What I have been getting is what appears to be the same list twice.
> It includes files from three directory trees.
>
> On Wed, Jul 25, 2018 at 8:19 PM, Andrew Bell <andrew.bell.ia at gmail.com>
> wrote:
> > Michael,
> >
> > It's not clear what you're asking. You need to say what you're trying to
> > achieve, your expected result, and the result that you believe incorrect.
> >
> > On Wed, Jul 25, 2018, 9:02 PM Michael Hennebry
> > <michael.hennebry at rivieranexus.com> wrote:
> >>
> >> frodak wrote:
> >> I think you want to try for absolute paths:
> >> file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> >> file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
> >>
> >> relative paths from those directories:
> >> file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
> >> ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> >> file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
> >> ./SensorUnit/*.c)
> >> :frodak
> >>
> >> I do not understand either your constructions or mine.
> >> I do not know how cmake interprets any of them,
> >> nor how anyone would know.
> >> What documentation I can find, cmake.org, has not been helpful..
> >>
> >> Mike
> >>
> >>
> >> On Wed, Jul 25, 2018 at 7:02 PM, frodak <frodak17 at gmail.com> wrote:
> >> > I think you want to try for absolute paths:
> >> > file (GLOB_RECURSE ards ./ArduinoCore/src/*.cpp ./ArduinoCore/src/*.c)
> >> > file (GLOB_RECURSE apps ./SensorUnit/*.cpp ./SensorUnit/*.c)
> >> >
> >> > relative paths from those directories:
> >> > file (GLOB_RECURSE ards RELATIVE  ./ArduinoCore/src/
> >> > ./ArduinoCore/src/*.cpp
> >> > ./ArduinoCore/src/*.c)
> >> > file (GLOB_RECURSE apps RELATIVE ./SensorUnit/ ./SensorUnit/*.cpp
> >> > ./SensorUnit/*.c)
> >> >
> >> >
> >> >
> >> > On Wed, Jul 25, 2018 at 6:47 PM, Michael Hennebry
> >> > <michael.hennebry at rivieranexus.com> wrote:
> >> >>
> >> >> Emphasis on curse.
> >> >>
> >> >> from CMakeLists.txt:
> >> >>
> >> >> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
> >> >> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)
> >> >>
> >> >> message("apps:;${apps};:apps")
> >> >> message("ards:;${ards};:ards")
> >> >>
> >> >> Both lists have ArduinoCore and SensorUnit sources.
> >> >> They both have precisely 57 entries.
> >> >> They both have three entries from sb-build.
> >> >>
> >> >> What is going on?
> >> >>
> >> >> From the siblings' parent:
> >> >> $ ls -F
> >> >> ArduinoCore/    SensorUnit/              generic-gcc-avr.cmake
> >> >> CMakeLists.txt  from-build-directory.sh  sb-build/
> >> >>
> >> >> I tried RELATIVE.
> >> >> I tried replacing the dot with ${CMAKE_SOURCE_DIR}.
> >> >> All to no avail.
> >> >>
> >> >> I'm stumped.
> >> >> --
> >> >>
> >> >> Powered by www.kitware.com
> >> >>
> >> >> Please keep messages on-topic and check the CMake FAQ at:
> >> >> http://www.cmake.org/Wiki/CMake_FAQ
> >> >>
> >> >> Kitware offers various services to support the CMake community. For
> >> >> more
> >> >> information on each offering, please visit:
> >> >>
> >> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> >> CMake Training Courses: http://cmake.org/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
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180725/0b88dc82/attachment.html>

From dan at su-root.co.uk  Thu Jul 26 01:32:07 2018
From: dan at su-root.co.uk (Dan Liew)
Date: Thu, 26 Jul 2018 06:32:07 +0100
Subject: [CMake] GLOB_RECURSE
In-Reply-To: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
Message-ID: <CAJ7DczFmDaeSw2Di1830q3fGfJ073M=DrZpYDGw6N4CJ1G3_Rw@mail.gmail.com>

On 25 July 2018 at 23:47, Michael Hennebry
<michael.hennebry at rivieranexus.com> wrote:
> Emphasis on curse.
>
> from CMakeLists.txt:
>
> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)

Your syntax is wrong. `./ArduinoCore/src`, ` ./SensorUnit`, `*.cpp`,
`*.c` are all being treated as separate glob expressions so `*.cpp`
and `*.c` recursively match the current directory.
If you look at the signature of the function you're calling

```

file(GLOB_RECURSE <variable> [FOLLOW_SYMLINKS]
     [LIST_DIRECTORIES true|false] [RELATIVE <path>]
     [<globbing-expressions>...])
```

you can see that all your arguments after `ards` and `apps` are being
treated as `<globbing-expressions>`.
Instead you want something like this

file(GLOB_RECURSE ards RELATIVE ArduinoCore/src *.cpp *.c)
file (GLOB_RECURSE apps RELATIVE ./SensorUnit *.cpp *.c)

Note the use of the `RELATIVE` argument. See
https://cmake.org/cmake/help/v3.10/command/file.html for more details.

Hope that helps.

From mario at emmenlauer.de  Thu Jul 26 05:58:20 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Thu, 26 Jul 2018 11:58:20 +0200
Subject: [CMake] order of includes seems wrong (or please help me understand)
Message-ID: <13ec3e40-afdc-0980-62c9-8095e36b211c@emmenlauer.de>


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


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

From francis.giraldeau at gmail.com  Thu Jul 26 09:27:32 2018
From: francis.giraldeau at gmail.com (Francis Giraldeau)
Date: Thu, 26 Jul 2018 09:27:32 -0400
Subject: [CMake] How do I use install() with targets that might not be
 built?
In-Reply-To: <CA+Zd3Ff1+tXSv225f+NN+9m_C52eYzys5TU3V-5XBkiJCzPhpw@mail.gmail.com>
References: <CA+Zd3Ff1+tXSv225f+NN+9m_C52eYzys5TU3V-5XBkiJCzPhpw@mail.gmail.com>
Message-ID: <CAC6yHM7AvYSLqufPFW8X-ovWwYU07OM_rvWP=75+kHsp5RfiqQ@mail.gmail.com>

To customize the build and install, I would suggest to use an
install(TRAGET) wrapper for each target. It allows to define an option for
each of them.

* The list of targets must be recorded in a global property.
* The install option is constructed using the target name
* call generate_install_config() after all targets to get a template that
you can customize and use as cmake initial cache

You might be able to adapt this to your needs.

Cheers,

====

set_property(GLOBAL PROPERTY target_list)

# add_install_option must be a macro, if put in a function, the option does
# not exists right after being declared.
macro(add_install_option target)
    string(TOUPPER ${target} TGT)
    option(CONFIG_INSTALL_${TGT} "Install ${TGT}" ON)
    get_property(tmp GLOBAL PROPERTY target_list)
    list(APPEND tmp CONFIG_INSTALL_${TGT})
    set_property(GLOBAL PROPERTY target_list ${tmp})
endmacro()

function(install_target_wrapper target)
  add_install_option(${target})
  if(CONFIG_INSTALL_${TGT})
      # message("CONFIG_INSTALL_${TGT}=${CONFIG_INSTALL_${TGT}}")
      install(TARGETS ${target}
          RUNTIME DESTINATION bin
          LIBRARY DESTINATION lib
          COMPONENT application
      )
  endif()
endfunction()

function(generate_install_config)
    set(CONF "${CMAKE_BINARY_DIR}/InstallConfig.cmake")
    file(WRITE "${CONF}" "# Automatically generated install config file.
Copy this file and edit to customize the installation.\n")
    file(APPEND "${CONF}" "# Use to populate the initial cmake cache: cmake
-C InstallConfigForCustomer.cmake\n")
    file(APPEND "${CONF}" "# EDIT VARIABLES BELOW\n")
    get_property(tmp GLOBAL PROPERTY target_list)
    list(SORT tmp)
    foreach(ITEM ${tmp})
        file(APPEND ${CONF} "set(${ITEM}_VALUE ${${ITEM}})\n")
    endforeach()
    file(APPEND "${CONF}" "#\n# DO NOT EDIT BELOW\n#\n")
    foreach(ITEM ${tmp})
        file(APPEND ${CONF} "set(${ITEM} \${${ITEM}_VALUE} CACHE BOOL
\"Install ${ITEM}\" FORCE)\n")
    endforeach()
    list(LENGTH tmp tmp_len)
    message("-- Number of targets: ${tmp_len}")
endfunction()


Le mer. 25 juil. 2018 ? 02:09, Jason Heeris <jason.heeris at gmail.com> a
?crit :

> My project consists of a lot of "module" style targets (static libraries,
> more or less), but only a few top-level targets that a user would actually
> want to build. The "all" target is empty, that is, every target has
> "EXCLUDE_FROM_ALL" set. The user will, at compile time, decide to build
> whichever target they need. A single target may depend on a couple of
> others, so the end result of a single target being built might be eg. an
> exe file plus a dll plus a couple of other things.
>
> But I also want to provide installation capabilities, so users don't have
> to hunt down exes and libs scattered throughout CMake's build tree. I might
> want to create installers using CPack at some point too.
>
> How do I do this if all of my targets are EXCLUDE_FROM_ALL? According to
> the documentation, even if I use the OPTIONAL flag in install(), the
> behaviour is undefined. Better not do that.
>
> The only other option I see is to create custom commands (POST_BUILD
> style) for every target that copies it to some designated output directory.
> But then I can't take advantage of CMake's other installation capabilities,
> and I think that would be invisible to CPack.
>
> Is there some other way?
>
> I'm using CMake 3.12 on Windows 10/Ubuntu 18.04, if that's relevant.
>
> Cheers,
> Jason
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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
>
-- 
Francis Giraldeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180726/c67142bf/attachment.html>

From michael.hennebry at rivieranexus.com  Thu Jul 26 09:46:57 2018
From: michael.hennebry at rivieranexus.com (Michael Hennebry)
Date: Thu, 26 Jul 2018 08:46:57 -0500
Subject: [CMake] Fwd: GLOB_RECURSE
In-Reply-To: <CAJxY6XoJ0Vy_J_L4CcHTdHzC-CGT1yDhyxfKHHNhVtwaH1DGhw@mail.gmail.com>
References: <CAAJOWOp2=kfs_JAbZve1_WHqwevm541LTYjGxB_TH51Ek4odKw@mail.gmail.com>
 <CAM_JqVkbQ9vTKL0_pBMgRWNinamymd-DX=EjefJ3r+obJSr-ww@mail.gmail.com>
 <CAAJOWOpW8dTSYjB4ogrp-tdEdJD-yt7BumKhR6hWdZJOJT4KSw@mail.gmail.com>
 <CACJ51z3_L0RuQ1yevCPuZzdRiL4f1ChJ2a203pKqS+zrKibZKg@mail.gmail.com>
 <CAAJOWOpWqDP88pOUqbYBgRKRG2zJJHVXni28JbaziYza7Uv_nQ@mail.gmail.com>
 <CAAJOWOpHp0mzJssjNNo+EJ-Q2kCV5eFeM7ZfizUwsMcm_AFiPA@mail.gmail.com>
 <CAJxY6XoJ0Vy_J_L4CcHTdHzC-CGT1yDhyxfKHHNhVtwaH1DGhw@mail.gmail.com>
Message-ID: <CAAJOWOptaMy8W18WOqyct6=UXeftTHcOxZAdiTH=Q4-Z+ppDrg@mail.gmail.com>

I finally found the ellipses.

On Wed, Jul 25, 2018 at 9:48 PM, J. Caleb Wherry <calebwherry at gmail.com> wrote:
> Latest CMake documentation can be found here:

> https://cmake.org/cmake/help/latest/command/file.html?highlight=glob_recurse#glob-recurse

That is what I was using, albeit badly.

> As for your issue, you are misunderstanding the purpose of RELATIVE. That
> means the paths you get path will be relative to that path, not that it
> searches from that path. So you are just searching for ?*.cpp? and ?*.c? in
> the CURRENT directory. That is why you are getting files in all the subdirs.
> As @frodak pointed out in his first example, you need to remove the RELATIVE
> and put the dir name you want like ?./dir/*.cpp?.

Ah.  The top level directories are not list separately.

> Once you do that, you should be good to go. All of the above is explained
> pretty clearly in the linked docs.

Yes, they are.
My "interpretation" was too heavily influenced by an example even
worse than mine.

Thanks.

From spacey_01 at outlook.com  Thu Jul 26 19:54:40 2018
From: spacey_01 at outlook.com (Space)
Date: Thu, 26 Jul 2018 16:54:40 -0700 (MST)
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
Message-ID: <1532649280746-0.post@n2.nabble.com>

Dear Cmake world,

I am wanting to learn how to use Cmake correctly and I would like to
implement Modern Cmake (the latest version and techniques). 

Currently I have a project that was intended for use on windows machine but
I want to run/develop it on Mac and am also interested to make it overall
cross platform. On Mac I'll use Visual Studio Code and Xcode (preferably
VSC).

Here is a link to the GitHub for the current project of interest:
https://github.com/AcademyOfInteractiveEntertainment/aieBootstrap

Dependencies are:
    glfw
    glm
    imgui
    stb
    openGL (gl_core_4_4.c/h)

I have visited the cmake.org site and looked at the tutorials, they teach
old cmake 2.8 but shouldn't there be material that teaches the Modern way. 

I know about the documentation that has made an effort to show some of the
modern practices but to a person, new to cmake, my brain just shuts down to
the reference styled documents, and yes, but thats what the documentation
is; a reference list.

I then found the webinars, but much disappoint, they are dated back to March
2012 ( a great effort for its time but left me confused; not modern). 

We are now end of July 2018. It would be great to see a webinar completely
refreshed, which is directed at the complete beginner and makes an effort to
teach Modern Cmake in todays world. It would also be nice to understand how
to bridge the gap between old 2.8 cmake and the latest cmake. For example:
Making proper use of find_package etc...

I hope this is an interesting topic to be reviewed,

regards,

Space





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

From Andreas-Naumann at gmx.net  Fri Jul 27 12:37:23 2018
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Fri, 27 Jul 2018 18:37:23 +0200
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
In-Reply-To: <1532649280746-0.post@n2.nabble.com>
References: <1532649280746-0.post@n2.nabble.com>
Message-ID: <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>

Dear space & and the rest of the cmake world :)

i just googled for "modern cmake" and came up with at least two 
interesting talks from cppcon and boostcon:
https://www.youtube.com/watch?v=bsXLMQ6WgIk&feature=youtu.be&t=37m15s
 ??? https://www.youtube.com/watch?v=eC9-iRN2b04
Their slides can be found at
https://github.com/CppCon/CppCon2017/blob/master/Tutorials/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design%20-%20Mathieu%20Ropert%20-%20CppCon%202017.pdf
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf

I just slipped through them, but they look like the right way. Another 
nice summary is at 
https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1#file-effective_modern_cmake-md

Wish you a nice weekend,
Andreas


Am 27.07.2018 um 01:54 schrieb Space:
> Dear Cmake world,
>
> I am wanting to learn how to use Cmake correctly and I would like to
> implement Modern Cmake (the latest version and techniques).
>
> Currently I have a project that was intended for use on windows machine but
> I want to run/develop it on Mac and am also interested to make it overall
> cross platform. On Mac I'll use Visual Studio Code and Xcode (preferably
> VSC).
>
> Here is a link to the GitHub for the current project of interest:
> https://github.com/AcademyOfInteractiveEntertainment/aieBootstrap
>
> Dependencies are:
>      glfw
>      glm
>      imgui
>      stb
>      openGL (gl_core_4_4.c/h)
>
> I have visited the cmake.org site and looked at the tutorials, they teach
> old cmake 2.8 but shouldn't there be material that teaches the Modern way.
>
> I know about the documentation that has made an effort to show some of the
> modern practices but to a person, new to cmake, my brain just shuts down to
> the reference styled documents, and yes, but thats what the documentation
> is; a reference list.
>
> I then found the webinars, but much disappoint, they are dated back to March
> 2012 ( a great effort for its time but left me confused; not modern).
>
> We are now end of July 2018. It would be great to see a webinar completely
> refreshed, which is directed at the complete beginner and makes an effort to
> teach Modern Cmake in todays world. It would also be nice to understand how
> to bridge the gap between old 2.8 cmake and the latest cmake. For example:
> Making proper use of find_package etc...
>
> I hope this is an interesting topic to be reviewed,
>
> regards,
>
> Space
>
>
>
>
>
> --
> Sent from: http://cmake.3232098.n2.nabble.com/



From zbeekman at gmail.com  Fri Jul 27 16:47:53 2018
From: zbeekman at gmail.com (Zaak Beekman)
Date: Fri, 27 Jul 2018 16:47:53 -0400
Subject: [CMake] Do transitive interace includes propagate to compilation of
 Fortran sources?
Message-ID: <CAAbnBwYnR-hjpp-zVXWhCLNgLSPhUhboeVKy2SvbFcerc8e_ig@mail.gmail.com>

I'm trying to use a superbuild to tightly control third party libraries for
an application. They will all be statically linked in the end (besides deps
like MPI that are effective system libraries). I have the following code in
the TPL's CMakeLists.txt that I am trying to link into the main application:

```cmake
# Make VTKmofo static library
add_library(vtkmofo STATIC ${VTKmofo_sources})

# Tell CMake where to put vtkmofo .mod files generated with libvtkmofo
set_property(TARGET vtkmofo
  PROPERTY
  Fortran_MODULE_DIRECTORY ${VTKmofo_mod_dir})

# Tell consumers where to find .mod files
target_include_directories(vtkmofo PUBLIC
  $<BUILD_INTERFACE:${VTKmofo_mod_dir}>
  $<INSTALL_INTERFACE:include/vtkmofo/mod>
  )

install(TARGETS vtkmofo DESTINATION lib EXPORT vtkmofo-targets)
install(EXPORT vtkmofo-targets DESTINATION lib/vtkmofo)
install(DIRECTORY "${VTKmofo_mod_dir}" DESTINATION include/vtkmofo) # i.e.,
include/vtkmofo/mod/*.mod
```

In the other main project I have:

```cmake
include("${VTKmofo_ROOT}/lib/vtkmofo/vtkmofo-targets.cmake")
...
target_link_libraries(FrapUtility PUBLIC Math MatLib vars ECI Coolant
vtkmofo)
```

Through transitive properties I would expect that the sources for
FrapUtility (all modern Fortran sources) would get the
`-I.../include/vtkmofo/mod` flag passed during compilation. Am I missing
something?


Thanks,
Zaak

Izaak "Zaak" Beekman

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

HPC Scientist
ParaTools Inc. <http://www.paratools.com/>
1509 16th St, NW
Washington, DC 20036
mobile: (917) 797-3239
-------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180727/293dbbd9/attachment.html>

From zbeekman at gmail.com  Fri Jul 27 17:10:48 2018
From: zbeekman at gmail.com (Zaak Beekman)
Date: Fri, 27 Jul 2018 17:10:48 -0400
Subject: [CMake] Do transitive interace includes propagate to
 compilation of Fortran sources?
In-Reply-To: <CAAbnBwYnR-hjpp-zVXWhCLNgLSPhUhboeVKy2SvbFcerc8e_ig@mail.gmail.com>
References: <CAAbnBwYnR-hjpp-zVXWhCLNgLSPhUhboeVKy2SvbFcerc8e_ig@mail.gmail.com>
Message-ID: <CAAbnBwb+GGsqHyzH_fv9ZjeVCj63xncvC+e3q6LwNmmj8exaxw@mail.gmail.com>

Hi,

OK, unless the answer to the question in the subject line should be "NO",
then please disregard this email. I think I was having a caching issue with
my super build setup. I'm pretty sure that transitive includes are being
correctly propagated now.

Sorry for the noise,
Zaak

On Fri, Jul 27, 2018 at 4:47 PM Zaak Beekman <zbeekman at gmail.com> wrote:

> I'm trying to use a superbuild to tightly control third party libraries
> for an application. They will all be statically linked in the end (besides
> deps like MPI that are effective system libraries). I have the following
> code in the TPL's CMakeLists.txt that I am trying to link into the main
> application:
>
> ```cmake
> # Make VTKmofo static library
> add_library(vtkmofo STATIC ${VTKmofo_sources})
>
> # Tell CMake where to put vtkmofo .mod files generated with libvtkmofo
> set_property(TARGET vtkmofo
>   PROPERTY
>   Fortran_MODULE_DIRECTORY ${VTKmofo_mod_dir})
>
> # Tell consumers where to find .mod files
> target_include_directories(vtkmofo PUBLIC
>   $<BUILD_INTERFACE:${VTKmofo_mod_dir}>
>   $<INSTALL_INTERFACE:include/vtkmofo/mod>
>   )
>
> install(TARGETS vtkmofo DESTINATION lib EXPORT vtkmofo-targets)
> install(EXPORT vtkmofo-targets DESTINATION lib/vtkmofo)
> install(DIRECTORY "${VTKmofo_mod_dir}" DESTINATION include/vtkmofo) #
> i.e., include/vtkmofo/mod/*.mod
> ```
>
> In the other main project I have:
>
> ```cmake
> include("${VTKmofo_ROOT}/lib/vtkmofo/vtkmofo-targets.cmake")
> ...
> target_link_libraries(FrapUtility PUBLIC Math MatLib vars ECI Coolant
> vtkmofo)
> ```
>
> Through transitive properties I would expect that the sources for
> FrapUtility (all modern Fortran sources) would get the
> `-I.../include/vtkmofo/mod` flag passed during compilation. Am I missing
> something?
>
>
> Thanks,
> Zaak
>
> Izaak "Zaak" Beekman
>
> -------------------------------------------------------------------------------
>
> HPC Scientist
> ParaTools Inc. <http://www.paratools.com/>
> 1509 16th St, NW
> Washington, DC 20036
> mobile: (917) 797-3239
>
> -------------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180727/5e80754a/attachment.html>

From spacey_01 at outlook.com  Fri Jul 27 19:00:59 2018
From: spacey_01 at outlook.com (spacey_01 at outlook.com)
Date: Fri, 27 Jul 2018 23:00:59 +0000
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
In-Reply-To: <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>
References: <1532649280746-0.post@n2.nabble.com>,
 <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>
Message-ID: <BN6PR01MB281995B04A44E98DE04C143E9F2A0@BN6PR01MB2819.prod.exchangelabs.com>

Hey Andreas,

 thanks for your comments. Yes I too have exhausted the resources you have mentioned here. The concepts make sense and I see the intended point but for a beginner its hard to grasp on how to implement and given the type of project  application of cmake's is diverse (easy to complex).

Im in need of some clear cut examples of modern cmake for it to really sink in (easy to complex).

I feel you have to be a veteran in cmake to understand how to implement the new way and overcome the problems of dependencies not providing modern transitive packages and the struggle of not just calling find_package.. etc. Instead we have to make that transition our selves in some cases. This is the hard part.

However if we are into making libraries it would be a benefit to know the process of cmake packages but at the advantage of being the maker and knowing the dependency path if the library does borrow.

It be great to see cmake.org revamping the webinars for the aforementioned.

Regards,

Space


Sent from my Samsung Galaxy smartphone.


-------- Original message --------
From: Andreas Naumann <Andreas-Naumann at gmx.net>
Date: 28/7/18 2:42 am (GMT+10:00)
To: cmake at cmake.org
Subject: Re: [CMake] Beginners Guide to Cmake and Modern Cmake

Dear space & and the rest of the cmake world :)

i just googled for "modern cmake" and came up with at least two
interesting talks from cppcon and boostcon:
https://www.youtube.com/watch?v=bsXLMQ6WgIk&feature=youtu.be&t=37m15s
     https://www.youtube.com/watch?v=eC9-iRN2b04
Their slides can be found at
https://github.com/CppCon/CppCon2017/blob/master/Tutorials/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design%20-%20Mathieu%20Ropert%20-%20CppCon%202017.pdf
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf

I just slipped through them, but they look like the right way. Another
nice summary is at
https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1#file-effective_modern_cmake-md

Wish you a nice weekend,
Andreas


Am 27.07.2018 um 01:54 schrieb Space:
> Dear Cmake world,
>
> I am wanting to learn how to use Cmake correctly and I would like to
> implement Modern Cmake (the latest version and techniques).
>
> Currently I have a project that was intended for use on windows machine but
> I want to run/develop it on Mac and am also interested to make it overall
> cross platform. On Mac I'll use Visual Studio Code and Xcode (preferably
> VSC).
>
> Here is a link to the GitHub for the current project of interest:
> https://github.com/AcademyOfInteractiveEntertainment/aieBootstrap
>
> Dependencies are:
>      glfw
>      glm
>      imgui
>      stb
>      openGL (gl_core_4_4.c/h)
>
> I have visited the cmake.org site and looked at the tutorials, they teach
> old cmake 2.8 but shouldn't there be material that teaches the Modern way.
>
> I know about the documentation that has made an effort to show some of the
> modern practices but to a person, new to cmake, my brain just shuts down to
> the reference styled documents, and yes, but thats what the documentation
> is; a reference list.
>
> I then found the webinars, but much disappoint, they are dated back to March
> 2012 ( a great effort for its time but left me confused; not modern).
>
> We are now end of July 2018. It would be great to see a webinar completely
> refreshed, which is directed at the complete beginner and makes an effort to
> teach Modern Cmake in todays world. It would also be nice to understand how
> to bridge the gap between old 2.8 cmake and the latest cmake. For example:
> Making proper use of find_package etc...
>
> I hope this is an interesting topic to be reviewed,
>
> regards,
>
> Space
>
>
>
>
>
> --
> Sent from: http://cmake.3232098.n2.nabble.com/


--

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

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

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

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

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

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

From twhall at umich.edu  Fri Jul 27 23:05:34 2018
From: twhall at umich.edu (Theodore Hall)
Date: Fri, 27 Jul 2018 23:05:34 -0400
Subject: [CMake] Add Windows library dependency
Message-ID: <CAGRUjbO4bXrBhrT0491ywFWfE=q+XKnEjK1EXp64rzzDT3DPfQ@mail.gmail.com>

Greetings,

I'm building a project that depends on a Windows library -- Secur32.Lib --
that is included in the regular library search path but is not one of the
specific libraries that the compiler normally links to.  In *NIX
command-line terms, the "-L<path>" is OK, I only need to specify the
"-lSecur32" part.

If I put "#pragma comment (lib, "Secur32.Lib")" in the cpp file, the system
finds and links it.  If I omit that, then the build fails with an
unresolved external symbol.

I cannot find a way to accomplish this in the CMakeLists.txt file rather
than relying on the #pragma.  CMake complains that it doesn't know how to
build it, though I've (tried to) set the IMPORTED property.  I've tried
various combinations of:

find_library(SECUR32 Secur32)
add_library(Secur32 SHARED IMPORTED)
target_link_libraries(MyTarget
Secur32)

I have not tried to set IMPORTED_LOCATION, because libraries with that name
exist in several locations, and the compiler actually knows better than I
do which one to use -- e.g., one of them is in:

C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x64\Secur32.Lib

We're building in VisualStudio 2017 as a CMake project.  We have not
generated and are not using VS ",proj" or ".sln" files.  We're aiming to
build this as a multi-platform application.  (The dependence on this
library is wrapped in the appropriate #if defined ... #endif directives.)

Any enlightenment would be greatly appreciated.  Thanks.

-- 

Ted Hall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180727/4a948164/attachment.html>

From d3ck0r at gmail.com  Fri Jul 27 23:09:10 2018
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 27 Jul 2018 20:09:10 -0700
Subject: [CMake] Add Windows library dependency
In-Reply-To: <CAGRUjbO4bXrBhrT0491ywFWfE=q+XKnEjK1EXp64rzzDT3DPfQ@mail.gmail.com>
References: <CAGRUjbO4bXrBhrT0491ywFWfE=q+XKnEjK1EXp64rzzDT3DPfQ@mail.gmail.com>
Message-ID: <CAA2GJqUD4-Qtr0UKwud6VUE+vtxWJgRfX+SDaE6KG66r95+y3w@mail.gmail.com>

should just be add_executable( whatever_target secur32 )


On Fri, Jul 27, 2018 at 8:05 PM Theodore Hall <twhall at umich.edu> wrote:

> Greetings,
>
> I'm building a project that depends on a Windows library -- Secur32.Lib --
> that is included in the regular library search path but is not one of the
> specific libraries that the compiler normally links to.  In *NIX
> command-line terms, the "-L<path>" is OK, I only need to specify the
> "-lSecur32" part.
>
> If I put "#pragma comment (lib, "Secur32.Lib")" in the cpp file, the
> system finds and links it.  If I omit that, then the build fails with an
> unresolved external symbol.
>
> I cannot find a way to accomplish this in the CMakeLists.txt file rather
> than relying on the #pragma.  CMake complains that it doesn't know how to
> build it, though I've (tried to) set the IMPORTED property.  I've tried
> various combinations of:
>
> find_library(SECUR32 Secur32)
> add_library(Secur32 SHARED IMPORTED)
> target_link_libraries(MyTarget
> Secur32)
>
> I have not tried to set IMPORTED_LOCATION, because libraries with that
> name exist in several locations, and the compiler actually knows better
> than I do which one to use -- e.g., one of them is in:
>
> C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x64\Secur32.Lib
>
> We're building in VisualStudio 2017 as a CMake project.  We have not
> generated and are not using VS ",proj" or ".sln" files.  We're aiming to
> build this as a multi-platform application.  (The dependence on this
> library is wrapped in the appropriate #if defined ... #endif directives.)
>
> Any enlightenment would be greatly appreciated.  Thanks.
>
> --
>
> Ted Hall
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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/20180727/7383bc5d/attachment.html>

From eric.noulard at gmail.com  Sat Jul 28 03:44:42 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Sat, 28 Jul 2018 09:44:42 +0200
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
In-Reply-To: <BN6PR01MB281995B04A44E98DE04C143E9F2A0@BN6PR01MB2819.prod.exchangelabs.com>
References: <1532649280746-0.post@n2.nabble.com>
 <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>
 <BN6PR01MB281995B04A44E98DE04C143E9F2A0@BN6PR01MB2819.prod.exchangelabs.com>
Message-ID: <CAPASGLrjHiw5Ay3D_4=gkDgRUwCNtBT1cxyo77zDdyc4gSd4XA@mail.gmail.com>

Le sam. 28 juil. 2018 ? 01:01, spacey_01 at outlook.com <spacey_01 at outlook.com>
a ?crit :

> Hey Andreas,
>
>  thanks for your comments. Yes I too have exhausted the resources you have
> mentioned here. The concepts make sense and I see the intended point but
> for a beginner its hard to grasp on how to implement and given the type of
> project  application of cmake's is diverse (easy to complex).
>
> Im in need of some clear cut examples of modern cmake for it to really
> sink in (easy to complex).
>
> I feel you have to be a veteran in cmake to understand how to implement
> the new way and overcome the problems of dependencies not providing modern
> transitive packages and the struggle of not just calling find_package..
> etc. Instead we have to make that transition our selves in some cases. This
> is the hard part.
>


AIFAIK, your example software does not seem to be built with CMake so there
is no transition to make for you.
Just use the "Modern way" from the ground up.

Concerning documentation, tutorial, webinar etc...
More and more resource are coming up:

1) The various slide/presentation already mentionned
2) The reference documentation (https://cmake.org/documentation/) which has
improved a lot after the switch to sphinx
3) The kitware training of course: https://training.kitware.fr
4) Books
    - The book recently announced by Craig Scott:
https://crascit.com/professional-cmake/
    - A forthcoming cookbook:
https://www.packtpub.com/application-development/cmake-cookbook
and probably many other to come.

However if we are into making libraries it would be a benefit to know the
> process of cmake packages but at the advantage of being the maker and
> knowing the dependency path if the library does borrow.
>

I bet (but I did not read it) the book from Craig could help you with that,
but I'm sure he may answer himself.

Now I am curious of what you mean by "it would be a benefit to know **the
process of cmake packages**" ?
What do you mean by that?


> It be great to see cmake.org revamping the webinars for the
> aforementioned.
>

All that said I agree the current are oldish and would benefit an upgrade
:-)

However from my perspective writing good doc, tutorial, webinar etc... is
very time-consuming so may be worth buying some for that and give some
rewards to people investing in it.
This is my own opinion though :-)

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

From spacey_01 at outlook.com  Sat Jul 28 04:54:52 2018
From: spacey_01 at outlook.com (spacey_01 at outlook.com)
Date: Sat, 28 Jul 2018 08:54:52 +0000
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
In-Reply-To: <CAPASGLrjHiw5Ay3D_4=gkDgRUwCNtBT1cxyo77zDdyc4gSd4XA@mail.gmail.com>
References: <1532649280746-0.post@n2.nabble.com>
 <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>
 <BN6PR01MB281995B04A44E98DE04C143E9F2A0@BN6PR01MB2819.prod.exchangelabs.com>,
 <CAPASGLrjHiw5Ay3D_4=gkDgRUwCNtBT1cxyo77zDdyc4gSd4XA@mail.gmail.com>
Message-ID: <BN6PR01MB28194B234D27C7B81A63C49D9F290@BN6PR01MB2819.prod.exchangelabs.com>

Hey Eric,

Yes you are correct, the example software is not built with Cmake but i would like to add Cmake to it. Id like it crossplatform and Cmake seems like the best way.

As said, im really new to Cmake, but ill try to explain with the best of my knowledge. Some  of the projects dependency list does have Cmake but some doesn't.
Project dependencies explained:

Glfw - Cmake is included but only with the build out of source download

Glm - seems to have Cmake package support

Imgui - no Cmake but is self contained and no external libraries

Stb - no Cmake but is header only.

OpenGl -  no Cmake source only, i think its just a list of bindings and is written in C

(project is otherwise C++)

Secondly, thank you for the list of resources. I am particularly interested in Craig Scotts book. Judging from the sample book Craig provides on his webpage I think it is well written. Looking forward to reading the full text.

Thirdly, sorry I was intermittently writting the reply. I mean to say the process of 'how to' provide Cmake package support. :)

Lastly, I agree totally, it is a time consuming job to make good tutorial content, but doesnt any good profession consume time. It would be a benefit to the community and beginners like myself who want to take on Cmake but without the struggle of trawling the whole internet and not finding much learning material that is practical. Most of the tutorial style content is just "hello Cmake" styled content. Some explain the same intro Cmake content in minutes as others spend hours. TT ... ;)
It would just be great to see some up to date tutorials on cmake.org landing page. Would make the learning process smoother.

Thanks so much for the reply Eric,

Regards,

Space


Sent from my Samsung Galaxy smartphone.


-------- Original message --------
From: Eric Noulard <eric.noulard at gmail.com>
Date: 28/7/18 5:44 pm (GMT+10:00)
To: spacey_01 at outlook.com
Cc: CMake Mailinglist <cmake at cmake.org>
Subject: Re: [CMake] Beginners Guide to Cmake and Modern Cmake



Le sam. 28 juil. 2018 ? 01:01, spacey_01 at outlook.com<mailto:spacey_01 at outlook.com> <spacey_01 at outlook.com<mailto:spacey_01 at outlook.com>> a ?crit :
Hey Andreas,

 thanks for your comments. Yes I too have exhausted the resources you have mentioned here. The concepts make sense and I see the intended point but for a beginner its hard to grasp on how to implement and given the type of project  application of cmake's is diverse (easy to complex).

Im in need of some clear cut examples of modern cmake for it to really sink in (easy to complex).

I feel you have to be a veteran in cmake to understand how to implement the new way and overcome the problems of dependencies not providing modern transitive packages and the struggle of not just calling find_package.. etc. Instead we have to make that transition our selves in some cases. This is the hard part.


AIFAIK, your example software does not seem to be built with CMake so there is no transition to make for you.
Just use the "Modern way" from the ground up.

Concerning documentation, tutorial, webinar etc...
More and more resource are coming up:

1) The various slide/presentation already mentionned
2) The reference documentation (https://cmake.org/documentation/) which has improved a lot after the switch to sphinx
3) The kitware training of course: https://training.kitware.fr
4) Books
    - The book recently announced by Craig Scott: https://crascit.com/professional-cmake/
    - A forthcoming cookbook: https://www.packtpub.com/application-development/cmake-cookbook
and probably many other to come.

However if we are into making libraries it would be a benefit to know the process of cmake packages but at the advantage of being the maker and knowing the dependency path if the library does borrow.

I bet (but I did not read it) the book from Craig could help you with that, but I'm sure he may answer himself.

Now I am curious of what you mean by "it would be a benefit to know **the process of cmake packages**" ?
What do you mean by that?

It be great to see cmake.org<http://cmake.org> revamping the webinars for the aforementioned.

All that said I agree the current are oldish and would benefit an upgrade :-)

However from my perspective writing good doc, tutorial, webinar etc... is very time-consuming so may be worth buying some for that and give some rewards to people investing in it.
This is my own opinion though :-)

--
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180728/01f9079e/attachment-0001.html>

From s_buschmann at gmx.de  Sat Jul 28 06:10:22 2018
From: s_buschmann at gmx.de (Stefan Buschmann)
Date: Sat, 28 Jul 2018 12:10:22 +0200
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
In-Reply-To: <BN6PR01MB28194B234D27C7B81A63C49D9F290@BN6PR01MB2819.prod.exchangelabs.com>
References: <1532649280746-0.post@n2.nabble.com>
 <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>
 <BN6PR01MB281995B04A44E98DE04C143E9F2A0@BN6PR01MB2819.prod.exchangelabs.com>
 <CAPASGLrjHiw5Ay3D_4=gkDgRUwCNtBT1cxyo77zDdyc4gSd4XA@mail.gmail.com>
 <BN6PR01MB28194B234D27C7B81A63C49D9F290@BN6PR01MB2819.prod.exchangelabs.com>
Message-ID: <14c33ece-d235-65d4-af8e-b7c1d5965713@gmx.de>

Hi,

you may also have a look at our cmake template "cmake-init", which we 
have been developing for several years now, based on modern CMake.
It may seem a bit overwhelming at first, but we tried to put in many 
best practices and support everything from building, to testing, 
documentation,
up to packaging. We developed it for use in our computer graphics 
middleware, which has pretty much the same dependencies you have (glm, 
glfw, opengl).
So maybe this is of interest to you as a starting point.

https://github.com/cginternals/cmake-init
https://github.com/cginternals/glbinding
https://github.com/cginternals/globjects

Stefan


On 28.07.2018 10:54, spacey_01 at outlook.com wrote:
> Hey Eric,
>
> Yes you are correct, the example software is not built with Cmake but 
> i would like to add Cmake to it. Id like it crossplatform and Cmake 
> seems like the best way.
>
> As said, im really new to Cmake, but ill try to explain with the best 
> of my knowledge. Some? of the projects dependency list does have Cmake 
> but some doesn't.
> Project dependencies explained:
>
> Glfw - Cmake is included but only with the build out of source download
>
> Glm - seems to have Cmake package support
>
> Imgui - no Cmake but is self contained and no external libraries
>
> Stb - no Cmake but is header only.
>
> OpenGl -? no Cmake source only, i think its just a list of bindings 
> and is written in C
>
> (project is otherwise C++)
>
> Secondly, thank you for the list of resources. I am particularly 
> interested in Craig Scotts book. Judging from the sample book Craig 
> provides on his webpage I think it is well written. Looking forward to 
> reading the full text.
>
> Thirdly, sorry I was intermittently writting the reply. I mean to say 
> the process of 'how to' provide Cmake package support. :)
>
> Lastly, I agree totally, it is a time consuming job to make good 
> tutorial content, but doesnt any good profession consume time. It 
> would be a benefit to the community and beginners like myself who want 
> to take on Cmake but without the struggle of trawling the whole 
> internet and not finding much learning material that is practical. 
> Most of the tutorial style content is just "hello Cmake" styled 
> content. Some explain the same intro Cmake content in minutes as 
> others spend hours. TT ... ;)
> It would just be great to see some up to date tutorials on cmake.org 
> landing page. Would make the learning process smoother.
>
> Thanks so much for the reply Eric,
>
> Regards,
>
> Space
>
>
> Sent from my Samsung Galaxy smartphone.
>
>
> -------- Original message --------
> From: Eric Noulard <eric.noulard at gmail.com>
> Date: 28/7/18 5:44 pm (GMT+10:00)
> To: spacey_01 at outlook.com
> Cc: CMake Mailinglist <cmake at cmake.org>
> Subject: Re: [CMake] Beginners Guide to Cmake and Modern Cmake
>
>
>
> Le?sam. 28 juil. 2018 ??01:01, spacey_01 at outlook.com 
> <mailto:spacey_01 at outlook.com> <spacey_01 at outlook.com 
> <mailto:spacey_01 at outlook.com>> a ?crit?:
>
>     Hey Andreas,
>
>     ?thanks for your comments. Yes I too have exhausted the resources
>     you have mentioned here. The concepts make sense and I see the
>     intended point but for a beginner its hard to grasp on how to
>     implement and given the type of project? application of cmake's is
>     diverse (easy to complex).
>
>     Im in need of some clear cut examples of modern cmake for it to
>     really sink in (easy to complex).
>
>     I feel you have to be a veteran in cmake to understand how to
>     implement the new way and overcome the problems of dependencies
>     not providing modern transitive packages and the struggle of not
>     just calling find_package.. etc. Instead we have to make that
>     transition our selves in some cases. This is the hard part.
>
>
>
> AIFAIK, your example software does not seem to be built with CMake so 
> there is no transition to make for you.
> Just use the "Modern way" from the ground up.
>
> Concerning documentation, tutorial, webinar etc...
> More and more resource are coming up:
>
> 1) The various slide/presentation already mentionned
> 2) The reference documentation (https://cmake.org/documentation/) 
> which has improved a lot after the switch to sphinx
> 3) The kitware training of course: https://training.kitware.fr
> 4) Books
> ? ? - The book recently announced by Craig Scott: 
> https://crascit.com/professional-cmake/ 
> <https://crascit.com/professional-cmake/>
> ? ? - A forthcoming cookbook: 
> https://www.packtpub.com/application-development/cmake-cookbook
> and probably many other to come.
>
>     However if we are into making libraries it would be a benefit to
>     know the process of cmake packages but at the advantage of being
>     the maker and knowing the dependency path if the library does borrow.
>
>
> I bet (but I did not read it) the book from Craig could help you with 
> that, but I'm sure he may answer himself.
>
> Now I am curious of what you mean by "it would be a benefit to know 
> **the process of cmake packages**" ?
> What do you mean by that?
>
>     It be great to see cmake.org <http://cmake.org> revamping the
>     webinars for the aforementioned.
>
>
> All that said I agree the current are oldish and would benefit an 
> upgrade :-)
>
> However from my perspective writing good doc, tutorial, webinar etc... 
> is very time-consuming so may be worth buying some for that and give 
> some rewards to people investing in it.
> This is my own opinion though :-)
>
> -- 
> Eric
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180728/6e47fc8e/attachment.html>

From frodak17 at gmail.com  Sun Jul 29 03:32:56 2018
From: frodak17 at gmail.com (frodak)
Date: Sun, 29 Jul 2018 03:32:56 -0400
Subject: [CMake] Add Windows library dependency
In-Reply-To: <CAGRUjbO4bXrBhrT0491ywFWfE=q+XKnEjK1EXp64rzzDT3DPfQ@mail.gmail.com>
References: <CAGRUjbO4bXrBhrT0491ywFWfE=q+XKnEjK1EXp64rzzDT3DPfQ@mail.gmail.com>
Message-ID: <CAM_JqVkT1J4kwycVzULHuv5HWACWHBA5pFQHjqMhE6y6JMF2=Q@mail.gmail.com>

I have a very simple project and just uses two commands:
Add_executable( exe_target ... )
Target_link_libraries( exe_target Shlwapi)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180729/6d82ad33/attachment.html>

From ripopov at gmail.com  Mon Jul 30 03:12:22 2018
From: ripopov at gmail.com (Roman Popov)
Date: Mon, 30 Jul 2018 00:12:22 -0700
Subject: [CMake] Get compiler command line (or json compilation database)
 for a target
Message-ID: <CAATAM3EYLCvbJ9wOd+ZriaWQHV22LOTvETB1GfeHdZMXbBLybw@mail.gmail.com>

Hi all,

How can I get a full compiler command line for a given target in CMakeLists
project? I want to run Clang-based tool on some targets (using CTest), and
it requires same options as used during compilation.

I know there is CMAKE_EXPORT_COMPILE_COMMANDS but it is not taget-specific.

There is a similar question on stackoverflow:
https://stackoverflow.com/questions/35808209/get-full-c-compiler-command-line
Here author suggets to use get_target_property on a target.  I've tried
this, but it does not work when some properties are inherited from
libraries (for example include paths).

Do you have any ideas?

Thanks,
Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180730/fa2a03e3/attachment.html>

From spacey_01 at outlook.com  Mon Jul 30 05:23:12 2018
From: spacey_01 at outlook.com (spacey_01 at outlook.com)
Date: Mon, 30 Jul 2018 09:23:12 +0000
Subject: [CMake] Beginners Guide to Cmake and Modern Cmake
In-Reply-To: <14c33ece-d235-65d4-af8e-b7c1d5965713@gmx.de>
References: <1532649280746-0.post@n2.nabble.com>
 <266cbba7-ede7-fc22-da77-b0f8edca5b14@gmx.net>
 <BN6PR01MB281995B04A44E98DE04C143E9F2A0@BN6PR01MB2819.prod.exchangelabs.com>
 <CAPASGLrjHiw5Ay3D_4=gkDgRUwCNtBT1cxyo77zDdyc4gSd4XA@mail.gmail.com>
 <BN6PR01MB28194B234D27C7B81A63C49D9F290@BN6PR01MB2819.prod.exchangelabs.com>,
 <14c33ece-d235-65d4-af8e-b7c1d5965713@gmx.de>
Message-ID: <BN6PR01MB2819FBDAFA75488B946CDBB19F2F0@BN6PR01MB2819.prod.exchangelabs.com>

Hey Stefan,

Thanks so much for the resource. There is so much information here. Very well documented. It is a lot for me to take on. I have it saved a reference so I can refer to.

Again,

thank you for showing me this,

Space




Sent from my Samsung Galaxy smartphone.


-------- Original message --------
From: Stefan Buschmann <s_buschmann at gmx.de>
Date: 28/7/18 8:15 pm (GMT+10:00)
To: cmake at cmake.org
Subject: Re: [CMake] Beginners Guide to Cmake and Modern Cmake

Hi,

you may also have a look at our cmake template "cmake-init", which we have been developing for several years now, based on modern CMake.
It may seem a bit overwhelming at first, but we tried to put in many best practices and support everything from building, to testing, documentation,
up to packaging. We developed it for use in our computer graphics middleware, which has pretty much the same dependencies you have (glm, glfw, opengl).
So maybe this is of interest to you as a starting point.

https://github.com/cginternals/cmake-init
https://github.com/cginternals/glbinding
https://github.com/cginternals/globjects

Stefan


On 28.07.2018 10:54, spacey_01 at outlook.com<mailto:spacey_01 at outlook.com> wrote:
Hey Eric,

Yes you are correct, the example software is not built with Cmake but i would like to add Cmake to it. Id like it crossplatform and Cmake seems like the best way.

As said, im really new to Cmake, but ill try to explain with the best of my knowledge. Some  of the projects dependency list does have Cmake but some doesn't.
Project dependencies explained:

Glfw - Cmake is included but only with the build out of source download

Glm - seems to have Cmake package support

Imgui - no Cmake but is self contained and no external libraries

Stb - no Cmake but is header only.

OpenGl -  no Cmake source only, i think its just a list of bindings and is written in C

(project is otherwise C++)

Secondly, thank you for the list of resources. I am particularly interested in Craig Scotts book. Judging from the sample book Craig provides on his webpage I think it is well written. Looking forward to reading the full text.

Thirdly, sorry I was intermittently writting the reply. I mean to say the process of 'how to' provide Cmake package support. :)

Lastly, I agree totally, it is a time consuming job to make good tutorial content, but doesnt any good profession consume time. It would be a benefit to the community and beginners like myself who want to take on Cmake but without the struggle of trawling the whole internet and not finding much learning material that is practical. Most of the tutorial style content is just "hello Cmake" styled content. Some explain the same intro Cmake content in minutes as others spend hours. TT ... ;)
It would just be great to see some up to date tutorials on cmake.org landing page. Would make the learning process smoother.

Thanks so much for the reply Eric,

Regards,

Space


Sent from my Samsung Galaxy smartphone.


-------- Original message --------
From: Eric Noulard <eric.noulard at gmail.com><mailto:eric.noulard at gmail.com>
Date: 28/7/18 5:44 pm (GMT+10:00)
To: spacey_01 at outlook.com<mailto:spacey_01 at outlook.com>
Cc: CMake Mailinglist <cmake at cmake.org><mailto:cmake at cmake.org>
Subject: Re: [CMake] Beginners Guide to Cmake and Modern Cmake



Le sam. 28 juil. 2018 ? 01:01, spacey_01 at outlook.com<mailto:spacey_01 at outlook.com> <spacey_01 at outlook.com<mailto:spacey_01 at outlook.com>> a ?crit :
Hey Andreas,

 thanks for your comments. Yes I too have exhausted the resources you have mentioned here. The concepts make sense and I see the intended point but for a beginner its hard to grasp on how to implement and given the type of project  application of cmake's is diverse (easy to complex).

Im in need of some clear cut examples of modern cmake for it to really sink in (easy to complex).

I feel you have to be a veteran in cmake to understand how to implement the new way and overcome the problems of dependencies not providing modern transitive packages and the struggle of not just calling find_package.. etc. Instead we have to make that transition our selves in some cases. This is the hard part.


AIFAIK, your example software does not seem to be built with CMake so there is no transition to make for you.
Just use the "Modern way" from the ground up.

Concerning documentation, tutorial, webinar etc...
More and more resource are coming up:

1) The various slide/presentation already mentionned
2) The reference documentation (https://cmake.org/documentation/) which has improved a lot after the switch to sphinx
3) The kitware training of course: https://training.kitware.fr
4) Books
    - The book recently announced by Craig Scott: https://crascit.com/professional-cmake/
    - A forthcoming cookbook: https://www.packtpub.com/application-development/cmake-cookbook
and probably many other to come.

However if we are into making libraries it would be a benefit to know the process of cmake packages but at the advantage of being the maker and knowing the dependency path if the library does borrow.

I bet (but I did not read it) the book from Craig could help you with that, but I'm sure he may answer himself.

Now I am curious of what you mean by "it would be a benefit to know **the process of cmake packages**" ?
What do you mean by that?

It be great to see cmake.org<http://cmake.org> revamping the webinars for the aforementioned.

All that said I agree the current are oldish and would benefit an upgrade :-)

However from my perspective writing good doc, tutorial, webinar etc... is very time-consuming so may be worth buying some for that and give some rewards to people investing in it.
This is my own opinion though :-)

--
Eric



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

From quang.t.ha.20 at gmail.com  Mon Jul 30 10:20:32 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Mon, 30 Jul 2018 08:20:32 -0600
Subject: [CMake] CMAKE doesn't pass NVCC flags?
In-Reply-To: <CAJGuVd-h=dMn9hqSDs4hkaCM3Z6z=uJzgCo=08Br_8D82+E-4g@mail.gmail.com>
References: <CAGfE9+M0KouWihAN5f+j0i00rFoTuUUxAoq0DxZwkdggmU=trA@mail.gmail.com>
 <CAJGuVd-h=dMn9hqSDs4hkaCM3Z6z=uJzgCo=08Br_8D82+E-4g@mail.gmail.com>
Message-ID: <CAGfE9+PiuBU+=RjArY7q=gWtPHDD364rWV3THZRDUGeGq+RU3w@mail.gmail.com>

I see - thanks! This is working now for 3.11 with CMAKE_CUDA_FLAGS.

On Tue, 24 Jul 2018 at 15:55, Stephen McDowell <sjm324 at cornell.edu> wrote:

> I think you are mixing old and new approaches. Since you have enabled the
> CUDA language (via your project(...) call), you should be using either
> CUDAFLAGS or CMAKE_CUDA_FLAGS.
>
> I think CUDA_NVCC_FLAGS is only used for the old cuda_add_library or
> executable functions.
>
> Note that finding the cuda package should no longer be necessary. If you
> support non-CUDA builds you should use CheckLanguage and
> enable_language(CUDA), and remove CUDA from the project(...) call.
> Currently if nvcc is not found, configuration will fail because you have
> CUDA in the project command which makes it required.
>
> Hope that helps!
>
> -Stephen
>
> On Tue, Jul 24, 2018, 1:48 PM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>
>> So, it doesn't seem that my setting in NVCC flags is being used:
>>
>> In CMakeLists.txt:
>>
>> project(tangram LANGUAGES CXX CUDA)
>> [...]
>>
>>     FIND_PACKAGE(CUDA REQUIRED)
>>     if(CUDA_FOUND)
>>       add_definitions(-DCUDA_CALLABLE="__host__ __device__")
>>       set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-Xcompiler="-fopenmp -fPIC")
>>       set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--std=c++11
>> --expt-relaxed-constexpr)
>>       set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
>> arch=compute_70,code=sm_70)
>>       set(CUDA_PROPAGATE_HOST_FLAGS ON)
>>       set(CUDA_SEPARABLE_COMPILATION OFF)
>>       message(STATUS "CUDA include directories ${CUDA_INCLUDE_DIRS}")
>>       message(STATUS "Overwriting THRUST_DIR to point to
>> ${CUDA_INCLUDE_DIRS}/thrust")
>>       set(THRUST_DIR "${CUDA_INCLUDE_DIRS}")
>>       set(EXTRA_LIBS ${CUDA_LIBRARIES})
>>       message("CUDA flags" ${CUDA_NVCC_FLAGS})
>>     else(CUDA_FOUND)
>>       message(FATAL "CUDA not found")
>>     endif(CUDA_FOUND)
>> [...]
>>
>> Then, at cmake stage:
>> [...]
>> -- Overwriting THRUST_DIR to point to
>> /projects/opt/centos7/cuda/9.0/include/thrust
>> CUDA flags-Xcompiler="-fopenmp
>> -fPIC"--std=c++11--expt-relaxed-constexpr-gencodearch=compute_70,code=sm_70
>> -- Adding application directory app
>> [...]
>>
>> But then, build fail, and when I do make VERBOSE=1:
>> [...]
>> [ 60%] Building CUDA object
>> app/simple-vfgen-cuda/CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
>> cd /home/qth20/develop/tangram/build/app/simple-vfgen-cuda &&
>> /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__
>> __device__\"" -DHAVE_LAPACKE -DTHRUST
>> -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
>> -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -I/home/qth20/develop/tangram
>> -I/home/qth20/develop/tangram/build
>> -I/home/qth20/develop/tangram/cinch/logging
>> -I/home/qth20/installed/jali/include
>> -I/home/qth20/installed/jali-tpls/include
>> -I/home/qth20/installed/jali-tpls/trilinos-12-10-1/include
>> -I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include
>> -I/home/qth20/installed/jali-tpls/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
>> -I/home/qth20/installed/jali-tpls/include/UnitTest++ -I/usr/include/lapacke
>> -I/home/qth20/installed/xmof2d/include
>> -I/projects/opt/centos7/cuda/9.0/include  -O3 -DNDEBUG   -std=c++11 -x cu
>> -c /home/qth20/develop/tangram/app/simple-vfgen-cuda/simple-vfgen-cuda.cu
>> -o CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
>> [...]
>>
>> None of the flags was passed into nvcc. This is with cmake/3.11.1. Does
>> upgrading to 3.12 recommended to solve the issue?
>>
>> 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/20180730/5337a8f3/attachment-0001.html>

From jim at maplesong.com  Mon Jul 30 13:48:38 2018
From: jim at maplesong.com (Jim Carroll)
Date: Mon, 30 Jul 2018 13:48:38 -0400
Subject: [CMake] AUTOUIC generated headers not found by lib that uses lib
 with headers
Message-ID: <CAA0WT-OC7dSk7J7_EmX=yeF0V-7Nxn7abgE++roT4_4NtuMGiw@mail.gmail.com>

I have a project that I'm updating from Cmake 3.5 to 3.12.

In the project, I have UI libraries that use other libraries, both of which
use Qt 5.6.
The lowest-level library uses AUTOUIC and I see the headers are generated
in the new lib_autogen/include_BUILD_CONFIG directory.

When my higher level library tries to use the lower level library, I get
the error that it can't find the auto-generated headers. It only seems to
have trouble finding about six of two dozen ui_***.h files.

How can I get my lower level libraries to include the generated header
files so they're available to the higher level library that's using it?

I'm using
cmake 3.12
Qt 5.6
Visual Studio 2015

I tried creating a work-around where in the CMakeLists.txt of my lowest
level directory I add

# CMake 10+ has a bug where automoc header files aren't found
SET(COMPONENTS_UIC_HDRS_DIR
"${CMAKE_CURRENT_BINARY_DIR}/ComponentsLib_autogen/include_${
*CMAKE_BUILD_TYPE*}")
message("** COMPONENTS AUTOUIC autogen dir: ${COMPONENTS_UIC_HDRS_DIR}")
*target_include_directories*(ComponentsLib INTERFACE
${COMPONENTS_UIC_HDRS_DIR})

but of course the CMAKE_BUILD_TYPE isn't available to CMake at this time.
I'd have to move the headers into a place common to the various
(Debug/Release) configurations or something.

Thanks!
-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180730/7f1f4732/attachment.html>

From robert.maynard at kitware.com  Mon Jul 30 14:39:02 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 30 Jul 2018 14:39:02 -0400
Subject: [CMake] AUTOUIC generated headers not found by lib that uses
 lib with headers
In-Reply-To: <CAA0WT-OC7dSk7J7_EmX=yeF0V-7Nxn7abgE++roT4_4NtuMGiw@mail.gmail.com>
References: <CAA0WT-OC7dSk7J7_EmX=yeF0V-7Nxn7abgE++roT4_4NtuMGiw@mail.gmail.com>
Message-ID: <CAFzjYVpUvmenHg6D6-7KCYoj3uZjPoe062SN61NZvBBMft1xUA@mail.gmail.com>

You need to defer the evaluation of the include directory to generate
time, which will know what exactly build type is needed. This is done
by using `$<CONFIG>` instead of `${CMAKE_BUILD_TYPE`.

Something like the following should work:

set(directory "${CMAKE_CURRENT_BINARY_DIR}/ComponentsLib_autogen/include_$<CONFIG>")
target_include_directories(ComponentsLib INTERFACE ${directory})
On Mon, Jul 30, 2018 at 1:48 PM Jim Carroll <jim at maplesong.com> wrote:
>
> I have a project that I'm updating from Cmake 3.5 to 3.12.
>
> In the project, I have UI libraries that use other libraries, both of which use Qt 5.6.
> The lowest-level library uses AUTOUIC and I see the headers are generated in the new lib_autogen/include_BUILD_CONFIG directory.
>
> When my higher level library tries to use the lower level library, I get the error that it can't find the auto-generated headers. It only seems to have trouble finding about six of two dozen ui_***.h files.
>
> How can I get my lower level libraries to include the generated header files so they're available to the higher level library that's using it?
>
> I'm using
> cmake 3.12
> Qt 5.6
> Visual Studio 2015
>
> I tried creating a work-around where in the CMakeLists.txt of my lowest level directory I add
>
> # CMake 10+ has a bug where automoc header files aren't found
> SET(COMPONENTS_UIC_HDRS_DIR "${CMAKE_CURRENT_BINARY_DIR}/ComponentsLib_autogen/include_${CMAKE_BUILD_TYPE}")
> message("** COMPONENTS AUTOUIC autogen dir: ${COMPONENTS_UIC_HDRS_DIR}")
> target_include_directories(ComponentsLib INTERFACE ${COMPONENTS_UIC_HDRS_DIR})
>
> but of course the CMAKE_BUILD_TYPE isn't available to CMake at this time. I'd have to move the headers into a place common to the various (Debug/Release) configurations or something.
>
> Thanks!
> -Jim
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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 mario at emmenlauer.de  Mon Jul 30 17:43:10 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Mon, 30 Jul 2018 23:43:10 +0200
Subject: [CMake] order of includes seems wrong (or please help me
 understand)
In-Reply-To: <13ec3e40-afdc-0980-62c9-8095e36b211c@emmenlauer.de>
References: <13ec3e40-afdc-0980-62c9-8095e36b211c@emmenlauer.de>
Message-ID: <9ab4f86e-1466-67fc-efb3-ab85df58033e@emmenlauer.de>


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/

From crestchristopher at gmail.com  Tue Jul 31 00:17:45 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Tue, 31 Jul 2018 00:17:45 -0400
Subject: [CMake] Beginning to compiling CMake file
Message-ID: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>

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


From miroslav.kubiczek at gmail.com  Tue Jul 31 07:56:24 2018
From: miroslav.kubiczek at gmail.com (Miroslav Kubiczek)
Date: Tue, 31 Jul 2018 13:56:24 +0200
Subject: [CMake] issue with CPack: RPM package was not generated!
Message-ID: <CALJGPmxfeYv_fumd+ouQ7tDrWJw0hwo0kOFkh3buz3FsPvj=fA@mail.gmail.com>

Hi All,

I'm running cmake 3.10.1 and have this issue:

$ make package
[ 50%] Built target Rest
[100%] Built target UT_RestLibrary
Run CPack packaging tool...
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: XXXCommonCppLibrary
CPack: - Install project: XXXCommonCppLibrary
CPack: Create package
CPackRPM: Will use USER specified spec file:
/data/git/common-cpp-libs/build/XXX-common-cpp-libs.spec
CMake Error at
/usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2703
(message):
  RPM package was not generated!
  /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
Call Stack (most recent call first):

/usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2774
(cpack_rpm_generate_package)


CPack Error: Error while execution CPackRPM.cmake
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: XXX-common-cpp-libs
make: *** [package] Error 1

The rpm file is generated by those strange errors printed, make exits with
an error code and jenkins build fails.
Does anyone know how to fix this?

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

From craig.scott at crascit.com  Tue Jul 31 08:30:31 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 31 Jul 2018 22:30:31 +1000
Subject: [CMake] issue with CPack: RPM package was not generated!
In-Reply-To: <CALJGPmxfeYv_fumd+ouQ7tDrWJw0hwo0kOFkh3buz3FsPvj=fA@mail.gmail.com>
References: <CALJGPmxfeYv_fumd+ouQ7tDrWJw0hwo0kOFkh3buz3FsPvj=fA@mail.gmail.com>
Message-ID: <CA+dygYn1+c+Of+CRZGPfVnp8-6=BVVEHFFprM2yJYnpwW_xXYA@mail.gmail.com>

On Tue, Jul 31, 2018 at 9:56 PM, Miroslav Kubiczek <
miroslav.kubiczek at gmail.com> wrote:

> Hi All,
>
> I'm running cmake 3.10.1 and have this issue:
>
> $ make package
> [ 50%] Built target Rest
> [100%] Built target UT_RestLibrary
> Run CPack packaging tool...
> CPack: Create package using RPM
> CPack: Install projects
> CPack: - Run preinstall target for: XXXCommonCppLibrary
> CPack: - Install project: XXXCommonCppLibrary
> CPack: Create package
> CPackRPM: Will use USER specified spec file: /data/git/common-cpp-libs/
> build/XXX-common-cpp-libs.spec
> CMake Error at /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2703
> (message):
>   RPM package was not generated!
>   /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
> Call Stack (most recent call first):
>   /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2774
> (cpack_rpm_generate_package)
>
>
> CPack Error: Error while execution CPackRPM.cmake
> CPack Error: Problem compressing the directory
> CPack Error: Error when generating package: XXX-common-cpp-libs
> make: *** [package] Error 1
>
> The rpm file is generated by those strange errors printed, make exits with
> an error code and jenkins build fails.
> Does anyone know how to fix this?
>
>
A few things to check:


   - Have you given any install() commands in your project? The message
   above seems to be suggesting nothing was installed.
   - Are you overriding the .spec file rather than using the one
   CMake/CPack creates for you? If so, can you indicate why and maybe check
   its contents. Less likely this is the main issue, but worth covering anyway.



-- 
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/20180731/7a5ef3dc/attachment-0001.html>

From miroslav.kubiczek at gmail.com  Tue Jul 31 08:49:29 2018
From: miroslav.kubiczek at gmail.com (Miroslav Kubiczek)
Date: Tue, 31 Jul 2018 14:49:29 +0200
Subject: [CMake] issue with CPack: RPM package was not generated!
In-Reply-To: <CA+dygYn1+c+Of+CRZGPfVnp8-6=BVVEHFFprM2yJYnpwW_xXYA@mail.gmail.com>
References: <CALJGPmxfeYv_fumd+ouQ7tDrWJw0hwo0kOFkh3buz3FsPvj=fA@mail.gmail.com>
 <CA+dygYn1+c+Of+CRZGPfVnp8-6=BVVEHFFprM2yJYnpwW_xXYA@mail.gmail.com>
Message-ID: <CALJGPmwGF48t-gCCCeu-GthPu_wsW7k7FL02TJMeejrNYFzgWw@mail.gmail.com>

yes, there are install commands, one of CMakeLists.txt content:

install(DIRECTORY ${PROJECT_SOURCE_DIR}/api/rest DESTINATION include)
install(TARGETS Rest DESTINATION lib)

I can see these files after running the 'make package':
$ find ./_CPack_Packages/Linux/
./_CPack_Packages/Linux/
./_CPack_Packages/Linux/RPM
./_CPack_Packages/Linux/RPM/SOURCES
./_CPack_Packages/Linux/RPM/rpmbuildXXX-common-cpp-libs.err
./_CPack_Packages/Linux/RPM/tmp
./_CPack_Packages/Linux/RPM/rpmbuilXXX-common-cpp-libs.out
./_CPack_Packages/Linux/RPM/BUILDROOT
./_CPack_Packages/Linux/RPM/SRPMS
./_CPack_Packages/Linux/RPM/BUILD
./_CPack_Packages/Linux/RPM/SPECS
./_CPack_Packages/Linux/RPM/SPECS/XXX-common-cpp-libs.spec
./_CPack_Packages/Linux/RPM/RPMS
./_CPack_Packages/Linux/RPM/XXX-common-cpp-libs-7.0.0-1.x86_64.rpm

I'm generating the spec file from a template by:
configure_file("${CMAKE_CURRENT_SOURCE_DIR}/rpm/xxx-common-cpp-libs.spec.in"
"${CMAKE_CURRENT_BINARY_DIR}/xxx-common-cpp-libs.spec" @ONLY IMMEDIATE)

The genereated spec file looks like this:

Buildroot:
/data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/xxx-common-cpp-libs-7.0.0-1.x86_64
Summary:        xxx common cpp libs
Name:           xxx-common-cpp-libs
Version:        7.0.0
Release:        1
License:        Proprietary
Group:          Development/Tools/Other
Vendor:         xxx
Prefix:         /usr/local

%define _rpmdir /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
%define _rpmfilename xxx-common-cpp-libs-7.0.0-1.x86_64.rpm
%define _unpackaged_files_terminate_build 0
%define _topdir /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM

%description
...

# This is a shortcutted spec file generated by CMake RPM generator
# we skip _install step because CPack does that for us.
# We do only save CPack installed tree in _prepr
# and then restore it in build.
%prep
mv $RPM_BUILD_ROOT
/data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/tmpBBroot

%install
if [ -e $RPM_BUILD_ROOT ];
then
  rm -Rf $RPM_BUILD_ROOT
fi
mv "/data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/tmpBBroot"
$RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
/usr/local/lib/*
/usr/local/include/*

<EOF>

On Tue, Jul 31, 2018 at 2:30 PM, Craig Scott <craig.scott at crascit.com>
wrote:

>
>
> On Tue, Jul 31, 2018 at 9:56 PM, Miroslav Kubiczek <
> miroslav.kubiczek at gmail.com> wrote:
>
>> Hi All,
>>
>> I'm running cmake 3.10.1 and have this issue:
>>
>> $ make package
>> [ 50%] Built target Rest
>> [100%] Built target UT_RestLibrary
>> Run CPack packaging tool...
>> CPack: Create package using RPM
>> CPack: Install projects
>> CPack: - Run preinstall target for: XXXCommonCppLibrary
>> CPack: - Install project: XXXCommonCppLibrary
>> CPack: Create package
>> CPackRPM: Will use USER specified spec file:
>> /data/git/common-cpp-libs/build/XXX-common-cpp-libs.spec
>> CMake Error at /usr/local/cmake-3.10.1-Linux-
>> x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2703 (message):
>>   RPM package was not generated!
>>   /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
>> Call Stack (most recent call first):
>>   /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2774
>> (cpack_rpm_generate_package)
>>
>>
>> CPack Error: Error while execution CPackRPM.cmake
>> CPack Error: Problem compressing the directory
>> CPack Error: Error when generating package: XXX-common-cpp-libs
>> make: *** [package] Error 1
>>
>> The rpm file is generated by those strange errors printed, make exits
>> with an error code and jenkins build fails.
>> Does anyone know how to fix this?
>>
>>
> A few things to check:
>
>
>    - Have you given any install() commands in your project? The message
>    above seems to be suggesting nothing was installed.
>    - Are you overriding the .spec file rather than using the one
>    CMake/CPack creates for you? If so, can you indicate why and maybe check
>    its contents. Less likely this is the main issue, but worth covering anyway.
>
>
>
> --
> 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/20180731/0161a2dc/attachment.html>

From robert.maynard at kitware.com  Tue Jul 31 09:04:26 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 31 Jul 2018 09:04:26 -0400
Subject: [CMake] order of includes seems wrong (or please help me
 understand)
In-Reply-To: <9ab4f86e-1466-67fc-efb3-ab85df58033e@emmenlauer.de>
References: <13ec3e40-afdc-0980-62c9-8095e36b211c@emmenlauer.de>
 <9ab4f86e-1466-67fc-efb3-ab85df58033e@emmenlauer.de>
Message-ID: <CAFzjYVpTodzxoQ0R4_F3xAmcqH43UWx2yZBKD3+Wu4GNZDw8Qw@mail.gmail.com>

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

From eric.noulard at gmail.com  Tue Jul 31 09:11:07 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 31 Jul 2018 15:11:07 +0200
Subject: [CMake] issue with CPack: RPM package was not generated!
In-Reply-To: <CALJGPmwGF48t-gCCCeu-GthPu_wsW7k7FL02TJMeejrNYFzgWw@mail.gmail.com>
References: <CALJGPmxfeYv_fumd+ouQ7tDrWJw0hwo0kOFkh3buz3FsPvj=fA@mail.gmail.com>
 <CA+dygYn1+c+Of+CRZGPfVnp8-6=BVVEHFFprM2yJYnpwW_xXYA@mail.gmail.com>
 <CALJGPmwGF48t-gCCCeu-GthPu_wsW7k7FL02TJMeejrNYFzgWw@mail.gmail.com>
Message-ID: <CAPASGLpWEAH_ML1jR9-JJtp6UdBfOEdetn7J97ZRsosyNxGWoQ@mail.gmail.com>

Hi Miroslav,

Do you need something very specific that you need a custom spec file?
If this is not the case you should try to let CPackRPM generate the spec
file for you.

This "USER spec file" feature was designed (quite a long time ago) when
CPackRPM was lacking some features that came in after that.
It was a debug & developer feature as well in order to ease CPackRPM
evolution.
This was made public in order to be able to "unblock" user before they get
the awaited feature in next CPackRPM release.
The USER spec file cannot be as rich as a "standard RPM spec file" there is
some restriction in what you can write in it.

In any case you can try to switch on CPackRPM debug output:
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

You should be able to get more detail about the failure.
In this mode CPack RPM will tell you where is the log/err file you can
inspect to know more.


Le mar. 31 juil. 2018 ? 14:49, Miroslav Kubiczek <
miroslav.kubiczek at gmail.com> a ?crit :

> yes, there are install commands, one of CMakeLists.txt content:
>
> install(DIRECTORY ${PROJECT_SOURCE_DIR}/api/rest DESTINATION include)
> install(TARGETS Rest DESTINATION lib)
>
> I can see these files after running the 'make package':
> $ find ./_CPack_Packages/Linux/
> ./_CPack_Packages/Linux/
> ./_CPack_Packages/Linux/RPM
> ./_CPack_Packages/Linux/RPM/SOURCES
> ./_CPack_Packages/Linux/RPM/rpmbuildXXX-common-cpp-libs.err
> ./_CPack_Packages/Linux/RPM/tmp
> ./_CPack_Packages/Linux/RPM/rpmbuilXXX-common-cpp-libs.out
> ./_CPack_Packages/Linux/RPM/BUILDROOT
> ./_CPack_Packages/Linux/RPM/SRPMS
> ./_CPack_Packages/Linux/RPM/BUILD
> ./_CPack_Packages/Linux/RPM/SPECS
> ./_CPack_Packages/Linux/RPM/SPECS/XXX-common-cpp-libs.spec
> ./_CPack_Packages/Linux/RPM/RPMS
> ./_CPack_Packages/Linux/RPM/XXX-common-cpp-libs-7.0.0-1.x86_64.rpm
>
> I'm generating the spec file from a template by:
> configure_file("${CMAKE_CURRENT_SOURCE_DIR}/rpm/
> xxx-common-cpp-libs.spec.in"
> "${CMAKE_CURRENT_BINARY_DIR}/xxx-common-cpp-libs.spec" @ONLY IMMEDIATE)
>
> The genereated spec file looks like this:
>
> Buildroot:
> /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/xxx-common-cpp-libs-7.0.0-1.x86_64
> Summary:        xxx common cpp libs
> Name:           xxx-common-cpp-libs
> Version:        7.0.0
> Release:        1
> License:        Proprietary
> Group:          Development/Tools/Other
> Vendor:         xxx
> Prefix:         /usr/local
>
> %define _rpmdir /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
> %define _rpmfilename xxx-common-cpp-libs-7.0.0-1.x86_64.rpm
> %define _unpackaged_files_terminate_build 0
> %define _topdir /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
>
> %description
> ...
>
> # This is a shortcutted spec file generated by CMake RPM generator
> # we skip _install step because CPack does that for us.
> # We do only save CPack installed tree in _prepr
> # and then restore it in build.
> %prep
> mv $RPM_BUILD_ROOT
> /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/tmpBBroot
>
> %install
> if [ -e $RPM_BUILD_ROOT ];
> then
>   rm -Rf $RPM_BUILD_ROOT
> fi
> mv "/data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/tmpBBroot"
> $RPM_BUILD_ROOT
>
> %files
> %defattr(-,root,root,-)
> /usr/local/lib/*
> /usr/local/include/*
>
> <EOF>
>
> On Tue, Jul 31, 2018 at 2:30 PM, Craig Scott <craig.scott at crascit.com>
> wrote:
>
>>
>>
>> On Tue, Jul 31, 2018 at 9:56 PM, Miroslav Kubiczek <
>> miroslav.kubiczek at gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm running cmake 3.10.1 and have this issue:
>>>
>>> $ make package
>>> [ 50%] Built target Rest
>>> [100%] Built target UT_RestLibrary
>>> Run CPack packaging tool...
>>> CPack: Create package using RPM
>>> CPack: Install projects
>>> CPack: - Run preinstall target for: XXXCommonCppLibrary
>>> CPack: - Install project: XXXCommonCppLibrary
>>> CPack: Create package
>>> CPackRPM: Will use USER specified spec file:
>>> /data/git/common-cpp-libs/build/XXX-common-cpp-libs.spec
>>> CMake Error at
>>> /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2703
>>> (message):
>>>   RPM package was not generated!
>>>   /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
>>> Call Stack (most recent call first):
>>>
>>> /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2774
>>> (cpack_rpm_generate_package)
>>>
>>>
>>> CPack Error: Error while execution CPackRPM.cmake
>>> CPack Error: Problem compressing the directory
>>> CPack Error: Error when generating package: XXX-common-cpp-libs
>>> make: *** [package] Error 1
>>>
>>> The rpm file is generated by those strange errors printed, make exits
>>> with an error code and jenkins build fails.
>>> Does anyone know how to fix this?
>>>
>>>
>> A few things to check:
>>
>>
>>    - Have you given any install() commands in your project? The message
>>    above seems to be suggesting nothing was installed.
>>    - Are you overriding the .spec file rather than using the one
>>    CMake/CPack creates for you? If so, can you indicate why and maybe check
>>    its contents. Less likely this is the main issue, but worth covering anyway.
>>
>>
>>
>> --
>> 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
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180731/9c8450c2/attachment-0001.html>

From ripopov at gmail.com  Tue Jul 31 12:47:04 2018
From: ripopov at gmail.com (Roman Popov)
Date: Tue, 31 Jul 2018 09:47:04 -0700
Subject: [CMake] Get compiler command line (or json compilation
 database) for a target
In-Reply-To: <CAATAM3EYLCvbJ9wOd+ZriaWQHV22LOTvETB1GfeHdZMXbBLybw@mail.gmail.com>
References: <CAATAM3EYLCvbJ9wOd+ZriaWQHV22LOTvETB1GfeHdZMXbBLybw@mail.gmail.com>
Message-ID: <CAATAM3FpCDiGiQur0rG=RgfY9Ek=UHyxwsytgQUX_DfNMgv4QQ@mail.gmail.com>

After day of googling I've found a solution that almost works for me.

There is a CXX_CLANG_TIDY property that enables clang-tidy on a target.
https://cmake.org/cmake/help/v3.12/prop_tgt/LANG_CLANG_TIDY.html
But I can replace clang-tidy with my own Clang-based tool:

set(CLANG_TIDY_EXE  ${MY_CLANG_BASED_TOOL} )
set(DO_CLANG_TIDY "${CLANG_TIDY_EXE}" " --my-additional-options")

set_target_properties(
        my_exe_target PROPERTIES
        CXX_CLANG_TIDY "${DO_CLANG_TIDY}"
)

The only drawback is that my tool will be run together with my_exe_target
build.  And I want to run it as a separate build target.
https://stackoverflow.com/questions/51618307/how-to-run-clang-based-tool-as-a-separate-cmake-target


??, 30 ???. 2018 ?. ? 0:12, Roman Popov <ripopov at gmail.com>:

> Hi all,
>
> How can I get a full compiler command line for a given target in
> CMakeLists project? I want to run Clang-based tool on some targets (using
> CTest), and it requires same options as used during compilation.
>
> I know there is CMAKE_EXPORT_COMPILE_COMMANDS but it is not taget-specific.
>
> There is a similar question on stackoverflow:
> https://stackoverflow.com/questions/35808209/get-full-c-compiler-command-line
> Here author suggets to use get_target_property on a target.  I've tried
> this, but it does not work when some properties are inherited from
> libraries (for example include paths).
>
> Do you have any ideas?
>
> Thanks,
> Roman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180731/43e8e856/attachment.html>

From ripopov at gmail.com  Tue Jul 31 12:53:10 2018
From: ripopov at gmail.com (Roman Popov)
Date: Tue, 31 Jul 2018 09:53:10 -0700
Subject: [CMake] Get compiler command line (or json compilation
 database) for a target
In-Reply-To: <CAATAM3FpCDiGiQur0rG=RgfY9Ek=UHyxwsytgQUX_DfNMgv4QQ@mail.gmail.com>
References: <CAATAM3EYLCvbJ9wOd+ZriaWQHV22LOTvETB1GfeHdZMXbBLybw@mail.gmail.com>
 <CAATAM3FpCDiGiQur0rG=RgfY9Ek=UHyxwsytgQUX_DfNMgv4QQ@mail.gmail.com>
Message-ID: <CAATAM3HhoN5ObghAtz1r0gteorRL-qRs1+2hxhTHnSboAZksCg@mail.gmail.com>

In general I don't understand why CMake provides a separate integration for
each tool (<LANG>_CLANG_TIDY <LANG>_COMPILER_LAUNCHER <LANG>_CPPCHECK
<LANG>_CPPLINT <LANG>_INCLUDE_WHAT_YOU_USE),

But a generic solution is not provided  (or not documented clearly? )

??, 31 ???. 2018 ?. ? 9:47, Roman Popov <ripopov at gmail.com>:

> After day of googling I've found a solution that almost works for me.
>
> There is a CXX_CLANG_TIDY property that enables clang-tidy on a target.
> https://cmake.org/cmake/help/v3.12/prop_tgt/LANG_CLANG_TIDY.html
> But I can replace clang-tidy with my own Clang-based tool:
>
> set(CLANG_TIDY_EXE  ${MY_CLANG_BASED_TOOL} )
> set(DO_CLANG_TIDY "${CLANG_TIDY_EXE}" " --my-additional-options")
>
> set_target_properties(
>         my_exe_target PROPERTIES
>         CXX_CLANG_TIDY "${DO_CLANG_TIDY}"
> )
>
> The only drawback is that my tool will be run together with my_exe_target
> build.  And I want to run it as a separate build target.
>
> https://stackoverflow.com/questions/51618307/how-to-run-clang-based-tool-as-a-separate-cmake-target
>
>
> ??, 30 ???. 2018 ?. ? 0:12, Roman Popov <ripopov at gmail.com>:
>
>> Hi all,
>>
>> How can I get a full compiler command line for a given target in
>> CMakeLists project? I want to run Clang-based tool on some targets (using
>> CTest), and it requires same options as used during compilation.
>>
>> I know there is CMAKE_EXPORT_COMPILE_COMMANDS but it is not
>> taget-specific.
>>
>> There is a similar question on stackoverflow:
>> https://stackoverflow.com/questions/35808209/get-full-c-compiler-command-line
>> Here author suggets to use get_target_property on a target.  I've tried
>> this, but it does not work when some properties are inherited from
>> libraries (for example include paths).
>>
>> Do you have any ideas?
>>
>> Thanks,
>> Roman
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180731/b03c27a8/attachment.html>

From mellery451 at gmail.com  Tue Jul 31 12:56:27 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Tue, 31 Jul 2018 09:56:27 -0700
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: <1549AA90-9773-45C9-A5E1-650B8DE5D623@gmail.com>

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/20180731/690909e2/attachment.sig>

From quang.t.ha.20 at gmail.com  Tue Jul 31 13:43:36 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Tue, 31 Jul 2018 11:43:36 -0600
Subject: [CMake] CMake for CUDA with MPICC still using gcc to link?
Message-ID: <CAGfE9+OfoByY1nFusGfFd3ormxgQgfEm5f=fwzd-fTdzKwA+PQ@mail.gmail.com>

Hi all,

Currently using cmake/3.11.1, I want to try and compile MPI/CUDA
application with cmake. I kept running into problems of 'undefined
MPI_Init', so I take a look at `make VERBOSE=1`. The output looks something
like this

===============================================================================
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script
CMakeFiles/tangram.dir/link.txt --verbose=1
*/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/bin/mpicc* -fPIC -fopenmp
-O3 -DNDEBUG  -shared -Wl,-soname,libtangram.so -o libtangram.so
CMakeFiles/tangram.dir/tangram/intersect/r3d.c.o
make[2]: Leaving directory `/home/qth20/develop/tangram/build'
[ 40%] Built target tangram
make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make
app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/depend
make[2]: Entering directory `/home/qth20/develop/tangram/build'
cd /home/qth20/develop/tangram/build &&
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_depends "Unix
Makefiles" /home/qth20/develop/tangram
/home/qth20/develop/tangram/app/vfgen-cuda
/home/qth20/develop/tangram/build
/home/qth20/develop/tangram/build/app/vfgen-cud$
 /home/qth20/develop/tangram/build/app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/DependInfo.cmake
--color=
make[2]: Leaving directory `/home/qth20/develop/tangram/build'
make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make
app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build
make[2]: Entering directory `/home/qth20/develop/tangram/build'
[ 60%] Building CUDA object
app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
cd /home/qth20/develop/tangram/build/app/vfgen-cuda &&
/projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__
__device__\"" -DENABLE_MPI -DHAVE_LAPACKE -DMPICH_SKIP_MPICXX
-DOMPI_SKIP_MPICXX -DTHRUST
-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -DTHRUST$
HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/home/qth20/develop/tangram
-I/home/qth20/develop/tangram/build
-I/home/qth20/develop/tangram/cinch/logging
-I/home/qth20/installed/jali-gcc_6.4.0-openmpi-2.1.2/include
-I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/include
-I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/include
-I/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/include
-I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
-I/home/qth20/installed$
jali-tpls-gcc_6.4.0-openmpi-2.1.2/include/UnitTest++ -I/usr/include/lapacke
-I/home/qth20/installed/xmof2d-gcc_6.4.0-openmpi_2.1.2/include
-I/projects/opt/centos7/cuda/9.0/include  --expt-relaxed-constexpr
--std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG   -x cu -c /home$
qth20/develop/tangram/app/vfgen-cuda/vfgen-cuda.cu -o
CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
/home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1708):
warning: variable "nnodes" was declared but never referenced

/home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1993):
warning: variable "ncells" was declared but never referenced

/home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(2070):
warning: variable "ibndry" was declared but never referenced

[ 80%] Linking CUDA device code
CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
cd /home/qth20/develop/tangram/build/app/vfgen-cuda &&
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script
CMakeFiles/vfgen-cuda.dir/dlink.txt --verbose=1
/projects/opt/centos7/cuda/9.0/bin/nvcc  --expt-relaxed-constexpr
--std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG  -Xcompiler=-fPIC
-Wno-deprecated-gpu-targets -shared -dlink
CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o -o
CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
[100%] Linking CUDA executable vfgen-cuda
cd /home/qth20/develop/tangram/build/app/vfgen-cuda &&
/projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script
CMakeFiles/vfgen-cuda.dir/link.txt --verbose=1
*/projects/opt/centos7/gcc/6.4.0/bin/g++*
CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
CMakeFiles/vfgen-cuda.dir/cmake_device_link.o -o vfgen-cuda
/projects/opt/centos7/cuda/9.0/lib64/libcudart_static.a -ldl
/usr/lib64/librt.so  -L"/projects/opt/centos7/cuda/9.0/lib64/stubs"
 -L"/projects/opt/centos7/cuda/9.0/lib64" -lcudadevrt -lcudart_static -lrt
-lpthread -ldl
===============================================================================

so apparently, mpicc is used other parts of the project, but when linking
extension between object codes it snaps back to g++(!). I have already
specified CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to be mpicc and mpic++,
respectively. Inside the CMakeLists for this CUDA:

===============================================================================
project(tangram LANGUAGES CXX CUDA)
[...]
if (CUDA_FOUND)
   string(APPEND CMAKE_CUDA_FLAGS "--expt-relaxed-constexpr --std=c++11 ")
   # Other CUDA flags
endif(CUDA_FOUND)

[... Inside CUDA app directory...]
add_executable(vfgen-cuda vfgen-cuda.cu)
target_link_libraries(vfgen-cuda ${EXTRA_LIBS} ${MPI_LIBRARIES})
===============================================================================

Is something missed out?

Thanks,
Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180731/8cdab47c/attachment-0001.html>

From robert.maynard at kitware.com  Tue Jul 31 15:11:27 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 31 Jul 2018 15:11:27 -0400
Subject: [CMake] CMake for CUDA with MPICC still using gcc to link?
In-Reply-To: <CAGfE9+OfoByY1nFusGfFd3ormxgQgfEm5f=fwzd-fTdzKwA+PQ@mail.gmail.com>
References: <CAGfE9+OfoByY1nFusGfFd3ormxgQgfEm5f=fwzd-fTdzKwA+PQ@mail.gmail.com>
Message-ID: <CAFzjYVouFMxOY-T8qV8wzE_2dyve86aKe1szmPSw-JYihVP+6A@mail.gmail.com>

It is snapping back to g++ as that was the linker that nvcc uses when
it builds an executable. CMake detects this as part of the compiler
detection process.

I haven't verified that this will work but you can try specifying the
LINKER_LANGUAGE(https://cmake.org/cmake/help/v3.12/prop_tgt/LINKER_LANGUAGE.html)
of the executable to be 'CXX'. You might also explore specifying
'CMAKE_CUDA_HOST_COMPILER' as part of your initial cmake configuration
options to be the same as your c++ compiler ( you will need a clean
build directory for this to work).
On Tue, Jul 31, 2018 at 1:43 PM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>
> Hi all,
>
> Currently using cmake/3.11.1, I want to try and compile MPI/CUDA application with cmake. I kept running into problems of 'undefined MPI_Init', so I take a look at `make VERBOSE=1`. The output looks something like this
>
> ===============================================================================
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/tangram.dir/link.txt --verbose=1
> /projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/bin/mpicc -fPIC -fopenmp -O3 -DNDEBUG  -shared -Wl,-soname,libtangram.so -o libtangram.so CMakeFiles/tangram.dir/tangram/intersect/r3d.c.o
> make[2]: Leaving directory `/home/qth20/develop/tangram/build'
> [ 40%] Built target tangram
> make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/depend
> make[2]: Entering directory `/home/qth20/develop/tangram/build'
> cd /home/qth20/develop/tangram/build && /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_depends "Unix Makefiles" /home/qth20/develop/tangram /home/qth20/develop/tangram/app/vfgen-cuda /home/qth20/develop/tangram/build /home/qth20/develop/tangram/build/app/vfgen-cud$
>  /home/qth20/develop/tangram/build/app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/DependInfo.cmake --color=
> make[2]: Leaving directory `/home/qth20/develop/tangram/build'
> make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build
> make[2]: Entering directory `/home/qth20/develop/tangram/build'
> [ 60%] Building CUDA object app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> cd /home/qth20/develop/tangram/build/app/vfgen-cuda && /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__ __device__\"" -DENABLE_MPI -DHAVE_LAPACKE -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -DTHRUST -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -DTHRUST$
> HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/home/qth20/develop/tangram -I/home/qth20/develop/tangram/build -I/home/qth20/develop/tangram/cinch/logging -I/home/qth20/installed/jali-gcc_6.4.0-openmpi-2.1.2/include -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/include
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/include -I/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/include -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/lib/cmake/Zoltan/../../../include -I/home/qth20/installed$
> jali-tpls-gcc_6.4.0-openmpi-2.1.2/include/UnitTest++ -I/usr/include/lapacke -I/home/qth20/installed/xmof2d-gcc_6.4.0-openmpi_2.1.2/include -I/projects/opt/centos7/cuda/9.0/include  --expt-relaxed-constexpr --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG   -x cu -c /home$
> qth20/develop/tangram/app/vfgen-cuda/vfgen-cuda.cu -o CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1708): warning: variable "nnodes" was declared but never referenced
>
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1993): warning: variable "ncells" was declared but never referenced
>
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(2070): warning: variable "ibndry" was declared but never referenced
>
> [ 80%] Linking CUDA device code CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
> cd /home/qth20/develop/tangram/build/app/vfgen-cuda && /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/vfgen-cuda.dir/dlink.txt --verbose=1
> /projects/opt/centos7/cuda/9.0/bin/nvcc  --expt-relaxed-constexpr --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG  -Xcompiler=-fPIC -Wno-deprecated-gpu-targets -shared -dlink CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o -o CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
> [100%] Linking CUDA executable vfgen-cuda
> cd /home/qth20/develop/tangram/build/app/vfgen-cuda && /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/vfgen-cuda.dir/link.txt --verbose=1
> /projects/opt/centos7/gcc/6.4.0/bin/g++   CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o CMakeFiles/vfgen-cuda.dir/cmake_device_link.o -o vfgen-cuda /projects/opt/centos7/cuda/9.0/lib64/libcudart_static.a -ldl /usr/lib64/librt.so  -L"/projects/opt/centos7/cuda/9.0/lib64/stubs"
>  -L"/projects/opt/centos7/cuda/9.0/lib64" -lcudadevrt -lcudart_static -lrt -lpthread -ldl
> ===============================================================================
>
> so apparently, mpicc is used other parts of the project, but when linking extension between object codes it snaps back to g++(!). I have already specified CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to be mpicc and mpic++, respectively. Inside the CMakeLists for this CUDA:
>
> ===============================================================================
> project(tangram LANGUAGES CXX CUDA)
> [...]
> if (CUDA_FOUND)
>    string(APPEND CMAKE_CUDA_FLAGS "--expt-relaxed-constexpr --std=c++11 ")
>    # Other CUDA flags
> endif(CUDA_FOUND)
>
> [... Inside CUDA app directory...]
> add_executable(vfgen-cuda vfgen-cuda.cu)
> target_link_libraries(vfgen-cuda ${EXTRA_LIBS} ${MPI_LIBRARIES})
> ===============================================================================
>
> Is something missed out?
>
> 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

From quang.t.ha.20 at gmail.com  Tue Jul 31 15:31:00 2018
From: quang.t.ha.20 at gmail.com (Quang Ha)
Date: Tue, 31 Jul 2018 13:31:00 -0600
Subject: [CMake] CMake for CUDA with MPICC still using gcc to link?
In-Reply-To: <CAFzjYVouFMxOY-T8qV8wzE_2dyve86aKe1szmPSw-JYihVP+6A@mail.gmail.com>
References: <CAGfE9+OfoByY1nFusGfFd3ormxgQgfEm5f=fwzd-fTdzKwA+PQ@mail.gmail.com>
 <CAFzjYVouFMxOY-T8qV8wzE_2dyve86aKe1szmPSw-JYihVP+6A@mail.gmail.com>
Message-ID: <CAGfE9+NgJpXp8aN5fYHhYrN-v0fgjGcqu05nU5pnYob-U0kp4Q@mail.gmail.com>

Thanks Robert - specific at the cmake -D [...] command seemsd to work. Is
it possible to set this inside a CMakeLists.txt? I have tried:

set(CUDA_HOST_COMPILER ${CMAKE_CXX_COMPILER})
set(CUDA_LINKER_PREFERENCE ${CMAKE_CXX_COMPILER})

but it snaps back to gcc still.

Thanks,
QT

On Tue, 31 Jul 2018 at 13:12, Robert Maynard <robert.maynard at kitware.com>
wrote:

> It is snapping back to g++ as that was the linker that nvcc uses when
> it builds an executable. CMake detects this as part of the compiler
> detection process.
>
> I haven't verified that this will work but you can try specifying the
> LINKER_LANGUAGE(
> https://cmake.org/cmake/help/v3.12/prop_tgt/LINKER_LANGUAGE.html)
> of the executable to be 'CXX'. You might also explore specifying
> 'CMAKE_CUDA_HOST_COMPILER' as part of your initial cmake configuration
> options to be the same as your c++ compiler ( you will need a clean
> build directory for this to work).
> On Tue, Jul 31, 2018 at 1:43 PM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
> >
> > Hi all,
> >
> > Currently using cmake/3.11.1, I want to try and compile MPI/CUDA
> application with cmake. I kept running into problems of 'undefined
> MPI_Init', so I take a look at `make VERBOSE=1`. The output looks something
> like this
> >
> >
> ===============================================================================
> > /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script
> CMakeFiles/tangram.dir/link.txt --verbose=1
> > /projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/bin/mpicc -fPIC -fopenmp
> -O3 -DNDEBUG  -shared -Wl,-soname,libtangram.so -o libtangram.so
> CMakeFiles/tangram.dir/tangram/intersect/r3d.c.o
> > make[2]: Leaving directory `/home/qth20/develop/tangram/build'
> > [ 40%] Built target tangram
> > make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make
> app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/depend
> > make[2]: Entering directory `/home/qth20/develop/tangram/build'
> > cd /home/qth20/develop/tangram/build &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_depends "Unix
> Makefiles" /home/qth20/develop/tangram
> /home/qth20/develop/tangram/app/vfgen-cuda
> /home/qth20/develop/tangram/build
> /home/qth20/develop/tangram/build/app/vfgen-cud$
> >
> /home/qth20/develop/tangram/build/app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/DependInfo.cmake
> --color=
> > make[2]: Leaving directory `/home/qth20/develop/tangram/build'
> > make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make
> app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build
> > make[2]: Entering directory `/home/qth20/develop/tangram/build'
> > [ 60%] Building CUDA object
> app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda &&
> /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__
> __device__\"" -DENABLE_MPI -DHAVE_LAPACKE -DMPICH_SKIP_MPICXX
> -DOMPI_SKIP_MPICXX -DTHRUST
> -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -DTHRUST$
> > HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/home/qth20/develop/tangram
> -I/home/qth20/develop/tangram/build
> -I/home/qth20/develop/tangram/cinch/logging
> -I/home/qth20/installed/jali-gcc_6.4.0-openmpi-2.1.2/include
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/include
> >
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/include
> -I/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/include
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
> -I/home/qth20/installed$
> > jali-tpls-gcc_6.4.0-openmpi-2.1.2/include/UnitTest++
> -I/usr/include/lapacke
> -I/home/qth20/installed/xmof2d-gcc_6.4.0-openmpi_2.1.2/include
> -I/projects/opt/centos7/cuda/9.0/include  --expt-relaxed-constexpr
> --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG   -x cu -c /home$
> > qth20/develop/tangram/app/vfgen-cuda/vfgen-cuda.cu -o
> CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> >
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1708):
> warning: variable "nnodes" was declared but never referenced
> >
> >
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1993):
> warning: variable "ncells" was declared but never referenced
> >
> >
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(2070):
> warning: variable "ibndry" was declared but never referenced
> >
> > [ 80%] Linking CUDA device code
> CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script
> CMakeFiles/vfgen-cuda.dir/dlink.txt --verbose=1
> > /projects/opt/centos7/cuda/9.0/bin/nvcc  --expt-relaxed-constexpr
> --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG  -Xcompiler=-fPIC
> -Wno-deprecated-gpu-targets -shared -dlink
> CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o -o
> CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
> > [100%] Linking CUDA executable vfgen-cuda
> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script
> CMakeFiles/vfgen-cuda.dir/link.txt --verbose=1
> > /projects/opt/centos7/gcc/6.4.0/bin/g++
>  CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> CMakeFiles/vfgen-cuda.dir/cmake_device_link.o -o vfgen-cuda
> /projects/opt/centos7/cuda/9.0/lib64/libcudart_static.a -ldl
> /usr/lib64/librt.so  -L"/projects/opt/centos7/cuda/9.0/lib64/stubs"
> >  -L"/projects/opt/centos7/cuda/9.0/lib64" -lcudadevrt -lcudart_static
> -lrt -lpthread -ldl
> >
> ===============================================================================
> >
> > so apparently, mpicc is used other parts of the project, but when
> linking extension between object codes it snaps back to g++(!). I have
> already specified CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to be mpicc and
> mpic++, respectively. Inside the CMakeLists for this CUDA:
> >
> >
> ===============================================================================
> > project(tangram LANGUAGES CXX CUDA)
> > [...]
> > if (CUDA_FOUND)
> >    string(APPEND CMAKE_CUDA_FLAGS "--expt-relaxed-constexpr --std=c++11
> ")
> >    # Other CUDA flags
> > endif(CUDA_FOUND)
> >
> > [... Inside CUDA app directory...]
> > add_executable(vfgen-cuda vfgen-cuda.cu)
> > target_link_libraries(vfgen-cuda ${EXTRA_LIBS} ${MPI_LIBRARIES})
> >
> ===============================================================================
> >
> > Is something missed out?
> >
> > 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/20180731/2e499726/attachment-0001.html>

From robert.maynard at kitware.com  Tue Jul 31 15:40:52 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 31 Jul 2018 15:40:52 -0400
Subject: [CMake] CMake for CUDA with MPICC still using gcc to link?
In-Reply-To: <CAGfE9+NgJpXp8aN5fYHhYrN-v0fgjGcqu05nU5pnYob-U0kp4Q@mail.gmail.com>
References: <CAGfE9+OfoByY1nFusGfFd3ormxgQgfEm5f=fwzd-fTdzKwA+PQ@mail.gmail.com>
 <CAFzjYVouFMxOY-T8qV8wzE_2dyve86aKe1szmPSw-JYihVP+6A@mail.gmail.com>
 <CAGfE9+NgJpXp8aN5fYHhYrN-v0fgjGcqu05nU5pnYob-U0kp4Q@mail.gmail.com>
Message-ID: <CAFzjYVrw0K4x-82zj40cBreOeooemTXHyOUifaED3sro3rzZfQ@mail.gmail.com>

The CUDA_HOST_COMPILER must be specified as a -D option on the first
invocation of cmake as it is used during the compiler detection
process.

The <LANG>_LINKER_PREFERENCE is a numeric value that determines which
language will be selected for linking when a library/executable has
source files from multiple languages.
On Tue, Jul 31, 2018 at 3:31 PM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>
> Thanks Robert - specific at the cmake -D [...] command seemsd to work. Is it possible to set this inside a CMakeLists.txt? I have tried:
>
> set(CUDA_HOST_COMPILER ${CMAKE_CXX_COMPILER})
> set(CUDA_LINKER_PREFERENCE ${CMAKE_CXX_COMPILER})
>
> but it snaps back to gcc still.
>
> Thanks,
> QT
>
> On Tue, 31 Jul 2018 at 13:12, Robert Maynard <robert.maynard at kitware.com> wrote:
>>
>> It is snapping back to g++ as that was the linker that nvcc uses when
>> it builds an executable. CMake detects this as part of the compiler
>> detection process.
>>
>> I haven't verified that this will work but you can try specifying the
>> LINKER_LANGUAGE(https://cmake.org/cmake/help/v3.12/prop_tgt/LINKER_LANGUAGE.html)
>> of the executable to be 'CXX'. You might also explore specifying
>> 'CMAKE_CUDA_HOST_COMPILER' as part of your initial cmake configuration
>> options to be the same as your c++ compiler ( you will need a clean
>> build directory for this to work).
>> On Tue, Jul 31, 2018 at 1:43 PM Quang Ha <quang.t.ha.20 at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > Currently using cmake/3.11.1, I want to try and compile MPI/CUDA application with cmake. I kept running into problems of 'undefined MPI_Init', so I take a look at `make VERBOSE=1`. The output looks something like this
>> >
>> > ===============================================================================
>> > /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/tangram.dir/link.txt --verbose=1
>> > /projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/bin/mpicc -fPIC -fopenmp -O3 -DNDEBUG  -shared -Wl,-soname,libtangram.so -o libtangram.so CMakeFiles/tangram.dir/tangram/intersect/r3d.c.o
>> > make[2]: Leaving directory `/home/qth20/develop/tangram/build'
>> > [ 40%] Built target tangram
>> > make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/depend
>> > make[2]: Entering directory `/home/qth20/develop/tangram/build'
>> > cd /home/qth20/develop/tangram/build && /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_depends "Unix Makefiles" /home/qth20/develop/tangram /home/qth20/develop/tangram/app/vfgen-cuda /home/qth20/develop/tangram/build /home/qth20/develop/tangram/build/app/vfgen-cud$
>> >  /home/qth20/develop/tangram/build/app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/DependInfo.cmake --color=
>> > make[2]: Leaving directory `/home/qth20/develop/tangram/build'
>> > make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build
>> > make[2]: Entering directory `/home/qth20/develop/tangram/build'
>> > [ 60%] Building CUDA object app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
>> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda && /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__ __device__\"" -DENABLE_MPI -DHAVE_LAPACKE -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -DTHRUST -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -DTHRUST$
>> > HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/home/qth20/develop/tangram -I/home/qth20/develop/tangram/build -I/home/qth20/develop/tangram/cinch/logging -I/home/qth20/installed/jali-gcc_6.4.0-openmpi-2.1.2/include -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/include
>> > -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/include -I/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/include -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/lib/cmake/Zoltan/../../../include -I/home/qth20/installed$
>> > jali-tpls-gcc_6.4.0-openmpi-2.1.2/include/UnitTest++ -I/usr/include/lapacke -I/home/qth20/installed/xmof2d-gcc_6.4.0-openmpi_2.1.2/include -I/projects/opt/centos7/cuda/9.0/include  --expt-relaxed-constexpr --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG   -x cu -c /home$
>> > qth20/develop/tangram/app/vfgen-cuda/vfgen-cuda.cu -o CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
>> > /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1708): warning: variable "nnodes" was declared but never referenced
>> >
>> > /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1993): warning: variable "ncells" was declared but never referenced
>> >
>> > /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(2070): warning: variable "ibndry" was declared but never referenced
>> >
>> > [ 80%] Linking CUDA device code CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
>> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda && /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/vfgen-cuda.dir/dlink.txt --verbose=1
>> > /projects/opt/centos7/cuda/9.0/bin/nvcc  --expt-relaxed-constexpr --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG  -Xcompiler=-fPIC -Wno-deprecated-gpu-targets -shared -dlink CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o -o CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
>> > [100%] Linking CUDA executable vfgen-cuda
>> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda && /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/vfgen-cuda.dir/link.txt --verbose=1
>> > /projects/opt/centos7/gcc/6.4.0/bin/g++   CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o CMakeFiles/vfgen-cuda.dir/cmake_device_link.o -o vfgen-cuda /projects/opt/centos7/cuda/9.0/lib64/libcudart_static.a -ldl /usr/lib64/librt.so  -L"/projects/opt/centos7/cuda/9.0/lib64/stubs"
>> >  -L"/projects/opt/centos7/cuda/9.0/lib64" -lcudadevrt -lcudart_static -lrt -lpthread -ldl
>> > ===============================================================================
>> >
>> > so apparently, mpicc is used other parts of the project, but when linking extension between object codes it snaps back to g++(!). I have already specified CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to be mpicc and mpic++, respectively. Inside the CMakeLists for this CUDA:
>> >
>> > ===============================================================================
>> > project(tangram LANGUAGES CXX CUDA)
>> > [...]
>> > if (CUDA_FOUND)
>> >    string(APPEND CMAKE_CUDA_FLAGS "--expt-relaxed-constexpr --std=c++11 ")
>> >    # Other CUDA flags
>> > endif(CUDA_FOUND)
>> >
>> > [... Inside CUDA app directory...]
>> > add_executable(vfgen-cuda vfgen-cuda.cu)
>> > target_link_libraries(vfgen-cuda ${EXTRA_LIBS} ${MPI_LIBRARIES})
>> > ===============================================================================
>> >
>> > Is something missed out?
>> >
>> > 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

From crestchristopher at gmail.com  Tue Jul 31 21:46:44 2018
From: crestchristopher at gmail.com (CrestChristopher)
Date: Tue, 31 Jul 2018 21:46:44 -0400
Subject: [CMake] Beginning to compiling CMake file
In-Reply-To: <1549AA90-9773-45C9-A5E1-650B8DE5D623@gmail.com>
References: <bd3f3de3-5da4-b2ec-3d31-2a5940741193@gmail.com>
 <1549AA90-9773-45C9-A5E1-650B8DE5D623@gmail.com>
Message-ID: <b192f4b9-42aa-7137-361c-cf1b95e6047f@gmail.com>

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