Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Craig Scott]

On Wed, Jan 4, 2017 at 11:43 AM, Stephen Kelly  wrote:

> René J.V. Bertin wrote:
>
> > The
> > issue was a project that requested an earlier CMake version
> > (2.8.something) further down.
>
> There should be no 'further down'. There should be exactly one use of
> cmake_minimum_required per buildsystem. If you are hitting this issue
> because you are cloning random repos and using add_subdirectory, you're
> essentially getting undefined behavior, unless the target repo is designed
> to let you do that.
>
> That is - some buildsystems check whether they are top-level and only then
> invoke cmake_minimum_required. Something like:
>
>  if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
># Building standalone
>cmake_minimum_required(VERSION 3.3)
>project(Dependency)
>  endif()
>
>  add_executable(etc)
>
>
>
> if you use add_subdirectory with top-level projects which don't explicitly
> do something like that, you're getting undefined , and generally unexpected
> behavior in many ways.
>

This seems at odds with the CMake documentation for
cmake_minimum_required(). That documentation talks about calling
cmake_minimum_required() within a function as a valid case, which is
obviously not going to be at the start of a top level CMakeLists.txt file.
I see no reason why having multiple calls to cmake_minimum_required()
shouldn't work. Yes, each one will alter the policy behaviour for that
scope and below, but assuming that's what the project wanted to enforce,
this should be fine.

We have many projects which do exactly the scenario you mention above where
a project can be built standalone or added to another project via
add_subdirectory(). We have not found it necessary to test if a project is
top level or not before calling cmake_minimum_required(). The behaviour is
well-defined and performs as per the documentation in regard to policies
and minimum CMake versions as far as we've observed. Can you point me/us at
documentation or code which shows why this should be considered undefined
behaviour? I'm particularly interested in this case since we use it
frequently in production.

Also, in case it is of interest, in a hierarchical project arrangement
where another project is brought in via add_subdirectory, the
CMAKE_POLICY_DEFAULT_CMP

variable
can be used to alter the default for a policy so that if that sub-project
specifies an older version in its cmake_minimum_required(), the
driving/main project can still influence its behaviour without requiring
changes to that sub-project. Not ideal, but I've had at least one
legitimate case where this was useful (dealing with warnings associated
with CMP0048 ).


-- 
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Stephen Kelly]

René J.V. Bertin wrote:

> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
> 
>> It is the responsibility of the project to understand what components
>> of CMake they require, and correctly specify a cmake_minimum required
>> that satisfies all those requirements. In this case to use compile
>> features you need a minimum of 3.0 which also automatically enables
>> policy 25.
> 
> I agree with you in a way, but in reality it would be up to end users and
> packagers to feed back that information to an unknown number of projects
> and convince them why it's necessary to comply with the request. That's
> just not doable. It would be a lot easier if the policy could be set at a
> central location, in this case in the Qt module invoking the test that
> fails.
> 
> 
> And it's CMake's responsibility to generate useful error messages, and
> where possible provide a hint for the fix.

Usually CMake does. CMP0025 is a bit unique (perhaps to a fault) in that it 
does not. Look at its docs.

Thanks,

Steve.
 

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Stephen Kelly]

René J.V. Bertin wrote:

> The
> issue was a project that requested an earlier CMake version
> (2.8.something) further down. 

There should be no 'further down'. There should be exactly one use of 
cmake_minimum_required per buildsystem. If you are hitting this issue 
because you are cloning random repos and using add_subdirectory, you're 
essentially getting undefined behavior, unless the target repo is designed 
to let you do that. 

That is - some buildsystems check whether they are top-level and only then 
invoke cmake_minimum_required. Something like:

 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
   # Building standalone
   cmake_minimum_required(VERSION 3.3)
   project(Dependency)
 endif()

 add_executable(etc)



if you use add_subdirectory with top-level projects which don't explicitly 
do something like that, you're getting undefined , and generally unexpected 
behavior in many ways.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 03 2017 15:23:45 Robert Maynard wrote:

> Basically my recommendation is if a project isn't setting
> cmake_minimum_required before the first project call than nothing you
> can do will fix that, as it is an error.

The issue here is not that the minimum version was NOT being set. Apparently 
that isn't an issue if I set CMP0025 from the commandline. The issue was a 
project that requested an earlier CMake version (2.8.something) further down. 
Apparently that undoes the explicit CMP0025 setting, but not if I execute a 
cmake_minimum_required(3.0) first.

Either way, I'm getting signals from others using the build system this is 
about (MacPorts) to please not force a minimum required CMake version, and 
calling `cmake_minimum_required` in an initial cache file does not have the 
expected effect.

R.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Robert Maynard]

Any project that isn't setting cmake_minimum_required before calling
project is invoking deprecated behavior of CMake, and is ignoring
Policy CMP (
https://cmake.org/cmake/help/v3.4/policy/CMP.html#policy:CMP
).

Basically my recommendation is if a project isn't setting
cmake_minimum_required before the first project call than nothing you
can do will fix that, as it is an error.

On Tue, Jan 3, 2017 at 2:49 PM, René J.V. Bertin  wrote:
> On Tuesday January 03 2017 14:27:40 Robert Maynard wrote:
>
> Well, that has to be set in every project, or else we'd have to write an 
> initial cache file to be loaded with -C ...
>
> Weird, btw: I just ran into a project that apparently wasn't satisfied with 
> setting only CMP0025 on the commandline. It did set the minimum required 
> version to 2.8.x but that was well after the project() definition, and it 
> seems to be behind the scenes of that call that the compiler features are 
> tested (judging from message(STATUS "here") probes).
>
> Do you know what's happening there, and have any brilliant thoughts how we 
> can prevent this without have to scan each project?
>
>> Sorry I wasn't clear. I mean the cmake_minimum_required command (
>> https://cmake.org/cmake/help/v3.0/command/cmake_minimum_required.html
>> )
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Robert Maynard]

Sorry I wasn't clear. I mean the cmake_minimum_required command (
https://cmake.org/cmake/help/v3.0/command/cmake_minimum_required.html
)

On Tue, Jan 3, 2017 at 2:26 PM, René J.V. Bertin 
wrote:

> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
>
> > You can explicitly do both of those things currently see:
> > https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html
>
> Are you sure about the minimum required version? I cannot seem to have any
> luck with `-DCMAKE_MINIMUM_REQUIRED_VERSION=3.0`.
>
> R.
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:

> You can explicitly do both of those things currently see:
> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

Are you sure about the minimum required version? I cannot seem to have any luck 
with `-DCMAKE_MINIMUM_REQUIRED_VERSION=3.0`.

R.

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Robert Maynard]

I doubt the change to cmPolicies.h would do as you expect, as the
logic to set a policy to a given state ( OLD,WARN,NEW ) is actually
done by cmPolicies::ApplyPolicyVersion.

Now as far as how Qt5 is operating, personally I agree it would be
nice that the module would provide better warnings or errors, instead
they have just documented these issues on their cmake page:
http://doc.qt.io/qt-5/cmake-manual.html

On Tue, Jan 3, 2017 at 12:12 PM, René J.V. Bertin  wrote:
> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
>
>> It is the responsibility of the project to understand what components
>> of CMake they require, and correctly specify a cmake_minimum required
>> that satisfies all those requirements. In this case to use compile
>> features you need a minimum of 3.0 which also automatically enables
>> policy 25.
>
> I agree with you in a way, but in reality it would be up to end users and 
> packagers to feed back that information to an unknown number of projects and 
> convince them why it's necessary to comply with the request. That's just not 
> doable.
> It would be a lot easier if the policy could be set at a central location, in 
> this case in the Qt module invoking the test that fails.
>
>
> And it's CMake's responsibility to generate useful error messages, and where 
> possible provide a hint for the fix.
>
>> You can explicitly do both of those things currently see:
>> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html
>
> Ah, thanks. I take it one can also change a line in cmPolicies.h:
>
>   SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.",   
> \
>  3, 0, 0, cmPolicies::NEW)   \
>
> ?
>
> R.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Creating a Keil uVision generator

[Paul Wilkinson]

Hi all,

I am involved in a software project targeting a handful of ARM Cortex-M
microcontrollers. We develop the software using the Keil uVision v5 IDE [1]. We
are considering whether CMake could help us with some of the limitations we
encounter using uVision alone.

Does anyone have experience or insight in to creating a CMake generator for an
embedded systems IDE like uVision?

Read on for some technical details.

A uVision project's structure appears _roughly_ similar to a Microsoft Visual
Studio 12 project. uVision has a Multi-Project Workspace (.uvmpw) rather than a
VS solution (.sln), and a uVision Project (.uvprojx) instead of a VS project
(.vcxproj).

One notable difference in the XML schemas: in uVision, the source file elements
are a child of the target elements (a uVision "target" is comparable to a VS
"configuration"), in contrast to VS's approach where a configuration-specific
option is a child of the source file element and has a "Condition" attribute.

As with the Visual Studio generators, a generator for uVision projects would
ideally be a multi-configuration generator.

I expect there are many concepts in CMake that wouldn't map to a uVision option,
and vice-versa. For example the "Packs" system used by uVision might not mesh
well with what CMake understands as a library. For my limited requirements -- a
single project workspace, where the project consists of exactly one executable
and no libraries other than some third-party libraries passed to linker -- I
expect we could make do with a skeleton/template .uvprojx and the CMake
generator would fill in the gaps for the source files.

Some of the benefits I would imagine we would get from such a generator:

- more human-friendly and diff-friendly project files (CMakeLists.txt instead
  of .uvprojx)

- avoiding a combinatorial explosion of configurations by using the CMake
  language and its cache variables.

[1] http://www2.keil.com/mdk5/uvision/

Thanks,
Paul Wilkinson
http://www.cmedrobotics.com/


This e-mail message is confidential and for use by the addressee only. If you 
are not the intended recipient, you must not use, disclose, copy or forward 
this transmission. Please return the message to the sender by replying to it 
and then delete the message from your computer. Cambridge Medical Robotics 
shall not be held liable to any person resulting from the use of any 
information contained in this e-mail and shall not be liable to any person who 
acts or omits to do anything in reliance upon it. Cambridge Medical Robotics 
does not accept responsibility for changes made to this message after it was 
sent.

Company Information:
Name: Cambridge Medical Robotics Limited.
Registered Address: Unit 2, Crome Lea Business Park, Madingley Road, Cambridge, 
CB23 7PH, UK.
Registered as a Company in England: 08863657 VAT Number: GB 186 4383 74.
i...@cmedrobotics.com
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:

> It is the responsibility of the project to understand what components
> of CMake they require, and correctly specify a cmake_minimum required
> that satisfies all those requirements. In this case to use compile
> features you need a minimum of 3.0 which also automatically enables
> policy 25.

I agree with you in a way, but in reality it would be up to end users and 
packagers to feed back that information to an unknown number of projects and 
convince them why it's necessary to comply with the request. That's just not 
doable.
It would be a lot easier if the policy could be set at a central location, in 
this case in the Qt module invoking the test that fails.


And it's CMake's responsibility to generate useful error messages, and where 
possible provide a hint for the fix.

> You can explicitly do both of those things currently see:
> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

Ah, thanks. I take it one can also change a line in cmPolicies.h:

  SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.",   \
 3, 0, 0, cmPolicies::NEW)   \

?

R.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Robert Maynard]

On Tue, Jan 3, 2017 at 11:29 AM, René J.V. Bertin  wrote:
> On Tuesday January 03 2017 10:36:54 Robert Maynard wrote:
>
> That's all nice and well but a bit delicate to expect from an unknown number 
> of project to adapt their minimum required CMake version for a policy they 
> probably don't even know they require.
>
>
>> The minimum cmake version of each project controls the default state
>> of the policies. So for policy 25 you need a minimum of CMake 3.0.
>> This is partially a moot point, because compiler feature detection was
>> added in CMake 3.0, so if you are expecting that feature to exist you
>> should be requiring CMake 3.0.
>
> Maybe, indeed, but that becomes a much less trivial point if the policy 
> becomes necessary somewhere hidden deep in a module that's loaded somewhere 
> well into running cmake. How is the user supposed to understand what happens 
> from the error message?

It is the responsibility of the project to understand what components
of CMake they require, and correctly specify a cmake_minimum required
that satisfies all those requirements. In this case to use compile
features you need a minimum of 3.0 which also automatically enables
policy 25.

>
> The point would be moot if the minimum required cmake version could be 
> adjusted whenever necessary, or policy 25 could be set when required.

You can explicitly do both of those things currently see:
https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

> Or indeed if a cmake installation can be configured locally to set a policy, 
> or to apply a limit to how far back the minimum required version can be set.
>
> R.
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Robert Maynard]

The minimum cmake version of each project controls the default state
of the policies. So for policy 25 you need a minimum of CMake 3.0.

This is partially a moot point, because compiler feature detection was
added in CMake 3.0, so if you are expecting that feature to exist you
should be requiring CMake 3.0.

On Tue, Jan 3, 2017 at 10:26 AM, René J.V. Bertin  wrote:
> On Tuesday January 3 2017 10:02:44 Robert Maynard wrote:
>
> Hi,
>
> Thanks for the sample CMake file!
>
> It appears indeed that the policy defaulting to OLD is the culprit here: 
> setting it to NEW at an appropriate location (and throwing out 
> build.dir/CMake*) makes detection work properly. Surprised me a bit TBH; a 
> casual read (and unburdened with prior knowledge) of the CMP0025 doc seems to 
> suggest that the opposite would happen.
>
> That almost begs the question what you're waiting for to make the new setting 
> the default. :)
> Maybe there's a way to toggle it locally, so that it doesn't have to be set 
> in every project that may need to be built with a non-Apple clang version?
>
> Cheers,
> René Bertin
>
>>The problem that was reported in that other thread was due to having
>>policy CMP0025 set to a false value, once that policy was enabled
>>compiler detection worked properly.
>>
>>I would make sure the same isn't happening for you.
>>
>>I have attached a simple CMakeList.txt file you can use to determine
>>if potentially you are seeing the same policy issue.
>>
>>
>>
>>On Tue, Jan 3, 2017 at 9:21 AM, René J.V. Bertin  wrote:
>>> Hi,
>>>
>>> I just had a run-in with a CMake file from Qt5 in a project I've been 
>>> building with a locally built Clang 3.9 version, affectionately called 
>>> clang-mp-3.9 . I got the cryptic message
>>>
>>>  CMake Error in src/platformtheme/CMakeLists.txt:
>>>No known features for CXX compiler
>>>
>>>"Clang"
>>>
>>>version 3.9.0.
>>>
>>>
>>> Would you consider adding support for non-Apple clang versions on Mac too, 
>>> and who would best request that, a Qt dev who considers the cxx_decltype 
>>> test crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>>>
>>> I see this has already come up for HB:
>>> https://cmake.org/pipermail/cmake/2016-December/064719.html
>>>
>>>
>>> Thanks,
>>> René Bertin
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: 
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more 
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at 
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 3 2017 10:02:44 Robert Maynard wrote:

Hi,

Thanks for the sample CMake file!

It appears indeed that the policy defaulting to OLD is the culprit here: 
setting it to NEW at an appropriate location (and throwing out 
build.dir/CMake*) makes detection work properly. Surprised me a bit TBH; a 
casual read (and unburdened with prior knowledge) of the CMP0025 doc seems to 
suggest that the opposite would happen.

That almost begs the question what you're waiting for to make the new setting 
the default. :)
Maybe there's a way to toggle it locally, so that it doesn't have to be set in 
every project that may need to be built with a non-Apple clang version?

Cheers,
René Bertin

>The problem that was reported in that other thread was due to having
>policy CMP0025 set to a false value, once that policy was enabled
>compiler detection worked properly.
>
>I would make sure the same isn't happening for you.
>
>I have attached a simple CMakeList.txt file you can use to determine
>if potentially you are seeing the same policy issue.
>
>
>
>On Tue, Jan 3, 2017 at 9:21 AM, René J.V. Bertin  wrote:
>> Hi,
>>
>> I just had a run-in with a CMake file from Qt5 in a project I've been 
>> building with a locally built Clang 3.9 version, affectionately called 
>> clang-mp-3.9 . I got the cryptic message
>>
>>  CMake Error in src/platformtheme/CMakeLists.txt:
>>No known features for CXX compiler
>>
>>"Clang"
>>
>>version 3.9.0.
>>
>>
>> Would you consider adding support for non-Apple clang versions on Mac too, 
>> and who would best request that, a Qt dev who considers the cxx_decltype 
>> test crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>>
>> I see this has already come up for HB:
>> https://cmake.org/pipermail/cmake/2016-December/064719.html
>>
>>
>> Thanks,
>> René Bertin
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Robert Maynard]

The problem that was reported in that other thread was due to having
policy CMP0025 set to a false value, once that policy was enabled
compiler detection worked properly.

I would make sure the same isn't happening for you.

I have attached a simple CMakeList.txt file you can use to determine
if potentially you are seeing the same policy issue.



On Tue, Jan 3, 2017 at 9:21 AM, René J.V. Bertin  wrote:
> Hi,
>
> I just had a run-in with a CMake file from Qt5 in a project I've been 
> building with a locally built Clang 3.9 version, affectionately called 
> clang-mp-3.9 . I got the cryptic message
>
>  CMake Error in src/platformtheme/CMakeLists.txt:
>No known features for CXX compiler
>
>"Clang"
>
>version 3.9.0.
>
>
> Would you consider adding support for non-Apple clang versions on Mac too, 
> and who would best request that, a Qt dev who considers the cxx_decltype test 
> crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>
> I see this has already come up for HB:
> https://cmake.org/pipermail/cmake/2016-December/064719.html
>
>
> Thanks,
> René Bertin
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR)
cmake_policy(SET CMP0025 NEW)

project(t C CXX)

cmake_policy(GET CMP0025 appleClangPolicy)
if(NOT appleClangPolicy STREQUAL NEW)
  message(STATUS "cmake_determine_compile_features was not enabled as policy 
0025 needs to be set to NEW")
endif()

message(STATUS "CMAKE_CXX_COMPILE_FEATURES: ${CMAKE_CXX_COMPILE_FEATURES}")
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

Hi,

I just had a run-in with a CMake file from Qt5 in a project I've been building 
with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I 
got the cryptic message

 CMake Error in src/platformtheme/CMakeLists.txt:
   No known features for CXX compiler

   "Clang"

   version 3.9.0.


Would you consider adding support for non-Apple clang versions on Mac too, and 
who would best request that, a Qt dev who considers the cxx_decltype test 
crucial, or the 1st user for whom that breaks his builds (i.e. me)?

I see this has already come up for HB:
https://cmake.org/pipermail/cmake/2016-December/064719.html


Thanks,
René Bertin
-- 

Powered by www.kitware.com

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

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

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

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

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