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

[Eric Wing]

(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 switched to Linux. I'm mostly there, but there
are still some things that need to be done. More inline...


>> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
>> as Java). But it didn't seem to do anything for me.
>
> Where did you add the code to set it?

I got it working. I put it in.
CMakeSwiftCompiler.cmake.in
I figured out I also needed to add:
set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1)



>> Under the hood, I think the LLVM linker can handle all of these
>> through ld. But I think the thing that is tripping me up is that Swift
>> seems to need to link against some additional libraries which are not
>> needed in the pure C case. The swiftc command seems to know how to
>> automatically link in those extra dependencies (and I don't need to
>> add all the search paths to where the Swift core libraries are
>> located).
>
> That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
> the call to it in "Modules/CMakeDetermineCompilerABI.cmake".  That is
> responsible for extracting the implicit link information passed by a
> given language compiler's front-end.  We'll need to extract that for
> Swift.

I looked at this file, but I still havne't groked what I need to do
with this yet.

However, I'm heavily debating if 'cc' or 'clang' is the right thing to
do here. I'm starting to think 'swiftc' might be the most robust and
correct thing for the linking command. There are several reasons for
this:

- swiftc seems to already do the right thing

- Not using swiftc requires me to set a lot of things, including the
Apple SDK when on Mac. This feels really messy.

- On Linux, I think there is a danger in calling 'cc' because it could
be gcc or it could be an older version of clang. (Officially, clang
3.5 is needed, but the default one on the particular Linux I'm using
is less than that.) Invoking swiftc theoretically side-steps this
problem.


But if I use swiftc, I create a few new complications:

- First, CMake seems to be passing the flag -rdynamic to the link
instructions, and this is causing a "unknown argument" error. I think
this needs to be removed. I'm not sure where this flag is coming from.

- Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument"
error. As shown in the beginning of this thread, swiftc wants each
argument to lead with -Xlinker (and there is no -Wl,)
-Xlinker -rpath -Xlinker /foo/bar

Again, I'm not sure where the old stuff is, and what is involved to
inject the -Xlinker stuff.


Additionally, I realized I should have some other variable besides

Seems like I should have . I'm not sure what the
correct way to create this is.

However, I currently employ a clever cheat. Since the compiler is
'swift', and the linker is 'swiftc', I just do
'c'




>  cmMakefileTargetGenerator::WriteObjectBuildFile
> You should be able to call
>  this->GeneratorTarget->GetObjectSources(objectSources, config);

Okay, I added this code. It seems to be working. Though I'm not
completely sure I fetched config correctly.

My current changes can be found here in the SwiftMakefile branch
https://github.com/ewmailing/CMake/tree/SwiftMakefile


> and the Ninja generator here:
>
>  cmNinjaTargetGenerator::WriteCompileRule
>  cmNinjaTargetGenerator::WriteObjectBuildStatement
>
> Note that for Ninja we actually convert our placeholders to Ninja
> rule placeholders and then provide the values on the actual build
> statement line.
>

I actually don't' know anything about Ninja. I assume it is just a
string translation at this point since I did the other? Any guidance
on the mapping?


> Do we know that there is a one-to-one mapping between libraries
> and Swift modules?

Sorry, I'm still not completely up to speed on Swift modules. My
impression is there are 3 parts: .swiftmodule (which contains the
public interface/definitions), .swiftdoc (for documentation), and a
library (.a, .so). I suspect the .swiftmodule will need to be part of
the compile parameters and the library will be part of the link, but
I'm not sure if there will be additional requirements.


But anyway, I would like to get something building on Linux first, so
I need to fix the swiftc/linker stuff first. Any suggestions?

Then, I would like to enhance the trivial test to support actually
using something from the intermixed C files. This means I need to add
the bridging header parameter.
So I need a new per-target variable in CMake for this and a way to
inject it into the compiler flags, maybe something like this:

  " -frontend -c   
-import-objc-header  -primary-file
  -emit-module -module-name  -o
")


With those two pieces, I think that actually makes add_executable()
usable in the Makefile generator.

[cmake-developers] RPATH bug + patch suggestion

[Lior Goldberg]

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 the project) is created,
the rpath is completely removed from the installed targets (including the
linker's predefined rpath). This is not the case when there are no
dependencies on other libraries in the project.
Of course this can be fixed by changing CMake rpath-related variables but
I think that this suggests that the default rpath handling should be fixed.

(Note that the same behavior happens when "-Wl,-rpath" is used in
CMAKE_EXE_LINKER_FLAGS)

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. I suggest replacing it with the command "FILE(RPATH_CHANGE ...)"
(even when NEW_RPATH is empty) and allowing this command to decide
(based on the actual rpath defined in the file) whether the rpath entry should
be removed.

Attached is the suggested patch.

Please let me know what you think.

Thanks,
Lior


0001-Use-RPATH_CHANGE-instead-of-RPATH_REMOVE.patch
Description: Binary data
-- 

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] install(EXPORT) with PRIVATE dependency: possible bug

[Brad King]

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
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aea1b036

-Brad

-- 

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] Git for windows patch

[Brad King]

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:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/WindowsPaths.cmake;hb=v3.4.1#l25

adds the program files directories to CMAKE_SYSTEM_PREFIX_PATH. Then
the find_program call in FindGit:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindGit.cmake;hb=v3.4.1#l54

uses the PATH_SUFFIXES options "Git/cmd" and "Git/bin" to look in
the relevant install directories.

You'll have to investigate locally to determine why this method is
not working.

-Brad
-- 

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

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 CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
>> as Java). But it didn't seem to do anything for me.
>
> Where did you add the code to set it?

I got it working. I put it in.
CMakeSwiftCompiler.cmake.in
I figured out I also needed to add:
set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1)



>> Under the hood, I think the LLVM linker can handle all of these
>> through ld. But I think the thing that is tripping me up is that Swift
>> seems to need to link against some additional libraries which are not
>> needed in the pure C case. The swiftc command seems to know how to
>> automatically link in those extra dependencies (and I don't need to
>> add all the search paths to where the Swift core libraries are
>> located).
>
> That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
> the call to it in "Modules/CMakeDetermineCompilerABI.cmake".  That is
> responsible for extracting the implicit link information passed by a
> given language compiler's front-end.  We'll need to extract that for
> Swift.

I looked at this file, but I still havne't groked what I need to do
with this yet.

However, I'm heavily debating if 'cc' or 'clang' is the right thing to
do here. I'm starting to think 'swiftc' might be the most robust and
correct thing for the linking command. There are several reasons for
this:

- swiftc seems to already do the right thing
- Not using swiftc requires me to set a lot of things, including the
Apple SDK when on Mac. This feels really messy.
- On Linux, I think there is a danger in calling 'cc'.




realized I may need to take a step back.


>

>
>> I just tried not filtering the current primary file from the list. It
>> still worked. So maybe we can get away with not filtering that.
>
> Great.  It will be simplest to list all the sources in every call and then
> repeat the one that is current.
>
>> Anyway, it seems like adding SOURCES is the next step. Any hints on
>> how to do that?
>
> The cmLocalGenerator::ExpandRuleVariable method does the placeholder
> substitution.  It relies on values in the RuleVariables structure
> to be populated by the calling generator.  The Makefile generator
> populates that for the compile line here:
>
>  cmMakefileTargetGenerator::WriteObjectBuildFile
>
> and the Ninja generator here:
>
>  cmNinjaTargetGenerator::WriteCompileRule
>  cmNinjaTargetGenerator::WriteObjectBuildStatement
>
> Note that for Ninja we actually convert our placeholders to Ninja
> rule placeholders and then provide the values on the actual build
> statement line.
>
> You should be able to call
>
>  this->GeneratorTarget->GetObjectSources(objectSources, config);
>
> to get the list of source files and then filter it based on
> sf->GetLanguage().
>
> The name "" is not very good because it does not specify
> how any filtering is done.  Perhaps a special case name such as
> "" would be better.
>
> Do we know that there is a one-to-one mapping between libraries
> and Swift modules?
>
> -Brad
>
>


-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-- 

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] Git for windows patch

[Shawn Waldon]

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 difference between the
two?  I can change the patch to use the other one, but I'd like to
understand why it is necessary.

Thanks,
Shawn

On Thu, Jan 14, 2016 at 10:42 PM, Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:

> Hi, Shawn!
>
> I am using CMake and Git on the Windows. As an IDE I use Qt Creator.
>
> My experience is that on Windows you need to use:
>
> "C:\Program Files [(x86)]\Git\cmd\git.exe"
>
> If you use your proposed way, I'm having problems
> work with Git in my project.
>
> It seems to me that this decision is necessary to discuss here.
>
> Dear list, does anyone have experience and recommendations?
>
> 15.01.2016, 02:49, "Shawn Waldon" :
> > Hi,
> >
> > Recently I had to build a project on windows whose required build git.
> And even though I had installed git from here [1] in the default location,
> I had to tell CMake where to find it every time I did a build in a clean
> build tree. So here is a patch that tells CMake to look in the default
> install location for Git for Windows [2] when asked for git. I have tested
> it on my windows machine and it works there.
> >
> > Shawn
> >
> > [1]: https://git-for-windows.github.io/
> > [2]: C:\Program Files\Git\bin\git.exe ('Program Files (x86)' for older
> versions or 32 bit systems)
> > ,--
> >
> > 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
>
>
> Regards,
> Konstantin Podsvirov
>
-- 

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] Git for windows patch

[Paul Smith]

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 not sure which command you're looking for?

git.exe exists only in Git/bin (old-style) and Git/cmd.  Where both
exist they'll have exactly the same version of git.exe in them.

I think using Git/cmd only to find git.exe is fine; I'm pretty sure
it's always existed there even in older releases of Git for Windows, an
d will continue to do so going forward.

You definitely don't need Git/usr/bin unless you want to find all the
UNIX tools.  Git.exe is not there.
-- 

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] Git for windows patch

[Paul Smith]

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, but I'd like to understand why
> it is necessary.

There is no difference between them.  When you install Git for Windows
the installer gives a choice of three different ways to set up %PATH%.

One way is to not add anything to %PATH%: then git is only available
from within the Git bash shell not from within command.com shell.

The second way is to make git, only (plus a few helpers like gitk,
start-ssh-agent, etc.) available on %PATH%: then git is available from
command.com but none of the other UNIX tools like find, diff, etc. are
available from command.com (only from Git shell).  In this install
method the \cmd directory is added to %PATH%.

The last way is to allow git plus all the ming32 versions of UNIX tools
that come with Git to be available to command.com.  In this install
method both \cmd AND \usr\bin are added to %PATH%.

The existence of \bin is there only for backward
-compatibility, because some people coming from older versions of Git
for Windows might be referencing it.  It shouldn't be used anymore by
modern installs (it contains bash.exe and sh.exe both of which are in
\usr\bin, and git.exe which is in \cmd).
-- 

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] Git for windows patch

[Jean-Christophe Fillion-Robin]

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:

> 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, but I'd like to understand why
> > it is necessary.
>
> There is no difference between them.  When you install Git for Windows
> the installer gives a choice of three different ways to set up %PATH%.
>
> One way is to not add anything to %PATH%: then git is only available
> from within the Git bash shell not from within command.com shell.
>
> The second way is to make git, only (plus a few helpers like gitk,
> start-ssh-agent, etc.) available on %PATH%: then git is available from
> command.com but none of the other UNIX tools like find, diff, etc. are
> available from command.com (only from Git shell).  In this install
> method the \cmd directory is added to %PATH%.
>
> The last way is to allow git plus all the ming32 versions of UNIX tools
> that come with Git to be available to command.com.  In this install
> method both \cmd AND \usr\bin are added to %PATH%.
>
> The existence of \bin is there only for backward
> -compatibility, because some people coming from older versions of Git
> for Windows might be referencing it.  It shouldn't be used anymore by
> modern installs (it contains bash.exe and sh.exe both of which are in
> \usr\bin, and git.exe which is in \cmd).
> --
>
> 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
>



-- 
+1 919 869 8849
-- 

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 ExternalProject_Add git clone -o support

[Brad King]

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

-Brad

-- 

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] Git for windows patch

[Brad King]

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:

 Windows: Find Program Files directories more robustly from environment
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09b2f1c3

-Brad

-- 

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 for ExternalProject_Add git clone -o support

[Adam Rankin]

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 library, 
development of that library is needed. In the case of github/bitbucket, the 
cloned repository can be a fork. To simplify management, providing a more 
descriptive remote name is desired.

Usage:
  ExternalProject_Add( OpenIGTLink
"${PLUSBUILD_EXTERNAL_PROJECT_CUSTOM_COMMANDS}"
SOURCE_DIR "${PLUS_OpenIGTLink_SRC_DIR}"
BINARY_DIR "${PLUS_OpenIGTLink_DIR}"
#--Download step--
GIT_REPOSITORY "${GIT_PROTOCOL}://github.com/adamrankin/OpenIGTLink.git"
GIT_TAG "master"
GIT_REMOTE_NAME "adamrankin_igtl"
#--Configure step-
...

I have attached a patch that provides an implementation of this parameter and 
tested it for both cloning and updating.

Feedback is appreciated and I hope this is of use for others.

Kind regards,
Adam


git_remote_name_support.patch
Description: git_remote_name_support.patch
-- 

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] RPATH bug + patch suggestion

[Brad King]

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 remove compiler-defined RPATH entries
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ec92267

-Brad

-- 

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] [CMake 0015921]: CUDA_nvcuvid_LIBRARY and CUDA_nvcuvenc_LIBRARY is never set to anything in FindCUDA.cmake

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15921 
== 
Reported By:Jason Juang
Assigned To:
== 
Project:CMake
Issue ID:   15921
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-15 18:10 EST
Last Modified:  2016-01-15 18:10 EST
== 
Summary:CUDA_nvcuvid_LIBRARY and CUDA_nvcuvenc_LIBRARY is
never set to anything in FindCUDA.cmake
Description: 
The variables CUDA_nvcuvenc_LIBRARY and CUDA_nvcuvid_LIBRARY is never set to
anything in FindCUDA.cmake, despite it being two of the variables and is suppose
to represent libnvcuvenc.so and libnvcuvid.so. 

Additionally, there are comments saying that these are windows only which is
outdated because now the CUDA video SDK is also available in linux.

Steps to Reproduce: 
At any CMakeLists.txt:

find_package( CUDA REQUIRED )

message(cuda decoder lib ${CUDA_nvcuvid_LIBRARY})

message(cuda encoder lib ${CUDA_nvcuvenc_LIBRARY})

Nothing will be there. 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-15 18:10 Jason JuangNew Issue
==

-- 

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

[Jean-Michaël Celerier]

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, 2016 at 1:28 AM, J Decker  wrote:

> On Thu, Jan 14, 2016 at 3:09 PM, Jean-Michaël Celerier
>  wrote:
> > The problem is doing :
> >
> > list(LENGTH MyList NumList)
> > math(EXPR MaxItList ${NumList}-1)
> >
> > foreach(i RANGE ${MaxItList})
> > list(GET MyOtherListOfSameSizeThanMyList ${i} Element)
> > foobazify(${Element})
> > endforeach()
> >
> Probably a bad exmple, since you're not using MyList or i that simplifies
> to
>
> foreach( Element ${MyOtherListOfSameSizeThanMylist} )
> foobazify( ${Element} )
> endforeach()
>
> > instead of :
> >
> > for i in range(0, MyList.size):
> > foobazifiy(MyOtherListOfSameSizeThanMyList[i])
> >
> >
> >
> >
> >
> > On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
> > wrote:
> >>
> >> As long as CMake embeds everything that is required, I don't see the
> >> additional pain (since this is what it already does with the CMake
> >> language).
> >>
> >>
> >> Le jeu. 14 janv. 2016 à 13:35, Jean-Michaël Celerier
> >>  a écrit :
> >>>
> >>>
> >>> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf  >
> >>> wrote:
> 
> 
>  My personal opinion: if the full power of python would be available,
> the
>  build
>  scripts would quickly turn into real programs, because programmers
> would
>  be
>  tempted to do so if all of python would be available. Then developers
>  would
>  have to understand two programs: the program itself, and the "build
>  program".
> >>>
> >>>
> >>> The problem is when you have to do a real program for your build system
> >>> anyways (which occurs one day or another for any large enough project I
> >>> guess).
> >>> Currently it's a real pain (but it'd be even more painful to have to
> ship
> >>> Python / Bash / $script_language as part of your build system).
> >>> --
> >>>
> >>> 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
> >
> >
> >
> > --
> >
> > 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
>
-- 

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