Re: [CMake] How to on multiple RPM packages

Hi Thomas, CPack RPM may generate several packages at once if you define COMPONENTS in your project. The behavior of CPackRPM w.r.t. COMPONENT packaging depends on Some CPack COMPONENT generic variables, namelly: CPACK_RPM_COMPONENT_INSTALL --> this one must be set to ON CPACK_COMPONENTS_*

Re: [CMake] How to on multiple RPM packages

I've accidentally dropped the mailing list in reply: > I do not find an example on how to provide separate RPM's > for them; one for the binary and one for the headers+library. > The required results (rough example): > > - foo-1.2.3.4-1.x86_64.rpm > - libfoo-1.2.3.4-1.x86.64.rpm You have to

Re: [CMake] using macros

Yes, indeed. Yikes, thanks for this! On Thu, Jan 14, 2016, 17:21 Petr Kmoch wrote: > Hi Owen. > > As a sanity check, the definition of the macro in the toplevel CMakeList > comes *before* the add_subdirectory() command for the one which errors out, > right? > > Petr > > On

Re: [CMake] How to on multiple RPM packages

Hm I've accidentally dropped cmake mailing list when replying before... Sorry about that. > Im using "bin" and "devel" as component names. I tried next with upper and > lower case in the properties but no difference. > it's about what you see in the RPM header using "rpm -qlip name.rpm" ...

Re: [CMake] ExternalProject_Add support for git clone -o option

Why would you like to have names other than origin? I am struggling to think of a use case for this, seeing as you never directly interact with the cloned repository. I don't even think it's safe to assume that a git repository is involved at all, for all you know it could be changed to just

[CMake] ExternalProject_Add support for git clone -o option

Hello all, I am reading through the ExternalProject source for 3.2 at the moment (if updating to 3.4 is the answer, great!) and trying to determine if there is support for the -o option when using a git repository. Has anyone accomplished this? I would like to have names other than "origin"

Re: [CMake] ExternalProject_Add support for git clone -o option

To elaborate on my reply: I do indeed interact with the repository after it's cloned (as per my previous email). With regards to implementation, I have implemented it such that the git remote name is only involved if git is chosen as the source of choice, in much the same manner as the

Re: [CMake] ExternalProject_Add support for git clone -o option

My use case is for forked repositories and sending pull requests upstream. In this case "origin" is ambiguous as manage both remotes and I would like to give the cloned repository a more accurate name. Cheers, Adam -Original Message- From: Nicholas Braden

Re: [CMake] Changing the the current generator in CMake GUI

>You can not change the generator. It is better to remove the entire >build tree. Out of source builds are a best practice with CMake. Once >a build tree has been configured with one compiler, it must be >completely removed to change to a new compiler Clearly, "can not" is incorrect, since

Re: [CMake] Changing the the current generator in CMake GUI

On Fri, Jan 15, 2016 at 8:26 AM, mozzis wrote: > > Clearly, "can not" is incorrect, since I did. "must be" seems also > incorrect. Changing Generator is not exactly the same idea of what you're doing 1) If you actually chaned from VS 2010 to VS2012 or more radically to MinGW

Re: [CMake] Changing the the current generator in CMake GUI

On 1/15/2016 11:26 AM, mozzis wrote: You can not change the generator. It is better to remove the entire build tree. Out of source builds are a best practice with CMake. Once a build tree has been configured with one compiler, it must be completely removed to change to a new compiler

Re: [CMake] Changing the the current generator in CMake GUI

Bill Hoffman wrote: You can do it by changing the CMakeCache.txt file, but it won't work in the general case. You should put them in separate directories: build-32 and build-64. You can build both 32 and 64 from the same SOURCE tree, just not the same build tree.

Re: [CMake] Changing the the current generator in CMake GUI

On 1/15/2016 2:41 PM, Greg Marr wrote: You can do both in the same solution/projects with the Microsoft fork of CMake, but it's not a general solution, and it doesn't handle different settings for 32 bit and 64 bit. Because of that, they're "not pushing too hard" for it to be in mainline CMake.

Re: [CMake] Changing the the current generator in CMake GUI

Bill Hoffman wrote: >On 1/15/2016 2:41 PM, Greg Marr wrote: >> You can do both in the same solution/projects with the Microsoft fork >> of CMake, but it's not a general solution, and it doesn't handle >> different settings for 32 bit and 64 bit. > >Yes, and things like CMAKE_SIZEOF_VOID_P would

Re: [CMake] Changing the the current generator in CMake GUI

Well, CMAKE is the thing that is conflating this idea of a "generator" (which is clearly a concept in CMAKE's own domain of "build configuration generator") with the idea of "platform" or "architecture" (which is a concept in the domain of certain kinds of build tools, such as a C compiler.) It

[CMake] How to on multiple RPM packages

Hi, We are currently looking forward to migrate to CMake and we are struggling a bit with cpack. The first project we migrate provides a executable binary but also a library and its headers. I do not find an example on how to provide separate RPM's for them; one for the binary and one for the

[Cmake-commits] CMake branch, next, updated. v3.4.1-1971-ga0e5995

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via a0e599587c8ddd4898d6019fab52f01f9ddec4d3 (commit) via

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

(Ignore the last post. The last message sent accidentally before I was even close to done. Not sure why it sent. I must have accidentally discovered a hot key in Gmail. Everything is rewritten here.) Okay, I think I'm making some good progress. I got a trivial program built on Mac. I've now

[cmake-developers] RPATH bug + patch suggestion

Hi, I think there is a bug in the way CMake handles rpath for installed targets. My GCC installation contains the following definition in the specs file: *link_libgcc: %D -rpath <> This configuration leads to the following bug in CMake: Whenever a target (which depends on a library in

Re: [cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug

On 01/14/2016 04:12 PM, Tamás Kenéz wrote: > Is this really a bug or did I miss something? It is a bug. Good catch and thanks for the simple example. This should fix it: Fix export of STATIC library PRIVATE dependencies with CMP0022 NEW

Re: [cmake-developers] Git for windows patch

On 01/14/2016 06:48 PM, Shawn Waldon wrote: > patch that tells CMake to look in the default install location for > Git for Windows [2] when asked for git. This is expected to work already as follows. This code:

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

Okay, I think I'm making some good progress. I got a trivial program built on Mac. I've now switched to Linux. I'm mostly there, but there are still some things that need to be done. More inline... https://github.com/ewmailing/CMake/tree/SwiftMakefile >> Anyway, I tried bumping up

Re: [cmake-developers] Git for windows patch

Hi Kanstantin, Thanks for the feedback. The location of git that I have always used is "C:\Program Files [(x86)]\bin\git.exe". Looking at the git installation, there is another executable "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed CMake at that one. What is the

[Cmake-commits] CMake branch, next, updated. v3.4.1-1975-g718c6e8

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 718c6e8e33bfb666e7482504f429409df1c0b566 (commit) via

Re: [cmake-developers] Git for windows patch

On Fri, 2016-01-15 at 11:37 -0500, Jean-Christophe Fillion-Robin wrote: > > The existence of \bin is there only for backward > -compatibility > > I guess we could also add "Git/usr/bin" to the suffixes so that it > prefer newer version first ? > > PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin I'm

Re: [cmake-developers] Git for windows patch

On Fri, 2016-01-15 at 10:05 -0500, Shawn Waldon wrote: > Looking at the git installation, there is another executable > "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed > CMake at that one. What is the difference between the two? I can > change the patch to use the other one,

Re: [cmake-developers] Git for windows patch

Hi, > The existence of \bin is there only for backward -compatibility I guess we could also add "Git/usr/bin" to the suffixes so that it prefer newer version first ? PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin Hth Jc On Fri, Jan 15, 2016 at 11:24 AM, Paul Smith wrote:

[Cmake-commits] CMake branch, next, updated. v3.4.1-1979-g1f83d8a

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 1f83d8a365ec1859b59c596d275fe431126ea63f (commit) via

Re: [cmake-developers] Patch for ExternalProject_Add git clone -o support

On 01/15/2016 12:50 PM, Adam Rankin wrote: > I have attached a patch that provides an implementation of this parameter Thanks! Applied with minor tweaks and a release note: ExternalProject: Add option to set `git clone -o` argument https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83d63391

Re: [cmake-developers] Git for windows patch

On 01/15/2016 10:25 AM, Brad King wrote: > You'll have to investigate locally to determine why this method is > not working. It looks like a 64-bit CMake binary would not properly include the "Program Files (x86)" directory as a search location due to outdated assumptions. Please try this fix:

[cmake-developers] Patch for ExternalProject_Add git clone -o support

Hello all, As per my inquiry on the users mailing list, I have implemented support for the -origin parameter of git clone. It is backwards compatible as the parameter is optional and defaults to "origin". Example use case: After using ExternalProject_Add to download and built a supporting

[Cmake-commits] CMake branch, next, updated. v3.4.1-1977-g7a8ce54

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 7a8ce548243625cc405200c759759e424cf50f98 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.1-1981-g39120bf

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 39120bfffe6b2f24cc488bfacf37bc5ca60f5718 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.1-1983-g3f6e325

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 3f6e32535b336418d834e583f5731832c1b1dd85 (commit) via

Re: [cmake-developers] RPATH bug + patch suggestion

On 01/15/2016 09:47 AM, Lior Goldberg wrote: > Specifically, I think that the command "FILE(RPATH_REMOVE ...)" is not subtle > enough, as it removes the compiler's predefined rpath together with the rpath > added by CMake. Good catch, thanks. Patch applied with minor tweaks: install: Do not

[Cmake-commits] CMake branch, next, updated. v3.4.1-1991-gba89125

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via ba8912559febcc1614558d2fb08ec802aa6602f4 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.1-1985-ge37e3f1

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via e37e3f18ca209a04568c1d40420fb385fff71aad (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.1-1987-ga10f081

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via a10f0819c3ddff6527b8ff2524a66079a245468e (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.1-1989-g32e0619

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 32e061936368819a8dc60cac90e4997d60a0a9aa (commit) via

[cmake-developers] [CMake 0015921]: CUDA_nvcuvid_LIBRARY and CUDA_nvcuvenc_LIBRARY is never set to anything in FindCUDA.cmake

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15921 == Reported By:Jason Juang Assigned To:

[Cmake-commits] CMake branch, master, updated. v3.4.1-848-g66942a7

_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20160115) +set(CMake_VERSION_PATCH 20160116) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [cmake-developers] CMake alternative language

Throw in a > list(GET MyList ${i} ElementA) > list(GET MyOtherListOfSameSizeThanMyList ${i} ElementB) > foobazify(${ElementA} ${ElementB}) (I did not want to put a ginormous code snippet, just to outline the amount of code necessary to do simple things) On Fri, Jan 15,