On Fri, Jan 6, 2017 at 11:57 AM, Stephen Kelly wrote:
> Craig Scott wrote:
>
> >> 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
Craig Scott wrote:
>> 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 docume
On Wed, Jan 04, 2017 at 12:12:46 +1100, Craig Scott wrote:
> 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 no
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 builds
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 com
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
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
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_re
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
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
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_VE
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 err
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 minim
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
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 c
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 C
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
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 po
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"
versi
19 matches
Mail list logo
