Re: [CMake] find_path / find_package hardcoded path

[Rolf Eike Beer]

Am 2019-08-28 12:28, schrieb Ran Regev:

I think you can also add "PATHS" or "HINTS" to find_package.


Yes, but this has a different purpose. It's idea is to provide places to 
look at based on other things already found, things that would work 
independent of the machine.


The plan here is to provide information about the local directories, and 
those should not end up in CMakeLists.txt as they are totally 
meaningless when switching to a different machine.


One could use an initial cache file for this if this has to be done over 
and over again on the same machine, or add a shell alias (or a shell 
alias to the cache file, which is more flexible).


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

Re: [CMake] find_path / find_package hardcoded path

[Rolf Eike Beer]

Am 2019-08-28 11:39, schrieb Stéphane Ancelot:

Hi,

using mingw32 with win10 , I can not manage to find jpeg libs .

I tried setting JPEG_DIR, it fails.

it also fails setting CMAKE_FIND_ROOT_PATH

set(JPEG_DIR c:\\work\\WIN32DEPS\\jpegfolder)


Use forward slashes. Don't do it in the CMakeLists.txt as it is 
something happening only on your system, so pass it on the command line, 
e.g. as


 cmake -D CMAKE_PREFIX_PATH=c:/work/win32deps/jpegfolder

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

Re: [cmake-developers] CPackComponentsDEB-components-depend2 test fails

[Rolf Eike Beer]

Am 2019-07-05 11:04, schrieb Raffi Enficiaud:

On 04.07.19 23:55, Rolf Eike Beer wrote:

Am Donnerstag, 4. Juli 2019, 23:33:22 CEST schrieb Rolf Eike Beer:

Raffi Enficiaud wrote:

[...]
is not creating a shared library by default on this distribution or 
is

interacting with other options you may have passed?
What if you explicitly write those lines like this:

add_library(mylib SHARED mylib.cpp)


I have looked into the library deb file: in case it is a static 
library it
contains /usr/lib64/libmylib.a, in case of a shared library it only 
contains

an empty /usr.



Thanks for the feedback. What if now you replace "ARCHIVE" by "LIBRARY"
in the same file, in the following command?

install(TARGETS mylib
  ARCHIVE
  DESTINATION ${CMAKE_INSTALL_LIBDIR}
  COMPONENT libraries)


It does show up in the lib.deb, but the test still fails:

152: -- CPack_error=CPackDeb: - Generating dependency list
152:
152: -- package='mylib-applications', dependencies=''
152: -- package='mylib-headers', dependencies='mylib-libraries (= 
1.0.2), depend-headers'

152: -- package='mylib-libraries', dependencies='depend-default'
152: CMake Error at 
/home/ebeer/repos/upstream/CMake/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend2.cmake:93 
(message):

152:   dpkg-deb checks failed:
152:
152:   ;dpkg-deb:
152:   
/home/ebeer/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-components-depend2/mylib-applications_1.0.2_amd64.deb:
152:   Incorrect dependencies for package mylib-applications: '' does 
not contain

152:   any 'lib'

--
--

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] CPackComponentsDEB-components-depend2 test fails

[Rolf Eike Beer]

Am Donnerstag, 4. Juli 2019, 23:33:22 CEST schrieb Rolf Eike Beer:
> Raffi Enficiaud wrote:
> > On 04.07.19 12:59, Rolf Eike Beer wrote:
> > > I have a Gentoo and an openSUSE system, that both have various dpkg*
> > > tools
> > > installed for $reasons.
> > > 
> > > I know that I need to disable the CPackDEB tests, they create a dynamic
> > > executable and check the deb afterwards. Since this is no Debian like
> > > system the libc this links to is not covered by any dep.
> > 
> > Hi,
> > 
> > I wrote those tests quite some time ago. They are basically checking if
> > CPackDEB is handling the options that were passed to it properly.
> > 
> > > When running the CPackComponentsDEB-components-depend2 test I get this
> > > output: [...]
> > > 
> > > Is this the same reason and I should just filter this test out (in
> > > contrast to the other CPackComponentsDEB tests, which work fine), do we
> > > need some sort of automatic detection, or what?
> > 
> > This failure indicates that:
> > 
> > - the default CPACK_DEBIAN_PACKAGE_SHLIBDEPS is on: it activates the
> > automatic detection of the dependencies with shlibdeps. This is a Debian
> > tool.
> > - for all components but the application one, the shlibdeps is disabled
> > - the application component should inherit from the default one
> > - since the application points to the shared library, then it should
> > have this dependency while it does not according to shlibdeps.
> > 
> > Here the test assumes that there is a shared library the application
> > component links to.
> > 
> > I do not know much about Gentoo. Maybe the line
> > 
> > -- Tests/CPackComponentsDEB/CMakeLists.txt:13
> > 
> > # Create the mylib library
> > add_library(mylib mylib.cpp)
> > 
> > ---
> > 
> > is not creating a shared library by default on this distribution or is
> > interacting with other options you may have passed?
> > What if you explicitly write those lines like this:
> > 
> > add_library(mylib SHARED mylib.cpp)

I have looked into the library deb file: in case it is a static library it 
contains /usr/lib64/libmylib.a, in case of a shared library it only contains 
an empty /usr.

Greetings,

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] CPackComponentsDEB-components-depend2 test fails

[Rolf Eike Beer]

Raffi Enficiaud wrote:
> On 04.07.19 12:59, Rolf Eike Beer wrote:
> > I have a Gentoo and an openSUSE system, that both have various dpkg* tools
> > installed for $reasons.
> > 
> > I know that I need to disable the CPackDEB tests, they create a dynamic
> > executable and check the deb afterwards. Since this is no Debian like
> > system the libc this links to is not covered by any dep.
> 
> Hi,
> 
> I wrote those tests quite some time ago. They are basically checking if
> CPackDEB is handling the options that were passed to it properly.
> 
> > When running the CPackComponentsDEB-components-depend2 test I get this
> > output: [...]
> > 
> > Is this the same reason and I should just filter this test out (in
> > contrast to the other CPackComponentsDEB tests, which work fine), do we
> > need some sort of automatic detection, or what?
> 
> This failure indicates that:
> 
> - the default CPACK_DEBIAN_PACKAGE_SHLIBDEPS is on: it activates the
> automatic detection of the dependencies with shlibdeps. This is a Debian
> tool.
> - for all components but the application one, the shlibdeps is disabled
> - the application component should inherit from the default one
> - since the application points to the shared library, then it should
> have this dependency while it does not according to shlibdeps.
> 
> Here the test assumes that there is a shared library the application
> component links to.
> 
> I do not know much about Gentoo. Maybe the line
> 
> -- Tests/CPackComponentsDEB/CMakeLists.txt:13
> 
> # Create the mylib library
> add_library(mylib mylib.cpp)
> 
> ---
> 
> is not creating a shared library by default on this distribution or is
> interacting with other options you may have passed?
> What if you explicitly write those lines like this:
> 
> add_library(mylib SHARED mylib.cpp)

Here is the output on my openSUSE system:

eike@daneel:~/repos/build/CMake$  ctest -V -R CPackComponentsDEB-components-
depend2
UpdateCTestConfiguration  from :/home/eike/repos/build/CMake/
DartConfiguration.tcl
Parse Config file:/home/eike/repos/build/CMake/DartConfiguration.tcl
 Add coverage exclude regular expressions.
 Add coverage exclude: XCode
 Add coverage exclude: /Source/(cm|kw)sys/
 Add coverage exclude: /CMakeFiles/CMakeTmp/
 Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src
SetCTestConfiguration:CMakeCommand:/usr/bin/cmake
UpdateCTestConfiguration  from :/home/eike/repos/build/CMake/
DartConfiguration.tcl
Parse Config file:/home/eike/repos/build/CMake/DartConfiguration.tcl
Test project /home/eike/repos/build/CMake
Constructing a list of tests
Guessing configuration NoConfig
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 152
Start 152: CPackComponentsDEB-components-depend2

152: Test command: /home/eike/repos/build/CMake/bin/ctest "-C" "NoConfig" "--
build-and-test" "/home/eike/repos/CMake/Tests/CPackComponentsDEB" "/home/eike/
repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-components-depend2" "--
build-generator" "Unix Makefiles" "--build-project" "CPackComponentsDEB" "--
build-options" "-DCMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/gmake" "-
DCPACK_GENERATOR:STRING=DEB" "-DCPACK_BINARY_DEB:BOOL=ON" "-
DCPackDEBConfiguration=components-depend2" "--graphviz=CPackComponentsDEB.dot" 
"--test-command" "/home/eike/repos/build/CMake/bin/cmake" "-
DCPackComponentsDEB_SOURCE_DIR:PATH=/home/eike/repos/CMake/Tests/
CPackComponentsDEB" "-DCPackComponentsDEB_BINARY_DIR:PATH=/home/eike/repos/
build/CMake/Tests/CPackComponentsDEB/buildDEB-components-depend2" "-
DCPackGen=DEB" "-DCPackDEBConfiguration=components-depend2" "-P" "/home/eike/
repos/CMake/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-
depend2.cmake"
152: Test timeout computed to be: 1500
152: Generate graphviz: /home/eike/repos/build/CMake/Tests/CPackComponentsDEB/
buildDEB-components-depend2/CPackComponentsDEB.dot
152: Writing /home/eike/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-
components-depend2/CPackComponentsDEB.dot.mylib...
152: Writing /home/eike/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-
components-depend2/CPackComponentsDEB.dot.mylibapp...
152: Writing /home/eike/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-
components-depend2/CPackComponentsDEB.dot.mylibapp2...
152: Writing /home/eike/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-
components-depend2/CPackComponentsDEB.dot.mylib.dependers...
152: Writing /home/eike/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-
c

[cmake-developers] CPackComponentsDEB-components-depend2 test fails

[Rolf Eike Beer]

I have a Gentoo and an openSUSE system, that both have various dpkg* tools 
installed for $reasons.

I know that I need to disable the CPackDEB tests, they create a dynamic 
executable and check the deb afterwards. Since this is no Debian like system 
the libc this links to is not covered by any dep.

When running the CPackComponentsDEB-components-depend2 test I get this output:

152: CPack Verbose: Install configuration: "NoConfig"
152: CPack Verbose: Installing: /home/ebeer/repos/build/CMake/Tests/
CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB/
MyLib-1.0.2-Linux/headers/usr/include/mylib.h
152: CPack: Create package
152: CPack Verbose: Package files to: /home/ebeer/repos/build/CMake/Tests/
CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB/
MyLib-1.0.2-Linux.deb
152: -- CPACK_DEBIAN_PACKAGE_DEPENDS not set, the package will have no 
dependencies.
152: CPack Verbose: Copying final package(s) [3]:
152: CPack: - package: /home/ebeer/repos/build/CMake/Tests/CPackComponentsDEB/
buildDEB-components-depend2/mylib-applications_1.0.2_amd64.deb generated.
152: CPack: - package: /home/ebeer/repos/build/CMake/Tests/CPackComponentsDEB/
buildDEB-components-depend2/mylib-headers_1.0.2_amd64.deb generated.
152: CPack: - package: /home/ebeer/repos/build/CMake/Tests/CPackComponentsDEB/
buildDEB-components-depend2/mylib-libraries_1.0.2_amd64.deb generated.
152: 
152: -- CPack_error=CPackDeb: - Generating dependency list
152: 
152: -- package='mylib-applications', dependencies=''
152: -- package='mylib-headers', dependencies='mylib-libraries (= 1.0.2), 
depend-headers'
152: -- package='mylib-libraries', dependencies='depend-default'
152: CMake Error at /home/ebeer/repos/upstream/CMake/Tests/CPackComponentsDEB/
RunCPackVerifyResult-components-depend2.cmake:93 (message):
152:   dpkg-deb checks failed:
152: 
152:   ;dpkg-deb:
152:   /home/ebeer/repos/build/CMake/Tests/CPackComponentsDEB/buildDEB-
components-depend2/mylib-applications_1.0.2_amd64.deb:
152:   Incorrect dependencies for package mylib-applications: '' does not 
contain
152:   any 'lib'

Is this the same reason and I should just filter this test out (in contrast to 
the other CPackComponentsDEB tests, which work fine), do we need some sort 
of automatic detection, or what?

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] String CONCAT issue

[Rolf Eike Beer]

Am 2019-06-28 08:52, schrieb vinay kumar Kotegowder:

Hello,

The snippet:
set(SUITE_DIR /home/../abc)

list(APPEND TEST_LSIT
 test_a001)


Since there is a type here I bet this is not the original code that you 
have run.



foreach(test ${TEST_LIST})
message(${test})


Please prefix the calls to message() with something so it is obvious 
which call is producing which output.



string(CONCAT TEST_CMAKE "${SUITE_DIR}/" "${test}/test.cmake")
message(${TEST_CMAKE})
endforeach()

Output:
test_a001

/home/.../abc/test_a001
/test.cmake


Which CMake version is this about?
--
--

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

Re: [cmake-developers] Ubuntu CMake Repository Now Available

[Rolf Eike Beer]

Am Freitag, 5. April 2019, 21:16:52 CEST schrieb Kyle Edwards via cmake-
developers:
> All,
> 
> I am pleased to announce that Kitware is now offering an
> officially-supported set of Ubuntu packages for CMake. These CMake
> packages can be installed with apt-get, just like other Ubuntu
> packages. We currently support Ubuntu 16.04 and 18.04.

Nice!

The magic spell for TravisCI is:

addons:
  apt:
sources:
  - sourceline: 'deb https://apt.kitware.com/ubuntu/ xenial main'
key_url: 'https://apt.kitware.com/keys/kitware-archive-2019.asc'
packages:
  - cmake

Or "trusty" if you still use the default distro.

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

[Rolf Eike Beer]

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

[Rolf Eike Beer]

> 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

[cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1

[Rolf Eike Beer]

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+).

Greetings,

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

[cmake-developers] Slowdown of nightly builds

[Rolf Eike Beer]

I noticed that for a few weeks the builds on my machines now take much longer 
to complete, without any particular change in my setup. This affects 2 
different machines, which makes me even more think it's a change in the test 
suite.

Is that something that is expected or is just someone using bootstrapping as a 
testbed for ExternalProject_Add with 5 runs in parallel? I don't mind if it's 
something really needed, but if it is just burning cycles than I would like to 
cut that down to the level before.

Today my gcc7 build took 45 minutes test time while it took only 28 minutes 
before. The change in the dashboard can be seen on the dashboard between 
2018-11-09 and 2018-11-10. There was no update in the system CMake version on 
that day either.

Any ideas? By the way: >3 minutes of configure time for CMake looks also quite 
excessive to me, but that has been the way before, too.

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] [CMake] dependencies of cross compiliations

[Rolf Eike Beer]

Eric Noulard wrote:

When ones do cross compile for the host + one or several target a 
lighter

"add_superbuild" API could be design. I'll try to think about it more
thoroughly and do some proposal. Ideally we shouldn't need to provide 
many

parameters beside the toolchain and a way to specify "the host build".


I guess putting the host-build location in the toolchain file could be 
one way
to just get it done. In case one has multiple builds that should share 
one host
build then just set an absolute location, and if you don't it will be 
below your

normal build directory.

There are just 2 things that scare me a bit off: we surely want a way to 
break
that into smaller pieces so we can introduce it over multiple releases, 
maybe even
as a tech-preview so we can break things if we see that we have not 
taken a bigger
usecase in account, and I currently don't see the points to slice that 
up.


And we really, really want a 
.cmake_no_freaking_in_source_build_under_any_circumstances
or however we gonna call it, and we need that first. There has been 
wasted enough time
with in-source builds, missing cleanups and all the weird side effects 
in our industry
for decades, and sadly CMake hasn't stopped that nonsense entirely. 
There are still
projects out there that can only build this way because they do some 
assumptions on
where to pick up files, but for something that will end up mixed 
cross/host build this

will never under any circumstances going to work.

I wonder if we can't just add it as extra argument to 
cmake_minimum_required(), in a
way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you 
require a version
newer than say 3.14, so anyone that is not explicitely requesting this 
to work will
automagically end up in a "clean" setup. Of course we need to make sure 
that no file is
written by CMake until that line is parsed (or any other command is 
encountered). Or
simply do something similar when using toolchain files, which CMake can 
detect before

even start parsing the main CMakeLists.txt.

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] [CMake] dependencies of cross compiliations

[Rolf Eike Beer]

Am Dienstag, 27. November 2018, 19:55:56 CET schrieb Eric Noulard:
> Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :
> > Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > > Hi,
> > > I hope this question was not asked before. I work in the embedded
> > > field and there it is usually to have at least two different build
> > > platforms. The Host platform, where unit tests are build (and where
> > > CMake is running) and an embedded Target platform, where targets are
> > > build with a cross compiler. Sometimes such a system comes with
> > > self-written tools that are build and run on the Host platform to
> > > build a target for the embedded Target platform (adding meta data to a
> > > binary to be used by a bootloader for example).
> > > 
> > > Usually I have two different build folders, one for the Host platform
> > > and one for the Target platform, using different calls to cmake to
> > > choose from a set of tools and targets. But when using this approach,
> > > it is necessary that the Host platform build ran before the Target
> > > platform build, so that tools that are required for the Target
> > > platform are build during the Host target build.
> > > 
> > > One solution I’ve came up with, is to build the required tools during
> > > the Target platform build, using an add_custom_target() to invoke the
> > > Target compiler directly. This works fine, as long as the tools are
> > > basically build just out of a couple of files.
> > > 
> > > What would be the „CMake-Way“ to add the tools (that have to be build
> > > on the Target platform) as dependency to targets that have to be build
> > > for the Target (cross compile) platform?
> > 
> > TL;DR: there is not "good" way yet. But there should be one.
> 
> I do agree with that quote I was quite surprised (a long time ago) that
> CMake did not support cross-compiling.
> Back then I was using recursive hand-written makefiles for cross-compiling.
> When I wanted to build
> the whole thing I only had to hit "make" and wait.
> 
> Moreover I think CMake cross-compiling support was biased by the fact CMake
> wasn't designed for that initially.
> Please don't take my remark as bare criticism I am using CMake for a long
> time now, I do like CMake very much
> and I was pleased to see the cross-compiling support coming.
> 
> However from my point of view and my cross-compiling experience when you
> cross-compile you have:
> 
> 1) the host compiler which is used to compile "host tools"
> 2) the target compiler (may be several of them) to "cross-compile"
> 
> My assumption are:
>  a) when you cross-compile your build is a "whole" and you shouldn't have
> to setup some superbuild
>structure for building host tools ht_exe and another for target1 tool
> t1t_exe and another one for target2 tool t2t_exe.
> 
>  b) what you want is to build:
>  ht_exe for the host
>  possibly use ht_exe during the build to generate some [source] file
>  t1t_exe for the [cross]target1
>  t2t_exe for the [cross]target2
> 
>  c)  you seldomly compile the same source for the host AND the target, but
> it may happen.
> 
> And you want to build all that stuff with a single configure+build command
> AND take advantage
> of fast and efficient parallel build for the **whole build**. I don't want
> to
> 
> cd /build/for/host
> ninja
> cd /build/for/target1
> ninja
> etc...
> 
> >  Helpful would be a special
> > 
> > variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> > a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> > here is an example:
> > 
> > if (CMAKE_CROSSCOMPILING)
> > 
> >  set(HOST_INSTALL_DIR "/some/where")
> >  add_host_build(. host HOST_INSTALL_DIR)
> > 
> > endif ()
> > add_executable(magic magic.cpp)
> > install(TARGETS magic DESTINATION bin) # installs both the host and the
> > target tool!
> > add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> > magic) # will call the host build
> > if (NOT CMAKE_HOST_BUILD)
> > 
> >  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
> >  install(TARGETS foo DESTINATION bin)
> > 
> > endif ()
> 
> I get your point but I think we may try a more declarative way.
> 
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin)
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
> add_executable(

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Rolf Eike Beer]

Am 2018-11-09 10:04, schrieb Torsten Robitzki:

Hi,
I hope this question was not asked before. I work in the embedded
field and there it is usually to have at least two different build
platforms. The Host platform, where unit tests are build (and where
CMake is running) and an embedded Target platform, where targets are
build with a cross compiler. Sometimes such a system comes with
self-written tools that are build and run on the Host platform to
build a target for the embedded Target platform (adding meta data to a
binary to be used by a bootloader for example).

Usually I have two different build folders, one for the Host platform
and one for the Target platform, using different calls to cmake to
choose from a set of tools and targets. But when using this approach,
it is necessary that the Host platform build ran before the Target
platform build, so that tools that are required for the Target
platform are build during the Host target build.

One solution I’ve came up with, is to build the required tools during
the Target platform build, using an add_custom_target() to invoke the
Target compiler directly. This works fine, as long as the tools are
basically build just out of a couple of files.

What would be the „CMake-Way“ to add the tools (that have to be build
on the Target platform) as dependency to targets that have to be build
for the Target (cross compile) platform?


TL;DR: there is not "good" way yet. But there should be one.

I'm hijacking this and move it to the developers list, because that is 
something "big", and we need to think about how to do that. I find it 
important to correctly solve this as it would simplify a lot of things. 
Especially given that Qt is thinking to use CMake to build Qt itself, 
which I bet all of us would love to see. But they will be after us if we 
don't offer a solution for this. And given the increasing amount of 
cross-setups these days I'm sure that a lot of other people would 
benefit.


My first idea was to have something like add_host_executable(), which 
would only be called when this is not CMAKE_CROSSCOMPILING, but at the 
end I think this clutters things too much.


Then I came up with:

  add_host_build("relative source dir" "build dir" [VARS])

This would create an entirely new CMake scope (with it's own 
CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
and would not take the CMAKE_TOOLCHAIN_FILE into account. People are 
free to pass "." as relative source dir in case they want to start at 
top level, but they may as well pass "tools", "generators" or whatever 
they call it. This is not intended to be called multiple times from the 
same project as it would scan for compiler and environment once for 
every call, but doing so does no harm beyond being slow(er) and the 
targets of one such sub-build not being visible to the others.


My idea would be that things added by add_executable() inside such a 
sub-build are visible as targets from the outer build. Other things like 
libraries and the like need not to be, they can't be linked in the outer 
world. The user is free to build with shared libs inside, and running 
the things from the build tree would result in the correct freshly build 
libs being picked up because of RPATH or whatever. There is no install 
of those targets possible from the outer build, this can entirely be 
managed from the host build. Of course one must be possible to set 
variables on the host build, that's where VARS comes into play. This 
holds a list of variable names that will be passed to the hostbuild. No 
values, to avoid all sorts of quoting issues. Helpful would be a special 
variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and 
a non-sysroot thing prefix in the toolchain file). Confused? Granted, 
here is an example:


if (CMAKE_CROSSCOMPILING)
set(HOST_INSTALL_DIR "/some/where")
add_host_build(. host HOST_INSTALL_DIR)
endif ()
add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin) # installs both the host and the 
target tool!
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND 
magic) # will call the host build

if (NOT CMAKE_HOST_BUILD)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)
endif ()

This should end up in a layout like this:

/tmp/install/prefix/tools/bin/magic.exe # Windows host
/tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
/tmp/install/prefix/sysroot/usr/bin/foo

The toolchain file would look somehow like this:

set(CMAKE_HOST_PREFIX prefix
set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot)

and the CMake command would look like this:

cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D 
CMAKE_HOST_INSTALL_PREFIX=tools ...


The wish-season is coming up, so that's sort of what I would like to 
have. Now it's your turn. No bikeshedding please, only deliveries ;)


Eike
--
--

Powered by www.kitware.com

Please keep messages on-topic and check 

Re: [CMake] dependencies of cross compiliations

[Rolf Eike Beer]

Am 2018-11-09 10:04, schrieb Torsten Robitzki:

Hi,
I hope this question was not asked before. I work in the embedded
field and there it is usually to have at least two different build
platforms. The Host platform, where unit tests are build (and where
CMake is running) and an embedded Target platform, where targets are
build with a cross compiler. Sometimes such a system comes with
self-written tools that are build and run on the Host platform to
build a target for the embedded Target platform (adding meta data to a
binary to be used by a bootloader for example).

Usually I have two different build folders, one for the Host platform
and one for the Target platform, using different calls to cmake to
choose from a set of tools and targets. But when using this approach,
it is necessary that the Host platform build ran before the Target
platform build, so that tools that are required for the Target
platform are build during the Host target build.

One solution I’ve came up with, is to build the required tools during
the Target platform build, using an add_custom_target() to invoke the
Target compiler directly. This works fine, as long as the tools are
basically build just out of a couple of files.

What would be the „CMake-Way“ to add the tools (that have to be build
on the Target platform) as dependency to targets that have to be build
for the Target (cross compile) platform?


TL;DR: there is not "good" way yet. But there should be one.

I'm hijacking this and move it to the developers list, because that is 
something "big", and we need to think about how to do that. I find it 
important to correctly solve this as it would simplify a lot of things. 
Especially given that Qt is thinking to use CMake to build Qt itself, 
which I bet all of us would love to see. But they will be after us if we 
don't offer a solution for this. And given the increasing amount of 
cross-setups these days I'm sure that a lot of other people would 
benefit.


My first idea was to have something like add_host_executable(), which 
would only be called when this is not CMAKE_CROSSCOMPILING, but at the 
end I think this clutters things too much.


Then I came up with:

  add_host_build("relative source dir" "build dir" [VARS])

This would create an entirely new CMake scope (with it's own 
CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
and would not take the CMAKE_TOOLCHAIN_FILE into account. People are 
free to pass "." as relative source dir in case they want to start at 
top level, but they may as well pass "tools", "generators" or whatever 
they call it. This is not intended to be called multiple times from the 
same project as it would scan for compiler and environment once for 
every call, but doing so does no harm beyond being slow(er) and the 
targets of one such sub-build not being visible to the others.


My idea would be that things added by add_executable() inside such a 
sub-build are visible as targets from the outer build. Other things like 
libraries and the like need not to be, they can't be linked in the outer 
world. The user is free to build with shared libs inside, and running 
the things from the build tree would result in the correct freshly build 
libs being picked up because of RPATH or whatever. There is no install 
of those targets possible from the outer build, this can entirely be 
managed from the host build. Of course one must be possible to set 
variables on the host build, that's where VARS comes into play. This 
holds a list of variable names that will be passed to the hostbuild. No 
values, to avoid all sorts of quoting issues. Helpful would be a special 
variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and 
a non-sysroot thing prefix in the toolchain file). Confused? Granted, 
here is an example:


if (CMAKE_CROSSCOMPILING)
set(HOST_INSTALL_DIR "/some/where")
add_host_build(. host HOST_INSTALL_DIR)
endif ()
add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin) # installs both the host and the 
target tool!
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND 
magic) # will call the host build

if (NOT CMAKE_HOST_BUILD)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)
endif ()

This should end up in a layout like this:

/tmp/install/prefix/tools/bin/magic.exe # Windows host
/tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
/tmp/install/prefix/sysroot/usr/bin/foo

The toolchain file would look somehow like this:

set(CMAKE_HOST_PREFIX prefix
set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot)

and the CMake command would look like this:

cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D 
CMAKE_HOST_INSTALL_PREFIX=tools ...


The wish-season is coming up, so that's sort of what I would like to 
have. Now it's your turn. No bikeshedding please, only deliveries ;)


Eike
--
--

Powered by www.kitware.com

Please keep messages on-topic and check 

Re: [cmake-developers] CMake string question

[Rolf Eike Beer]

Am 2018-11-09 14:55, schrieb Joachim Wuttke:

if("${srcdir}" STREQUAL "${bindir}")


if(srcdir STREQUAL bindir)


looks more idiomatic, thank you Eike -

But can we be sure that srcdir contains no blank?
Or does STREQUAL work even for argument strings
that contain blanks?


If you pass in only the variable names CMake will do the expansion only 
internally, so this is save. It just works (tm).


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] module proposal: PreventInSourceBuilds

[Rolf Eike Beer]

(correct list this time)


# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")


if(srcdir STREQUAL bindir)

HTH

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] [cmake-developers] module proposal: PreventInSourceBuilds

[Rolf Eike Beer]

# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")


if(srcdir STREQUAL bindir)

HTH

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

Re: [CMake] [HOWTO] Easily Cross-Compile CMake (with xstatic)

[Rolf Eike Beer]

Zach van Rijn wrote:
> On Fri, 2018-10-26 at 11:09 +0200, Rolf Eike Beer wrote:
> > ...
> 
> Hi Eike,
> 
> Thank you for writing. I agree that my approach is a bit brutish
> and aim to revise/reduce it to a minimum example. My goal was to
> describe a process that is uniform between compilers, easily
> automated, and less likely to break between CMake releases.
> 
> > So, the 2 things that I do not understand why you need them at
> > all:
> > 
> > -why do the bootstrap thing and move compilers? Just build a
> > recent CMake with your host toolchain, package that, and drop
> > it into the build container. The need for the host compiler
> > should be gone at this point
> 
> While it would make sense to build a complete (sufficiently-
> recent) CMake that performs the final build, I have not had
> consistent success (using the same exact compilers and systems)
> in doing so. For example, even specifying all of the settings as
> in your 'toolchain.cmake' file (below in this email), omitting
> the 'CMAKE_SYSTEM_NAME=Linux' part:
> 
> ...
> cmake-3.12.3/Utilities/cmcurl/lib/strerror.c:32:6: error: #error
> "strerror_r MUST be either POSIX, glibc or vxworks-style"
> ...

That's exactly what I meant with:

> > Well, it did not, but that was just because the embedded curl tries to do
> > some try_run() things that do not work. Since I already have a cross-curl
> > library at hand I decided to just use that, and things worked.

> and the build fatally aborts. If we add this back,
> 
> ...
> CMake Error: TRY_RUN() invoked in cross-compiling mode, please
> set the following cache variables appropriately:
> ...

You can instead just pass the expected codes, you just have to pass them as 
cache variables using "-C cache_file".

> # In an empty 'build/' directory in the root of CMake source:
> 
> $ cmake .. \
> -DCMAKE_SYSTEM_NAME=Linux  \
> -DCMAKE_C_COMPILER=/bin/gcc  `# cross` \
> -DCMAKE_C_FLAGS="-static --static -g0 -s -Os"  \
> -DCMAKE_CXX_COMPILER=/bin/g++`# cross` \
> -DCMAKE_CXX_FLAGS="-static --static -g0 -s -Os"\
> -DCMAKE_FIND_ROOT_PATH=/armv7l-linux-musleabihf  `# cross` \
> -DCMAKE_SYSROOT=/armv7l-linux-musleabihf `# cross` \
> -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER  \
> -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY   \
> -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY   \
> -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY   \
> -DKWSYS_LFS_WORKS=ON   \
> -DKWSYS_LFS_WORKS__TRYRUN_OUTPUT=""\
> -DHAVE_FSETXATTR_5=ON  \
> -DHAVE_FSETXATTR_5__TRYRUN_OUTPUT=""   \
> -DHAVE_GLIBC_STRERROR_R=OFF   `# because musl` \
> -DHAVE_GLIBC_STRERROR_R__TRYRUN_OUTPUT=""  \
> -DHAVE_POSIX_STRERROR_R=ON`# because musl` \
> -DHAVE_POSIX_STRERROR_R__TRYRUN_OUTPUT=""  \
> -DHAVE_POLL_FINE_EXITCODE=ON   \
> -DHAVE_POLL_FINE_EXITCODE__TRYRUN_OUTPUT=""
> 
> ...
> CMake Warning:
>   Manually-specified variables were not used by the project:
> 
> KWSYS_LFS_WORKS__TRYRUN_OUTPUT

You need to pass things like CMAKE_SYSTEM_NAME in the toolchain file in order 
to get the cross-build mode properly initialized, passing them on the 
commandline is not enough.

> Specifically because it would either require defining all of the
> above variables, including toolchain path(s), or running some
> sort of script or command like 'sed' to attempt to replace all
> hard-coded occurrences of the original toolchain. You can see
> that there are many:

No, you start in a clean build directory and pass the initial CMake invocation 
the toolchain file with -D CMAKE_TOOLCHAIN_FILE=toolchain-arm.cmake. CMake 
will then know only this compiler, and will find the other programs using the 
same triplet. Have one build dir per target, and one toolchain file per 
target. Maybe it's only one toolchain file that you need, when they differ 
only in the target triplet, which can then be placed e.g. in an environment 
variable before the first build.

> In summary, while I agree my original method could be
> simplified, I propose it for the following reasons:
> 
> (1) Avoid building two full CMake binaries (one for build system
> and one for target host system)

You do, bootstrapping builds a CMake binary. Not a full-featured 

Re: [CMake] [HOWTO] Easily Cross-Compile CMake (with xstatic)

[Rolf Eike Beer]

Am 2018-10-26 10:04, schrieb Zach van Rijn:

Hi Friends,


I have, until recently, been under the impression that CMake is
rather difficult (or impossible?) to cross-compile correctly. I
believe I have devised a sane method of doing so. In addition to
being simple, the output binaries are fully static, so they may
be transferred to any compatible system without dependencies. It
has been tested on CMake version 3.12.3, on 48 platforms, of
which 19 do not build without patches (contribs welcome!)


Hi Zach,

as someone who does crosscompiling for a living I have read your post, 
even if I have never seen a need for what you are doing. It's an 
interesting approach, although it looks pretty brute force. Not that I 
have not done things like that myself (has anyone tried to compile a 
recent udev without all the systemd things around it and without 
packaging the dependencies only needed for the systemd parts before? you 
know what I mean.).


I had an old cross-build recipe for CMake around and decided to clean 
the dust away and see if it still works. Well, it did not, but that was 
just because the embedded curl tries to do some try_run() things that do 
not work. Since I already have a cross-curl library at hand I decided to 
just use that, and things worked.


So, the 2 things that I do not understand why you need them at all:

-why do the bootstrap thing and move compilers? Just build a recent 
CMake with your host toolchain, package that, and drop it into the build 
container. The need for the host compiler should be gone at this point


-why do you need to overwrite the compiler with the target compiler? 
Just drop it anywhere and tell CMake with CC and CXX variables where it 
is. Or better, pass it a toolchain file like mine:


=== toolchain.cmake ===
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

# specify the cross compiler
set(CMAKE_C_COMPILER /opt/emlix/test/bin/arm-unknown-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER 
/opt/emlix/test/bin/arm-unknown-linux-gnueabi-g++)


# where is the target environment
set(CMAKE_FIND_ROOT_PATH /opt/emlix/test/sysroot)
set(CMAKE_SYSROOT /opt/emlix/test/sysroot)

# search for programs in the build host directories
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
===

I'm pretty sure you may find some rough edges, especially if you do not 
want to have the dependencies pre-build but use the embedded copies and 
do static builds with them. But otherwise you should hopefully be able 
to simplify your setup a lot.


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

Re: [cmake-developers] kernel log segfault warning messages when building/testing CMake

[Rolf Eike Beer]

Am Dienstag, 23. Oktober 2018, 20:58:51 CEST schrieb Alan W. Irwin:
> My "merlin" computer automatically builds and tests (including the
> PLplot contract test) CMake each day at 4:32 Pacific time, and I have
> noticed for some time now that those successful "merlin" tests (clean for
> the CMake dashboard, but with 8 compile warnings but no errors for the
> KWSys dashboard that is also generated by the CMake test) are always
> accompanied by segfault warnings in the kernel log file for my Debian
> Buster system.  At least some of those segfaults seem to
> be associated with the KWSys part of this test.  Here are those log
> warnings for today (taken from /var/log/messages):

I get those daily, here from my sparc:

[1540252.631482] kwsysTestProces[44830]: segfault at 4 ip 00011c68 
(rpc 00011c28) sp ffd7b670 error 1 in 
kwsysTestProcess[1+e000]
[1540255.178055] kwsysTestProces[45441]: segfault at 4 ip 00011c68 
(rpc 00011c28) sp ff933670 error 1 in 
kwsysTestProcess[1+e000]
[1541099.090339] kwsysTestProces[65043]: segfault at 4 ip 00011c68 
(rpc 00011c28) sp ffad96b0 error 1 in 
kwsysTestProcess[1+e000]
[1541099.096219] kwsysTestProces[65049]: segfault at 4 ip 00011c68 
(rpc 00011c28) sp ff95f6b0 error 1 in 
kwsysTestProcess[1+e000]

This is intentional, there are test binaries that segfault to test if that is 
properly detected by the signal handler/debug/ctest/whatever code.

> I don't notice any other platform on KWSys dashboard that also has the
> 8 build warnings, but it is likely my fairly recent gcc compiler
> (Debian Buster ccache and gcc/g++ 8.2.0) is more sensitive to
> problematic code in KWSys than prior versions of the gcc compiler
> suite.

I run gcc 8.2 on castor, but I don't know why this does not trigger these 
warnings.

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] Generalized verbose option for cmake --build.

[Rolf Eike Beer]

Am Donnerstag, 18. Oktober 2018, 17:48:28 CEST schrieb Ray Donnelly:
> Hi CMake developers,
> 
> Why do I need to know the necessary verbose flag to make each back-end
> that cmake --build calls emit more information? If forces my build
> script to switch on the platform in a really ugly way for something
> I'd consider a very important feature (you already hardcode various
> things to enable cmake --build to work, so why not this as well?)
> Something like cmake --build --verbose would be good.

I had the same problem with our automated builds, and I solved this by simply 
passing

-D CMAKE_VERBOSE_MAKEFILE=On

to the CMake run.

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] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing

[Rolf Eike Beer]

Am 2018-10-09 20:17, schrieb Brad King:

On 10/09/2018 02:00 PM, Rolf Eike Beer wrote:

Seems like you missed one part of the announcement mail ;)

Policies
==


The announcement comes from the release notes, and all policies
are mentioned there in relevant bullets.  We've never called them
out separately in such notes.  One can always see the list here:


https://cmake.org/cmake/help/v3.13/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-13

separated by version.


The idea was that someone like me would look on the announcement and say 
"hey, these 2 policies should be set to new even in my code supporting 
old CMake versions because it makes sense to us".


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] [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing

[Rolf Eike Beer]

Robert Maynard wrote:
> I am proud to announce the first CMake 3.13 release candidate.
>   https://cmake.org/download/
> 
> Documentation is available at:
>   https://cmake.org/cmake/help/v3.13
> 
> Release notes appear below and are also published at
>   https://cmake.org/cmake/help/v3.13/release/3.13.html
> 
> Some of the more significant changes in CMake 3.13 are:

[…]

Seems like you missed one part of the announcement mail ;)

Policies
==
 
* An explicit deprecation diagnostic was added for policies
  "CMP0055" through "CMP0063" ("CMP0054" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* CMP0076: The ``target_sources()`` command converts relative paths to
  absolute.

* CMP0077: ``option()`` honors normal variables.

* CMP0078: ``UseSWIG`` generates now standard target names.

* CMP0079: ``target_link_libraries()`` allows use with targets in other
  directories.

* CMP0080: ``BundleUtilities`` cannot be included at configure time.

* CMP0081: Relative paths not allowed in ``LINK_DIRECTORIES`` target property.

HTH,

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

Re: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing

[Rolf Eike Beer]

Robert Maynard wrote:
> I am proud to announce the first CMake 3.13 release candidate.
>   https://cmake.org/download/
> 
> Documentation is available at:
>   https://cmake.org/cmake/help/v3.13
> 
> Release notes appear below and are also published at
>   https://cmake.org/cmake/help/v3.13/release/3.13.html
> 
> Some of the more significant changes in CMake 3.13 are:

[…]

Seems like you missed one part of the announcement mail ;)

Policies
==
 
* An explicit deprecation diagnostic was added for policies
  "CMP0055" through "CMP0063" ("CMP0054" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* CMP0076: The ``target_sources()`` command converts relative paths to
  absolute.

* CMP0077: ``option()`` honors normal variables.

* CMP0078: ``UseSWIG`` generates now standard target names.

* CMP0079: ``target_link_libraries()`` allows use with targets in other
  directories.

* CMP0080: ``BundleUtilities`` cannot be included at configure time.

* CMP0081: Relative paths not allowed in ``LINK_DIRECTORIES`` target property.

HTH,

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

[cmake-developers] Automatically set policies for shipped modules

[Rolf Eike Beer]

I have seen multiple commits basically wrapping Modules/* in 
cmake_policy(PUSH|POP). I neither find that appealing nor do I think 
that this will scale for maintenance.


I suggest that every module included from the CMake installation is 
considered clean for whatever we do and automatically gets a policy 
scope push/pop right from the C++ level. The policies are all set to 
new. This has several advantages:


-we can just use whatever things CMake offers in them
-adding new policies during development would more likely cause things 
to "break" earlier, i.e. if a module is not clean for a new policy we 
may notice this earlier
-processing of the modules themselves should be slightly faster as the 
whole compat code paths are not taken into account right from the start


If a module needs to offer e.g. a function with a specific "old" 
behavior it can still explicitely set this policy to whatever value it 
needs. It does not need to push/pop as that will be done by the C++ code 
anyway.


Opinions?

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] Problems with static jpeg library

[Rolf Eike Beer]

wo...@masterdevops.eu wrote:
> Hi,
> 
> I am trying to compile the project libgd
> (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled.
> 
> I.e. first I downloaded the source code of libjpeg-turbo from
> https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled it

You need to make sure that this compile includes -fPIC in the compileflags of 
libjpeg.

> But I get several errors like this one:
> > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o):
> > relocation R_X86_64_32S against `.text' can not be used when making a
> > shared object; recompile with -fPIC

As said here.

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

Re: [CMake] [cmake-developers] RfD: deprecate link_directories() and link_libraries()

[Rolf Eike Beer]

Am Montag, 20. August 2018, 19:10:57 CEST schrieb Brad King:
> On 08/15/2018 01:30 PM, Rolf Eike Beer wrote:
> > My dislike against these functions is probably known, and now I would like
> > to bring this to a new level: I would like to formally deprecate these
> > functions. I don't think they serve any useful purpose anymore, given
> > that now even the pkg-config module can (and does) return absolute paths
> > to the libraries.
> What harm does their presence cause?
> 
> Please ask on the user list to see if people are using them.
> 
> I suspect they may be used by some projects to link to special runtime
> libraries when cross-compiling.  We'd need to make sure there is a
> better way for all such use cases before deprecating the commands.

I have only seen this commands in failed attempts to convert Makefiles to 
CMake without using the proper methods of calling find_library(). And then 
showing up here or in #cmake and complaining that it breaks.

So, has anyone an example where these are still needed with CMake 3.12 for 
anything that _can't_ be done properly?

Eike


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

[cmake-developers] RfD: deprecate link_directories() and link_libraries()

[Rolf Eike Beer]

My dislike against these functions is probably known, and now I would like to 
bring this to a new level: I would like to formally deprecate these functions. 
I don't think they serve any useful purpose anymore, given that now even the 
pkg-config module can (and does) return absolute paths to the libraries.

The plan is to introduce 2 new policies and whenever you set

 cmake_minimum_required(VERSION 3.13)

and use these functions you will get a warning telling you to stop that 
nonsense.

Thoughts?

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] find_package: keyword REQUIRED ignored

[Rolf Eike Beer]

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

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

Re: [CMake] find_package: keyword REQUIRED ignored

[Rolf Eike Beer]

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

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

Re: [cmake-developers] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

[Rolf Eike Beer]

> There is an easy workaround, but it feels nasty:
> 
> add_library(osm2go_x_lib INTERFACE)
> target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas)
> target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib)

This also seems to be not "stackable", i.e. an additional interface library in 
sub/sub can neither be linked into osm2go_lib nor osm2go_x_lib.

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] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

[Rolf Eike Beer]

> * The "target_link_libraries()" command may now be called to modify
>   targets created outside the current directory.

I played a bit around with that as I hope it would simplify some things in 
OSM2go, but it looks there are still some limitations:

in main:

add_library(osm2go_lib ...)

add_subdirectory(sub)

in sub:

pkg_search_module(GooCanvas REQUIRED IMPORTED_TARGET goocanvas)
target_sources(osm2go_lib PRIVATE
src/platforms/gtk/canvas_goocanvas.cpp
)
target_link_libraries(osm2go_lib PRIVATE PkgConfig::GooCanvas)

Breaks:

CMake Error at CMakeLists.txt:43 (add_library):
  Target "osm2go_lib" links to target "PkgConfig::GooCanvas" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

Is this intended to work?

There is an easy workaround, but it feels nasty:

add_library(osm2go_x_lib INTERFACE)
target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas)
target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib)


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] Prefer clang over gcc

[Rolf Eike Beer]

Am Sonntag, 24. Juni 2018, 11:32:32 CEST schrieb Quaquaraquà:
> Dear users,
> 
> how do you specify the order of compilers to select from the system?
> That is, if the user didn't set neither CMAKE_C_COMPILER nor the env.
> var. CC, I wish the build system would pick one of the compilers from a
> given list. In AutoConf, this is achieved through AC_PROG_CC([clang gcc
> icc cc]) [1]. What would be the corresponding snippet in cmake?

CMake will look at /usr/bin/cc if nothing else is set.

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

Re: [cmake-developers] cmake on AIX

[Rolf Eike Beer]

Am 2018-06-22 14:11, schrieb REIX, Tony:

Hi Brad,


Still investigating why MariaDB does not build.


We have the following trace:


CMake Error at
/opt/freeware/src/packages/BUILD/mariadb-10.3.7/64bit/CMakeFiles/CMakeTmp/CMakeLists.txt:14

cmake_minimum_required(VERSION 3.11.4.0)
set(CMAKE_MODULE_PATH
"/opt/freeware/src/packages/BUILD/mariadb-10.3.7/64bit/cmake;/opt/freeware/src/packages/BUILD/mariadb-10.3.7/64bit/plugin/auth_gssapi/cmake")
project(CMAKE_TRY_COMPILE CXX)
set(CMAKE_VERBOSE_MAKEFILE 1)
set(CMAKE_CXX_FLAGS " -pie -fPIC -fPIC -fno-rtti")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_DEFINITIONS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} 
${EXE_LINKER_FLAGS}")

include_directories(${INCLUDE_DIRECTORIES})
set(CMAKE_SUPPRESS_REGENERATION 1)
link_directories(${LINK_DIRECTORIES})
add_definitions(-DPACKAGE=test -D_LARGEFILE_SOURCE -D_LARGE_FILES
-D_FILE_OFFSET_BITS=64 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS)
cmake_policy(SET CMP0065 OLD)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY
"/opt/freeware/src/packages/BUILD/mariadb-10.3.7/64bit/CMakeFiles/CMakeTmp")
add_executable(cmTC_3efe0
"/opt/freeware/src/packages/BUILD/mariadb-10.3.7/64bit/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx")
target_link_libraries(cmTC_3efe0  "-L/opt/freeware/lib
-blibpath:/opt/freeware/lib::/usr/lib:/lib -I/usr/include
-I/opt/freeware/include -L/opt/freeware/lib
-blibpath:/opt/freeware/lib:/usr/lib:/lib -bmaxdata:0x8000 -brtl
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lpthreads" )


As Brad already said:


I suspect mariadb's source is setting CMAKE_REQUIRED_LIBRARIES
to a space-separated value instead of a ;-separated value.


That broken here: 
https://github.com/MariaDB/server/blob/ed0b84a0270bd99b001dd00654875d26e29b9432/plugin/auth_gssapi/cmake/FindGSSAPI.cmake#L56


Report to MariaDB to fix their things.

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] problem with CMake not including library's path (with pkg-config)

[Rolf Eike Beer]

Am Freitag, 25. Mai 2018, 18:53:43 schrieb Francesco Abbate:
> Hi,
> 
> thank you for the help.
> 
> As suggested by Andreas, AGG_LDFLAGS does what I think should be done
> and it works for me.
> 
> As for the IMPORTED_TARGET approach, I still need to explicitly call
> target_include_directories() and in addition the options given to the
> linker with PkgConfig::AGG seems to be wrong. I am quite inclined to
> forgot about this IMPORTED_TARGET approach, I prefer to use the more
> simple approach that works.

I would like to hear that story, just in case the module still has bugs. But 
please try with a recent development snapshot of CMake as there have been some 
additional fixes to the module recently.

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

Re: [CMake] problem with CMake not including library's path (with pkg-config)

[Rolf Eike Beer]

Am 2018-05-24 18:48, schrieb Francesco Abbate:

Hi all,

I stumbled in a problem with CMake. Everything is working fine except
that, for two libraries that I locate with pkg-config, cmake does not
include during linking the library's path (-L) which is given by
pkg-config.


Here an extract of the CMakeLists.txt:


[...]

include(FindPkgConfig)
pkg_search_module(AGG REQUIRED libagg)

[...]

target_link_libraries(libcanvas ${AGG_LIBRARIES})
target_include_directories(libcanvas PUBLIC
${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
[...]


Yes, this is a known shortcoming. But there is already help available!

For CMake >= 3.7 you can ask FindPkgConfig to create an imported target 
for you, which will then include not only the library paths, but also 
the include directories, so you do not need to explicitely call 
target_include_directories() anymore:


pkg_search_module(AGG REQUIRED IMPORTED_TARGET libagg)

target_link_libraries(libcanvas PkgConfig::AGG)

I strongly encourage you to go this way as it also drags in needed 
defines and the like.


If you can't go that route for whatever reason you need to do

link_directories(${AGG_LIBRARY_DIRS})

Side note: this is the only place I can still accept the usage of that 
command.


And since it's crappy that you have the full library path in the target, 
but not in a variable, there will be _LINK_LIBARIES from CMake 
3.12 on, which would be the thing you pass to target_link_libraries() 
instead and which has the exact same information the imported target 
already has.


Greetings,

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

Re: [CMake] cmake finds libxml2 but still says its missing

[Rolf Eike Beer]

Florian Lindner wrote:

Am 08.05.2018 um 15:12 schrieb Rolf Eike Beer:

Am 2018-05-08 14:51, schrieb Florian Lindner:

Hello,

I try to compile my software like

cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake 
-DBUILD_SHARED_LIBS=off ../..



cat ../../toolchain.cmake

SET(CMAKE_SYSTEM_NAME Hazelhen)
SET(CMAKE_C_COMPILER   cc)
SET(CMAKE_CXX_COMPILER CC)
SET(CMAKE_Fortran_COMPILER ftn)

which gives me the error:

CMake Error at
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
(message):
  Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES) (found version 
"2.9.4")

Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindLibXml2.cmake:69
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:73 (find_package)


It can determine the version, e.g. because it can ask pkg-config or 
finds the header, but it does not find the library

to link to.


Ok, is there any way to get more information on that? CMakeOutput.log
contains no reference at all to "xml".

The library files are there:


ls /usr/lib/libxml*

/usr/lib/libxml2.so.2  /usr/lib/libxml2.so.2.9.4


So they are indeed not. The module is looking for libxml2.so, which 
usually comes with the -dev or -devel package.


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

Re: [CMake] cmake finds libxml2 but still says its missing

[Rolf Eike Beer]

Am 2018-05-08 14:51, schrieb Florian Lindner:

Hello,

I try to compile my software like

cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake 
-DBUILD_SHARED_LIBS=off ../..



cat ../../toolchain.cmake

SET(CMAKE_SYSTEM_NAME Hazelhen)
SET(CMAKE_C_COMPILER   cc)
SET(CMAKE_CXX_COMPILER CC)
SET(CMAKE_Fortran_COMPILER ftn)

which gives me the error:

CMake Error at
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
(message):
  Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES) (found version 
"2.9.4")

Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindLibXml2.cmake:69
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:73 (find_package)


It can determine the version, e.g. because it can ask pkg-config or 
finds the header, but it does not find the library to link to.



I am a bit puzzled, because it says it found libxml 2.9.4, but then
again does not set the $LIBXML2_LIBRARIES.

Usage is

find_package(LibXml2 REQlesUIRED)


sure?

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

Re: [CMake] -std=c++17 vs -std=c++1y

[Rolf Eike Beer]

Am Sonntag, 6. Mai 2018, 08:00:14 schrieb Andrew Brownsword:
> Hi,
> 
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.

My bet is: that code is wrong. For every compiler I have seen the rules have 
been:

-std=c++AA is used as long as the standard is not fixed

-afterwards std=c++YY is introduced, and -std=c++AA is an alias for that

So it does not matter which flag you use when the compiler supports both, but 
you can't of course properly test on the value of __cplusplus in older 
compilers because you don't know in which year/month the standard will be 
released.

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

Re: [cmake-developers] target_link_libraries not callable from other directory scopes

[Rolf Eike Beer]

Craig Scott wrote:

> This limitation has been intentional since target_link_libraries was first
> created long before the others. It is the oldest of the target_ commands.
> The original justification is that we don't want to allow this because it
> makes it very easy for non-local commands to drastically change the way a
> target is built. That the newer target_ commands allow non-local targets
> was an oversight.
> 
> Maybe the limitation could be lifted but I'd like to see a strong
> justification and example use case.

[…]

This sounds very much like what I'm doing for OSM2go by other means. This will 
become simpler once 3.12 is out and object libraries can drag in additional 
dependencies:

https://github.com/osm2go/osm2go/blob/master/src/platforms/gtk/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] link_libraries

[Rolf Eike Beer]

Ranjeet Kuruvilla wrote:
> I have read that link_libraries command has gotten deprecated for version
> 3.10 and instead one needs to use link_librariestarget_link_libraries has
> one major disadvantage, in that it is required to put that statement after
> add_executable. I have here a CMake file for many different projects with
> the same folder structure, that scans a subfolder for files ending with
> .cmake. Those .cmake files can contain extra includes, definitions and
> libraries. With link_libraries I can put all statements inside one .cmake
> file. With target_link_libraries statement however I need 2 .cmake files,
> one before add_executable and one after for all the libraries. So I ask you
> to keep link_libraries alive!

tl;dr: no, surely not, it just adds libraries to probably unrelated targets.

> cmake_minimum_required( VERSION 3.10.0 )
> 
> project( ${PROJ_NAME} ${CXX} )enable_language(CXX)
> set( CMAKE_VERBOSE_MAKEFILE ON)
> 
> set( OPTIMIZING_FLAGS -O2)
> 
> set( CUSTOMBUILD "customBuild" )
> ...include_directories( BEFORE "/usr/local/include/x86_64-linux-gnu")

That is a compiler specific include, that should never be needed. The compiler 
adds that anyway, and if you use a different compiler this will probably badly 
screw things up.

> link_directories( BEFORE "/usr/lib")

That is a default link directory and is not needed.

> link_directories( BEFORE
> "/usr/lib/boost" ... 
> IF(EXISTS ${ CUSTOMBUILD})
>   message("Found custom cmake to build")
>   file( GLOB_RECURSE CMAKE_ITEMS LIST_DIRECTORIES false
> ${CONST_BASE_PATH_CUSTOMBUILD}*${CMAKE_SUFFIX})
>   foreach(CMAKE_ITEM ${CMAKE_ITEMS})
> message("Add cmake file " ${CMAKE_ITEM})   
> include(${CMAKE_ITEM})
>   endforeach(CMAKE_ITEM)
> endif()...

If you like it that way, fine…

> link_libraries(-lqpidclient -lqpidmessaging)
> link_libraries( -ljsoncpp)
> link_libraries( -lpistache)
> link_libraries( -lboost_system -lboost_thread -lboost_regex
> -lboost_filesystem -lboost_random -lboost_date_time -lboost_log
> -lboost_program_options -lboost_signals)link_libraries( -lpulse-simple
> -lpulse)
> link_libraries( -lcrypto -lpthread -lcurl)
> link_libraries(-lgstreamer-1.0 -lgstrtp-1.0 -lgstrtsp-1.0 -lgstsdp-1.0 -
lgstbase-1.0)
> link_libraries( -lgobject-2.0 -lsigc-2.0)
> link_libraries( -lssl -levent_openssl)
> link_libraries( -lcassandra)
> link_libraries( -lwebsockets)
> link_libraries( -levent -levent_pthreads -lcrypto -lcrypto++)
> link_libraries( -lm -lrt -lz -ldl -lva -lX11 -lm)
> link_libraries(${SEASTAR_DIR_LIBS})

but this is just broken. This will break
-when you update one of those libraries and it needs new dependencies
-when the libraries have different names e.g. because of a custom build
-probably just when you leave your own Linux distro
-for sure if you ever go to any other system (*BSD, Mac, Windows)

> add_executable( ${PROJ_NAME} ${SOURCES} )

When you use the modern version with (imported) targets you can even skip the 
include_directories things. I will reduce my example to 2 libraries for 
clarity, but it will work with the whole bunch also:

find_library(OpenSSL REQUIRED)
find_library(Boost REQUIRED regex)

add_library(foo ...)
target_link_libraries(foo
   # the usage of SSL is buried inside the lib and just an implementation
   # detail
PRIVATE OpenSSL::SSL 
   # a Boost Regex is part of the API, so everyone using this library needs
   # to get the headers and link to Boost
   PUBLIC Boost:regex
)

add_executable(bar ...)
target_link_libraries(bar foo)

So bar also links to Boost, it get's all the headers and more needed to use 
Boost.

For the very same reason people started using include-what-you-use one should 
not use link_libraries: explicitely specify what you need, otherwise you very 
likely break your build system if any of your dependencies changes and 
suddenly does not drag in one of your needed pieces anymore.

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

Re: [CMake] looking for 2 features to help pkg-config pc files

[Rolf Eike Beer]

Am Dienstag, 27. März 2018, 21:25:51 schrieb Nikos Chantziaras:
> Note that one downside to that is that people not using CMake cannot
> make use of that. They still need a pkgconfig file. So in a sense,
> pkgconfig is the common denominator everybody can use, regardless of
> build system.

What happened with that autoconf macro that was able to read in .cmake files?

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

[cmake-developers] Compiler changes on voyager.sf-tec.de

[Rolf Eike Beer]

I will remove gcc 4.8 on voyager now. There will be a gcc 6.4 eventually as 
replacement.

Greetings,

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

Re: [cmake-developers] Need more information concerning the Trilinos test of CMake

[Rolf Eike Beer]

> I notice in
>  there is
> an unstage comment from you.  Just out of curiosity, does that mean
> that commit was effectively immediately removed from
> stage/master/head?

Yes.

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

Re: [cmake-developers] Need more information concerning the Trilinos test of CMake

[Rolf Eike Beer]

Am 2017-10-25 02:24, schrieb Alan W. Irwin:

@Matthias:

I am directly addressing you in this post because git bisect says your
recent commit is the first one that shows this issue.  More details 
below.



commit 49287eed2bf9860919a155af848e7cf49d45f504
Author: Matthias Maennich 
Date:   Mon Oct 9 16:25:52 2017 +0200

CommandArgumentParser: avoid strcpy usage

as the first commit that had the bootstrap issue.


This very much looks like a change I had in a few weeks ago but removed 
from there because of exactly those compile failures. This works fine 
with newer gcc and apparently Clang versions, but older compilers do not 
like it.


Looking on that code again: I don't think it is needed to have anything 
of that in the class. Just make this file static variables:


static const char EmptyVariable[] = "";
static char DCURLYVariable[3] = "${";

and then drop those members from the class entirely. Maybe make them 
static variables in the class and initialize them in the cxx file if it 
is needed to have them in the class. But I don't see no reason to have 
them as writable, instance specific class members as those values will 
never change.


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

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Rolf Eike Beer]

Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey:
> Ok I debugged find_path() code in CMake and I determined the problem.
> First, let me explain what I'm doing a little more...
> 
> I build third party libraries on demand during configure step in
> CMake. I do so via execute_process() to invoke another CMake instance,
> that builds and installs a library. This is similar to how
> ExternalProject_Add() works, but forces it to happen at configure time
> so I can use find_package() afterwards to find the library I just
> built.

The trick with ExternalProject_Add is to also build your project with it, and 
not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs 
to be one level above your actual project. This way all things are done in 
order, so the dependencies are build before your main project.

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

Re: [CMake] FindIce module and C++11

[Rolf Eike Beer]

Am Donnerstag, 10. August 2017, 10:28:31 schrieb rle...@codelibre.net:
> On 2017-08-10 09:50, Jones J.W. wrote:
> > I'm building my code on Linux using the g++ flags "-std=c++11". This
> > means that I must link with the libIce++11 libraries instead of
> > libIce.
> > 
> > The FindIce module, however as no provision for choosing these
> > libraries thus resulting in unresolved symbols at link time.
> > 
> > I tried getting around the problem by simply listing Ice++11 as a
> > COMPONENT which works in Linux but the same CMakeLists.txt file in
> > Windows won't work as there is no Ice++11. Currently I have resolved
> > this by having two calls to the FindIce module inside an IF( MSVC )
> > conditional.
> > 
> > Would it be possible to add a flag to tell the FindIce module whether
> > C++11 is being used or not?
> 
> FindIce certainly needs an update for Ice 3.7.

To me this smells like an imported target with a generator expression that 
uses the C++11 or other lib depending on the used interface of the target. No 
idea if that is possible, but that would be the direction I would search in.

Greetings,

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

Re: [CMake] Can't get CMake to link pthreads to my lib

[Rolf Eike Beer]

Am 2017-08-08 15:45, schrieb Jean-Michaël Celerier:

Here's my CMakeLists.txt :





cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
project(oscour)
set(CMAKE_INCLUDE_CURRENT_DIR ON)

set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address 
-fsanitize=undefined")

set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address
-fsanitize=undefined")

add_subdirectory(uWebSockets)


set(CMAKE_THREAD_PREFER_PTHREAD On)


find_package(Threads REQUIRED)


Greetings,

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

Re: [CMake] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)"

[Rolf Eike Beer]

  (and we don't use find_lib(QT) because once upon a time it was
  tried but not instantly found working for cross compiling).

We're investigating whether we simply can switch to find_lib(QT)
which should solve that.

Does this make sense or am I mislead?


I have used it for crosscompiling in the CMake 3.x timeframe and it 
worked fine as long as qmake is properly set up (i.e. has it's qt.conf 
so it finds it's paths).


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

Re: [CMake] HOWTO cmake compatiblity?

[Rolf Eike Beer]

Steffen Dettmer wrote:

[…]


So far I think we need to install cmake into a versionized
directory and invoke it:

  v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake

and maybe remove cmake from PATH to ensure a failure if
accidentally calling "cmake".

What do you think?


Having multiple parallel versions of CMake in different directories 
works.


Greetings,

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

Re: [CMake] Advice on converting legacy project to modern CMake

[Rolf Eike Beer]

Am 2017-08-07 11:57, schrieb Björn Blissing:

Hi Eike,


3. Some of my legacy projects have all source in the same directory,
i.e. both source and header files are in the same directory. Others
have both private and public headers in the same directory. How do I
handle this with target_include_directories()? Preferably I would 
like

to avoid reorganizing the file structure.


If things are in the same directory you don't need
target_include_directories(), as the header files will be found anyway
if you use "" (probably also <>). If they are in a different directory
it doesn't matter if the private and public things are mixed, you need
to add that directory anyway.


Lets see if I understood what you are suggesting correctly:

Alternative 1: If both source and headers are in the same directory.
===
Solution: Omit the target_include_directories() statement completely
and just add the private and public header files in the add_library()
statement and the public headers in the install(FILES ...) statement.


Alternative 2: If source and headers are separated but both private
and public headers are included in the same directory.
===
Solution: Add the private and public header files in the add_library()
statement . Then add a target_include_directories() statement such as:
target_include_directories(anvil_lib PUBLIC
$
$
)

Then add the public headers in the install(FILES ...) statement.


Yes.


Is this correct? Follow up question: Since the directory include
contains both public and private headers should the
target_include_directories() be specified as PUBLIC or PRIVATE?


I would make it public: less code, and the private headers will simply 
not exist when installed.


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

Re: [CMake] Advice on converting legacy project to modern CMake

[Rolf Eike Beer]

Am 2017-08-07 11:35, schrieb Björn Blissing:

Hi,

I have some legacy projects which I intend to update to modern CMake.
The documentation is good but do not really cover "best practices". So
I have some questions which I hope some of you could help to answer:

1. Which version if CMake should I target? I.e. Which version should I
require in my cmake_minimum_required() statement?


If you want to have support for compile feature (i.e. automatically 
selecting C++11 if needed), then you should use at least 3.1. I 
personally don't see a reason to start lower anyway, if someone wants to 
build your new software, getting a new CMake shouldn't a problem anyway.



3. Some of my legacy projects have all source in the same directory,
i.e. both source and header files are in the same directory. Others
have both private and public headers in the same directory. How do I
handle this with target_include_directories()? Preferably I would like
to avoid reorganizing the file structure.


If things are in the same directory you don't need 
target_include_directories(), as the header files will be found anyway 
if you use "" (probably also <>). If they are in a different directory 
it doesn't matter if the private and public things are mixed, you need 
to add that directory anyway.


Greetings,

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

Re: [CMake] Coverage support

[Rolf Eike Beer]

Am 2017-08-07 11:06, schrieb Clément Gregoire:

I usually stop reading Cmakelists.txt as soon as I see this

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
-fprofile-arcs -ftest-coverage")


The pthread thing there is likely wrong anyway, and the -Wall is 
entirely optional. The other things are needed, otherwise gcov will not 
produce any useful output.


Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single 
test

target, which seems to be a difficult to scale on big projects


No, you don't. It's entirely fine if you just run "make test" as I do in 
OSM2go.


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

Re: [CMake] Coverage support

[Rolf Eike Beer]

Am 2017-08-07 09:57, schrieb Clément Gregoire:

Hi,
I'm a bit stuck when trying to add coverage reports to Cmake (gcov + 
lcov)

as I can't figure out what is the best (idiomatic) way to do it.
So far here are the ways I know of :
- setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / 
run

gcov on it : would like to avoid this
- same but adding a new build type : seems to be way better but running
gcov would still be a pain
- same with a tool chain file for the flags : doesn't sound a good idea
since coverage should only be ran in debug
- some library to link with that propagates the flags : not possible
because link flags are not transient
- macro that adds the flags / does magic on a per target basis : many
scripts do this but seems to be a pain to maintain. Also I would rather
have all my test targets be set up automatically
- any of the above for flags and Ctest ctest_coverage but all I need 
are

the gcov/lcov reports, not the coverage.xml for the dashboard
- using the command parameter of add_test
- something I missed?

I want the setup to be easy and compatible with codecov.io, sadly all 
the

script I found are bad, undocumented, or old and using bad practices.


What's wrong with this one: 
https://github.com/codecov/example-cpp11-cmake ?


I use it for both Codecov.io and CDash at the same time, see 
https://github.com/osm2go/osm2go/blob/master/.travis.yml


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

Re: [cmake-developers] C++ IDE

[Rolf Eike Beer]

Am Sonntag, 6. August 2017, 17:52:13 schrieb Ivam Pretti:
> Can you recomend an IDE to code in C/C++?

KDevelop.

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

Re: [CMake] How do I specify VTK minimum version?

[Rolf Eike Beer]

Am Dienstag, 11. Juli 2017, 15:18:11 schrieb Victor Lamoine:
> Hi,
> 
> I am using CMake to set up a VTK project. Our project requires VTK to be
> version 7.1 or newer. I'm using Ubuntu 16.04 with CMake 3.5.1.
> 

> find_package(VTK 7.1 REQUIRED)
[…]
>   The following configuration files were considered but not accepted:
> 
> /usr/local/lib/cmake/vtk-8.0/VTKConfig.cmake, version: 8.0.0
> /usr/lib/cmake/vtk-6.2/VTKConfig.cmake, version: 6.2.0
> 
> I have also tried find_package(VTK 7.1*.0* REQUIRED), without success.
> 
> Why isn't VTK 8.0.0 accepted? It is a greater version number so I expected
> it to be ok. How do I specify that I want VTK 7.1 OR newer?

It could be that VTK sets in it's config file "same major version" 
compatibility.

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

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[Rolf Eike Beer]

Am Mittwoch, 12. Juli 2017, 18:31:56 schrieb René J. V. Bertin:
> Andreas Naumann wrote:
> > cmake instrospects your compiler and asks for system directories. Only
> > these system directories will be removed and the corresponding libraries
> > will be linked by -l<...>. So, you should check your compiler and the
> > environment. I had several problems years ago with the environment
> > variable LIBRARY_PATH, which leads to such a behavior.
> 
> Hello Andreas,
> 
> Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I
> use). From what I understand, that variable allows you to specify a set of
> -L directories via an env. variable (other than LDFLAGS).
> 
> It seems that clang handles that variable in a somewhat different manner
> than GCC does. Even in a very simple call on the commandline (including the
> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied
> libraries, where GCC puts it before the 1st -l option.

Welcome to the work of link_directories(). This is exactly the reason to avoid 
it: it always causes trouble.

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

Re: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable

[Rolf Eike Beer]

Am 2017-07-12 13:35, schrieb René J.V. Bertin:

Hi,

I routinely use cmake to build projects for installation into a prefix
(/opt/local) and that use libraries from that location which also
exist in the system locations (typically in older versions, in that
case).

I thus have .pc files under /opt/local which generate linker
instructions of the type "-L/opt/local/lib -lfoo".

You'd expect this should work, but (too) often I still get linker
errors about symbols not being found which upon verification are in
fact provided by the intended library. In that case the
-L/opt/local/lib is typically given only once on the linker command
line ("way" before the corresponding -l argument), or not at all. See
the example below, where I don't see the -L option at all (linker
output and data from CMakeCache.txt after the HUGE linker command).

Initially I thought this was a case where one shouldn't filter out
identical -L options because the linker could limit their scope to
just the -l option immediately following the -L, but in this case it
appears that FindPNG.cmake simply doesn't consider the possibility
that libpng might be found in a location that isn't in the standard
library search path. IOW, FindPNG.cmake doesn't return a
PNG_LIBRARY_DIR variable, and provides the full path only in an
obsolete variable (PNG_LIBRARY). And for some reason, the command
`target_link_libraries(digikamcore ... ${PNG_LIBRARIES} ...)` is
translated into `-lpng -lz` .
Is that a bug or feature?


First, FindPNG.cmake doesn't care about pkg-config files, if that is bug 
or feature depends on your personal things. CMake will detect the 
library using the full path (as it has done), and construct proper -L 
and -l from that. It doesn't happen here, which makes me suspect that 
you don't even link to ${PNG_LIBRARIES} or PNG::PNG (the latter being 
the better version). It seems to me like the -lpng you see comes from 
QtWebkitWidgets, which would also need to be linked against your library 
anyway, as things could break in funny ways otherwise (no idea how 
stable the libPNG API is).


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

Re: [CMake] Status of "Modern" linking and modules?

[Rolf Eike Beer]

Am 2017-06-15 10:19, schrieb Nicholas Devenish:

I've been finding the 'modern' approaches of imported targets as used
by e.g. Boost and some other modules much better - being able to
specify all dependencies in a single target_link_libraries instead of
hauling around a whole load of required variables for each dependency.

However, only very few of the modules seem to have been altered to use
this paradigm - and some I'd have assumed were popular
(PythonInterp/PythonLibs - the libs themselves a dependency for
Boost::python) certainly aren't.

Is it just that nobody has gone over many of the existing packages, or
is there some reason this approach has been abandoned? This seems to
have been around for a couple of years, so I'd have expected more to
have of the module library converted.


It's just the former: patches welcome.

Greetings,

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

Re: [cmake-developers] Issues with overriding Python version, possible bug?

[Rolf Eike Beer]

Am 2017-04-29 22:47, schrieb Alan W. Irwin:

My use case (which I am pretty sure is a common one) is that for
PLplot I want the default behaviour of our build system to be that it
looks for Python 3, but if that does not exist it looks for Python 2.

It appears the following logic implements that desired default
behaviour.

find_package(PythonInterp 3)
find_package(PythonInterp 2)

So far so good, but I am sure there will be some of our users that
prefer Python 2 even when Python 3 is installed on their system.


find_package(PythonInterp 2 EXACT)

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

Re: [CMake] How to set libcurl library path and the library name?

[Rolf Eike Beer]

Alex Chen wrote:
> There is an error in the FindCURL document of Cmake 3.8 (or prior versions).

No.

> It says
> 
> CURL_INCLUDE_DIRS   - where to find curl/curl.h, etc.

Which is what it is _setting_.

> But in fact it is looking for CURL_INCLUDE_DIR, not CURL_INCLUDE_DIRS.  If I
> set –DCURL_INCLUDE_DIRS, cmake cannot find libcurl’s header files.

This is correct, it is _looking_ for the singular form, and then putting it in 
the plural one, like basically all modules do. This has the reason that 
sometimes you need multiple include dirs, but you can't properly store that in 
one cache variable (you need to know which one was actually not found on next 
run).

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

Re: [cmake-developers] [UseSWIG] regression in results from CMake-3.0.2 to recent versions --SOLVED

[Rolf Eike Beer]

> The somewhat longer story is just at the start (fortunately for me) of
> that simplification process, I double checked the source of both
> FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
> out to be special cutting-edge versions recommended by one user of the
> cmake bug tracking system from a decade (!) ago.  Oops!  Those
> versions did continue to work for a very long time for our simple swig
> needs, but those are obviously well past their "best buy" date, and
> complete removal of those "special" versions from PLplot (so PLplot is
> now using the official version of those modules that is distributed by
> whatever CMake version a user chooses) works without the warning
> messages for both CMake-3.0.2 AND CMake-3.8.0-rc4.

So something in that range of versions has broken those old modules. It would 
be interesting to find out if that was breaking a never-really-supported case 
or something else.

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

Re: [cmake-developers] Fortran standards compliance for various compilers

[Rolf Eike Beer]

>  What would really be useful is a list containing
> what Fortran features from the Fortran 2003 and 2008 standards that the
> given Fortran compiler supports.  That information is already

To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and 
friends, no? This exactly sounds like the whole compile_features things 
already done for C and C++, so yet another language shouldn't be too hard I 
guess.

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

Re: [cmake-developers] Mirror CMake release files on GitHub?

[Rolf Eike Beer]

Am Montag, 6. Februar 2017, 13:00:33 schrieb Brad King:
> On 02/05/2017 02:10 PM, Gregor Jasny via cmake-developers wrote:
> > I wonder if it would make sense to publish the CMake release tarballs
> > and binaries not only on cmake.org but also on github...
> > https://github.com/aktau/github-release
> 
> Thanks.  I'll take a look at that when I get a chance.

Now would be a good time ;)

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

Re: [CMake] Multiple ELSE() clauses

[Rolf Eike Beer]

Am 2017-03-20 11:57, schrieb Sergey Zakharchenko:

Hello,

I've just noticed that CMake doesn't forbid multiple ELSE() (not just
ELSEIF()) clauses, and proceeds without warnings.

IF(1)
ELSE()
ELSE()
ENDIF()

Is this expected?


https://gitlab.kitware.com/cmake/cmake/issues/14335

--
--

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

[cmake-developers] Problems with CTestTestParallel

[Rolf Eike Beer]

My new build machine (castor.sf-tec.de) seems to reliably trigger some sort of 
error in CTestTestParallel. If I run that test standalone or just "ctest -j 
64" in a build tree it seems to work. Running the nightly script gives the 
error again. I initially suspected some sort of system problem, but other 
hosts see this problem again, so I now suspect it's a deeper problem.

Even if it says "compile errors" the Lockfile binary is produced and can be run 
successfully. I've attached the complete build dir of that test, maybe anyone 
has a clue what is going on there. You probably cannot run the executable as 
this is compiled for a Sparc Niagara 2 processor.

Greetings,

Eike

testparallel.tar.xz
Description: application/xz-compressed-tar
-- 

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] [RESEND] [PATCH] x32-abi support #15994 (without line wrapping!)

[Rolf Eike Beer]

> +  PATH_SUFFIXES libx32 lib64 lib lib32

> +  PATH_SUFFIXES lib64 libx32)

> +/usr/local/libx32
>  /usr/local/lib64
>  /usr/local/lib
> +/usr/libx32
>  /usr/lib64
>  /usr/lib
>  /usr/X11R6/include

> +  list(APPEND ice_library_suffixes "libx32" "${_lib64}" "lib${_x64}" "lib")

And so on…

Shouldn't we think of providing some sort of variable that holds those things? 
Maybe one that even knows what kind of distro is used (I remember there is 
some sort of lib64 special casing for Debian), so the chance of a direct hit 
is bigger?

Yes, there will always be modules that need to override this (e.g. for 
Windows), but it could make things a lot easier for the "normal case". 
Something like GNUInstallDirs backwards or so.

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

Re: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

[Rolf Eike Beer]

Adrian Sevcenco wrote:
> Hi! I am trying to rebuild the f25 srpm on a centos 7 machine but after
> a successful compilation i get this test error :
> 99% tests passed, 1 tests failed out of 454
> 
> Label Time Summary:
> Label1=   0.20 sec (1 test)
> Label2=   0.20 sec (1 test)
> 
> Total Test time (real) = 257.33 sec
> 
> The following tests FAILED:
>6 - kwsys.testSystemTools (Failed)
> Errors while running CTest

ctest -V --rerun-failed

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

[Cmake-commits] CMake branch, next, updated. v3.7.2-2515-g50be50f

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  50be50f8fd017a4f014aded68d81e1955382db63 (commit)
   via  37ed860ad1e71f347513a38432640f7dda5c07ee (commit)
   via  94a8ee6fd0ba487437579bb224500b9f46c2819c (commit)
   via  940bf6a4a427c8edfd975bf078a3ea331847f72a (commit)
   via  f26ca5a1953e7f260bc23d30c5d35cc071a6f6ab (commit)
  from  9a4338d7f59750c2cbd61ed0a252224f102f0384 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50be50f8fd017a4f014aded68d81e1955382db63
commit 50be50f8fd017a4f014aded68d81e1955382db63
Merge: 9a4338d 37ed860
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Thu Feb 2 15:56:13 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Feb 2 15:56:13 2017 -0500

Merge topic 'gcc-features' into next

37ed860a GNU C++: record that -fvisibility-inlines-hidden is available 
since 4.0
94a8ee6f GNU C: record that C99 is available since at least 3.4
940bf6a4 Tests/Module/WCDH: only use -Werror=undef compiler flag if 
actually supported
f26ca5a1 Tests/Module/WCDH: write multi_file_compiler_detection.h before 
using it


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=37ed860ad1e71f347513a38432640f7dda5c07ee
commit 37ed860ad1e71f347513a38432640f7dda5c07ee
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Jan 27 16:52:42 2017 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Thu Feb 2 18:28:56 2017 +0100

GNU C++: record that -fvisibility-inlines-hidden is available since 4.0

See https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Option-Summary.html

diff --git a/Modules/Compiler/GNU-CXX.cmake b/Modules/Compiler/GNU-CXX.cmake
index b04ea11..c007c98 100644
--- a/Modules/Compiler/GNU-CXX.cmake
+++ b/Modules/Compiler/GNU-CXX.cmake
@@ -6,7 +6,7 @@ if (WIN32)
 set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN 
"-fno-keep-inline-dllexport")
   endif()
 else()
-  if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.2)
+  if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0)
 set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN 
"-fvisibility-inlines-hidden")
   endif()
 endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94a8ee6fd0ba487437579bb224500b9f46c2819c
commit 94a8ee6fd0ba487437579bb224500b9f46c2819c
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Jan 27 16:49:45 2017 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Thu Feb 2 18:28:56 2017 +0100

GNU C: record that C99 is available since at least 3.4

diff --git a/Help/manual/cmake-compile-features.7.rst 
b/Help/manual/cmake-compile-features.7.rst
index 4f48ad9..448fe9a 100644
--- a/Help/manual/cmake-compile-features.7.rst
+++ b/Help/manual/cmake-compile-features.7.rst
@@ -338,6 +338,14 @@ versions specified for each:
 * ``SunPro``: Oracle SolarisStudio version 12.4.
 * ``Intel``: Intel compiler versions 12.1 through 17.0.
 
+CMake is currently aware of the :prop_tgt:`C standards `
+and :prop_gbl:`compile features ` available from
+the following :variable:`compiler ids <CMAKE__COMPILER_ID>` as of the
+versions specified for each:
+
+* all compilers and versions listed above for C++
+* ``GNU``: GNU compiler versions 3.4 through 5.0.
+
 CMake is currently aware of the :prop_tgt:`CUDA standards `
 from the following :variable:`compiler ids <CMAKE__COMPILER_ID>` as of 
the
 versions specified for each:
diff --git a/Help/release/dev/gcc-features.rst 
b/Help/release/dev/gcc-features.rst
new file mode 100644
index 000..c6959ab
--- /dev/null
+++ b/Help/release/dev/gcc-features.rst
@@ -0,0 +1,5 @@
+gcc-features
+
+
+* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
+  is now aware of the availability of C99 in gcc since version 3.4.
diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 

[Cmake-commits] CMake branch, next, updated. v3.7.2-2492-g45ffe4d

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  45ffe4d2d2f45f04f9e5e5800cb374a2fc9fa18c (commit)
   via  42820eaedad8c6dddcf84e7a57ea102a6ca72bd4 (commit)
   via  da1abae81303233cb78f0590f92aef75e82275f9 (commit)
  from  e7bbf8c3ce1362f30602b73e57feb36af14b46ac (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45ffe4d2d2f45f04f9e5e5800cb374a2fc9fa18c
commit 45ffe4d2d2f45f04f9e5e5800cb374a2fc9fa18c
Merge: e7bbf8c 42820ea
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Wed Feb 1 15:28:07 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Feb 1 15:28:07 2017 -0500

Merge topic 'gcc-features' into next

42820eae GNU C++: record that -fvisibility-inlines-hidden is available 
since 4.0
da1abae8 GNU C: record that C99 is available since at least 3.4


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42820eaedad8c6dddcf84e7a57ea102a6ca72bd4
commit 42820eaedad8c6dddcf84e7a57ea102a6ca72bd4
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Jan 27 16:52:42 2017 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Wed Feb 1 21:27:37 2017 +0100

GNU C++: record that -fvisibility-inlines-hidden is available since 4.0

See https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Option-Summary.html

diff --git a/Modules/Compiler/GNU-CXX.cmake b/Modules/Compiler/GNU-CXX.cmake
index b04ea11..c007c98 100644
--- a/Modules/Compiler/GNU-CXX.cmake
+++ b/Modules/Compiler/GNU-CXX.cmake
@@ -6,7 +6,7 @@ if (WIN32)
 set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN 
"-fno-keep-inline-dllexport")
   endif()
 else()
-  if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.2)
+  if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0)
 set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN 
"-fvisibility-inlines-hidden")
   endif()
 endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da1abae81303233cb78f0590f92aef75e82275f9
commit da1abae81303233cb78f0590f92aef75e82275f9
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Jan 27 16:49:45 2017 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Wed Feb 1 21:27:37 2017 +0100

GNU C: record that C99 is available since at least 3.4

diff --git a/Help/manual/cmake-compile-features.7.rst 
b/Help/manual/cmake-compile-features.7.rst
index d641856..078b20b 100644
--- a/Help/manual/cmake-compile-features.7.rst
+++ b/Help/manual/cmake-compile-features.7.rst
@@ -338,6 +338,14 @@ versions specified for each:
 * ``SunPro``: Oracle SolarisStudio version 12.4.
 * ``Intel``: Intel compiler versions 12.1 through 17.0.
 
+CMake is currently aware of the :prop_tgt:`language standards `
+and :prop_gbl:`compile features ` available from
+the following :variable:`compiler ids <CMAKE__COMPILER_ID>` as of the
+versions specified for each:
+
+* all compilers and versions listed above for C++
+* ``GNU``: GNU compiler versions 3.4 through 5.0.
+
 CMake is currently aware of the :prop_tgt:`language standards `
 from the following :variable:`compiler ids <CMAKE__COMPILER_ID>` as of 
the
 versions specified for each:
diff --git a/Help/release/dev/gcc-features.rst 
b/Help/release/dev/gcc-features.rst
new file mode 100644
index 000..c6959ab
--- /dev/null
+++ b/Help/release/dev/gcc-features.rst
@@ -0,0 +1,5 @@
+gcc-features
+
+
+* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
+  is now aware of the availability of C99 in gcc since version 3.4.
diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 4.4 at least:
-set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MIN

[Cmake-commits] CMake branch, next, updated. v3.7.2-2489-ge7bbf8c

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  e7bbf8c3ce1362f30602b73e57feb36af14b46ac (commit)
   via  f4de2ab585caf8a9c6773fa4507008b83a1ca2cf (commit)
   via  771e9f2fe79ec1a1bdf8189f88e48704e97b827e (commit)
   via  c381c193a1ceeb79cf84ab905a0076c783b32707 (commit)
  from  bef58c63926fdb86c63525bed0ea57ed40d9e529 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7bbf8c3ce1362f30602b73e57feb36af14b46ac
commit e7bbf8c3ce1362f30602b73e57feb36af14b46ac
Merge: bef58c6 f4de2ab
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Wed Feb 1 14:56:48 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Feb 1 14:56:48 2017 -0500

Merge topic 'gcc-features' into next

f4de2ab5 GNU C++: record that -fvisibility-inlines-hidden is available 
since 4.0
771e9f2f GNU C: record that C99 is available since at least 3.4
c381c193 Tests/Module/WCDH: write multi_file_compiler_detection.h before 
using it


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f4de2ab585caf8a9c6773fa4507008b83a1ca2cf
commit f4de2ab585caf8a9c6773fa4507008b83a1ca2cf
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Jan 27 16:52:42 2017 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Wed Feb 1 20:53:00 2017 +0100

GNU C++: record that -fvisibility-inlines-hidden is available since 4.0

See https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Option-Summary.html

diff --git a/Modules/Compiler/GNU-CXX.cmake b/Modules/Compiler/GNU-CXX.cmake
index b04ea11..c007c98 100644
--- a/Modules/Compiler/GNU-CXX.cmake
+++ b/Modules/Compiler/GNU-CXX.cmake
@@ -6,7 +6,7 @@ if (WIN32)
 set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN 
"-fno-keep-inline-dllexport")
   endif()
 else()
-  if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.2)
+  if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0)
 set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN 
"-fvisibility-inlines-hidden")
   endif()
 endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=771e9f2fe79ec1a1bdf8189f88e48704e97b827e
commit 771e9f2fe79ec1a1bdf8189f88e48704e97b827e
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Jan 27 16:49:45 2017 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Wed Feb 1 20:53:00 2017 +0100

GNU C: record that C99 is available since at least 3.4

diff --git a/Help/release/dev/gcc-features.rst 
b/Help/release/dev/gcc-features.rst
new file mode 100644
index 000..c6959ab
--- /dev/null
+++ b/Help/release/dev/gcc-features.rst
@@ -0,0 +1,5 @@
+gcc-features
+
+
+* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
+  is now aware of the availability of C99 in gcc since version 3.4.
diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 4.4 at least:
-set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
-set(_cmake_feature_test_c_restrict "${GNU44_C99}")
-set(_cmake_feature_test_c_variadic_macros "${GNU44_C99}")
+# Since 3.4 at least:
+set(GNU34_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
+set(_cmake_feature_test_c_restrict "${GNU34_C99}")
+set(_cmake_feature_test_c_variadic_macros "${GNU34_C99}")
 
 set(GNU_C90 "${_cmake_oldestSupported}")
 set(_cmake_feature_test_c_function_prototypes "${GNU_C90}")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index

Re: [cmake-developers] Recording compiler features for older gcc versions

[Rolf Eike Beer]

Am Montag, 9. Januar 2017, 10:59:13 schrieb Rolf Eike Beer:
> I need for several projects the ability to set CMAKE_C_STANDARD on older
> compilers, at least gcc 4.2, but preferably also down to gcc 3.4. I have
> them available, so testing is not the issue. But there are some problems
> besides "just record them".
> 
> The problems that I know of:
> 
> -WriteCompilerDetectionHeader last time had problems when the features for
> the compiler were recorded only for C for a given version, i.e. I can't
> just tell CMake "gcc 3.4ff. know about C99" without also recording C++
> features for that versions

This is actually not true. What happens is that the testcases assume that when 
one of them is set, the other one is set, too. This is also what is causing 
the current test breakage. I'll come up with a patch shortly, but maybe not 
today. The solution is easy: sort the subtests in the CMakeLists.txt and check 
for both variables independently.

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

Re: [CMake] Find Vulkan on 32 bit builds

[Rolf Eike Beer]

There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different 
architectures.)


Ideally they would just provide CMake config files then…

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

[cmake-developers] Recording compiler features for older gcc versions

[Rolf Eike Beer]

I need for several projects the ability to set CMAKE_C_STANDARD on older 
compilers, at least gcc 4.2, but preferably also down to gcc 3.4. I have them 
available, so testing is not the issue. But there are some problems besides 
"just record them".

The problems that I know of:

-WriteCompilerDetectionHeader last time had problems when the features for the 
compiler were recorded only for C for a given version, i.e. I can't just tell 
CMake "gcc 3.4ff. know about C99" without also recording C++ features for that 
versions
-the standard check for working features is currently auto_type, which is not 
supported by older compilers. Basically all support long_long_type, so we 
either need to change that (patch is in my gcc-34-features branch), or we need 
a better way to check what is available at all before using it.

Any help welcome.

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

Re: [CMake] cmake vs. Python 3.4

[Rolf Eike Beer]

Am Samstag, 24. Dezember 2016, 12:06:10 schrieb Rolf Eike Beer:
> Am Freitag, 23. Dezember 2016, 20:57:49 schrieb Lev:
> > Hi list,
> > 
> > 
> > I have this:
> > 
> > FIND_PACKAGE(PythonInterp)
> > 
> > and cmake finds this:
> > 
> > -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
> > 
> > However, 3.4 is also installed. How can I specify to find 3.4?
> > 
> > If I say:
> > 
> > set(Python_ADDITIONAL_VERSIONS 3.4)
> > FIND_PACKAGE(PythonInterp 3 REQUIRED)
> 
> The problem here is the "REQUIRED". Older CMake versions did not let "3.4"
> satisfy "3" as required version, what newer versions do. However they let it
> pass as a minimum version. And you don't need to add 3.4 to the list of
> supported versions, if I read the log correct then 3.4 is already in the
> list for CMake 3.0.

Ehm, the "3" would not satisfy EXACT, but it of course satisfies REQUIRED. And 
it works for me, btw.

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

Re: [CMake] cmake vs. Python 3.4

[Rolf Eike Beer]

Am Freitag, 23. Dezember 2016, 20:57:49 schrieb Lev:
> Hi list,
> 
> 
> I have this:
> 
> FIND_PACKAGE(PythonInterp)
> 
> and cmake finds this:
> 
> -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
> 
> However, 3.4 is also installed. How can I specify to find 3.4?
> 
> If I say:
> 
> set(Python_ADDITIONAL_VERSIONS 3.4)
> FIND_PACKAGE(PythonInterp 3 REQUIRED)

The problem here is the "REQUIRED". Older CMake versions did not let "3.4" 
satisfy "3" as required version, what newer versions do. However they let it 
pass as a minimum version. And you don't need to add 3.4 to the list of 
supported versions, if I read the log correct then 3.4 is already in the list 
for CMake 3.0.

Eike, having done most of this version detection stuff

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

[Cmake-commits] CMake branch, next, updated. v3.7.1-1830-gebb7ff5

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  ebb7ff5b9ba490a8645de7092c729f211b8cd464 (commit)
   via  7ac84052c4f6a22349fde7b43b8b073a22bf30f1 (commit)
   via  4918cd8c98938ab245d7fea74ba6e20f3ec8ef8b (commit)
  from  b55c0379eeab76a40a0a8291d1e5ab53b0014689 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ebb7ff5b9ba490a8645de7092c729f211b8cd464
commit ebb7ff5b9ba490a8645de7092c729f211b8cd464
Merge: b55c037 7ac8405
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Tue Dec 20 12:38:36 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Dec 20 12:38:36 2016 -0500

Merge topic 'sparc-libatomic' into next

7ac84052 explicitely link against libatomic on Linux/sparc for 
__atomic_fetch_add_4()
4918cd8c CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ac84052c4f6a22349fde7b43b8b073a22bf30f1
commit 7ac84052c4f6a22349fde7b43b8b073a22bf30f1
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Mon Dec 19 14:47:01 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Tue Dec 20 18:38:15 2016 +0100

explicitely link against libatomic on Linux/sparc for __atomic_fetch_add_4()

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index d15fdbe..388bf89 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -785,6 +785,15 @@ target_link_libraries(CMakeLib cmsys
   ${CMake_KWIML_LIBRARIES}
   )
 
+if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_SYSTEM_PROCESSOR MATCHES 
"sparc")
+  # the atomic instructions are implemented using libatomic on some platforms,
+  # so linking to that may be required
+  check_library_exists(atomic __atomic_fetch_add_4 "" LIBATOMIC_NEEDED)
+  if(LIBATOMIC_NEEDED)
+target_link_libraries(CMakeLib atomic)
+  endif()
+endif()
+
 # On Apple we need CoreFoundation
 if(APPLE)
   target_link_libraries(CMakeLib "-framework CoreFoundation")

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.1-1827-gb55c037

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  b55c0379eeab76a40a0a8291d1e5ab53b0014689 (commit)
   via  799e55a6a525e255c7b3c49e1afa9a62f463ca96 (commit)
  from  934289dd5dce80d4f8e53b5dfdb3c300e3dbf5b2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b55c0379eeab76a40a0a8291d1e5ab53b0014689
commit b55c0379eeab76a40a0a8291d1e5ab53b0014689
Merge: 934289d 799e55a
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Tue Dec 20 12:38:04 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Dec 20 12:38:04 2016 -0500

Merge topic 'sparc-libatomic' into next

799e55a6 FIXUP: match libatomic for all sparc


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=799e55a6a525e255c7b3c49e1afa9a62f463ca96
commit 799e55a6a525e255c7b3c49e1afa9a62f463ca96
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Tue Dec 20 18:37:52 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Tue Dec 20 18:37:52 2016 +0100

FIXUP: match libatomic for all sparc

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 7342524..388bf89 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -785,7 +785,7 @@ target_link_libraries(CMakeLib cmsys
   ${CMake_KWIML_LIBRARIES}
   )
 
-if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_SYSTEM_PROCESSOR STREQUAL 
"sparc")
+if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_SYSTEM_PROCESSOR MATCHES 
"sparc")
   # the atomic instructions are implemented using libatomic on some platforms,
   # so linking to that may be required
   check_library_exists(atomic __atomic_fetch_add_4 "" LIBATOMIC_NEEDED)

---

Summary of changes:
 Source/CMakeLists.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.1-1825-g934289d

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  934289dd5dce80d4f8e53b5dfdb3c300e3dbf5b2 (commit)
   via  f3b3644c4fed7915bb6774929af5766ed1809054 (commit)
   via  3657ac9fbb6bf6cd82bf9a0119fd989ab3f4f704 (commit)
   via  77468c751f62c4dfa64fb60c5f4336a8534aec85 (commit)
  from  0fdba25baabb8f32141a6ebc854ad8cd9f4a646c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=934289dd5dce80d4f8e53b5dfdb3c300e3dbf5b2
commit 934289dd5dce80d4f8e53b5dfdb3c300e3dbf5b2
Merge: 0fdba25 f3b3644
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Mon Dec 19 08:47:33 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Dec 19 08:47:33 2016 -0500

Merge topic 'sparc-libatomic' into next

f3b3644c explicitely link against libatomic on Linux/sparc for 
__atomic_fetch_add_4()
3657ac9f CMake Nightly Date Stamp
77468c75 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3b3644c4fed7915bb6774929af5766ed1809054
commit f3b3644c4fed7915bb6774929af5766ed1809054
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Mon Dec 19 14:47:01 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Mon Dec 19 14:47:01 2016 +0100

explicitely link against libatomic on Linux/sparc for __atomic_fetch_add_4()

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index d15fdbe..7342524 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -785,6 +785,15 @@ target_link_libraries(CMakeLib cmsys
   ${CMake_KWIML_LIBRARIES}
   )
 
+if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_SYSTEM_PROCESSOR STREQUAL 
"sparc")
+  # the atomic instructions are implemented using libatomic on some platforms,
+  # so linking to that may be required
+  check_library_exists(atomic __atomic_fetch_add_4 "" LIBATOMIC_NEEDED)
+  if(LIBATOMIC_NEEDED)
+target_link_libraries(CMakeLib atomic)
+  endif()
+endif()
+
 # On Apple we need CoreFoundation
 if(APPLE)
   target_link_libraries(CMakeLib "-framework CoreFoundation")

---

Summary of changes:
 Source/CMakeLists.txt |9 +
 Source/CMakeVersion.cmake |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.1-1821-g0fdba25

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0fdba25baabb8f32141a6ebc854ad8cd9f4a646c (commit)
   via  7c8a07a306894bec95b465411759c6fff76a35be (commit)
  from  65aadbed2e3361519eec9a32a3250976c0ae04ed (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0fdba25baabb8f32141a6ebc854ad8cd9f4a646c
commit 0fdba25baabb8f32141a6ebc854ad8cd9f4a646c
Merge: 65aadbe 7c8a07a
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Sun Dec 18 13:21:17 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Dec 18 13:21:17 2016 -0500

Merge topic 'gcc-34-features' into next

7c8a07a3 Revert "record features of gcc 3.4..4.3"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c8a07a306894bec95b465411759c6fff76a35be
commit 7c8a07a306894bec95b465411759c6fff76a35be
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Sun Dec 18 19:20:30 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Sun Dec 18 19:20:30 2016 +0100

Revert "record features of gcc 3.4..4.3"

This reverts commit 5b5bdb2638ccd83dfe7127444121907c11769b25.

This breaks the dashboard, revert it to get at least the first commit work
without errors.

diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index 0ab5265..b3fe33f 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 304")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 3.4 at least:
-set(GNU34_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
-set(_cmake_feature_test_c_restrict "${GNU34_C99}")
-set(_cmake_feature_test_c_variadic_macros "${GNU34_C99}")
+# Since 4.4 at least:
+set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
+set(_cmake_feature_test_c_restrict "${GNU44_C99}")
+set(_cmake_feature_test_c_variadic_macros "${GNU44_C99}")
 
 set(GNU_C90 "${_cmake_oldestSupported}")
 set(_cmake_feature_test_c_function_prototypes "${GNU_C90}")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 3f02618..05c3bb2 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -4,12 +4,12 @@ __compiler_gnu(C)
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.5)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c90")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90")
-elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
+elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c89")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu89")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "-std=c99")
   set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99")
 endif()
@@ -22,7 +22,7 @@ elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x")
 endif()
 
-if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
+if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   if (NOT CMAKE_C_COMPILER_FORCED)
 if (NOT CMAKE_C_STANDARD_COMPUTED_DEFAULT)
   message(FATAL_ERROR "CMAKE_C_STANDARD_COMPUTED_DEFAULT should be set for 
${CMAKE_C_COMPILER_ID} (${CMAKE_C_COMPILER}) version 
${CMAKE_C_COMPILER_VERSION}")
@@ -38,9 +38,10 @@ if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   endif()
 endif()
 
+
 macro(cmake_record_c_compile_features)
   set(_result 0)
-  if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
+  if (NOT CMAKE_C_COMPILER

[Cmake-commits] CMake branch, next, updated. v3.7.1-1819-g65aadbe

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  65aadbed2e3361519eec9a32a3250976c0ae04ed (commit)
   via  5b5bdb2638ccd83dfe7127444121907c11769b25 (commit)
   via  674aaf80bda5254cd7c16377f93fda577a06bedc (commit)
   via  9639b2f7e7fadee1c160b915183dc2aa30a0408e (commit)
  from  08f31611996f8c7878f6267bd3698056cb016f61 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65aadbed2e3361519eec9a32a3250976c0ae04ed
commit 65aadbed2e3361519eec9a32a3250976c0ae04ed
Merge: 08f3161 5b5bdb2
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Sat Dec 17 09:01:07 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Dec 17 09:01:07 2016 -0500

Merge topic 'gcc-34-features' into next

5b5bdb26 record features of gcc 3.4..4.3
674aaf80 use cxx_long_long_type instead of cxx_auto_type to check C++ 
compile features
9639b2f7 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b5bdb2638ccd83dfe7127444121907c11769b25
commit 5b5bdb2638ccd83dfe7127444121907c11769b25
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Thu Dec 15 22:54:41 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Sat Dec 17 15:00:54 2016 +0100

record features of gcc 3.4..4.3

This is not entirely complete, i.e. for some features the version they were
introduced in is not set yet. This is just a first test to see what breaks.

DO NOT MERGE YET.

diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 4.4 at least:
-set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
-set(_cmake_feature_test_c_restrict "${GNU44_C99}")
-set(_cmake_feature_test_c_variadic_macros "${GNU44_C99}")
+# Since 3.4 at least:
+set(GNU34_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
+set(_cmake_feature_test_c_restrict "${GNU34_C99}")
+set(_cmake_feature_test_c_variadic_macros "${GNU34_C99}")
 
 set(GNU_C90 "${_cmake_oldestSupported}")
 set(_cmake_feature_test_c_function_prototypes "${GNU_C90}")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 05c3bb2..3f02618 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -4,12 +4,12 @@ __compiler_gnu(C)
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.5)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c90")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90")
-elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c89")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu89")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "-std=c99")
   set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99")
 endif()
@@ -22,7 +22,7 @@ elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x")
 endif()
 
-if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   if (NOT CMAKE_C_COMPILER_FORCED)
 if (NOT CMAKE_C_STANDARD_COMPUTED_DEFAULT)
   message(FATAL_ERROR "CMAKE_C_STANDARD_COMPUTED_DEFAULT should be set for 
${CMAKE_C_COMPILER_ID} (${CMAKE_C_COMPILER}) version 
${CMAKE_C_COMPILER_VERSION}")
@

[Cmake-commits] CMake branch, next, updated. v3.7.1-1815-g08f3161

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  08f31611996f8c7878f6267bd3698056cb016f61 (commit)
   via  d1cdeeedc18387660759f09958b8e47b9162b83a (commit)
  from  9220290194fffec111890c28ff17ff0b79947a5b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08f31611996f8c7878f6267bd3698056cb016f61
commit 08f31611996f8c7878f6267bd3698056cb016f61
Merge: 9220290 d1cdeee
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Sat Dec 17 09:00:32 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Dec 17 09:00:32 2016 -0500

Merge topic 'gcc-34-features' into next

d1cdeeed FIXUP: more auto -> long long test changes


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1cdeeedc18387660759f09958b8e47b9162b83a
commit d1cdeeedc18387660759f09958b8e47b9162b83a
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Sat Dec 17 15:00:05 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Sat Dec 17 15:00:05 2016 +0100

FIXUP: more auto -> long long test changes

diff --git a/Tests/CMakeCommands/target_compile_features/CMakeLists.txt 
b/Tests/CMakeCommands/target_compile_features/CMakeLists.txt
index 8a433cd..7da526a 100644
--- a/Tests/CMakeCommands/target_compile_features/CMakeLists.txt
+++ b/Tests/CMakeCommands/target_compile_features/CMakeLists.txt
@@ -35,11 +35,11 @@ if (CMAKE_CXX_COMPILE_FEATURES)
 PRIVATE cxx_long_long_type
   )
 
-  add_library(lib_auto_type lib_auto_type.cpp)
-  target_compile_features(lib_auto_type
-PUBLIC cxx_auto_type
+  add_library(lib_long_long_type lib_long_long_type.cpp)
+  target_compile_features(lib_long_long_type
+PUBLIC cxx_long_long_type
   )
 
   add_executable(lib_user lib_user.cpp)
-  target_link_libraries(lib_user lib_auto_type)
+  target_link_libraries(lib_user lib_long_long_type)
 endif()
diff --git a/Tests/CMakeCommands/target_compile_features/lib_auto_type.cpp 
b/Tests/CMakeCommands/target_compile_features/lib_auto_type.cpp
deleted file mode 100644
index 71b2215..000
--- a/Tests/CMakeCommands/target_compile_features/lib_auto_type.cpp
+++ /dev/null
@@ -1,6 +0,0 @@
-
-int getAutoTypeImpl()
-{
-  auto i = 0;
-  return i;
-}
diff --git a/Tests/CMakeCommands/target_compile_features/lib_auto_type.h 
b/Tests/CMakeCommands/target_compile_features/lib_auto_type.h
deleted file mode 100644
index c825b10..000
--- a/Tests/CMakeCommands/target_compile_features/lib_auto_type.h
+++ /dev/null
@@ -1,8 +0,0 @@
-
-int getAutoTypeImpl();
-
-int getAutoType()
-{
-  auto i = getAutoTypeImpl();
-  return i;
-}
diff --git a/Tests/CMakeCommands/target_compile_features/lib_long_long_type.cpp 
b/Tests/CMakeCommands/target_compile_features/lib_long_long_type.cpp
new file mode 100644
index 000..4d3a896
--- /dev/null
+++ b/Tests/CMakeCommands/target_compile_features/lib_long_long_type.cpp
@@ -0,0 +1,11 @@
+
+int getLLTypeImpl(long long )
+{
+  int i = 64;
+  while(l) {
+if(l & 1)
+  i--;
+l >>= 1;
+  }
+  return i;
+}
diff --git a/Tests/CMakeCommands/target_compile_features/lib_long_long_type.h 
b/Tests/CMakeCommands/target_compile_features/lib_long_long_type.h
new file mode 100644
index 000..8111382
--- /dev/null
+++ b/Tests/CMakeCommands/target_compile_features/lib_long_long_type.h
@@ -0,0 +1,8 @@
+
+int getLLTypeImpl(long long &);
+
+int getLLType(int i)
+{
+  long long l = i;
+  return getLLTypeImpl(l);
+}
diff --git a/Tests/CMakeCommands/target_compile_features/lib_user.cpp 
b/Tests/CMakeCommands/target_compile_features/lib_user.cpp
index 541e528..8e6f860 100644
--- a/Tests/CMakeCommands/target_compile_features/lib_user.cpp
+++ b/Tests/CMakeCommands/target_compile_features/lib_user.cpp
@@ -1,7 +1,7 @@
 
-#include "lib_auto_type.h"
+#include "lib_long_long_type.h"
 
 int main(int argc, char** argv)
 {
-  return getAutoType();
+  return getLLType(42);
 }
diff --git a/Tests/CompileFeatures/CMakeLists.txt 
b/Tests/CompileFeatures/CMakeLists.txt
index fbd868f..7c5aa88 100644
--- a/Tests/CompileFeatures/CMakeLists.txt
+++ b/Tests/CompileFeatures/CMakeLists.txt
@@ -291,7 +291,7 @@ if (CMAKE_CXX_COMPILE_FEATURES)
 
   add_library(iface INTERFACE)
   set_property(TARGET iface
-PROPERTY INTERFACE_COMPILE_FEATURES "cxx_auto_type"
+PROPERTY INTERFACE_COMPILE_FEATURES "cxx_long_long_type"
   )
   add_executable(IfaceCompileFeatures main.cpp)
   target_link_libraries(IfaceCompileFeatures iface)

---

Summary of changes:
 

[Cmake-commits] CMake branch, next, updated. v3.7.1-1813-g9220290

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  9220290194fffec111890c28ff17ff0b79947a5b (commit)
   via  78b6017c86c7367bf7ef217e026c71435df491e2 (commit)
   via  e9d1ae8c8e19d9a5394311488c319ba7b783 (commit)
  from  b5b7a7107955aaa704230378393745f1dffeddc1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9220290194fffec111890c28ff17ff0b79947a5b
commit 9220290194fffec111890c28ff17ff0b79947a5b
Merge: b5b7a71 78b6017
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 11:17:42 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Dec 16 11:17:42 2016 -0500

Merge topic 'gcc-34-features' into next

78b6017c record features of gcc 3.4..4.3
e9d1ae8c use cxx_long_long_type instead of cxx_auto_type to check C++ 
compile features


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78b6017c86c7367bf7ef217e026c71435df491e2
commit 78b6017c86c7367bf7ef217e026c71435df491e2
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Thu Dec 15 22:54:41 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Fri Dec 16 17:17:31 2016 +0100

record features of gcc 3.4..4.3

This is not entirely complete, i.e. for some features the version they were
introduced in is not set yet. This is just a first test to see what breaks.

DO NOT MERGE YET.

diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 4.4 at least:
-set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
-set(_cmake_feature_test_c_restrict "${GNU44_C99}")
-set(_cmake_feature_test_c_variadic_macros "${GNU44_C99}")
+# Since 3.4 at least:
+set(GNU34_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
+set(_cmake_feature_test_c_restrict "${GNU34_C99}")
+set(_cmake_feature_test_c_variadic_macros "${GNU34_C99}")
 
 set(GNU_C90 "${_cmake_oldestSupported}")
 set(_cmake_feature_test_c_function_prototypes "${GNU_C90}")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 05c3bb2..3f02618 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -4,12 +4,12 @@ __compiler_gnu(C)
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.5)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c90")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90")
-elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c89")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu89")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "-std=c99")
   set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99")
 endif()
@@ -22,7 +22,7 @@ elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x")
 endif()
 
-if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   if (NOT CMAKE_C_COMPILER_FORCED)
 if (NOT CMAKE_C_STANDARD_COMPUTED_DEFAULT)
   message(FATAL_ERROR "CMAKE_C_STANDARD_COMPUTED_DEFAULT should be set for 
${CMAKE_C_COMPILER_ID} (${CMAKE_C_COMPILER}) version 
${CMAKE_C_COMPILER_VERSION}")
@@ -38,10 +38,9 @@ if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   endif()
 endif()
 
-

[Cmake-commits] CMake branch, next, updated. v3.7.1-1810-gb5b7a71

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  b5b7a7107955aaa704230378393745f1dffeddc1 (commit)
   via  682a8d17ce83d04b867e7197cc7e34734d4990f9 (commit)
  from  35ca0a30dcc2048ccac57e1dec7756416abd3468 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b5b7a7107955aaa704230378393745f1dffeddc1
commit b5b7a7107955aaa704230378393745f1dffeddc1
Merge: 35ca0a3 682a8d1
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 11:17:16 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Dec 16 11:17:16 2016 -0500

Merge topic 'gcc-34-features' into next

682a8d17 FIXUP: CompileFeatures tests


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=682a8d17ce83d04b867e7197cc7e34734d4990f9
commit 682a8d17ce83d04b867e7197cc7e34734d4990f9
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 17:16:56 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Fri Dec 16 17:16:56 2016 +0100

FIXUP: CompileFeatures tests

diff --git a/Tests/CMakeCommands/target_compile_features/main.cpp 
b/Tests/CMakeCommands/target_compile_features/main.cpp
index 9ebeefc..aee232a 100644
--- a/Tests/CMakeCommands/target_compile_features/main.cpp
+++ b/Tests/CMakeCommands/target_compile_features/main.cpp
@@ -2,5 +2,5 @@
 int main(int, char**)
 {
   long long i = 1 << 31;
-  return (i << 1) != 0;
+  return (i << 1) == 0;
 }
diff --git a/Tests/CompileFeatures/main.cpp b/Tests/CompileFeatures/main.cpp
index 7abf90f..5472cab 100644
--- a/Tests/CompileFeatures/main.cpp
+++ b/Tests/CompileFeatures/main.cpp
@@ -2,5 +2,5 @@
 int main(int, char**)
 {
   long long value = 1 << 31;
-  return (value << 1) != 0;
+  return (value << 1) == 0;
 }

---

Summary of changes:
 Tests/CMakeCommands/target_compile_features/main.cpp |2 +-
 Tests/CompileFeatures/main.cpp   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.1-1808-g35ca0a3

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  35ca0a30dcc2048ccac57e1dec7756416abd3468 (commit)
   via  d415b3cffa0beec9f7d174400f6850ad68972e28 (commit)
   via  8f2af4b18e340ea50a716199e27e8af27b929aca (commit)
  from  369bfc70d8548baaad751c11d36b88f7c2678f78 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35ca0a30dcc2048ccac57e1dec7756416abd3468
commit 35ca0a30dcc2048ccac57e1dec7756416abd3468
Merge: 369bfc7 d415b3c
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 10:58:55 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Dec 16 10:58:55 2016 -0500

Merge topic 'gcc-34-features' into next

d415b3cf record features of gcc 3.4..4.3
8f2af4b1 use cxx_long_long_type instead of cxx_auto_type to check C++ 
compile features


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d415b3cffa0beec9f7d174400f6850ad68972e28
commit d415b3cffa0beec9f7d174400f6850ad68972e28
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Thu Dec 15 22:54:41 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Fri Dec 16 16:58:25 2016 +0100

record features of gcc 3.4..4.3

This is not entirely complete, i.e. for some features the version they were
introduced in is not set yet. This is just a first test to see what breaks.

DO NOT MERGE YET.

diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 4.4 at least:
-set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
-set(_cmake_feature_test_c_restrict "${GNU44_C99}")
-set(_cmake_feature_test_c_variadic_macros "${GNU44_C99}")
+# Since 3.4 at least:
+set(GNU34_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
+set(_cmake_feature_test_c_restrict "${GNU34_C99}")
+set(_cmake_feature_test_c_variadic_macros "${GNU34_C99}")
 
 set(GNU_C90 "${_cmake_oldestSupported}")
 set(_cmake_feature_test_c_function_prototypes "${GNU_C90}")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 05c3bb2..3f02618 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -4,12 +4,12 @@ __compiler_gnu(C)
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.5)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c90")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90")
-elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c89")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu89")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "-std=c99")
   set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99")
 endif()
@@ -22,7 +22,7 @@ elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x")
 endif()
 
-if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   if (NOT CMAKE_C_COMPILER_FORCED)
 if (NOT CMAKE_C_STANDARD_COMPUTED_DEFAULT)
   message(FATAL_ERROR "CMAKE_C_STANDARD_COMPUTED_DEFAULT should be set for 
${CMAKE_C_COMPILER_ID} (${CMAKE_C_COMPILER}) version 
${CMAKE_C_COMPILER_VERSION}")
@@ -38,10 +38,9 @@ if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   endif()
 endif()
 
-

[Cmake-commits] CMake branch, next, updated. v3.7.1-1805-g369bfc7

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  369bfc70d8548baaad751c11d36b88f7c2678f78 (commit)
   via  b59ed27ea731244fad7276182467b1076704a10a (commit)
   via  6bb3ebd485cd92c3c9760432dd4db716ec831723 (commit)
  from  8c6f5311aea01e3d8dd597c6f5c847bb55420471 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=369bfc70d8548baaad751c11d36b88f7c2678f78
commit 369bfc70d8548baaad751c11d36b88f7c2678f78
Merge: 8c6f531 b59ed27
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 10:58:01 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Dec 16 10:58:01 2016 -0500

Merge topic 'gcc-34-features' into next

b59ed27e use cxx_long_long_type instead of cxx_auto_type to check C++ 
compile features
6bb3ebd4 FIXUP: gcc 3.4 features


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b59ed27ea731244fad7276182467b1076704a10a
commit b59ed27ea731244fad7276182467b1076704a10a
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 16:53:39 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Fri Dec 16 16:57:15 2016 +0100

use cxx_long_long_type instead of cxx_auto_type to check C++ compile 
features

Older gcc versions do not support auto, but already have some C++11 features
available as extension.

diff --git a/Tests/CMakeCommands/target_compile_features/CMakeLists.txt 
b/Tests/CMakeCommands/target_compile_features/CMakeLists.txt
index 9b35f27..8a433cd 100644
--- a/Tests/CMakeCommands/target_compile_features/CMakeLists.txt
+++ b/Tests/CMakeCommands/target_compile_features/CMakeLists.txt
@@ -32,7 +32,7 @@ if (CMAKE_CXX_COMPILE_FEATURES)
   endif()
   add_executable(target_compile_features${target_suffix} main.cpp)
   target_compile_features(target_compile_features${target_suffix}
-PRIVATE cxx_auto_type
+PRIVATE cxx_long_long_type
   )
 
   add_library(lib_auto_type lib_auto_type.cpp)
diff --git a/Tests/CMakeCommands/target_compile_features/main.cpp 
b/Tests/CMakeCommands/target_compile_features/main.cpp
index 6f5daee..9ebeefc 100644
--- a/Tests/CMakeCommands/target_compile_features/main.cpp
+++ b/Tests/CMakeCommands/target_compile_features/main.cpp
@@ -1,6 +1,6 @@
 
 int main(int, char**)
 {
-  auto i = 0;
-  return i;
+  long long i = 1 << 31;
+  return (i << 1) != 0;
 }
diff --git a/Tests/CompileFeatures/CMakeLists.txt 
b/Tests/CompileFeatures/CMakeLists.txt
index 0405def..fbd868f 100644
--- a/Tests/CompileFeatures/CMakeLists.txt
+++ b/Tests/CompileFeatures/CMakeLists.txt
@@ -278,7 +278,7 @@ if (CMAKE_CXX_COMPILE_FEATURES)
 
   add_executable(CompileFeatures main.cpp)
   set_property(TARGET CompileFeatures
-PROPERTY COMPILE_FEATURES "cxx_auto_type"
+PROPERTY COMPILE_FEATURES "cxx_long_long_type"
   )
   set_property(TARGET CompileFeatures
 PROPERTY CXX_STANDARD_REQUIRED TRUE
diff --git a/Tests/CompileFeatures/main.cpp b/Tests/CompileFeatures/main.cpp
index c5a7a46..7abf90f 100644
--- a/Tests/CompileFeatures/main.cpp
+++ b/Tests/CompileFeatures/main.cpp
@@ -1,6 +1,6 @@
 
 int main(int, char**)
 {
-  auto value = 0;
-  return value;
+  long long value = 1 << 31;
+  return (value << 1) != 0;
 }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6bb3ebd485cd92c3c9760432dd4db716ec831723
commit 6bb3ebd485cd92c3c9760432dd4db716ec831723
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Fri Dec 16 16:50:45 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Fri Dec 16 16:57:15 2016 +0100

FIXUP: gcc 3.4 features

diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 48442dd..3f02618 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -4,7 +4,7 @@ __compiler_gnu(C)
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.5)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c90")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90")
-elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c89")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu89")
 endif()
@@ -38,7 +38,6 @@ if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   endif()
 endif()
 
-
 macro(cmake_record_c_compile_features)
   set(_result 0)
   if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)

---

Summary of changes:
 Modules/Compiler/GNU-C.cmake  

[Cmake-commits] CMake branch, next, updated. v3.7.1-1788-g52a9fd5

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  52a9fd5a28163f02091b81d343ac897df5f6fc37 (commit)
   via  30ef584bd16398ed4736175c965872172107d92a (commit)
  from  048f528573587cb310456dc8b28833bc44cbe6d1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52a9fd5a28163f02091b81d343ac897df5f6fc37
commit 52a9fd5a28163f02091b81d343ac897df5f6fc37
Merge: 048f528 30ef584
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Thu Dec 15 16:55:58 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Dec 15 16:55:58 2016 -0500

Merge topic 'gcc-34-features' into next

30ef584b record features of gcc 3.4..4.3


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=30ef584bd16398ed4736175c965872172107d92a
commit 30ef584bd16398ed4736175c965872172107d92a
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Thu Dec 15 22:54:41 2016 +0100
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Thu Dec 15 22:54:41 2016 +0100

record features of gcc 3.4..4.3

This is not entirely complete, i.e. for some features the version they were
introduced in is not set yet. This is just a first test to see what breaks.

DO NOT MERGE YET.

diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..0ab5265 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,5 +1,5 @@
 
-set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
+set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304")
 
 # GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
 # to 201000L.  As the former is strictly greater than the latter, test only
@@ -8,10 +8,10 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) 
>= 404")
 # to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
 set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
-# Since 4.4 at least:
-set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
-set(_cmake_feature_test_c_restrict "${GNU44_C99}")
-set(_cmake_feature_test_c_variadic_macros "${GNU44_C99}")
+# Since 3.4 at least:
+set(GNU34_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 304 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
+set(_cmake_feature_test_c_restrict "${GNU34_C99}")
+set(_cmake_feature_test_c_variadic_macros "${GNU34_C99}")
 
 set(GNU_C90 "${_cmake_oldestSupported}")
 set(_cmake_feature_test_c_function_prototypes "${GNU_C90}")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 05c3bb2..48442dd 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -9,7 +9,7 @@ elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu89")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "-std=c99")
   set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99")
 endif()
@@ -22,7 +22,7 @@ elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x")
 endif()
 
-if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
   if (NOT CMAKE_C_COMPILER_FORCED)
 if (NOT CMAKE_C_STANDARD_COMPUTED_DEFAULT)
   message(FATAL_ERROR "CMAKE_C_STANDARD_COMPUTED_DEFAULT should be set for 
${CMAKE_C_COMPILER_ID} (${CMAKE_C_COMPILER}) version 
${CMAKE_C_COMPILER_VERSION}")
@@ -41,7 +41,7 @@ endif()
 
 macro(cmake_record_c_compile_features)
   set(_result 0)
-  if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
+  if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
 if(_result EQUAL 0 AND CMAKE_C11_STANDARD_COMPILE_OPTION)
   _record_compiler_features_c(11)
 endif()
diff --git a/Modules/Compiler/GNU-CXX-FeatureTests.cmake 
b/Modules/Compiler/GNU-CXX-FeatureTests.cmake
index d18adaf..003 100644
--- a/Modules/Compiler/GNU-CXX-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-CXX-FeatureTests.cmake
@@ -2,7 +2,7 @@
 # Reference

Re: [cmake-developers] Tag signature with expired key

[Rolf Eike Beer]

Am Montag, 12. Dezember 2016, 17:26:08 schrieb Alan W. Irwin:
> Hi Brad:
> 
> I attempted to verify a recent tag on the release branch with the
> following results:
> 
> software@raven> git tag --verify v3.7.1
> object db3499df5d06ab2cacc61e9f7720a33456aeafe4
> type commit
> tag v3.7.1
> tagger Brad King  1480522722 -0500
> 
> CMake 3.7.1
> gpg: Signature made Wed 30 Nov 2016 08:18:42 AM PST using RSA key ID
> 34921684 gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "Brad King"
> gpg: aka "Brad King "
> gpg: aka "[jpeg image of size 4005]"
> gpg: Note: This key has expired!
> Primary key fingerprint: CBA2 3971 357C 2E65 90D9  EFD3 EC8F EF3A 7BFB 4EDA
>   Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5  13D0 2D2C EF10 3492 1684
> error: could not verify the tag 'v3.7.1'
> software@raven> echo $?
> 1
> 
> I assume that error in an otherwise good tag signature is due to the
> fact your key has expired, but I thought it was impossible to sign
> with an expired key?  Anyhow, I thought I should bring this signing by
> an expired key to your attention in case there is something going on
> here that you are not aware of.

Speculation: the key was renewed locally, but those things have not been 
uploaded to the keyservers.

Eikek

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

Re: [CMake] Problem with ACME_Climate project on my.cdash.org

[Rolf Eike Beer]

Am Freitag, 18. November 2016, 17:34:28 schrieb Burgess, Wade:
> To whom it may concern,
> 
> Firstly, if this is not the way I should seek assistance from Kitware,
> please help me learn the correct way to do so.
 
> Secondly, the ACME_Climate project on my.cdash.org is experiencing a problem
> with the graphical reflection of a machine that reported.  See below.  The
> second row, melvin, reported to the dashboard 11 hours ago, but three of
> the cells in the row (the Test columns of Not Run, Fail, & Pass” are not
> reflected; they are white instead of red, yellow, or green.
 
> Please help us resolve this problem.

This often happens if the submission was incomplete, e.g. if there was  
timeout submitting the last 3 xml files.

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

Re: [cmake-developers] cmake 3.7.0-rc3 regression

[Rolf Eike Beer]

Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet:
> Hi,
> 
> After trying to upgrade to CMake 3.7.0-rc3, we've found the following
> regression:
> 
> Previously, we were able to put multiple platform CMake executables in the
> same root by just renaming the "bin" folder, so that they don't overlap
> each other, as such:
> 
> cmake/win/cmake.exe
> cmake/mac/cmake
> cmake/linux/cmake
> cmake/share/...
> cmake/doc/...
> 
> However in 3.7.0-rc3 this is broken, no longer works if the CMake binary
> folder isn't named specifically "bin". CMake will fail to start, reporting
> "CMake Error: Could not find CMAKE_ROOT !!!".
> 
> Traced it back to this commit:
> 
> Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
> 
> Add option to control 'bin' directory of CMake's own installation
> (#16076)
> 
> Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
> Add a `--bindir` option to the `bootstrap` script to set it.
> 
> If this wasn't intentional, can we get a fix before 3.7.0 is released?

If you read the commit message you should be able to fix your problem: just 
build the different CMake instances with different --bindir switches.

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

Re: [cmake-developers] [FindPostgreSQL] Search for version 9.6

[Rolf Eike Beer]

Am Sonntag, 18. September 2016, 12:21:10 schrieb Tamar Kranenburg:
> Hi all,
> 
> PostgreSQL 9.6 will be released this quarter. The first patch corrects a
> comment, the second patch adds version 9.6 to the search suffixes of the
> FindPostgreSQL module.

Merged to next here:

 
https://cmake.org/gitweb?p=cmake.git;a=commit;h=0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20

Greetings,

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

[Cmake-commits] CMake branch, next, updated. v3.6.2-2182-g0c1355f

[Rolf Eike Beer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20 (commit)
   via  8dac3af03c0685d61ff10e1d1adc4bbf6d096966 (commit)
   via  84039a6aa2b1bbc606dbb8bbccf956296a2c153b (commit)
  from  1366ab7171a995f35de6f1a91a80515057428730 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20
commit 0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20
Merge: 1366ab7 8dac3af
Author: Rolf Eike Beer <e...@sf-mail.de>
AuthorDate: Sun Sep 18 10:40:02 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Sep 18 10:40:02 2016 -0400

Merge topic 'postgresql-96' into next

8dac3af0 FindPostgreSQL: Search for version 9.6
84039a6a FindPostgreSQL: Correct comment about known postgres versions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8dac3af03c0685d61ff10e1d1adc4bbf6d096966
commit 8dac3af03c0685d61ff10e1d1adc4bbf6d096966
Author: Tamar Kranenburg <i...@takar.nl>
AuthorDate: Sun Sep 18 12:11:58 2016 +0200
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Sun Sep 18 16:39:18 2016 +0200

FindPostgreSQL: Search for version 9.6

diff --git a/Modules/FindPostgreSQL.cmake b/Modules/FindPostgreSQL.cmake
index b92f785..84fa541 100644
--- a/Modules/FindPostgreSQL.cmake
+++ b/Modules/FindPostgreSQL.cmake
@@ -37,7 +37,7 @@
 # In Windows the default installation of PostgreSQL uses that as part of the 
path.
 # E.g C:\Program Files\PostgreSQL\8.4.
 # Currently, the following version numbers are known to this module:
-# "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" "8.1" "8.0"
+# "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" "8.1" "8.0"
 #
 # To use this variable just do something like this:
 # set(PostgreSQL_ADDITIONAL_VERSIONS "9.2" "8.4.4")
@@ -81,7 +81,7 @@ set(PostgreSQL_ROOT_DIR_MESSAGE "Set the PostgreSQL_ROOT 
system variable to wher
 
 
 set(PostgreSQL_KNOWN_VERSIONS ${PostgreSQL_ADDITIONAL_VERSIONS}
-"9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" "8.1" "8.0")
+"9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" "8.1" "8.0")
 
 # Define additional search paths for root directories.
 set( PostgreSQL_ROOT_DIRECTORIES

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84039a6aa2b1bbc606dbb8bbccf956296a2c153b
commit 84039a6aa2b1bbc606dbb8bbccf956296a2c153b
Author: Tamar Kranenburg <i...@takar.nl>
AuthorDate: Sun Sep 18 12:10:50 2016 +0200
Commit: Rolf Eike Beer <e...@sf-mail.de>
CommitDate: Sun Sep 18 16:39:18 2016 +0200

FindPostgreSQL: Correct comment about known postgres versions

diff --git a/Modules/FindPostgreSQL.cmake b/Modules/FindPostgreSQL.cmake
index 32a3f0a..b92f785 100644
--- a/Modules/FindPostgreSQL.cmake
+++ b/Modules/FindPostgreSQL.cmake
@@ -37,7 +37,7 @@
 # In Windows the default installation of PostgreSQL uses that as part of the 
path.
 # E.g C:\Program Files\PostgreSQL\8.4.
 # Currently, the following version numbers are known to this module:
-# "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" "8.1" "8.0"
+# "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" "8.1" "8.0"
 #
 # To use this variable just do something like this:
 # set(PostgreSQL_ADDITIONAL_VERSIONS "9.2" "8.4.4")

---

Summary of changes:
 Modules/FindPostgreSQL.cmake |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] using arm toolchain and having issues with linux socket can

[Rolf Eike Beer]

> Doesn't seem ideal, but I tried it.  I got past that part, and now on to
> something I have seen before:
 
> [ 68%] Linking CXX executable enterprise
> arm-none-linux-gnueabi-g++: CMakeFiles/enterprise.dir/..o: No such file or
> directory
 
> What does that mean?

That you probably have something fishy in your list of source files or so, like 
"..c" or something like that.

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

Re: [CMake] using arm toolchain and having issues with linux socket can

[Rolf Eike Beer]

Am Freitag, 16. September 2016, 22:54:25 schrieb Gunter, Walter E:
> Ah..got ya. 
> There are two in my toolchain:
> Sys/socket.h
> Linux/socket.h
> 
> I couldn't find AF_CAN or PF_CAN defined in the sys one, but it is in the
> linux.
 I included it, but still getting the error when building that it
> can't find it. 

I already told you it's sys/socket.h. In fact it's bits/socket.h, but the 
bits/* stuff should never be included directly. But it is included in 
sys/socket.h, so just use this.

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

Re: [CMake] using arm toolchain and having issues with linux socket can

[Rolf Eike Beer]

Am Freitag, 16. September 2016, 22:13:14 schrieb Gunter, Walter E:
> So, now that I am rocking and rolling using the correct toolchain, I am
> stuck with a failed compile.
 
> error: 'PF_CAN' was not declared in this scope
> 
> Does this mean it can’t find the header file?  I am just implementing the
> CAN interface; nothing complex.

If it would not find linux/can.h it would tell you. It does not find the 
define, 
which means it actually can include linux/can.h. And this makes sense, as 
PF_CAN is in indirectly in sys/socket.h, so you should (also) include that.

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

Re: [CMake] is it worth using cmake to cross-compile for embedded arm device?

[Rolf Eike Beer]

Gunter, Walter E wrote:
> I am having some troubles getting cmake setup and wonder if cmake is the
> right tool.
> Thoughts? Suggestions?

Yes, it is. I do it basically every day. Read my advise and properly set up a 
toolchain file, that is very likely the missing magic.

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

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

Re: [CMake] cross-compiling for arm

[Rolf Eike Beer]

Gunter, Walter E wrote:
> I setup the Main CMakeLists.txt to cross_compile using an arm toolchain:
> 
> cmake_minimum_required(VERSION 3.2)
> 
> project(enterprise CXX)
> 
> set(CMAKE_SYSTEM_NAME Linux)
> set(CMAKE_CXX_COMPILER
> /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++)
> set(CMAKE_SYSTEM_PROCESSOR arm)
> 
> set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)
> set(CMAKE_FIND_ROOT_PATH /mnt/root)
> 
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> 
> set(COMPILE_FLAGS "-lrt -Wall -lpthread")
> 
> find_package(Threads)
> 
> add_subdirectory(src)
> 
> if(CMAKE_CROSSCOMPILING)
>  message("I should be cross compiling: ")
> endif()
> 
> #find_package(GTest REQUIRED)
> 
> 
> 
> I made some changes to my cmakelists.txt in my src file :
> 
> set(SOURCES  ${CMAKE_CURRENT_SOURCE_DIR}
> *list of files*.cpp
> Mainfile.cpp
> Mycan.cpp   #this one references the linux/can.h
> )
> 
> include_directories("../includes")
> set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)

This is not needed, CMake will automatically detect this.

> add_executable(enterprise ${SOURCES})
> target_link_libraries(enterprise  ${CMAKE_THREAD_LIBS_INIT} pthread)

pthread is not needed here. If CMAKE_THREAD_LIBS_INIT is empty you probably 
have a problem already. Also you should do

set(CMAKE_THREAD_PREFER_PTHREAD TRUE)

before find_package(Threads), and ideally

target_link_libraries(enterprise Threads::Threads)

afterwards, as this will also add the -pthread flag to compilation.

I still doubt that you properly use a toolchain file (i.e. "cmake -D 
CMAKE_TOOLCHAIN_FILE=my_arm_stuff.cmake …" in a clean build dir).

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

Re: [CMake] cross-compiling for arm

[Rolf Eike Beer]

Am Donnerstag, 15. September 2016, 15:48:02 schrieb Gunter, Walter E:
> I am using the arm-2008q3 toolchain and having some issues with compiling.
> Doing a c++ compile for RT Linux,
> I have setup the following in my main CMakeLists.txt

Use a toolchain file. project() will scan for the compiler and do all sorts of 
setup code, you can never be sure to override enough afterwards. In fact, you 
probably can't.

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

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