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

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

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

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

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

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

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

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

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

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 >

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

Am 2019-03-18 14:45, schrieb Brad King: On 3/15/19 6:10 PM, Rolf Eike Beer wrote: I suspected it was a policy thing, so I tried this: foreach(_p RANGE 21 54) cmake_policy(SET CMP00${_p} OLD) endforeach() Only policies 51-54 were added between 3.0 and 3.1. The starting point

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

> I'm trying to figure out what's actually going wrong here. At this stage in > the log you have have already built the Subsurface installer and > smtk_import... so what is it trying to build there? It's running packaging/windows/smtk2ssrf-mxe-build.sh to build smtk-import/ CMakeLists.txt. Eike

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

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

[cmake-developers] Slowdown of nightly builds

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

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

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

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

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

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

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

Re: [cmake-developers] CMake string question

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

Re: [cmake-developers] module proposal: PreventInSourceBuilds

(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

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

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

Re: [cmake-developers] Generalized verbose option for cmake --build.

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

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

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

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

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 >

[cmake-developers] Automatically set policies for shipped modules

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

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

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

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

> 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

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

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

Re: [cmake-developers] cmake on AIX

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)

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

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

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

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:

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

> 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

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

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

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

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

Re: [cmake-developers] C++ IDE

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:

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

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

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

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

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

> 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

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

> 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

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

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

[cmake-developers] Problems with CTestTestParallel

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,

Re: [cmake-developers] [RESEND] [PATCH] x32-abi support #15994 (without line wrapping!)

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

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

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

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

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:

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

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

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

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

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

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:

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

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

Re: [cmake-developers] FindOpenSSL: Link libraries needed for static OpenSSL.

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 +

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

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

Re: [cmake-developers] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master

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

Re: [cmake-developers] daemon-mode meeting last Tuesday

> 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

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

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 >

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

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

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

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

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

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

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

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 s

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

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

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

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

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

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

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

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)

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

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 wee

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

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

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

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

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

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 lib

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

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 >

Re: [cmake-developers] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

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

Re: [cmake-developers] Suggest if function has lte gte operators

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

Re: [cmake-developers] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039)

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

Re: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES

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

Re: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix

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

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

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

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

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:

Re: [cmake-developers] FindGTest.cmake and CMP0064

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

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

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

Re: [cmake-developers] [CPackDeb] empty directories in packages

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

Re: [cmake-developers] Python extension to FindProtobuf

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

Re: [cmake-developers] Replace deprecated libarchive functions

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

Re: [cmake-developers] FindBZip2.cmake

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

Re: [cmake-developers] FindZLIB module should find debug and release variants

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

[cmake-developers] FindBZip2.cmake

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

[cmake-developers] I fear $COMPILE_FEATURES:* is not really useful...

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,

Re: [cmake-developers] Java support

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 ^@,

Re: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround

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,

Re: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround

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,

Re: [cmake-developers] [PATCH v3] FindHDF5.cmake HDF5_VERSION Support

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

Re: [cmake-developers] [PATCH v2] FindHDF5.cmake HDF5_VERSION Support

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

Re: [cmake-developers] [PATCH] FindHDF5.cmake HDF5_VERSION Support

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

Re: [cmake-developers] [PATCH 1/3] wxWidgets module: allow specifying required version

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

Re: [cmake-developers] CTest update broken with non-ASCII filenames

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:

Re: [cmake-developers] fixing a bug after topic was merged to master

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

Re: [cmake-developers] [PATCH] CPackRPM: Fix cross-building rpms

# 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

Re: [cmake-developers] New module: CheckFortranCompilerFlag.cmake

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

Re: [cmake-developers] [PATCH] OpenSSL 1.0.2 update

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

Re: [cmake-developers] [PATCH] OpenSSL 1.0.2 update

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

Re: [cmake-developers] Unknown CMake bugs

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

[cmake-developers] Unknown CMake bugs

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

Re: [cmake-developers] Improving the version selection behavior of EXACT

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

Re: [cmake-developers] patch for FindCUDA.cmake

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

Re: [cmake-developers] patch for FindCUDA.cmake

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

Re: [cmake-developers] [PATCH] Avoid bad alloc for large files

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

Re: [cmake-developers] [PATCH] Avoid bad alloc for large files

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

[cmake-developers] Introducing targets in FindPkgConfig

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

Re: [cmake-developers] Introducing targets in FindPkgConfig

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

Re: [cmake-developers] [PATCH] Avoid bad alloc for large files

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

Re: [cmake-developers] [PATCH] Avoid bad alloc for large files

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

  1   2   3   4   >