Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
On 3/19/19 11:57 AM, Rolf Eike Beer wrote: > It has nothing to do with either the policies or the order of > cmake_minimum_required() and project(). Okay. My order comment was a side note and should be corrected either way. > If I require version 3.0 it works, with 3.1 it fails. See this code in FindPkgConfig: https://gitlab.kitware.com/cmake/cmake/blob/v3.14.0/Modules/FindPkgConfig.cmake#L128-136 and the documentation note about CMAKE_MINIMUM_REQUIRED_VERSION: https://cmake.org/cmake/help/v3.14/module/FindPkgConfig.html#command:pkg_check_modules -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
Am Montag, 18. März 2019, 14:45:15 CET schrieb Brad King:
> On 3/15/19 6:10 PM, Rolf Eike Beer wrote:
> > I suspected it was a policy thing, so I tried this:
> >
> > foreach(_p RANGE 21 54)
> >
> >cmake_policy(SET CMP00${_p} OLD)
> >
> > endforeach()
>
> Only policies 51-54 were added between 3.0 and 3.1. I suggest
> testing with
>
> cmake_minimum_required(VERSION 3.0)
> cmake_policy(SET CMP0051 NEW)
> cmake_policy(SET CMP0052 NEW)
> cmake_policy(SET CMP0053 NEW)
> cmake_policy(SET CMP0054 NEW)
>
> and then trying different combinations. My guess is CMP0054.
It has nothing to do with either the policies or the order of
cmake_minimum_required() and project(). If I require version 3.0 it works,
with 3.1 it fails.
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
Am 2019-03-18 14:45, schrieb Brad King:
On 3/15/19 6:10 PM, Rolf Eike Beer wrote:
I suspected it was a policy thing, so I tried this:
foreach(_p RANGE 21 54)
cmake_policy(SET CMP00${_p} OLD)
endforeach()
Only policies 51-54 were added between 3.0 and 3.1.
The starting point was 2.8.11, I have not bothered to change the loop
afterwards.
I suggest
testing with
cmake_minimum_required(VERSION 3.0)
cmake_policy(SET CMP0051 NEW)
cmake_policy(SET CMP0052 NEW)
cmake_policy(SET CMP0053 NEW)
cmake_policy(SET CMP0054 NEW)
and then trying different combinations. My guess is CMP0054.
Good idea.
-
While looking at the source of that project, I noticed that
both `CMakeLists.txt` and `smtk-import/CMakeLists.txt` call
the `project()` command before `cmake_minimum_required()`.
The other order is preferred:
cmake_minimum_required(VERSION 2.8.11)
project(Subsurface)
because there are policies that affect project()'s behavior.
This order preference is documented by both commands.
This is not the case, I have changed that and it did not help.
I also noticed this code:
```
# don't process generated files - this is new in 3.10
if (POLICY CMP0071)
cmake_policy(SET CMP0071 OLD)
endif()
```
The cmake-policies(7) manual states that a policy should only
be set to OLD to silence warnings in frozen code bases or in
short-term circumstances.
The proper way to deal with CMP0071 is to set it to NEW
and set the `SKIP_AUTO*` properties on the sources that should
not be processed.
I'll look into this. The problem here is that this IIRC breaks with new
CMake and old Qt version where this would process generated files twice.
Eike
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
On 3/15/19 6:10 PM, Rolf Eike Beer wrote:
> I suspected it was a policy thing, so I tried this:
>
> foreach(_p RANGE 21 54)
>cmake_policy(SET CMP00${_p} OLD)
> endforeach()
Only policies 51-54 were added between 3.0 and 3.1. I suggest
testing with
cmake_minimum_required(VERSION 3.0)
cmake_policy(SET CMP0051 NEW)
cmake_policy(SET CMP0052 NEW)
cmake_policy(SET CMP0053 NEW)
cmake_policy(SET CMP0054 NEW)
and then trying different combinations. My guess is CMP0054.
-
While looking at the source of that project, I noticed that
both `CMakeLists.txt` and `smtk-import/CMakeLists.txt` call
the `project()` command before `cmake_minimum_required()`.
The other order is preferred:
cmake_minimum_required(VERSION 2.8.11)
project(Subsurface)
because there are policies that affect project()'s behavior.
This order preference is documented by both commands.
I also noticed this code:
```
# don't process generated files - this is new in 3.10
if (POLICY CMP0071)
cmake_policy(SET CMP0071 OLD)
endif()
```
The cmake-policies(7) manual states that a policy should only
be set to OLD to silence warnings in frozen code bases or in
short-term circumstances.
The proper way to deal with CMP0071 is to set it to NEW
and set the `SKIP_AUTO*` properties on the sources that should
not be processed.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
> I'm trying to figure out what's actually going wrong here. At this stage in > the log you have have already built the Subsurface installer and > smtk_import... so what is it trying to build there? It's running packaging/windows/smtk2ssrf-mxe-build.sh to build smtk-import/ CMakeLists.txt. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
On 2019-03-15 23:10+0100 Rolf Eike Beer wrote:
Out of boredom I'm hacking a bit around in the build system of Subsurface
(https://github.com/Subsurface-divelog/subsurface). One of the things I'm
looking to is requiring a newer CMake version. And now something strange
happens:
The original code:
cmake_minimum_required(VERSION 2.8.11)
This still works:
cmake_minimum_required(VERSION 3.0)
like this:
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Checking for module 'libxml-2.0'
-- Found libxml-2.0, version 2.9.4
-- Checking for module 'sqlite3'
-- Found sqlite3, version 3.20.1
-- Checking for module 'libxslt'
-- Found libxslt, version 1.1.29
-- Checking for module 'libzip'
-- Found libzip, version 1.1.3
And this breaks:
cmake_minimum_required(VERSION 3.1)
like this:
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Checking for module 'libxml-2.0'
-- Found libxml-2.0, version 2.9.1
-- Checking for module 'sqlite3'
-- Found sqlite3, version 3.8.2
-- Checking for module 'libxslt'
-- Found libxslt, version 1.1.28
-- Checking for module 'libzip'
-- No package 'libzip' found
I suspected it was a policy thing, so I tried this:
foreach(_p RANGE 21 54)
cmake_policy(SET CMP00${_p} OLD)
endforeach()
Does not change anything.
Build logs can be found here for 3.0:
https://api.travis-ci.org/v3/job/506938155/log.txt
And for 3.1:
https://api.travis-ci.org/v3/job/506849909/log.txt
It's a CMake 3.8.2 actually, which can be found in the mxe tarballs (look in
the logs, IIRC it's the first one).
Has anyone an idea what's happening there? And even more important: how to get
it fixed? The maximum version the requirement can be raised to is 3.5.1 for
the moment because of the supported Ubuntu versions (16.04+).
Hi Eike:
Since you appear to be running 3.8.2 in both cases, then the default
policy change difference between cmake_minimum_required(VERSION 3.0)
and cmake_minimum_required(VERSION 3.1) should be the only difference
between the two results. So you appear to be left with (i)
cmake_minimum_required is not implemented as documented (i.e., there
is more going on then just a policy change for CMake 3.8.2), (ii)
there is some typo in how you changed policies for
cmake_minimum_required(VERSION 3.1) to be effectively the same as the
default policies for cmake_minimum_required(VERSION 3.0), or (iii)
there is absolutely no explanation for what you have found. :-)
However, if it were me I would simply forget about getting to the
bottom of this mystery for cmake_minimum_required(VERSION 3.1) since
that is a really an old set of policies. Instead, I suggest you move
on to the more modern set of policies associated with
cmake_minimum_required(VERSION 3.5.1) to see whether you have the same
trouble in that case for a range of CMake versions (including 3.8.2,
just in case there is a specific bug in that version) from 3.5.1 to
the latest version.
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-developers
