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

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

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

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

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

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Rolf Eike Beer]

Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott:
> Cheeky way to get me more involved in contributing, but okay, I'll bite. ;)
> Switching discussion to the dev list.
> 
> So how would you want the feature to work? I'd suggest an initial set of
> requirements something like the following:
> 
>- Need to support the ability to define multiple setup and/or tear down
>tasks.
>- It should be possible to specify dependencies between setup tasks and
>between tear down tasks.
>- Individual tests need to be able to indicate which setup and/or tear
>down tasks they require, similar to the way DEPENDS is used to specify
>dependencies between test cases.
>- When using ctest --rerun-failed, ctest should automatically invoke any
>setup or tear down tasks required by the test cases that will be re-run.
>- Setup or tear down tasks which reference executable targets should
>substitute the actual built executable just like how add_custom_command()
> does.

-need a way to mark if 2 tests with the same setup/teardown can share those or 
if they need to run for every of them
-the default for each test is "no s/t", which means it can't be run with any 
of the above in parallel (especially for compatibillity)[1]
-need a way to tell if a test doesn't care about those

1) think of a database connector test: the test that will check what happens 
if no DB is present will fail if the setup step "start DB" was run, but not 
the teardown

> Some open questions:
> 
>- Should setup and tear down tasks be defined in pairs, or should they
>completely independent (this would still require the ability to specify a
> dependency of a tear down task on a setup task)?

The test could be "shutdown daemon" or "delete files" so I would keep them 
separated. They may be created by the same command, so they could be batched 
anyway.

>- Should the setup and tear down tasks be defined by a new CTest/CMake
>command or extend an existing mechanism (e.g. add_custom_command())?

Don't clutter existing commands more than needed. If it's something new, then 
create a new command (they could still share C++ code). If it's basically the 
same as anything existing at the end then use that.

>- If no test case has a dependency on a setup or tear down task, should
>that task be skipped? Perhaps tasks need to have a flag which indicates
>whether they always run or only if a test case depends on it.

Keep backward compatibility. I.e. if I now add a new test with s/t, then every 
other test should still run (and succeed) as before.

>- What terminology to use? Things like GoogleTest use terms like test
>*fixtures* for this sort of thing. The terms setup and tear down are a
>bit imprecise and cumbersome, so we would probably need something better
>than those.
>- Would it make sense for the ctest command line to support disabling
>setup and/or tear down steps? I can see some potential scenarios where
> this may be desirable, but maybe this is getting too ambitious for a
> starting set of requirements.

IMHO that doesn't make sense. One could think about an option to disable the 
s/t merging, i.e. that they are really called alone for every test.

>- What should happen if a setup or tear down task fails? How would
>failure be detected? How would such failures impact things like a CDash
>test report, etc.?

Then the test fails, just the same as it now does when it can't find the 
executable.

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] FindOpenSSL: Link libraries needed for static OpenSSL.

[Rolf Eike Beer]

Am 2016-08-17 14:53, schrieb Brad King:

On 08/16/2016 04:44 PM, Alexander Lamaison wrote:
I've attached a new patch without the changes to the singular-named 
variables.


Thanks.


+if(WIN32 AND NOT CYGWIN)
+  set_target_properties(OpenSSL::Crypto PROPERTIES
+INTERFACE_LINK_LIBRARIES crypt32)
+else()
+  set_target_properties(OpenSSL::Crypto PROPERTIES
+INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
+endif()


The addition of crypt32/dl is done with this logic in several places.
Instead please use a _OPENSSL_LIBRARY_DEPENDS variable to hold the
value and then reference it in the other locations so that the
conditions for setting it do not have to be duplicated.


Don't forget to unset() the variable at the end of the module.

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

Re: [cmake-developers] [patch] Document -H and -B

[Rolf Eike Beer]

Am Donnerstag, 30. Juni 2016, 23:54:42 schrieb Ruslan Baratov via cmake-
developers:
> On 30-Jun-16 23:40, Brad King wrote:
> > On 06/30/2016 04:28 PM, Ruslan Baratov wrote:
> >> On 30-Jun-16 23:18, Brad King wrote:
> >>> On 06/30/2016 03:56 PM, Ruslan Baratov wrote:
>  What is the public-use way to specify source-tree and build-tree by
>  cmake options simultaneously?
> >>> 
> >>> cd $build && cmake $src
> >> 
> >> Will not work if $build not exists.
> > 
> > mkdir -p "$build" && cd "$build" && cmake "$src"
> 
> Next issue is that this command change directory, how can I move back to
> the directory where I was working on?

pushd/popd or do the cd/cmake call in a subshell.

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] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master

[Rolf Eike Beer]

Am 2016-06-29 09:35, schrieb Tobias Hunger:

Hello Brad,

I currently get more than 2000 warnings when building cmake master, all 
about

missing overrides.

Could you please take the fix warning patch from
https://github.com/hunger/CMake/commits/for-upstream and apply it to 
master?

That fixes all those pesky override warnings.


This should be CM_OVERRIDE.

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] daemon-mode meeting last Tuesday

[Rolf Eike Beer]

>   1.1 Communication:
>   
>   * Clients should talk to daemon mode via a socket (libuv supports that), 
> but we also want to support stdin/stdout at least for a "debug mode" *
> There should be a separate command line switch to start stdin/out mode and
> for socket mode
>  * This is needed before it makes sense to merge the patch set.

What about just passing --server-fd= into it? That way the client can set 
up whatever if wants to pass there and CMake has nothing to do with any setup. 
And if one really wants to get messy one could pass a tty there.

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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Rolf Eike Beer]

Ben Boeckel wrote:
> Hi,
> 
> Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
> for that. However, it is hidden behind the check that pkg_check_modules
> uses to see if it already ran:
> 
> if (NOT DEFINED __pkg_config_checked_${_prefix} OR
> __pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR
> NOT ${_prefix}_FOUND)
> 
> which means that on the second configure, the target is not created
> causing build faiures. Could you please look at reordering the logic so
> that the imported target is always created (if requested)? Thanks.
> 
> Brad, this is in the rc releases; what should be done? Block the
> release, undocument the feature, or wait for a patch?

Please check if 
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3213b747a84a4e584e9edc6bd8c114b809b18bec
 
fixes it for you.

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] FindFreetype patch for Windows debug lib naming

[Rolf Eike Beer]

Am Freitag, 17. Juni 2016, 13:02:30 schrieb Stuart Mentzer:
> On 6/17/2016 11:54 AM, Brad King wrote:
> On 06/12/2016 01:52 PM, Stuart Mentzer wrote:
> Looking at FindZlib.cmake I think the attached should be OK
> Thanks.  I've applied that as a patch here:
> 
>  FindFreetype: Find release and debug libraries separately
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6
> 
> -Brad
> Thanks but a line was lost in translation at the bottom:
> 
> mark_as_advanced(
>   FREETYPE_LIBRARY
>   FREETYPE_INCLUDE_DIR_freetype2
>   FREETYPE_INCLUDE_DIR_ft2build
> )
> 
> SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables but I
> assume we still need the base variable handled in FindFreetype.
> 
> With that fix, if Eike is OK with this then it is done.

No, this is actually correct. The things marked as advanced are cache 
variables. FREETYPE_LIBRARY is computed dynamically. The "advanced" thing is 
to hide these in the default view of cmake-gui.

If Brad says the change of what is cached is ok I'm entirely fine with it.

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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Rolf Eike Beer]

Am 2016-06-17 15:36, schrieb Ben Boeckel:

Hi,

Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
for that. However, it is hidden behind the check that pkg_check_modules
uses to see if it already ran:

if (NOT DEFINED __pkg_config_checked_${_prefix} OR
__pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR
NOT ${_prefix}_FOUND)

which means that on the second configure, the target is not created
causing build faiures. Could you please look at reordering the logic so
that the imported target is always created (if requested)? Thanks.

Brad, this is in the rc releases; what should be done? Block the
release, undocument the feature, or wait for a patch?


I also have another todo for FindFreetype open which I must handle. I'll 
do both over the weekend.


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

Re: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase

[Rolf Eike Beer]

Am 2016-06-16 13:37, schrieb mail6543210--- via cmake-developers:

Hi there,

Here're two trivial patches for testing of CPack/DEB.

One is for building cmake on SELinux-enabled system, and other is for a
typo in the same file form the former one.

These patches is based on commit 83ae7944

First patch:

When building cmake on an SELinux-enabled system, there will be an 
extra

dot at the end of permission field of `ls -l` like this:
-rwxrwxrwx.
  ^ this dot
This makes the testing RunCMake.CPack_DEB fail.

This patch add an optional dot in the regex to fix it.


If it is exactly a dot and not "some random character", than you need to 
escape that in the regular expression as dot is the wildcard character 
there.


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

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

[Rolf Eike Beer]

Am Freitag, 10. Juni 2016, 09:03:13 schrieb Brad King:
> On 06/10/2016 03:19 AM, Stuart Mentzer wrote:
> > On 6/10/2016 2:45 AM, Rolf Eike Beer wrote:
> >> I'm sure I also wrote "you probably need to set/unset
> >> FREETYPE_LIBRARY_RELEASE around SLC so it still works",
> >> The point here is that you can't change the variable name
> >> that is used in find_library() as it would break compatibility.
> > 
> > Is there someone who can just do what is needed and let us be done with
> > this?
> Eike, IIRC what we've done for other modules is change the cache
> entries to use ${pkg}_LIBRARY_{RELEASE,DEBUG} and then provided
> compatibility with scripts that explicitly set ${pkg}_LIBRARY
> by using the value if set and skipping the search.  See FindZLIB
> for an example of this.

I'll hack something together, but that might take a day or two.

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] FindFreetype patch for Windows debug lib naming

[Rolf Eike Beer]

Am 2016-06-09 15:00, schrieb Brad King:

On 06/08/2016 12:33 AM, Stuart Mentzer wrote:

Here is a little patch that lets FindFreetype find the debug
library on Windows, where it is named with a d suffix.


Thanks.  I split the patch into two and applied:

 FindFreetype: Factor out common find command arguments
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245

 FindFreetype: Search for a separate debug library
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855


This will probably not work: SLC will look for FREETYPE_LIBRARY_RELEASE, 
which is never set. So you will have to


set(FREETYPE_LIBRARY_RELEASE ${FREETYPE_LIBRARY})
SLC()
unset(FREETYPE_LIBRARY_RELEASE)

or something like that.

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

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

[Rolf Eike Beer]

Am Mittwoch, 8. Juni 2016, 12:24:29 schrieb Brad King:
> On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote:
> > the : is obviously the default for noop which is correct for
> > Linux but not for Windows. My CMakeCache has the following entry:
> > //noop for ranlib
> 
> > CMAKE_RANLIB:INTERNAL=:
> I see that here:
> 
>  
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeFindBinUtils.cma
> ke;hb=v3.5.2#l55
> 
>   if(NOT CMAKE_RANLIB)
> set(CMAKE_RANLIB : CACHE INTERNAL "noop for ranlib")
>   endif()
> 
> Here is a fix:
> 
>  Run ranlib on archives only if the tool is available
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671

Shouldn't the first check also be "cmd == ":" instead of only checking the 
first 
byte?

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

[Rolf Eike Beer]

Am Freitag, 13. Mai 2016, 13:38:52 schrieb Brad King:
> On 05/13/2016 12:21 PM, Rolf Eike Beer wrote:
> >> Can you just use
> >> 
> >>   set_property(TARGET PkgConfig::${_prefix} PROPERTY ...)
> >> 
> >> in each `if()` block?
> > 
> > I had this before, but I thought I avoid multiple target lookups. You
> > should only ever see that message if none of the branches is taken I
> > think. And that should never happen, or the if before is wrong. Can you
> > add a message() and show what is actually in _props there?
> 
> The problem is that _libs has more than one value, so set_target_properties
> ends up with
> 
>   PROPERTIES PROP1 v1 PROP2 v2a v2b PROP3 v3
> ^^^
> 
> Please use set_property(TARGET).  It is much more robust, and this is not
> exactly a performance-critical loop.

Hopefully all better now.

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

[Rolf Eike Beer]

Am Freitag, 13. Mai 2016, 11:16:28 schrieb Brad King:
> On 05/13/2016 11:02 AM, Rolf Eike Beer wrote:
> > Should all be done now.
> 
> Thanks.
> 
> The test fails for me with
> 
> CMake Error at /.../Modules/FindPkgConfig.cmake:239
> (set_target_properties): set_target_properties called with incorrect number
> of arguments.
> At least part of the problem is here:
> > +if(${_prefix}_INCLUDE_DIRS)
> > +  list(APPEND _props INTERFACE_INCLUDE_DIRECTORIES
> > "${${_prefix}_INCLUDE_DIRS}") +endif()
> > +if(_libs)
> > +  list(APPEND _props INTERFACE_LINK_LIBRARIES "${_libs}")
> > +endif()
> > +if(${_prefix}_CFLAGS_OTHER)
> > +  list(APPEND _props INTERFACE_COMPILE_OPTIONS
> > "${${_prefix}_CFLAGS_OTHER}") +endif()
> > +set_target_properties(PkgConfig::${_prefix} PROPERTIES ${_props})
> 
> If any of the property values is empty the `${_props}` will
> remove it from the argument list to set_target_properties.
> Can you just use
> 
>   set_property(TARGET PkgConfig::${_prefix} PROPERTY ...)
> 
> in each `if()` block?

I had this before, but I thought I avoid multiple target lookups. You should 
only ever see that message if none of the branches is taken I think. And that 
should never happen, or the if before is wrong. Can you add a message() and 
show what is actually in _props there?

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

[Rolf Eike Beer]

Am Donnerstag, 12. Mai 2016, 13:17:42 schrieb Brad King:
> On 05/12/2016 12:48 PM, Rolf Eike Beer wrote:
> > Good point. I have changed this accordingly and pushed it to next. There
> > are no tests yet, so maybe not immediately merge it to next but wait for
> > the weekend or so.
> 
> Okay, thanks.  Please also add a Help/release/dev/FindPkgConfig-targets.rst
> file with a release note for the feature.

Should all be done now.

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

[Rolf Eike Beer]

Am Donnerstag, 12. Mai 2016, 09:53:06 schrieb Brad King:
> On 05/12/2016 09:34 AM, Rolf Eike Beer wrote:
> > find_library(${_prefix}-${CMAKE_MATCH_1}
> > 
> >   NAMES ${CMAKE_MATCH_1}
> >   ${_find_opts})
> > 
> > list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")
> 
> Generally I try to store the CMAKE_MATCH_ values in other variables
> as soon as possible and then use those other variables.  Otherwise
> refactoring may cause their values to change and break existing logic.

Good point. I have changed this accordingly and pushed it to next. There are 
no tests yet, so maybe not immediately merge it to next but wait for the 
weekend or so.

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

[Rolf Eike Beer]

Am 2016-05-12 14:59, schrieb Brad King:

On 05/11/2016 05:52 PM, Rolf Eike Beer wrote:
It has always nagged me that the FindPkgConfig module requires people 
to use
link_directories(). Now I created a new optional mode for 
pkg_check_modules()
and pkg_search_modules() which will search the absolute paths of the 
libraries
that are returned by pkg-config, and create an imported target from 
that
information that also contains defines and include directories. It 
restricts
searching to the directories returned by pkg-config, if none are given 
the
normal search rules are used. I have manually tested this and it seems 
to
work. Please have a look and tell me if I have missed something before 
I put

this into next.


Great!  I've long wanted to see this done.


+if (flag MATCHES "^-l(.*)")
+  set(_pkg_search "${CMAKE_MATCH_1}")
+else()
+  continue()
+endif()
+
+find_library(${_prefix}-${CMAKE_MATCH_1}
+ NAMES ${CMAKE_MATCH_1}
+ ${_find_opts})
+list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")


Shouldn't these latter ${CMAKE_MATCH_1} references use ${_pkg_search} 
instead?


The whole _pkg_search thing can go away, it's from an earlier version of 
the patch. This should work the same:


if (NOT flag MATCHES "^-l(.*)")
  continue()
endif()

find_library(${_prefix}-${CMAKE_MATCH_1}
 NAMES ${CMAKE_MATCH_1}
 ${_find_opts})
list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")

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

[cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

[Rolf Eike Beer]

It has always nagged me that the FindPkgConfig module requires people to use 
link_directories(). Now I created a new optional mode for pkg_check_modules() 
and pkg_search_modules() which will search the absolute paths of the libraries 
that are returned by pkg-config, and create an imported target from that 
information that also contains defines and include directories. It restricts 
searching to the directories returned by pkg-config, if none are given the 
normal search rules are used. I have manually tested this and it seems to 
work. Please have a look and tell me if I have missed something before I put 
this into next.

Greetings,

Eike

From 352e6b2733995dc121fe5d80d1183fe372522124 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer <e...@sf-mail.de>
Date: Wed, 11 May 2016 23:45:26 +0200
Subject: [PATCH] FindPkgConfig: optionally create imported target for the
 found libraries

---
 Modules/FindPkgConfig.cmake | 81 +
 1 file changed, 74 insertions(+), 7 deletions(-)

diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 447c526..fd71a7a 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -16,6 +16,7 @@
 # Copyright 2006-2014 Kitware, Inc.
 # Copyright 2014  Christoph Grüninger <f...@grueninger.de>
 # Copyright 2006  Enrico Scholz <enrico.sch...@informatik.tu-chemnitz.de>
+# Copyright 2016  Rolf Eike Beer <e...@sf-mail.de>
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -119,11 +120,12 @@ macro(_pkgconfig_invoke_dyn _pkglist _prefix _varname 
cleanup_regexp)
 endmacro()
 
 # Splits given arguments into options and a package list
-macro(_pkgconfig_parse_options _result _is_req _is_silent _no_cmake_path 
_no_cmake_environment_path)
+macro(_pkgconfig_parse_options _result _is_req _is_silent _no_cmake_path 
_no_cmake_environment_path _imp_target)
   set(${_is_req} 0)
   set(${_is_silent} 0)
   set(${_no_cmake_path} 0)
   set(${_no_cmake_environment_path} 0)
+  set(${_imp_target} 0)
   if(DEFINED PKG_CONFIG_USE_CMAKE_PREFIX_PATH)
 if(NOT PKG_CONFIG_USE_CMAKE_PREFIX_PATH)
   set(${_no_cmake_path} 1)
@@ -147,6 +149,9 @@ macro(_pkgconfig_parse_options _result _is_req _is_silent 
_no_cmake_path _no_cma
 if (_pkg STREQUAL "NO_CMAKE_ENVIRONMENT_PATH")
   set(${_no_cmake_environment_path} 1)
 endif()
+if (_pkg STREQUAL "IMPORTED_TARGET")
+  set(${_imp_target} 1)
+endif()
   endforeach()
 
   set(${_result} ${ARGN})
@@ -154,6 +159,7 @@ macro(_pkgconfig_parse_options _result _is_req _is_silent 
_no_cmake_path _no_cma
   list(REMOVE_ITEM ${_result} "QUIET")
   list(REMOVE_ITEM ${_result} "NO_CMAKE_PATH")
   list(REMOVE_ITEM ${_result} "NO_CMAKE_ENVIRONMENT_PATH")
+  list(REMOVE_ITEM ${_result} "IMPORTED_TARGET")
 endmacro()
 
 # Add the content of a variable or an environment variable to a list of
@@ -181,8 +187,60 @@ function(_pkgconfig_add_extra_path _extra_paths_var _var)
   set(${_extra_paths_var} ${${_extra_paths_var}} PARENT_SCOPE)
 endfunction()
 
+# scan the LDFLAGS returned by pkg-config for library directories and
+# libraries, figure out the absolute paths of that libraries in the
+# given directories, and create an imported target from them
+function(_pkg_create_imp_target _prefix _no_cmake_path 
_no_cmake_environment_path)
+  unset(_libs)
+  unset(_find_opts)
+
+  # set the options that are used as long as the .pc file does not provide a 
library
+  # path to look into
+  if(_no_cmake_path)
+set(_find_opts "NO_CMAKE_PATH")
+  endif()
+  if(_no_cmake_environment_path)
+set(_find_opts "${_find_opts} NO_CMAKE_ENVIRONMENT_PATH")
+  endif()
+
+  foreach (flag IN LISTS ${_prefix}_LDFLAGS)
+if (flag MATCHES "^-L(.*)")
+  # only look into the given paths from now on
+  set(_find_opts "HINTS ${${CMAKE_MATCH_1}} NO_DEFAULT_PATH")
+  continue()
+endif()
+if (flag MATCHES "^-l(.*)")
+  set(_pkg_search "${CMAKE_MATCH_1}")
+else()
+  continue()
+endif()
+
+find_library(${_prefix}-${CMAKE_MATCH_1}
+ NAMES ${CMAKE_MATCH_1}
+ ${_find_opts})
+list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")
+  endforeach()
+
+  # only create the target if it is linkable, i.e. no executables
+  if (NOT TARGET PkgConfig::${_prefix}
+  AND ( ${_prefix}_INCLUDE_DIRS OR _libs OR ${_prefix}_CFLAGS_OTHER ))
+add_library(PkgConfig::${_prefix} INTERFACE IMPORTED)
+if(${_prefix}_INCLUDE_DIRS)
+  set_target_properties(PkgConfig::${_prefix} PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${${_prefix}_INCLUDE_DIRS}")
+endif()
+if(_libs)
+  set_target_properties(PkgConfig::${_prefix} PROPERTIES
+INTERFACE_LINK_LIBRARIES "${_libs}"

Re: [cmake-developers] Code style auto-formatting

[Rolf Eike Beer]

Am Montag, 9. Mai 2016, 13:14:17 schrieb Brad King:
> On 05/02/2016 10:08 AM, Brad King wrote:
> > Next I'll look at the style updates themselves.
> 
> I've made some more preparatory commits:

[…]
>  Remove `//--...` horizontal separator comments
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40

This one did not remove the additional newlines if there was a blank line 
before and after the marker.

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] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

[Rolf Eike Beer]

Am Freitag, 6. Mai 2016, 17:09:14 schrieb Harry Mallon:
> According to Fedora documentation the "Release:" variable in RPM files
> should be set to 1%{?dist}.
> https://fedoraproject.org/wiki/How_to_create_an_RPM_package
> https://fedoraproject.org/wiki/Packaging:DistTag
> 
> This means it should be set to a string which looks like "1.el7.centos" on
> my CentOS7 machine. CPack sets this to "1" by default, but can be changed
> with the CPACK_RPM_PACKAGE_RELEASE variable. I propose a change as follows:
> https://github.com/hm1992/CMake/commit/94c611d5710a51072e15855ed96a225def97
> 5c38
> 
> * Adds CPACK_RPM_DIST which defaults to the output of "rpmbuild -E %{dist}
> 2>/dev/null". * Makes CPACK_RPM_PACKAGE_RELEASE default to
> "1${CPACK_RPM_DIST}"

Instead of "2>/dev/null" you should use the ERROR_QUIET option.

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] Suggest if function has lte gte operators

[Rolf Eike Beer]

Am Freitag, 8. April 2016, 14:24:08 schrieb Harry Mallon:
> CMake's "if" functionality is missing greater than or equal to and less than
> or equal to. This change could be tweaked and added to provide this
> functionality to avoid things like "if(VERSION_STRING VERSION_GREATER
> "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")".
> 
> Commit on github:
> https://github.com/hm1992/CMake/commit/75b318f8809ae71685cad068cd2e8ce9f19fb
> 28a
> 
> Would this be of interest for merging? I don't really have the time to do
> extensive testing on it at the moment.

The common way is to use the power of not:

LTE -> NOT GE
GTE -> NOT LE

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] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039)

[Rolf Eike Beer]

Am Freitag, 1. April 2016, 16:20:10 schrieb Nils Gladitz:
> On 04/01/2016 02:44 PM, melven.roehrig-zoell...@dlr.de wrote:
> > Patch for a problem with find_package(BLAS/LAPACK) on Windows for pure
> > Fortran projects reported by me in
> > https://cmake.org/Bug/view.php?id=16039.
> This might be a use case for the newish IN_LIST operator?
> 
> e.g. if(Fortran IN_LIST _LANGUAGES_)

Why not simply:

 if (CMAKE_Fortran_COMPILER_LOADED)

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] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES

[Rolf Eike Beer]

Am Mittwoch, 10. Februar 2016, 10:36:31 schrieb Antonio Perez Barrero:
> Before this change, the variable PROTOBUF_LIBRARIES might get redundant
> value for debug and optimized configurations, e.g.
> 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so'
> ---
>  Modules/FindProtobuf.cmake | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
> index 2f13b09..57c6e62 100644
> --- a/Modules/FindProtobuf.cmake
> +++ b/Modules/FindProtobuf.cmake
> @@ -213,6 +213,8 @@ endif()
>  # Internal function: search for normal library as well as a debug one
>  #if the debug one is specified also include debug/optimized keywords
>  #in *_LIBRARIES variable
> +include(SelectLibraryConfigurations)

For modules that are part of CMake use

  include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)

This makes sure exactly the version of SLC the module was designed to use will 
be used, i.e. those shipped with the exact same version of CMake.

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] [PATCH] FindProtobuf: fix wrong library list for Unix

[Rolf Eike Beer]

Am 09.02.2016 11:10, schrieb Antonio Pérez Barrero:


On 02/08/2016 04:24 PM, Antonio Pérez Barrero wrote:
> Yes, it is possible, but currently it's not looking for the debug
> library with a different name, just in a different path that is
> unlikely to exist in a Unix system.

The fact that a separate find_library is called for it and the result
is stored in a separate (user-settable) cache entry means that it is
possible to get two different values.  This convention is well 
established

in several find modules.

> Having the PROTOBUF_LIBRARIES variable getting the afore mentioned
> value messes up the client code using `find_package(Protobuf)` on Unix.

The only supported use for PROTOBUF_LIBRARIES is to pass it to
target_link_libraries, and that interprets the 'optimized' and 'debug'
keywords.  This is shown in the module documentation example:

target_link_libraries(bar ${PROTOBUF_LIBRARIES})

The documentation makes no other guarantees about the variable value.



Thanks for your explanantion, that makes sense. I had issues because I 
was

appending the value of PROTOBUF_LIBRARIES to a list and then removing
duplicates before calling `target_link_libraries(bar ${LIST})`. So when 
the

PROTOBUF_LIBRARIES values was
`optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was
missing the link flag for /usr/lib/libprotobuf.so in Debug builds. 
Skipping

the duplicates removal step solves my issue.

Anyway, the root cause is the `find_library` is finding the same 
library

for optimized and debug configuration. So, would a patch like this be
benefial?

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 2f13b09..35929a4 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename)
PATHS
${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
mark_as_advanced(${name}_LIBRARY_DEBUG)

-   if(NOT ${name}_LIBRARY_DEBUG)
+   if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL
${name}_LIBRARY_DEBUG))
   # There is no debug library
   set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE)
   set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE)


Just use SelectLibraryConfigurations, that does the same automatically 
if they are identical, and also handles the cases where only debug, but 
not release is found.


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

Re: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements

[Rolf Eike Beer]

Am Dienstag, 19. Januar 2016, 14:25:15 schrieb Brad King:
> On 09/09/2015 11:01 AM, Brad King wrote:
> >  FindwxWidgets: allow specifying required version
> >  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5
> 
> This introduced a regression reported here:
> 
>  https://cmake.org/Bug/view.php?id=15928
> 
> The version extraction from the header is breaking the reported case.
> 
> > + find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS}
> > NO_DEFAULT_PATH)
> This call is affected by CMAKE_FIND_ROOT_PATH.  Please take a look.

A random collection of thoughts I have on this:

-"_filename" is a bad name for something that is find_* set in any module. 
Really. Since the value is also in the cache with older CMake releases I think 
this name is also used at another place, so here is not searched at all or so.

-reading with file(STRINGS) will put much less stuff in the list that is REGEX 
REPLACEd later, which is probably much more efficient (depending on how large 
the file is)

-maybe call to find_file can be omitted at all, and instead just FOREACH loop 
over the include dirs and simply if(EXISTS) check if the header is there

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] Assertion hit in CMake for KDevelop on Ubuntu

[Rolf Eike Beer]

Am Mittwoch, 13. Januar 2016, 12:44:59 schrieb Robert Dailey:
> On Wed, Jan 13, 2016 at 12:36 PM, Brad King  wrote:
> > On 01/13/2016 11:16 AM, Robert Dailey wrote:
> >> Running version 3.2.2 on Ubuntu 15. I run the following command:
> > [snip]
> > 
> >> cmake: ../../Source/cmTarget.cxx:722: void
> >> cmTarget::GetSourceFiles(std::vector >> 
> >>> &, const string&) const: Assertion `this->GetType() !=
> >> 
> >> INTERFACE_LIBRARY' failed.
> >> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
> >> 21545 Aborted (core dumped) cmake "$DIR/../../.."
> > 
> > Please try running with CMake 3.4 or 'master' to see if it still
> > happens.  There has been substantial refactoring of this code
> > since 3.2.

> 3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can
> add to grab the latest CMake debian package?

https://cmake.org/files/v3.4/cmake-3.4.1-Linux-i386.tar.gz

Extract it whereever you like, then point the PATH variable to it.

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] FindGTest.cmake and CMP0064

[Rolf Eike Beer]

Am 17.11.2015 17:08, schrieb David Chen:

We’ve been getting a warning from FindGTest.cmake about CMP0064 when
building SimpleITK.  The warning occurs at lines 127, 129 and 131 when
the variable ${test_type} is equal to “TEST”.  With CMP0064 this TEST
could be interpreted as commands in the if() and elseif() statements
unless the policy is set to OLD.

I’ve attached a patch for your consideration that re-writes those
statements.  I have changed the STREQUAL comparisons to regex MATCHES
comparisons.  This change removes the possibility of “TEST” being the
first word inside the parentheses.


The correct fix would probably to just remove the dereference, i.e. 
change


  if(${test_type} STREQUAL "TEST_P")

to

  if(test_type STREQUAL "TEST_P")

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

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Rolf Eike Beer]

+endif()
+set(${VARNAME} ${RES} PARENT_SCOPE)
+endfunction()
\ No newline at end of file


Bug ;)
--

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] [CPackDeb] empty directories in packages

[Rolf Eike Beer]

Domen Vrankar wrote:

I was looking at this issue
http://public.kitware.com/Bug/view.php?id=13009

and apparently it is not possible to install empty directories (I just
tested).

I believe that it should be possible to do that (even if there are 
better

ways like postinst).
What is your opinion?


I agree. This is also an issue on other packaging generators (e.g. tar 
gz)


The attached patch addresses this (and adds the corresponding test). 
It is

based on my previous patch
"0001-CPackDeb-preventing-md5sum-on-symlinks.patch".


Thanks, applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=47b060

Your patch only fixed the issue for component packaging so I extended
it to non component packaging as well. This also fixes the issue for
other generators:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b58de9f


You left a commented out line in Source/CPack/cmCPackGenerator.cxx.

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

Re: [cmake-developers] Python extension to FindProtobuf

[Rolf Eike Beer]

Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier:
> Since beneath generating cpp and h files we often also want python bindings
> to be generated, I would like to have the following extension to
> FindProtobuf added.
 This adds protobuf_generate_python function.

Forgot to add patch?

> 
> Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder
[…] Argh!

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] Replace deprecated libarchive functions

[Rolf Eike Beer]

Páder Rezső wrote:

Hi all,

cmake requires libarchive3, but uses old, deprecated libarchive 
functions.


The attached patch solves this.


I may be wrong, but I would assume that these are not deprecated 
libarchive3 functions, but function deprecated _in_ libarchive3, no?


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

Re: [cmake-developers] FindBZip2.cmake

[Rolf Eike Beer]

Brad King wrote:
 On 08/23/2015 07:36 AM, Rolf Eike Beer wrote:

  Another thing which I found is that there seems to be an obscure problem
  in FindBZip2.cmake to not find the library on Windows if the path contains
  backslashes. Yes, really. Just compare the cmake part of these 2 links (no
  idea how long they will present, as they are CI logs):
  
  https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.228/job/my1segq
  cq89k28en
  https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.227/job/rnu1e7
  1degn7snwm
  
  I have no clue what happens there, why it happens only for that module,
  and
  why noone noticed that before. I do not have access to a Windows system
  where I can test easily, but maybe you can have a look (or find someone
  to)? I thought that it may be \b, because that would be unique to that
  module in that build configuration, but if I pass the CMAKE_PREFIX_PATH
  with forward slash at that point it still fails, while all other modules
  work.
 
 The BZIP2_NEED_PREFIX check generates a CMakeLists.txt file that
 refers to the raw path given without re-escaping the backslashes.
 Then the check fails to configure due to the backslashes being
 interpreted as invalid CMake escape sequences.

No, this is not the problem. That happens if FPHSA succeeds, but that fails 
because it can't find the library, which means the problem is actually happen 
before FPHSA.

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] FindZLIB module should find debug and release variants

[Rolf Eike Beer]

Michael Scott wrote:
 Hi,
 
 Carrying on in the list of open issues to look at for contributing to
 CMake, I've had a look at issue 15280 - FindZLIB module should find
 debug and release variants. I've made some changes to the FindZLIB
 module which should make it so that debug and release variants are found
 as separate libraries, if they're both found then they're provided in
 ZLIB_LIBRARIES and ZLIB::ZLIB's imported location properties. Attached
 is the patch for FindZLIB.cmake.
 
 With this, I noticed that the Windows DLL's use different file names for
 the release and debug variants, but I couldn't tell if this is true on
 UNIX, it didn't seem to be the case. As the change to FinZLIB is based
 on the two variants having different names, I'm not sure these changes
 will have any effect on UNIX, is this expected or am I missing
 something/going about it the wrong way?

On Unix systems those variants usually do not exists, as there are no 
different standard libraries (and therefore e.g. allocators) used for release 
and debug mode.

You should use SelectLibraryConfigurations.cmake instead of building the list 
of libraries yourself. Look at FindPNG.cmake, which uses it.

I wonder if we should add a function or macro to SLC which does the target 
fiddling which is done at the bottom of the patch.

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-developers] FindBZip2.cmake

[Rolf Eike Beer]

Brad,

you introduced in 7c912af2 that this module not only looks into the Windows 
registry, but also added PATH_SUFFIXES include and lib for find_* calls. Am I 
gettings something wrong? Wouldn't CMake automatically append those to all 
paths given?

Another thing which I found is that there seems to be an obscure problem in 
FindBZip2.cmake to not find the library on Windows if the path contains 
backslashes. Yes, really. Just compare the cmake part of these 2 links (no 
idea how long they will present, as they are CI logs):

https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.228/job/my1segqcq89k28en
https://ci.appveyor.com/project/Mapbox/libosmium/build/1.0.227/job/rnu1e71degn7snwm

I have no clue what happens there, why it happens only for that module, and 
why noone noticed that before. I do not have access to a Windows system where 
I can test easily, but maybe you can have a look (or find someone to)? I 
thought that it may be \b, because that would be unique to that module in 
that build configuration, but if I pass the CMAKE_PREFIX_PATH with forward 
slash at that point it still fails, while all other modules work.

Everyone else interested may of course have a look, too.

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-developers] I fear $COMPILE_FEATURES:* is not really useful...

[Rolf Eike Beer]

Yes, sadly. I have this code:

if (NOT CMAKE_VERSION VERSION_LESS 3.1)
   set_property(TARGET osmium_convert PROPERTY CXX_STANDARD 11)
   target_compile_definitions(osmium_convert PRIVATE 
$$COMPILE_FEATURES:cxx_decltype_incomplete_return_types:BOOST_RESULT_OF_USE_DECLTYPE)
endif()

So, in theory, this will set the definition if the compiler supports decltype, 
and just don't set it if not. And it works fine for g++. The problem is when it 
comes to MSVC:

There is no MSVC version that supports this feature properly, so there is no 
variable for this compiler defined. Or just think of $FooBarC++, where noone 
cared to report the supported features. No variable either. For these 
compilers the above expression fails, because this is no recorded feature of 
the compiler. I would have expected it to just not set the definition, but not 
error out.

So for now my code is:

if (NOT CMAKE_VERSION VERSION_LESS 3.1 AND CMAKE_CXX_COMPILER_ID STREQUAL 
GNU)
 ...

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] Java support

[Rolf Eike Beer]

Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc:
 Hi,
 
 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for
 java sources specification.

You do not need leading or trailing .* in regular expressions. In fact I think 
your expression should simply be ^@, otherwise you would match an @ at any 
position in the argument name, which does not look intended.

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] [PATCH] FindMPI: Intel-MPI 5+ workaround

[Rolf Eike Beer]

Am Donnerstag, 9. Juli 2015, 14:42:13 schrieb Brennan, Sean M:
 See attached git patch.
 
 FindMPI: Intel-MPI 5+ workaround needs an additional/alternate keyword to
 recognize this case with recent GCCs.
 
 Confirmed working with intel-mpi/5.0.1 using gcc/4.4.7, gcc/4.6.1,
 gcc/4.7.2, gcc/4.8.2, intel/11.1.072, intel/12.1.5, intel/13.1.3,
 intel/14.0.4, intel/15.0.090, pgi/10.9, pgi/12.6, pgi/13.7, pgi/14.10.
 Tested by building LLNL's PnMPI library.

That's quite an impressive list of tools. Is there any chance that we can get 
an automated nigthly build that has access to them?

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] [PATCH] FindMPI: Intel-MPI 5+ workaround

[Rolf Eike Beer]

Am Donnerstag, 9. Juli 2015, 11:05:13 schrieb Brad King:
 On 07/09/2015 10:42 AM, Brennan, Sean M wrote:
  See attached git patch.
 
 Applied, thanks:
 
  FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d7653a0

For the usual reasons, can we please change this from ${cmdline} to cmdline?

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] [PATCH v3] FindHDF5.cmake HDF5_VERSION Support

[Rolf Eike Beer]

Huebl, Axel wrote:

 I personally also tend to the cropped HDF5_VERSION for consistency and
 ease-of-use in environments using stable versions of HDF5 (most
 distributions).
 
 That doesn't mean we could not provide and *additional*
 HDF5_VERSION_STRING.
 For sake of consistency, I am not sure how to provide a -somestring
 extension to HDF5_VERSION that cmake's compare operators such as
 VERSION_LESS would understand (and/or ignore). I guess that is not
 possible and would introduce an inconsistency between the string
 HDF5_VERSION_STRING and the quasi-numeric variable HDF5_VERSION.

VERSION_LESS and friends already ignore the extra parts, that is why you only 
need one variable.

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] [PATCH v2] FindHDF5.cmake HDF5_VERSION Support

[Rolf Eike Beer]

Am 11.05.2015 10:29, schrieb Huebl, Axel:

On 08.05.2015 19:07, Huebl, Axel wrote:

This commit adds VERSION support for HDF5 from
the same sources as it adds the HDF5_IS_PARALLEL
flag.

Previously posted on
  https://github.com/Kitware/CMake/pull/153

and improved with feedback from

 - Brad King
 - Rolf Eike Beer



@@ -343,6 +346,16 @@ if( NOT HDF5_FOUND )
 if( HDF5_HAVE_PARALLEL_DEFINE )
 set( HDF5_IS_PARALLEL TRUE )
 endif()
+unset(HDF5_HAVE_PARALLEL_DEFINE)
+
+file( STRINGS ${_dir}/H5pubconf.h
+HDF5_VERSION_DEFINE
+REGEX ^[ \t]*#[ \t]*define[ \t]+H5_VERSION[ \t]+ )
+if( ${HDF5_VERSION_DEFINE} MATCHES
+H5_VERSION[ \t]+\([0-9]+\\.[0-9]+\\.[0-9]+)\ )
+set( HDF5_VERSION ${CMAKE_MATCH_1} )
+endif()
+unset(HDF5_VERSION_DEFINE)
 endif()
 endforeach()
 set( HDF5_IS_PARALLEL ${HDF5_IS_PARALLEL} CACHE BOOL


I double checked some of the previous releases and pre-releases usually
take the format with appended -something, e.g.
  1.8.10-patch1

One could skip the subrelease but still avoid breaking the configure
by looking for a H5_VERSION of format

   #define X.Y.Z

(neglecting the last ).


-if( ${HDF5_VERSION_DEFINE} MATCHES
-H5_VERSION[ \t]+\([0-9]+\\.[0-9]+\\.[0-9]+)\ )
+if( ${HDF5_VERSION_DEFINE} MATCHES
+H5_VERSION[ \t]+\([0-9]+\\.[0-9]+\\.[0-9]+) )



Any comments on that?


Then I would change the regex to:

H5_VERSION[ \t]+\([0-9]+\\.[0-9]+\\.[0-9]+[^]*)

This would include whatever comes next into the visible string, but 
CMake should be able to deal with that just fine (please check, as you 
seem to have the versions available).


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] [PATCH] FindHDF5.cmake HDF5_VERSION Support

[Rolf Eike Beer]

Huebl, Axel wrote:
 This commit adds VERSION support for HDF5 from
 the same sources as it adds the HDF5_IS_PARALLEL
 flag.

 @@ -343,6 +346,14 @@ if( NOT HDF5_FOUND )
  if( HDF5_HAVE_PARALLEL_DEFINE )
  set( HDF5_IS_PARALLEL TRUE )
  endif()
 +
 +file( STRINGS ${_dir}/H5pubconf.h
 +HDF5_VERSION_DEFINE
 +REGEX #define H5_VERSION )

I suggest using #define[ \t]+H5_VERSION[ \t]+: this works also on changed 
indendation and does not accidentially match H5_VERSION_FOO.

 +if( ${HDF5_VERSION_DEFINE} MATCHES
 +H5_VERSION[ \t]+\([0-9]+\\.[0-9]+\\.[0-9]+)\ )
 +set( HDF5_VERSION ${CMAKE_MATCH_1} )
 +endif()

please unset HDF5_VERSION_DEFINE here.

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] [PATCH 1/3] wxWidgets module: allow specifying required version

[Rolf Eike Beer]

Am Samstag, 2. Mai 2015, 00:59:38 schrieb Simon Richter:
 ---
  Modules/FindwxWidgets.cmake | 40 
  1 file changed, 36 insertions(+), 4 deletions(-)
 
 diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake
 index c16c011..ecce49c 100644
 --- a/Modules/FindwxWidgets.cmake
 +++ b/Modules/FindwxWidgets.cmake
 @@ -103,6 +103,12 @@
  #include(${wxWidgets_USE_FILE})
  ## and for each of your dependent executable/library targets:
  #target_link_libraries(YourTarget ${wxWidgets_LIBRARIES})
 +#
 +# If a wxWidgets version or greater is required:
 +#   find_package(wxWidgets 2.8.12 COMPONENTS net gl core base REQUIRED)
 +#
 +# If specific wxWidgets version is required:
 +#   find_package(wxWidgets 2.8.12 EXACT COMPONENTS net gl core base
 REQUIRED)

Drop that, it is already documented in the find_package command documentation. 
Otherwise we would end up replicating half of that documentation in every find 
module.

 @@ -856,6 +862,28 @@ else()
endif()
  endif()
 
 +# Check if a specfic version was requested by find_package().
 +if(wxWidgets_FOUND AND wxWidgets_FIND_VERSION)

Drop that if, just extract the version always. And just make it dependend on 
the include paths being found. That way even if no specific version was 
requested the version found will be shown in CMake output.

 +  find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS}
 NO_DEFAULT_PATH) +  dbg_msg(_filename:  ${_filename})
 +
 +  if(NOT _filename)
 +message(FATAL_ERROR wxWidgets wx/version.h file not found in
 ${wxWidgets_INCLUDE_DIRS}.) +  endif()
 +
 +  file(READ ${_filename} _wx_version_h)
 +
 +  string(REGEX REPLACE ^(.*\n)?#define wxMAJOR_VERSION[ ]+([0-9]+).*
 +\\2 wxWidgets_VERSION_MAJOR ${_wx_version_h} )
 +  string(REGEX REPLACE ^(.*\n)?#define wxMINOR_VERSION[ ]+([0-9]+).*
 +\\2 wxWidgets_VERSION_MINOR ${_wx_version_h} )
 +  string(REGEX REPLACE ^(.*\n)?#define wxRELEASE_NUMBER[ ]+([0-9]+).*
 +\\2 wxWidgets_VERSION_PATCH ${_wx_version_h} )

You should allow any amount of spaces and tabs also between the #define and the 
constant name, if they decide to reformat their sources in the next version 
the CMake module will continue to work.

 +  set(wxWidgets_VERSION_STRING
 +   
 ${wxWidgets_VERSION_MAJOR}.${wxWidgets_VERSION_MINOR}.${wxWidgets_VERSION_
 PATCH} ) +  dbg_msg(wxWidgets_VERSION_STRING:   
 ${wxWidgets_VERSION_STRING}) +endif()
 +
  # Debug output:
  DBG_MSG(wxWidgets_FOUND   : ${wxWidgets_FOUND})
  DBG_MSG(wxWidgets_INCLUDE_DIRS: ${wxWidgets_INCLUDE_DIRS})
 @@ -866,10 +894,14 @@ DBG_MSG(wxWidgets_USE_FILE:
 ${wxWidgets_USE_FILE})
 
  #=
  #=
 -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 -FIND_PACKAGE_HANDLE_STANDARD_ARGS(wxWidgets DEFAULT_MSG wxWidgets_FOUND)
 -# Maintain consistency with all other variables.
 -set(wxWidgets_FOUND ${WXWIDGETS_FOUND})
 +
 +include(FindPackageHandleStandardArgs)

The other include is the correct one for an upstream CMake module.

 +
 +find_package_handle_standard_args(wxWidgets
 +  FOUND_VAR wxWidgets_FOUND

You can drop that, this variable will always be set. On the other hand: the 
variable is already set above by hand, which probably is also wrong.

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] CTest update broken with non-ASCII filenames

[Rolf Eike Beer]

Am Donnerstag, 9. April 2015, 10:30:35 schrieb Brad King:
 On 04/09/2015 10:28 AM, Nils Gladitz wrote:
  What was the original problem you were trying to fix?
  
  You pointed out test failures on nibble.ngladitz which I then tried to
  fix:
  
  https://open.cdash.org/testDetails.php?test=316350872build=3711574
 
 Right, I forgot about that, thanks.  So, this was exposed by
 using the zh_HK locale.

Just guessing: C will be ASCII, i.e. every 8 bit character gets mangled 
(or at least everything not being able to be displayed in a 256 byte 
codepage). So a fix could be to use something like en_US.UTF-8, if that is 
available on the system, which sadly may not always be the case.

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] fixing a bug after topic was merged to master

[Rolf Eike Beer]

Domen Vrankar wrote:
 Hi all,
 
 While writing tests for a new topic I found a bug in an older topic
 that I wrote.
 The that topic was already merged to master (last week) but remote
 stage branch still exists.
 The fix is trivial - one variable typo.
 
 How can I get the fix both into master and next release candidate branch?
 Should I create a new topic and push that to next or should I extend
 the old one even though it was already merged to master and push that
 one to next?

Just create a new branch based on origin/release and merge to next.

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] [PATCH] CPackRPM: Fix cross-building rpms

[Rolf Eike Beer]

  # CPACK_RPM_PACKAGE_ARCHITECTURE (optional)
 -if(CPACK_RPM_PACKAGE_ARCHITECTURE)
 +if(NOT CPACK_RPM_PACKAGE_ARCHITECTURE)
 +  execute_process(COMMAND uname -m
 +  WORKING_DIRECTORY ${WDIR}
 +  OUTPUT_VARIABLE CPACK_RPM_PACKAGE_ARCHITECTURE)
 +endif()

You don't need to specify a working directory for uname. Also I assume that 
you want to use OUTPUT_STRIP_TRAILING_WHITESPACE to not have the trailing 
newline in the variable.

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] New module: CheckFortranCompilerFlag.cmake

[Rolf Eike Beer]

Nicolas Bock wrote:
 Hi,
 
 please find attached for potential inclusion into CMake a new Module
 that tests Fortran compiler flags. It is a modified copy of the
 existing CheckCCompilerFlag.cmake module.

Hi Nicolas,

which version did you base this on? It looks like this is a version older than 
any 3.0.0-rc. Please take a look at the git version instead.

Also I don't know if it makes sense to check for certain flags that look 
specific to C++. Which compilers did you use to test?

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] [PATCH] OpenSSL 1.0.2 update

[Rolf Eike Beer]

Guillaume Belz wrote:
 Hi,
 
 OpenSSL 1.0.2 was released last week and there is a little change in code,
 which impact FindOpenSSL.cmake script. The script use a regex to read the
 version of OpenSLL inside opensslv.h file. In the last commit, this file
 was modified with a formatting tool and the line 33 was changed from:
 
  # define OPENSSL_VERSION_NUMBER  0x1010L
 
 to:
 
  #define OPENSSL_VERSION_NUMBER 0x1010L
 
 To fix that, it's possible to change regex in FindOpenSSL.cmake file in
 line 288, from:
 
  REGEX ^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*)
 
 to:
 
  REGEX ^# *define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*)
 
 It's work on Scientific Linux 7 with OpenSSL 1.0.2 and CMake 3.1.1. I have
 not checked on other platforms.

Should there be a patch? Otherwise I'll create one from your mail.

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] [PATCH] OpenSSL 1.0.2 update

[Rolf Eike Beer]

Rolf Eike Beer wrote:
 Guillaume Belz wrote:
  Hi,
  
  OpenSSL 1.0.2 was released last week and there is a little change in code,
  which impact FindOpenSSL.cmake script. The script use a regex to read the
  version of OpenSLL inside opensslv.h file. In the last commit, this file
  
  was modified with a formatting tool and the line 33 was changed from:
   # define OPENSSL_VERSION_NUMBER  0x1010L
  
  to:
   #define OPENSSL_VERSION_NUMBER 0x1010L
  
  To fix that, it's possible to change regex in FindOpenSSL.cmake file in
  
  line 288, from:
   REGEX ^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*)
  
  to:
   REGEX ^# *define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*)
  
  It's work on Scientific Linux 7 with OpenSSL 1.0.2 and CMake 3.1.1. I have
  not checked on other platforms.
 
 Should there be a patch? Otherwise I'll create one from your mail.

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5d9a8283cfac15b4a5a07f18d5eb10c1f388505

Brad, this is based on origin/release. In case there will be a 3.1.2 I think 
this is a good candidate.

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] Unknown CMake bugs

[Rolf Eike Beer]

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cmake/patches/patch-b
  ootstrap?rev=1.7content-type=text/x-cvsweb-markup
 They just want to bootstrap with Ninja, except on specific
 architectures.  Not an upstream concern.

Yes, because:

XXX: broken on arm and m88k

It's the same as with the other stuff: as long as they don't report what 
actually went wrong it will be hard to fix.

I'll see if I can do a CMake run on a BeagleBoard on Linux in the next time, 
maybe that will give a clue.

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-developers] Unknown CMake bugs

[Rolf Eike Beer]

Some bugs of CMake (or what downstreams thinks are bug), that I was not aware 
of, and maybe noone else. I have no connection to any of these bugs, I just 
found them by accident:

https://bugs.gentoo.org/show_bug.cgi?id=445308

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cmake/patches/patch-bootstrap?rev=1.7content-type=text/x-cvsweb-markup

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cmake/patches/patch-Source_CMakeLists_txt?rev=1.6content-type=text/x-cvsweb-markuphideattic=1

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] Improving the version selection behavior of EXACT

[Rolf Eike Beer]

Matthew Woehlke wrote:
 On 2014-10-03 03:35, Rolf Eike Beer wrote:
  find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In
  most cases this behavior is not the one that one would expect or need.
  Most people would instead allow any 2.0.x version to match. This sort of
  selection is currently impossible without additional effort in every
  Find*.cmake that is used.
 
 This is probably a bit late, but did anyone think of using MATCHES to
 say all provided components match exactly and the rest can be whatever?

I bet everybody will get it wrong.

Ok, this is version 2.1 and any of it's patch versions, if _I_ got it right:

if (VER MATCHES ^2\\.1(\\..*|[^0-9].*)?$)

So this should match 2.1, 2.1a, 2.1.1, but not 2.10. What combination 
of stuff did I miss?

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] patch for FindCUDA.cmake

[Rolf Eike Beer]

Am Montag, 5. Januar 2015, 00:22:51 schrieb Mark Abraham:
 On Sun, Jan 4, 2015 at 3:02 PM, Rolf Eike Beer e...@sf-mail.de wrote:
  Mark Abraham wrote:
   Hi,
   
   The FindCUDA.cmake module since v3.0 has had a bug because it assumes
   that when cross compiling that CMAKE_SYSTEM_PROCESSOR will be defined.
   That definition is documented as optional at
   http://www.vtk.org/Wiki/CMake_Cross_Compiling, and the module can't
   work if it happens to be undefined. Attached patch
   wraps the uses of CMAKE_SYSTEM_PROCESSOR in quotes so that interpolation
   will lead to the intended behaviour in all cases.
  
  The easier and better fix would be to just remove the dereference, i.e.
  
  if (… CMAKE_SYSTEM_PROCESSOR MATCHES arm …)

 True, once you look at the minutae of if(... MATCHES ...) :-)
 
 Updated patch attached.

Fix pushed to next: 
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52d4ff49d973d77dba480e0b60b08c6c70e94538

Brad, it is based on release in case you want to pick it for 3.1.1.

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] patch for FindCUDA.cmake

[Rolf Eike Beer]

Mark Abraham wrote:
 Hi,
 
 The FindCUDA.cmake module since v3.0 has had a bug because it assumes that
 when cross compiling that CMAKE_SYSTEM_PROCESSOR will be defined. That
 definition is documented as optional at
 http://www.vtk.org/Wiki/CMake_Cross_Compiling, and the module can't work if
 it happens to be undefined. Attached patch
 wraps the uses of CMAKE_SYSTEM_PROCESSOR in quotes so that interpolation
 will lead to the intended behaviour in all cases.

The easier and better fix would be to just remove the dereference, i.e.

if (… CMAKE_SYSTEM_PROCESSOR MATCHES arm …)

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] [PATCH] Avoid bad alloc for large files

[Rolf Eike Beer]

Am Montag, 22. Dezember 2014, 22:16:50 schrieb Rolf Eike Beer:
 Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King:
  On 12/20/2014 08:44 AM, Rolf Eike Beer wrote:
   This is basically the same, but it avoids the needless floating point
   arithmetic. Does it work for you?
  
  Thanks, Eike.  Please add a topic to put this in 'next' when ready.
 
 Done. I wonder if we should not check for new returning null?

Ok, now I get this:

cmCTest.cxx
C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) : 
warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', 
possible loss of data

The problem is: this is absolutely right. On Windows64 this means that the 
maximum file size will be 4GB, or one needs to change the base64 
implementation. Which way to go?

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] [PATCH] Avoid bad alloc for large files

[Rolf Eike Beer]

Am Dienstag, 23. Dezember 2014, 10:27:47 schrieb Rolf Eike Beer:
 Am Montag, 22. Dezember 2014, 22:16:50 schrieb Rolf Eike Beer:
  Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King:
   On 12/20/2014 08:44 AM, Rolf Eike Beer wrote:
This is basically the same, but it avoids the needless floating point
arithmetic. Does it work for you?
   
   Thanks, Eike.  Please add a topic to put this in 'next' when ready.
  
  Done. I wonder if we should not check for new returning null?
 
 Ok, now I get this:
 
 cmCTest.cxx
 C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705)
 : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long',
 possible loss of data
 
 The problem is: this is absolutely right. On Windows64 this means that the
 maximum file size will be 4GB, or one needs to change the base64
 implementation. Which way to go?

*lol*

From: Brad King (Code Review) rev...@kitware.com
Date: Tue, 23 Dec 2014 04:27:55 -0500
Subject: Change in KWSys[master]: Base64: Use size_t for lenghts in API


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-developers] Introducing targets in FindPkgConfig

[Rolf Eike Beer]

Hi Daniele,

the feature about CMake language I probably hate most is link_directories(). 
Sadly one currently needs to use it when working with software dependencies 
imported from PkgConfig.

What I would like to get is the following: when a list of libraries and 
directories is returned by PkgConfig then for every of these libraries the 
absolute path to the library is determined using find_library() using the given 
directories as hints. With that, noone needs to use link_directories() 
anymore. Since this would introduce new behavior people would need to adapt 
their CMakeLists.txt to this new feature. Therefore I think it would be a good 
idea to expose this new information not by new variables, but using targets.

So if I search for OpenSSL using PkgConfig I would get a target 
PkgConfig::OpenSSL that I can link to, and that has the libraries, compile 
flags, include dirs and whatnot.

Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can you 
either point me to the right place where I would hook up something like that 
or try doing it?

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] Introducing targets in FindPkgConfig

[Rolf Eike Beer]

Am Montag, 22. Dezember 2014, 18:55:16 schrieb Daniele E. Domenichelli:
 Hello Eike,
 
 On 22/12/14 16:39, Rolf Eike Beer wrote:
  What I would like to get is the following: when a list of libraries and
  directories is returned by PkgConfig then for every of these libraries the
  absolute path to the library is determined using find_library() using the
  given directories as hints.
  [...]
  Since this would introduce new behavior people would need to adapt
  their CMakeLists.txt to this new feature. Therefore I think it would be a
  good idea to expose this new information not by new variables, but using
  targets.
 We have a macro to do exactly this and a few other things (actually 2
 macros, that diverged slightly I will make them one again as soon I as I
 have some time), you can find them here:
 
 
https://github.com/robotology/yarp/blob/master/conf/MacroStandardFindModule.cmake
 
https://github.com/robotology/ycm/blob/master/modules/StandardFindModule.cmake

[...]

  So if I search for OpenSSL using PkgConfig I would get a target
  PkgConfig::OpenSSL that I can link to, and that has the libraries, compile
  flags, include dirs and whatnot.
  
  Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can
  you either point me to the right place where I would hook up something
  like that or try doing it?
 
 You can start from the macros I linked before for the pkg-config part, and
 then have a look at the CMake modules that create imported targets
 (FindQt4, FindGTK2, FindZLIB, FindGLUT, FindGLEW) for the targets part
 (all the variables you need should be there already).
 Let me know if you do it, I'd like to do it too one day...

The imported targets was not the thing worrying me, although my experience 
with this is a bit limited at the moment.

 About the FindPkgConfig macros documentation, what is that is not clear?

It's not about the documentation of that module, but where I need to hack it 
into the module. The code is quite a bit of indirections, I guess I would need 
to do this _pkg_check_modules_internal at the end of the last foreach?

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] [PATCH] Avoid bad alloc for large files

[Rolf Eike Beer]

Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King:
 On 12/20/2014 08:44 AM, Rolf Eike Beer wrote:
  This is basically the same, but it avoids the needless floating point
  arithmetic. Does it work for you?
 
 Thanks, Eike.  Please add a topic to put this in 'next' when ready.

Done. I wonder if we should not check for new returning null?

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] [PATCH] Avoid bad alloc for large files

[Rolf Eike Beer]

Justin Borodinsky wrote:
 I received a bad alloc when uploading a large file with CTest. The patch
 below resolved this.

Your patch is line-wrapped and can't be applied. However, I did this by hand.
This is basically the same, but it avoids the needless floating point
arithmetic. Does it work for you?

diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 2bf7b77..1a7bf45 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -1688,7 +1688,7 @@ std::string cmCTest::Base64GzipEncodeFile(std::string 
file)
 //--
 std::string cmCTest::Base64EncodeFile(std::string file)
 {
-  long len = cmSystemTools::FileLength(file);
+  const size_t len = cmSystemTools::FileLength(file);
   cmsys::ifstream ifs(file.c_str(), std::ios::in
 #ifdef _WIN32
 | std::ios::binary
@@ -1699,8 +1699,7 @@ std::string cmCTest::Base64EncodeFile(std::string file)
   ifs.close();
 
   unsigned char *encoded_buffer
-= new unsigned char [ static_castint(
-static_castdouble(len) * 1.5 + 5.0) ];
+= new unsigned char [ (len * 3) / 2 + 5 ];
 
   unsigned long rlen
 = cmsysBase64_Encode(file_buffer, len, encoded_buffer, 1);



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