Re: [CMake] find_path / find_package hardcoded path

Am 2019-08-28 12:28, schrieb Ran Regev: I think you can also add "PATHS" or "HINTS" to find_package. Yes, but this has a different purpose. It's idea is to provide places to look at based on other things already found, things that would work independent of the machine. The plan here is to

Re: [CMake] find_path / find_package hardcoded path

Am 2019-08-28 11:39, schrieb Stéphane Ancelot: Hi, using mingw32 with win10 , I can not manage to find jpeg libs . I tried setting JPEG_DIR, it fails. it also fails setting CMAKE_FIND_ROOT_PATH set(JPEG_DIR c:\\work\\WIN32DEPS\\jpegfolder) Use forward slashes. Don't do it in the

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

Am 2019-06-28 08:52, schrieb vinay kumar Kotegowder: Hello, The snippet: set(SUITE_DIR /home/../abc) list(APPEND TEST_LSIT test_a001) Since there is a type here I bet this is not the original code that you have run. foreach(test ${TEST_LIST}) message(${test}) Please prefix

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

# 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

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

Zach van Rijn wrote: > On Fri, 2018-10-26 at 11:09 +0200, Rolf Eike Beer wrote: > > ... > > Hi Eike, > > Thank you for writing. I agree that my approach is a bit brutish > and aim to revise/reduce it to a minimum example. My goal was to > describe a process that i

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

Am 2018-10-26 10:04, schrieb Zach van Rijn: Hi Friends, I have, until recently, been under the impression that CMake is rather difficult (or impossible?) to cross-compile correctly. I believe I have devised a sane method of doing so. In addition to being simple, the output binaries are fully

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

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

Re: [CMake] Problems with static jpeg library

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

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

Am Montag, 20. August 2018, 19:10:57 CEST schrieb Brad King: > On 08/15/2018 01:30 PM, Rolf Eike Beer wrote: > > My dislike against these functions is probably known, and now I would like > > to bring this to a new level: I would like to formally deprecate these > > fun

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

Am Montag, 9. Juli 2018, 09:45:25 CEST schrieb Mark De Wit: > I thought that the find script itself was responsible for checking the > required flag? That's what find_package_handle_standard_args() does. Eike signature.asc Description: This is a digitally signed message part. -- Powered by

Re: [CMake] find_package: keyword REQUIRED ignored

Am 2018-07-08 23:34, schrieb Quaquaraquà: Hi there, I'm using a custom script [1] to look for the library sqlite3. However, the keyword "REQUIRED" (as quietly) is ignored by find_package. That is even if the library is not found, the script continues is processing: // CMakeLists.txt

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

Am Sonntag, 24. Juni 2018, 11:32:32 CEST schrieb Quaquaraquà: > Dear users, > > how do you specify the order of compilers to select from the system? > That is, if the user didn't set neither CMAKE_C_COMPILER nor the env. > var. CC, I wish the build system would pick one of the compilers from a >

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

Am Freitag, 25. Mai 2018, 18:53:43 schrieb Francesco Abbate: > Hi, > > thank you for the help. > > As suggested by Andreas, AGG_LDFLAGS does what I think should be done > and it works for me. > > As for the IMPORTED_TARGET approach, I still need to explicitly call > target_include_directories()

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

Am 2018-05-24 18:48, schrieb Francesco Abbate: Hi all, I stumbled in a problem with CMake. Everything is working fine except that, for two libraries that I locate with pkg-config, cmake does not include during linking the library's path (-L) which is given by pkg-config. Here an extract of

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

Florian Lindner wrote: Am 08.05.2018 um 15:12 schrieb Rolf Eike Beer: Am 2018-05-08 14:51, schrieb Florian Lindner: Hello, I try to compile my software like cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -DBUILD_SHARED_LIBS=off ../.. cat ../../toolchain.cmake SET(CMAKE_SYSTEM_NAME

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

Am 2018-05-08 14:51, schrieb Florian Lindner: Hello, I try to compile my software like cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -DBUILD_SHARED_LIBS=off ../.. cat ../../toolchain.cmake SET(CMAKE_SYSTEM_NAME Hazelhen) SET(CMAKE_C_COMPILER cc) SET(CMAKE_CXX_COMPILER CC)

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

Am Sonntag, 6. Mai 2018, 08:00:14 schrieb Andrew Brownsword: > Hi, > > Is there a way to get cmake 3.11 to emit 17 vs 1y when setting > CMAKE_CXX_STANDARD? I’m finding that it seems to be a common practice to > use the value of the preprocessor define __cplusplus (which is a date), and > the

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

Re: [CMake] link_libraries

Ranjeet Kuruvilla wrote: > I have read that link_libraries command has gotten deprecated for version > 3.10 and instead one needs to use link_librariestarget_link_libraries has > one major disadvantage, in that it is required to put that statement after > add_executable. I have here a CMake file

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

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

[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] FindIce module and C++11

Am Donnerstag, 10. August 2017, 10:28:31 schrieb rle...@codelibre.net: > On 2017-08-10 09:50, Jones J.W. wrote: > > I'm building my code on Linux using the g++ flags "-std=c++11". This > > means that I must link with the libIce++11 libraries instead of > > libIce. > > > > The FindIce module,

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

Am 2017-08-08 15:45, schrieb Jean-Michaël Celerier: Here's my CMakeLists.txt : cmake_minimum_required(VERSION 3.8 FATAL_ERROR) project(oscour) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined") set(CMAKE_EXE_LINKER_FLAGS

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

(and we don't use find_lib(QT) because once upon a time it was tried but not instantly found working for cross compiling). We're investigating whether we simply can switch to find_lib(QT) which should solve that. Does this make sense or am I mislead? I have used it for crosscompiling in

Re: [CMake] HOWTO cmake compatiblity?

Steffen Dettmer wrote: […] So far I think we need to install cmake into a versionized directory and invoke it: v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake and maybe remove cmake from PATH to ensure a failure if accidentally calling "cmake". What do you think? Having multiple

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

Am 2017-08-07 11:57, schrieb Björn Blissing: Hi Eike, 3. Some of my legacy projects have all source in the same directory, i.e. both source and header files are in the same directory. Others have both private and public headers in the same directory. How do I handle this with

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

Am 2017-08-07 11:35, schrieb Björn Blissing: Hi, I have some legacy projects which I intend to update to modern CMake. The documentation is good but do not really cover "best practices". So I have some questions which I hope some of you could help to answer: 1. Which version if CMake should I

Re: [CMake] Coverage support

Am 2017-08-07 11:06, schrieb Clément Gregoire: I usually stop reading Cmakelists.txt as soon as I see this set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 -fprofile-arcs -ftest-coverage") The pthread thing there is likely wrong anyway, and the -Wall is entirely

Re: [CMake] Coverage support

Am 2017-08-07 09:57, schrieb Clément Gregoire: Hi, I'm a bit stuck when trying to add coverage reports to Cmake (gcov + lcov) as I can't figure out what is the best (idiomatic) way to do it. So far here are the ways I know of : - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files

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] How do I specify VTK minimum version?

Am Dienstag, 11. Juli 2017, 15:18:11 schrieb Victor Lamoine: > Hi, > > I am using CMake to set up a VTK project. Our project requires VTK to be > version 7.1 or newer. I'm using Ubuntu 16.04 with CMake 3.5.1. > > find_package(VTK 7.1 REQUIRED) […] > The following configuration files were

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

Am Mittwoch, 12. Juli 2017, 18:31:56 schrieb René J. V. Bertin: > Andreas Naumann wrote: > > cmake instrospects your compiler and asks for system directories. Only > > these system directories will be removed and the corresponding libraries > > will be linked by -l<...>. So, you should check your

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] Status of "Modern" linking and modules?

Am 2017-06-15 10:19, schrieb Nicholas Devenish: I've been finding the 'modern' approaches of imported targets as used by e.g. Boost and some other modules much better - being able to specify all dependencies in a single target_link_libraries instead of hauling around a whole load of required

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] How to set libcurl library path and the library name?

Alex Chen wrote: > There is an error in the FindCURL document of Cmake 3.8 (or prior versions). No. > It says > > CURL_INCLUDE_DIRS - where to find curl/curl.h, etc. Which is what it is _setting_. > But in fact it is looking for CURL_INCLUDE_DIR, not CURL_INCLUDE_DIRS. If I > set

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

Re: [CMake] Multiple ELSE() clauses

Am 2017-03-20 11:57, schrieb Sergey Zakharchenko: Hello, I've just noticed that CMake doesn't forbid multiple ELSE() (not just ELSEIF()) clauses, and proceeds without warnings. IF(1) ELSE() ELSE() ENDIF() Is this expected? https://gitlab.kitware.com/cmake/cmake/issues/14335 -- -- Powered

[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] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

Adrian Sevcenco wrote: > Hi! I am trying to rebuild the f25 srpm on a centos 7 machine but after > a successful compilation i get this test error : > 99% tests passed, 1 tests failed out of 454 > > Label Time Summary: > Label1= 0.20 sec (1 test) > Label2= 0.20 sec (1 test) > > Total

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

955382db63 commit 50be50f8fd017a4f014aded68d81e1955382db63 Merge: 9a4338d 37ed860 Author: Rolf Eike Beer <e...@sf-mail.de> AuthorDate: Thu Feb 2 15:56:13 2017 -0500 Commit: CMake Topic Stage <kwro...@kitware.com> CommitDate: Thu Feb 2 15:56:13 2017 -0500 Merge topic 'g

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

ns in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45ffe4d2d2f45f04f9e5e5800cb374a2fc9fa18c commit 45ffe4d2d2f45f04f9e5e5800cb374a2fc9fa18c Merge: e7bbf8c 42820ea Author: Rolf Eike Beer <e...@sf-mail.d

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

e: bef58c6 f4de2ab Author: Rolf Eike Beer <e...@sf-mail.de> AuthorDate: Wed Feb 1 14:56:48 2017 -0500 Commit: CMake Topic Stage <kwro...@kitware.com> CommitDate: Wed Feb 1 14:56:48 2017 -0500 Merge topic 'gcc-features' into next f4de2ab5 GNU C++: record that -fvis

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

Re: [CMake] Find Vulkan on 32 bit builds

There's a couple of ways to fix this; for instance, on Windows I could use NO_DEFAULT_PATH on the find_library call and that would resolve the issue. The main reason why I haven't done this yet is because I think that's a packaging bug in the Vulkan SDK side which I was going to report there (I

[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] cmake vs. Python 3.4

Am Samstag, 24. Dezember 2016, 12:06:10 schrieb Rolf Eike Beer: > Am Freitag, 23. Dezember 2016, 20:57:49 schrieb Lev: > > Hi list, > > > > > > I have this: > > > > FIND_PACKAGE(PythonInterp) > > > > and cmake finds this: > > > &g

Re: [CMake] cmake vs. Python 3.4

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

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

ns in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ebb7ff5b9ba490a8645de7092c729f211b8cd464 commit ebb7ff5b9ba490a8645de7092c729f211b8cd464 Merge: b55c037 7ac8405 Author: Rolf Eike Beer <e...@sf-mail.d

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

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

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

e: 0fdba25 f3b3644 Author: Rolf Eike Beer <e...@sf-mail.de> AuthorDate: Mon Dec 19 08:47:33 2016 -0500 Commit: CMake Topic Stage <kwro...@kitware.com> CommitDate: Mon Dec 19 08:47:33 2016 -0500 Merge topic 'sparc-libatomic' into next f3b3644c explicitely link agai

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

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

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

e: 08f3161 5b5bdb2 Author: Rolf Eike Beer <e...@sf-mail.de> AuthorDate: Sat Dec 17 09:01:07 2016 -0500 Commit: CMake Topic Stage <kwro...@kitware.com> CommitDate: Sat Dec 17 09:01:07 2016 -0500 Merge topic 'gcc-34-features' into next 5b5bdb26 record features of gcc 3.4

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

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

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

ns in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9220290194fffec111890c28ff17ff0b79947a5b commit 9220290194fffec111890c28ff17ff0b79947a5b Merge: b5b7a71 78b6017 Author: Rolf Eike Beer <e...@sf-mail.d

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

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

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

ns in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35ca0a30dcc2048ccac57e1dec7756416abd3468 commit 35ca0a30dcc2048ccac57e1dec7756416abd3468 Merge: 369bfc7 d415b3c Author: Rolf Eike Beer <e...@sf-mail.d

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

ns in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=369bfc70d8548baaad751c11d36b88f7c2678f78 commit 369bfc70d8548baaad751c11d36b88f7c2678f78 Merge: 8c6f531 b59ed27 Author: Rolf Eike Beer <e...@sf-mail.d

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

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

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] Problem with ACME_Climate project on my.cdash.org

Am Freitag, 18. November 2016, 17:34:28 schrieb Burgess, Wade: > To whom it may concern, > > Firstly, if this is not the way I should seek assistance from Kitware, > please help me learn the correct way to do so. > Secondly, the ACME_Climate project on my.cdash.org is experiencing a problem >

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:

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

ns in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20 commit 0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20 Merge: 1366ab7 8dac3af Author: Rolf Eike Beer <e...@sf-mail.d

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

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

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

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

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

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

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

Gunter, Walter E wrote: > I am having some troubles getting cmake setup and wonder if cmake is the > right tool. > Thoughts? Suggestions? Yes, it is. I do it basically every day. Read my advise and properly set up a toolchain file, that is very likely the missing magic.

Re: [CMake] cross-compiling for arm

Gunter, Walter E wrote: > I setup the Main CMakeLists.txt to cross_compile using an arm toolchain: > > cmake_minimum_required(VERSION 3.2) > > project(enterprise CXX) > > set(CMAKE_SYSTEM_NAME Linux) > set(CMAKE_CXX_COMPILER > /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++) >

Re: [CMake] cross-compiling for arm

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

  1   2   3   4   5   6   7   8   9   10   >