From y.piao.us at ieee.org  Thu Jan  1 09:09:13 2015
From: y.piao.us at ieee.org (Yong Piao)
Date: Thu, 1 Jan 2015 09:09:13 -0500
Subject: [cmake-developers] Greetings!
Message-ID: <CADkBgUWgJZWwpdgCJAdJajqytrewMz4RA5ijH9ui-UqSVS7W3A@mail.gmail.com>

Hi everyone-

My name is Frank, I am a graduating college student. I have been enjoying
CMake for a bit more than a year and I think I am finally confident to
start contributing!

Recently I have been working on Purify
<https://github.com/piaoasd123/PurifySampleProject>, an auto build toolkit
I developed with CMake. It is a relatively new project but my friends and I
have been using it consistently for Visual Studio based C++ projects. Be
sure to check it out!

I also have an idea for the existing FindGit module. I came across this
idea because I am currently using batch script to locate the portable Git
contained in GitHub for Windows and have found it working very
consistently. I think it would be great to add this functionality for those
who exclusively use GitHub.

Let me know what you think!

Sincerely,
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150101/d0260c46/attachment.html>

From justin.borodinsky at gmail.com  Thu Jan  1 14:22:54 2015
From: justin.borodinsky at gmail.com (Justin Borodinsky)
Date: Thu, 1 Jan 2015 14:22:54 -0500
Subject: [cmake-developers] [PATCH] Source file AUTOUIC_OPTIONS were not
	being set
Message-ID: <CAFdhTuMxseOj4fkPK0md=GDwF8ptbT3fKF7FC4==sOw8PrTW4w@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150101/795d3722/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Source-file-AUTOUIC_OPTIONS-were-not-being-set.patch
Type: application/octet-stream
Size: 832 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150101/795d3722/attachment.obj>

From mantis at public.kitware.com  Thu Jan  1 20:45:17 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 1 Jan 2015 20:45:17 -0500
Subject: [cmake-developers] [CMake 0015332]: Feature request for giving
	CMake the ability to define C++11 generic attributes.
Message-ID: <461a517fe41033702714b2d752468f01@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15332 
====================================================================== 
Reported By:                Ezekiel Warren
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15332
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-01 20:45 EST
Last Modified:              2015-01-01 20:45 EST
====================================================================== 
Summary:                    Feature request for giving CMake the ability to
define C++11 generic attributes.
Description: 
The proposed feature would allow developers to define generic attributes so that
a CMake script may be ran at build time when they are encountered.

A possible syntax could be similar to functions. Additionally with variables
defined within function-like scope that hold information on the attribute.  

attribute(<name> [arg1 [arg2 [arg3 ...]]])
  
  ${ATTRIBUTE_TYPE} # could be "class", "function", "namespace", etc. 
  
endattribute(<name>)

Compilers such as gcc give the ability to write plugins that could be used to
implement this feature. Other compilers may have other ways to accomplish this,
but if a compiler doesn't there could be a fail safe that would require CMake to
parse the code itself (not ideal.)

I'm not sure if such a feature falls in CMake's scope of responsibilities, but I
thought I'd get some feedback.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-01 20:45 Ezekiel Warren New Issue                                    
======================================================================


From neundorf at kde.org  Fri Jan  2 15:48:12 2015
From: neundorf at kde.org (Alexander Neundorf)
Date: Fri, 02 Jan 2015 21:48:12 +0100
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
Message-ID: <2005590.8riUHD6eAy@tuxedo.neundorf.net>

On Tuesday, December 23, 2014 01:30:58 Aleix Pol wrote:
> On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
...
> > * No progress indication. Since the generation may take several minutes,
> > 
> >   providing feedback is crucial.
> 
> I never found such case, I would argue that a project which has a
> cmake script that takes several minutes is broken, but maybe we can
> open a thread to discuss it?

On network file systems things can get slow... (even if the file system feels 
really fast in general usage, i.e. has high data throuhgput).

...
> > * Not sure if it?s possible at all - a lightweight phase where CMake only
> > 
> >   collects necessary information (list of files/targets, compiler
> >   settings).
> >   This will help IDE react to the changes much faster.
> 
> That would be extra-cool, agreed. Maybe it's an iteration we can
> consider in the future.


Yes, this would be cool, but until now whenever I thought about this my 
conclusion was that this is unfortunately not possible, since the 
targets/files/etc. can depend on anything, if() clauses, execution of 
commands, results of find_package(), etc.
 
Alex


From mantis at public.kitware.com  Fri Jan  2 18:39:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 2 Jan 2015 18:39:07 -0500
Subject: [cmake-developers] [CMake 0015333]: Behaviour change with 3.1 -
	target properies set to empty string returned as -NOTFOUND
Message-ID: <328fee4624e154fcd29bb7fe65585cf3@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15333 
====================================================================== 
Reported By:                arlbranch
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15333
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-02 18:39 EST
Last Modified:              2015-01-02 18:39 EST
====================================================================== 
Summary:                    Behaviour change with 3.1 - target properies set to
empty string returned as -NOTFOUND
Description: 
Under the old behaviour, when a target property was set to "",
get_target_property would give "". In version 3.1 it now gives prop-NOTFOUND.
Needless to say, this change breaks build systems that relied on the old
behaviour.

Steps to Reproduce: 
CMakeLists.txt
---------------
cmake_minimum_required(VERSION 2.8.0)

add_custom_target(tgt)
set_target_properties(tgt PROPERTIES emptyprop "")
get_target_property(val tgt emptyprop)
message("val = ${val}")
---------------

Old Behaviour
---------------
[branch at viter on /dev/pts/9] 1044 ~/tmp/cm31bug/build
$ cmake --version
cmake version 2.8.12.2
[branch at viter on /dev/pts/9] 1045 ~/tmp/cm31bug/build
$ cmake ..
val = 
-- Configuring done
-- Generating done
-- Build files have been written to: /local/home/branch/tmp/cm31bug/build
----------------

New Behaviour
----------------
$ cmake --version
cmake version 3.1.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).
[branch at fortuna on /dev/pts/5] 1054 ~/tmp/cm31bug/fbuild
$ cmake ..
val = val-NOTFOUND
-- Configuring done
-- Generating done
-- Build files have been written to: /home/branch/tmp/cm31bug/fbuild
----------------

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-02 18:39 arlbranch      New Issue                                    
======================================================================


From mantis at public.kitware.com  Sat Jan  3 19:34:31 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 3 Jan 2015 19:34:31 -0500
Subject: [cmake-developers] [CMake 0015334]: CMake cannot work
Message-ID: <68c2b5110643b6e2fa313f45578f4419@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15334 
====================================================================== 
Reported By:                jhuang
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15334
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   immediate
Status:                     new
====================================================================== 
Date Submitted:             2015-01-03 19:34 EST
Last Modified:              2015-01-03 19:34 EST
====================================================================== 
Summary:                    CMake cannot work
Description: 
I installed the latest CMake from Binary and try to test it with a very simple
project, but there're some error in console:

-------------------Console output---------------------------------

-- The C compiler identification is unknown
CMake Error at /home/jhuang/local/package/cmake-3.1.0-Linux-x86_64/share/cmake-3
                                        
.1/Modules/CMakeDetermineCCompiler.cmake:172 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- The CXX compiler identification is unknown
CMake Error at /home/jhuang/local/package/cmake-3.1.0-Linux-x86_64/share/cmake-3
                                        
.1/Modules/CMakeDetermineCXXCompiler.cmake:170 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Check for working C compiler: /usr/bin/cc
CMake Error at /home/jhuang/local/package/cmake-3.1.0-Linux-x86_64/share/cmake-3
                                         .1/Modules/CMakeTestCCompiler.cmake:47
(try_compile):
  Unknown extension ".c" for file

    /home/jhuang/cmake_test/CMakeFiles/CMakeTmp/testCCompiler.c

  try_compile() works only for enabled languages.  Currently these are:

    C CXX

  See project() command to enable other languages.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /home/jhuang/local/package/cmake-3.1.0-Linux-x86_64/share/cmake-3
                                         .1/Modules/CMakeTestCCompiler.cmake:61
(message):
  The C compiler "/usr/bin/cc" is not able to compile a simple test program.

  It fails with the following output:





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "/home/jhuang/cmake_test/CMakeFiles/CMakeOutput.log".
See also "/home/jhuang/cmake_test/CMakeFiles/CMakeError.log".
-------------------Console output---------------------------------

Following is the 172 in CMakeDetermineCCompiler.cmake 
# configure variables set in this file for fast reload later on
configure_file(${CMAKE_ROOT}/Modules/CMakeCCompiler.cmake.in
  ${CMAKE_PLATFORM_INFO_DIR}/CMakeCCompiler.cmake
  @ONLY
  )

Why there's an CMakeERROR on this line, no any hints, even in the
CMakeOutput.log and CMakeError.log
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-03 19:34 jhuang         New Issue                                    
2015-01-03 19:34 jhuang         File Added: CMakeLog and CMakeList.txt          
         
======================================================================


From mark.j.abraham at gmail.com  Sun Jan  4 08:47:46 2015
From: mark.j.abraham at gmail.com (Mark Abraham)
Date: Sun, 4 Jan 2015 14:47:46 +0100
Subject: [cmake-developers] patch for FindCUDA.cmake
Message-ID: <CAMNuMAT+=39Cs5i70f6+DBoS70bPYU3Fq_4AWXduWjf28P2d-Q@mail.gmail.com>

Hi,

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

I haven't filed a bug report, per
http://www.cmake.org/Wiki/CMake_FAQ#I_found_a_Bug.21_What_should_I_do.3F

Thanks,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150104/296900d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-FindCUDA.cmake-assumption-about-cross-compiling.patch
Type: text/x-patch
Size: 1788 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150104/296900d8/attachment-0001.bin>

From eike at sf-mail.de  Sun Jan  4 09:02:23 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Sun, 04 Jan 2015 15:02:23 +0100
Subject: [cmake-developers] patch for FindCUDA.cmake
In-Reply-To: <CAMNuMAT+=39Cs5i70f6+DBoS70bPYU3Fq_4AWXduWjf28P2d-Q@mail.gmail.com>
References: <CAMNuMAT+=39Cs5i70f6+DBoS70bPYU3Fq_4AWXduWjf28P2d-Q@mail.gmail.com>
Message-ID: <1462492.A3OEPouZdB@eto>

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

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

if (? CMAKE_SYSTEM_PROCESSOR MATCHES arm ?)

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150104/df38968c/attachment.sig>

From mark.j.abraham at gmail.com  Sun Jan  4 18:22:51 2015
From: mark.j.abraham at gmail.com (Mark Abraham)
Date: Mon, 5 Jan 2015 00:22:51 +0100
Subject: [cmake-developers] patch for FindCUDA.cmake
In-Reply-To: <1462492.A3OEPouZdB@eto>
References: <CAMNuMAT+=39Cs5i70f6+DBoS70bPYU3Fq_4AWXduWjf28P2d-Q@mail.gmail.com>
 <1462492.A3OEPouZdB@eto>
Message-ID: <CAMNuMASrLNHHhuFJsJ1Pi6YQf6DKfwWt3en458b9OoxPCZfvbg@mail.gmail.com>

On Sun, Jan 4, 2015 at 3:02 PM, Rolf Eike Beer <eike at sf-mail.de> wrote:

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


Hi,

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

Updated patch attached.

Mark


>
> Eike
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/90e22440/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-FindCUDA.cmake-assumption-about-cross-compiling.patch
Type: text/x-patch
Size: 1778 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/90e22440/attachment.bin>

From mantis at public.kitware.com  Sun Jan  4 21:19:40 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 4 Jan 2015 21:19:40 -0500
Subject: [cmake-developers] [CMake 0015335]: if () evaluates to FALSE for
	quoted constants/variables where the contents are non-null
	and not defined constants
Message-ID: <4b9aff4d320851719ac444460554e919@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15335 
====================================================================== 
Reported By:                Brian Chojnowski
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15335
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-04 21:19 EST
Last Modified:              2015-01-04 21:19 EST
====================================================================== 
Summary:                    if () evaluates to FALSE for quoted
constants/variables where the contents are non-null and not defined constants
Description: 
An if statement should evaluate to TRUE if the variable is not-null and is not a
defined false constant.

>From the documentation:

if(<constant>)
True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if the
constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, or ends in
the suffix -NOTFOUND. Named boolean constants are case-insensitive. If the
argument is not one of these constants, it is treated as a variable.
if(<variable>)
True if the variable is defined to a value that is not a false constant. False
otherwise. (Note macro arguments are not variables.)

Steps to Reproduce: 
set(myvar "not a false constant")
message(STATUS "myvar=${myvar}")
if(myvar)
    message(STATUS "un quoted variable name = TRUE")
endif()
if(${myvar})
    message(STATUS "un quoted variable contents = TRUE")
endif()
if("${myvar}")
    message(STATUS "quoted variable = TRUE")
endif()

Output:

Eclipse version is set to 4.4 (). Adjust CMAKE_ECLIPSE_VERSION if this is wrong.
myvar=test string
un quoted variable name = TRUE
Configuring done
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-04 21:19 Brian ChojnowskiNew Issue                                    
======================================================================


From eike at sf-mail.de  Mon Jan  5 07:15:32 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 05 Jan 2015 13:15:32 +0100
Subject: [cmake-developers] patch for FindCUDA.cmake
In-Reply-To: <CAMNuMASrLNHHhuFJsJ1Pi6YQf6DKfwWt3en458b9OoxPCZfvbg@mail.gmail.com>
References: <CAMNuMAT+=39Cs5i70f6+DBoS70bPYU3Fq_4AWXduWjf28P2d-Q@mail.gmail.com>
 <1462492.A3OEPouZdB@eto>
 <CAMNuMASrLNHHhuFJsJ1Pi6YQf6DKfwWt3en458b9OoxPCZfvbg@mail.gmail.com>
Message-ID: <5010317.JeqFIRG8g4@caliban.sf-tec.de>

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

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

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

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

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/9ae63298/attachment.sig>

From Robert.Goulet at autodesk.com  Mon Jan  5 14:09:03 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Mon, 5 Jan 2015 19:09:03 +0000
Subject: [cmake-developers] target_link_libraries and
	--start-group/--end-group ?
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi,

My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax:

-Wl,--start-group ...libs... -Wl,--end-group

...so that the linker is able to correctly find all symbols. What's the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks!



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616
DIRECT +1 514 954 3911
MOBILE +1 438 397 4075

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com<http://www.autodesk.com/>

[Description: Email_Signature_Logobar]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/98c52cd8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/98c52cd8/attachment-0001.jpg>

From mantis at public.kitware.com  Mon Jan  5 16:13:44 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 5 Jan 2015 16:13:44 -0500
Subject: [cmake-developers] [CMake 0015336]: When property USE_FOLDERS is ON,
	the generated VS solution is not sorted propertly
Message-ID: <17e6c8d178a924ab30265c74ed8f19a9@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15336 
====================================================================== 
Reported By:                Scott Aron Bloom
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15336
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-05 16:13 EST
Last Modified:              2015-01-05 16:13 EST
====================================================================== 
Summary:                    When property USE_FOLDERS is ON, the generated VS
solution is not sorted propertly
Description: 
WHen I turn on the USE_FOLDERS property, via
set_property(GLOBAL PROPERTY USE_FOLDERS ON), and set the appropriate property
on each project, the folders are not added to the top level solution in a sorted
manner.

Also, the projects themselves are not added to the folder in a sorted manner.


Steps to Reproduce: 
Run cmake on the attached project
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-05 16:13 Scott Aron BloomNew Issue                                    
2015-01-05 16:13 Scott Aron BloomFile Added: lab5.zip                         
======================================================================


From robert.maynard at kitware.com  Mon Jan  5 16:21:37 2015
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 5 Jan 2015 16:21:37 -0500
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>

I believe what you want to do is bring the libraries in as imported targets
and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY (
http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html
).

By default the value should be 2 which means that we will list all static
libraries twice, but you might need to increase the value.

I would also read the resolution of bug 14463 (
http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation of
how the target_link_libraries order determines the static link ordering.


On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet <Robert.Goulet at autodesk.com>
wrote:

>  Hi,
>
>
>
> My project needs to link with an external library which actually consist
> of a set of libraries. Adding these libs using target_link_libraries should
> be working just fine but unfortunately these libs have a bunch of circular
> dependencies, so it fails. In the makefile, we link with these libs using
> this syntax:
>
>
>
> -Wl,--start-group ?libs? -Wl,--end-group
>
>
>
> ?so that the linker is able to correctly find all symbols. What?s the
> proper way to deal with this using CMake? I tried to add the group flags to
> target_link_libraries but it does not work. Thanks!
>
>
>
>
>
>
>
> *Robert Goulet*
>
> Senior Software Developer
>
> Games Solutions Group
>
> Autodesk Media & Entertainment
>
>
>
> *MAIN* +1 514 393 1616
>
> *DIRECT* +1 514 954 3911
>
> *MOBILE* +1 438 397 4075
>
>
>
> *Autodesk, Inc.*
>
> 10 Rue Duke
>
> Montreal, QC, H3C 2L7
>
> www.autodesk.com
>
>
>
> [image: Description: Email_Signature_Logobar]
>
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/e88a3d20/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150105/e88a3d20/attachment-0001.jpg>

From gjasny at googlemail.com  Tue Jan  6 01:19:36 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Tue, 06 Jan 2015 07:19:36 +0100
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54AB7E78.8080308@googlemail.com>

Hello,

On 05/01/15 20:09, Robert Goulet wrote:
> My project needs to link with an external library which actually consist
> of a set of libraries. Adding these libs using target_link_libraries
> should be working just fine but unfortunately these libs have a bunch of
> circular dependencies, so it fails. In the makefile, we link with these
> libs using this syntax:
>
> -Wl,--start-group ?libs? -Wl,--end-group
>
> ?so that the linker is able to correctly find all symbols. What?s the
> proper way to deal with this using CMake? I tried to add the group flags
> to target_link_libraries but it does not work. Thanks!

I'm not 100% sure that this also works with circular dependencies, but 
you could create an IMPORTED target per library and declare its 
dependencies via INTERFACE_LINK_LIBRARIES.

Adding the imported ones to your executable should do the right thing.

Thanks,
Gregor

PS: This list is mainly for development of CMake; cmake at cmake.org is for 
the actual consumers.

From mantis at public.kitware.com  Tue Jan  6 10:23:20 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 6 Jan 2015 10:23:20 -0500
Subject: [cmake-developers] [CMake 0015338]: Querying for (deprecated)
	LOCATION property prevents expansion of TARGET_OBJECTS
	generator expression
Message-ID: <af3433e6a33c4455f0e3d90a10c01e2a@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15338 
====================================================================== 
Reported By:                Matthias Maier
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15338
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-06 10:23 EST
Last Modified:              2015-01-06 10:23 EST
====================================================================== 
Summary:                    Querying for (deprecated) LOCATION property prevents
expansion of TARGET_OBJECTS generator expression
Description: 
Consider the following minimal project:

foo.cc
    int main () {}

CMakeLists.txt$<TARGET_OBJECTS:foo>
    add_library(foo OBJECT foo.cc)
    add_executable(bar $<TARGET_OBJECTS:foo>)
    get_target_property(location bar LOCATION)

Starting with CMake 3.1 above example fails with an error message ("CMake Error:
CMake can not determine linker language for target: bar") because the generator
expression "$<TARGET_OBJECTS:foo>" does not get expanded and thus the final link
line is empty.

Not querying for the LOCATION property fixes this.
This bug is not present in CMake 3.0.* or 2.8.*.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-06 10:23 Matthias Maier New Issue                                    
======================================================================


From ppietraszkiewicz at psi.de  Tue Jan  6 14:13:31 2015
From: ppietraszkiewicz at psi.de (Pietraszkiewicz, Piotr)
Date: Tue, 6 Jan 2015 20:13:31 +0100
Subject: [cmake-developers] [PATCH] FindCURL: Search for Windows
	debugbuilds as well
In-Reply-To: <3504156.qAej1ZuaQ6@caliban.sf-tec.de>
References: <6A111E4E6826BD4E826D9EFED1970381A08208@INFRA-BLN-EXP.psi.de>
 <6A111E4E6826BD4E826D9EFED1970381A0820A@INFRA-BLN-EXP.psi.de>
 <3504156.qAej1ZuaQ6@caliban.sf-tec.de>
Message-ID: <6A111E4E6826BD4E826D9EFED1970381A08218@INFRA-BLN-EXP.psi.de>

Thank you for the hint.  How do you find my second attempt? See attachment.

Piotr

-----Urspr?ngliche Nachricht-----
Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im Auftrag von Rolf Eike Beer
Gesendet: Freitag, 19. Dezember 2014 13:39
An: cmake-developers at cmake.org
Betreff: Re: [cmake-developers] [PATCH] FindCURL: Search for Windows debugbuilds as well

Am Freitag, 19. Dezember 2014, 12:31:24 schrieb Pietraszkiewicz, Piotr:
> Please forgive me the patch below. It looks my email client (MS 
> Outlook) tempered with the content after I pressed "Send". Here it 
> comes again as attachment.

The right way would be to do another find_library() into a different variable, and then use SelectLibraryConfigurations.cmake to merge the results into CURL_LIBRARIES, so it will work with any combination of libs found. That way linking will work on Windows if you switch between debug and release configurations.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindCURL-Search-for-Windows-debug-builds-as-well_TRY2.patch
Type: application/octet-stream
Size: 2137 bytes
Desc: 0001-FindCURL-Search-for-Windows-debug-builds-as-well_TRY2.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150106/448eea76/attachment.obj>

From Robert.Goulet at autodesk.com  Tue Jan  6 15:50:47 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 6 Jan 2015 20:50:47 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>

Thanks Robert,

But it doesn?t seems to work when building for NVidia NSight Android platform using Visual Studio IDE. Is there a way to add custom flags before and after the flags set by target_link_libraries? I tried CMAKE_LINK_EXE_FLAGS but it doesn?t work. Thanks!

From: Robert Maynard [mailto:robert.maynard at kitware.com]
Sent: Monday, January 5, 2015 4:22 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

I believe what you want to do is bring the libraries in as imported targets and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY ( http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html ).

By default the value should be 2 which means that we will list all static libraries twice, but you might need to increase the value.

I would also read the resolution of bug 14463 (http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation of how the target_link_libraries order determines the static link ordering.


On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet <Robert.Goulet at autodesk.com<mailto:Robert.Goulet at autodesk.com>> wrote:
Hi,

My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax:

-Wl,--start-group ?libs? -Wl,--end-group

?so that the linker is able to correctly find all symbols. What?s the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks!



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616<tel:%2B1%20514%20393%201616>
DIRECT +1 514 954 3911<tel:%2B1%20514%20954%203911>
MOBILE +1 438 397 4075<tel:%2B1%20438%20397%204075>

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com<http://www.autodesk.com/>

[Description: Email_Signature_Logobar]


--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150106/00118930/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150106/00118930/attachment-0001.jpg>

From mantis at public.kitware.com  Wed Jan  7 08:46:43 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Jan 2015 08:46:43 -0500
Subject: [cmake-developers] [CMake 0015339]: CXX_STANDARD does not support
	C++03 and C++14
Message-ID: <f2b0474634149110af262b3b233895c0@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15339 
====================================================================== 
Reported By:                Pawe? Stankowski
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15339
Category:                   CMake
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-07 08:46 EST
Last Modified:              2015-01-07 08:46 EST
====================================================================== 
Summary:                    CXX_STANDARD does not support C++03 and C++14
Description: 
CXX_STANDARD support only '98' and '11', but there is also C++03 standard that
should be supported. When CXX_EXTENSIONS property is ON, "-std=gnu98" should be
used, "-std=c++03" otherwise.

C++14 standard is now finalized, so it could be added to CMake as well.
GCC supports it since 4.8, Clang has complete support in version 3.4. MSVC 2013
also supports some C++14 features, but it does not need to be asked for enabling
them.

C++17 also may be enabled in newest clang by passing "-std=c++1z" argument. Not
sure whether you are keen to standard drafts support to CMake, but you could add
it as '1z' and then remove it when c++17 is finally published. I would not use
'17' as its name, as name may be changed (C++11 was initialially called c++0x,
because it was supposed to be published before 2010).
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-07 08:46 Pawe? StankowskiNew Issue                                    
======================================================================


From mantis at public.kitware.com  Thu Jan  8 10:18:42 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 8 Jan 2015 10:18:42 -0500
Subject: [cmake-developers] [CMake 0015342]: [AUTOUI] Simplifiy wrong headers
Message-ID: <7e4a8dbd061e43516c6ed28c21ed3679@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15342 
====================================================================== 
Reported By:                SunBlack
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15342
Category:                   CMake
Reproducibility:            always
Severity:                   text
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-08 10:18 EST
Last Modified:              2015-01-08 10:18 EST
====================================================================== 
Summary:                    [AUTOUI] Simplifiy wrong headers
Description: 
If in a header file a ui file is mentioned, but ui file noct exists you are
getting currently a message like

1>AUTOUIC : error : process for ui_testwidget.h failed:
1>  File 'C:/mypath/testwidget.ui' is not valid

After this message you have no idea, where the error is. E.g. in my case
testwidget.ui + cpp + h was in parent directory and in subfolder #include
ui_testwidget.h" file was mentioned in another header file (e.g. wrongheader.h).

My only way to get an idea what was wrong, was to debug cmake.

Simply solution would be something like this (cmQtAutoGenerators.cxx):

      std::cerr << "AUTOUIC: error: process for " << ui_output_file <<
                " failed:\n" << output << 
				"UI file was mentioned in " << realName << std::endl;
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-08 10:18 SunBlack       New Issue                                    
======================================================================


From Anton.Makeev at jetbrains.com  Thu Jan  8 11:42:44 2015
From: Anton.Makeev at jetbrains.com (Anton Makeev)
Date: Thu, 8 Jan 2015 16:42:44 +0000 (UTC)
Subject: [cmake-developers] Extracting target metadata, IDE integration
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
Message-ID: <loom.20150108T174009-382@post.gmane.org>

Aleix Pol <aleixpol at ...> writes:

>....
> 
> I'd really appreciate your feedback on the patch I provided, I'll be
> happy to provide the information you miss.
> Aleix

Aleix, could you please point me to the most recent patch version?









From aleixpol at kde.org  Thu Jan  8 21:33:34 2015
From: aleixpol at kde.org (Aleix Pol)
Date: Fri, 9 Jan 2015 03:33:34 +0100
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <loom.20150108T174009-382@post.gmane.org>
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
 <loom.20150108T174009-382@post.gmane.org>
Message-ID: <CACcA1RrNT9-B_n7=TobM=MQ39eiiDczaByE5ZmNzEd2drMsSfw@mail.gmail.com>

On Thu, Jan 8, 2015 at 5:42 PM, Anton Makeev <Anton.Makeev at jetbrains.com> wrote:
> Aleix Pol <aleixpol at ...> writes:
>
>>....
>>
>> I'd really appreciate your feedback on the patch I provided, I'll be
>> happy to provide the information you miss.
>> Aleix
>
> Aleix, could you please point me to the most recent patch version?
>
>
>
>
>
>
>
>
> --
>
> 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

I'll attach it in this e-mail, to make sure it reaches.

Aleix

PS: there's no changes system for cmake  like reviewboard, is there?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
Type: text/x-patch
Size: 6483 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150109/ef185bf9/attachment.bin>

From justin.borodinsky at gmail.com  Thu Jan  8 22:18:19 2015
From: justin.borodinsky at gmail.com (Justin Borodinsky)
Date: Thu, 8 Jan 2015 22:18:19 -0500
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>

I had a similar problem, and I found that passing the extra flags, along
with the libraries, to target_link_libraries directly worked.

On Tue, Jan 6, 2015 at 3:50 PM, Robert Goulet <Robert.Goulet at autodesk.com>
wrote:

>  Thanks Robert,
>
>
>
> But it doesn?t seems to work when building for NVidia NSight Android
> platform using Visual Studio IDE. Is there a way to add custom flags before
> and after the flags set by target_link_libraries? I tried
> CMAKE_LINK_EXE_FLAGS but it doesn?t work. Thanks!
>
>
>
> *From:* Robert Maynard [mailto:robert.maynard at kitware.com]
> *Sent:* Monday, January 5, 2015 4:22 PM
> *To:* Robert Goulet
> *Cc:* cmake-developers at cmake.org
> *Subject:* Re: [cmake-developers] target_link_libraries and
> --start-group/--end-group ?
>
>
>
> I believe what you want to do is bring the libraries in as imported
> targets and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY (
> http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html
> ).
>
>
>
> By default the value should be 2 which means that we will list all static
> libraries twice, but you might need to increase the value.
>
>
>
> I would also read the resolution of bug 14463 (
> http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation
> of how the target_link_libraries order determines the static link ordering.
>
>
>
>
>
> On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet <Robert.Goulet at autodesk.com>
> wrote:
>
>  Hi,
>
>
>
> My project needs to link with an external library which actually consist
> of a set of libraries. Adding these libs using target_link_libraries should
> be working just fine but unfortunately these libs have a bunch of circular
> dependencies, so it fails. In the makefile, we link with these libs using
> this syntax:
>
>
>
> -Wl,--start-group ?libs? -Wl,--end-group
>
>
>
> ?so that the linker is able to correctly find all symbols. What?s the
> proper way to deal with this using CMake? I tried to add the group flags to
> target_link_libraries but it does not work. Thanks!
>
>
>
>
>
>
>
> *Robert Goulet*
>
> Senior Software Developer
>
> Games Solutions Group
>
> Autodesk Media & Entertainment
>
>
>
> *MAIN* +1 514 393 1616 <%2B1%20514%20393%201616>
>
> *DIRECT* +1 514 954 3911 <%2B1%20514%20954%203911>
>
> *MOBILE* +1 438 397 4075
>
>
>
> *Autodesk, Inc.*
>
> 10 Rue Duke
>
> Montreal, QC, H3C 2L7
>
> www.autodesk.com
>
>
>
> [image: Description: Email_Signature_Logobar]
>
>
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150108/87e5925c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150108/87e5925c/attachment-0001.jpg>

From Robert.Goulet at autodesk.com  Fri Jan  9 10:54:47 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Fri, 9 Jan 2015 15:54:47 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF224F@005-TK5MPN4-042.MGDADSK.autodesk.com>

I tried that but then target_link_libraries will automatically add ?-l? in front of every additional flag I pass. Is there a way to pass other flags without having it changed them?

i.e.:
target_link_libraries(${PROJECT_NAME} -Wl,--start-group foo bar -Wl,--end-group)

?ends up like this in the linker command line:
-l?-Wl,--start-group? ?lfoo ?lbar ?l?-Wl,--end-group?

So how do you preserve other flags so that it ends up like this:

-Wl,--start-group ?lfoo ?lbar -Wl,--end-group


From: Justin Borodinsky [mailto:justin.borodinsky at gmail.com]
Sent: Thursday, January 8, 2015 10:18 PM
To: Robert Goulet
Cc: Robert Maynard; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

I had a similar problem, and I found that passing the extra flags, along with the libraries, to target_link_libraries directly worked.

On Tue, Jan 6, 2015 at 3:50 PM, Robert Goulet <Robert.Goulet at autodesk.com<mailto:Robert.Goulet at autodesk.com>> wrote:
Thanks Robert,

But it doesn?t seems to work when building for NVidia NSight Android platform using Visual Studio IDE. Is there a way to add custom flags before and after the flags set by target_link_libraries? I tried CMAKE_LINK_EXE_FLAGS but it doesn?t work. Thanks!

From: Robert Maynard [mailto:robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>]
Sent: Monday, January 5, 2015 4:22 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org<mailto:cmake-developers at cmake.org>
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

I believe what you want to do is bring the libraries in as imported targets and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY ( http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html ).

By default the value should be 2 which means that we will list all static libraries twice, but you might need to increase the value.

I would also read the resolution of bug 14463 (http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation of how the target_link_libraries order determines the static link ordering.


On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet <Robert.Goulet at autodesk.com<mailto:Robert.Goulet at autodesk.com>> wrote:
Hi,

My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax:

-Wl,--start-group ?libs? -Wl,--end-group

?so that the linker is able to correctly find all symbols. What?s the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks!



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616<tel:%2B1%20514%20393%201616>
DIRECT +1 514 954 3911<tel:%2B1%20514%20954%203911>
MOBILE +1 438 397 4075<tel:%2B1%20438%20397%204075>

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com<http://www.autodesk.com/>

[Description: Email_Signature_Logobar]


--

Powered by www.kitware.com<http://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<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150109/3160d6b2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150109/3160d6b2/attachment-0001.jpg>

From mw_triad at users.sourceforge.net  Fri Jan  9 13:13:49 2015
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 09 Jan 2015 13:13:49 -0500
Subject: [cmake-developers] Improving the version selection behavior of
	EXACT
In-Reply-To: <2265519.UlzGx0ETMW@caliban.sf-tec.de>
References: <2265519.UlzGx0ETMW@caliban.sf-tec.de>
Message-ID: <m8p5ot$ape$1@ger.gmane.org>

On 2014-10-03 03:35, Rolf Eike Beer wrote:
> find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most 
> cases this behavior is not the one that one would expect or need. Most people 
> would instead allow any 2.0.x version to match. This sort of selection is 
> currently impossible without additional effort in every Find*.cmake that is 
> used.

This is probably a bit late, but did anyone think of using "MATCHES" to
say "all provided components match exactly and the rest can be whatever"?

-- 
Matthew


From evangelos at foutrelis.com  Fri Jan  9 13:37:51 2015
From: evangelos at foutrelis.com (Evangelos Foutras)
Date: Fri, 9 Jan 2015 20:37:51 +0200
Subject: [cmake-developers] [PATCH] FindRuby: Fix output check in
	_RUBY_CONFIG_VAR
In-Reply-To: <1419872524-11286-1-git-send-email-evangelos@foutrelis.com>
References: <1419872524-11286-1-git-send-email-evangelos@foutrelis.com>
Message-ID: <CAA407mwhFsjXcN7xbgpE8aouqVCv=r+XXWVuwQZQen2cYivNuA@mail.gmail.com>

On 29 December 2014 at 19:02, Evangelos Foutras <evangelos at foutrelis.com> wrote:
> Since commit 854e762 (FindRuby: clean up querying variables from Ruby)
> we query RbConfig::CONFIG first and, if the command fails or its output
> equates to a false constant, then fall back to querying Config::CONFIG.
>
> Due to the above, an error condition exists with Ruby 2.2.0; when querying
> RbConfig::CONFIG['TEENY'], the output of '0' will be discarded since it
> matches the false constant '0'.
>
> In previous versions this wasn't a problem, but Ruby 2.2 has completely
> removed Config::CONFIG. This causes RUBY_VERSION_PATCH to be set to an
> empty string and the Ruby version to be detected as '2.2.' (instead of
> '2.2.0').
>
> This patch fixes the output check to explicitly look for an empty string
> before using the fallback query method. (Someone more familiar with Ruby
> might be able to deem the fallback as unnecessary and fully remove it.)
> ---
>  Modules/FindRuby.cmake | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Modules/FindRuby.cmake b/Modules/FindRuby.cmake
> index b5ac703..0950d15 100644
> --- a/Modules/FindRuby.cmake
> +++ b/Modules/FindRuby.cmake
> @@ -90,7 +90,7 @@ if(RUBY_EXECUTABLE  AND NOT  RUBY_VERSION_MAJOR)
>        RESULT_VARIABLE _RUBY_SUCCESS
>        OUTPUT_VARIABLE _RUBY_OUTPUT
>        ERROR_QUIET)
> -    if(_RUBY_SUCCESS OR NOT _RUBY_OUTPUT)
> +    if(_RUBY_SUCCESS OR _RUBY_OUTPUT STREQUAL "")
>        execute_process(COMMAND ${RUBY_EXECUTABLE} -r rbconfig -e "print Config::CONFIG['${RBVAR}']"
>          RESULT_VARIABLE _RUBY_SUCCESS
>          OUTPUT_VARIABLE _RUBY_OUTPUT
> --
> 2.2.1

Could I get some feedback on this please?

Thanks.

From eike at sf-mail.de  Fri Jan  9 14:18:25 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Fri, 09 Jan 2015 20:18:25 +0100
Subject: [cmake-developers] Improving the version selection behavior of
	EXACT
In-Reply-To: <m8p5ot$ape$1@ger.gmane.org>
References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <m8p5ot$ape$1@ger.gmane.org>
Message-ID: <22203882.FFY0rs2GGb@eto>

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

I bet everybody will get it wrong.

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

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

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

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150109/da6f76e2/attachment.sig>

From ben.boeckel at kitware.com  Fri Jan  9 15:02:04 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 9 Jan 2015 15:02:04 -0500
Subject: [cmake-developers] Improving the version selection behavior of
 EXACT
In-Reply-To: <22203882.FFY0rs2GGb@eto>
References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <m8p5ot$ape$1@ger.gmane.org>
 <22203882.FFY0rs2GGb@eto>
Message-ID: <20150109200204.GA25840@megas.kitwarein.com>

On Fri, Jan 09, 2015 at 20:18:25 +0100, Rolf Eike Beer wrote:
> Matthew Woehlke wrote:
> > On 2014-10-03 03:35, Rolf Eike Beer wrote:
> > > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In
> > > most cases this behavior is not the one that one would expect or need.
> > > Most people would instead allow any 2.0.x version to match. This sort of
> > > selection is currently impossible without additional effort in every
> > > Find*.cmake that is used.
> > 
> > This is probably a bit late, but did anyone think of using "MATCHES" to
> > say "all provided components match exactly and the rest can be whatever"?
> 
> I bet everybody will get it wrong.
> 
> Ok, this is "version 2.1 and any of it's patch versions", if _I_ got it right:
> 
> if (VER MATCHES "^2\\.1(\\..*|[^0-9].*)?$")
> 
> So this should match "2.1", "2.1a", "2.1.1", but not "2.10". What combination 
> of stuff did I miss?

What about "VERSION_RANGE 2.1 2.2" which is interpreted as a half-open
range? Should be easier with:

    NOT ver VERSION_LESS low AND ver VERSION_LESS high

--Ben

From Robert.Goulet at autodesk.com  Fri Jan  9 16:28:37 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Fri, 9 Jan 2015 21:28:37 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com> 
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>

I realize the cmake documentation says that everything that starts with ?-? should be treated as other linker flags, so I wonder, perhaps it?s a new bug, or maybe just with a specific generator? In this case I am using the new NVidia NSight Android generator for Visual Studio.

Can anyone confirm if this also happens with other generators?
Thanks!

From: Robert Goulet
Sent: Friday, January 9, 2015 10:55 AM
To: 'Justin Borodinsky'
Cc: Robert Maynard; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

I tried that but then target_link_libraries will automatically add ?-l? in front of every additional flag I pass. Is there a way to pass other flags without having it changed them?

i.e.:
target_link_libraries(${PROJECT_NAME} -Wl,--start-group foo bar -Wl,--end-group)

?ends up like this in the linker command line:
-l?-Wl,--start-group? ?lfoo ?lbar ?l?-Wl,--end-group?

So how do you preserve other flags so that it ends up like this:

-Wl,--start-group ?lfoo ?lbar -Wl,--end-group


From: Justin Borodinsky [mailto:justin.borodinsky at gmail.com]
Sent: Thursday, January 8, 2015 10:18 PM
To: Robert Goulet
Cc: Robert Maynard; cmake-developers at cmake.org<mailto:cmake-developers at cmake.org>
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

I had a similar problem, and I found that passing the extra flags, along with the libraries, to target_link_libraries directly worked.

On Tue, Jan 6, 2015 at 3:50 PM, Robert Goulet <Robert.Goulet at autodesk.com<mailto:Robert.Goulet at autodesk.com>> wrote:
Thanks Robert,

But it doesn?t seems to work when building for NVidia NSight Android platform using Visual Studio IDE. Is there a way to add custom flags before and after the flags set by target_link_libraries? I tried CMAKE_LINK_EXE_FLAGS but it doesn?t work. Thanks!

From: Robert Maynard [mailto:robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>]
Sent: Monday, January 5, 2015 4:22 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org<mailto:cmake-developers at cmake.org>
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

I believe what you want to do is bring the libraries in as imported targets and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY ( http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html ).

By default the value should be 2 which means that we will list all static libraries twice, but you might need to increase the value.

I would also read the resolution of bug 14463 (http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation of how the target_link_libraries order determines the static link ordering.


On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet <Robert.Goulet at autodesk.com<mailto:Robert.Goulet at autodesk.com>> wrote:
Hi,

My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax:

-Wl,--start-group ?libs? -Wl,--end-group

?so that the linker is able to correctly find all symbols. What?s the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks!



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616<tel:%2B1%20514%20393%201616>
DIRECT +1 514 954 3911<tel:%2B1%20514%20954%203911>
MOBILE +1 438 397 4075<tel:%2B1%20438%20397%204075>

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com<http://www.autodesk.com/>

[Description: Email_Signature_Logobar]


--

Powered by www.kitware.com<http://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<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150109/fd3e4f18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150109/fd3e4f18/attachment-0001.jpg>

From steveire at gmail.com  Sat Jan 10 13:23:27 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 10 Jan 2015 19:23:27 +0100
Subject: [cmake-developers] Extracting target metadata, IDE integration
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
 <loom.20150108T174009-382@post.gmane.org>
 <CACcA1RrNT9-B_n7=TobM=MQ39eiiDczaByE5ZmNzEd2drMsSfw@mail.gmail.com>
Message-ID: <m8rqmv$kk2$1@ger.gmane.org>

Aleix Pol wrote:

> I'll attach it in this e-mail, to make sure it reaches.
> 
> PS: there's no changes system for cmake  like reviewboard, is there?

Nope, review is communicated on the mailing list, but if you want you can 
push the patch on a branch in a public repo. It could be more convenient.

Thanks,

Steve.



From gjasny at googlemail.com  Sat Jan 10 14:41:52 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Sat, 10 Jan 2015 20:41:52 +0100
Subject: [cmake-developers] [PATCH] Document find_package
	CMAKE_FIND_PACKAGE_NAME variable
Message-ID: <1420918912-47248-1-git-send-email-gjasny@googlemail.com>

Signed-off-by: Gregor Jasny <gjasny at googlemail.com>
---
 Help/command/find_package.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Help/command/find_package.rst b/Help/command/find_package.rst
index 190d05c..7f518a6 100644
--- a/Help/command/find_package.rst
+++ b/Help/command/find_package.rst
@@ -312,6 +312,8 @@ When loading a find module or package configuration file ``find_package``
 defines variables to provide information about the call arguments (and
 restores their original state before returning):
 
+``CMAKE_FIND_PACKAGE_NAME``
+  the ``<package>`` name which is searched for
 ``<package>_FIND_REQUIRED``
   true if ``REQUIRED`` option was given
 ``<package>_FIND_QUIETLY``
-- 
1.9.3 (Apple Git-50)


From foss at grueninger.de  Sat Jan 10 16:03:26 2015
From: foss at grueninger.de (=?windows-1252?Q?Christoph_Gr=FCninger?=)
Date: Sat, 10 Jan 2015 22:03:26 +0100
Subject: [cmake-developers] Which binaries should be required in
	FindLATEX?
In-Reply-To: <549978AA.9070000@kitware.com>
References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com>
 <5497CBF7.1090001@grueninger.de> <549834EB.9080307@kitware.com>
 <5498A95D.1010509@grueninger.de> <54993897.4000106@kitware.com>
 <54994560.2070400@grueninger.de> <549978AA.9070000@kitware.com>
Message-ID: <54B1939E.4000001@grueninger.de>

Hi Brad,
concerning FindLATEX again:

> Applied:
> 
>  FindLATEX: Add components handling
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07a3f9ad

The link does not work and I couldn't find the commit in next. Can you
double check whether you pushed it?

> with minor documentation tweaks and one logic fix:
> 
>  -#   set(LATEX_MAKEINDEX_FOUND TRUE)
>  +  set(LATEX_MAKEINDEX_FOUND TRUE)
> 
> that looked left from local testing.

Sorry, you are right. Thanks for the heads-up. I attached the right
patch this time.

Additionally I attached patches to add more LaTeX-related component we
should test. This includes Biber (BibTeX replacement), xindy (makeindex
replacement), pdftops, htlatex (compiler to HTML), XeLaTeX and LuaLaTeX.

Bye
Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindLATEX-Add-components-handling.patch
Type: text/x-patch
Size: 4733 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150110/99a6c396/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-FindLATEX-Add-components-PDFtoPS-and-HTLATEX.patch
Type: text/x-patch
Size: 1955 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150110/99a6c396/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-FindLATEX-Add-components-Biber-and-xindy.patch
Type: text/x-patch
Size: 2054 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150110/99a6c396/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-FindLATEX-Add-components-for-XeLaTeX-and-LuaLaTeX.patch
Type: text/x-patch
Size: 2291 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150110/99a6c396/attachment-0003.bin>

From gjasny at googlemail.com  Sun Jan 11 14:25:55 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Sun, 11 Jan 2015 20:25:55 +0100
Subject: [cmake-developers] [PATCH] Retrieve Xcode CompilerId via static
	libraries
Message-ID: <1421004355-68565-1-git-send-email-gjasny@googlemail.com>

The current approach to determine the CompilerId via
an XCTest bundle on iOS requires a valid code sign identity.

This is a regression compared to CMake 3.0. This patch changes
the detection to be performed on a static library and also
unifies detection across iOS and OSX.

This has been tested on OSX 10.10 with Xcode 6.1.1.

Signed-off-by: Gregor Jasny <gjasny at googlemail.com>
---
 Modules/CMakeDetermineCompilerId.cmake | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/Modules/CMakeDetermineCompilerId.cmake b/Modules/CMakeDetermineCompilerId.cmake
index 0ea9ce1..85934a3 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -264,9 +264,7 @@ Id flags: ${testflags}
     set(id_product_type "com.apple.product-type.tool")
     if(CMAKE_OSX_SYSROOT)
       set(id_sdkroot "SDKROOT = \"${CMAKE_OSX_SYSROOT}\";")
-      if(CMAKE_OSX_SYSROOT MATCHES "(^|/)[Ii][Pp][Hh][Oo][Nn][Ee]")
-        set(id_product_type "com.apple.product-type.bundle.unit-test")
-      endif()
+      set(id_product_type "com.apple.product-type.library.static")
     else()
       set(id_sdkroot "")
     endif()
@@ -303,11 +301,11 @@ Id flags: ${testflags}
     endif()
 
     # Match the link line from xcodebuild output of the form
-    #  Ld ...
+    #  CompileC ...
     #      ...
-    #      /path/to/cc ...CompilerId${lang}/...
+    #      /path/to/cc ...-o CMake${lang}CompilerId.o
     # to extract the compiler front-end for the language.
-    if("${CMAKE_${lang}_COMPILER_ID_OUTPUT}" MATCHES "\nLd[^\n]*(\n[ \t]+[^\n]*)*\n[ \t]+([^ \t\r\n]+)[^\r\n]*-o[^\r\n]*CompilerId${lang}/(\\./)?(CompilerId${lang}.xctest/)?CompilerId${lang}[ \t\n\\\"]")
+    if("${CMAKE_${lang}_COMPILER_ID_OUTPUT}" MATCHES "\nCompileC[^\n]*(\n[ \t]+[^\n]*)*\n[ \t]+([^ \t\r\n]+)[^\r\n]*-o[ \t][^ \t\r\n]*CMake${lang}CompilerId.o[ \t\n\\\"]")
       set(_comp "${CMAKE_MATCH_2}")
       if(EXISTS "${_comp}")
         set(CMAKE_${lang}_COMPILER_ID_TOOL "${_comp}" PARENT_SCOPE)
-- 
1.9.3 (Apple Git-50)


From justin.borodinsky at gmail.com  Sun Jan 11 19:02:19 2015
From: justin.borodinsky at gmail.com (Justin Borodinsky)
Date: Sun, 11 Jan 2015 19:02:19 -0500
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <CAFdhTuNKYC__XperYVK-qun14RY5v2rwU+ZYQvqXMhL7zgEbUQ@mail.gmail.com>

I just tested with Unix Makefiles and it works ok,
target_link_libraries(${TARGET_NAME} -Wl,--start-group -lm -Wl,--end-group)
results in /usr/bin/c++   -g   CMakeFiles/TestM.dir/testm.cpp.o  -o TestM
-rdynamic -Wl,--start-group -lm -Wl,--end-group

On Fri, Jan 9, 2015 at 4:28 PM, Robert Goulet <Robert.Goulet at autodesk.com>
wrote:

>  I realize the cmake documentation says that everything that starts with
> ?-? should be treated as other linker flags, so I wonder, perhaps it?s a
> new bug, or maybe just with a specific generator? In this case I am using
> the new NVidia NSight Android generator for Visual Studio.
>
>
>
> Can anyone confirm if this also happens with other generators?
>
> Thanks!
>
>
>
> *From:* Robert Goulet
> *Sent:* Friday, January 9, 2015 10:55 AM
> *To:* 'Justin Borodinsky'
> *Cc:* Robert Maynard; cmake-developers at cmake.org
> *Subject:* RE: [cmake-developers] target_link_libraries and
> --start-group/--end-group ?
>
>
>
> I tried that but then target_link_libraries will automatically add ?-l? in
> front of every additional flag I pass. Is there a way to pass other flags
> without having it changed them?
>
>
>
> i.e.:
>
> target_link_libraries(${PROJECT_NAME} -Wl,--start-group foo bar
> -Wl,--end-group)
>
>
>
> ?ends up like this in the linker command line:
>
> -l?-Wl,--start-group? ?lfoo ?lbar ?l?-Wl,--end-group?
>
>
>
> So how do you preserve other flags so that it ends up like this:
>
>
>
> -Wl,--start-group ?lfoo ?lbar -Wl,--end-group
>
>
>
>
>
> *From:* Justin Borodinsky [mailto:justin.borodinsky at gmail.com
> <justin.borodinsky at gmail.com>]
> *Sent:* Thursday, January 8, 2015 10:18 PM
> *To:* Robert Goulet
> *Cc:* Robert Maynard; cmake-developers at cmake.org
>
> *Subject:* Re: [cmake-developers] target_link_libraries and
> --start-group/--end-group ?
>
>
>
> I had a similar problem, and I found that passing the extra flags, along
> with the libraries, to target_link_libraries directly worked.
>
>
>
> On Tue, Jan 6, 2015 at 3:50 PM, Robert Goulet <Robert.Goulet at autodesk.com>
> wrote:
>
>  Thanks Robert,
>
>
>
> But it doesn?t seems to work when building for NVidia NSight Android
> platform using Visual Studio IDE. Is there a way to add custom flags before
> and after the flags set by target_link_libraries? I tried
> CMAKE_LINK_EXE_FLAGS but it doesn?t work. Thanks!
>
>
>
> *From:* Robert Maynard [mailto:robert.maynard at kitware.com]
> *Sent:* Monday, January 5, 2015 4:22 PM
> *To:* Robert Goulet
> *Cc:* cmake-developers at cmake.org
> *Subject:* Re: [cmake-developers] target_link_libraries and
> --start-group/--end-group ?
>
>
>
> I believe what you want to do is bring the libraries in as imported
> targets and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY (
> http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html
> ).
>
>
>
> By default the value should be 2 which means that we will list all static
> libraries twice, but you might need to increase the value.
>
>
>
> I would also read the resolution of bug 14463 (
> http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation
> of how the target_link_libraries order determines the static link ordering.
>
>
>
>
>
> On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet <Robert.Goulet at autodesk.com>
> wrote:
>
>  Hi,
>
>
>
> My project needs to link with an external library which actually consist
> of a set of libraries. Adding these libs using target_link_libraries should
> be working just fine but unfortunately these libs have a bunch of circular
> dependencies, so it fails. In the makefile, we link with these libs using
> this syntax:
>
>
>
> -Wl,--start-group ?libs? -Wl,--end-group
>
>
>
> ?so that the linker is able to correctly find all symbols. What?s the
> proper way to deal with this using CMake? I tried to add the group flags to
> target_link_libraries but it does not work. Thanks!
>
>
>
>
>
>
>
> *Robert Goulet*
>
> Senior Software Developer
>
> Games Solutions Group
>
> Autodesk Media & Entertainment
>
>
>
> *MAIN* +1 514 393 1616 <%2B1%20514%20393%201616>
>
> *DIRECT* +1 514 954 3911 <%2B1%20514%20954%203911>
>
> *MOBILE* +1 438 397 4075
>
>
>
> *Autodesk, Inc.*
>
> 10 Rue Duke
>
> Montreal, QC, H3C 2L7
>
> www.autodesk.com
>
>
>
> [image: Description: Email_Signature_Logobar]
>
>
>
>
> --
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150111/69b103ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150111/69b103ed/attachment-0001.jpg>

From mantis at public.kitware.com  Mon Jan 12 07:43:41 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 12 Jan 2015 07:43:41 -0500
Subject: [cmake-developers] [CMake 0015345]: FindRuby: Problem with
	"find_package(Ruby 2.0)"
Message-ID: <92b2af40d0803c02e5c4a25e1bfea30d@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15345 
====================================================================== 
Reported By:                David Coppa
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15345
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-12 07:43 EST
Last Modified:              2015-01-12 07:43 EST
====================================================================== 
Summary:                    FindRuby: Problem with "find_package(Ruby 2.0)"
Description: 
OS is OpenBSD, but I think this also applies to Linux or other Unix-like OSes.
Both ruby-2.0.0 and ruby-2.1.5 are installed on the system:

$ ls -1 /usr/local/bin/ruby*
/usr/local/bin/ruby20
/usr/local/bin/ruby21

Using "find_package(Ruby 2.1)" works as expected:

-- ATTENTION -> Ruby_FIND_VERSION_MINOR == 1
-- ATTENTION -> setting Ruby_FIND_VERSION_SHORT_NODOT...
-- --------FindRuby.cmake debug------------
-- _RUBY_POSSIBLE_EXECUTABLE_NAMES:
ruby2.1;ruby21;ruby;ruby2.0;ruby20;ruby1.9;ruby19;ruby1.8;ruby18
-- _RUBY_POSSIBLE_LIB_NAMES: ruby;ruby-static;ruby2.1;ruby21;ruby-2.1;ruby-2.1.0
-- RUBY_ARCH_DIR: /usr/local/lib/ruby/2.1/x86_64-openbsd
-- RUBY_HDR_DIR: /usr/local/include/ruby-2.1
-- RUBY_POSSIBLE_LIB_DIR: /usr/local/lib
-- Found RUBY_VERSION: "2.1.0" , short: "2.1", nodot: "21"
-- _RUBY_REQUIRED_VARS:
RUBY_EXECUTABLE;RUBY_INCLUDE_DIR;RUBY_LIBRARY;RUBY_CONFIG_INCLUDE_DIR
-- RUBY_EXECUTABLE: /usr/local/bin/ruby21
-- RUBY_LIBRARY: /usr/local/lib/libruby21.so.1.0
-- RUBY_INCLUDE_DIR: /usr/local/include/ruby-2.1
-- RUBY_CONFIG_INCLUDE_DIR: /usr/local/include/ruby-2.1/x86_64-openbsd
-- --------------------
-- Found Ruby: /usr/local/bin/ruby21 (found suitable version "2.1.0", minimum
required is "2.1")

** NOTE: I've added some messages to help understand the problem and set
_RUBY_DEBUG_OUTPUT to true.

While "find_package(Ruby 2.0)" is broken:

-- ATTENTION -> Ruby_FIND_VERSION_MINOR == 0
-- --------FindRuby.cmake debug------------
-- _RUBY_POSSIBLE_EXECUTABLE_NAMES:
ruby;ruby2.1;ruby21;ruby2.0;ruby20;ruby1.9;ruby19;ruby1.8;ruby18
-- _RUBY_POSSIBLE_LIB_NAMES: ruby;ruby-static;ruby2.1;ruby21;ruby-2.1;ruby-2.1.0
-- RUBY_ARCH_DIR: /usr/local/lib/ruby/2.1/x86_64-openbsd
-- RUBY_HDR_DIR: /usr/local/include/ruby-2.1
-- RUBY_POSSIBLE_LIB_DIR: /usr/local/lib
-- Found RUBY_VERSION: "2.1.0" , short: "2.1", nodot: "21"
-- _RUBY_REQUIRED_VARS:
RUBY_EXECUTABLE;RUBY_INCLUDE_DIR;RUBY_LIBRARY;RUBY_CONFIG_INCLUDE_DIR
-- RUBY_EXECUTABLE: /usr/local/bin/ruby21
-- RUBY_LIBRARY: /usr/local/lib/libruby21.so.1.0
-- RUBY_INCLUDE_DIR: /usr/local/include/ruby-2.1
-- RUBY_CONFIG_INCLUDE_DIR: /usr/local/include/ruby-2.1/x86_64-openbsd
-- --------------------
-- Found Ruby: /usr/local/bin/ruby21 (found suitable version "2.1.0", minimum
required is "2.0")

This is because, when "Ruby_FIND_VERSION_MINOR" is 0, the
"if(Ruby_FIND_VERSION_MAJOR  AND  Ruby_FIND_VERSION_MINOR)" check at line 61
evaluates to false.

Changing line 61 to:

"if(DEFINED Ruby_FIND_VERSION_MAJOR AND DEFINED Ruby_FIND_VERSION_MINOR)"

works around the issue for me:

-- ATTENTION -> Ruby_FIND_VERSION_MINOR == 0
-- ATTENTION -> setting Ruby_FIND_VERSION_SHORT_NODOT ...
-- --------FindRuby.cmake debug------------
-- _RUBY_POSSIBLE_EXECUTABLE_NAMES:
ruby2.0;ruby20;ruby;ruby2.1;ruby21;ruby1.9;ruby19;ruby1.8;ruby18
-- _RUBY_POSSIBLE_LIB_NAMES: ruby;ruby-static;ruby2.0;ruby20;ruby-2.0;ruby-2.0.0
-- RUBY_ARCH_DIR: /usr/local/lib/ruby/2.0/x86_64-openbsd
-- RUBY_HDR_DIR: /usr/local/include/ruby-2.0
-- RUBY_POSSIBLE_LIB_DIR: /usr/local/lib
-- Found RUBY_VERSION: "2.0.0" , short: "2.0", nodot: "20"
-- _RUBY_REQUIRED_VARS:
RUBY_EXECUTABLE;RUBY_INCLUDE_DIR;RUBY_LIBRARY;RUBY_CONFIG_INCLUDE_DIR
-- RUBY_EXECUTABLE: /usr/local/bin/ruby20
-- RUBY_LIBRARY: /usr/local/lib/libruby20.so.1.0
-- RUBY_INCLUDE_DIR: /usr/local/include/ruby-2.0
-- RUBY_CONFIG_INCLUDE_DIR: /usr/local/include/ruby-2.0/x86_64-openbsd
-- --------------------
-- Found Ruby: /usr/local/bin/ruby20 (found suitable version "2.0.0", minimum
required is "2.0")



Steps to Reproduce: 
Use "find_package(Ruby 2.0)" or "find_package(Ruby 2.0 EXACT)"

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-12 07:43 David Coppa    New Issue                                    
======================================================================


From brad.king at kitware.com  Mon Jan 12 08:26:59 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 08:26:59 -0500
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54B3CBA3.4000703@kitware.com>

On 1/9/2015 4:28 PM, Robert Goulet wrote:
> I realize the cmake documentation says that everything that starts with
> "-" should be treated as other linker flags, so I wonder, perhaps it's a
> new bug, or maybe just with a specific generator? In this case I am
> using the new NVidia NSight Android generator for Visual Studio.
[snip]
> -l"-Wl,--start-group" ?lfoo ?lbar ?l"-Wl,--end-group"

It is likely specific to that (new) generator.

Please post the .vcxproj file that is generated for that.

Thanks,
-Brad

From brad.king at kitware.com  Mon Jan 12 08:28:04 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 08:28:04 -0500
Subject: [cmake-developers] FindGit and GitHub for Windows (was:
	Greetings!)
In-Reply-To: <CADkBgUWgJZWwpdgCJAdJajqytrewMz4RA5ijH9ui-UqSVS7W3A@mail.gmail.com>
References: <CADkBgUWgJZWwpdgCJAdJajqytrewMz4RA5ijH9ui-UqSVS7W3A@mail.gmail.com>
Message-ID: <54B3CBE4.2040802@kitware.com>

On 1/1/2015 9:09 AM, Yong Piao wrote:
> I also have an idea for the existing FindGit module. I came across this
> idea because I am currently using batch script to locate the portable
> Git contained in GitHub for Windows and have found it working very
> consistently. I think it would be great to add this functionality for
> those who exclusively use GitHub.

Yes, I think that would make sense if at "git" tool is the standard
command-line client.  Please read CONTRIBUTING.rst and submit a patch
for Modules/FindGit.cmake to add this.

Thanks!
-Brad

From brad.king at kitware.com  Mon Jan 12 08:31:09 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 08:31:09 -0500
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
 prefixes
In-Reply-To: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
Message-ID: <54B3CC9D.8000008@kitware.com>

On 12/30/2014 8:03 PM, Domen Vrankar wrote:
> Could somebody please review the topic rpm_multi_prefix.
> 
> http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=c908ba3707fcf8cf43df0c5cd90f8ea6d98d7c29
> 
> Patch adds support for multiple relocation paths per RPM package.
> For relocation paths I have extended GNUInstallDirs module since it
> already provides the required functionality but for install command.
> Is this OK?

I'm not familiar with the corresponding use case.  Please explain
how "multiple relocation paths" works in general with RPM tools.

Thanks,
-Brad

From brad.king at kitware.com  Mon Jan 12 08:37:12 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 08:37:12 -0500
Subject: [cmake-developers] [PATCH] Document find_package
 CMAKE_FIND_PACKAGE_NAME variable
In-Reply-To: <1420918912-47248-1-git-send-email-gjasny@googlemail.com>
References: <1420918912-47248-1-git-send-email-gjasny@googlemail.com>
Message-ID: <54B3CE08.2060909@kitware.com>

On 1/10/2015 2:41 PM, Gregor Jasny wrote:
> Signed-off-by: Gregor Jasny <gjasny at googlemail.com>

Thanks.  Applied:

 find_package: Document CMAKE_FIND_PACKAGE_NAME variable
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8abd258

I also added a dedicated document for it:

 Help: Document CMAKE_FIND_PACKAGE_NAME variable
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8435088d

Thanks,
-Brad

From brad.king at kitware.com  Mon Jan 12 08:44:01 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 08:44:01 -0500
Subject: [cmake-developers] [PATCH] FindRuby: Fix output check in
	_RUBY_CONFIG_VAR
In-Reply-To: <1419872524-11286-1-git-send-email-evangelos@foutrelis.com>
References: <1419872524-11286-1-git-send-email-evangelos@foutrelis.com>
Message-ID: <54B3CFA1.5090502@kitware.com>

On 12/29/2014 12:02 PM, Evangelos Foutras wrote:
> This patch fixes the output check to explicitly look for an empty string
> before using the fallback query method. (Someone more familiar with Ruby
> might be able to deem the fallback as unnecessary and fully remove it.)

Thanks.  Applied:

 FindRuby: Fix output check in _RUBY_CONFIG_VAR
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802d0aa0

-Brad

From brad.king at kitware.com  Mon Jan 12 09:00:45 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 09:00:45 -0500
Subject: [cmake-developers] [PATCH] Retrieve Xcode CompilerId via static
 libraries
In-Reply-To: <1421004355-68565-1-git-send-email-gjasny@googlemail.com>
References: <1421004355-68565-1-git-send-email-gjasny@googlemail.com>
Message-ID: <54B3D38D.7080709@kitware.com>

Hi Gregor,

Thanks for working on this.  Unfortunately it is a bit complex.

On 1/11/2015 2:25 PM, Gregor Jasny wrote:
> The current approach to determine the CompilerId via
> an XCTest bundle on iOS requires a valid code sign identity.

All the subsequent try_compile calls, including ABI detection,
currently require a signing identity too.  An approach to
overcome that (CODE_SIGNING_REQUIRED) is mentioned here:

 http://www.cmake.org/Bug/view.php?id=15329

I've made a change using that approach here:

 Xcode: Do not require code signing for compiler id (#15329)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=584aaa1c

That also discusses the need to use a different product type
for try_compile calls too.  For those linking is needed so we
cannot use static libraries.  Selection has to be specific to
the target platform.

> This is a regression compared to CMake 3.0. This patch changes
> the detection to be performed on a static library and also
> unifies detection across iOS and OSX.

As explained in

 http://www.cmake.org/Bug/view.php?id=15214#c37064

3.0 only detected the host OS X compiler.

> -    #  Ld ...
> +    #  CompileC ...

Some versions of Xcode do not actually print the compilation
command line with the full path to the correct compiler tool.
For example with C++ it may compile with the path to the C
compiler and use "-x c++".  That's why we have to use Ld, and
therefore need a product type that links.

I really wish there were another way to detect the path to the
compiler tool that Xcode invokes :(

-Brad

From brad.king at kitware.com  Mon Jan 12 09:02:26 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 09:02:26 -0500
Subject: [cmake-developers] patch to fix installed size for cpack
 PackageMaker generator
In-Reply-To: <4D6C5E27-2087-4AC4-98AA-DC6350F0DE7B@acm.org>
References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org>
 <F008536D-3909-43A8-89F7-8BB1A0F43B0E@acm.org> <54982D4C.5060808@kitware.com>
 <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org>
 <20141222155211.1362005544@mail.rogue-research.com>
 <54983F64.5020307@kitware.com> <4D6C5E27-2087-4AC4-98AA-DC6350F0DE7B@acm.org>
Message-ID: <54B3D3F2.50603@kitware.com>

On 12/26/2014 12:55 PM, Calin Cascaval wrote:
> The patch is attached. I tested it with a few settings (10.4, 10.5, and
> 10.10) on a 10.9.5 system. Unfortunately I don?t have a 10.10 machine,
> however, the package built with a 10.10 option looks good.

Applied, thanks:

 CPack: Fix PackageMaker internal versioning for OS X 10.10
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=418bf735

-Brad

From brad.king at kitware.com  Mon Jan 12 09:05:49 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 09:05:49 -0500
Subject: [cmake-developers] [PATCH] Source file AUTOUIC_OPTIONS were not
 being set
In-Reply-To: <CAFdhTuMxseOj4fkPK0md=GDwF8ptbT3fKF7FC4==sOw8PrTW4w@mail.gmail.com>
References: <CAFdhTuMxseOj4fkPK0md=GDwF8ptbT3fKF7FC4==sOw8PrTW4w@mail.gmail.com>
Message-ID: <54B3D4BD.3020106@kitware.com>

Hi Justin,

Thanks.  This was a regression in 3.1.0.  Applied:

 QtAutoUic: Restore source file AUTOUIC_OPTIONS settings
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c585699

Steve also added the missing test case:

 QtAutoUic: Add a test for the regression in the parent commit.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a673737

I've queued this for 3.1.1.

Thanks,
-Brad

From brad.king at kitware.com  Mon Jan 12 09:18:04 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 09:18:04 -0500
Subject: [cmake-developers] Which binaries should be required in
	FindLATEX?
In-Reply-To: <54B1939E.4000001@grueninger.de>
References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com>
 <5497CBF7.1090001@grueninger.de> <549834EB.9080307@kitware.com>
 <5498A95D.1010509@grueninger.de> <54993897.4000106@kitware.com>
 <54994560.2070400@grueninger.de> <549978AA.9070000@kitware.com>
 <54B1939E.4000001@grueninger.de>
Message-ID: <54B3D79C.9090809@kitware.com>

On 1/10/2015 4:03 PM, Christoph Gr?ninger wrote:
> The link does not work and I couldn't find the commit in next. Can you
> double check whether you pushed it?

Oops, thanks.  I pushed it to our staging repo but never merged
to 'next'.  Done now, along with the below.

> Additionally I attached patches to add more LaTeX-related component we
> should test. This includes Biber (BibTeX replacement), xindy (makeindex
> replacement), pdftops, htlatex (compiler to HTML), XeLaTeX and LuaLaTeX.

Applied, thanks:

 FindLATEX: Add components PDFtoPS and HTLATEX
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=222ee2c0

 FindLATEX: Add components Biber and xindy
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c32f6919

 FindLATEX: Add components for XeLaTeX and LuaLaTeX
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89e08de8

-Brad

From domen.vrankar at gmail.com  Mon Jan 12 09:20:19 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 12 Jan 2015 15:20:19 +0100
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
	prefixes
In-Reply-To: <54B3CC9D.8000008@kitware.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <54B3CC9D.8000008@kitware.com>
Message-ID: <CAKgx6B+G8XqQ98XWmwGwOpDBdBRtVzaRYvPnnDE2UMXHt5wVSg@mail.gmail.com>

> I'm not familiar with the corresponding use case.  Please explain
> how "multiple relocation paths" works in general with RPM tools.

In RPM packages you can specify multiple "Prefix:" sections and during
installation you have multiple options:

use "--prefix <new_path>" during installation: this will take the
value of first "Prefix:" path from spec file and relocate all the
paths from old path to provided path (I'd say that this is a back
compatibility feature of RPM) - for this reason I have preserved first
"Prefix:" path in spec file to be the same as in
CPACK_PACKAGING_INSTALL_PREFIX variable (same as before the patch) in
situations where this path is really used (with the patch
CPACK_PACKAGING_INSTALL_PREFIX would probably be set to / in most
cases).

use --relocate <path_from_spec_file>=<new_path> (this flag may be
repeated multiple times): "Prefix:" path from spec file that matches
the one provided by relocate flag will be replaced by new path and
this enables us to move for e.g. only documentation or libraries - we
are no longer bound to one root location for all files in a single
relocatable RPM.

http://rpm5.org/docs/api/relocatable.html

e.g.
-------------------------

spec file:
Prefix: /foo
Prefix: /foo/bin
Prefix: /foo/share/lib

/foo/bin/some_program
/foo/lib/some_lib
/foo/share/lib/some_other_lib
/bar/not_relocatable

rpm installation:
rpm -i --relocate /foo/bin=/bar/bin --relocate /foo/share/lib=/foo/lib
<rpm_file>

This will relocate some_program and some_other_lib during install but
will keep some_lib on the same location as defined in spec file.

rpm installation option 2:
rpm -i --prefix /foo/share <rpm_file>

This will relocate all three files to /foo/share/bin/some_program,
/foo/share/lib/some_lib and /foo/share/share/lib/some_other_lib

In both cases not_relocatable file will not be relocated since its
path prefix was not defined in spec file as relocatable.

-------------------------

I've checked and this feature is provided in RPM 3.0.5 on AIX as well
as in 4.12 on latest Fedora (version 21) so the feature is not just
RPM5 fork specific.

I've bound the relocation paths to standard GNU filesystem locations
and since GNUInstallDirs.cmake module already provides this
functionality for install command I extended that module. I don't know
who the maintainer of the module is so I hope that extending it in
such way is OK.

Thanks,
Domen

From mw_triad at users.sourceforge.net  Mon Jan 12 11:40:19 2015
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 12 Jan 2015 11:40:19 -0500
Subject: [cmake-developers] Improving the version selection behavior of
	EXACT
In-Reply-To: <22203882.FFY0rs2GGb@eto>
References: <2265519.UlzGx0ETMW@caliban.sf-tec.de>
 <m8p5ot$ape$1@ger.gmane.org> <22203882.FFY0rs2GGb@eto>
Message-ID: <m90tdj$o4k$1@ger.gmane.org>

On 2015-01-09 14:18, Rolf Eike Beer wrote:
> Matthew Woehlke wrote:
>> On 2014-10-03 03:35, Rolf Eike Beer wrote:
>>> find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed.. In
>>> most cases this behavior is not the one that one would expect or need.
>>> Most people would instead allow any 2.0.x version to match. This sort of
>>> selection is currently impossible without additional effort in every
>>> Find*.cmake that is used.
>>
>> This is probably a bit late, but did anyone think of using "MATCHES" to
>> say "all provided components match exactly and the rest can be whatever"?
> 
> I bet everybody will get it wrong.
> 
> Ok, this is "version 2.1 and any of it's patch versions", if _I_ got it right:
> 
> if (VER MATCHES "^2\\.1(\\..*|[^0-9].*)?$")
> 
> So this should match "2.1", "2.1a", "2.1.1", but not "2.10". What combination 
> of stuff did I miss?

...except I was talking about a new mode for find_package (*not*
necessarily a regex). IOW:

  find_package(Foo 2.1 MATCHES)

...finds Foo 2.1, 2.1.0, 2.1.beta, etc., but not 2.0, 2.0.1, 2.2, etc.

(In if(), if available at all (which maybe it needs to be), it would be
spelled VERSION_MATCHES.)

Anyway, your regex is overcomplicated; I'd think it would be just
'^2[.]1([.]|$)'. (I'd be a little hesitant to allow '2.1a' to match
'2.1'... is that '2.1 alpha' or 'release "a" after 2.1'? Or the release
following '2.19' because someone is using hex version numbers? I'm not
entirely sure that *any* of those should "match" 2.1, and certainly at
most only one should match.)

-- 
Matthew


From Robert.Goulet at autodesk.com  Mon Jan 12 12:39:35 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Mon, 12 Jan 2015 17:39:35 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <54B3CBA3.4000703@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>

Unfortunately I cannot do that, but I can tell you that the generated line in the .vcxproj file looks correct :

<AdditionalDependencies>android;dl;EGL;GLESv3;OpenSLES;-Wl,--start-group;libfoo.a;libbar.a;-Wl,--end-group</AdditionalDependencies>

So now I am guessing the problem is in the glue that adds support of Android to the VS IDE?
Where is the code that translate a link library into the command line, such as "libfoo.a" to "-lfoo"?

Thanks!


-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, January 12, 2015 8:27 AM
To: Robert Goulet
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/9/2015 4:28 PM, Robert Goulet wrote:
> I realize the cmake documentation says that everything that starts 
> with "-" should be treated as other linker flags, so I wonder, perhaps 
> it's a new bug, or maybe just with a specific generator? In this case 
> I am using the new NVidia NSight Android generator for Visual Studio.
[snip]
> -l"-Wl,--start-group" ?lfoo ?lbar ?l"-Wl,--end-group"

It is likely specific to that (new) generator.

Please post the .vcxproj file that is generated for that.

Thanks,
-Brad

From brad.king at kitware.com  Mon Jan 12 13:06:04 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jan 2015 13:06:04 -0500
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54B40D0C.5070009@kitware.com>

On 1/12/2015 12:39 PM, Robert Goulet wrote:
> the generated line in the .vcxproj file looks correct :
> 
> <AdditionalDependencies>android;dl;EGL;GLESv3;OpenSLES;-Wl,--start-group;libfoo.a;libbar.a;-Wl,--end-group</AdditionalDependencies>
> 
> So now I am guessing the problem is in the glue that adds support of Android to the VS IDE?
> Where is the code that translate a link library into the command line, such as "libfoo.a" to "-lfoo"?

That is in the Nsight Tegra implementation AFAIK.  Here is
a related change already in 3.1.0:

 VS: Fix Tegra-Android platform linking of libraries by name
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=178f56a5

Dmitry, how does Nsight Tegra transform these flags?

Thanks,
-Brad

From ben.boeckel at kitware.com  Mon Jan 12 13:51:37 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 12 Jan 2015 13:51:37 -0500
Subject: [cmake-developers] Improving the version selection behavior of
 EXACT
In-Reply-To: <m90tdj$o4k$1@ger.gmane.org>
References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <m8p5ot$ape$1@ger.gmane.org>
 <22203882.FFY0rs2GGb@eto> <m90tdj$o4k$1@ger.gmane.org>
Message-ID: <20150112185137.GA8244@megas.kitwarein.com>

On Mon, Jan 12, 2015 at 11:40:19 -0500, Matthew Woehlke wrote:
> Anyway, your regex is overcomplicated; I'd think it would be just
> '^2[.]1([.]|$)'. (I'd be a little hesitant to allow '2.1a' to match
> '2.1'... is that '2.1 alpha' or 'release "a" after 2.1'?

Depends on whether it's a "normal" project or OpenSSL or tzdata :) .

--Ben

From domen.vrankar at gmail.com  Tue Jan 13 01:55:04 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 13 Jan 2015 07:55:04 +0100
Subject: [cmake-developers] [PATCH] Setting default user,
	group and permissions for CPackRPM
Message-ID: <CAKgx6B+vbrDBcV3HpBRca=JeiOU2_01ka28otWxNyFL3d1QEZA@mail.gmail.com>

Hi all,

I wrote a patch for http://www.cmake.org/Bug/view.php?id=14714 which
add support for defining RPM package default user, group, file
permissions and directory permissions (default file and dir
permissions accept the same values that are defined for install
command PERMISSIONS without SETUID and SETGID).

This patch is somewhat related to
http://public.kitware.com/pipermail/cmake/2014-December/059460.html
(bug report: http://www.cmake.org/Bug/view.php?id=3602) as it defines
user and group that should be used for RPM content but on a per RPM
scale since it is not possible to define it in install command.

My question is if such functionality would be useful for other CPack
packagers as well?

If yes for default user and group I would suggest adding the following
variables to CPack and the attached patch:
CPACK_DEFAULT_USER and CPACK_<compName>_DEFAULT_USER for default user setting
CPACK_DEFAULT_GROUP and CPACK_<compName>_DEFAULT_GROUP for default group setting
and if there would also be interest in default permissions also:
CPACK_DEFAULT_FILE_PERMISSIONS and
CPACK_<compName>_DEFAULT_FILE_PERMISSIONS for default file permissions
and
CPACK_DEFAULT_DIR_PERMISSIONS and
CPACK_<compName>_DEFAULT_DIR_PERMISSIONS for default directory permissions

Regards,
Domen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cpack-rpm-setting-of-defattr.patch
Type: text/x-diff
Size: 10219 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150113/7a24a953/attachment-0001.patch>

From mantis at public.kitware.com  Tue Jan 13 05:41:49 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 13 Jan 2015 11:41:49 +0100
Subject: [cmake-developers] [CMake 0015346]: Xcode generator default target
	is no longer "ALL_BUILD"
Message-ID: <ad4214b3c29a6db31ed0deb5bfd96712@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15346 
====================================================================== 
Reported By:                Daniele E. Domenichelli
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15346
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-13 11:41 CET
Last Modified:              2015-01-13 11:41 CET
====================================================================== 
Summary:                    Xcode generator default target is no longer
"ALL_BUILD"
Description: 
Since CMake 3.1, the order of the targets is changed and therefore the default
target for Xcode generator is no longer "ALL_BUILD" if there is at least one
install command. Also some other custom targets were moved to the top of the
list.

Steps to Reproduce: 
Using this small project:

  cmake_minimum_required(VERSION 2.8.9)
  project(FOO)
  install(CODE "message(FATAL_ERROR \"This fatal error should not happen\")")



- CMake 3.0.2

   * "xcodebuild -list" prints

       Targets:
          ALL_BUILD
          ZERO_CHECK
          install

   * "xcodebuild" executes the "ALL_BUILD" target

   * "cmake --build ." executes the "ALL_BUILD" target


- CMake 3.1

   * "xcodebuild -list" prints

       Targets:
          install
          ALL_BUILD
          ZERO_CHECK

   * "xcodebuild" executes the "install" target (and fails)

   * "cmake --build ." executes the "ALL_BUILD" target


Building the project with "cmake --build ." still works because it calls the
correct target, but "xcodebuild" fails because the "install" target is called
instead of the "ALL_BUILD" one.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-13 11:41 Daniele E. DomenichelliNew Issue                               
    
======================================================================


From dpolyanitsa at nvidia.com  Tue Jan 13 06:19:11 2015
From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa)
Date: Tue, 13 Jan 2015 11:19:11 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <54B40D0C.5070009@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
Message-ID: <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>

Hi Brad, Robert,

Here's the algorithm in short: we split the string by the semicolon and then merge it again, processing each entry as follows. If it contains a slash (forward or backward) or ends with a .so or .a, we consider it to be a fully specified path and don?t add the "-l" prefix. Otherwise, we add it. We also do some additional processing to handle parentheses (we use them to denote start/end of the groups), but it should be orthogonal to the addition of the prefix.

Speaking of which, you could try using parentheses instead of -Wl,--start-group/-Wl,--end-group to define a linker group in the CMakeLists.txt file. The following worked for me (note the escaping):
target_link_libraries(twolib-second twolib-first \( c m gcc log \))

This won't be compatible with other generators I presume, but at least it should serve as a workaround while we fix the prefix addition to the -Wl flags in Nsight Tegra.

-Dmitry

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, January 12, 2015 9:06 PM
To: Robert Goulet
Cc: Justin Borodinsky; cmake-developers at cmake.org; Dmitry Polyanitsa
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/12/2015 12:39 PM, Robert Goulet wrote:
> the generated line in the .vcxproj file looks correct :
> 
> <AdditionalDependencies>android;dl;EGL;GLESv3;OpenSLES;-Wl,--start-gro
> up;libfoo.a;libbar.a;-Wl,--end-group</AdditionalDependencies>
> 
> So now I am guessing the problem is in the glue that adds support of Android to the VS IDE?
> Where is the code that translate a link library into the command line, such as "libfoo.a" to "-lfoo"?

That is in the Nsight Tegra implementation AFAIK.  Here is a related change already in 3.1.0:

 VS: Fix Tegra-Android platform linking of libraries by name
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=178f56a5

Dmitry, how does Nsight Tegra transform these flags?

Thanks,
-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From sergey.nikulov at gmail.com  Tue Jan 13 08:58:53 2015
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Tue, 13 Jan 2015 16:58:53 +0300
Subject: [cmake-developers] FindBoost // patch for current boost versions
Message-ID: <CAE7Ac0AoZZgupj40x69SSdRCWQv2n+SMm-LSH0i3PZjxwwCuOg@mail.gmail.com>

Hello!

I've updated _Boost_KNOWN_VERSIONS to help cmake find current Boost C++
version.
Also I've added upcoming milestone 1.58.0 in advance.

Could you please review and merge?

I've also submitted PR https://github.com/Kitware/CMake/pull/139 against
latest master.

Thank you.

-- 
Best Regards,
Sergei Nikulov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150113/9d9bc61c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-added-latest-boost-version-1.57.0-and-next-milestone.patch
Type: application/octet-stream
Size: 1073 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150113/9d9bc61c/attachment.obj>

From brad.king at kitware.com  Tue Jan 13 09:05:11 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Jan 2015 09:05:11 -0500
Subject: [cmake-developers] FindBoost // patch for current boost versions
In-Reply-To: <CAE7Ac0AoZZgupj40x69SSdRCWQv2n+SMm-LSH0i3PZjxwwCuOg@mail.gmail.com>
References: <CAE7Ac0AoZZgupj40x69SSdRCWQv2n+SMm-LSH0i3PZjxwwCuOg@mail.gmail.com>
Message-ID: <54B52617.8080705@kitware.com>

On 1/13/2015 8:58 AM, Sergei Nikulov wrote:
> I've updated _Boost_KNOWN_VERSIONS to help cmake find current Boost C++
> version.
> Also I've added upcoming milestone 1.58.0 in advance.

Applied, thanks:

 FindBoost: Add latest Boost version 1.57.0 and next milestone 1.58.0
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4048f7cd

-Brad

From brad.king at kitware.com  Tue Jan 13 09:10:39 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Jan 2015 09:10:39 -0500
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
Message-ID: <54B5275F.5070502@kitware.com>

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to the
> -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach
CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for
INTERFACE_LINK_LIBRARIES the libraries should show up repeated in
the .vcxproj file.

-Brad

From Robert.Goulet at autodesk.com  Tue Jan 13 10:36:45 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 13 Jan 2015 15:36:45 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <54B5275F.5070502@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

From dpolyanitsa at nvidia.com  Tue Jan 13 10:47:31 2015
From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa)
Date: Tue, 13 Jan 2015 15:47:31 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] 
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From Robert.Goulet at autodesk.com  Tue Jan 13 10:51:56 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 13 Jan 2015 15:51:56 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>

Using NVidia NSight Tegra 3.0r3. Upgrading to 3.0r4 is not an option right now because it would require all our users to use and nightly build of CMake and we want to stick with official releases.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] 
Sent: Tuesday, January 13, 2015 10:48 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From dpolyanitsa at nvidia.com  Tue Jan 13 11:01:21 2015
From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa)
Date: Tue, 13 Jan 2015 16:01:21 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <ebb0b08506cb4173861425f0b4db2f4d@UKMAIL102.nvidia.com>

Ah, in that case I'm afraid it won't work since we've added the parentheses syntax in 3.0r4.

The only other option I can think of is using the Linker -> Command Line -> Additional Options to manually add all the dependencies and leave the Linker -> Input -> Additional Dependencies empty. These additional options are passed to the linker unchanged and lots of people have been using them to define linker groups before we've introduced the official syntax for that. I'm not sure how you can write to that property from CMakeLists.txt, however.

Brad, can we do that in CMake? Our additional options are compatible with VC++ ones in terms of the metadata name, i.e. it's Link.AdditionalOptions.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] 
Sent: Tuesday, January 13, 2015 6:52 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Using NVidia NSight Tegra 3.0r3. Upgrading to 3.0r4 is not an option right now because it would require all our users to use and nightly build of CMake and we want to stick with official releases.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 10:48 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From Robert.Goulet at autodesk.com  Tue Jan 13 11:08:47 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 13 Jan 2015 16:08:47 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <ebb0b08506cb4173861425f0b4db2f4d@UKMAIL102.nvidia.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <ebb0b08506cb4173861425f0b4db2f4d@UKMAIL102.nvidia.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF64A6@005-TK5MPN4-042.MGDADSK.autodesk.com>

Problem with that is that we are using generator expressions in the library path names. That won't work when trying to set CMAKE_EXE_LINKER_FLAGS if I'm not mistaken.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] 
Sent: Tuesday, January 13, 2015 11:01 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Ah, in that case I'm afraid it won't work since we've added the parentheses syntax in 3.0r4.

The only other option I can think of is using the Linker -> Command Line -> Additional Options to manually add all the dependencies and leave the Linker -> Input -> Additional Dependencies empty. These additional options are passed to the linker unchanged and lots of people have been using them to define linker groups before we've introduced the official syntax for that. I'm not sure how you can write to that property from CMakeLists.txt, however.

Brad, can we do that in CMake? Our additional options are compatible with VC++ ones in terms of the metadata name, i.e. it's Link.AdditionalOptions.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:52 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Using NVidia NSight Tegra 3.0r3. Upgrading to 3.0r4 is not an option right now because it would require all our users to use and nightly build of CMake and we want to stick with official releases.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 10:48 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From mantis at public.kitware.com  Tue Jan 13 11:10:12 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 13 Jan 2015 11:10:12 -0500
Subject: [cmake-developers] [CMake 0015347]: Eclipse indexing no longer works
Message-ID: <6904de8d320cb7f8cf4e139b0feec540@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15347 
====================================================================== 
Reported By:                Christopher Buxenstein
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15347
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-13 11:10 EST
Last Modified:              2015-01-13 11:10 EST
====================================================================== 
Summary:                    Eclipse indexing no longer works
Description: 
We are experiencing the same issue reported by another user (Tushar Soni) at
http://cmake.3232098.n2.nabble.com/Cmake-3-0-2-Eclipse-project-indexing-issues-under-linux-td7588680.html.
 Since I don't see their issue reported here, I am copying their response here
so it is tracked.

The issue is that Eclipse is only indexing the contents of [Source directory]
and does not include subprojects.



[Tushar Soni's original message]
Hi,

After generating Eclipse projects and importing them, Eclipse is not indexing
all source files. I have detailed the issue (so sorry for the long email) and
the experiments I have performed to resolve the issue. I would be really glad if
someone could point out, what is going wrong or is there some bug?

Not to go in too much details, here is how my directory (project) structure
looks like in order to explain the issue in more details:

Sources: 

$someDir/common/project_a/src/source_a.cpp
$someDir/common/project_a/CMakeLists.txt -> Project A is a common lib, uses by
many tests

$someDir/tests/test_a/src/test_a.cpp
$someDir/tests/test_a/CMakeLists.txt -> Includes the Project A using
add_subdirectory and creates a share object

Cmake build directories:
$someDir/cmakeOut/common/project_a/
$someDir/cmakeOut/tests/test_a/

Cmake generated everything without errors and building the project using make or
Eclipse was not an issue. The issue is only when I import the project in Eclipse
(version 4.3.2) by Import -> General -> Existing Project ->
$someDir/cmakeOut/tests/test_a/, the indexer does not seem to be working
properly. It only indexes one source (test_a.cpp) whereas it should index two
(test_a.cpp + sourc_a.cpp).

this is just an example setup, in my actual project, only 1 source file gets
indexed out of the 142 it should do. therefore it makes using Eclipse very hard!

Now this is what I noticed with my experiments.

Experiment 1: Change cmake version and compare

I used the exact same files and folder structure but changed the cmake version
to 2.8.10.2. The generated Eclipse project was able to index both the source
files! This was mind boggling. I have to use the cmake 3.0.2 version, so I tried
to narrow down the issue. 

When I did the diff of the .cproject created by the two cmake version I saw
this:

cmake 3.0.2 has this in the .cproject

<pathentry kind="src" path="[Source directory]"/>
<pathentry excluding="[Source directory]/|**/CMakeFiles/" kind="out" path=""/>

cmake 2.8.10.2 has this in the .cproject

<pathentry excluding="**/CMakeFiles/" kind="out" path=""/>

The rest of the file is similar (except cmake path, which is obvious).

Success Result: If I delete the line <pathentry kind="src" path="[Source
directory]"/> from the .cproject and then import the project, indexing seems to
be working!!! however I cant use this solution as my project is not checked in
and every body using it needs to make this step manually.

Experiment 2: Change the import method

After a lot of googling I found out that someone was suggesting to import the
project using this method (BTW, for totally different problem): Import -> C/C++
-> Existing Code as Makefile Project -> $someDir/cmakeOut/tests/test_a/ . When I
did this, it again works! Mind boggling yet again!

Just by chance I found out that this method works because, by importing this way
Eclipse somehow modifies the .cproject and removed the lines like I did in first
experiment. 

Conclusion: So based on my experiments this line in the .cproject is causing an
issue with indexing:
<pathentry kind="src" path="[Source directory]"/>

I know most likely my conclusion is not correct but I do not have any other
explanation. Also I do not know why this line is actually the issue! Therfore I
am writing to you all to understand the issue a bit better. Maybe the issue is
elsewhere.

Thanks in advance!
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-13 11:10 Christopher BuxensteinNew Issue                                
   
======================================================================


From dpolyanitsa at nvidia.com  Tue Jan 13 12:29:27 2015
From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa)
Date: Tue, 13 Jan 2015 17:29:27 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF64A6@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <ebb0b08506cb4173861425f0b4db2f4d@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF64A6@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <8f507b5ae95440a5970782dd001134f0@UKMAIL102.nvidia.com>

Well, in this particular case I believe we can patch the old release of Nsight Tegra that you're using to make it behave properly when -Wl,--start-group/-Wl,--end-group is encountered in the linker dependencies. Updating the old TADP to contain the fixed version of Nsight Tegra won't be a fast task, but we could provide you with the latter directly via email/FTP. How does that sound?

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] 
Sent: Tuesday, January 13, 2015 7:09 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Problem with that is that we are using generator expressions in the library path names. That won't work when trying to set CMAKE_EXE_LINKER_FLAGS if I'm not mistaken.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 11:01 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Ah, in that case I'm afraid it won't work since we've added the parentheses syntax in 3.0r4.

The only other option I can think of is using the Linker -> Command Line -> Additional Options to manually add all the dependencies and leave the Linker -> Input -> Additional Dependencies empty. These additional options are passed to the linker unchanged and lots of people have been using them to define linker groups before we've introduced the official syntax for that. I'm not sure how you can write to that property from CMakeLists.txt, however.

Brad, can we do that in CMake? Our additional options are compatible with VC++ ones in terms of the metadata name, i.e. it's Link.AdditionalOptions.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:52 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Using NVidia NSight Tegra 3.0r3. Upgrading to 3.0r4 is not an option right now because it would require all our users to use and nightly build of CMake and we want to stick with official releases.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 10:48 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From Robert.Goulet at autodesk.com  Tue Jan 13 12:39:51 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 13 Jan 2015 17:39:51 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <8f507b5ae95440a5970782dd001134f0@UKMAIL102.nvidia.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <ebb0b08506cb4173861425f0b4db2f4d@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF64A6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <8f507b5ae95440a5970782dd001134f0@UKMAIL102.nvidia.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121DF6B3D@005-TK5MPN4-042.MGDADSK.autodesk.com>

Thank you very much Dmitry, but I actually found a not-so-ugly work-around for now. I simply add the libraries twice and it works for us (target_link_library(${PROJECT_NAME} foo bar foo bar)), so you won't have to issue a special build for us. We are getting very close to release so for now we'd rather not upgrade Nsight Tegra yet, but as soon as the pressure is over I will be looking into this again and make it my top priority. Thanks!

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] 
Sent: Tuesday, January 13, 2015 12:29 PM
To: Robert Goulet
Cc: Brad King; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Well, in this particular case I believe we can patch the old release of Nsight Tegra that you're using to make it behave properly when -Wl,--start-group/-Wl,--end-group is encountered in the linker dependencies. Updating the old TADP to contain the fixed version of Nsight Tegra won't be a fast task, but we could provide you with the latter directly via email/FTP. How does that sound?

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 7:09 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Problem with that is that we are using generator expressions in the library path names. That won't work when trying to set CMAKE_EXE_LINKER_FLAGS if I'm not mistaken.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 11:01 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Ah, in that case I'm afraid it won't work since we've added the parentheses syntax in 3.0r4.

The only other option I can think of is using the Linker -> Command Line -> Additional Options to manually add all the dependencies and leave the Linker -> Input -> Additional Dependencies empty. These additional options are passed to the linker unchanged and lots of people have been using them to define linker groups before we've introduced the official syntax for that. I'm not sure how you can write to that property from CMakeLists.txt, however.

Brad, can we do that in CMake? Our additional options are compatible with VC++ ones in terms of the metadata name, i.e. it's Link.AdditionalOptions.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:52 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Using NVidia NSight Tegra 3.0r3. Upgrading to 3.0r4 is not an option right now because it would require all our users to use and nightly build of CMake and we want to stick with official releases.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 10:48 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From dpolyanitsa at nvidia.com  Tue Jan 13 12:42:39 2015
From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa)
Date: Tue, 13 Jan 2015 17:42:39 +0000
Subject: [cmake-developers] target_link_libraries and
 --start-group/--end-group ?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121DF6B3D@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <6285449e56d747268b8bec92cdda5df1@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF6387@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <ebb0b08506cb4173861425f0b4db2f4d@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF64A6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <8f507b5ae95440a5970782dd001134f0@UKMAIL102.nvidia.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF6B3D@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <4b427efd192f445b9b403bc4348b8cfe@UKMAIL102.nvidia.com>

No problem, I'm glad it worked for you in the end :)

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] 
Sent: Tuesday, January 13, 2015 8:40 PM
To: Dmitry Polyanitsa
Cc: Brad King; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Thank you very much Dmitry, but I actually found a not-so-ugly work-around for now. I simply add the libraries twice and it works for us (target_link_library(${PROJECT_NAME} foo bar foo bar)), so you won't have to issue a special build for us. We are getting very close to release so for now we'd rather not upgrade Nsight Tegra yet, but as soon as the pressure is over I will be looking into this again and make it my top priority. Thanks!

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 12:29 PM
To: Robert Goulet
Cc: Brad King; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Well, in this particular case I believe we can patch the old release of Nsight Tegra that you're using to make it behave properly when -Wl,--start-group/-Wl,--end-group is encountered in the linker dependencies. Updating the old TADP to contain the fixed version of Nsight Tegra won't be a fast task, but we could provide you with the latter directly via email/FTP. How does that sound?

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 7:09 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Problem with that is that we are using generator expressions in the library path names. That won't work when trying to set CMAKE_EXE_LINKER_FLAGS if I'm not mistaken.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 11:01 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Ah, in that case I'm afraid it won't work since we've added the parentheses syntax in 3.0r4.

The only other option I can think of is using the Linker -> Command Line -> Additional Options to manually add all the dependencies and leave the Linker -> Input -> Additional Dependencies empty. These additional options are passed to the linker unchanged and lots of people have been using them to define linker groups before we've introduced the official syntax for that. I'm not sure how you can write to that property from CMakeLists.txt, however.

Brad, can we do that in CMake? Our additional options are compatible with VC++ ones in terms of the metadata name, i.e. it's Link.AdditionalOptions.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:52 PM
To: Dmitry Polyanitsa; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Using NVidia NSight Tegra 3.0r3. Upgrading to 3.0r4 is not an option right now because it would require all our users to use and nightly build of CMake and we want to stick with official releases.

-----Original Message-----
From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com]
Sent: Tuesday, January 13, 2015 10:48 AM
To: Robert Goulet; Brad King
Cc: Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Robert,

What Nsight Tegra version are you using? The AdditionalDependencies string you've described should be correctly parsed as libraries list with a group in the latest Nsight Tegra release.

Unfortunately, the existence of a declarative-style platform files workaround is unlikely - we do most of the processing in the build tasks DLL, which is written in C#, so you cannot easily alter things there.

-Dmitry

-----Original Message-----
From: Robert Goulet [mailto:Robert.Goulet at autodesk.com]
Sent: Tuesday, January 13, 2015 6:37 PM
To: Brad King
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: RE: [cmake-developers] target_link_libraries and --start-group/--end-group ?

Hi all,

Dmitry suggestion didn't work. It outputs the following in the .vcxproj file:

<AdditionalDependencies>c;m;dl;log;android;EGL;GLESv2;OpenSLES;(;foo;bar;)</AdditionalDependencies>

...and Nsight Tegra interpreted it like this (clang compiler):

-l"c" -l"m" -l"dl" -l"log" -l"android" -l"EGL" -l"GLESv2" -l"OpenSLES" -l"(" -l"foo" -l"bar" -l")"

...which obviously generated a link error (cannot find library '(' and ')').

Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant.

Dmitry, is there a work-around I could temporarily implement in the VS files until you issue a new version of Nsight Tegra? i.e. the files found under "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Tegra-Android" ?

Thanks.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, January 13, 2015 9:11 AM
To: Robert Goulet
Cc: Dmitry Polyanitsa; Justin Borodinsky; cmake-developers at cmake.org
Subject: Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?

On 1/13/2015 6:19 AM, Dmitry Polyanitsa wrote:
> you could try using parentheses instead of 
> -Wl,--start-group/-Wl,--end-group
[snip]
> it should serve as a workaround while we fix the prefix addition to 
> the -Wl flags in Nsight Tegra.

Thanks, Dmitry.

Robert, the linker group flags are platform-specific so the approach CMake offers for doing this in general is the "link multiplicity"
approach Robert Maynard mentioned earlier in this thread:

On 1/6/2015 3:50 PM, Robert Goulet wrote:
> But it doesn't seems to work when building for NVidia NSight Android 
> platform using Visual Studio IDE.

With IMPORTED_LINK_INTERFACE_MULTIPLICITY and circular settings for INTERFACE_LINK_LIBRARIES the libraries should show up repeated in the .vcxproj file.

-Brad

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

From steveire at gmail.com  Tue Jan 13 17:48:33 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 13 Jan 2015 23:48:33 +0100
Subject: [cmake-developers] Generator Expressions and packages (Was:
	target_link_libraries and --start-group/--end-group ?)
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <m947c1$pou$2@ger.gmane.org>

Robert Goulet wrote:

> Using Brad's method of link multiplicity is too much work because we make
> use of packages and heavy generator expressions, making it a lot more
> difficult and much less elegant.

Hi Robert,

We have not had much external feedback from the generator expressions and 
IMPORTED targets in packages features, so this is interesting to me.

Can you say what you rely on those features for? Which generator expressions 
you use? Limitations you hit? Experience learning to use the features?

Thanks,

Steve.



From dendy.ua at gmail.com  Wed Jan 14 04:11:50 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Wed, 14 Jan 2015 04:11:50 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
Message-ID: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>

Story short: we need Ninja generator running on Windows with Unix
environment. With exactly the same purpose as 'Unix Makefiles' one.

Where this is used: actually, in the same cases when 'Unix Makefiles' used
on Windows.

Particularly in my personal case 'Unix Ninja' generator is the only way to
use Ninja with QNX toolchain on Windows. The background of this is horrible
default make performance that comes with QNX SDK. At the same time regular
Ninja generator cannot be used with QNX SDK because latter always emulates
Unix environment in his toolchain. So we stuck with 'Unix Makefiles'.

And even more exciting news, I already done this for you. Attached patch is
fast forward to v3.1.0 tag. It is not supposed to be clean and maybe does
not cover all tricky use cases, but it works damn good for me when building
huge QNX project with tens of libraries and executables in the same
directory.

Please review and tell me what do you think overall about this idea.

Thanks,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150114/cf49a2a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Ninja-Add-Unix-Ninja-generator.patch
Type: application/octet-stream
Size: 65791 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150114/cf49a2a5/attachment-0001.obj>

From dendy.ua at gmail.com  Wed Jan 14 04:31:45 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Wed, 14 Jan 2015 04:31:45 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
Message-ID: <CAAvz69w0iMr_rqCx7szo_u0+7qGrte6+4U+nCgU1VOz7Ge+yEQ@mail.gmail.com>

Sorry for including garbage QtCreator files into formatted patch in
previous e-mail.
Attached clean patch with changes only.

Thanks,
Daniel

On Wed, Jan 14, 2015 at 4:11 AM, Daniel Levin <dendy.ua at gmail.com> wrote:

> Story short: we need Ninja generator running on Windows with Unix
> environment. With exactly the same purpose as 'Unix Makefiles' one.
>
> Where this is used: actually, in the same cases when 'Unix Makefiles' used
> on Windows.
>
> Particularly in my personal case 'Unix Ninja' generator is the only way to
> use Ninja with QNX toolchain on Windows. The background of this is horrible
> default make performance that comes with QNX SDK. At the same time regular
> Ninja generator cannot be used with QNX SDK because latter always emulates
> Unix environment in his toolchain. So we stuck with 'Unix Makefiles'.
>
> And even more exciting news, I already done this for you. Attached patch
> is fast forward to v3.1.0 tag. It is not supposed to be clean and maybe
> does not cover all tricky use cases, but it works damn good for me when
> building huge QNX project with tens of libraries and executables in the
> same directory.
>
> Please review and tell me what do you think overall about this idea.
>
> Thanks,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150114/ce5e7bba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Ninja-Add-Unix-Ninja-generator.patch
Type: application/octet-stream
Size: 12979 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150114/ce5e7bba/attachment.obj>

From mantis at public.kitware.com  Wed Jan 14 09:14:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Jan 2015 09:14:07 -0500
Subject: [cmake-developers] [CMake 0015349]: The regular expression in
	CMakeDetermineCompilerID.cmake strips out qnxnto
Message-ID: <78793171ba88b6b1702855b4e8f92508@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15349 
====================================================================== 
Reported By:                Rodney Dowdall
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15349
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-14 09:14 EST
Last Modified:              2015-01-14 09:14 EST
====================================================================== 
Summary:                    The regular expression in
CMakeDetermineCompilerID.cmake strips out qnxnto
Description: 
The regular expression that is used to determine compiler info on line 425 of
CMakeDetermineCompilerID.cmake fails to match qnxnto.  This means that you
cannot use cmake to generate Makefiles for qcc anymore.  What happens is that it
fails to set the COMPILER_QNXNTO variable and then further on down the process
it adds compiler flags for a GNU compiler that are not supported by the qcc
compiler. If this regular expression is removed, then cmake correctly identifies
qcc and sets the COMPILER_QNXNTO variable. 

Steps to Reproduce: 
Set the CMAKE_C_COMPILER to "qcc" and the DCMAKE_CXX_COMPILER="qcc" and try and
build something like webkit.  It will pass in the -isystem flag to the qcc
compiler.  This flag is not supported.  You will also see a message about
failing to determine compiler settings while cmake is generating the cmake
files.  If you remove the regular expression from the
CMakeDetermineCompilerID.cmake file, then that message disappears. 
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-14 09:14 Rodney Dowdall New Issue                                    
======================================================================


From brad.king at kitware.com  Wed Jan 14 10:07:10 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 14 Jan 2015 10:07:10 -0500
Subject: [cmake-developers] pause on new topics please
Message-ID: <54B6861E.9090305@kitware.com>

Hi Folks,

There are several open topics in 'next' right now that
have been churning on the dashboard for a few days.
Please refrain from adding more topics to 'next' while
we work these out.  Of course topics for documentation-only
changes or fixes to existing dashboard problems are still
allowed.

Thanks,
-Brad

From mantis at public.kitware.com  Wed Jan 14 11:19:03 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Jan 2015 11:19:03 -0500
Subject: [cmake-developers] [CMake 0015351]: Dependencies not detected when
	comment is in front of #include statement
Message-ID: <508cda79c7943f74c8f574d80bd08782@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15351 
====================================================================== 
Reported By:                joachim
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15351
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-14 11:19 EST
Last Modified:              2015-01-14 11:19 EST
====================================================================== 
Summary:                    Dependencies not detected when comment is in front
of #include statement
Description: 
Generator: MinGW or MSYS Unix Makefiles

Consider code like this in main.cpp:
/* Comment */ #include "header.h"
#include "header2.h"

The header.h is never detected as dependency and does not appear in the
respective depend.make file:

CMakeFiles/simpleDemo.dir/main.cpp.obj: header2.h
CMakeFiles/simpleDemo.dir/main.cpp.obj: main.cpp


Additional Information: 
See attached zip for a little testproject.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-14 11:19 joachim        New Issue                                    
2015-01-14 11:19 joachim        File Added: simple.zip                       
======================================================================


From Robert.Goulet at autodesk.com  Wed Jan 14 11:20:52 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Wed, 14 Jan 2015 16:20:52 +0000
Subject: [cmake-developers] Generator Expressions and packages
	(Was:	target_link_libraries and --start-group/--end-group ?)
In-Reply-To: <m947c1$pou$2@ger.gmane.org>
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <m947c1$pou$2@ger.gmane.org>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E063D1@005-TK5MPN4-042.MGDADSK.autodesk.com>

To be honest I haven't spent much time trying to learn 'imported' libraries with CMake. It was already difficult to deal with commands that don't support generator expressions versus those that does. It wasn't clear which commands we should not try to use because of that, and in the end we had to rewrite part of the CMakeLists.txt file because we wanted to use generator expressions and packages.

Talking about that, what is the correct way to use generator expressions in a context of packages? find_library does not support generator expressions, so right now in our Find files we don't use it, we just set variables instead.

For example, consider the following external library setup:

root/lib/vs2012/x86/debug/foo.lib
root/lib/vs2012/x64/debug/foo.lib
root/lib/vs2012/x86/release/foo.lib
root/lib/vs2012/x64/release/foo.lib
root/lib/ios/debug/foo.a
root/lib/ios/release/foo.a
root/lib/android/debug/foo.a
root/lib/android/release/foo.a
etc...

How does one deal with such a setup, when all versions of the library use the same name, but in different paths, within a package context? It would have been nice if find_library supported generator expressions. But maybe I misunderstood how to properly deal with that?

Thanks.

-----Original Message-----
From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stephen Kelly
Sent: Tuesday, January 13, 2015 5:49 PM
To: cmake-developers at cmake.org
Subject: [cmake-developers] Generator Expressions and packages (Was: target_link_libraries and --start-group/--end-group ?)

Robert Goulet wrote:

> Using Brad's method of link multiplicity is too much work because we 
> make use of packages and heavy generator expressions, making it a lot 
> more difficult and much less elegant.

Hi Robert,

We have not had much external feedback from the generator expressions and IMPORTED targets in packages features, so this is interesting to me.

Can you say what you rely on those features for? Which generator expressions you use? Limitations you hit? Experience learning to use the features?

Thanks,

Steve.


-- 

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

From mantis at public.kitware.com  Wed Jan 14 13:11:03 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Jan 2015 13:11:03 -0500
Subject: [cmake-developers] [CMake 0015352]:
	find_package_handle_standard_args generates inadequate error
	message when last item in a list is unavailable
Message-ID: <e9a77addae3b67b94074870b747cbfac@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15352 
====================================================================== 
Reported By:                Joachim Wuttke
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15352
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-14 13:11 EST
Last Modified:              2015-01-14 13:11 EST
====================================================================== 
Summary:                    find_package_handle_standard_args generates
inadequate error message when last item in a list is unavailable
Description: 
Code example:

set (FOO_LIBRARIES ${FOO_LIB_A} ${FOO_LIB_B})
find_package_handle_standard_args (FOO DEFAULT_MSG FOO_LIBRARIES
FOO_INCLUDE_DIR)

If lib A is missing, I get the error message:

CMake Error: The following variables are used in this project, but they are set
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
FOO_LIB_A

However, if lib B (or more generally, the last item in FOO_LIBRARIES) is
missing, I get the less informative:

CMake Error at
/usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
  Could NOT find Foo (missing: FOO_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343
(_FPHSA_FAILURE_MESSAGE)
  my_cmake_modules/FindFoo.cmake:84 (find_package_handle_standard_args)

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-14 13:11 Joachim Wuttke New Issue                                    
======================================================================


From ben.boeckel at kitware.com  Wed Jan 14 17:36:31 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 14 Jan 2015 17:36:31 -0500
Subject: [cmake-developers] Generator Expressions and packages (Was:
 target_link_libraries and --start-group/--end-group ?)
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E063D1@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <m947c1$pou$2@ger.gmane.org>
 <B690D45ED8AB4146AE3D908EB41D0DA121E063D1@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <20150114223631.GA19601@megas.kitwarein.com>

On Wed, Jan 14, 2015 at 16:20:52 +0000, Robert Goulet wrote:
> To be honest I haven't spent much time trying to learn 'imported'
> libraries with CMake. It was already difficult to deal with commands
> that don't support generator expressions versus those that does. It
> wasn't clear which commands we should not try to use because of that,
> and in the end we had to rewrite part of the CMakeLists.txt file
> because we wanted to use generator expressions and packages.

Yeah, documentation for where commands accept genexes should be more
comprehensive (generally, if it isn't mentioned, they aren't supported
but I'm sure there are gaps in there).

> Talking about that, what is the correct way to use generator
> expressions in a context of packages? find_library does not support
> generator expressions, so right now in our Find files we don't use it,
> we just set variables instead.

Since CMake doesn't support hybrid Debug/Release build trees outside of
XCode or Visual Studio, general support is pretty hard. Basically, I'd
say export your targets where possible and make imported targets instead
of using variables elsewhere. There should be properties you can set to
indicate whether the found library is release or debug. Skimming the
docs shows the IMPORTED_CONFIGURATIONS property.

> For example, consider the following external library setup:
> 
> root/lib/vs2012/x86/debug/foo.lib
> root/lib/vs2012/x64/debug/foo.lib
> root/lib/vs2012/x86/release/foo.lib
> root/lib/vs2012/x64/release/foo.lib
> root/lib/ios/debug/foo.a
> root/lib/ios/release/foo.a
> root/lib/android/debug/foo.a
> root/lib/android/release/foo.a
> etc...
> 
> How does one deal with such a setup, when all versions of the library
> use the same name, but in different paths, within a package context?
> It would have been nice if find_library supported generator
> expressions. But maybe I misunderstood how to properly deal with that?

If this were the case, you wouldn't be able to know where the file is
until generate time (generator expressions may not have a real semantic
meaning until run *after* CMakeLists.txt has been parsed). The thing to
do here is find a debug path and a release path and set them either on
an imported target properly or use the
"debug;${debug_path};optimized;${optimized_path}" thing (though I'm not
all that familiar with what goes on with that).

--Ben

From mantis at public.kitware.com  Wed Jan 14 18:09:25 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Jan 2015 18:09:25 -0500
Subject: [cmake-developers] [CMake 0015354]: regression: ccache no longer
	works with cmake 3.1.2
Message-ID: <87cbc1a6399515ba002c1a278f390a9f@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15354 
====================================================================== 
Reported By:                Tom Hughes
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15354
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-14 18:09 EST
Last Modified:              2015-01-14 18:09 EST
====================================================================== 
Summary:                    regression: ccache no longer works with cmake 3.1.2
Description: 
Between cmake 3.0.2 and 3.1.2, ccache (v3.2.1) stopped working (I'm using the
ninja generator). I had been using ccache by setting CMAKE_C_COMPILER to ccache
and CMAKE_C_COMPILER_ARG1 to clang.

In the original project where I hit this, the error occurs during the first run
of cmake when it decides that it needs to re-run configure:

-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /usr/local/bin/ccache
CMAKE_CXX_COMPILER= /usr/local/bin/ccache
CMAKE_C_COMPILER= /usr/local/bin/ccache
CMAKE_CXX_COMPILER= /usr/local/bin/ccache

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- broken

However, in the simple test case that I created, it doesn't occur until you
touch the CMakeLists.txt and re-run ninja (see attachments).


Steps to Reproduce: 
I have a simple test case that reproduces the problem and a script that you can
use with "git bisect run" (attached as find-cmake-bug.sh).

That points to the following commit:

commit 6120fca8e229da08fae1d58017962491fb6e03f3
Author: Sylvain Joubert <joubert.sy at gmail.com>
Date:   Sat Sep 20 22:37:52 2014 +0200

    Ninja: Prevent compilers to be silently modified

    Unlike with Unix Makefiles generator modifying compiler paths was not
    protected with Ninja generator.  It was possible to modify them in the
    cache without the expected effect on the generated solution.  Also
    activate corresponding tests with Ninja.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-14 18:09 Tom Hughes     New Issue                                    
2015-01-14 18:09 Tom Hughes     File Added: cmake-ccache-bug.tar.gz             
      
======================================================================


From brad.king at kitware.com  Thu Jan 15 08:44:10 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 15 Jan 2015 08:44:10 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
Message-ID: <54B7C42A.8010103@kitware.com>

On 01/14/2015 04:11 AM, Daniel Levin wrote:
> we need Ninja generator running on Windows with Unix environment.
[snip]
> is the only way to use Ninja with QNX toolchain on Windows.

Thanks for working on this.

Each generator corresponds to a specific build tool.  Users should
select a generator based on the build tool and environment in which
they want to run, not the toolchain they want to use.  Unless there
is a separate "ninja" tool for this environment that is distinct
from the Windows "ninja", this should not need a separate generator.
>From your patch it looks like you're still using a normal ninja tool
but wrapping all command lines inside 'sh.exe'.

Perhaps the main Ninja generator can be taught how to generate the
command lines for this toolchain.  Much of your work on the patch
so far could probably be re-used for this approach.  It may need
to be integrated differently, though.

Side note: Have you tried running the Cygwin versions of CMake and
Ninja to drive this toolchain?

-Brad


From dendy.ua at gmail.com  Thu Jan 15 09:15:00 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Thu, 15 Jan 2015 09:15:00 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <54B7C42A.8010103@kitware.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
Message-ID: <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>

Brad,

The main problem was in environment when build tool is running from inside
of QNX SDK 'make' or 'sh' commands.
Those tools completely screw up the environment simulating Unix, so Ninja
cannot process generated *.ninja scripts normally anymore.

As soon as *.ninja scripts generated in the same way as on Unix (use
sh.exe, forward slashes, proper escaping, etc) regular Windows Ninja
executable runs normally under that QNX SDK shell.

I did not try Cygwin CMake, but expect it might produce similar output.
Maybe with exceptions to Windows drive letters. I predict that QNX SDK
might conflict with Cygwin environment, but did not check that actually.

I should also note that one of my goals was to keep using standard Windows
shell for both generation and build stages. This allows to continue using
native IDEs. For instance, when I work in QtCreator I simply override
'make' executable with 'ninja' and it keeps working normally.

Thanks,
Daniel

On Thu, Jan 15, 2015 at 8:44 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/14/2015 04:11 AM, Daniel Levin wrote:
> > we need Ninja generator running on Windows with Unix environment.
> [snip]
> > is the only way to use Ninja with QNX toolchain on Windows.
>
> Thanks for working on this.
>
> Each generator corresponds to a specific build tool.  Users should
> select a generator based on the build tool and environment in which
> they want to run, not the toolchain they want to use.  Unless there
> is a separate "ninja" tool for this environment that is distinct
> from the Windows "ninja", this should not need a separate generator.
> From your patch it looks like you're still using a normal ninja tool
> but wrapping all command lines inside 'sh.exe'.
>
> Perhaps the main Ninja generator can be taught how to generate the
> command lines for this toolchain.  Much of your work on the patch
> so far could probably be re-used for this approach.  It may need
> to be integrated differently, though.
>
> Side note: Have you tried running the Cygwin versions of CMake and
> Ninja to drive this toolchain?
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150115/497712c2/attachment-0001.html>

From brad.king at kitware.com  Thu Jan 15 10:34:58 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 15 Jan 2015 10:34:58 -0500
Subject: [cmake-developers] pause on new topics please
In-Reply-To: <54B6861E.9090305@kitware.com>
References: <54B6861E.9090305@kitware.com>
Message-ID: <54B7DE22.4090407@kitware.com>

On 01/14/2015 10:07 AM, Brad King wrote:
> Please refrain from adding more topics to 'next' while
> we work these out.

This is done.  Please proceed with normal development.

Thanks,
-Brad


From brad.king at kitware.com  Thu Jan 15 15:01:58 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 15 Jan 2015 15:01:58 -0500
Subject: [cmake-developers] [PATCH] Setting default user,
 group and permissions for CPackRPM
In-Reply-To: <CAKgx6B+vbrDBcV3HpBRca=JeiOU2_01ka28otWxNyFL3d1QEZA@mail.gmail.com>
References: <CAKgx6B+vbrDBcV3HpBRca=JeiOU2_01ka28otWxNyFL3d1QEZA@mail.gmail.com>
Message-ID: <54B81CB6.2070901@kitware.com>

On 01/13/2015 01:55 AM, Domen Vrankar wrote:
> This patch is somewhat related to
> http://public.kitware.com/pipermail/cmake/2014-December/059460.html
> (bug report: http://www.cmake.org/Bug/view.php?id=3602) as it defines
> user and group that should be used for RPM content but on a per RPM
> scale since it is not possible to define it in install command.

If it were possible to define it in the install() command, that would
be useful for local installs.  We would also need the information to
be communicated to the packaging step.  If such functionality existed,
would it eliminate the need for a CPack/RPM-specific solution?  Should
the staged install location for packaging not bother setting uid/gid
because they will be handled by the packaging tool instead?  We need
to be able to package on a host machine that does not have the users
or groups of the target machine (perhaps because a pre-install script
in the package creates the users/groups).

> My question is if such functionality would be useful for other CPack
> packagers as well?

I would think so.  The permissions are a property of the project and
target environment, not of the packaging tools.  Each CPack generator
should treat permissions according to the capabilities of its tools
and target environment.

-Brad


From mantis at public.kitware.com  Thu Jan 15 15:25:46 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 15 Jan 2015 15:25:46 -0500
Subject: [cmake-developers] [CMake 0015355]: cmake 3.1 doesn't know how to
	select CMAKE_CXX_STANDARD 11 on Mac OS
Message-ID: <0fd649ae264358281139e08ef2e67afb@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15355 
====================================================================== 
Reported By:                Laurent Demailly
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15355
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-15 15:25 EST
Last Modified:              2015-01-15 15:25 EST
====================================================================== 
Summary:                    cmake 3.1 doesn't know how to select
CMAKE_CXX_STANDARD 11 on Mac OS
Description: 
I have a very simple CMakeLists.txt ? am using cmake 3.1 to be able to easily
request C++ 11 ? it works fine on ubuntu but not on MacOS with Xcode 6 and
command line tools installed:

$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.1)

project("Test1" C CXX)

# We need C++ 11
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED on)

file(WRITE test1.cpp "int main(int argc, char** argv) {auto x=argc; return x;}")

add_executable(test1 test1.cpp)

$ cmake31 .
-- The C compiler identification is AppleClang 6.0.0.6000056
-- The CXX compiler identification is AppleClang 6.0.0.6000056
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
CMake Error in CMakeLists.txt:
  Target "test1" requires the language dialect "CXX11" (with compiler
  extensions), but CMake does not know the compile flags to use to enable it.


This is with 
CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
CXXFLAGS="-std=c++11"
But same without that


Steps to Reproduce: 
cmake_minimum_required(VERSION 3.1)

project("Test1" C CXX)

# We need C++ 11
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED on)

file(WRITE test1.cpp "int main(int argc, char** argv) {auto x=argc; return x;}")

add_executable(test1 test1.cpp)


====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-15 15:25 Laurent DemaillyNew Issue                                    
======================================================================


From domen.vrankar at gmail.com  Fri Jan 16 03:10:51 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 16 Jan 2015 09:10:51 +0100
Subject: [cmake-developers] [PATCH] Setting default user,
 group and permissions for CPackRPM
In-Reply-To: <54B81CB6.2070901@kitware.com>
References: <CAKgx6B+vbrDBcV3HpBRca=JeiOU2_01ka28otWxNyFL3d1QEZA@mail.gmail.com>
 <54B81CB6.2070901@kitware.com>
Message-ID: <CAKgx6B+xteU6V3-SZR4xYqo9E1Og70+6oB6rVLE6+LwrkRxUMw@mail.gmail.com>

> On 01/13/2015 01:55 AM, Domen Vrankar wrote:
>> This patch is somewhat related to
>> http://public.kitware.com/pipermail/cmake/2014-December/059460.html
>> (bug report: http://www.cmake.org/Bug/view.php?id=3602) as it defines
>> user and group that should be used for RPM content but on a per RPM
>> scale since it is not possible to define it in install command.

The provided patch is only somewhat related because it sets default
permissions, user and group on a global scale and can be overwritten
per file by install command. Currently all files are by default
installed through rpm as root:root (provided patch would at least add
global override option for this).

> If it were possible to define it in the install() command, that would
> be useful for local installs.  We would also need the information to
> be communicated to the packaging step.  If such functionality existed,
> would it eliminate the need for a CPack/RPM-specific solution?

The functionality described above is a workaround for cases when
CPack/RPM doesn't support some file manipulation that RPM spec files
support so the functionality would stay in place for the time being
but for setting user and group it would no longer be needed.

Currently you have to write something like this:

install(...) # command used to install file - this should be the only
requirement
set(CPACK_RPM_USER_FILELIST "%attr(-,usrname,groupname)
/opt/some_file") # set something like this for each file individually
(making CMakeLists.txt less readable, CPack/RPM generator specific and
more error prone)

> Should the staged install location for packaging not bother setting uid/gid
> because they will be handled by the packaging tool instead?
> We need to be able to package on a host machine that does not have the users
> or groups of the target machine (perhaps because a pre-install script
> in the package creates the users/groups).

I'm not certain about other CPack generators but for RPM user and
group don't need to exist as rpm packaging tool only sets user and
group without actually changing them - they are only actually set on
files during rpm installation.
RPM spec file requires user and group name and not uid/gid exactly
because on install environment the ids will probably differ from
packaging environment. That is why uid and gid in install command
don't help much - if CPack/RPM would use uid and gid from install
command it would be limited to users and groups listed in systems
/etc/passwd file.

I could write an initial patch for bug report 3602 that would add user
and group setting to install command and add that functionality to
CPack/RPM and later we could extend the use for install and other
CPack generators to use it as well (I also wrote some ideas for a
patch here http://www.cmake.org/pipermail/cmake/2015-January/059518.html).

>> My question is if such functionality would be useful for other CPack
>> packagers as well?
>
> I would think so.  The permissions are a property of the project and
> target environment, not of the packaging tools.  Each CPack generator
> should treat permissions according to the capabilities of its tools
> and target environment.

In this case I will add the defaults to be set to CPACK_ variables and
later the variables can be used by other CPack generators.

Regards,
Domen

From mantis at public.kitware.com  Fri Jan 16 05:15:17 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 16 Jan 2015 11:15:17 +0100
Subject: [cmake-developers] [CMake 0015356]: CodeBlocks: add target to which
	a file belongs to
Message-ID: <054ee928482c61fd26873facb723f1d2@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15356 
====================================================================== 
Reported By:                Peter Kuemmel
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15356
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-16 11:15 CET
Last Modified:              2015-01-16 11:15 CET
====================================================================== 
Summary:                    CodeBlocks: add target to which a file belongs to
Description: 
IDEs like QtCreator parse the cbp file to figure out compile options for each
file.

Currently it is not possible to figure out to which <Target title=> a file
belongs to and the IDE has to guess a target which is mostly done by the file
location.

But when there are multiple targets within the same directory with different
options the IDE has no chance to do the mapping file<->target right.

A <Unit> part within <Target> would solve the problem.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-16 11:15 Peter Kuemmel  New Issue                                    
======================================================================


From domen.vrankar at gmail.com  Fri Jan 16 06:01:59 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 16 Jan 2015 12:01:59 +0100
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
	prefixes
In-Reply-To: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
Message-ID: <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>

2014-12-31 2:03 GMT+01:00 Domen Vrankar <domen.vrankar at gmail.com>:
> Hello,
>
> Could somebody please review the topic rpm_multi_prefix.
>
> http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=c908ba3707fcf8cf43df0c5cd90f8ea6d98d7c29
>
> Patch adds support for multiple relocation paths per RPM package.
> For relocation paths I have extended GNUInstallDirs module since it
> already provides the required functionality but for install command.
> Is this OK?
>
> Thanks,
> Domen

This topic is now on stage branch for quite a while and since there
were no objections regarding extension of GNUInstallDirs module I'd
like to merge it to next.

Are there any specifics when merging topic from stage to next after it
has been on stage for a while?

Thanks,
Domen

From ono at java.pl  Fri Jan 16 06:54:13 2015
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 16 Jan 2015 12:54:13 +0100
Subject: [cmake-developers] CUDA as a compiler instead FindCUDA?
Message-ID: <9F2CF081-470B-42E4-9DCE-CB67BA7D2DD0@java.pl>

Hi. It makes me curious why CUDA support is not just implemented as compiler via proper CMakeDetermineCUDACompiler and other files defining how to handle .cu files, but rather it uses just awkward 3rd party functions, cmake script wrappers, etc, which basically obscure whole process and instead using "ninja -v" to see invocation of "nvcc" you need CUDA_VERBOSE_BUILD=YES which makes me more and more sick every time I use it.

Is it some kind of legacy reasons? If so is CMake open to accept patch that will make CUDA support via new compiler definition?

--Adam

From brad.king at kitware.com  Fri Jan 16 08:42:49 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 16 Jan 2015 08:42:49 -0500
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
 prefixes
In-Reply-To: <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
Message-ID: <54B91559.3030701@kitware.com>

On 01/16/2015 06:01 AM, Domen Vrankar wrote:
> This topic is now on stage branch for quite a while and since there
> were no objections regarding extension of GNUInstallDirs module I'd
> like to merge it to next.

Sorry I haven't been more responsive in reviewing this.  Your previous
response is still on my todo list.

> Are there any specifics when merging topic from stage to next after it
> has been on stage for a while?

You could rebase on 'master' just to reduce the chance of conflicts.

Go ahead and merge to 'next' for testing and follow up with any
dashboard trouble.  I'll still be able to review it there.

Thanks,
-Brad


From brad.king at kitware.com  Fri Jan 16 08:46:53 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 16 Jan 2015 08:46:53 -0500
Subject: [cmake-developers] CUDA as a compiler instead FindCUDA?
In-Reply-To: <9F2CF081-470B-42E4-9DCE-CB67BA7D2DD0@java.pl>
References: <9F2CF081-470B-42E4-9DCE-CB67BA7D2DD0@java.pl>
Message-ID: <54B9164D.5080507@kitware.com>

On 01/16/2015 06:54 AM, Adam Strzelecki wrote:
> Hi. It makes me curious why CUDA support is not just implemented
> as compiler via proper CMakeDetermineCUDACompiler

I don't think there is any reason besides no one doing it yet.

> is CMake open to accept patch that will make CUDA support via
> new compiler definition?

Yes!  Does CUDA distinguish between C and C++?  Should there be
separate "CUDAC" and "CUDACXX" languages?

Does Visual Studio or Xcode have any builtin CUDA support, perhaps
via a plugin?  This will affect how the corresponding generators
need to handle the language.  Without native support then they
will have to generate custom commands to build the languages.

-Brad


From brad.king at kitware.com  Fri Jan 16 10:58:29 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 16 Jan 2015 10:58:29 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>	<54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
Message-ID: <54B93525.5090709@kitware.com>

On 01/15/2015 09:15 AM, Daniel Levin wrote:
> running from inside of QNX SDK 'make' or 'sh' commands.
> Those tools completely screw up the environment simulating Unix,
> so Ninja cannot process generated *.ninja scripts normally anymore.

Interesting.  Please explain this in more detail.  How does one launch
the QNX SDK environment and then run "ninja" from inside that?  What
goes wrong with "ninja" from inside that environment?

Thanks,
-Brad


From william at lynch.us  Fri Jan 16 12:39:55 2015
From: william at lynch.us (William Lynch)
Date: Fri, 16 Jan 2015 12:39:55 -0500
Subject: [cmake-developers] [PATCH] Help: Correct two dead links to cmake.org
Message-ID: <CABmhRSX-BpjrDxh_c9JupTiifqGcTnSKbYWGXXBqEidJhs5bHQ@mail.gmail.com>

These links are currently 404s. The attached patch fixes them to point
to the correct destinations.

---
 Help/manual/LINKS.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Help/manual/LINKS.txt b/Help/manual/LINKS.txt
index f6f707d..38fd151 100644
--- a/Help/manual/LINKS.txt
+++ b/Help/manual/LINKS.txt
@@ -11,12 +11,12 @@ Frequently Asked Questions
  A Wiki is provided containing answers to frequently asked questions.

 Online Documentation
- http://www.cmake.org/HTML/Documentation.html
+ http://www.cmake.org/documentation

  Links to available documentation may be found on this web page.

 Mailing List
- http://www.cmake.org/HTML/MailingLists.html
+ http://www.cmake.org/mailing-lists

  For help and discussion about using cmake, a mailing list is
  provided at cmake at cmake.org.  The list is member-post-only but one
-- 
1.9.3 (Apple Git-50)

From dendy.ua at gmail.com  Fri Jan 16 13:13:56 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Fri, 16 Jan 2015 13:13:56 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <54B93525.5090709@kitware.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
Message-ID: <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>

Last time I made detailed analysis about year ago.
The CMake and Ninja were part of the bigger build script, which was running
under the QNX SDK sh.exe.
When running under this shell it overrides some environment variables
(compare attached files).
But as far as I remember it also does some nasty launcher overrides,
intercepting calls to cmd, bat and sh and tries to process them somehow
else.

Thanks,
Daniel

On Fri, Jan 16, 2015 at 10:58 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/15/2015 09:15 AM, Daniel Levin wrote:
> > running from inside of QNX SDK 'make' or 'sh' commands.
> > Those tools completely screw up the environment simulating Unix,
> > so Ninja cannot process generated *.ninja scripts normally anymore.
>
> Interesting.  Please explain this in more detail.  How does one launch
> the QNX SDK environment and then run "ninja" from inside that?  What
> goes wrong with "ninja" from inside that environment?
>
> Thanks,
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150116/7d2b0915/attachment.html>
-------------- next part --------------
!C:=c:\projects\tmp\ninja-deps\build-ninja
!EXITCODE=00000001
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\levind\AppData\Roaming
COMMANDER_DRIVE=C:
COMMANDER_EXE=C:\opt\total\TOTALCMD64.EXE
COMMANDER_INI=C:\opt\total\wincmd.ini
COMMANDER_PATH=C:\opt\total
COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files
COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files
COMMONPROGRAMW6432=C:\Program Files\Common Files
COMPUTERNAME=LEVINDGTLT
COMSPEC=C:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\levind
LOCALAPPDATA=C:\Users\levind\AppData\Local
LOGONSERVER=\\PTCPASADC1
NUMBER_OF_PROCESSORS=4
OS=Windows_NT
PATH=/usr/bin:/c/opt/perl/site/bin:/c/opt/perl/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/Common Files/Roxio Shared/DLLShared/:/c/Program Files (x86)/Common Files/Roxio Shared/10.0/DLLShared/:/c/bin:c:/c/opt/qgit:/c/opt/deltacopy:/c/opt/7z:/c/opt/cmake/win32/x86/bin:/c/opt/python33:/c/opt/perl/site/bin:/c/opt/perl/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/Common Files/Roxio Shared/DLLShared/:/c/Program Files (x86)/Common Files/Roxio Shared/10.0/DLLShared/
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3a09
PROGRAMDATA=C:\ProgramData
PROGRAMFILES=C:\Program Files (x86)
PROGRAMFILES(X86)=C:\Program Files (x86)
PROGRAMW6432=C:\Program Files
PROMPT=$P$G
PSI_ENABLE_VIDEO=1
PSMODULEPATH=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
PWD=/c/projects/tmp/ninja-deps/build-ninja
QNXLM_LICENSE_FILE=@10.144.209.10
QNX_CONFIGURATION=c:\opt\qnx-software-systems
QNX_HOST=c:\opt\qnx650-gcc-4.8.1\host\win32\x86
QNX_TARGET=c:\opt\qnx650-gcc-4.8.1\target\qnx6
ROXIOCENTRAL=C:\Program Files (x86)\Common Files\Roxio Shared\10.0\Roxio Central36\
SESSIONNAME=Console
SHLVL=1
SYSTEMDRIVE=C:
SYSTEMROOT=C:\Windows
TEMP=/tmp
TERM=cygwin
TMP=/tmp
UATDATA=C:\Windows\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77
USERDNSDOMAIN=PASA.PAS.LOCAL
USERDOMAIN=PASA
USERNAME=levind
USERPROFILE=C:\Users\levind
WINDIR=C:\Windows
_=/usr/bin/env
-------------- next part --------------
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\levind\AppData\Roaming
COMMANDER_DRIVE=C:
COMMANDER_EXE=C:\opt\total\TOTALCMD64.EXE
COMMANDER_INI=C:\opt\total\wincmd.ini
COMMANDER_PATH=C:\opt\total
COMMONPROGRAMFILES=C:\Program Files\Common Files
COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files
COMMONPROGRAMW6432=C:\Program Files\Common Files
COMPUTERNAME=LEVINDGTLT
COMSPEC=C:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\levind
LOCALAPPDATA=C:\Users\levind\AppData\Local
LOGONSERVER=\\PTCPASADC1
NUMBER_OF_PROCESSORS=4
OS=Windows_NT
PATH=C:\opt\perl\site\bin;C:\opt\perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared\;c:\bin;c;\opt\qgit;c:\opt\deltacopy;c:\opt\7z;c:\opt\cmake\win32\x86\bin;c:\opt\python33;C:\opt\perl\site\bin;C:\opt\perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3a09
PROGRAMDATA=C:\ProgramData
PROGRAMFILES=C:\Program Files
PROGRAMFILES(X86)=C:\Program Files (x86)
PROGRAMW6432=C:\Program Files
PROMPT=$P$G
PSI_ENABLE_VIDEO=1
PSMODULEPATH=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
QNXLM_LICENSE_FILE=@10.144.209.10
QNX_CONFIGURATION=c:\opt\qnx-software-systems
ROXIOCENTRAL=C:\Program Files (x86)\Common Files\Roxio Shared\10.0\Roxio Central36\
SESSIONNAME=Console
SYSTEMDRIVE=C:
SYSTEMROOT=C:\Windows
TEMP=C:\Users\levind\AppData\Local\Temp
TMP=C:\Users\levind\AppData\Local\Temp
UATDATA=C:\Windows\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77
USERDNSDOMAIN=PASA.PAS.LOCAL
USERDOMAIN=PASA
USERNAME=levind
USERPROFILE=C:\Users\levind
WINDIR=C:\Windows

From jamesbigler at gmail.com  Fri Jan 16 14:16:38 2015
From: jamesbigler at gmail.com (James Bigler)
Date: Fri, 16 Jan 2015 12:16:38 -0700
Subject: [cmake-developers] CUDA as a compiler instead FindCUDA?
In-Reply-To: <54B9164D.5080507@kitware.com>
References: <9F2CF081-470B-42E4-9DCE-CB67BA7D2DD0@java.pl>
 <54B9164D.5080507@kitware.com>
Message-ID: <CA+77nZD74b4GFePG2uDm2h8FjBM_8smdD4vAhS3sCXzz7QE5pA@mail.gmail.com>

On Fri, Jan 16, 2015 at 6:46 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/16/2015 06:54 AM, Adam Strzelecki wrote:
> > Hi. It makes me curious why CUDA support is not just implemented
> > as compiler via proper CMakeDetermineCUDACompiler
>
> I don't think there is any reason besides no one doing it yet.
>
>
Whenever someone brings this up I want to make sure these features get
considered.

1. Support for dependency scanning.  If I change a header included by
file.cu I want file.cu to be recompiled.  This is easy for makefiles, hard
for anything else.
2. In the past there have been bugs with nvcc, such as leaving a partially
written output file during generation that failed, that FindCUDA has worked
around.
3. Host flags generally need to be propagated to the CUDA flags (I'll admit
that this support in FindCUDA isn't perfect).
4. How do you support other targets besides cubin (obj), such as PTX?
5. How would separable compilation work?  Especially since you can't easily
replace the linker.
6. If you support PTX, can you use the output as input for other custom
commands (I like to encode the PTX into strings compiled into C++ files
using bin2c from CUDA).

> is CMake open to accept patch that will make CUDA support via
> > new compiler definition?
>
> Yes!  Does CUDA distinguish between C and C++?  Should there be
> separate "CUDAC" and "CUDACXX" languages?
>
>
No.  All CUDA code is C++ code as of 3-4 years ago.  I wouldn't attempt to
add support for really old versions of CUDA anyway.


> Does Visual Studio or Xcode have any builtin CUDA support, perhaps
> via a plugin?  This will affect how the corresponding generators
> need to handle the language.  Without native support then they
> will have to generate custom commands to build the languages.
>

There are CUDA plugins (build rules for VS+MSbuild).  These get updated for
every version of CUDA. I'm not sure how the different versions live side by
side, since I don't use them.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150116/f6d833f4/attachment.html>

From brad.king at kitware.com  Fri Jan 16 16:04:50 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 16 Jan 2015 16:04:50 -0500
Subject: [cmake-developers] [PATCH] Help: Correct two dead links to
	cmake.org
In-Reply-To: <CABmhRSX-BpjrDxh_c9JupTiifqGcTnSKbYWGXXBqEidJhs5bHQ@mail.gmail.com>
References: <CABmhRSX-BpjrDxh_c9JupTiifqGcTnSKbYWGXXBqEidJhs5bHQ@mail.gmail.com>
Message-ID: <54B97CF2.20602@kitware.com>

On 01/16/2015 12:39 PM, William Lynch wrote:
> These links are currently 404s. The attached patch fixes them to point
> to the correct destinations.

Thanks for pointing those out.  We've installed the needed redirects.

I've applied the patch with an updated commit message and extended it
to include a couple other links:

 Help: Update cmake.org links to avoid redirects
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=91fbcda2

Thanks,
-Brad


From brad.king at kitware.com  Fri Jan 16 16:38:42 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 16 Jan 2015 16:38:42 -0500
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
 prefixes
In-Reply-To: <54B91559.3030701@kitware.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
 <54B91559.3030701@kitware.com>
Message-ID: <54B984E2.4080208@kitware.com>

On 01/16/2015 08:42 AM, Brad King wrote:
> Go ahead and merge to 'next' for testing and follow up with any
> dashboard trouble.  I'll still be able to review it there.

AFAICT the change to GNUInstallDirs is just to help projects use
the new feature, and not actually part of the new feature itself.
The feature itself just happens to use the same set of <dir> values.
It feels a bit strange to have CPACK_ variables set by GNUInstallDirs,
and to require CPACK_PACKAGING_INSTALL_PREFIX to be set before that
module is included.

Perhaps instead CPackRPM can provide an option to compute a default
for CPACK_PACKAGING_INSTALL_FULL_<dir> based on the GNUInstallDirs
values.  This way GNUInstallDirs does not have to change at all,
and users can choose to include GNUInstallDirs and still set their
own CPACK_PACKAGING_INSTALL_FULL_<dir> values separately.

> +  set(TMP_RPM_PREFIXES ${TMP_RPM_PREFIXES} PARENT_SCOPE)

Typically I quote the second argument in this case.  It is not
strictly necessary but looks cleaner IMO.

Please look at adding test cases, perhaps in Tests/RunCMake,
to check the warning message about non-relocatable paths.

Thanks,
-Brad


From mantis at public.kitware.com  Fri Jan 16 16:52:56 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 16 Jan 2015 16:52:56 -0500
Subject: [cmake-developers] [CMake 0015357]: the src tarball is not ready
	for build like all other source releases
Message-ID: <6eb678c4fb768c48b5e8c152eb8eee7d@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15357 
====================================================================== 
Reported By:                Dave Yost
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15357
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-16 16:52 EST
Last Modified:              2015-01-16 16:52 EST
====================================================================== 
Summary:                    the src tarball is not ready for build like all
other source releases
Description: 
I have software that will automatically download, extract, build, and install
from source.

The cmake 3.0.0-1 release doesn't follow the standard pattern. When the software
goes to extract from the bz2 file, instead of a simple source directory, it gets
three folders.

245 Z% tar tzf build/cmake-3.1.0-1-src.tar.bz2 
cmake-3.1.0-1.sh
cmake-3.1.0-1.patch
cmake-3.1.0.tar.bz2
246 Z% 

I and this software think this is a bad idea. Please package all releases in the
normal way, not like this with a patch and a shell script.

Steps to Reproduce: 
tar xzf build/cmake-3.1.0-1-src.tar.bz2
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-16 16:52 Dave Yost      New Issue                                    
======================================================================


From domen.vrankar at gmail.com  Fri Jan 16 17:06:46 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 16 Jan 2015 23:06:46 +0100
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
	prefixes
In-Reply-To: <54B984E2.4080208@kitware.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
 <54B91559.3030701@kitware.com> <54B984E2.4080208@kitware.com>
Message-ID: <CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>

Resending as I accidentally dropped the developers mailing list...

2015-01-16 22:38 GMT+01:00 Brad King <brad.king at kitware.com>:
> On 01/16/2015 08:42 AM, Brad King wrote:
>> Go ahead and merge to 'next' for testing and follow up with any
>> dashboard trouble.  I'll still be able to review it there.
>
> AFAICT the change to GNUInstallDirs is just to help projects use
> the new feature, and not actually part of the new feature itself.
> The feature itself just happens to use the same set of <dir> values.

Yes I added variables to GNUInstallDirs as a convenience method. Users
can still choose to set values without the use of GNUInstallDirs
module.

> It feels a bit strange to have CPACK_ variables set by GNUInstallDirs,
> and to require CPACK_PACKAGING_INSTALL_PREFIX to be set before that
> module is included.
>
> Perhaps instead CPackRPM can provide an option to compute a default
> for CPACK_PACKAGING_INSTALL_FULL_<dir> based on the GNUInstallDirs
> values.  This way GNUInstallDirs does not have to change at all,
> and users can choose to include GNUInstallDirs and still set their
> own CPACK_PACKAGING_INSTALL_FULL_<dir> values separately.

I tried to do that first but the problem is that only CPACK_*
variables are propagated to CPackRPM script and I thought that
redefining the variables with new names in GNUInstallDirs is better
than creating a new module just for that.

I could write a new module for converting CMAKE_INSTALL* variables to
CPACK_PACKAGING_INSTALL* variables and then generate
CPACK_PACKAGING_INSTALL_FULL_<
dir> inside CPackRPM.

Alternative that comes to mind is that I just remove the convenience
method of setting variables through GNUInstallDirs.

I'm opened to suggestions.

>> +  set(TMP_RPM_PREFIXES ${TMP_RPM_PREFIXES} PARENT_SCOPE)
>
> Typically I quote the second argument in this case.  It is not
> strictly necessary but looks cleaner IMO.

I agree.

> Please look at adding test cases, perhaps in Tests/RunCMake,
> to check the warning message about non-relocatable paths.

Haven't tried to write negative tests or parsing of command line
during test execution. Are there any good examples of such tests?

> Thanks,
> -Brad
>

From domen.vrankar at gmail.com  Fri Jan 16 17:16:26 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Fri, 16 Jan 2015 23:16:26 +0100
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
	prefixes
In-Reply-To: <CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
 <54B91559.3030701@kitware.com> <54B984E2.4080208@kitware.com>
 <CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>
Message-ID: <CAKgx6BKatt-Cgt8aweuxHbpDMmPS8bV3O4jiaT=250pmObrkiQ@mail.gmail.com>

One other idea came to mind... Allow arbitrary paths for different
prefixes and a script to generate prefixes from paths in
GNUInstallDirs. That would be a more general solution.

I could also remove the use of GNUInstallDirs paths all together but I
like the idea of having packaging relocation paths set automatically
by defining install paths since that guarantees the consistency of the
structure installed by cmake and from rpm...

2015-01-16 23:06 GMT+01:00 Domen Vrankar <domen.vrankar at gmail.com>:
> Resending as I accidentally dropped the developers mailing list...
>
> 2015-01-16 22:38 GMT+01:00 Brad King <brad.king at kitware.com>:
>> On 01/16/2015 08:42 AM, Brad King wrote:
>>> Go ahead and merge to 'next' for testing and follow up with any
>>> dashboard trouble.  I'll still be able to review it there.
>>
>> AFAICT the change to GNUInstallDirs is just to help projects use
>> the new feature, and not actually part of the new feature itself.
>> The feature itself just happens to use the same set of <dir> values.
>
> Yes I added variables to GNUInstallDirs as a convenience method. Users
> can still choose to set values without the use of GNUInstallDirs
> module.
>
>> It feels a bit strange to have CPACK_ variables set by GNUInstallDirs,
>> and to require CPACK_PACKAGING_INSTALL_PREFIX to be set before that
>> module is included.
>>
>> Perhaps instead CPackRPM can provide an option to compute a default
>> for CPACK_PACKAGING_INSTALL_FULL_<dir> based on the GNUInstallDirs
>> values.  This way GNUInstallDirs does not have to change at all,
>> and users can choose to include GNUInstallDirs and still set their
>> own CPACK_PACKAGING_INSTALL_FULL_<dir> values separately.
>
> I tried to do that first but the problem is that only CPACK_*
> variables are propagated to CPackRPM script and I thought that
> redefining the variables with new names in GNUInstallDirs is better
> than creating a new module just for that.
>
> I could write a new module for converting CMAKE_INSTALL* variables to
> CPACK_PACKAGING_INSTALL* variables and then generate
> CPACK_PACKAGING_INSTALL_FULL_<
> dir> inside CPackRPM.
>
> Alternative that comes to mind is that I just remove the convenience
> method of setting variables through GNUInstallDirs.
>
> I'm opened to suggestions.
>
>>> +  set(TMP_RPM_PREFIXES ${TMP_RPM_PREFIXES} PARENT_SCOPE)
>>
>> Typically I quote the second argument in this case.  It is not
>> strictly necessary but looks cleaner IMO.
>
> I agree.
>
>> Please look at adding test cases, perhaps in Tests/RunCMake,
>> to check the warning message about non-relocatable paths.
>
> Haven't tried to write negative tests or parsing of command line
> during test execution. Are there any good examples of such tests?
>
>> Thanks,
>> -Brad
>>

From domen.vrankar at gmail.com  Sat Jan 17 01:19:33 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Sat, 17 Jan 2015 07:19:33 +0100
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
	prefixes
In-Reply-To: <CAKgx6BKatt-Cgt8aweuxHbpDMmPS8bV3O4jiaT=250pmObrkiQ@mail.gmail.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
 <54B91559.3030701@kitware.com> <54B984E2.4080208@kitware.com>
 <CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>
 <CAKgx6BKatt-Cgt8aweuxHbpDMmPS8bV3O4jiaT=250pmObrkiQ@mail.gmail.com>
Message-ID: <CAKgx6B+cmNHSi1OfzUAdrG2MeB-LCDQ0yJajOX24u6HQkx-JUQ@mail.gmail.com>

2015-01-16 23:16 GMT+01:00 Domen Vrankar <domen.vrankar at gmail.com>:
> One other idea came to mind... Allow arbitrary paths for different
> prefixes and a script to generate prefixes from paths in
> GNUInstallDirs. That would be a more general solution.
>
> I could also remove the use of GNUInstallDirs paths all together but I
> like the idea of having packaging relocation paths set automatically
> by defining install paths since that guarantees the consistency of the
> structure installed by cmake and from rpm...

I've decided to go with the generic solution and without dependency on
GNUInstallDirs altogether.

Thanks for the review Brad.

Regards,
Domen

From ono at java.pl  Sat Jan 17 10:13:28 2015
From: ono at java.pl (Adam Strzelecki)
Date: Sat, 17 Jan 2015 16:13:28 +0100
Subject: [cmake-developers] CUDA as a compiler instead FindCUDA?
In-Reply-To: <CA+77nZD74b4GFePG2uDm2h8FjBM_8smdD4vAhS3sCXzz7QE5pA@mail.gmail.com>
References: <9F2CF081-470B-42E4-9DCE-CB67BA7D2DD0@java.pl>
 <54B9164D.5080507@kitware.com>
 <CA+77nZD74b4GFePG2uDm2h8FjBM_8smdD4vAhS3sCXzz7QE5pA@mail.gmail.com>
Message-ID: <A0455417-004F-4FA4-85A0-131070D4C366@java.pl>

> 1. Support for dependency scanning.  If I change a header included by file.cu I want file.cu to be recompiled.  This is easy for makefiles, hard for anything else.

.cu is superset of C++ so it should be pretty easy to get dependency scanning working same as for regular .cpp/.h files using CMake facilities.

> 2. In the past there have been bugs with nvcc, such as leaving a partially written output file during generation that failed, that FindCUDA has worked around.

I don't see why we should care about that? If they still exist isn't it what NVIDIA partner bug report site is for?

> 3. Host flags generally need to be propagated to the CUDA flags (I'll admit that this support in FindCUDA isn't perfect).

You mean user-defined preprocessor definitions or compiler flags? Host compiler flags are picked up by nvcc from host compiler itself. Aside of that, CMake will insert -D definitions as well to any extra compiler.

So you may only want to wrap CMAKE_CXX_FLAGS into CMAKE_CUDACXX_FLAGS using -Xcompiler which can be tricky, but I believe we can workaround that somehow.

> 4. How do you support other targets besides cubin (obj), such as PTX?

For what purpose? Debugging?

> 5. How would separable compilation work?  Especially since you can't easily replace the linker.

Correct me if I am wrong, but we will still use platform linker.

> 6. If you support PTX, can you use the output as input for other custom commands (I like to encode the PTX into strings compiled into C++ files using bin2c from CUDA).

Again can you please elaborate more why would you like to handle PTX yourself if CUDA does it for you, i.e.:

nvcc -arch sm_30 -> makes .o contain native device code
nvcc -arch compute_30 -> makes .o contain ptx code compiled later by the driver itself

This sounds like some custom behavior.

--Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150117/a5653c14/attachment.html>

From mail at petervasil.net  Sat Jan 17 19:27:28 2015
From: mail at petervasil.net (ptrv)
Date: Sun, 18 Jan 2015 01:27:28 +0100
Subject: [cmake-developers] [PATCH] cmake-mode.el: Fix extracting keyword at
	point in cmake-help
Message-ID: <1421540848-21238-1-git-send-email-mail@petervasil.net>

With commit 30f14aebeee90bc1af6236888599db86b2bd8fae 'word-at-point'
function does not extract the whole keyword anymore if it contains an
'_', because 'forward-word' stops at '_'. Use 'symbol-at-point' to
extract whole keyword even if there is an '_'.
---
 Auxiliary/cmake-mode.el | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Auxiliary/cmake-mode.el b/Auxiliary/cmake-mode.el
index f1470f3..37ca942 100644
--- a/Auxiliary/cmake-mode.el
+++ b/Auxiliary/cmake-mode.el
@@ -320,9 +320,13 @@ and store the result as a list in LISTVAR."
       ))
   )
 
-(require 'thingatpt)
+(defun cmake-symbol-at-point ()
+  (let ((symbol (symbol-at-point)))
+    (and (not (null symbol))
+         (symbol-name symbol))))
+
 (defun cmake-help-type (type)
-  (let* ((default-entry (word-at-point))
+  (let* ((default-entry (cmake-symbol-at-point))
          (history (car (cdr (cdr (assoc type cmake-string-to-list-symbol)))))
          (input (completing-read
                  (format "CMake %s: " type) ; prompt
@@ -365,7 +369,7 @@ and store the result as a list in LISTVAR."
 (defun cmake-help ()
   "Queries for any of the four available help topics and prints out the approriate page."
   (interactive)
-  (let* ((default-entry (word-at-point))
+  (let* ((default-entry (cmake-symbol-at-point))
          (command-list (cmake-get-list "command"))
          (variable-list (cmake-get-list "variable"))
          (module-list (cmake-get-list "module"))
-- 
2.2.2


From mantis at public.kitware.com  Sun Jan 18 14:09:20 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 18 Jan 2015 14:09:20 -0500
Subject: [cmake-developers] [CMake 0015358]: try_compile ignores
	INCLUDE_DIRECTORIES argument
Message-ID: <49c67fa3fb6726b8c6e60448a9a3387d@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15358 
====================================================================== 
Reported By:                Alexey Chernov
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15358
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-18 14:09 EST
Last Modified:              2015-01-18 14:09 EST
====================================================================== 
Summary:                    try_compile ignores INCLUDE_DIRECTORIES argument
Description: 
try_compile command apparently ignores INCLUDE_DIRECTORIES argument for unknown
reason. As documentation
(http://www.cmake.org/cmake/help/v3.1/command/try_compile.html) reads:
"Some extra flags that can be included are, INCLUDE_DIRECTORIES,
LINK_DIRECTORIES, and LINK_LIBRARIES. COMPILE_DEFINITIONS are -Ddefinition that
will be passed to the compile line." But unfortunately parameter of
INCLUDE_DIRECTORIES argument won't be transferred to CMakeLists.txt.

It also be true for other arguments mentioned in that paragraph.

Steps to Reproduce: 
1. Write try_compile() command with INCLUDE_DIRECTORIES, e.g.:
try_compile(
	COMPILE_RESULT
	${CMAKE_BINARY_DIR}
	test.cpp
	INCLUDE_DIRECTORIES ${CMAKE_SOURCE_DIR}/include
	OUTPUT_VARIABLE COMPILE_LOG
)
2. Notice that INCLUDE_DIRECTORIES parameter isn't transferred neither to
temporary CMakeLists.txt in CMakeFiles/CMakeTmp (with --debug-trycompile
enabled) nor to compiler command line arguments.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-18 14:09 Alexey Chernov New Issue                                    
======================================================================


From domen.vrankar at gmail.com  Mon Jan 19 03:24:33 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 19 Jan 2015 09:24:33 +0100
Subject: [cmake-developers] CPack RPM failing tests on dashboard
Message-ID: <CAKgx6BLhkDFw0=JBTu1=ZVVi8m6Mn3X35T14QAu+GhPu64cEFA@mail.gmail.com>

I've noticed CPack/RPM test fails on dashboard for two
Fedora-19-x86_64 machines:

https://open.cdash.org/buildSummary.php?buildid=3658687
https://open.cdash.org/buildSummary.php?buildid=3658677

Would it be possible to get generated rpm files from one of them for analysis?

/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-Unspecified.rpm
/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-applications.rpm
/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm
/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-libraries.rpm

Thanks,
Domen

From eric.noulard at gmail.com  Mon Jan 19 03:59:17 2015
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 19 Jan 2015 09:59:17 +0100
Subject: [cmake-developers] CPack RPM failing tests on dashboard
In-Reply-To: <CAKgx6BLhkDFw0=JBTu1=ZVVi8m6Mn3X35T14QAu+GhPu64cEFA@mail.gmail.com>
References: <CAKgx6BLhkDFw0=JBTu1=ZVVi8m6Mn3X35T14QAu+GhPu64cEFA@mail.gmail.com>
Message-ID: <CAPASGLrjL-98Ap0AxRLM7TB7wmz=ecuby2nv-h-U6LD2q55rRA@mail.gmail.com>

2015-01-19 9:24 GMT+01:00 Domen Vrankar <domen.vrankar at gmail.com>:

> I've noticed CPack/RPM test fails on dashboard for two
> Fedora-19-x86_64 machines:
>
> https://open.cdash.org/buildSummary.php?buildid=3658687
> https://open.cdash.org/buildSummary.php?buildid=3658677
>
> Would it be possible to get generated rpm files from one of them for
> analysis?
>
>
> /home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-Unspecified.rpm
>
> /home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-applications.rpm
>
> /home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm
>
> /home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-libraries.rpm
>

From:
https://open.cdash.org/testDetails.php?test=307325450&build=3658677
you get that:

-- actual_count='4'
CMake Error at /home/kevin/kitware/CMake/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake:193
(message):
  error:
  '/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-libraries.rpm'
  rpm package relocation path does not match expected value - regex
  'Relocations : /usr /usr/lib'


May be you can make  "RunCPackVerifyResult.cmake" more verbose when a
failure occurs?
(i.e. a bunch of extra rpm query on the culprit generated RPM) and/or more
informations
in the error message.

In particular, you have the "expected" value but onot the "actual" content,
may be you miss the "check_file_content" display in error cases?

That way you'll automatically get more informations on every failure.

Getting your hand on the RPM itself would help but in my experience it
tends to slow down the test loop.

-- 
Eric
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150119/43561fb8/attachment.html>

From domen.vrankar at gmail.com  Mon Jan 19 04:06:55 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 19 Jan 2015 10:06:55 +0100
Subject: [cmake-developers] CPack RPM failing tests on dashboard
In-Reply-To: <CAPASGLrjL-98Ap0AxRLM7TB7wmz=ecuby2nv-h-U6LD2q55rRA@mail.gmail.com>
References: <CAKgx6BLhkDFw0=JBTu1=ZVVi8m6Mn3X35T14QAu+GhPu64cEFA@mail.gmail.com>
 <CAPASGLrjL-98Ap0AxRLM7TB7wmz=ecuby2nv-h-U6LD2q55rRA@mail.gmail.com>
Message-ID: <CAKgx6BJOjuh=VGg1r6PS9NFPD0Y_4g=MpPM2G3PcmkBTcS_L9w@mail.gmail.com>

> May be you can make  "RunCPackVerifyResult.cmake" more verbose when a
> failure occurs?
> (i.e. a bunch of extra rpm query on the culprit generated RPM) and/or more
> informations
> in the error message.

You're right. Haven't thought about such cases when I don't have the
output RPM files. I'll extend the logging.

Thanks,
Domen

From brad.king at kitware.com  Mon Jan 19 09:31:31 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Jan 2015 09:31:31 -0500
Subject: [cmake-developers] [PATCH] cmake-mode.el: Fix extracting
 keyword at point in cmake-help
In-Reply-To: <1421540848-21238-1-git-send-email-mail@petervasil.net>
References: <1421540848-21238-1-git-send-email-mail@petervasil.net>
Message-ID: <54BD1543.9000701@kitware.com>

On 01/17/2015 07:27 PM, ptrv wrote:
> With commit 30f14aebeee90bc1af6236888599db86b2bd8fae 'word-at-point'
> function does not extract the whole keyword anymore if it contains an
> '_', because 'forward-word' stops at '_'. Use 'symbol-at-point' to
> extract whole keyword even if there is an '_'.

Thanks, applied:

 cmake-mode.el: Fix extracting keyword at point in cmake-help
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca80598e

I've queued this regression fix for 3.1.1.

-Brad


From brad.king at kitware.com  Mon Jan 19 09:31:52 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Jan 2015 09:31:52 -0500
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
 prefixes
In-Reply-To: <CAKgx6B+cmNHSi1OfzUAdrG2MeB-LCDQ0yJajOX24u6HQkx-JUQ@mail.gmail.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>	<CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>	<54B91559.3030701@kitware.com>	<54B984E2.4080208@kitware.com>	<CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>	<CAKgx6BKatt-Cgt8aweuxHbpDMmPS8bV3O4jiaT=250pmObrkiQ@mail.gmail.com>
 <CAKgx6B+cmNHSi1OfzUAdrG2MeB-LCDQ0yJajOX24u6HQkx-JUQ@mail.gmail.com>
Message-ID: <54BD1558.1030809@kitware.com>

On 01/17/2015 01:19 AM, Domen Vrankar wrote:
> I've decided to go with the generic solution and without dependency on
> GNUInstallDirs altogether.

Okay.  I reverted the 'rpm_multi_prefix' topic from 'next' for now.
Please resubmit when ready.

On 01/16/2015 05:06 PM, Domen Vrankar wrote:
>> Please look at adding test cases, perhaps in Tests/RunCMake,
>> to check the warning message about non-relocatable paths.
> Haven't tried to write negative tests or parsing of command line
> during test execution. Are there any good examples of such tests?

Most of the RunCMake tests are for negative tests, but mostly for
running "cmake".  IIUC you need tests that run "cpack", right?
For that you can use run_cmake_command.  See use in the
RunCMake.CTestMemcheck test to run "ctest":

 Tests/RunCMake/CTestMemcheck/RunCMakeTest.cmake

See also Tests/RunCMake/CommandLine/RunCMakeTest.cmake for other
uses to try the non-generator signatures of "cmake".

Thanks,
-Brad


From mail at petervasil.net  Mon Jan 19 13:49:07 2015
From: mail at petervasil.net (Peter Vasil)
Date: Mon, 19 Jan 2015 19:49:07 +0100
Subject: [cmake-developers] [PATCH] cmake-mode.el: Re-add explicit call to
	require thingatpt
In-Reply-To: <1421540848-21238-1-git-send-email-mail@petervasil.net>
References: <1421540848-21238-1-git-send-email-mail@petervasil.net>
Message-ID: <1421693347-8104-1-git-send-email-mail@petervasil.net>

Usually it is not needed to call '(require 'thingatpt')' explicitly
because the function 'symbol-at-point' is in autoloaded but to be sure
to have the function loaded in every case, require thingatpt.
---
 Auxiliary/cmake-mode.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Auxiliary/cmake-mode.el b/Auxiliary/cmake-mode.el
index 37ca942..7458a66 100644
--- a/Auxiliary/cmake-mode.el
+++ b/Auxiliary/cmake-mode.el
@@ -320,6 +320,7 @@ and store the result as a list in LISTVAR."
       ))
   )
 
+(require 'thingatpt)
 (defun cmake-symbol-at-point ()
   (let ((symbol (symbol-at-point)))
     (and (not (null symbol))
-- 
2.2.2


From brad.king at kitware.com  Mon Jan 19 13:55:04 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Jan 2015 13:55:04 -0500
Subject: [cmake-developers] [PATCH] cmake-mode.el: Re-add explicit call
 to require thingatpt
In-Reply-To: <1421693347-8104-1-git-send-email-mail@petervasil.net>
References: <1421540848-21238-1-git-send-email-mail@petervasil.net>
 <1421693347-8104-1-git-send-email-mail@petervasil.net>
Message-ID: <54BD5308.1040503@kitware.com>

On 01/19/2015 01:49 PM, Peter Vasil wrote:
> Usually it is not needed to call '(require 'thingatpt')' explicitly
> because the function 'symbol-at-point' is in autoloaded but to be sure
> to have the function loaded in every case, require thingatpt.

Okay, thanks:

 cmake-mode.el: Re-add explicit call to require thingatpt
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a147e1b

-Brad


From brad.king at kitware.com  Mon Jan 19 14:26:20 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Jan 2015 14:26:20 -0500
Subject: [cmake-developers] [PATCH] Setting default user,
 group and permissions for CPackRPM
In-Reply-To: <CAKgx6B+xteU6V3-SZR4xYqo9E1Og70+6oB6rVLE6+LwrkRxUMw@mail.gmail.com>
References: <CAKgx6B+vbrDBcV3HpBRca=JeiOU2_01ka28otWxNyFL3d1QEZA@mail.gmail.com>	<54B81CB6.2070901@kitware.com>
 <CAKgx6B+xteU6V3-SZR4xYqo9E1Og70+6oB6rVLE6+LwrkRxUMw@mail.gmail.com>
Message-ID: <54BD5A5C.9070808@kitware.com>

On 01/16/2015 03:10 AM, Domen Vrankar wrote:
> That is why uid and gid in install command
> don't help much - if CPack/RPM would use uid and gid from install
> command it would be limited to users and groups listed in systems
> /etc/passwd file.
> 
> I could write an initial patch for bug report 3602 that would add user
> and group setting to install command and add that functionality to
> CPack/RPM and later we could extend the use for install and other
> CPack generators to use it as well (I also wrote some ideas for a
> patch here http://www.cmake.org/pipermail/cmake/2015-January/059518.html).

If you're interested in working on 3602 then please do so.  However it
sounds from the above that for CPack we need declarative information
for CPack to put in the package for package-install-time updates.

Please look at the "INSTALL" scope of set_property:

 http://www.cmake.org/cmake/help/v3.1/command/set_property.html

It is meant specifically for setting information about files for use
by CPack.  One could add properties for user and group names.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jan 19 14:50:06 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Jan 2015 14:50:06 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>	<54B7C42A.8010103@kitware.com>	<CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>	<54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
Message-ID: <54BD5FEE.4040605@kitware.com>

On 01/16/2015 01:13 PM, Daniel Levin wrote:
> The CMake and Ninja were part of the bigger build script,
> which was running under the QNX SDK sh.exe.
> When running under this shell it overrides some environment
> variables (compare attached files).

The main differences I see are:

* The Windows shell is a 64-bit cmd and the MSYS one is 32-bit
* PATH has been converted to MSYS-style and prepended with /usr/bin
* Added: QNX_HOST=c:\opt\qnx650-gcc-4.8.1\host\win32\x86
* Added: QNX_TARGET=c:\opt\qnx650-gcc-4.8.1\target\qnx6
* Added: TERM=cygwin, consistent with MSYS shells
* Added: SHLVL=1
* The "TEMP" and "TMP" variables are /tmp instead of the Windows dirs

So this is a MSYS shell.  AFAIK ninja under MSYS sh.exe normally
works even for pure Windows builds.  Perhaps their shell does more.

> But as far as I remember it also does some nasty launcher overrides,
> intercepting calls to cmd, bat and sh and tries to process them
> somehow else.

Do you mean some kind of dll injection to intercept CreateProcess calls?

I'd really like to have a deep understanding of the situation before
adding a lot of escaping code for a specialized environment.  It
may be that ninja simply needs to learn how to isolate itself in
this case.

Thanks,
-Brad

From mantis at public.kitware.com  Mon Jan 19 16:39:58 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 19 Jan 2015 16:39:58 -0500
Subject: [cmake-developers] [CMake 0015359]: __attribute__((weak))
	support/detection (weak symbols)
Message-ID: <8e77e92a44a8274c975bdbc4360a0a12@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15359 
====================================================================== 
Reported By:                Laurent Demailly
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15359
Category:                   CMake
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-19 16:39 EST
Last Modified:              2015-01-19 16:39 EST
====================================================================== 
Summary:                    __attribute__((weak)) support/detection (weak
symbols)
Description: 
it would be great if some built in recipe would set some variable depending on
whether the
compiler/linker support  __attribute__((weak))


this is done in autoconf the following way for instance:

AC_CACHE_CHECK(
  [for weak symbol support],
  [folly_cv_prog_cc_weak_symbols],
  [AC_LINK_IFELSE(
    [AC_LANG_SOURCE[
      extern "C" void configure_link_extern_weak_test()
__attribute__((weak));
      int main(int argc, char** argv) {
          return configure_link_extern_weak_test == nullptr;
      }]],
    [folly_cv_prog_cc_weak_symbols="yes"],
    [folly_cv_prog_cc_weak_symbols="no"])])

if test "$folly_cv_prog_cc_weak_symbols" = yes; then
  AC_DEFINE([HAVE_WEAK_SYMBOLS], [1],
            [Define to 1 if the linker supports weak symbols.])
fi


ps: sent similar request (more of a question on how to do it pending built in
support by cmake base) to the cmake at cmake.org mailing list - hope it's ok to
have some amount of duplicate

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-19 16:39 Laurent DemaillyNew Issue                                    
======================================================================


From mantis at public.kitware.com  Mon Jan 19 16:53:03 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 19 Jan 2015 16:53:03 -0500
Subject: [cmake-developers] [CMake 0015360]: XCode generated project yield
	"Project 'X' overrides the Architectures setting" warning
Message-ID: <6a5729b60c58270a8bddf073f2d68b6d@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15360 
====================================================================== 
Reported By:                Laurent Demailly
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15360
Category:                   CMake
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-19 16:53 EST
Last Modified:              2015-01-19 16:53 EST
====================================================================== 
Summary:                    XCode generated project yield "Project 'X' overrides
the Architectures setting" warning
Description: 
XCode generated project yield "Project 'X' overrides the Architectures setting"
warning
That Xcode offers to fix by saying
"This will remove the setting and allow Xcode to automatically select
Architectures based on the hardware available for the active platform and
deployment target."


Steps to Reproduce: 
ldemailly-mbp:cmake_test ldemailly$ cat CMakeLists.txt
# CMake build file

cmake_minimum_required(VERSION 3.1)

project("CmakeTest" C CXX)

# On MacOS this requires the latest (master) CMake (and/or CMake 3.2)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED on)

add_executable(test1 test1.cpp)

ldemailly-mbp:cmake_test ldemailly$ cat test1.cpp
int main() {return 0;}

ldemailly-mbp:cmake_test_xcode ldemailly$ cmake31 ../cmake_test -G Xcode
-- The C compiler identification is AppleClang 6.0.0.6000056
-- The CXX compiler identification is AppleClang 6.0.0.6000056
-- Check for working C compiler using: Xcode
-- Check for working C compiler using: Xcode -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Xcode
-- Check for working CXX compiler using: Xcode -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/ldemailly/cmake_test_xcode
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-19 16:53 Laurent DemaillyNew Issue                                    
2015-01-19 16:53 Laurent DemaillyFile Added: Screenshot 2015-01-19 13.51.37.png 
                  
======================================================================


From mantis at public.kitware.com  Mon Jan 19 18:28:34 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 19 Jan 2015 15:28:34 -0800
Subject: [cmake-developers] [CMake 0015361]: CHECK_CXX_SOURCE_COMPILES
	doesn't use c++11 flags specified
Message-ID: <8e2a4aa220eb56217525c4ce57361d5c@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15361 
====================================================================== 
Reported By:                Laurent Demailly
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15361
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-19 15:28 PST
Last Modified:              2015-01-19 15:28 PST
====================================================================== 
Summary:                    CHECK_CXX_SOURCE_COMPILES doesn't use c++11 flags
specified
Description: 
I have 

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED on)

in my cmake file - yet later when I try:

check_cxx_source_compiles(
"extern \"C\" void cmkcheckweak() __attribute__((weak));
int main(int argc, char** argv) {
  return cmkcheckweak == nullptr; // works with (void*)0;
}" HAVE_WEAK_SYMBOLS)

it fails incorrectly because it invokes the compiler without the  -std=gnu++11
it adds for regular files

(the goal/point of CMAKE_CXX_STANDARD_REQUIRED is to use that compiler for
everything and not me having to write code to guess the way to request c++11
compiler)

this is related to http://public.kitware.com/Bug/view.php?id=15359
but while here there is an easy work around (not use nullptr and use 0 instead)
that won't work for other tests I'm trying to do with CHECK_CXX_SOURCE_COMPILES

suggestions/workarounds on how to make CHECK_CXX_SOURCE_COMPILES use the same
compiler invocation as my other targets would be most welcome in the meantime


Steps to Reproduce: 
see above and below


Additional Information: 
Performing C++ SOURCE FILE Test HAVE_WEAK_SYMBOLS failed with the following
output:
Change Dir: /home/ldemailly/mac/wdt_ubuntu_build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTryCompileExec1489303762/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec1489303762.dir/build.make
CMakeFiles/cmTryCompileExec1489303762.dir/build
make[1]: Entering directory
`/mnt/hgfs/ldemailly/wdt_ubuntu_build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report
/home/ldemailly/mac/wdt_ubuntu_build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec1489303762.dir/src.cxx.o
/usr/bin/c++    -DHAVE_WEAK_SYMBOLS   -o
CMakeFiles/cmTryCompileExec1489303762.dir/src.cxx.o -c
/home/ldemailly/mac/wdt_ubuntu_build/CMakeFiles/CMakeTmp/src.cxx
/home/ldemailly/mac/wdt_ubuntu_build/CMakeFiles/CMakeTmp/src.cxx: In function
?int main(int, char**)?:
/home/ldemailly/mac/wdt_ubuntu_build/CMakeFiles/CMakeTmp/src.cxx:3:26: error:
?nullptr? was not declared in this scope
   return cmkcheckweak == nullptr; // (void*)0; works
                          ^
make[1]: Leaving directory
`/mnt/hgfs/ldemailly/wdt_ubuntu_build/CMakeFiles/CMakeTmp'
make[1]: *** [CMakeFiles/cmTryCompileExec1489303762.dir/src.cxx.o] Error 1
make: *** [cmTryCompileExec1489303762/fast] Error 2

Source file was:
extern "C" void cmkcheckweak() __attribute__((weak));
int main(int argc, char** argv) {
  return cmkcheckweak == nullptr; // (void*)0; works
}

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-19 15:28 Laurent DemaillyNew Issue                                    
======================================================================


From mantis at public.kitware.com  Mon Jan 19 19:44:35 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 19 Jan 2015 19:44:35 -0500
Subject: [cmake-developers] [CMake 0015362]: Target property
	INTERFACE_SYSTEM_INCLUDE_DIRECTORIES doesn't seem to work
Message-ID: <e7e8c636c30b7af271489ccd96663ed0@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15362 
====================================================================== 
Reported By:                Clinton Stimpson
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15362
Category:                   CMake
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-19 19:44 EST
Last Modified:              2015-01-19 19:44 EST
====================================================================== 
Summary:                    Target property INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
doesn't seem to work
Description: 
I had some code doing
set_property(TARGET A APPEND PROPERTY
    INTERFACE_INCLUDE_DIRECTORIES
"$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>")

And I replaced INTERFACE_INCLUDE_DIRECTORIES with
INTERFACE_SYSTEM_INCLUDE_DIRECTORIES, and it no longer worked.

I understand the different to be equivalent to 
include_directories(...)
vs.
include_directories(SYSTEM ...)




Steps to Reproduce: 
See attached project for an example which doesn't work.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-19 19:44 Clinton StimpsonNew Issue                                    
2015-01-19 19:44 Clinton StimpsonFile Added: test-usage-includes.tar.gz         
          
======================================================================


From brad.king at kitware.com  Tue Jan 20 09:47:09 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 20 Jan 2015 09:47:09 -0500
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <CACcA1RoqwY_z2edqSiWaxbx3JD9+ZTMrthYJ_eOMLZ68Z+KhYA@mail.gmail.com>
References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com>
 <CACcA1RobpX-JENv7pJo=gAqTXB_W7-qF3OrFd6e8XS4eUCERBg@mail.gmail.com>
 <542D4879.20204@kitware.com> <6761034.LHuUtODnIM@eto>
 <CACcA1RpF9V7NnpgmShr=6cKJHcMz3kZ0XxUFwtPtgYJkkS+Fzg@mail.gmail.com>
 <CACcA1RoqwY_z2edqSiWaxbx3JD9+ZTMrthYJ_eOMLZ68Z+KhYA@mail.gmail.com>
Message-ID: <54BE6A6D.4070007@kitware.com>

On 12/18/2014 09:02 PM, Aleix Pol wrote:
> I would like to propose this as a final version of this patch.
> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch

For reference, this was also attached in a later message of this
thread on 2015-01-09:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061

> I have a working proof of concept in KDevelop already I'm quite happy with.

Can you post a link to that implementation so others may try it?

Steve K. posted a review of your patch on 2014-12-19:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972

that has not yet received a response.

Also, for unrelated reasons we've now added JsonCpp into the CMake
build process.  You could consider using that to write the .json
file so that no manual formatting or escaping code is needed.
The current patch does not add potentially needed json escapes.

Thanks,
-Brad

From dendy.ua at gmail.com  Tue Jan 20 10:42:47 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Tue, 20 Jan 2015 10:42:47 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <54BD5FEE.4040605@kitware.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
 <54BD5FEE.4040605@kitware.com>
Message-ID: <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>

Brad, below is the list of variables set manually by me before testing QNX
SDK environment variables, the qcc will fail if any of them are missing:

set QNX_CONFIGURATION=d:\opt\qnx-software-systems
set QNXLM_LICENSE_FILE=@10.144.209.10
set QNX_HOST=d:\opt\qnx650sp1\host\win32\x86
set QNX_TARGET=d:\projects\pasa\ford\r6\QNX_SDK\target\qnx6
set PATH=d:\opt\qnx650sp1\host\win32\x86\usr\bin;%PATH%

> Do you mean some kind of dll injection to intercept CreateProcess calls?

I doubt, but that does not mean it does not. I remember errors from Ninja
when it was trying to execute "%1" in CreateProcess call, but suspect that
was a problem in escape characters in .ninja file.

I did short research again and would want to explain from scratch.

1. My story takes start from the existing QNX project based on Makefiles
and my effort was to inject CMake into that build tree. QNX SDK always uses
Unix environment which means:
- Makefiles always use Unix syntax
- environment guarantees that you can use shell scripts in your Makefiles
as commands

2. When you want to reuse existing .sh scripts in your CMake target rules
it apparently fails because Ninja does not know how to execute them. QNX
SDK make tool does.

3. The most problematic issue for me was that qcc and gcc tools from QNX
SDK cannot run without QNX_HOST and QNX_TARGET variables set. Also qcc will
fail if QNX_CONFIGURATION and QNXLM_LICENSE_FILE are missing or license
server is not available (but that is another story). CMake build works in
two stages: generation and native build. Setting listed env variables at
generation stage is absolutely valid. But setting them again later at build
stage leads to issues:
- you need to explicitly load environment variables each time before build
- if you have multiple QNX SDKs you might accidentally load wrong variable
set
- if you use IDE launched from clean shell with default variables you
cannot source env variables saved in some script anymore
- if you use IDE you probably need to explicitly replicate env variables in
some IDE specific way

CMake has solution to overcome problems like this: cache. But apparently
cache does not work when you need to save environment variables which need
to be loaded _before_ build starts.

So the only way to fix that was to wrap compiler into script, that does: a)
environment variable setup, b) launch real compiler, forwarding passed
arguments to it.

This wrapper script cannot be common, because for each kind of build env
variable set will be different. So it need to be created at CMake
generation time saving current QNX* env variables into this wrapper script.
So next time you can open clean shell and run 'make' or 'ninja' and it will
properly use environment variables defined previously at generation stage.

I implemented that in my toolchain file, redirecting CMAKE_C_COMPILER to my
gcc_wrapper.sh and that was working perfectly for 'Unix Makefiles'
generator. 'Ninja' generator was failing because it cannot execute .sh
files. Fine, lets replace CMAKE_C_COMPILER="gcc_wrapper.sh" with
CMAKE_C_COMPILER="/path/to/sh.exe gcc_wrapper.sh". But that does not work,
because CMAKE_C_COMPILER expects full path to executable, not command line.
I reworked wrapper as Windows batch file: gcc_wrapper.bat. Now it works
under 'Ninja' but fails under 'Unix Makefiles', because QNX SDK make
overrides .bat processing somehow.

Maybe there were another reasons, but at some point I decided that the most
appropriate way will be to stop playing with Windows environment. If QNX
SDK applications always expect Unix environment we should give it to them.
That is why I added 'Unix Ninja' generator that will always use sh as shell
tool.

Thanks,
Daniel


On Mon, Jan 19, 2015 at 2:50 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/16/2015 01:13 PM, Daniel Levin wrote:
> > The CMake and Ninja were part of the bigger build script,
> > which was running under the QNX SDK sh.exe.
> > When running under this shell it overrides some environment
> > variables (compare attached files).
>
> The main differences I see are:
>
> * The Windows shell is a 64-bit cmd and the MSYS one is 32-bit
> * PATH has been converted to MSYS-style and prepended with /usr/bin
> * Added: QNX_HOST=c:\opt\qnx650-gcc-4.8.1\host\win32\x86
> * Added: QNX_TARGET=c:\opt\qnx650-gcc-4.8.1\target\qnx6
> * Added: TERM=cygwin, consistent with MSYS shells
> * Added: SHLVL=1
> * The "TEMP" and "TMP" variables are /tmp instead of the Windows dirs
>
> So this is a MSYS shell.  AFAIK ninja under MSYS sh.exe normally
> works even for pure Windows builds.  Perhaps their shell does more.
>
> > But as far as I remember it also does some nasty launcher overrides,
> > intercepting calls to cmd, bat and sh and tries to process them
> > somehow else.
>
> Do you mean some kind of dll injection to intercept CreateProcess calls?
>
> I'd really like to have a deep understanding of the situation before
> adding a lot of escaping code for a specialized environment.  It
> may be that ninja simply needs to learn how to isolate itself in
> this case.
>
> Thanks,
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150120/c284735f/attachment-0001.html>

From aleixpol at kde.org  Tue Jan 20 11:50:39 2015
From: aleixpol at kde.org (Aleix Pol)
Date: Tue, 20 Jan 2015 17:50:39 +0100
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <54BE6A6D.4070007@kitware.com>
References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com>
 <CACcA1RobpX-JENv7pJo=gAqTXB_W7-qF3OrFd6e8XS4eUCERBg@mail.gmail.com>
 <542D4879.20204@kitware.com> <6761034.LHuUtODnIM@eto>
 <CACcA1RpF9V7NnpgmShr=6cKJHcMz3kZ0XxUFwtPtgYJkkS+Fzg@mail.gmail.com>
 <CACcA1RoqwY_z2edqSiWaxbx3JD9+ZTMrthYJ_eOMLZ68Z+KhYA@mail.gmail.com>
 <54BE6A6D.4070007@kitware.com>
Message-ID: <CACcA1RrhtMdQETuNfzeCSBLpr-iYMwi=i7YkAD8FX=oKis-vpA@mail.gmail.com>

On Tue, Jan 20, 2015 at 3:47 PM, Brad King <brad.king at kitware.com> wrote:
> On 12/18/2014 09:02 PM, Aleix Pol wrote:
>> I would like to propose this as a final version of this patch.
>> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
>
> For reference, this was also attached in a later message of this
> thread on 2015-01-09:
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061
>
>> I have a working proof of concept in KDevelop already I'm quite happy with.
>
> Can you post a link to that implementation so others may try it?
It can be found by:
git clone git://anongit.kde.org/kdevelop -b cmakePossibleTargetsFile

https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/show?rev=cmakePossibleTargetsFile

>
> Steve K. posted a review of your patch on 2014-12-19:
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972
>
> that has not yet received a response.
Will look into these tonight.

>
> Also, for unrelated reasons we've now added JsonCpp into the CMake
> build process.  You could consider using that to write the .json
> file so that no manual formatting or escaping code is needed.
> The current patch does not add potentially needed json escapes.

I will consider to.

Aleix

From ben.boeckel at kitware.com  Tue Jan 20 12:00:58 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 20 Jan 2015 12:00:58 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
 <54BD5FEE.4040605@kitware.com>
 <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
Message-ID: <20150120170058.GA11931@megas.kitwarein.com>

On Tue, Jan 20, 2015 at 10:42:47 -0500, Daniel Levin wrote:
> This wrapper script cannot be common, because for each kind of build env
> variable set will be different. So it need to be created at CMake
> generation time saving current QNX* env variables into this wrapper script.
> So next time you can open clean shell and run 'make' or 'ninja' and it will
> properly use environment variables defined previously at generation stage.

What if Ninja itself gained support for 'env =' on rules for Ninja to
set environment variables for the rule and QNX-on-Windows set CMake
variables which filled this in appropriately?

--Ben

From dendy.ua at gmail.com  Tue Jan 20 12:26:59 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Tue, 20 Jan 2015 12:26:59 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <20150120170058.GA11931@megas.kitwarein.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
 <54BD5FEE.4040605@kitware.com>
 <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
 <20150120170058.GA11931@megas.kitwarein.com>
Message-ID: <CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>

As far as I understand this 'env' is not a standard key in Ninja, right?
That would be actually great to let CMake define environment variables in
rules.
Does CMake support that already?
What about Makefile compatibility, is it possible to define env variables
per rule in Makefiles?


On Tue, Jan 20, 2015 at 12:00 PM, Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Tue, Jan 20, 2015 at 10:42:47 -0500, Daniel Levin wrote:
> > This wrapper script cannot be common, because for each kind of build env
> > variable set will be different. So it need to be created at CMake
> > generation time saving current QNX* env variables into this wrapper
> script.
> > So next time you can open clean shell and run 'make' or 'ninja' and it
> will
> > properly use environment variables defined previously at generation
> stage.
>
> What if Ninja itself gained support for 'env =' on rules for Ninja to
> set environment variables for the rule and QNX-on-Windows set CMake
> variables which filled this in appropriately?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150120/1166b14e/attachment.html>

From brad.king at kitware.com  Tue Jan 20 12:50:01 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 20 Jan 2015 12:50:01 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>	<54B7C42A.8010103@kitware.com>	<CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>	<54B93525.5090709@kitware.com>	<CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>	<54BD5FEE.4040605@kitware.com>
 <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
Message-ID: <54BE9549.4090308@kitware.com>

On 01/20/2015 10:42 AM, Daniel Levin wrote:
> - you need to explicitly load environment variables each time before build

This is the standard approach expected by Makefile and Ninja generators.
Even for builds with MSVC's cl tool we expect users to launch a command
prompt with the proper PATH, INCLUDE, LIB, etc. environment variables set,
and then run the build from there.

-Brad


From brad.king at kitware.com  Tue Jan 20 12:51:38 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 20 Jan 2015 12:51:38 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>	<54B7C42A.8010103@kitware.com>	<CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>	<54B93525.5090709@kitware.com>	<CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>	<54BD5FEE.4040605@kitware.com>	<CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>	<20150120170058.GA11931@megas.kitwarein.com>
 <CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>
Message-ID: <54BE95AA.9020300@kitware.com>

On 01/20/2015 12:26 PM, Daniel Levin wrote:
> As far as I understand this 'env' is not a standard key in Ninja, right?
> That would be actually great to let CMake define environment variables in rules.
> Does CMake support that already?
> What about Makefile compatibility, is it possible to define env variables per rule in Makefiles?

There is no model for specifying environment variables as part of build
rules.  We expect that environment variables required by the toolchain
in use are already loaded.

-Brad


From dendy.ua at gmail.com  Tue Jan 20 13:04:14 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Tue, 20 Jan 2015 13:04:14 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <54BE95AA.9020300@kitware.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
 <54BD5FEE.4040605@kitware.com>
 <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
 <20150120170058.GA11931@megas.kitwarein.com>
 <CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>
 <54BE95AA.9020300@kitware.com>
Message-ID: <CAAvz69yvW8S0MzNc-YSJeUZhu5vR9uTzn=JM5CRf-qSxRSxSag@mail.gmail.com>

Brad, do you think rule env variables would be a good enhancement for CMake?
This actually follows existing approach: configure everything once, save
into cache, build with single invocation of build tool.
The difference is only in details whether to pass options as arguments or
as environment variables.
But for the end user both should be able to be saved in cache, because
regardless whether that was env variable or CMake variable they have same
meaning: it is a configure time option.
Requiring user to set same env variables at build is error prone, because
it is something that can be automated.

P.S. My personal thumb rule is "what can be automated should be automated".

On Tue, Jan 20, 2015 at 12:51 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/20/2015 12:26 PM, Daniel Levin wrote:
> > As far as I understand this 'env' is not a standard key in Ninja, right?
> > That would be actually great to let CMake define environment variables
> in rules.
> > Does CMake support that already?
> > What about Makefile compatibility, is it possible to define env
> variables per rule in Makefiles?
>
> There is no model for specifying environment variables as part of build
> rules.  We expect that environment variables required by the toolchain
> in use are already loaded.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150120/063279cc/attachment.html>

From brad.king at kitware.com  Tue Jan 20 13:18:27 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 20 Jan 2015 13:18:27 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69yvW8S0MzNc-YSJeUZhu5vR9uTzn=JM5CRf-qSxRSxSag@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>	<54B7C42A.8010103@kitware.com>	<CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>	<54B93525.5090709@kitware.com>	<CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>	<54BD5FEE.4040605@kitware.com>	<CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>	<20150120170058.GA11931@megas.kitwarein.com>	<CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>	<54BE95AA.9020300@kitware.com>
 <CAAvz69yvW8S0MzNc-YSJeUZhu5vR9uTzn=JM5CRf-qSxRSxSag@mail.gmail.com>
Message-ID: <54BE9BF3.9060209@kitware.com>

On 01/20/2015 01:04 PM, Daniel Levin wrote:
> Brad King wrote:
>> We expect that environment variables required by the toolchain
>> in use are already loaded.
> configure everything once, save into cache, build with single
> invocation of build tool

Use of a developer-provided environment was a very early and quite
fundamental design decision, and is unlikely to be changed.

I'd rather this discussion focus on how to get a sh-based ninja
working for your environment.  Unfortunately without access to
such an environment myself I do not understand it well enough to
suggest the best approach.

Can you provide sample ninja build files (perhaps hand written)
that demonstrate invocations of the compiler and other tools,
assuming it runs with the proper environment already defined?

-Brad


From gjasny at googlemail.com  Tue Jan 20 14:44:43 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Tue, 20 Jan 2015 20:44:43 +0100
Subject: [cmake-developers] [PATCH] Retrieve Xcode CompilerId via static
 libraries
In-Reply-To: <54B3D38D.7080709@kitware.com>
References: <1421004355-68565-1-git-send-email-gjasny@googlemail.com>
 <54B3D38D.7080709@kitware.com>
Message-ID: <54BEB02B.7000206@googlemail.com>

Hello,

On 12/01/15 15:00, Brad King wrote:
> I've made a change using that approach here:
> 
>  Xcode: Do not require code signing for compiler id (#15329)
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=584aaa1c

Works great. Do you plan to make this patch available in 3.1.1 release?

Thanks,
Gregor


From eike at sf-mail.de  Tue Jan 20 17:31:12 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 20 Jan 2015 23:31:12 +0100
Subject: [cmake-developers] Unknown CMake bugs
Message-ID: <1529445.fgTbK1zrLZ@caliban.sf-tec.de>

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

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

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

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cmake/patches/patch-Source_CMakeLists_txt?rev=1.6&content-type=text/x-cvsweb-markup&hideattic=1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150120/a9b881f5/attachment.sig>

From brad.king at kitware.com  Wed Jan 21 08:24:10 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 21 Jan 2015 08:24:10 -0500
Subject: [cmake-developers] [PATCH] Retrieve Xcode CompilerId via static
 libraries
In-Reply-To: <54BEB02B.7000206@googlemail.com>
References: <1421004355-68565-1-git-send-email-gjasny@googlemail.com>
 <54B3D38D.7080709@kitware.com> <54BEB02B.7000206@googlemail.com>
Message-ID: <54BFA87A.4060404@kitware.com>

On 01/20/2015 02:44 PM, Gregor Jasny wrote:
> Do you plan to make this patch available in 3.1.1 release?

Yes.  It's already been backported to the 'release' branch:

 Xcode: Do not require code signing for compiler id (#15214)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b7209f6

and the commit message revised to reference a more appropriate
issue number.

-Brad


From prasad.sharath at gmail.com  Wed Jan 21 10:57:32 2015
From: prasad.sharath at gmail.com (Sharath Prasad)
Date: Wed, 21 Jan 2015 09:57:32 -0600
Subject: [cmake-developers] Cmake 2.8.8 --> can't find curses.h
Message-ID: <CAFsDJ=-vujwhVTUNfN9BkxO_jWBdjKmmR0iYjN-EeHZwdrvWMw@mail.gmail.com>

Hello.

I am trying to use a specific version of cmake (v2.8.8). I also need ccmake
(v2.8.8). I located the folders uploaded for this release. I plan to use it
on ubuntu. I downloaded cmake folders and extracted all the folders related
to Linux. However, only one folder has options to build from scratch. Other
folders have binaries that do not run on my machine.

The folder that compiles from scratch cannot locate CURSES or NCURSES and
has trouble locating curses.h

So ccmake does not work. If I install ccmake, it updates to the latest
version 2.8.12 or so.

I need v2.8.8 specifically, Can you help?


Thanks,
Sharath
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150121/23635ff5/attachment.html>

From brad.king at kitware.com  Wed Jan 21 11:36:14 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 21 Jan 2015 11:36:14 -0500
Subject: [cmake-developers] Unknown CMake bugs
In-Reply-To: <1529445.fgTbK1zrLZ@caliban.sf-tec.de>
References: <1529445.fgTbK1zrLZ@caliban.sf-tec.de>
Message-ID: <54BFD57E.3020503@kitware.com>

On 01/20/2015 05:31 PM, Rolf Eike Beer wrote:
> Some bugs of CMake (or what downstreams thinks are bug)

Thanks for the links.

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

They don't want to get -isysroot flags for their toolchain, and
claim that CMake is stupid for trying to add it, and patch it out.
Of course we have good reasons for adding it, and just need to
make it not do so with their toolchain.  In
Modules/Platform/Darwin-GNU.cmake we already try to detect
whether the flag is available.  Without more details I don't know
if we can know why it doesn't work automatically for them.

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

They just want to bootstrap with Ninja, except on specific
architectures.  Not an upstream concern.

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

That says "CMake's built-in ELF parser is broken on arm" but
does not say why.  Someone with access to such a platform
would have to investigate further.

-Brad


From raffi.enficiaud at free.fr  Wed Jan 21 12:01:40 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Wed, 21 Jan 2015 18:01:40 +0100
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
In-Reply-To: <543FD60A.5060508@kitware.com>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com>
Message-ID: <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>

Hi again,

I did some progress on this topic, slowly as usual. 

> On 16 Oct 2014, at 16:28, Brad King <brad.king at kitware.com> wrote:
> 
> On 10/13/2014 02:23 PM, Raffi Enficiaud wrote:
>> I had a hard time making some stuff compile again with Matlab under Linux.
>> The fact is that Matlab is shipped with its own version of libC, libhdf5,
>> libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc)
>> but the subminor versions are not. If I understand properly, the fact that
>> the filenames are the same prevents the dynamic loader of Linux to load the
>> files that are referred by the mex file in their respective rpath (there
>> is only one libhdf51.8.2.so in the matlab process).
> 
> It's the SONAME that matters for the dynamic loader to find the libraries
> at runtime.  It is a string copied into the dependents and used by the
> dynamic loader to find the matching file at runtime.

Even with different SONAMES, the symbols may clash. I do not know exactly how it works, but the symbols brought by an SO are not in a specific namespace and might conflict with symbols from other SOs. If there is a proper way of saying that a particular shared library needs the symbols from a particular SO, and then uses these symbols only, then it should work. I tested with symbol mapping files but I could not get it to work. The latter solution is more portable at least.

> 
>> Beside that, the
>> symbols also may clash: I had an implementation with a dynamic loader under
>> linux, but yet the boost symbols of my mex files were not loaded because
>> same symbols were already there in the process.
>> I found a technical solution to this on Linux:
>> - the use of -Wl,--exclude-libs,ALL for the linker.
> 
> According to "man ld" that option is only available on specific systems
> (i386 PE).  As you pointed out it is not available on OS X.
> 
> I think the only reliable way to do this is to make sure your plugins
> are built against the same libraries as Matlab, or to mangle the
> symbols in your dependencies so they don't conflict with Matlab.

This is not always possible:
- Matlab does not ship the headers
- Matlab has a lot of dependencies
- I experienced problems even with the same version (example of HDF5 - same subminor - and libC - different subminor)

> 
> This is outside the scope of what I think the FindMatlab module can
> achieve, so it will have to be left to the application author.
> For now please leave out the REDUCE_VISIBILITY option.  I think
> functionality like that, if provided by CMake, should be a more
> general feature not specific to FindMatlab.

Ok. What do you think about mimicking the mex compiler in terms of options set to the compiler? The -Wl,--exclude-libs,ALL is in fact set by the mex compiler for compiling the mex extensions under Linux. Then I will just drop the REDUCE_VISIBILITY from the interface and add some doc about the "best practices" that work better.

> 
>> I am using this FindMatlab in two projects now, under OSX 10.9,
>> Win7 Visual2013 and Ubuntu12.04.
> 
> Great.  In order to keep the module working, we will also need tests
> for it.  Please look at adding to the Tests/ directory a case for
> using this module.  The test case can be something we enable with
> some explicit option.  Then you can run a nightly build of CMake on
> a machine of each platform with Matlab installed and enable the test.
> Ideally you would have one for Windows, OS X, and Linux, at least.
> Without regular testing the functionality is bound to regress as
> changes are made to CMake.

I added some tests:
https://github.com/raffienficiaud/CMake/tree/matlab_wrapper/Tests/Module/Matlab2

But I have a quick question about the proper way of adding a test:
https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/CMakeLists.txt#L3095-L3099

So I am declaring tests in the CMakeLists.txt of the Matlab module test, and I am running ctest with the current configuration in order to run these tests. Is that the way of doing correctly this? If these tests should be ran in a nightly build process, should I add these tests only if Matlab is available? What are the best practices?
For instance, this test
https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/Module/Matlab2/test_should_fail/CMakeLists.txt

should fail because of a component lacking the the find_package option, and I test it with this:
https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/CMakeLists.txt#L3099

but I do not know if this is the right way to go.


I also changed the 
set(MATLAB_ADDITIONAL_VERSIONS
       "release_name1" "corresponding_version1"
       "release_name2" "corresponding_version2"
to

set(MATLAB_ADDITIONAL_VERSIONS
       "release_name1=corresponding_version1"
       "release_name2=corresponding_version2"

as you suggested in an earlier post.

Best,
Raffi

> 
> Thanks,
> -Brad


From DLRdave at aol.com  Wed Jan 21 12:32:40 2015
From: DLRdave at aol.com (David Cole)
Date: Wed, 21 Jan 2015 12:32:40 -0500
Subject: [cmake-developers] Cmake 2.8.8 --> can't find curses.h
In-Reply-To: <CAFsDJ=-vujwhVTUNfN9BkxO_jWBdjKmmR0iYjN-EeHZwdrvWMw@mail.gmail.com>
References: <CAFsDJ=-vujwhVTUNfN9BkxO_jWBdjKmmR0iYjN-EeHZwdrvWMw@mail.gmail.com>
Message-ID: <CAKME8fGZ7uUR7O7N0tTr6Y44VKB_vxm871E_5bMPm9rKHXdOoA@mail.gmail.com>

This is a pre-built Linux binary that should work on that system, and
should include ccmake:

    http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz

If you can't run it, it's probably because you're on an x64 box, and
you need the "run the 32-bit exes and libs" library -- hopefully
somebody else can chime in with the package to install, because I can
never remember the name of it.


HTH,
David C.



On Wed, Jan 21, 2015 at 10:57 AM, Sharath Prasad
<prasad.sharath at gmail.com> wrote:
> Hello.
>
> I am trying to use a specific version of cmake (v2.8.8). I also need ccmake
> (v2.8.8). I located the folders uploaded for this release. I plan to use it
> on ubuntu. I downloaded cmake folders and extracted all the folders related
> to Linux. However, only one folder has options to build from scratch. Other
> folders have binaries that do not run on my machine.
>
> The folder that compiles from scratch cannot locate CURSES or NCURSES and
> has trouble locating curses.h
>
> So ccmake does not work. If I install ccmake, it updates to the latest
> version 2.8.12 or so.
>
> I need v2.8.8 specifically, Can you help?
>
>
> Thanks,
> Sharath
>
> --
>
> 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

From mantis at public.kitware.com  Wed Jan 21 13:45:33 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 21 Jan 2015 13:45:33 -0500
Subject: [cmake-developers] [CMake 0015363]: CMake 3.1.0 with "Visual Studio
	12 2013 ARM" generator for WP8.1 fails to compile simple test
	program if path length > 91 chars
Message-ID: <6f806709325ee5293a1c0437e4460355@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15363 
====================================================================== 
Reported By:                Moshe Rubin
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15363
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-01-21 13:45 EST
Last Modified:              2015-01-21 13:45 EST
====================================================================== 
Summary:                    CMake 3.1.0 with "Visual Studio 12 2013 ARM"
generator for WP8.1 fails to compile simple test program if path length > 91
chars
Description: 
When running CMake with the "Visual Studio 12 2013 ARM" generator to create a
Windows Phone 8.1 project file, the run will fail with the message:

<quote>
The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/x86_arm/cl.exe" is not able to compile a simple test program.
</quote>

I have been able to confirm that CMake will fail consistently if the full path
to the folder from which CMake is being run is greater than ninety (90)
characters.  If equal to, or less, than 90 characters, the run succeeds.

I have only been able to consistently reproduce this problem with the "Visual
Studio 12 2013 ARM" generator.


Steps to Reproduce: 
I attach a Windows batch file called "cmake-mantis.bat" that will reproduce the
two cases, successful and unsuccessful.  Here are the steps:

(1) Copy the Windows batch file "cmake-matis.bat" to any folder in the file
system.

(2) "cd" to above folder.

(3) To reproduce an unsuccessful run, execute the following command:

    cmake-mantis.bat bad

    In this case, the folder from where CMake is execute is:

   
%TEMP%\CMakeTest\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890

(4) To reproduce a successful run, execute the following command:

    cmake-mantis.bat good

    In this case, the folder from which CMake is executed is:

    %TEMP%\CMakeTest

(5) The batch file leaves the try_compile build trees intact for debugging
purposes.


Additional Information: 
I added the "--trace" command line option for both the 'good' and the 'bad' runs
and have uploaded them as the files "foo.good" and "foo.bad".  Doing a diff on
them both shows the following strange phenomenon: both logs are essentially
identical (except for folder names) until foo.good:2649 and foo.bad:2650.  At
this point, inexplicably, CMAKE_C_COMPILER_WORKS is TRUE in foo.good but FALSE
in goo.bad:

Starting at line 2649 in foo.good:

<snippet>
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake(56):  if(NOT
CMAKE_C_COMPILER_WORKS )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake(65):  else()
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake(66): 
if(C_TEST_WAS_RUN )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake(67): 
PrintTestCompilerStatus(C  -- works )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCompilerCommon.cmake(16): 
if(CMAKE_GENERATOR MATCHES Make )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCompilerCommon.cmake(18):  else()
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCompilerCommon.cmake(19): 
message(STATUS Check for working ${LANG} compiler using:
${CMAKE_GENERATOR}${MSG} )
-- Check for working C compiler using: Visual Studio 12 2013 ARM -- works
</snippet>

Starting at line 2650 in foo.bad:

<snippet>
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake(56):  if(NOT
CMAKE_C_COMPILER_WORKS )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake(57): 
PrintTestCompilerStatus(C  -- broken )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCompilerCommon.cmake(16): 
if(CMAKE_GENERATOR MATCHES Make )
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCompilerCommon.cmake(18):  else()
C:/Program Files
(x86)/CMake/share/cmake-3.1/Modules/CMakeTestCompilerCommon.cmake(19): 
message(STATUS Check for working ${LANG} compiler using:
${CMAKE_GENERATOR}${MSG} )
-- Check for working C compiler using: Visual Studio 12 2013 ARM -- broken
</snippet>

There are no differences in the traces leading up to these points to explain the
discrepancy.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-21 13:45 Moshe Rubin    New Issue                                    
======================================================================


From eike at sf-mail.de  Wed Jan 21 14:11:11 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Wed, 21 Jan 2015 20:11:11 +0100
Subject: [cmake-developers] Unknown CMake bugs
In-Reply-To: <54BFD57E.3020503@kitware.com>
References: <1529445.fgTbK1zrLZ@caliban.sf-tec.de>
 <54BFD57E.3020503@kitware.com>
Message-ID: <2123066.uvAyuHlEIU@eto>

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

Yes, because:

XXX: broken on arm and m88k

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

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

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150121/1940f0c1/attachment.sig>

From aseidl at gmail.com  Wed Jan 21 15:19:58 2015
From: aseidl at gmail.com (Andrew Seidl)
Date: Wed, 21 Jan 2015 14:19:58 -0600
Subject: [cmake-developers] [PATCH] FindCUDA: add cuSOLVER
Message-ID: <CADVd=LwsUZsEgOuZg2pd2UbjPX5agBG0W=saP72x87wWLiOSVQ@mail.gmail.com>

Hi all,

Here's a small patch for FindCUDA for finding the new cuSOLVER library
included in the upcoming CUDA 7.0.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150121/52f87875/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindCUDA-add-cuSOLVER.patch
Type: application/octet-stream
Size: 1621 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150121/52f87875/attachment.obj>

From brad.king at kitware.com  Wed Jan 21 15:55:29 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 21 Jan 2015 15:55:29 -0500
Subject: [cmake-developers] [PATCH] FindCUDA: add cuSOLVER
In-Reply-To: <CADVd=LwsUZsEgOuZg2pd2UbjPX5agBG0W=saP72x87wWLiOSVQ@mail.gmail.com>
References: <CADVd=LwsUZsEgOuZg2pd2UbjPX5agBG0W=saP72x87wWLiOSVQ@mail.gmail.com>
Message-ID: <54C01241.9000201@kitware.com>

On 01/21/2015 03:19 PM, Andrew Seidl wrote:
> Here's a small patch for FindCUDA for finding the new cuSOLVER
> library included in the upcoming CUDA 7.0.

Applied, thanks:

 FindCUDA: Add cuSOLVER library from CUDA 7.0
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e56c9327

-Brad


From ben.boeckel at kitware.com  Wed Jan 21 16:17:35 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 21 Jan 2015 16:17:35 -0500
Subject: [cmake-developers] Improving Vim support in CMake
Message-ID: <20150121211735.GA32290@megas.kitwarein.com>

Hi all,

Any Vim users out there who would like to try out the changes I've made
to the Vim files shipped with CMake can grab it from either stage
(vim-support-overhaul) or my GitHub fork[1]. It is not in next yet since
I expect further changes to come and that would only make unnecessary
churn on the dashboards.

List of improvements to the syntax file:

  - drop support for < 7.0 (which is 7.5 years old now);
  - add support for Lua-style comments;
  - update the list of system variables;
  - update the list of operators;
  - make only commands case-insensitive;
  - update the list of built-in commands (and deprecated ones);
  - highlight user-defined function and macro calls; and
  - tweak colors a bit.

One thing which was also changed that isn't in that list (from the
commit message) is that deprecated commands are now highlighted as
WarningMsg so they stand out.

The cmake-help code has also been changed to use 'K' rather than <F1> to
get help about a command (and the global binding was removed since I
don't expect it is used much and it's only going to be a surprise).

I don't have enough experience with indentation logic, but that also
needs some work.

Testers and comments welcome :) .

--Ben

[1]https://github.com/mathstuf/CMake/tree/vim-support-overhaul

From brad.king at kitware.com  Wed Jan 21 16:30:42 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 21 Jan 2015 16:30:42 -0500
Subject: [cmake-developers] Introduction and volunteering for the Matlab
 package
In-Reply-To: <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
Message-ID: <54C01A82.6080400@kitware.com>

On 01/21/2015 12:01 PM, Raffi Enficiaud wrote:
> Ok. What do you think about mimicking the mex compiler in terms
> of options set to the compiler? The -Wl,--exclude-libs,ALL is in
> fact set by the mex compiler for compiling the mex extensions under
> Linux. Then I will just drop the REDUCE_VISIBILITY from the
> interface and add some doc about the "best practices" that work better.

I think suggesting it in the documentation is fine.  If some common
cross-platform solutions evolve then we can revisit adding official
support.

> But I have a quick question about the proper way of adding a test:
[snip]
> should fail because of a component lacking the the find_package option

The best place to put tests covering bad CMake code and error cases
is under the Tests/RunCMake infrastructure.  That allows explicit
matching of return codes and error messages.

Thanks,
-Brad


From michael at ensslin.cc  Thu Jan 22 04:46:40 2015
From: michael at ensslin.cc (=?UTF-8?B?TWljaGFlbCBFbsOfbGlu?=)
Date: Thu, 22 Jan 2015 10:46:40 +0100
Subject: [cmake-developers] Adding an option for relative compiler
	invocations
Message-ID: <54C0C700.5010801@ensslin.cc>

Hi,

this issue has been discussed here in 2011, but not to my satisfaction
(http://www.cmake.org/pipermail/cmake/2011-December/thread.html#48266).

My logging code uses __FILE__ to print the name of the relevant source
file; cmake's absolute-path compiler invocations, combined with gcc's
implementation of __FILE__, cause two issues:

(0.0) The build path ends up being part of the binary
(0.1) The build path is printed for every log message

I've identified several solutions, all of which are unsatisfactory:

(1.0) At the top of every single source and header file, writing
      '#line 2 subdir/my_file.cpp'.
(1.1) Using run-time string manipulations to sanitize the filename.
      Doesn't solve (0.0) and comes with a run-time cost.
(1.2) Using compile-time string manipulations to sanitize the filename.
      Due to limitations of C++, this requires template metaprogramming,
      leading to unreasonable complexity and compile times.
(1.3) Storing CMAKE_SOURCE_DIR as an constexpr in configure.h,
      and using that to calculate constexpr offsets into the __FILE__
      literals. This does not solve (0.0), but it's the solution I've
      decided to use for now.
(1.4) Replacing gcc by a wrapper script that sanitizes all
      filename arguments and changes the working directory.

The following are not solutions at all:

(2.0) Using '-DFILENAME=subdir/my_file.cpp'. This fails for
      included headers.
(2.1) Ignoring the issue. I care about such minor details.

Over the last several decades, at least on the POSIX platform, it has
become common practice to invoke compilers with relative file paths, and
compilers have adopted to act accordingly. While the true culprit is the
C standard's lax definition of __FILE__, I'm blaming cmake's unusual,
absolute-path invocation behavior.

Even in the unlikely event that gcc (and clang) decided to introduce
flags that would modify the behavior of __FILE__, all they could do
would be stripping the entire basename, so 'project_dir/my_file.cpp' and
'project_dir/subdir/my_file.cpp' would have the same value for __FILE__.

I suggest adding an additional, optional parameter to add_executable
that would allow switching on relative gcc invocations from a directory
of the user's choosing.

Thanks for considering this proposal.

 ~ Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/369d8805/attachment.sig>

From mantis at public.kitware.com  Thu Jan 22 07:55:54 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 22 Jan 2015 07:55:54 -0500
Subject: [cmake-developers] [CMake 0015364]: FindBoost.cmake does not find
	debug libraries if they are located in a different directory
	than the release libraries
Message-ID: <ab7c1d3edde89c1507905cbfcd571aab@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15364 
====================================================================== 
Reported By:                Gunther Laure
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15364
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-22 07:55 EST
Last Modified:              2015-01-22 07:55 EST
====================================================================== 
Summary:                    FindBoost.cmake does not find debug libraries if
they are located in a different directory than the release libraries
Description: 
FindBoost.cmake does not find debug libraries if they are located in a different
directory than the release libraries.

Assume following boost lib dir layout:

lib/shared/Debug
lib/shared/Release
lib/static/Debug
lib/static/Release
lib64/shared/Debug
lib64/shared/Release
lib64/static/Debug
lib64/static/Release

For previous cmake version we changed changed the CMAKE_LIBRARY_PATH (depending
on x86,x64,Release,Debug) so that FindBoost did find the correct libraries.

The current version of FindBoost.cmake assumes that Debug and Release have to be
in the same directoy.

This is done in the macro _Boost_FIND_LIBRARY (line 323-325):
  # If Boost_LIBRARY_DIR is known then search only there.
  if(Boost_LIBRARY_DIR)
    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
  endif()


Commenting/Removing these lines restores the previous behaviour and Release and
Debug libraries are found again.


Steps to Reproduce: 

create a directory structure like that:
lib/Debug
lib/Release

and put valid boost libs in there:
lib/Debug/boost_system-vc120-mt-gd-1_55.lib
lib/Release/boost_system-vc120-mt-1_55.lib

With CMAKE_LIBRARY_PATH set to both directories and the current version of cmake
(3.1) 
find_package(Boost REQUIRED COMPONENTS
  system
)
will result in:
Boost_SYSTEM_LIBRARY = lib/Release/boost_system-vc120-mt-1_55.lib


with the lines 323 to 325 commented in FindBoost.cmake it will find both libs:
Boost_SYSTEM_LIBRARY =
optimized;lib/Release/boost_system-vc120-mt-1_55.lib;debug;lib/Debug/boost_system-vc120-mt-gd-1_55.lib
(absolute path removed manually)



Additional Information: 
If this is only an issue for us, we could workaround the problem with a
customized FindBoost.cmake file in our environment.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-22 07:55 Gunther Laure  New Issue                                    
======================================================================


From raffi.enficiaud at free.fr  Thu Jan 22 10:13:47 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Thu, 22 Jan 2015 16:13:47 +0100
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
In-Reply-To: <54C01A82.6080400@kitware.com>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com>
Message-ID: <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>

Hi,

I added a section "known problems" in the documentation and removed the REDUCE_VISIBILITY option. I am keeping the hidden symbols of the compiled MEX file as it appears to be something properly supported. This behaviour is also documented.

I moved the test for bad configuration under RunCMake with appropriate error message and return code.

How do we proceed next?

Best,
Raffi Enficiaud


> On 21 Jan 2015, at 22:30, Brad King <brad.king at kitware.com> wrote:
> 
> On 01/21/2015 12:01 PM, Raffi Enficiaud wrote:
>> Ok. What do you think about mimicking the mex compiler in terms
>> of options set to the compiler? The -Wl,--exclude-libs,ALL is in
>> fact set by the mex compiler for compiling the mex extensions under
>> Linux. Then I will just drop the REDUCE_VISIBILITY from the
>> interface and add some doc about the "best practices" that work better.
> 
> I think suggesting it in the documentation is fine.  If some common
> cross-platform solutions evolve then we can revisit adding official
> support.
> 
>> But I have a quick question about the proper way of adding a test:
> [snip]
>> should fail because of a component lacking the the find_package option
> 
> The best place to put tests covering bad CMake code and error cases
> is under the Tests/RunCMake infrastructure.  That allows explicit
> matching of return codes and error messages.
> 
> Thanks,
> -Brad
> 


From dendy.ua at gmail.com  Thu Jan 22 10:34:18 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Thu, 22 Jan 2015 10:34:18 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <54BE9BF3.9060209@kitware.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
 <54BD5FEE.4040605@kitware.com>
 <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
 <20150120170058.GA11931@megas.kitwarein.com>
 <CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>
 <54BE95AA.9020300@kitware.com>
 <CAAvz69yvW8S0MzNc-YSJeUZhu5vR9uTzn=JM5CRf-qSxRSxSag@mail.gmail.com>
 <54BE9BF3.9060209@kitware.com>
Message-ID: <CAAvz69w_hPfF+9N-UyDDF7+h0w8a0VYpAyj3r0K6VyhaLKp7RA@mail.gmail.com>

I played a bit more and finally came with solution that works for me with
standard Ninja generator for QNX SDK.

1. In my toolchain file if ( CMAKE_HOST_WIN32 AND NOT "${CMAKE_GENERATOR}"
STREQUAL "Unix Makefiles" ) then I will generate .bat wrapper around
compiler instead of .sh.
2. In custom build rules instead of launching .sh scripts directly shell
should be specified explicitly.

I predict that answer about (1) will be the same: load environment before
launching build. I would want to start another thread to discuss this
issue, because it sounds critical to me.

About "Unix Ninja". I believe the main reason for the "Unix Makefiles" was
the fact that some make tools can handle Unix syntax only. From my point of
view it also means Unix environment. That is why I still think even if
Ninja tool has single syntax, when running it under Unix environment it
still make sense to force Ninja to use sh as shell.


On Tue, Jan 20, 2015 at 1:18 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/20/2015 01:04 PM, Daniel Levin wrote:
> > Brad King wrote:
> >> We expect that environment variables required by the toolchain
> >> in use are already loaded.
> > configure everything once, save into cache, build with single
> > invocation of build tool
>
> Use of a developer-provided environment was a very early and quite
> fundamental design decision, and is unlikely to be changed.
>
> I'd rather this discussion focus on how to get a sh-based ninja
> working for your environment.  Unfortunately without access to
> such an environment myself I do not understand it well enough to
> suggest the best approach.
>
> Can you provide sample ninja build files (perhaps hand written)
> that demonstrate invocations of the compiler and other tools,
> assuming it runs with the proper environment already defined?
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/c199b180/attachment.html>

From mark.j.abraham at gmail.com  Thu Jan 22 10:41:36 2015
From: mark.j.abraham at gmail.com (Mark Abraham)
Date: Thu, 22 Jan 2015 16:41:36 +0100
Subject: [cmake-developers] make more CUDA cache variables advanced
Message-ID: <CAMNuMAS5oBFVYsBq3OQ2-LOHm0__WD5k_wa+i4ZhydJ7bYFgag@mail.gmail.com>

Hi,

FindCUDA.cmake creates a number of option variables that are not set to be
advanced cache variables. I think that those that do not seem to relate to
normal usage of CUDA should be made advanced. That way, non-developer end
users of ccmake get to see among the non-advanced options for their project
the ones that really make sense for them to change. Developers and power
users can switch to the advanced display, of course, just like they do now
for a range of other CUDA variables.

Patch on cmake master attached.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/2cab062c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Mark-more-CUDA-variables-as-advanced.patch
Type: text/x-patch
Size: 1160 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/2cab062c/attachment.bin>

From mantis at public.kitware.com  Thu Jan 22 10:57:13 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 22 Jan 2015 10:57:13 -0500
Subject: [cmake-developers] [CMake 0015365]: Provide per-target CXX/C flags
Message-ID: <6c51360db218e543cbbd011b4484cc46@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15365 
====================================================================== 
Reported By:                Kevin Wojniak
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15365
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-22 10:57 EST
Last Modified:              2015-01-22 10:57 EST
====================================================================== 
Summary:                    Provide per-target CXX/C flags
Description: 
CMake provides CMAKE_CXX_FLAGS, but this is global. It'd be good to have a
per-target CXX flags ability. Possibly a macro such as
target_compile_options_cxx() and target_compile_options_c(), or a way to do this
with generator expressions (doesn't seem to have a LANG property for sources).
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-22 10:57 Kevin Wojniak  New Issue                                    
======================================================================


From brad.king at kitware.com  Thu Jan 22 11:27:37 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 22 Jan 2015 11:27:37 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <CAAvz69w_hPfF+9N-UyDDF7+h0w8a0VYpAyj3r0K6VyhaLKp7RA@mail.gmail.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>	<54B7C42A.8010103@kitware.com>	<CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>	<54B93525.5090709@kitware.com>	<CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>	<54BD5FEE.4040605@kitware.com>	<CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>	<20150120170058.GA11931@megas.kitwarein.com>	<CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>	<54BE95AA.9020300@kitware.com>	<CAAvz69yvW8S0MzNc-YSJeUZhu5vR9uTzn=JM5CRf-qSxRSxSag@mail.gmail.com>	<54BE9BF3.9060209@kitware.com>
 <CAAvz69w_hPfF+9N-UyDDF7+h0w8a0VYpAyj3r0K6VyhaLKp7RA@mail.gmail.com>
Message-ID: <54C124F9.9010905@kitware.com>

On 01/22/2015 10:34 AM, Daniel Levin wrote:
> finally came with solution that works for me with standard Ninja
> generator for QNX SDK.

Great!

> 2. In custom build rules instead of launching .sh scripts directly
> shell should be specified explicitly.

This is expected for any Windows platform that wants to run scripts.
Windows does not support shebang lines so the interpreter must always
be specified explicitly.

> 1. In my toolchain file...I will generate .bat wrapper around compiler
> instead of .sh.
> I predict that answer about (1) will be the same: load environment
> before launching build. I would want to start another thread to discuss
> this issue, because it sounds critical to me.

As I said in earlier responses this is simply a requirement and is not
likely to change.  I understand your desire to automate the environment,
but I do not think CMake is the right level to achieve that.

> About "Unix Ninja". I believe the main reason for the "Unix Makefiles"
> was the fact that some make tools can handle Unix syntax only.

The "Unix Makefiles" generator refers exactly to unix-style make tools,
and on POSIX systems is the only generator besides Ninja (excluding the
"extra" generators that use makefiles+project files).  It is available
on Windows because there are make tools on Windows that work with such
paths/shells natively.  Unless ninja were to have a variant that does
so too, then it does not need a distinct generator.

-Brad


From brad.king at kitware.com  Thu Jan 22 11:46:13 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 22 Jan 2015 11:46:13 -0500
Subject: [cmake-developers] make more CUDA cache variables advanced
In-Reply-To: <CAMNuMAS5oBFVYsBq3OQ2-LOHm0__WD5k_wa+i4ZhydJ7bYFgag@mail.gmail.com>
References: <CAMNuMAS5oBFVYsBq3OQ2-LOHm0__WD5k_wa+i4ZhydJ7bYFgag@mail.gmail.com>
Message-ID: <54C12955.5080505@kitware.com>

On 01/22/2015 10:41 AM, Mark Abraham wrote:
> FindCUDA.cmake creates a number of option variables that are not set to be advanced cache variables. I think that those that do not seem to relate to normal usage of CUDA should be made advanced. That way, non-developer end users of ccmake get to see among the non-advanced options for their project

Applied with a simpler commit message, thanks:

 FindCUDA: Mark more cache variables as advanced
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=005b409d

-Brad


From brad.king at kitware.com  Thu Jan 22 11:48:59 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 22 Jan 2015 11:48:59 -0500
Subject: [cmake-developers] Introduction and volunteering for the Matlab
 package
In-Reply-To: <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
Message-ID: <54C129FB.3070102@kitware.com>

On 01/22/2015 10:13 AM, Raffi Enficiaud wrote:
> How do we proceed next?

Please attach a copy of the patch with the latest revisions.

Thanks,
-Brad


From raffi.enficiaud at free.fr  Thu Jan 22 11:50:56 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Thu, 22 Jan 2015 17:50:56 +0100
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
In-Reply-To: <54C129FB.3070102@kitware.com>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
 <54C129FB.3070102@kitware.com>
Message-ID: <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>

Attached to this email.
I can also do a pull request if you prefer, 

Best,
Raffi Enficiaud



-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindMatlab.cmake
Type: application/octet-stream
Size: 44478 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/e911cfc8/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MatlabTestsRedirect.cmake
Type: application/octet-stream
Size: 2750 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/e911cfc8/attachment-0003.obj>
-------------- next part --------------


> On 22 Jan 2015, at 17:48, Brad King <brad.king at kitware.com> wrote:
> 
> On 01/22/2015 10:13 AM, Raffi Enficiaud wrote:
>> How do we proceed next?
> 
> Please attach a copy of the patch with the latest revisions.
> 
> Thanks,
> -Brad
> 


From dendy.ua at gmail.com  Thu Jan 22 11:54:33 2015
From: dendy.ua at gmail.com (Daniel Levin)
Date: Thu, 22 Jan 2015 11:54:33 -0500
Subject: [cmake-developers] Introduce 'Unix Ninja' generator
In-Reply-To: <54C124F9.9010905@kitware.com>
References: <CAAvz69xsVtPDgLEURi1dYSzoiaKbbBbcz=gJpe-Af-Bna+iP_g@mail.gmail.com>
 <54B7C42A.8010103@kitware.com>
 <CAAvz69xaFf_YLpJkgA=TFOO0iBz3GBGOqr1U+nGZtecOZbMapg@mail.gmail.com>
 <54B93525.5090709@kitware.com>
 <CAAvz69y732+aBAbX5hJcTmwghoC6dcgZ=827iOQR=eHoB_WwJw@mail.gmail.com>
 <54BD5FEE.4040605@kitware.com>
 <CAAvz69yF0Qxx1ameB05hVQc8rDeG3L=CugNKLq1M6=gF0SPVig@mail.gmail.com>
 <20150120170058.GA11931@megas.kitwarein.com>
 <CAAvz69wYTU1r4NQRG_RzO8EaJ+J5RybDtNusy3H0B25q9+epMA@mail.gmail.com>
 <54BE95AA.9020300@kitware.com>
 <CAAvz69yvW8S0MzNc-YSJeUZhu5vR9uTzn=JM5CRf-qSxRSxSag@mail.gmail.com>
 <54BE9BF3.9060209@kitware.com>
 <CAAvz69w_hPfF+9N-UyDDF7+h0w8a0VYpAyj3r0K6VyhaLKp7RA@mail.gmail.com>
 <54C124F9.9010905@kitware.com>
Message-ID: <CAAvz69xJsWWR+gqVPhA8A8jMQyeJgDUUwMJKiMMxBEMefcYQyQ@mail.gmail.com>

> This is expected for any Windows platform that wants to run scripts.
> Windows does not support shebang lines so the interpreter must always
> be specified explicitly.

At the same CMakeLists.txt is supposed to be portable. I assume any time
build rule is added shell should be always specified explicitly unless
executable file can be executed natively on all platforms.

> As I said in earlier responses this is simply a requirement and is not
> likely to change.

I would want to understand origins of this requirement. Let me describe my
thoughts in separate thread to avoid offtopic.



On Thu, Jan 22, 2015 at 11:27 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/22/2015 10:34 AM, Daniel Levin wrote:
> > finally came with solution that works for me with standard Ninja
> > generator for QNX SDK.
>
> Great!
>
> > 2. In custom build rules instead of launching .sh scripts directly
> > shell should be specified explicitly.
>
> This is expected for any Windows platform that wants to run scripts.
> Windows does not support shebang lines so the interpreter must always
> be specified explicitly.
>
> > 1. In my toolchain file...I will generate .bat wrapper around compiler
> > instead of .sh.
> > I predict that answer about (1) will be the same: load environment
> > before launching build. I would want to start another thread to discuss
> > this issue, because it sounds critical to me.
>
> As I said in earlier responses this is simply a requirement and is not
> likely to change.  I understand your desire to automate the environment,
> but I do not think CMake is the right level to achieve that.
>
> > About "Unix Ninja". I believe the main reason for the "Unix Makefiles"
> > was the fact that some make tools can handle Unix syntax only.
>
> The "Unix Makefiles" generator refers exactly to unix-style make tools,
> and on POSIX systems is the only generator besides Ninja (excluding the
> "extra" generators that use makefiles+project files).  It is available
> on Windows because there are make tools on Windows that work with such
> paths/shells natively.  Unless ninja were to have a variant that does
> so too, then it does not need a distinct generator.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/cb02deb7/attachment.html>

From robert.maynard at kitware.com  Thu Jan 22 16:54:37 2015
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 22 Jan 2015 16:54:37 -0500
Subject: [cmake-developers] [ANNOUNCE] CMake 3.1.1 Released
Message-ID: <CAFzjYVpmmXMz2B4OYPkCO63MV2T-901Gvmtom4bRGKVjTe8_7w@mail.gmail.com>

We are pleased to announce that CMake 3.1.1 is now available for download.

Please use the latest release from our download page:
  http://www.cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.1.1 since 3.1.0:

Andr? Klitzing (1):
      Eclipse: Add org.eclipse.cdt.core.cnature to CXX projects (#15068)

Ben Boeckel (4):
      get_test_property: clarify the documentation
      set_tests_properties: fix documentation
      tests: add tests for querying properties
      Xcode: Sort targets deterministically and with ALL_BUILD first (#15346)

Brad King (14):
      bootstrap: Fix syntax for Solaris 10 shell (#15317)
      Help: Clarify MinGW v. MSYS Makefiles generators (#15319)
      Ninja: Do not crash when CMAKE_<LANG>_COMPILE_OBJECT is empty (#15325)
      Ninja: Generate rules only for languages compiled in a target (#15325)
      Tests: Test using objects from a language enabled in a
subdirectory (#15325)
      Help: Add 3.1 release note about '#' escaping in Makefiles (#15322)
      Help: Clarify if(<variable>) documentation (#15335)
      Help: Document CMAKE_FIND_PACKAGE_NAME variable
      Xcode: Do not require code signing for compiler id (#15214)
      Copyright.txt: Update year range to end in 2015
      XL: Fix link flags for executables on Linux with XL compilers
      QNX: Fix detection of QCC compiler id (#15349)
      Xcode: Fix early termination on per-config source file error
      CMake 3.1.1

Calin Cascaval (1):
      CPack: Fix PackageMaker internal versioning for OS X 10.10

Chuck Atkins (1):
      Fix compilation with the Oracle / Sun compiler (#15318)

Daniele E. Domenichelli (1):
      Help: Small fixes in CPackComponent documentation

David Coppa (1):
      FindRuby: fix selection of version x.0 (#15345)

Domen Vrankar (1):
      CPack: Avoid crash on invalid CMake generator name (#15308)

Evangelos Foutras (1):
      FindRuby: Fix output check in _RUBY_CONFIG_VAR

Gregor Jasny (1):
      find_package: Document CMAKE_FIND_PACKAGE_NAME variable

Justin Borodinsky (1):
      QtAutoUic: Restore source file AUTOUIC_OPTIONS settings

Mark Abraham (1):
      FindCUDA: Do not assume CMAKE_SYSTEM_PROCESSOR is set

Peter Vasil (2):
      cmake-mode.el: Fix extracting keyword at point in cmake-help
      cmake-mode.el: Re-add explicit call to require thingatpt

Rolf Eike Beer (5):
      FindIce: Port to work with CMP0054 NEW behavior
      FindSDL: Allow if() to dereference SDL_INCLUDE_DIR for matching
      FindQt: fix setting DESIRED_QT_VERSION if "find_package(Qt VVV)"
was called
      FindQt: fix variable name in error message
      FindQt: explicitely mention that it cannot Qt5 or later

Sergey Nikulov (1):
      FindBoost: Add latest Boost version 1.57.0 and next milestone 1.58.0

Simon Gomizelj (1):
      KWSys Terminal: Add xterm-termite to VT100 color support whitelist

Stephen Kelly (7):
      Help: Document valid 14 value for CXX_STANDARD. (#15339)
      get_target_property: discern empty from undefined properties (#15333)
      QtAutoUic: Add a test for the regression in the parent commit.
      cmMakefile: Rename a method to what it really does.
      Features: Fix the COMPILE_FEATURES genex for unavailable features.
      cmTarget: Compute link language of TARGET_OBJECTS with CMP0026
OLD (#15338)
      Help: Link relevant documents for virtual override features (#15311)

Tim Blechmann (1):
      Help: Add INTERFACE_LIBRARY to TYPE target property documentation

William Lynch (1):
      Help: Update cmake.org links to avoid redirects

From prasad.sharath at gmail.com  Thu Jan 22 17:27:50 2015
From: prasad.sharath at gmail.com (Sharath Prasad)
Date: Thu, 22 Jan 2015 16:27:50 -0600
Subject: [cmake-developers] Cmake 2.8.8 --> can't find curses.h
In-Reply-To: <CAKME8fGZ7uUR7O7N0tTr6Y44VKB_vxm871E_5bMPm9rKHXdOoA@mail.gmail.com>
References: <CAFsDJ=-vujwhVTUNfN9BkxO_jWBdjKmmR0iYjN-EeHZwdrvWMw@mail.gmail.com>
 <CAKME8fGZ7uUR7O7N0tTr6Y44VKB_vxm871E_5bMPm9rKHXdOoA@mail.gmail.com>
Message-ID: <CAFsDJ=8YP+WFTW2HYHSachV3iGxhkcqgGxiOFCHiTBZntYkpRg@mail.gmail.com>

Thank you David. That helped and fixed it. I was missing libraries to run
the 32bit exes.

On Wed, Jan 21, 2015 at 11:32 AM, David Cole <DLRdave at aol.com> wrote:

> This is a pre-built Linux binary that should work on that system, and
> should include ccmake:
>
>     http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz
>
> If you can't run it, it's probably because you're on an x64 box, and
> you need the "run the 32-bit exes and libs" library -- hopefully
> somebody else can chime in with the package to install, because I can
> never remember the name of it.
>
>
> HTH,
> David C.
>
>
>
> On Wed, Jan 21, 2015 at 10:57 AM, Sharath Prasad
> <prasad.sharath at gmail.com> wrote:
> > Hello.
> >
> > I am trying to use a specific version of cmake (v2.8.8). I also need
> ccmake
> > (v2.8.8). I located the folders uploaded for this release. I plan to use
> it
> > on ubuntu. I downloaded cmake folders and extracted all the folders
> related
> > to Linux. However, only one folder has options to build from scratch.
> Other
> > folders have binaries that do not run on my machine.
> >
> > The folder that compiles from scratch cannot locate CURSES or NCURSES and
> > has trouble locating curses.h
> >
> > So ccmake does not work. If I install ccmake, it updates to the latest
> > version 2.8.12 or so.
> >
> > I need v2.8.8 specifically, Can you help?
> >
> >
> > Thanks,
> > Sharath
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/529abd02/attachment.html>

From foss at grueninger.de  Thu Jan 22 17:55:56 2015
From: foss at grueninger.de (=?UTF-8?B?Q2hyaXN0b3BoIEdyw7xuaW5nZXI=?=)
Date: Thu, 22 Jan 2015 23:55:56 +0100
Subject: [cmake-developers] FeatureSummary: Fix wrong bracket
Message-ID: <54C17FFC.5090808@grueninger.de>

Hi CMake developers,
please find attached a small patch to change a ] to a ).

Bye
Christoph

-- 
When you die, that does not mean that you lose to cancer,
you beat cancer by how you live, why you live, and in the
manner in which you live.      -- Stuart Scott, 1965-2015

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FeatureSummary-Fix-bracket-in-documentation.patch
Type: text/x-patch
Size: 1257 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150122/98a7c0f0/attachment.bin>

From mantis at public.kitware.com  Thu Jan 22 19:09:11 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 22 Jan 2015 19:09:11 -0500
Subject: [cmake-developers] [CMake 0015366]: set_source_files_properties
	OBJECT_DEPENDS broken after normalization
Message-ID: <3ad94b1fd0c7f632145cf51713010d5b@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15366 
====================================================================== 
Reported By:                Daniel v. Gerpen
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15366
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-22 19:09 EST
Last Modified:              2015-01-22 19:09 EST
====================================================================== 
Summary:                    set_source_files_properties OBJECT_DEPENDS broken
after normalization
Description: 
With cmake 2.8.9 (ubuntu repos) and cmake 3.0.2 (build locally) 
the attached project can be build.

[ 50%] Generating ../bla/stuff.h
Scanning dependencies of target app
[100%] Building CXX object blubb/CMakeFiles/app.dir/__/bla/a.cpp.o
Linking CXX executable app
[100%] Built target app

With 3.1 and 3.1.1 it fails because a custom command is not run:

Scanning dependencies of target app
make[2]: *** No rule to make target `blubb/../bla/stuff.h', needed by
`blubb/CMakeFiles/app.dir/__/bla/a.cpp.o'.  Stop.
make[1]: *** [blubb/CMakeFiles/app.dir/all] Error 2
make: *** [all] Error 2



Steps to Reproduce: 
tar zxf object_depends.tar.gz
cd object_depends
cmake .
make

Additional Information: 
https://github.com/Kitware/CMake/commit/c4af46 is the first commit
with this behavior, it introduced normalization of OUTPUT and
DEPENDS in add_custom_command. 

>From what I can see OBJECT_DEPENDS in set_source_file_properties
is not normalized.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-22 19:09 Daniel v. GerpenNew Issue                                    
2015-01-22 19:09 Daniel v. GerpenFile Added: object_depends.tar.gz              
     
======================================================================


From mantis at public.kitware.com  Thu Jan 22 23:04:43 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 22 Jan 2015 23:04:43 -0500
Subject: [cmake-developers] [CMake 0015367]: cmake crash in
	GetNumberOfFilesInDirectory
Message-ID: <27fe5e963d99eb49573bef1ea1ccecf5@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15367 
====================================================================== 
Reported By:                Thomas Klausner
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15367
Category:                   CMake
Reproducibility:            sometimes
Severity:                   crash
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-01-22 23:04 EST
Last Modified:              2015-01-22 23:04 EST
====================================================================== 
Summary:                    cmake crash in GetNumberOfFilesInDirectory
Description: 
In Source/kwsys/Directory.cxx, the result value of opendir() is not checked,
which can lead to readdir being called with a NULL pointer as first argument,
which, at least on NetBSD, leads to a segfault.

Steps to Reproduce: 
I don't know how to cause this, but it happened to me in parallel builds on a
tmpfs e.g. when building wesnoth.

Additional Information: 
The attached patch returns '0' as count for directories when opendir fails,
which makes wesnoth build for me. Perhaps dirp==NULL should be reported, but I
don't know how to best do that, so I'll leave that up to you.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-22 23:04 Thomas KlausnerNew Issue                                    
2015-01-22 23:04 Thomas KlausnerFile Added: patch-Source_kwsys_Directory.cxx    
               
======================================================================


From mantis at public.kitware.com  Fri Jan 23 01:18:51 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 23 Jan 2015 01:18:51 -0500
Subject: [cmake-developers] [CMake 0015368]: ExternalProject's BUILD_ALWAYS
	flag doesn't clear any existing build stamp file
Message-ID: <684be5903fab2e643df43562131ce88e@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15368 
====================================================================== 
Reported By:                peitschie
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15368
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-23 01:18 EST
Last Modified:              2015-01-23 01:18 EST
====================================================================== 
Summary:                    ExternalProject's BUILD_ALWAYS flag doesn't clear
any existing build stamp file
Description: 
Setting the BUILD_ALWAYS flag on an external project should cause the build step
to always trigger. This was new in 3.1 from what I can see. Unfortunately, it
appears to do this by making the *next* stamp file created symbolic (see
https://github.com/Kitware/CMake/blob/master/Modules/ExternalProject.cmake#L1457).
This means that until the existing stamp file is deleted, or something else
causes a rebuild to occur, BUILD_ALWAYS has no effect

Steps to Reproduce: 
1. Create a CMake file with an external project, with BUILD_ALWAYS set to 0
2. Build the external project
3. Change the BUILD_ALWAYS flag to 1
4. Attempt to rebuild the external project, and note how the build step is never
executed.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-23 01:18 peitschie      New Issue                                    
======================================================================


From brad.king at kitware.com  Fri Jan 23 09:04:07 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 23 Jan 2015 09:04:07 -0500
Subject: [cmake-developers] FeatureSummary: Fix wrong bracket
In-Reply-To: <54C17FFC.5090808@grueninger.de>
References: <54C17FFC.5090808@grueninger.de>
Message-ID: <54C254D7.5000104@kitware.com>

On 01/22/2015 05:55 PM, Christoph Gr?ninger wrote:
> please find attached a small patch to change a ] to a ).

Applied, thanks:

 FeatureSummary: Fix bracket in documentation.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b79d8f29

-Brad


From mantis at public.kitware.com  Fri Jan 23 14:32:03 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 23 Jan 2015 14:32:03 -0500
Subject: [cmake-developers] [CMake 0015369]: file(STRINGS file VAR) fails to
	read entire file
Message-ID: <ff4b64e43611b2c2e1e3b45dfa409ab0@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15369 
====================================================================== 
Reported By:                Joakim S?derberg
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15369
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-01-23 14:32 EST
Last Modified:              2015-01-23 14:32 EST
====================================================================== 
Summary:                    file(STRINGS file VAR) fails to read entire file
Description: 
I am experiencing some weird issues with file(STRINGS. 

It fails to read my entire file. The file is 2529 lines long, but CMake only
read 1885. Or well it reads the entire file, but then stops splitting it up into
lines, instead the last list entry consists of all the lines between 1885-2529.

Steps to Reproduce: 
cmake -DFILE=thefile.gcov -P testscript.cmake


testscript:

file(STRINGS ${FILE} LIST)
list(LENGTH LIST LIST_COUNT)
message("${LIST_COUNT}")

Additional Information: 
I have not been able to test with a later CMake yet. But I hope there is some
workaround for this for older versions as well.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-23 14:32 Joakim S?derbergNew Issue                                    
2015-01-23 14:32 Joakim S?derbergFile Added: thefile.gcov                     
======================================================================


From brad.king at kitware.com  Fri Jan 23 15:04:58 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 23 Jan 2015 15:04:58 -0500
Subject: [cmake-developers] Introduction and volunteering for the Matlab
 package
In-Reply-To: <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
 <54C129FB.3070102@kitware.com> <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>
Message-ID: <54C2A96A.3060100@kitware.com>

On 01/22/2015 11:50 AM, Raffi Enficiaud wrote:
> I can also do a pull request if you prefer, 

As described in CONTRIBUTING.rst a patch here is preferred.

I've fetched your branch from https://github.com/raffienficiaud/CMake
Here are some comments.

Please wrap text in the documentation blocks of the FindMatlab
module to fit in 79 columns.

> #    find_package(Matlab
> #                 [VERSION]
> #                 [REQUIRED]
> #                 [COMPONENTS component1 [component2]])

Individual find modules don't need to summarize the find_package
signature.  Documentation of components and versions can just
refer to the :command:`find_package` command and name the options.

> # .. note:
> #
> # The version above is the Matlab version...

The note text needs to be indented to be part of the note.  The same
goes for all the variable and command documentation inside explicit
markup directives like ".. variable::" and ".. command::".

> # User defined variables
> # ----------------------

This section should be called something like "Module Input Variables"
and have intro wording like "Users or projects may set the following
variables to configure this module behavior.".

> # Variables defined by the module
> # -------------------------------

This section should distinguish between cache entries and output
variables.  See FindJsonCpp for an example.

> # Provided macros
> # ---------------

Generally we try to use functions with "set(... PARENT_SCOPE)".

Also on the endmacro() and endfunction() calls please drop the
command name.

> # WARNING: this thing pollutes the CMAKE_FIND_LIBRARY_PREFIXES global variable. 
> # Should it be restored afterwards? Is there a more appropriate way to do that?
> set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES} ${_matlab_lib_prefix_for_search})

This should be handled with a save/restore.

> # The function arguments are:

Please use definition lists instead of bullet lists for function
argument documentation.

The copyright year should be 2014-2015 since we've spilled into
that range.  There is no need for copyright notices in the
Tests/RunCMake test cmake code because there no creative input
in that boilerplate.

Please remove all trailing whitespace and make sure the files are
committed with LF newlines and not CRLF newlines (including tests).
Also make sure all files end in a newline (but not trailing blank
lines).

Thanks,
-Brad


From brad.king at kitware.com  Fri Jan 23 16:38:08 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 23 Jan 2015 16:38:08 -0500
Subject: [cmake-developers] Adding an option for relative compiler
	invocations
In-Reply-To: <54C0C700.5010801@ensslin.cc>
References: <54C0C700.5010801@ensslin.cc>
Message-ID: <54C2BF40.7050307@kitware.com>

On 01/22/2015 04:46 AM, Michael En?lin wrote:
> (1.2) Using compile-time string manipulations to sanitize the filename.
>       Due to limitations of C++, this requires template metaprogramming,
>       leading to unreasonable complexity and compile times.

See below.

> Over the last several decades, at least on the POSIX platform, it has
> become common practice to invoke compilers with relative file paths

This is only true for in-source builds.  CMake recommends out-of-source,
and then full paths are much more reliable.  Even if one used relative
paths then your messages would still have a bunch of "../" in them for
an out-of-source build.  Therefore I'll assume you're using in-source
builds.

Side note: To make relative paths behave right with __FILE__ you would
also need all include paths (-I) to be relative.  Otherwise headers will
still get full paths.  This would require much more work than just
trying to get compile lines to refer to source files with a relative
path.

So, assuming you have an in-source build then all sources and headers
must sit under a single prefix (the top of the source tree).  With that
you can do something like:

 string(LENGTH "${CMAKE_SOURCE_DIR}/" SRC_DIR_LEN)
 add_definitions(-DSRC_DIR_LEN=${SRC_DIR_LEN})

and then in the source code do:

 #define MY__FILE__ (__FILE__+SRC_DIR_LEN)

That will give you a compile-time constant __FILE__ with a relative path
and no runtime overhead.  Use MY__FILE__ in your log macros.

-Brad


From michael at ensslin.cc  Fri Jan 23 17:44:07 2015
From: michael at ensslin.cc (=?windows-1252?Q?Michael_En=DFlin?=)
Date: Fri, 23 Jan 2015 23:44:07 +0100
Subject: [cmake-developers] Adding an option for relative compiler
	invocations
In-Reply-To: <54C2BF40.7050307@kitware.com>
References: <54C0C700.5010801@ensslin.cc> <54C2BF40.7050307@kitware.com>
Message-ID: <54C2CEB7.9090609@ensslin.cc>

Hi,

thanks for your reply.

I am using an out-of-source build, and my build system even contains
rules to explicitly prohibit in-source builds.

To make __FILE__ behave correctly, you'd have to invoke the compiler
with a different cwd.

A generated line in build.make, which currently looks like this:

cd /home/mic/git/openage/.bin/gcc-release-O2/cpp && /usr/bin/g++
$(CXX_DEFINES) $(CXX_FLAGS) -o CMakeFiles/openage.dir/engine.cpp.o -c
/home/mic/git/openage/cpp/engine.cpp

would need to be changed to

cd /home/mic/git/openage && /usr/bin/g++ $(CXX_DEFINES) $(CXX_FLAGS) -o
/home/mic/git/openage/.bin/gcc-release-O2/cpp/CMakeFiles/openage.dir/engine.cpp.o
-c cpp/engine.cpp

The solution I'm currently using is similar to the one you're
suggesting; note that your suggestion can lead to misleading debug
messages or even undefined behavior in the event that __FILE__ does not
start with CMAKE_SOURCE_DIR for whatever reason.

I'm not using any non-library include paths, so the include issue
doesn't apply to my.

~ Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150123/736e1e97/attachment.sig>

From mantis at public.kitware.com  Fri Jan 23 19:18:49 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 23 Jan 2015 19:18:49 -0500
Subject: [cmake-developers] [CMake 0015370]: find_path MinGW not working
	while find_library does
Message-ID: <f3cc769cd7ea3e201569745d46cc96cb@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15370 
====================================================================== 
Reported By:                Lectem
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15370
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-23 19:18 EST
Last Modified:              2015-01-23 19:18 EST
====================================================================== 
Summary:                    find_path MinGW not working while find_library does
Description: 
I couldn't get most of my libraries detected with find_package.
I figured out that the libraries files were found but not the headers.

For example :

find_path(GLEW_INCLUDE_DIR GL/glew.h)
will not work while
find_library(GLEW_LIBRARY glew32)
does.


FIND_PACKAGE(GLEW)

Does also set GLEW_LIBRARY and GLEW_LIBRARIES but not GLEW_INCLUDE_DIR.

Steps to Reproduce: 
FIND_PACKAGE(GLEW)
IF(GLEW_FOUND)
  MESSAGE(STATUS "GLEW found.")
  MESSAGE(STATUS "Detected GLEW path is : ${GLEW_LIBRARIES}")
ENDIF(GLEW_FOUND)
IF(GLEW_LIBRARIES)
  MESSAGE(STATUS "Detected GLEW_LIBRARIES path is : ${GLEW_LIBRARIES}")
ENDIF(GLEW_LIBRARIES)
IF(GLEW_INCLUDE_DIRS)
  MESSAGE(STATUS "Detected GLEW_INCLUDE_DIRS path is : ${GLEW_INCLUDE_DIRS}")
ELSE(GLEW_INCLUDE_DIRS)
  MESSAGE(STATUS "Couldn't find GLEW_INCLUDE_DIRS")
ENDIF(GLEW_INCLUDE_DIRS)
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-23 19:18 Lectem         New Issue                                    
======================================================================


From raffi.enficiaud at free.fr  Fri Jan 23 19:52:02 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Sat, 24 Jan 2015 01:52:02 +0100
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
In-Reply-To: <54C2A96A.3060100@kitware.com>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
 <54C129FB.3070102@kitware.com> <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>
 <54C2A96A.3060100@kitware.com>
Message-ID: <022001d0376f$f87f3c50$e97db4f0$@enficiaud@free.fr>

I believe I addressed all the raised issues, apart from this one:

> > # WARNING: this thing pollutes the CMAKE_FIND_LIBRARY_PREFIXES global
variable. 
> > # Should it be restored afterwards? Is there a more appropriate way to
do that?
> > set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES} 
> > ${_matlab_lib_prefix_for_search})

> This should be handled with a save/restore.

Are you referring to the CMakePushCheckState ? If so, please correct me but
the documentation does not state that it stores the value of
CMAKE_FIND_LIBRARY_PREFIXES. 

Tests still ok. Patch attached.

Regards,
Raffi Enficiaud

-----Message d'origine-----
De?: Brad King [mailto:brad.king at kitware.com] 
Envoy??: vendredi 23 janvier 2015 21:05
??: Raffi Enficiaud
Cc?: cmake-developers at cmake.org
Objet?: Re: [cmake-developers] Introduction and volunteering for the Matlab
package

On 01/22/2015 11:50 AM, Raffi Enficiaud wrote:
> I can also do a pull request if you prefer,

As described in CONTRIBUTING.rst a patch here is preferred.

I've fetched your branch from https://github.com/raffienficiaud/CMake
Here are some comments.

Please wrap text in the documentation blocks of the FindMatlab module to fit
in 79 columns.

> #    find_package(Matlab
> #                 [VERSION]
> #                 [REQUIRED]
> #                 [COMPONENTS component1 [component2]])

Individual find modules don't need to summarize the find_package signature.
Documentation of components and versions can just refer to the
:command:`find_package` command and name the options.

> # .. note:
> #
> # The version above is the Matlab version...

The note text needs to be indented to be part of the note.  The same goes
for all the variable and command documentation inside explicit markup
directives like ".. variable::" and ".. command::".

> # User defined variables
> # ----------------------

This section should be called something like "Module Input Variables"
and have intro wording like "Users or projects may set the following
variables to configure this module behavior.".

> # Variables defined by the module
> # -------------------------------

This section should distinguish between cache entries and output variables.
See FindJsonCpp for an example.

> # Provided macros
> # ---------------

Generally we try to use functions with "set(... PARENT_SCOPE)".

Also on the endmacro() and endfunction() calls please drop the command name.

> # WARNING: this thing pollutes the CMAKE_FIND_LIBRARY_PREFIXES global
variable. 
> # Should it be restored afterwards? Is there a more appropriate way to do
that?
> set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES} 
> ${_matlab_lib_prefix_for_search})

This should be handled with a save/restore.

> # The function arguments are:

Please use definition lists instead of bullet lists for function argument
documentation.

The copyright year should be 2014-2015 since we've spilled into that range.
There is no need for copyright notices in the Tests/RunCMake test cmake code
because there no creative input in that boilerplate.

Please remove all trailing whitespace and make sure the files are committed
with LF newlines and not CRLF newlines (including tests).
Also make sure all files end in a newline (but not trailing blank lines).

Thanks,
-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: findmatlab.patch
Type: application/octet-stream
Size: 257001 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150124/b84419c5/attachment-0001.obj>

From steveire at gmail.com  Sat Jan 24 10:05:36 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 24 Jan 2015 16:05:36 +0100
Subject: [cmake-developers] Generator Expressions and packages
	(Was:	target_link_libraries and --start-group/--end-group ?)
References: <B690D45ED8AB4146AE3D908EB41D0DA121DEF147@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFzjYVqotS3i8M_VJLW2i8OR5a5YLQUvFisTxk0eu9eMOMp5WQ@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF00C8@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <CAFdhTuPvU=tN79sTr7HkNRERQUDKKOz+1W-CxAkTyLO+AcwHNw@mail.gmail.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF2B12@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B3CBA3.4000703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF51A7@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54B40D0C.5070009@kitware.com>
 <c0f9ff7f3cc04901b466223d8360d3db@UKMAIL102.nvidia.com>
 <54B5275F.5070502@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121DF60FE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <m947c1$pou$2@ger.gmane.org>
 <B690D45ED8AB4146AE3D908EB41D0DA121E063D1@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <ma0cc1$14a$1@ger.gmane.org>

Robert Goulet wrote:

> To be honest I haven't spent much time trying to learn 'imported'
> libraries with CMake. It was already difficult to deal with commands that
> don't support generator expressions versus those that does. It wasn't
> clear which commands we should not try to use because of that, and in the
> end we had to rewrite part of the CMakeLists.txt file because we wanted to
> use generator expressions and packages.

The commands which accept generator expressions document that they support 
generator expressions. I'm not aware of any gaps there.

I have had a note locally to add more-comprehensive linking in the other 
direction from 

 http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html

but it's not done yet.

Thanks for the feedback!

Steve.



From alex.merry at kde.org  Sat Jan 24 10:29:51 2015
From: alex.merry at kde.org (Alex Merry)
Date: Sat, 24 Jan 2015 15:29:51 +0000
Subject: [cmake-developers] Improving Vim support in CMake
In-Reply-To: <20150121211735.GA32290@megas.kitwarein.com>
References: <20150121211735.GA32290@megas.kitwarein.com>
Message-ID: <3007201.OrQ5ITbOiW@kyoshi>

On Wednesday 21 January 2015 16:17:35 Ben Boeckel wrote:
> List of improvements to the syntax file:
> 
>   - drop support for < 7.0 (which is 7.5 years old now);
>   - add support for Lua-style comments;
>   - update the list of system variables;
>   - update the list of operators;
>   - make only commands case-insensitive;
>   - update the list of built-in commands (and deprecated ones);
>   - highlight user-defined function and macro calls; and
>   - tweak colors a bit.

Much needed, especially updating the list of commands and operators, thanks!

However, I'm missing having variables highlighted in a different colour, 
especially when they appear in strings. Also, do you know if it's possible to 
make command and operator highlighting context-sensitive? For example, in 
add_command(COMMAND foo), COMMAND is highlighted because it is in the list of 
operators, and I've got a command that takes a LINK_LIBRARIES keyword 
argument, which is highlighted as a deprecated command.

Alex

From joubert.sy at gmail.com  Sat Jan 24 14:02:09 2015
From: joubert.sy at gmail.com (Sylvain Joubert)
Date: Sat, 24 Jan 2015 20:02:09 +0100
Subject: [cmake-developers] [patch] Configure some targets with USES_TERMINAL
Message-ID: <54C3EC31.8010805@gmail.com>

Hi all,

Please find attached a patch that adds the USES_TERMINAL configuration 
to some targets.

These targets are good candidates to use the Ninja 'console' pool since 
they are likely to be built on their own and may take some time to complete.

Sylvain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Configure-some-targets-with-USES_TERMINAL.patch
Type: text/x-patch
Size: 5040 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150124/716872c7/attachment.bin>

From tobias.hunger at gmail.com  Sun Jan 25 08:26:02 2015
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Sun, 25 Jan 2015 14:26:02 +0100
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <m8rqmv$kk2$1@ger.gmane.org>
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
 <loom.20150108T174009-382@post.gmane.org>
 <CACcA1RrNT9-B_n7=TobM=MQ39eiiDczaByE5ZmNzEd2drMsSfw@mail.gmail.com>
 <m8rqmv$kk2$1@ger.gmane.org>
Message-ID: <CAMdWP3GJhXWM1dtzBiA48OFrSOqc_AaS-wP3+qZAyCNJKqsoJQ@mail.gmail.com>

Hi Everybody,

I just had a bit of time to play with cmake this weekend: Is this
patch available somewhere by now?

Best Regards,
Tobias


On Sat, Jan 10, 2015 at 7:23 PM, Stephen Kelly <steveire at gmail.com> wrote:
> Aleix Pol wrote:
>
>> I'll attach it in this e-mail, to make sure it reaches.
>>
>> PS: there's no changes system for cmake  like reviewboard, is there?
>
> Nope, review is communicated on the mailing list, but if you want you can
> push the patch on a branch in a public repo. It could be more convenient.
>
> Thanks,
>
> Steve.
>
>
> --
>
> 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

From foss at grueninger.de  Sun Jan 25 17:03:05 2015
From: foss at grueninger.de (=?UTF-8?B?Q2hyaXN0b3BoIEdyw7xuaW5nZXI=?=)
Date: Sun, 25 Jan 2015 23:03:05 +0100
Subject: [cmake-developers] Clarify status of link_libraries
Message-ID: <54C56819.4090909@grueninger.de>

Hi CMake developers,

we wanted to use the link_libraries command and we were scared off by
its deprecation. Fortunately someone found Brad's statement [1] about
the "deprecated".
The use of deprecated is pretty bad as this usually indicates that a
feature will be removed in future versions. I understand that the
command should be avoided if possible.

I tried to clarify the documentation with the attached patch. It uses
Sphinx' note command to emphasis using target_link_libraries.

Bye
Christoph

[1] http://www.cmake.org/pipermail/cmake/2009-April/028439.html

-- 
When you die, that does not mean that you lose to cancer,
you beat cancer by how you live, why you live, and in the
manner in which you live.      -- Stuart Scott, 1965-2015

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-link_libraries.rst-Clarify-status-of-command.patch
Type: text/x-patch
Size: 1263 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150125/5feab2c7/attachment.bin>

From mantis at public.kitware.com  Mon Jan 26 04:17:30 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 26 Jan 2015 10:17:30 +0100
Subject: [cmake-developers] [CMake 0015371]: Different components for
	library and link using just one install command
Message-ID: <23a3f30778e0e5ba0eacc4a4cb1e8a75@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15371 
====================================================================== 
Reported By:                Daniele E. Domenichelli
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15371
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-26 10:17 CET
Last Modified:              2015-01-26 10:17 CET
====================================================================== 
Summary:                    Different components for library and link using just
one install command
Description: 
When a library with a SOVERSION is created, the only way to install the library
and the links to the library with a different component is installing the target
twice using NAMELINK_SKIP and NAMELINK_ONLY. For example

  add_library(foo ${foo_SRCS})
  set_target_properties(foo PROPERTIES SOVERSION 1)
  install(TARGETS foo
          LIBRARY DESTINATION lib COMPONENT library NAMELINK_SKIP)
  install(TARGETS foo
          LIBRARY DESTINATION lib COMPONENT devel NAMELINK_ONLY)

This is redundant and not intuitive, it would be useful to be able to do this in
just one command, for example:

  install(TARGETS foo
          LIBRARY DESTINATION lib COMPONENT library
                                  NAMELINK_COMPONENT devel)


Additional Information: 
Mailing list thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12023
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-26 10:17 Daniele E. DomenichelliNew Issue                               
    
======================================================================


From brad.king at kitware.com  Mon Jan 26 08:41:47 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 08:41:47 -0500
Subject: [cmake-developers] Adding an option for relative compiler
	invocations
In-Reply-To: <54C2CEB7.9090609@ensslin.cc>
References: <54C0C700.5010801@ensslin.cc> <54C2BF40.7050307@kitware.com>
 <54C2CEB7.9090609@ensslin.cc>
Message-ID: <54C6441B.6080206@kitware.com>

On 01/23/2015 05:44 PM, Michael En?lin wrote:
> cd /home/mic/git/openage && /usr/bin/g++ $(CXX_DEFINES) $(CXX_FLAGS) -o
> /home/mic/git/openage/.bin/gcc-release-O2/cpp/CMakeFiles/openage.dir/engine.cpp.o
> -c cpp/engine.cpp

Invoking the compiler inside the source tree is not an option.  Many
compilers leave around extra files as side-effects and we cannot allow
them to pollute the source tree in an out-of-source build.

I don't think getting a relative __FILE__ is a realistic option with
CMake.

-Brad


From brad.king at kitware.com  Mon Jan 26 08:43:53 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 08:43:53 -0500
Subject: [cmake-developers] Introduction and volunteering for the Matlab
 package
In-Reply-To: <54c2ecb9.6308b40a.75ff.ffffa484SMTPIN_ADDED_BROKEN@mx.google.com>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
 <54C129FB.3070102@kitware.com> <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>
 <54C2A96A.3060100@kitware.com>
 <54c2ecb9.6308b40a.75ff.ffffa484SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <54C64499.3050707@kitware.com>

On 01/23/2015 07:52 PM, Raffi Enficiaud wrote:
>> This should be handled with a save/restore.
> 
> Are you referring to the CMakePushCheckState?

No, CMAKE_FIND_LIBRARY_PREFIXES should be saved/restored manually
with code in the Find module around the find_library calls.  You
could also create a _Matlab_find_library function that sets
CMAKE_FIND_LIBRARY_PREFIXES and calls find_library.  The setting
would go out of scope when the function returns.  See the FindBoost
module for a similar example.

-Brad


From brad.king at kitware.com  Mon Jan 26 09:17:21 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 09:17:21 -0500
Subject: [cmake-developers] Clarify status of link_libraries
In-Reply-To: <54C56819.4090909@grueninger.de>
References: <54C56819.4090909@grueninger.de>
Message-ID: <54C64C71.6000608@kitware.com>

On 01/25/2015 05:03 PM, Christoph Gr?ninger wrote:
> we wanted to use the link_libraries command and we were scared off by
> its deprecation. Fortunately someone found Brad's statement [1] about
> the "deprecated".

Thanks.  I never updated the docs after sending that message.

Inspired by your patch I've revised the documentation:

 Help: Clarify status of link_libraries command
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c7310917

Thanks,
-Brad


From brad.king at kitware.com  Mon Jan 26 10:23:59 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 10:23:59 -0500
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <CAMdWP3GJhXWM1dtzBiA48OFrSOqc_AaS-wP3+qZAyCNJKqsoJQ@mail.gmail.com>
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
 <loom.20150108T174009-382@post.gmane.org>
 <CACcA1RrNT9-B_n7=TobM=MQ39eiiDczaByE5ZmNzEd2drMsSfw@mail.gmail.com>
 <m8rqmv$kk2$1@ger.gmane.org>
 <CAMdWP3GJhXWM1dtzBiA48OFrSOqc_AaS-wP3+qZAyCNJKqsoJQ@mail.gmail.com>
Message-ID: <54C65C0F.9090902@kitware.com>

On 01/25/2015 08:26 AM, Tobias Hunger wrote:
> I just had a bit of time to play with cmake this weekend: Is this
> patch available somewhere by now?

Aleix sent it in a message of this thread on 2015-01-09:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061

Some review comments elsewhere in this thread are still pending.

-Brad


From brad.king at kitware.com  Mon Jan 26 10:25:49 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 10:25:49 -0500
Subject: [cmake-developers] [patch] Configure some targets with
	USES_TERMINAL
In-Reply-To: <54C3EC31.8010805@gmail.com>
References: <54C3EC31.8010805@gmail.com>
Message-ID: <54C65C7D.2000602@kitware.com>

On 01/24/2015 02:02 PM, Sylvain Joubert wrote:
> Please find attached a patch that adds the USES_TERMINAL configuration 
> to some targets.

Very nice.  This finishes addressing an issue tracker entry:

 cmake should support ninja's "console" pool
 http://www.cmake.org/Bug/view.php?id=14915

Applied:

 Configure some CMake-provided targets with USES_TERMINAL (#14915)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=148ad4b3

Thanks,
-Brad


From ben.boeckel at kitware.com  Mon Jan 26 11:00:05 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 26 Jan 2015 11:00:05 -0500
Subject: [cmake-developers] Improving Vim support in CMake
In-Reply-To: <3007201.OrQ5ITbOiW@kyoshi>
References: <20150121211735.GA32290@megas.kitwarein.com>
 <3007201.OrQ5ITbOiW@kyoshi>
Message-ID: <20150126160005.GB12746@megas.kitwarein.com>

On Sat, Jan 24, 2015 at 15:29:51 +0000, Alex Merry wrote:
> On Wednesday 21 January 2015 16:17:35 Ben Boeckel wrote:
> > List of improvements to the syntax file:
> > 
> >   - drop support for < 7.0 (which is 7.5 years old now);
> >   - add support for Lua-style comments;
> >   - update the list of system variables;
> >   - update the list of operators;
> >   - make only commands case-insensitive;
> >   - update the list of built-in commands (and deprecated ones);
> >   - highlight user-defined function and macro calls; and
> >   - tweak colors a bit.
> 
> Much needed, especially updating the list of commands and operators, thanks!
> 
> However, I'm missing having variables highlighted in a different colour, 
> especially when they appear in strings.

Odd; attached is an HTML dump from Vim for what I see (:TOhtml) where
variable expansions are highlighted in strings just like outside of
strings.

>                                         Also, do you know if it's possible to 
> make command and operator highlighting context-sensitive? For example, in 
> add_command(COMMAND foo), COMMAND is highlighted because it is in the list of 
> operators, and I've got a command that takes a LINK_LIBRARIES keyword 
> argument, which is highlighted as a deprecated command.

The problem is that they are keywords right now. I'll take a stab at
making it a regex instead so it can be properly contained within other
groupings.

Thanks for testing :) .

--Ben

From ben.boeckel at kitware.com  Mon Jan 26 11:00:44 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 26 Jan 2015 11:00:44 -0500
Subject: [cmake-developers] Improving Vim support in CMake
In-Reply-To: <20150126160005.GB12746@megas.kitwarein.com>
References: <20150121211735.GA32290@megas.kitwarein.com>
 <3007201.OrQ5ITbOiW@kyoshi>
 <20150126160005.GB12746@megas.kitwarein.com>
Message-ID: <20150126160044.GC12746@megas.kitwarein.com>

On Mon, Jan 26, 2015 at 11:00:05 -0500, Ben Boeckel wrote:
> Odd; attached is an HTML dump from Vim for what I see (:TOhtml) where
> variable expansions are highlighted in strings just like outside of
> strings.

Probably help if I actually attached the file :/ .

--Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150126/3c535c9a/attachment-0001.html>

From kainjow at kainjow.com  Mon Jan 26 11:01:31 2015
From: kainjow at kainjow.com (Kevin Wojniak)
Date: Mon, 26 Jan 2015 08:01:31 -0800
Subject: [cmake-developers] Patch for some GUI Mac fixes
Message-ID: <732A883B-4B08-403D-9AEA-480D8B91F22D@kainjow.com>

These 3 patches fix the Install menu not showing for Qt5 builds, the Install buttons not behaving like the other (standard) buttons, and fixes the search field not being shown on OS X when the window is at minimum size.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gui-mac.patch
Type: application/octet-stream
Size: 3329 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150126/8833b653/attachment.obj>
-------------- next part --------------


Kevin


From brad.king at kitware.com  Mon Jan 26 11:41:54 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 11:41:54 -0500
Subject: [cmake-developers] CMake 3.2 feature freeze on 2015-02-02
In-Reply-To: <5498373B.9070308@kitware.com>
References: <5498373B.9070308@kitware.com>
Message-ID: <54C66E52.9060504@kitware.com>

On 12/22/2014 10:22 AM, Brad King wrote:
> The feature freeze in 'master' for CMake 3.2 will be on Feb 2, 2015.
> I will announce a freeze in 'next' sometime in the preceding week so
> that we can get any remaining dashboard trouble cleaned up.
> 
> Please schedule any planned topics accordingly.  Any major or disruptive
> changes should be completed a few weeks prior to the freeze or delayed
> until after 'next' re-opens.

In preparation for this freeze to 'master' next week, I'm now freezing
'next' to new features.  We should work to get topics already in 'next'
through to 'master' within the next week.  Documentation and bug fix
topics may still of course be added to 'next'.

Thanks,
-Brad

From Robert.Goulet at autodesk.com  Mon Jan 26 12:20:24 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Mon, 26 Jan 2015 17:20:24 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl files?
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi all,

Any reasons why setting additional compile flags on .hlsl files would not work?

I tried this:

set_source_files_properties(${SHADER_FILE} PROPERTIES COMPILE_FLAGS "/I${CMAKE_SOURCE_DIR}/src")

...and it didn't get written to the .vcxproj file at all. In this specific case, I want to add include directories when I build this .hlsl shader. Is it correct to assume that it should have passed the additional flag to this file? Or maybe there's another way to do this? Thanks.



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616
DIRECT +1 514 954 3911
MOBILE +1 438 397 4075

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com<http://www.autodesk.com/>

[Description: Email_Signature_Logobar]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150126/14eadbaa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150126/14eadbaa/attachment-0001.jpg>

From clinton at elemtech.com  Mon Jan 26 11:29:37 2015
From: clinton at elemtech.com (Clinton Stimpson)
Date: Mon, 26 Jan 2015 09:29:37 -0700
Subject: [cmake-developers] Patch for some GUI Mac fixes
In-Reply-To: <732A883B-4B08-403D-9AEA-480D8B91F22D@kainjow.com>
References: <732A883B-4B08-403D-9AEA-480D8B91F22D@kainjow.com>
Message-ID: <1438981.B3zSvZA5cH@stryke>

On Monday, January 26, 2015 08:01:31 AM Kevin Wojniak wrote:
> These 3 patches fix the Install menu not showing for Qt5 builds, the Install
> buttons not behaving like the other (standard) buttons, and fixes the
> search field not being shown on OS X when the window is at minimum size.

Thanks for the patches!

They have been applied:

http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8ced6375
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b46a1519
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=c19539c5

Clint

From brad.king at kitware.com  Mon Jan 26 12:42:44 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 12:42:44 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C67C94.8030103@kitware.com>

On 01/26/2015 12:20 PM, Robert Goulet wrote:
> set_source_files_properties(${SHADER_FILE} PROPERTIES COMPILE_FLAGS "/I${CMAKE_SOURCE_DIR}/src")
> and it didn't get written to the .vcxproj file at all.

Right now .hlsl files are written by

 cmVisualStudio10TargetGenerator::WriteExtraSource

because they are (perhaps incorrectly) not classified as
compiled sources.  Look at use of GetObjectSources in
cmVisualStudio10TargetGenerator::WriteAllSources for where
compiled sources get handled.  The OutputSourceSpecificFlags
method handles source-specific COMPILE_FLAGS.

The reason .hlsl files are not classified as compiled sources
is because HLSL is not a first-class language in CMake that
one enables via enable_language().  This also prevents them
from being handled by non-VS generators.  If you are
interested in working on making HLSL a first-class language
I can help you get started.

-Brad


From Robert.Goulet at autodesk.com  Mon Jan 26 13:04:21 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Mon, 26 Jan 2015 18:04:21 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C67C94.8030103@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>

Do we really need to go down the road of making hlsl a 'first-class' language to add support for additional compile flags?

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, January 26, 2015 12:43 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/26/2015 12:20 PM, Robert Goulet wrote:
> set_source_files_properties(${SHADER_FILE} PROPERTIES COMPILE_FLAGS 
> "/I${CMAKE_SOURCE_DIR}/src") and it didn't get written to the .vcxproj file at all.

Right now .hlsl files are written by

 cmVisualStudio10TargetGenerator::WriteExtraSource

because they are (perhaps incorrectly) not classified as compiled sources.  Look at use of GetObjectSources in cmVisualStudio10TargetGenerator::WriteAllSources for where compiled sources get handled.  The OutputSourceSpecificFlags method handles source-specific COMPILE_FLAGS.

The reason .hlsl files are not classified as compiled sources is because HLSL is not a first-class language in CMake that one enables via enable_language().  This also prevents them from being handled by non-VS generators.  If you are interested in working on making HLSL a first-class language I can help you get started.

-Brad


From brad.king at kitware.com  Mon Jan 26 13:07:46 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 13:07:46 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C68272.8040505@kitware.com>

On 01/26/2015 01:04 PM, Robert Goulet wrote:
> Do we really need to go down the road of making hlsl a 'first-class'
> language to add support for additional compile flags?

Right now the Visual Studio generator has custom logic for .hlsl
sources, so the rest of CMake knows nothing about them and treats
them like .txt files.  So, one could either add more custom logic
to the VS .hlsl support to honor COMPILE_FLAGS, or add the needed
infrastructure for enable_language(HLSL).  The latter approach
is much more general.

-Brad


From mantis at public.kitware.com  Mon Jan 26 13:10:55 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 26 Jan 2015 13:10:55 -0500
Subject: [cmake-developers] [CMake 0015372]: CMAKE_Fortran_COMPILER_VERSION
	is never set but FindOpenMP.cmake depends on it
Message-ID: <ec320d8e3ff093dd71e5caa8e5b35b75@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15372 
====================================================================== 
Reported By:                Kelly Thompson
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15372
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-26 13:10 EST
Last Modified:              2015-01-26 13:10 EST
====================================================================== 
Summary:                    CMAKE_Fortran_COMPILER_VERSION is never set but
FindOpenMP.cmake depends on it
Description: 
I am trying to use FindOpenMP.cmake provided by cmake/3.1.1 but it is returning
the wrong value for ${OpenMP_Fortran_FLAGS} because the value of
CMAKE_Fortran_COMPILER_VERSION is never set by CMake. 

When using ifort 15, FindOpenMP returns the deprecated value for older versions
of ifort (ver < 15.0.0.20140528).

Steps to Reproduce: 
The missing value for CMAKE_Fortran_COMPILER_VERSION does not appear to depend
on the compiler chosen.  Running cmake with the CMakeLists.txt provided below
shows that the value is blank:

cmake_minimum_required(VERSION 3.1)
project(nofortranver CXX Fortran)
find_package(OpenMP)
message("
CMAKE_Fortran_COMPILER_ID      = ${CMAKE_Fortran_COMPILER_ID}
CMAKE_Fortran_COMPILER_VERSION = ${CMAKE_Fortran_COMPILER_VERSION}
")

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-26 13:10 Kelly Thompson New Issue                                    
======================================================================


From Robert.Goulet at autodesk.com  Mon Jan 26 13:10:55 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Mon, 26 Jan 2015 18:10:55 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C68272.8040505@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>

Considering HLSL is DirectX only, I don't think we need (yet) to add it as a first-class language. And also because of time constraints, I might just go and add the COMPILE_FLAGS into the custom logic. I will send a patch when I can. Thanks!

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, January 26, 2015 1:08 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/26/2015 01:04 PM, Robert Goulet wrote:
> Do we really need to go down the road of making hlsl a 'first-class'
> language to add support for additional compile flags?

Right now the Visual Studio generator has custom logic for .hlsl sources, so the rest of CMake knows nothing about them and treats them like .txt files.  So, one could either add more custom logic to the VS .hlsl support to honor COMPILE_FLAGS, or add the needed infrastructure for enable_language(HLSL).  The latter approach is much more general.

-Brad


From brad.king at kitware.com  Mon Jan 26 13:23:20 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 13:23:20 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C68618.90602@kitware.com>

On 01/26/2015 01:10 PM, Robert Goulet wrote:
> I might just go and add the COMPILE_FLAGS into the custom logic.

Okay.  Look at the OutputSourceSpecificFlags logic as a reference.

-Brad


From Robert.Goulet at autodesk.com  Mon Jan 26 14:28:37 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Mon, 26 Jan 2015 19:28:37 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C68618.90602@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>

Here's a patch for adding additional compile flags to .hlsl files in Visual Studio. For this I simply added the new VS_SHADER_FLAGS source file property and basically did the same as other VS_SHADER_* properties. Tested in my project and it works. Please consider merging in master.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, January 26, 2015 1:23 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/26/2015 01:10 PM, Robert Goulet wrote:
> I might just go and add the COMPILE_FLAGS into the custom logic.

Okay.  Look at the OutputSourceSpecificFlags logic as a reference.

-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_vs_shader_flags_property.patch
Type: application/octet-stream
Size: 1890 bytes
Desc: add_vs_shader_flags_property.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150126/77a6a222/attachment-0001.obj>

From raffi.enficiaud at free.fr  Mon Jan 26 14:29:43 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Mon, 26 Jan 2015 20:29:43 +0100
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
In-Reply-To: <54C64499.3050707@kitware.com>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
 <54C129FB.3070102@kitware.com> <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>
 <54C2A96A.3060100@kitware.com>
 <54c2ecb9.6308b40a.75ff.ffffa484SMTPIN_ADDED_BROKEN@mx.google.com>
 <54C64499.3050707@kitware.com>
Message-ID: <98EDE7BE-00E7-4EFE-8D74-E51F41B49535@free.fr>

Dear Brad,

I addressed your proposed solution and sent you a patch, that is pending approval since this afternoon because of a size exceeding 300KB.

Best regards,
Raffi Enficiaud

> On 26 Jan 2015, at 14:43, Brad King <brad.king at kitware.com> wrote:
> 
> On 01/23/2015 07:52 PM, Raffi Enficiaud wrote:
>>> This should be handled with a save/restore.
>> 
>> Are you referring to the CMakePushCheckState?
> 
> No, CMAKE_FIND_LIBRARY_PREFIXES should be saved/restored manually
> with code in the Find module around the find_library calls.  You
> could also create a _Matlab_find_library function that sets
> CMAKE_FIND_LIBRARY_PREFIXES and calls find_library.  The setting
> would go out of scope when the function returns.  See the FindBoost
> module for a similar example.
> 
> -Brad
> 


From brad.king at kitware.com  Mon Jan 26 15:09:15 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jan 2015 15:09:15 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C69EEB.3050008@kitware.com>

On 01/26/2015 02:28 PM, Robert Goulet wrote:
> Here's a patch for adding additional compile flags to .hlsl
> files in Visual Studio. For this I simply added the new
> VS_SHADER_FLAGS source file property and basically did the
> same as other VS_SHADER_* properties.

Okay.  Please use spaces instead of tabs and match the surrounding
indentation.  Also please add/modify:

 Help/prop_sf/VS_SHADER_FLAGS.rst
 Help/manual/cmake-properties.7.rst

to add the documentation, and add a release note as:

 Help/release/dev/vs-shader-flags.rst

following the style of other release note files in that directory.

Also please extend Tests/VSWinStorePhone/CMakeLists.txt with a
test for this feature.

Thanks,
-Brad


From tobias.hunger at gmail.com  Mon Jan 26 15:15:52 2015
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Mon, 26 Jan 2015 21:15:52 +0100
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <54C65C0F.9090902@kitware.com>
References: <CACcA1RpJ_GS55S3QwjSL0a_FJYVvzRU1NnOEg8fuBQTTMp=nNQ@mail.gmail.com>
 <loom.20140925T085612-346@post.gmane.org>
 <CACcA1RqQ4Dq_xzEM9nDMWxke_mN0Z4mO-MY-NQFWoBZMqey5KA@mail.gmail.com>
 <loom.20150108T174009-382@post.gmane.org>
 <CACcA1RrNT9-B_n7=TobM=MQ39eiiDczaByE5ZmNzEd2drMsSfw@mail.gmail.com>
 <m8rqmv$kk2$1@ger.gmane.org>
 <CAMdWP3GJhXWM1dtzBiA48OFrSOqc_AaS-wP3+qZAyCNJKqsoJQ@mail.gmail.com>
 <54C65C0F.9090902@kitware.com>
Message-ID: <CAMdWP3Ep1X-MfsruYV5ZGPhUJU4FkwL1=uChXtRQoj_V=F9ofg@mail.gmail.com>

I gave this patch a try with the cmake project data.

I had hoped that this file would contain all the information an IDE
might need, but there seems quite a bit missing for that. E.g. there
is no information on which files are used to build a target. What am I
missing?

Best Regards,
Tobias

On Mon, Jan 26, 2015 at 4:23 PM, Brad King <brad.king at kitware.com> wrote:
> On 01/25/2015 08:26 AM, Tobias Hunger wrote:
>> I just had a bit of time to play with cmake this weekend: Is this
>> patch available somewhere by now?
>
> Aleix sent it in a message of this thread on 2015-01-09:
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061
>
> Some review comments elsewhere in this thread are still pending.
>
> -Brad
>

From alex.merry at kde.org  Mon Jan 26 17:39:00 2015
From: alex.merry at kde.org (Alex Merry)
Date: Mon, 26 Jan 2015 22:39 +0000
Subject: [cmake-developers] Improving Vim support in CMake
In-Reply-To: <20150126160044.GC12746@megas.kitwarein.com>
References: <20150121211735.GA32290@megas.kitwarein.com>
 <20150126160005.GB12746@megas.kitwarein.com>
 <20150126160044.GC12746@megas.kitwarein.com>
Message-ID: <6184583.1D5PAqj5sf@kyoshi>

On Monday 26 January 2015 11:00:44 Ben Boeckel wrote:
> On Mon, Jan 26, 2015 at 11:00:05 -0500, Ben Boeckel wrote:
> > Odd; attached is an HTML dump from Vim for what I see (:TOhtml) where
> > variable expansions are highlighted in strings just like outside of
> > strings.
> 
> Probably help if I actually attached the file :/ .
> 
> --Ben

Maybe it's just my colour scheme - I'll have a play with the colour settings 
when I have some free time.

Alex

From ben.boeckel at kitware.com  Mon Jan 26 18:22:41 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 26 Jan 2015 18:22:41 -0500
Subject: [cmake-developers] Improving Vim support in CMake
In-Reply-To: <6184583.1D5PAqj5sf@kyoshi>
References: <20150121211735.GA32290@megas.kitwarein.com>
 <20150126160005.GB12746@megas.kitwarein.com>
 <20150126160044.GC12746@megas.kitwarein.com>
 <6184583.1D5PAqj5sf@kyoshi>
Message-ID: <20150126232241.GA19440@megas.kitwarein.com>

On Mon, Jan 26, 2015 at 22:39:00 +0000, Alex Merry wrote:
> Maybe it's just my colour scheme - I'll have a play with the colour settings 
> when I have some free time.

FWIW, I use neverland-darker, a 256-color scheme. Looking at it with an
8-color scheme does indeed have it all being the same. 'Label' seems to
at least be different than 'String' in all the default color schemes
whereas 'Constant' is the same as 'String' there. Unfortunately, there's
no 'Variable' highlighting group and if we don't stick to the defaults
available, none of the colorschemes will know what to do with it :/ .
'Tag' also seems like it might be viable.

Maybe making cmakeArguments -> Constant and cmakeVariableValue ->
Identifier would work better? Strings are the same as unquoted words
there though :/ .

--Ben

From mantis at public.kitware.com  Tue Jan 27 09:02:21 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Jan 2015 09:02:21 -0500
Subject: [cmake-developers] [CMake 0015373]: GNUInstallDirs is not correct
	for ArchLinux
Message-ID: <ace3c687b3a327a7a3bf896b29a15aeb@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15373 
====================================================================== 
Reported By:                Dimitri Merejkowsky
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15373
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-27 09:02 EST
Last Modified:              2015-01-27 09:02 EST
====================================================================== 
Summary:                    GNUInstallDirs is not correct for ArchLinux
Description: 
When setting CMAKE_INSTALL_PREFIX to /usr, CMAKE_INSTALL_FULL_LIBDIR is set to
/usr/lib64, which is not correct since the /usr merge :

https://www.archlinux.org/news/update-filesystem-201301-1-and-glibc-217-2-together/



Steps to Reproduce: 
# CMakeLists.txt:

cmake_minimum_required(VERSION 3.1)
project(foo)

include(GNUInstallDirs)

message(STATUS "CMAKE_INSTALL_FULL_LIBDIR: ${CMAKE_INSTALL_FULL_LIBDIR}")


$ cmake -DCMAKE_INSTALL_PREFIX=/usr

Output is /usr/lib64, should be /usr/lib
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-27 09:02 Dimitri MerejkowskyNew Issue                                   

======================================================================


From mantis at public.kitware.com  Tue Jan 27 10:14:12 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Jan 2015 10:14:12 -0500
Subject: [cmake-developers] [CMake 0015374]: Support generator expresssions
	in add_definitions()
Message-ID: <7588bb5a3ff55355052a9c2d59d5d0ae@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15374 
====================================================================== 
Reported By:                raspy
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15374
Category:                   CMake
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-27 10:14 EST
Last Modified:              2015-01-27 10:14 EST
====================================================================== 
Summary:                    Support generator expresssions in add_definitions()
Description: 
Generator expressions are supported in add_compile_options(),
target_compile_options() and target_compile_definitions(), but not in
add_definitions() which leads to some inconsistency. I would make use of
generator expressions in definitions on a global level, mostly define some
symbols based on CMake's variables setup.

Please add support for generator expressions in add_definitions().
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-27 10:14 raspy          New Issue                                    
======================================================================


From dgmaths9 at gmail.com  Tue Jan 27 10:52:18 2015
From: dgmaths9 at gmail.com (Deepak Garg)
Date: Tue, 27 Jan 2015 16:52:18 +0100
Subject: [cmake-developers] build on multiple cores
Message-ID: <CAGbnQ09WmG1RYBQEB=JkWKqkxyCctxLnMF8r_Z+f5WGga5=NfQ@mail.gmail.com>

I want to build my cmake code with multiple cores (64). For this I am
trying to test the build on 4 cores by typing

make -j 4

But still build is done by a single core. The time taken for build by

make  and  make -j 4

is same. Can anyone guide me that what am I doing wrong?


thanks
Deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/c3004bc1/attachment.html>

From nilsgladitz at gmail.com  Tue Jan 27 10:56:32 2015
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Tue, 27 Jan 2015 16:56:32 +0100
Subject: [cmake-developers] build on multiple cores
In-Reply-To: <CAGbnQ09WmG1RYBQEB=JkWKqkxyCctxLnMF8r_Z+f5WGga5=NfQ@mail.gmail.com>
References: <CAGbnQ09WmG1RYBQEB=JkWKqkxyCctxLnMF8r_Z+f5WGga5=NfQ@mail.gmail.com>
Message-ID: <54C7B530.1000904@gmail.com>

On 01/27/2015 04:52 PM, Deepak Garg wrote:
> I want to build my cmake code with multiple cores (64). For this I am
> trying to test the build on 4 cores by typing
>
> make -j 4
>
> But still build is done by a single core. The time taken for build by
>
> make  and  make -j 4
>
> is same. Can anyone guide me that what am I doing wrong?

I think this might be better discussed on the user's rather than 
developer's mailing list.

In general this works for me as-is (with gnu make).

Nils



From mantis at public.kitware.com  Tue Jan 27 11:00:06 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Jan 2015 11:00:06 -0500
Subject: [cmake-developers] [CMake 0015375]: Please provide a way to
	evaluate generator expressions on demand
Message-ID: <b174276c8c61e86019cdb7a015d88963@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15375 
====================================================================== 
Reported By:                raspy
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15375
Category:                   CMake
Reproducibility:            have not tried
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-27 11:00 EST
Last Modified:              2015-01-27 11:00 EST
====================================================================== 
Summary:                    Please provide a way to evaluate generator
expressions on demand
Description: 
I have a use case like this:

I have a custom module which requires to call external script with current
compilation flags. This is performed with execute_process() passing flags
gathered from property COMPILE_OPTIONS, CMAKE_C_FLAGS and
CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE}.

However, with the COMPILE_OPTIONS I get generator expression, which is not
evaluated, i.e. $<$<CONFIG:DEBUG>:-g> and passing it further makes no sense. It
would be good if I could in any way (with a variant of set() command maybe?)
force evaluation of such generator expressions to make use of them where they
may be needed but not natively supported.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-27 11:00 raspy          New Issue                                    
======================================================================


From bill.hoffman at kitware.com  Tue Jan 27 11:02:09 2015
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 27 Jan 2015 11:02:09 -0500
Subject: [cmake-developers] build on multiple cores
In-Reply-To: <CAGbnQ09WmG1RYBQEB=JkWKqkxyCctxLnMF8r_Z+f5WGga5=NfQ@mail.gmail.com>
References: <CAGbnQ09WmG1RYBQEB=JkWKqkxyCctxLnMF8r_Z+f5WGga5=NfQ@mail.gmail.com>
Message-ID: <54C7B681.7090405@kitware.com>

On 1/27/2015 10:52 AM, Deepak Garg wrote:
> I want to build my cmake code with multiple cores (64). For this I am
> trying to test the build on 4 cores by typing
>
> make -j 4
>
> But still build is done by a single core. The time taken for build by
>
> make  and  make -j 4
>
> is same. Can anyone guide me that what am I doing wrong?
http://www.kitware.com/blog/home/post/434

However, if make and make -j4 are the same something is odd.  What 
platform/compiler?  What version of make?

-Bill


From brad.king at kitware.com  Tue Jan 27 11:40:35 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Jan 2015 11:40:35 -0500
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
 prefixes
In-Reply-To: <54BD1558.1030809@kitware.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>	<CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>	<54B91559.3030701@kitware.com>	<54B984E2.4080208@kitware.com>	<CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>	<CAKgx6BKatt-Cgt8aweuxHbpDMmPS8bV3O4jiaT=250pmObrkiQ@mail.gmail.com>
 <CAKgx6B+cmNHSi1OfzUAdrG2MeB-LCDQ0yJajOX24u6HQkx-JUQ@mail.gmail.com>
 <54BD1558.1030809@kitware.com>
Message-ID: <54C7BF83.9030603@kitware.com>

On 01/19/2015 09:31 AM, Brad King wrote:
> Most of the RunCMake tests are for negative tests, but mostly for
> running "cmake".  IIUC you need tests that run "cpack", right?
> For that you can use run_cmake_command.  See use in the
> RunCMake.CTestMemcheck test to run "ctest":
> 
>  Tests/RunCMake/CTestMemcheck/RunCMakeTest.cmake
> 
> See also Tests/RunCMake/CommandLine/RunCMakeTest.cmake for other
> uses to try the non-generator signatures of "cmake".

The topic as of commit 36f93b60 has Tests/CPackRPM/RunCPack.cmake
which should be refactored to use RunCMake infrastructure, perhaps
in a new Tests/RunCMake/CPackRPM test.  Please extend the topic
to move the test over.

Thanks,
-Brad


From Robert.Goulet at autodesk.com  Tue Jan 27 12:03:30 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 27 Jan 2015 17:03:30 +0000
Subject: [cmake-developers] Windows Store generated solution also containing
	win32 console app?
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi all,

When generating VS solution targeting the Windows Store system, it turns out that ALL projects gets to target Windows Store. In the event that the solution also contains a project that is a simple Win32 console application that perform some tasks on files needed by the final Windows Store app, it looks like this is currently not possible.

Looking at the code, it seems CMake uses a global variable that essentially means that the generator targets a Windows Store app. This makes it difficult to hack it to control this per project rather than globally. A quick test shows that it is possible to have a solution that contains both Win32 console targets as well as Windows Store app targets in Visual Studio.

How should I go about this? I would like to avoid creating two distinct build folders with their own solutions and having to deal with paths once we want to execute commands. What if CMake could simply force specific projects to be Win32 console apps? Or perhaps the other way around, add a new token in add_executable to specify if it's a Windows Store app (just like WIN32 or MACOSX_BUNDLE, could have a third one: WINSTORE)?

Thoughts?



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616
DIRECT +1 514 954 3911
MOBILE +1 438 397 4075

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com<http://www.autodesk.com/>

[Description: Email_Signature_Logobar]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/1b72ca0f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14277 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/1b72ca0f/attachment-0001.jpg>

From brad.king at kitware.com  Tue Jan 27 12:42:59 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Jan 2015 12:42:59 -0500
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C7CE23.6010707@kitware.com>

On 01/27/2015 12:03 PM, Robert Goulet wrote:
> CMake uses a global variable that essentially means that the generator
> targets a Windows Store app. This makes it difficult to hack it to
> control this per project rather than globally.

This is a fundamental limitation of the design of CMake, not just of
the VS generator.  We only support one target arch/platform at a time.
The entire configuration process runs with one platform in mind, and
one toolchain per language.  This is the same reason one cannot build
host binaries while cross compiling.  Even if one were to hack the
VS generator to set the type of one .vcxproj file, it still would not
have proper information to generate the other properties in the file.

You could try running CMake with execute_process to generate a second
nested build tree, and then include_external_msproject to make one of
its .vcxproj files available in the outer .sln.  I've not tried this
though.

-Brad


From Robert.Goulet at autodesk.com  Tue Jan 27 12:47:37 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 27 Jan 2015 17:47:37 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C69EEB.3050008@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C69EEB.3050008@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>

There you go. Let me know if it's good now.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, January 26, 2015 3:09 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/26/2015 02:28 PM, Robert Goulet wrote:
> Here's a patch for adding additional compile flags to .hlsl files in 
> Visual Studio. For this I simply added the new VS_SHADER_FLAGS source 
> file property and basically did the same as other VS_SHADER_* 
> properties.

Okay.  Please use spaces instead of tabs and match the surrounding indentation.  Also please add/modify:

 Help/prop_sf/VS_SHADER_FLAGS.rst
 Help/manual/cmake-properties.7.rst

to add the documentation, and add a release note as:

 Help/release/dev/vs-shader-flags.rst

following the style of other release note files in that directory.

Also please extend Tests/VSWinStorePhone/CMakeLists.txt with a test for this feature.

Thanks,
-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vs-shader-flags.patch
Type: application/octet-stream
Size: 5959 bytes
Desc: vs-shader-flags.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/3273805d/attachment.obj>

From brad.king at kitware.com  Tue Jan 27 12:59:29 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Jan 2015 12:59:29 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C69EEB.3050008@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C7D201.4020404@kitware.com>

On 01/27/2015 12:47 PM, Robert Goulet wrote:
> There you go. Let me know if it's good now.

Thanks.  I've committed the patch and merged for testing:

 VS: Add source file property to set extra hlsl shader flags
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b9bd827

In the test I see:

 VS_SHADER_FLAGS "/Fh $(OutDir)%(Filename).h"

which can be manually verified but I do not see how the test
automatically verifies that the flag is correctly used.

Thanks,
-Brad


From Robert.Goulet at autodesk.com  Tue Jan 27 13:22:09 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 27 Jan 2015 18:22:09 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C7D201.4020404@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C69EEB.3050008@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7D201.4020404@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1B887@005-TK5MPN4-042.MGDADSK.autodesk.com>

If the flag would be wrong, compilation would fail.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Tuesday, January 27, 2015 12:59 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/27/2015 12:47 PM, Robert Goulet wrote:
> There you go. Let me know if it's good now.

Thanks.  I've committed the patch and merged for testing:

 VS: Add source file property to set extra hlsl shader flags
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b9bd827

In the test I see:

 VS_SHADER_FLAGS "/Fh $(OutDir)%(Filename).h"

which can be manually verified but I do not see how the test automatically verifies that the flag is correctly used.

Thanks,
-Brad


From brad.king at kitware.com  Tue Jan 27 13:31:05 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Jan 2015 13:31:05 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1B887@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C69EEB.3050008@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7D201.4020404@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B887@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C7D969.6070508@kitware.com>

On 01/27/2015 01:22 PM, Robert Goulet wrote:
> If the flag would be wrong, compilation would fail.

What if the flag is not added at all because the property is ignored?
The test needs to be something that would fail without this change.

Thanks,
-Brad


From mantis at public.kitware.com  Tue Jan 27 13:48:35 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Jan 2015 13:48:35 -0500
Subject: [cmake-developers] [CMake 0015376]: CMake creates Xcode project
	with invalid project settings
Message-ID: <f0bb81cf4b3ddd6d39fd75c6c422b99b@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15376 
====================================================================== 
Reported By:                tron_thomas
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15376
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-27 13:48 EST
Last Modified:              2015-01-27 13:48 EST
====================================================================== 
Summary:                    CMake creates Xcode project with invalid project
settings
Description: 
A project configured for Xcode will have invalid project settings

Steps to Reproduce: 
Steps:
1.Create a simple hello world C++ module named Hello.cpp
2. Use the following CMake script to configure the project to build with Xcode
6.1.1

cmake_minimum_required (VERSION 3.1.0)

project(Hello)

add_executable(Hello Hello.cpp)

3. Open the Xcode project

Expected:
The project should open with no warnings or errors

Actual:
The project will contain the following warning about overriding architecture
settings

Additional Information: 
This can be particularly bad for project that contains many buildables as Xcode
may take a long time to fix the issue or may get hung up trying to apply the fix

It is also quite annoying when someone frequently reconfigures the project with
CMake as the problem return each time
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-27 13:48 tron_thomas    New Issue                                    
======================================================================


From alex.merry at kde.org  Tue Jan 27 14:41:26 2015
From: alex.merry at kde.org (Alex Merry)
Date: Tue, 27 Jan 2015 19:41:26 +0000
Subject: [cmake-developers] Improving Vim support in CMake
In-Reply-To: <20150126232241.GA19440@megas.kitwarein.com>
References: <20150121211735.GA32290@megas.kitwarein.com>
 <6184583.1D5PAqj5sf@kyoshi> <20150126232241.GA19440@megas.kitwarein.com>
Message-ID: <1553443.s0ezttjiKB@kyoshi>

On Monday 26 January 2015 18:22:41 Ben Boeckel wrote:
> On Mon, Jan 26, 2015 at 22:39:00 +0000, Alex Merry wrote:
> > Maybe it's just my colour scheme - I'll have a play with the colour
> > settings when I have some free time.
> 
> FWIW, I use neverland-darker, a 256-color scheme. Looking at it with an
> 8-color scheme does indeed have it all being the same. 'Label' seems to
> at least be different than 'String' in all the default color schemes
> whereas 'Constant' is the same as 'String' there. Unfortunately, there's
> no 'Variable' highlighting group and if we don't stick to the defaults
> available, none of the colorschemes will know what to do with it :/ .
> 'Tag' also seems like it might be viable.
> 
> Maybe making cmakeArguments -> Constant and cmakeVariableValue ->
> Identifier would work better? Strings are the same as unquoted words
> there though :/ .

That would explain it. I think variables are used in strings enough that 
making them different colours on standard colour schemes is sensible. I would 
argue that distinguishing variables and constants, say, is less important.

Alex

From Robert.Goulet at autodesk.com  Tue Jan 27 14:58:07 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Tue, 27 Jan 2015 19:58:07 +0000
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <54C7CE23.6010707@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>

Ok, make sense. However, the generator is essentially the same for both Win32 and WinRT except for a very few properties. Turns out I was able to make a patch, however I don't know if that's going to be rejected because of the way I did it, but it works really well so far.

This allow me to set the target property VS_WINRT_DISABLE on the projects I want, while still targeting Windows Store in the toolchain file. I personally find it cleaner to do that in my CMakeLists.txt files rather than using multiple CMake root projects. It also works for the add_custom_command rule with COMMAND as stated in the documentation: "If COMMAND specifies an executable target (created by the add_executable() command) it will automatically be replaced by the location of the executable created at build time." I can share the same add_custom_command between all platforms instead of having a different one just for Windows Store build.

Let me know your thoughts about it.
Thanks!


-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Tuesday, January 27, 2015 12:43 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Windows Store generated solution also containing win32 console app?

On 01/27/2015 12:03 PM, Robert Goulet wrote:
> CMake uses a global variable that essentially means that the generator 
> targets a Windows Store app. This makes it difficult to hack it to 
> control this per project rather than globally.

This is a fundamental limitation of the design of CMake, not just of the VS generator.  We only support one target arch/platform at a time.
The entire configuration process runs with one platform in mind, and one toolchain per language.  This is the same reason one cannot build host binaries while cross compiling.  Even if one were to hack the VS generator to set the type of one .vcxproj file, it still would not have proper information to generate the other properties in the file.

You could try running CMake with execute_process to generate a second nested build tree, and then include_external_msproject to make one of its .vcxproj files available in the outer .sln.  I've not tried this though.

-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vs-winrt-disable.patch
Type: application/octet-stream
Size: 5943 bytes
Desc: vs-winrt-disable.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/314b94f2/attachment.obj>

From guillaume.belz at gmail.com  Tue Jan 27 16:09:31 2015
From: guillaume.belz at gmail.com (Guillaume Belz)
Date: Tue, 27 Jan 2015 21:09:31 +0000
Subject: [cmake-developers] [PATCH] OpenSSL 1.0.2 update
Message-ID: <CAMfMMyorM_3XJ+xf_ypWetDpsxj6YAcvyoZ1BSQqQtuS0LZcAg@mail.gmail.com>

Hi,

OpenSSL 1.0.2 was released last week and there is a little change in code,
which impact FindOpenSSL.cmake script. The script use a regex to read the
version of OpenSLL inside opensslv.h file. In the last commit, this file
was modified with a formatting tool and the line 33 was changed from:

 # define OPENSSL_VERSION_NUMBER  0x10100000L

to:

 #define OPENSSL_VERSION_NUMBER 0x10100000L

To fix that, it's possible to change regex in FindOpenSSL.cmake file in
line 288, from:

 REGEX "^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")

to:

 REGEX "^# *define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")

It's work on Scientific Linux 7 with OpenSSL 1.0.2 and CMake 3.1.1. I have
not checked on other platforms.

Thanks,
Guillaume



Commit on opensslv.h:
https://github.com/openssl/openssl/blob/0f113f3ee4d629ef9a4a30911b22b224772085e5/crypto/opensslv.h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/bf155648/attachment.html>

From eike at sf-mail.de  Tue Jan 27 16:20:42 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 27 Jan 2015 22:20:42 +0100
Subject: [cmake-developers] [PATCH] OpenSSL 1.0.2 update
In-Reply-To: <CAMfMMyorM_3XJ+xf_ypWetDpsxj6YAcvyoZ1BSQqQtuS0LZcAg@mail.gmail.com>
References: <CAMfMMyorM_3XJ+xf_ypWetDpsxj6YAcvyoZ1BSQqQtuS0LZcAg@mail.gmail.com>
Message-ID: <1742228.YiRrImQkJY@eto>

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

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

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/493fc49a/attachment.sig>

From eike at sf-mail.de  Tue Jan 27 16:56:20 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 27 Jan 2015 22:56:20 +0100
Subject: [cmake-developers] [PATCH] OpenSSL 1.0.2 update
In-Reply-To: <1742228.YiRrImQkJY@eto>
References: <CAMfMMyorM_3XJ+xf_ypWetDpsxj6YAcvyoZ1BSQqQtuS0LZcAg@mail.gmail.com>
 <1742228.YiRrImQkJY@eto>
Message-ID: <2085931.zHIy8E0g1K@eto>

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

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

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

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150127/110ad2c9/attachment.sig>

From mantis at public.kitware.com  Tue Jan 27 18:34:02 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Jan 2015 18:34:02 -0500
Subject: [cmake-developers] [CMake 0015377]: CMake cannot test compiler
	features in Turkish locale
Message-ID: <84b3cd15193f00106cebbd2d29d8522a@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15377 
====================================================================== 
Reported By:                Ongun Kanat
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15377
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-01-27 18:34 EST
Last Modified:              2015-01-27 18:34 EST
====================================================================== 
Summary:                    CMake cannot test compiler features in Turkish
locale
Description: 
When using Turkish UTF-8 locale(tr_TR.UTF-8) CMake exits with error below

   CMake Error at /usr/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake:78
(CMAKE_DETERMINE_COMPILE_FEATURES):
  Unknown CMake command "CMAKE_DETERMINE_COMPILE_FEATURES".

Exporting LANG and LC_ALL variables as en_US.UTF-8 fixes problem temporarily.

Steps to Reproduce: 
- Download any source with CMake build support
- Run
  $ export LANG=tr_TR.UTF-8
  $ export LC_ALL=tr_TR.UTF-8
  $ cmake
- It will exit.

Additional Information: 
I suspect that there may be a Turkish 'I' problem in source code. If it does a
uppercase/lowercase conversion there is a risk that the result of conversion
wrong/non-English. 

For detailed info check:
http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html

I'm also adding trace output of cmake.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-27 18:34 Ongun Kanat    New Issue                                    
2015-01-27 18:34 Ongun Kanat    File Added: cmakeout.txt                     
======================================================================


From brian at briansmith.org  Wed Jan 28 07:31:15 2015
From: brian at briansmith.org (Brian Smith)
Date: Wed, 28 Jan 2015 04:31:15 -0800
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the flags
	relevant to the language.
Message-ID: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>

This patch is an attempt to fix
http://www.cmake.org/Bug/view.php?id=15253. As noted in the bug, this
affects the Chromium BoringSSL build.

Cheers,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Ninja-Pass-only-the-flags-relevant-to-the-language.patch
Type: application/octet-stream
Size: 1923 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150128/e28a9abe/attachment.obj>

From brad.king at kitware.com  Wed Jan 28 08:47:01 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Jan 2015 08:47:01 -0500
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>
Message-ID: <54C8E855.7090008@kitware.com>

On 01/28/2015 07:31 AM, Brian Smith wrote:
> This patch is an attempt to fix
> http://www.cmake.org/Bug/view.php?id=15253. As noted in the bug, this
> affects the Chromium BoringSSL build.

Thanks for working on this.

> -  std::string flags = "$FLAGS";
> +  std::string flags;
> +  
> +  if (lang == "C" || lang == "CXX" || lang == "RC")
> +    {
> +    flags += "$FLAGS";
> +    }

Why is this hunk needed?  The $FLAGS placeholder should be
okay for any language because the corresponding build rules
should be generated with the proper FLAGS value.

>      else
>        {
>        deptype = "msvc";
>        depfile = "";
> -      flags += " /showIncludes";
> +      if (lang == "C" || lang == "CXX")
> +        {
> +        flags += " /showIncludes";
> +        }
>        }

Without /showIncludes the "msvc" deptype does not make sense.
Should some other code path be used here to get dependencies?

Thanks,
-Brad


From brian at briansmith.org  Wed Jan 28 09:06:35 2015
From: brian at briansmith.org (Brian Smith)
Date: Wed, 28 Jan 2015 06:06:35 -0800
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <54C8E855.7090008@kitware.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>
 <54C8E855.7090008@kitware.com>
Message-ID: <CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>

On Wed, Jan 28, 2015 at 5:47 AM, Brad King <brad.king at kitware.com> wrote:
> On 01/28/2015 07:31 AM, Brian Smith wrote:
>> -  std::string flags = "$FLAGS";
>> +  std::string flags;
>> +
>> +  if (lang == "C" || lang == "CXX" || lang == "RC")
>> +    {
>> +    flags += "$FLAGS";
>> +    }
>
> Why is this hunk needed?  The $FLAGS placeholder should be
> okay for any language because the corresponding build rules
> should be generated with the proper FLAGS value.

You are probably right. In the BoringSSL build, $FLAGS consists of a
bunch of "-I <dir>" arguments that specify the paths to the C/C++
include directories. BoringSSL's assembly language code doesn't use
".include" so these arguments are unnecessary, and it seemed wrong to
me to inherit the C/C++ include directories for assembly language
compilations, so I removed it. But, this change doesn't have any
bearing on the problem described in the bug, so it is probably better
to revert it.

>>      else
>>        {
>>        deptype = "msvc";
>>        depfile = "";
>> -      flags += " /showIncludes";
>> +      if (lang == "C" || lang == "CXX")
>> +        {
>> +        flags += " /showIncludes";
>> +        }
>>        }
>
> Without /showIncludes the "msvc" deptype does not make sense.
> Should some other code path be used here to get dependencies?

Good point. Again, BoringSSL's assembly language code doesn't use
".include" so I'm not sure what is correct. However, both the nasm
documentation and the yasm documentation say that "-M" should be used
to generate makefile dependencies.

IMO, it is a good idea to fix this bug by committing a variant of the
second hunk, and then file a new bug about correctly getting
dependencies from nasm/yasm. If you agree, I'm happy to send an
updated patch that removes the first hunk and that changes the deptype
line in the second hunk to something else. In that case, what should I
change the deptype line to?

Thanks,
Brian

From brad.king at kitware.com  Wed Jan 28 09:19:11 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Jan 2015 09:19:11 -0500
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>	<54C8E855.7090008@kitware.com>
 <CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>
Message-ID: <54C8EFDF.9030804@kitware.com>

On 01/28/2015 09:06 AM, Brian Smith wrote:
> it seemed wrong to me to inherit the C/C++ include directories for
> assembly language compilations, so I removed it.

I don't think it is getting the C/C++ flags.  It's getting the
preprocessor flags.  Anyway, we agree to skip this hunk.

> Good point. Again, BoringSSL's assembly language code doesn't use
> ".include" so I'm not sure what is correct. However, both the nasm
> documentation and the yasm documentation say that "-M" should be used
> to generate makefile dependencies.
> 
> IMO, it is a good idea to fix this bug by committing a variant of the
> second hunk, and then file a new bug about correctly getting
> dependencies from nasm/yasm. If you agree, I'm happy to send an
> updated patch that removes the first hunk and that changes the deptype
> line in the second hunk to something else. In that case, what should I
> change the deptype line to?

The original issue could have been worded to explain that nasm/yasm
dependencies are not handled correctly, so I'd like to treat it that
way.  If these tools have the -M flag then a "deptype = gcc" code path
should work.  The usingMSVC boolean should be updated to be false
for lang != C|CXX|RC so that the "else" code path is taken.  Then

 CMAKE_DEPFILE_FLAGS_<LANG>

should be added to the platform modules for these toolchains.

Thanks,
-Brad


From raffi.enficiaud at free.fr  Wed Jan 28 09:21:10 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Wed, 28 Jan 2015 15:21:10 +0100
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
In-Reply-To: <98EDE7BE-00E7-4EFE-8D74-E51F41B49535@free.fr>
References: <DA5F7E6B-8B42-4410-8269-952BE577DDE1@free.fr>
 <543FD60A.5060508@kitware.com> <D3A34A02-199B-4928-91B5-4B3DE08BB6B1@free.fr>
 <54C01A82.6080400@kitware.com> <8017F6A3-A9D0-47D2-9B53-DE4C0E2C3FDE@free.fr>
 <54C129FB.3070102@kitware.com> <073A6DE2-B2DF-4DF8-A603-DAA6429C142E@free.fr>
 <54C2A96A.3060100@kitware.com>
 <54c2ecb9.6308b40a.75ff.ffffa484SMTPIN_ADDED_BROKEN@mx.google.com>
 <54C64499.3050707@kitware.com> <98EDE7BE-00E7-4EFE-8D74-E51F41B49535@free.fr>
Message-ID: <08F24DF8-41E7-4FD8-837E-5FC514C65338@free.fr>

Dear Brad,

I am wondering why I haven't zipped the patch before.

Please find attached the patch addressing the issues you raised.

Best,
Raffi Enficiaud


-------------- next part --------------
A non-text attachment was scrubbed...
Name: find_matlab_1.patch.zip
Type: application/zip
Size: 52890 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150128/fd324182/attachment-0001.zip>
-------------- next part --------------




> On 26 Jan 2015, at 20:29, Raffi Enficiaud <raffi.enficiaud at free.fr> wrote:
> 
> Dear Brad,
> 
> I addressed your proposed solution and sent you a patch, that is pending approval since this afternoon because of a size exceeding 300KB.
> 
> Best regards,
> Raffi Enficiaud
> 
>> On 26 Jan 2015, at 14:43, Brad King <brad.king at kitware.com> wrote:
>> 
>> On 01/23/2015 07:52 PM, Raffi Enficiaud wrote:
>>>> This should be handled with a save/restore.
>>> 
>>> Are you referring to the CMakePushCheckState?
>> 
>> No, CMAKE_FIND_LIBRARY_PREFIXES should be saved/restored manually
>> with code in the Find module around the find_library calls.  You
>> could also create a _Matlab_find_library function that sets
>> CMAKE_FIND_LIBRARY_PREFIXES and calls find_library.  The setting
>> would go out of scope when the function returns.  See the FindBoost
>> module for a similar example.
>> 
>> -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


From brad.king at kitware.com  Wed Jan 28 09:31:43 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Jan 2015 09:31:43 -0500
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C7D969.6070508@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C69EEB.3050008@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7D201.4020404@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B887@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7D969.6070508@kitware.com>
Message-ID: <54C8F2CF.2020508@kitware.com>

On 01/27/2015 01:31 PM, Brad King wrote:
> On 01/27/2015 01:22 PM, Robert Goulet wrote:
>> If the flag would be wrong, compilation would fail.
> 
> What if the flag is not added at all because the property is ignored?
> The test needs to be something that would fail without this change.

I revised the test to add preprocessor definitions as flags and
check for them in the .hlsl sources.  I also fixed the /Fh flag
value to be quoted to work with a space in the path.

Revised commit:

 VS: Add source file property to set extra hlsl shader flags
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4775c901

-Brad


From Robert.Goulet at autodesk.com  Wed Jan 28 10:06:51 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Wed, 28 Jan 2015 15:06:51 +0000
Subject: [cmake-developers] Setting additional compile flags to .hlsl
 files?
In-Reply-To: <54C8F2CF.2020508@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E16B08@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C67C94.8030103@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16BDE@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68272.8040505@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16C23@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C68618.90602@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E16F47@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C69EEB.3050008@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B5EC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7D201.4020404@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1B887@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7D969.6070508@kitware.com> <54C8F2CF.2020508@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1C7D4@005-TK5MPN4-042.MGDADSK.autodesk.com>

Awesome, thanks!

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, January 28, 2015 9:32 AM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/27/2015 01:31 PM, Brad King wrote:
> On 01/27/2015 01:22 PM, Robert Goulet wrote:
>> If the flag would be wrong, compilation would fail.
> 
> What if the flag is not added at all because the property is ignored?
> The test needs to be something that would fail without this change.

I revised the test to add preprocessor definitions as flags and check for them in the .hlsl sources.  I also fixed the /Fh flag value to be quoted to work with a space in the path.

Revised commit:

 VS: Add source file property to set extra hlsl shader flags
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4775c901

-Brad


From mantis at public.kitware.com  Wed Jan 28 10:25:42 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 28 Jan 2015 10:25:42 -0500
Subject: [cmake-developers] [CMake 0015379]: [PATCH] CTest does not
	recognize recent gmake's messages as errors
Message-ID: <82267537d6403ae6d421808ef4b35a12@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15379 
====================================================================== 
Reported By:                Marco Nolden
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15379
Category:                   CTest
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-28 10:25 EST
Last Modified:              2015-01-28 10:25 EST
====================================================================== 
Summary:                    [PATCH] CTest does not recognize recent gmake's
messages as errors
Description: 
The "No rule to make target" error message of gmake is not correctly recognized
since GNU make changed the quoting style [1] . Example:

gmake[5]: *** No rule to make target
'/space/dartclients/clang/MITK-Superbuild-Release-nightly/OpenCV-build/lib/libopencv_videostab.so.2.4.8',
needed by 'lib/libITKVideoBridgeOpenCV-4.5.so.1'.  Stop.

is not recognized so the superbuild continues an leads to an incorrect report on
the dashboard.

I attached a fix, would be great if this could go into CMake 3.2

Steps to Reproduce: 
Happens always with a problematic superbuild and recent versions of GNU make 

Additional Information: 
[1]:
http://git.savannah.gnu.org/cgit/make.git/commit/remake.c?id=23c2b99e9d23e726ede9442728272616e66d416f
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-28 10:25 Marco Nolden   New Issue                                    
2015-01-28 10:25 Marco Nolden   File Added:
0001-cmCTestBuildHandler-fix-for-newer-GNU-style-error-me.patch                 
  
======================================================================


From mantis at public.kitware.com  Wed Jan 28 10:27:53 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 28 Jan 2015 10:27:53 -0500
Subject: [cmake-developers] [CMake 0015380]: Optional arguments for macros
	are ignored by if()
Message-ID: <fbd52bfbd4a54a28b9d42453252003da@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15380 
====================================================================== 
Reported By:                Alina
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15380
Category:                   CMake
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-28 10:27 EST
Last Modified:              2015-01-28 10:27 EST
====================================================================== 
Summary:                    Optional arguments for macros are ignored by if()
Description: 
The issue was reproduced also on CMake 3.0.2 on OS X Yosemite.

Documentation points to the following :
"In the first case you can use if(${ARGV1}), in the second case, you can use
foreach(loop_var ${ARGN}) but this will skip empty arguments. If you need to
include them, you can use:"
http://www.cmake.org/cmake/help/v3.0/command/macro.html

But if on any ARGVXXX is always false.

An simple example is attached.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-28 10:27 Alina          New Issue                                    
2015-01-28 10:27 Alina          File Added: CMakeLists.txt                    
======================================================================


From brad.king at kitware.com  Wed Jan 28 13:20:38 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Jan 2015 13:20:38 -0500
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C92876.3030001@kitware.com>

On 01/27/2015 02:58 PM, Robert Goulet wrote:
> the generator is essentially the same for both Win32 and WinRT
> except for a very few properties.
> 
> This allow me to set the target property VS_WINRT_DISABLE

I think this can work as a feature of this specific generator.
Let's restrict it to executable targets for now.  Also, rather
than a new property, let's define that the VS_WINRT_COMPONENT
property may be *explicitly* set to a false value to disable
WinRT settings on Store targets.  On Windows Store it should
be an error to set VS_WINRT_COMPONENT explicitly to false for
anything but an EXECUTABLE target.

> -     (target->IsImported() || !this->Makefile->IsOn("CMAKE_CROSSCOMPILING")))
> +     (target->IsImported() || !this->Makefile->IsOn("CMAKE_CROSSCOMPILING") || target->GetPropertyAsBool("VS_WINRT_DISABLE")))

That leaks knowledge of the VS generator features into code
that is not specific to the generator.  Instead you could add
a method to cmTarget like "IsHostExecutable" that can answer
the above question.  Internally it could ask the global gen
for help, which could then be a vtable dispatch to special
knowledge in the VS >= 10 generators.

Thanks,
-Brad


From Robert.Goulet at autodesk.com  Wed Jan 28 13:36:08 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Wed, 28 Jan 2015 18:36:08 +0000
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <54C92876.3030001@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>

Nice, I'm glad you think this can be part of CMake, since it I think it is extremely useful to be able to run standard executables that are part of the CMake project within a Windows Store solution, for any preprocessing that could be needed.

I agree let's restrict it only to executables for now. And I will use the VS_WINRT_COMPONENT target property as you are suggesting.

Also I will try to see how I can move that last change into the specifics of the VS generator, I knew it was pretty bad to put that code there but I wasn't sure how to implement it.

Thanks!

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, January 28, 2015 1:21 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Windows Store generated solution also containing win32 console app?

On 01/27/2015 02:58 PM, Robert Goulet wrote:
> the generator is essentially the same for both Win32 and WinRT except 
> for a very few properties.
> 
> This allow me to set the target property VS_WINRT_DISABLE

I think this can work as a feature of this specific generator.
Let's restrict it to executable targets for now.  Also, rather than a new property, let's define that the VS_WINRT_COMPONENT property may be *explicitly* set to a false value to disable WinRT settings on Store targets.  On Windows Store it should be an error to set VS_WINRT_COMPONENT explicitly to false for anything but an EXECUTABLE target.

> -     (target->IsImported() || !this->Makefile->IsOn("CMAKE_CROSSCOMPILING")))
> +     (target->IsImported() || 
> + !this->Makefile->IsOn("CMAKE_CROSSCOMPILING") || 
> + target->GetPropertyAsBool("VS_WINRT_DISABLE")))

That leaks knowledge of the VS generator features into code that is not specific to the generator.  Instead you could add a method to cmTarget like "IsHostExecutable" that can answer the above question.  Internally it could ask the global gen for help, which could then be a vtable dispatch to special knowledge in the VS >= 10 generators.

Thanks,
-Brad


From brad.king at kitware.com  Wed Jan 28 13:38:15 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Jan 2015 13:38:15 -0500
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C92C97.9060703@kitware.com>

On 01/28/2015 01:36 PM, Robert Goulet wrote:
> Also I will try to see how I can move that last change into the
> specifics of the VS generator, I knew it was pretty bad to put that
> code there but I wasn't sure how to implement it.

There will at least need to be a hook in the general code to get to
the VS-specific code.

Thanks,
-Brad


From Robert.Goulet at autodesk.com  Wed Jan 28 14:06:02 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Wed, 28 Jan 2015 19:06:02 +0000
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <54C92C97.9060703@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>

How do I test if a target property is explicitly set to false instead of undefined?

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, January 28, 2015 1:38 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Windows Store generated solution also containing win32 console app?

On 01/28/2015 01:36 PM, Robert Goulet wrote:
> Also I will try to see how I can move that last change into the 
> specifics of the VS generator, I knew it was pretty bad to put that 
> code there but I wasn't sure how to implement it.

There will at least need to be a hook in the general code to get to the VS-specific code.

Thanks,
-Brad


From brad.king at kitware.com  Wed Jan 28 14:09:26 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Jan 2015 14:09:26 -0500
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54C933E6.6010605@kitware.com>

On 01/28/2015 02:06 PM, Robert Goulet wrote:
> How do I test if a target property is explicitly set to false
> instead of undefined?

Something like this (untested):

 const char* isWinRT = target->GetProperty("VS_WINRT_COMPONENT");
 if (isWinRT && cmSystemTools::IsOff(isWinRT))
   {
   // explicitly off
   }

-Brad


From gjasny at googlemail.com  Wed Jan 28 14:14:08 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Wed, 28 Jan 2015 20:14:08 +0100
Subject: [cmake-developers] [PATCH] Generator expressions for XCODE_ATTRIBUTE
Message-ID: <1422472449-71392-1-git-send-email-gjasny@googlemail.com>

Hello,

I'm still working on xctest support and decided that most logic should
be implemented as a function or macro outside of the C++ code base.

However to achive this I must be able to set the following property
on the xctest bundle:

XCODE_ATTRIBUTE_TEST_HOST "$<TARGET_FILE:CocoaExample>"

Would you consider applying the attached patch? If yes I will add the
necesary documentation.

How would you test that feature? Just grepping in the generated pbxproj?

Thanks,
Gregor

Gregor Jasny (1):
  Add support for Generator Expressions within XCODE_ATTRIBUTE target
    properties

 Source/cmGlobalXCodeGenerator.cxx | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
1.9.3 (Apple Git-50)


From gjasny at googlemail.com  Wed Jan 28 14:14:09 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Wed, 28 Jan 2015 20:14:09 +0100
Subject: [cmake-developers] [PATCH] Add support for Generator Expressions
	within XCODE_ATTRIBUTE target properties
In-Reply-To: <1422472449-71392-1-git-send-email-gjasny@googlemail.com>
References: <1422472449-71392-1-git-send-email-gjasny@googlemail.com>
Message-ID: <1422472449-71392-2-git-send-email-gjasny@googlemail.com>

Signed-off-by: Gregor Jasny <gjasny at googlemail.com>
---
 Source/cmGlobalXCodeGenerator.cxx | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx
index e7a6141..25668e8 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2394,8 +2394,11 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target,
 
       if (!attribute.empty())
         {
+        cmListFileBacktrace backtrace = this->CurrentMakefile->GetBacktrace();
+        cmGeneratorExpression ge(&backtrace);
+        std::string processed = ge.Parse(i->second.GetValue())->Evaluate(this->CurrentMakefile, configName);
         buildSettings->AddAttribute(attribute.c_str(),
-                                    this->CreateString(i->second.GetValue()));
+                                    this->CreateString(processed));
         }
       }
     }
-- 
1.9.3 (Apple Git-50)


From steveire at gmail.com  Wed Jan 28 14:39:58 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 28 Jan 2015 20:39:58 +0100
Subject: [cmake-developers] Windows Store generated solution also
	containing win32 console app?
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
Message-ID: <mabdue$bke$1@ger.gmane.org>

Brad King wrote:

> Instead you could add
> a method to cmTarget like "IsHostExecutable" that can answer
> the above question.

Are commands like find_library affected? Can a host executable have 
(external) dependencies? That is one of the open issues recorded at 
  
 http://public.kitware.com/Bug/view.php?id=14539

Thanks,

Steve.



From Robert.Goulet at autodesk.com  Wed Jan 28 17:08:04 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Wed, 28 Jan 2015 22:08:04 +0000
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <54C933E6.6010605@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C933E6.6010605@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1D146@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi,

Please review my patch and let me know if it correspond to what you had in mind. Thanks!

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, January 28, 2015 2:09 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Windows Store generated solution also containing win32 console app?

On 01/28/2015 02:06 PM, Robert Goulet wrote:
> How do I test if a target property is explicitly set to false instead 
> of undefined?

Something like this (untested):

 const char* isWinRT = target->GetProperty("VS_WINRT_COMPONENT");
 if (isWinRT && cmSystemTools::IsOff(isWinRT))
   {
   // explicitly off
   }

-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: option-to-disable-winstore-on-execs.patch
Type: application/octet-stream
Size: 11440 bytes
Desc: option-to-disable-winstore-on-execs.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150128/b49d1285/attachment-0001.obj>

From domen.vrankar at gmail.com  Wed Jan 28 18:06:44 2015
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 29 Jan 2015 00:06:44 +0100
Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation
	prefixes
In-Reply-To: <54C7BF83.9030603@kitware.com>
References: <CAKgx6BLpMN6omZv89TMfgjHzFuqZ9Ov9YH89OoaE3JkCdFZcpA@mail.gmail.com>
 <CAKgx6B+Ort7b8jMMg_BNvd00J1D4vmRHoX70cYKnb9m89jOh6A@mail.gmail.com>
 <54B91559.3030701@kitware.com> <54B984E2.4080208@kitware.com>
 <CAKgx6BKaNrQkx_QopWSKjQKcPgvs1Pn313R-37p38V02SC-f7A@mail.gmail.com>
 <CAKgx6BKatt-Cgt8aweuxHbpDMmPS8bV3O4jiaT=250pmObrkiQ@mail.gmail.com>
 <CAKgx6B+cmNHSi1OfzUAdrG2MeB-LCDQ0yJajOX24u6HQkx-JUQ@mail.gmail.com>
 <54BD1558.1030809@kitware.com> <54C7BF83.9030603@kitware.com>
Message-ID: <CAKgx6B+w87wT3LD6VXL2JZ=K3E90FDYNHeKiWgVJ_4bFh=py_A@mail.gmail.com>

>> Most of the RunCMake tests are for negative tests, but mostly for
>> running "cmake".  IIUC you need tests that run "cpack", right?
>> For that you can use run_cmake_command.  See use in the
>> RunCMake.CTestMemcheck test to run "ctest":
>>
>>  Tests/RunCMake/CTestMemcheck/RunCMakeTest.cmake
>>
>> See also Tests/RunCMake/CommandLine/RunCMakeTest.cmake for other
>> uses to try the non-generator signatures of "cmake".
>
> The topic as of commit 36f93b60 has Tests/CPackRPM/RunCPack.cmake
> which should be refactored to use RunCMake infrastructure, perhaps
> in a new Tests/RunCMake/CPackRPM test.  Please extend the topic
> to move the test over.

Attached is the patch for this. Please apply it.

I'm unable to apply it myself as git push to stage is reporting
conflicts and git pull from stage is reporting not a repository
error...

Thanks,
Domen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm_multi_prefix_test_fix.patch
Type: text/x-diff
Size: 6160 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/10d78a80/attachment.patch>

From Geoffrey.Viola at asirobots.com  Wed Jan 28 22:51:05 2015
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Thu, 29 Jan 2015 03:51:05 +0000
Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
 Generator Support
In-Reply-To: <5474E132.2010705@kitware.com>
References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
 <543D2BBC.1010306@kitware.com>
 <0b5b33c4d1f0472782e260f9e5bce980@CO1PR07MB208.namprd07.prod.outlook.com>
 <544E4C9F.3050408@kitware.com>
 <64abd7ba273245b686146aa67acb7e8a@DM2PR0701MB1020.namprd07.prod.outlook.com>
 <545A7C44.6040305@kitware.com>
 <e45b6652445a49f69e0b4efafc3ddeee@DM2PR0701MB1020.namprd07.prod.outlook.com>
 <5474E132.2010705@kitware.com>
Message-ID: <DM2PR0701MB1020735E911AECEDDF8C784089300@DM2PR0701MB1020.namprd07.prod.outlook.com>

>* The hunk in Modules/CMakeDetermineCompilerId.cmake is now just a
>  whitespace change, so please drop it.

It's removed

>* Please ensure C++ sources do not have lines exceeding 79 columns.
>
>* Please avoid trailing whitespace on source lines.

ClangFormat with llvm configuration was run to clean some of the files up.

>Next we need to add tests.  Since CMake won't build with this generator we need to add tests using the generator as part of the test suite when the needed tools are available.  Look in >Tests/CMakeLists.txt for uses of add_test_VSWinStorePhone as an example of how this is done for another target platform.
>You can either add a new test directory with dedicated code covering capabilities of the generator, or re-use some of the existing tests to see if they build under the new generator, or >both.

I added 2 tests. They are named "GhsMulti.arm_integrity_simarm" and "GhsMulti.arm64_integrity_simarm."

>Once you get tests working, please look at submitting an experimental build to our dashboard and posting a link to it.
>You can do that from the build tree of CMake with
>
> ctest -C Debug -D Experimental
>
>(or with whatever configuration you built locally).

I submitted some builds. Here's a link https://open.cdash.org/viewTest.php?buildid=3671841.
I'm not sure why 9 fail. Also, the tests that I added don't show up, but I can see them in the Test.xml document.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com



-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, November 25, 2014 1:06 PM
To: Geoffrey Viola
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support

On 11/17/2014 05:16 PM, Geoffrey Viola wrote:
> I made some changes and rebased on the trunk.

Thanks.  Here are a few minor comments:

* The hunk in Modules/CMakeDetermineCompilerId.cmake is now just a
  whitespace change, so please drop it.

* Please ensure C++ sources do not have lines exceeding 79 columns.

* Please avoid trailing whitespace on source lines.

Next we need to add tests.  Since CMake won't build with this generator we need to add tests using the generator as part of the test suite when the needed tools are available.  Look in Tests/CMakeLists.txt for uses of add_test_VSWinStorePhone as an example of how this is done for another target platform.
You can either add a new test directory with dedicated code covering capabilities of the generator, or re-use some of the existing tests to see if they build under the new generator, or both.

Once you get tests working, please look at submitting an experimental build to our dashboard and posting a link to it.
You can do that from the build tree of CMake with

  ctest -C Debug -D Experimental

(or with whatever configuration you built locally).

Thanks,
-Brad
This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch
Type: application/octet-stream
Size: 62048 bytes
Desc: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/3bcd51e8/attachment-0001.obj>

From gjasny at googlemail.com  Thu Jan 29 01:36:01 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Thu, 29 Jan 2015 07:36:01 +0100
Subject: [cmake-developers] [PATCH] Require libarchive 3.0.0 or later
Message-ID: <54C9D4D1.5070104@googlemail.com>

Hello,

the libarchive shipped with RHEL6 is too old and does not provide
archive_entry_copy_sourcepath_w. This patch tells cmake to look for
version 3.0.0 or later.

Thanks,
Gregor
-------------- next part --------------
From cff52ed7841fccb25836e14f45f433173fddee99 Mon Sep 17 00:00:00 2001
From: Gregor Jasny <Gregor.Jasny at citrix.com>
Date: Wed, 28 Jan 2015 22:31:37 -0800
Subject: [PATCH] Require libarchive 3.0.0 or later

Older versions do not provide archive_entry_copy_sourcepath_w.
---
 CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8ad1be8..e61621d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -336,7 +336,7 @@ macro (CMAKE_BUILD_UTILITIES)
   #---------------------------------------------------------------------
   # Build or use system libarchive for CMake and CTest.
   if(CMAKE_USE_SYSTEM_LIBARCHIVE)
-    find_package(LibArchive)
+    find_package(LibArchive 3.0.0)
     if(NOT LibArchive_FOUND)
       message(FATAL_ERROR "CMAKE_USE_SYSTEM_LIBARCHIVE is ON but LibArchive is not found!")
     endif()
-- 
1.8.5.5


From mantis at public.kitware.com  Thu Jan 29 02:59:49 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 29 Jan 2015 02:59:49 -0500
Subject: [cmake-developers] [CMake 0015381]: Certain COMPILE_OPTIONS are
	missing in Fortran VS10 project after set_source_files_properties()
Message-ID: <e6e7c077bbedf0f46856e4a2a25c17ec@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15381 
====================================================================== 
Reported By:                ?yvind Jensen
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15381
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-29 02:59 EST
Last Modified:              2015-01-29 02:59 EST
====================================================================== 
Summary:                    Certain COMPILE_OPTIONS are missing in Fortran VS10
project after set_source_files_properties()
Description: 
Unknown flags are at risk of being unintentionally overwritten.

By "unknown flags" I mean: compile flags that are unknown to the Visual Studio
generator, and for that reason are placed under "Additional options" in the
source file properties dialog of Visual Studio.

According to the documentation, the COMPILE_FLAGS property represents
*additional* flags. However, if an unknown flag is added to a source file using
set_source_files_properties(... COMPILE_FLAGS ...), 
any existing unknown flags will be overwritten.


Steps to Reproduce: 
Please find attached a minimal case that reproduces this behaviour. The archive
contains the files:
    cmake_bug_case/CMakeLists.txt
    cmake_bug_case/source.f90

1) Generate the build files using the Visual Studio 2010 generator (32bit or
64bit).

2) Verify that the "Additional options" field of the source file's property
dialog (Configuration Properties -> Fortran -> Command Line) contains only the
option "/unknown_flag2".

The expected outcome is to see both of the flags "/unknown_flag1" and
"/unknown_flag2" in the "Additional options" field.



Additional Information: 
There are some relatively important flags that are affected by this, for example
the /Qopenmp and the /traceback flags of Intels fortran compiler.

The NMake generator does not have this problem. It behaves as one would expect
from the documentation.

It is also interesting to note that if the COMPILE_FLAGS property is populated
with options that are known to the VS10 generator (flags that do not end up in
the "Additional options" field), everything works as expected.

Also, as you can see from the supplied test case, the problem is not that the
COMPILE_FLAGS property is overwritten, but rather that the visual studio
generator fails to combine compile flags with different origins.

CMake 2.8.12 has the same problem.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-29 02:59 ?yvind Jensen  New Issue                                    
2015-01-29 02:59 ?yvind Jensen  File Added: cmake_bug_case.zip                 
  
======================================================================


From brian at briansmith.org  Thu Jan 29 03:12:39 2015
From: brian at briansmith.org (Brian Smith)
Date: Thu, 29 Jan 2015 00:12:39 -0800
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <54C8EFDF.9030804@kitware.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>
 <54C8E855.7090008@kitware.com>
 <CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>
 <54C8EFDF.9030804@kitware.com>
Message-ID: <CAFewVt5Y5AWP75QmVZQqNAxJG+o2fZ0ViYkmjdF0u_bsZTLT2A@mail.gmail.com>

Brad King <brad.king at kitware.com> wrote:
> The original issue could have been worded to explain that nasm/yasm
> dependencies are not handled correctly, so I'd like to treat it that
> way.

OK.

> If these tools have the -M flag then a "deptype = gcc" code path
> should work.

yasm has an -M flag that causes it to write the dependencies to stdout
WITHOUT doing the assembly. nasm additionally has -MD <file>, which
causes it to write the dependencies to <file> AND do the assembly.
yasm does NOT have -MD. I don't see how to make CMake execute yasm -M
-o <x>.obj <x>.asm > $DEP_FILE and then execute yasm -o <x>.obj
<x>.asm to do the actual assembly.

Instead, I decided to try to add -MD to yasm. See the attached patch,
which is a very rough draft.

> The usingMSVC boolean should be updated to be false
> for lang != C|CXX|RC so that the "else" code path is taken.  Then
>
>  CMAKE_DEPFILE_FLAGS_<LANG>
>
> should be added to the platform modules for these toolchains.

I think I understood what you meant, and I've attached a patch that does that.

With my patch, cmake -GNinja generates a rule like this:

rule ASM_NASM_COMPILER
  depfile = $DEP_FILE
  deps = gcc
  command = c:\<path-to-yasm>yasm.exe  $FLAGS -MD $DEP_FILE -f win32 -o $out $in
  description = Building ASM_NASM object $out

That looks right to me.

But, when I execute ninja and it executes the rule, it never provides
a value for $DEP_FILE. Instead, the executed command looks like this:

10/358] Building ASM_NASM object cryp...\CMakeFiles\sha.dir\sha512-586.asm.obj
FAILED: c:\<path-to-yasm>\yasm.exe  -I..\crypto\.
-I..\crypto\..\include -I..\crypto\sha\. -I..\crypto\sha\..
-I..\crypto\sha\..\..\include -MD  -f win32 -o
crypto\sha\CMakeFiles\sha.dir\sha512-586.asm.obj crypto\sh
\sha512-586.asm
asm: option `-MD' needs an argument!

Notice that the empty string was substituted for $DEP_FILE.

It seems like solving this requires more understanding of how CMake
works than I currently have. Any ideas?

Thanks for your help on this.

Cheers,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-an-MD-option-for-generating-dependency-file-duri.patch
Type: application/octet-stream
Size: 11852 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/d5fe39e8/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-dependency-generation-for-ASM_NASM-Ninja.patch
Type: application/octet-stream
Size: 3061 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/d5fe39e8/attachment-0003.obj>

From brad.king at kitware.com  Thu Jan 29 08:47:41 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 08:47:41 -0500
Subject: [cmake-developers] [PATCH] Generator expressions for
	XCODE_ATTRIBUTE
In-Reply-To: <1422472449-71392-1-git-send-email-gjasny@googlemail.com>
References: <1422472449-71392-1-git-send-email-gjasny@googlemail.com>
Message-ID: <54CA39FD.8000700@kitware.com>

On 01/28/2015 02:14 PM, Gregor Jasny wrote:
> XCODE_ATTRIBUTE_TEST_HOST "$<TARGET_FILE:CocoaExample>"
> 
> Would you consider applying the attached patch?

It looks okay to me.

> How would you test that feature? Just grepping in the generated pbxproj?

Add a case to the Tests/RunCMake/XcodeProject/RunCMakeTest.cmake file:

 run_cmake(XcodeAttributeGenex)

and add the associated test code next to it in XcodeAttributeGenex.cmake:

 enable_language(C)
 ...
 set_property(TARGET ...)

Then create a XcodeAttributeGenex-check.cmake script to read the
project file.  See the existing XcodeFileType case for an example.

Thanks,
-Brad


From brad.king at kitware.com  Thu Jan 29 08:47:45 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 08:47:45 -0500
Subject: [cmake-developers] [PATCH] Require libarchive 3.0.0 or later
In-Reply-To: <54C9D4D1.5070104@googlemail.com>
References: <54C9D4D1.5070104@googlemail.com>
Message-ID: <54CA3A01.3020408@kitware.com>

On 01/29/2015 01:36 AM, Gregor Jasny wrote:
> the libarchive shipped with RHEL6 is too old and does not provide
> archive_entry_copy_sourcepath_w. This patch tells cmake to look for
> version 3.0.0 or later.

Applied, thanks:

 Require libarchive 3.0.0 or later
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3526daf5

-Brad


From vahidkadivar66 at gmail.com  Thu Jan 29 09:56:15 2015
From: vahidkadivar66 at gmail.com (vahid kadivarkadivar)
Date: Thu, 29 Jan 2015 18:26:15 +0330
Subject: [cmake-developers] Using Cmake
Message-ID: <CAMoOEvLzUtKZr6ypbewEShidrvsk6otxqX8nAUN7tcUghsfKPg@mail.gmail.com>

Hi,
How can use Cmake builder for Eclipse IDE is possible?
I want to build the MITK project in eclips IDE
Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/ce4bb6c1/attachment.html>

From brad.king at kitware.com  Thu Jan 29 11:43:50 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 11:43:50 -0500
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <CAFewVt5Y5AWP75QmVZQqNAxJG+o2fZ0ViYkmjdF0u_bsZTLT2A@mail.gmail.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>	<54C8E855.7090008@kitware.com>	<CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>	<54C8EFDF.9030804@kitware.com>
 <CAFewVt5Y5AWP75QmVZQqNAxJG+o2fZ0ViYkmjdF0u_bsZTLT2A@mail.gmail.com>
Message-ID: <54CA6346.3040209@kitware.com>

On 01/29/2015 03:12 AM, Brian Smith wrote:
> I don't see how to make CMake execute yasm -M -o <x>.obj <x>.asm > $DEP_FILE
> and then execute yasm -o <x>.obj <x>.asm to do the actual assembly.

The CMAKE_<LANG>_COMPILE_OBJECT value can be set to a list of multiple
strings.  Each will be invoked in order.  I haven't tested this though.
Also it would have to be set up in a generator-specific manner for Ninja.

> But, when I execute ninja and it executes the rule, it never provides
> a value for $DEP_FILE. Instead, the executed command looks like this:

Please try out this commit:

 Ninja: Use "deps = msvc" only for C and CXX
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2596f95e

Then rebase your changes on it.

Thanks,
-Brad


From mantis at public.kitware.com  Thu Jan 29 13:15:13 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 29 Jan 2015 13:15:13 -0500
Subject: [cmake-developers] [CMake 0015382]: Unable to specify resource
	filters in Eclipse project
Message-ID: <6384f98d7ea3f9967b8b229ee8754f85@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15382 
====================================================================== 
Reported By:                void.pointer
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15382
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-01-29 13:15 EST
Last Modified:              2015-01-29 13:15 EST
====================================================================== 
Summary:                    Unable to specify resource filters in Eclipse
project
Description: 
I generate my project using Eclipse CDT4 - Ninja. I have a subdirectory called
"Third Party" under my source directory that contains boost, QT, and a number of
other very large libraries. I notice that the C++ indexer in Eclipse processes
files in these directories and frequently locks up my machine or crashes.
Indexing takes up to 30 minutes if it decides to complete.

There should be a way I can specify resource filters in CMake scripts. If I can
do this, I can tell Eclipse to ignore the directories I don't want it to scan or
care about. I'd also be able to tell it to ignore .SO files, .A files, and other
non-source file types that way when I use the Open Resource window in Eclipse, I
do not see object files and binaries in the search results.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-29 13:15 void.pointer   New Issue                                    
======================================================================


From Robert.Goulet at autodesk.com  Thu Jan 29 13:45:13 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Thu, 29 Jan 2015 18:45:13 +0000
Subject: [cmake-developers] Fix for Windows Store warning APPX1901: The
 DefaultLanguage property is either missing from the project file or does
 not have a value.
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1DDA0@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi folks,

Here's a patch to fix a warning we get when generating a clean Windows Store project, APPX1901: The DefaultLanguage property is either missing from the project file or does not have a value.

This patch also fix an indentation error in the vcxproj.
Thanks!

-Robert Goulet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/e1c68d2c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-warning-appx1901.patch
Type: application/octet-stream
Size: 1662 bytes
Desc: fix-warning-appx1901.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150129/e1c68d2c/attachment.obj>

From brad.king at kitware.com  Thu Jan 29 14:56:39 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 14:56:39 -0500
Subject: [cmake-developers] Fix for Windows Store warning APPX1901: The
 DefaultLanguage property is either missing from the project file or does
 not have a value.
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1DDA0@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1DDA0@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54CA9077.6000902@kitware.com>

On 01/29/2015 01:45 PM, Robert Goulet wrote:
> Here's a patch to fix a warning
> 
> This patch also fix an indentation error in the vcxproj.

Applied, thanks:

 VS: Add missing newlines to .vcxproj generation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c5574a1

 VS: Set default language in generated Windows Phone and Store projects
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=500794b0

-Brad


From brian at briansmith.org  Thu Jan 29 15:02:38 2015
From: brian at briansmith.org (Brian Smith)
Date: Thu, 29 Jan 2015 12:02:38 -0800
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <54CA6346.3040209@kitware.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>
 <54C8E855.7090008@kitware.com>
 <CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>
 <54C8EFDF.9030804@kitware.com>
 <CAFewVt5Y5AWP75QmVZQqNAxJG+o2fZ0ViYkmjdF0u_bsZTLT2A@mail.gmail.com>
 <54CA6346.3040209@kitware.com>
Message-ID: <CAFewVt7HrRaYSUEw3FjmV7YEpm1VOBMj54EN5k2ywBe17SZ-VQ@mail.gmail.com>

Brad King <brad.king at kitware.com> wrote:
> On 01/29/2015 03:12 AM, Brian Smith wrote:
>> I don't see how to make CMake execute yasm -M -o <x>.obj <x>.asm > $DEP_FILE
>> and then execute yasm -o <x>.obj <x>.asm to do the actual assembly.
>
> The CMAKE_<LANG>_COMPILE_OBJECT value can be set to a list of multiple
> strings.  Each will be invoked in order.  I haven't tested this though.
> Also it would have to be set up in a generator-specific manner for Ninja.

I thought about trying that. Ninja generator unconditionally appends
CMAKE_DEPFILE_FLAGS_<lang> to $FLAGS for the compile command.
Presumably, if there were to commands, it would append
CMAKE_DEPFILE_FLAGS_<lang> to the flags of both commands. But, in this
case, it should only be incorporated into one of the two. It seems
like CMAKE_<LANG>_COMPILE_OBJECT needs to have another parameter
<DEPFILE_FLAGS> distinct from <FLAGS> to handle this. But, that means
would require modifying all the templates that use
CMAKE_DEPFILE_FLAGS_<lang> and all the generators, which is a lot of
work.

>> But, when I execute ninja and it executes the rule, it never provides
>> a value for $DEP_FILE. Instead, the executed command looks like this:
>
> Please try out this commit:
>
>  Ninja: Use "deps = msvc" only for C and CXX
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2596f95e

I tried out your change. With it, BoringSSL will build without
warnings using yasm, which was my original goal. Also, I verified that
even without adding my changes to use "-MD" or "-M", ninja does
rebuild the obj file from the asm file.

> Then rebase your changes on it.

It seems like the support for -MD that I've written isn't useful for
my needs, since I don't use .include. Also, even if I added -MD to
yasm, that solution wouldn't work for any older versions of yasm. It
seems like it would be better to have support for the two-step
compilation process (compile; then generate dep file), but that's too
much for me to take on right now.

Thanks a lot! I really appreciate you fixing this.

Also, note that this bug was originally reported by "karlhungus" in
the bug tracker, but your commit message says it was reported by me.
It would be great if you could give "karlhungus" the credit for
reporting the bug instead of me when you merge it into the trunk.

Thanks again,
Brian

From steveire at gmail.com  Thu Jan 29 15:21:34 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Thu, 29 Jan 2015 21:21:34 +0100
Subject: [cmake-developers] [PATCH] Generator expressions for
	XCODE_ATTRIBUTE
References: <1422472449-71392-1-git-send-email-gjasny@googlemail.com>
 <54CA39FD.8000700@kitware.com>
Message-ID: <mae4oe$phm$1@ger.gmane.org>

Brad King wrote:

> On 01/28/2015 02:14 PM, Gregor Jasny wrote:
>> XCODE_ATTRIBUTE_TEST_HOST "$<TARGET_FILE:CocoaExample>"
>>
>> Would you consider applying the attached patch?
> 
> It looks okay to me.

Please extend the docs too

 http://www.cmake.org/cmake/help/v3.0/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html

Thanks,

Steve.



From brad.king at kitware.com  Thu Jan 29 15:37:45 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 15:37:45 -0500
Subject: [cmake-developers] [PATCH for bug 15253] Ninja: Pass only the
 flags relevant to the language.
In-Reply-To: <CAFewVt7HrRaYSUEw3FjmV7YEpm1VOBMj54EN5k2ywBe17SZ-VQ@mail.gmail.com>
References: <CAFewVt4_uQyi9MDnA6oSnAQti+FknA7wdPBizz2u4H9MG5KVOw@mail.gmail.com>	<54C8E855.7090008@kitware.com>	<CAFewVt4R_xH4LokT4NxgVm65ctFCx3R=wasDUsqq_otnRwQkMw@mail.gmail.com>	<54C8EFDF.9030804@kitware.com>	<CAFewVt5Y5AWP75QmVZQqNAxJG+o2fZ0ViYkmjdF0u_bsZTLT2A@mail.gmail.com>	<54CA6346.3040209@kitware.com>
 <CAFewVt7HrRaYSUEw3FjmV7YEpm1VOBMj54EN5k2ywBe17SZ-VQ@mail.gmail.com>
Message-ID: <54CA9A19.4010403@kitware.com>

On 01/29/2015 03:02 PM, Brian Smith wrote:
> Also, note that this bug was originally reported by "karlhungus" in
> the bug tracker, but your commit message says it was reported by me.
> It would be great if you could give "karlhungus" the credit for
> reporting the bug instead of me when you merge it into the trunk.

It was your trouble with DEP_FILE in constructing your patch that
lead to the commit.  I've changed it to generically reference the
issue tracker entry instead:

 Ninja: Use "deps = msvc" only for C and CXX (#15253)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a93d3ea

Thanks,
-Brad


From brad.king at kitware.com  Thu Jan 29 16:45:49 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 16:45:49 -0500
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1D146@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C933E6.6010605@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1D146@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54CAAA0D.8040105@kitware.com>

On 01/28/2015 05:08 PM, Robert Goulet wrote:
> Please review my patch

Good start.

>> On Windows Store it should be an error to set VS_WINRT_COMPONENT
>> explicitly to false for anything but an EXECUTABLE target.

Actually, what does it mean to build targeting Windows Store and call
add_executable or add_library without setting VS_WINRT_COMPONENT
right now?  Gilles?

Robert, please look at updating the VSWinPhoneStore test to try this
feature on Store, with a custom command running an executable to
generate a source or something.  Regardless of how we modify the
interface we will still need a test for the functionality.

Please wrap C++ source lines to <= 79 characters.  Please avoid trailing
whitespace or blank lines at EOF, but make sure there is a newline at EOF.

Please squash this all back into one commit for the next round of review.

Thanks,
-Brad


From Robert.Goulet at autodesk.com  Thu Jan 29 16:52:48 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Thu, 29 Jan 2015 21:52:48 +0000
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <54CAAA0D.8040105@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C933E6.6010605@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1D146@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54CAAA0D.8040105@kitware.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1E194@005-TK5MPN4-042.MGDADSK.autodesk.com>

Ok. :)

That sounds silly, but how do I merge patches with git?

Not setting VS_WINRT_COMPONENT on an executable at all, when system name is 'WindowsStore', will produce an executable with everything properly set as a Windows Store app. I don't use VS_WINRT_COMPONENT (except for my new special case to turn it off explicitly) and everything seems to work properly. Essentially, if you set system name to 'WindowsStore', then all projects are assumed to have the Windows Store Support turned ON in Visual Studio.


-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Thursday, January 29, 2015 4:46 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org; Gilles Khouzam
Subject: Re: [cmake-developers] Windows Store generated solution also containing win32 console app?

On 01/28/2015 05:08 PM, Robert Goulet wrote:
> Please review my patch

Good start.

>> On Windows Store it should be an error to set VS_WINRT_COMPONENT 
>> explicitly to false for anything but an EXECUTABLE target.

Actually, what does it mean to build targeting Windows Store and call add_executable or add_library without setting VS_WINRT_COMPONENT right now?  Gilles?

Robert, please look at updating the VSWinPhoneStore test to try this feature on Store, with a custom command running an executable to generate a source or something.  Regardless of how we modify the interface we will still need a test for the functionality.

Please wrap C++ source lines to <= 79 characters.  Please avoid trailing whitespace or blank lines at EOF, but make sure there is a newline at EOF.

Please squash this all back into one commit for the next round of review.

Thanks,
-Brad


From brad.king at kitware.com  Thu Jan 29 17:11:14 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Jan 2015 17:11:14 -0500
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <B690D45ED8AB4146AE3D908EB41D0DA121E1E194@005-TK5MPN4-042.MGDADSK.autodesk.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C933E6.6010605@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1D146@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54CAAA0D.8040105@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1E194@005-TK5MPN4-042.MGDADSK.autodesk.com>
Message-ID: <54CAB002.6060301@kitware.com>

On 01/29/2015 04:52 PM, Robert Goulet wrote:
> That sounds silly, but how do I merge patches with git?

Read up on interactive rebase: "git rebase -i".

> Not setting VS_WINRT_COMPONENT on an executable at all, when system
> name is 'WindowsStore', will produce an executable with everything
> properly set as a Windows Store app. I don't use VS_WINRT_COMPONENT
> (except for my new special case to turn it off explicitly) and
> everything seems to work properly. Essentially, if you set system
> name to 'WindowsStore', then all projects are assumed to have the
> Windows Store Support turned ON in Visual Studio.

Hmm...I'm reconsidering the explicit OFF approach.

Gilles, Tests/VSWinStorePhone/CMakeLists.txt does:

 set_property(TARGET ${EXE_NAME} PROPERTY VS_WINRT_COMPONENT TRUE)

What does this cover?  What does it mean to have this on Store?

Thanks,
-Brad


From Gilles.Khouzam at microsoft.com  Thu Jan 29 18:11:26 2015
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Thu, 29 Jan 2015 23:11:26 +0000
Subject: [cmake-developers] Windows Store generated solution also
 containing win32 console app?
In-Reply-To: <54CAB002.6060301@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1B331@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C7CE23.6010707@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1BFDC@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92876.3030001@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CBC6@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C92C97.9060703@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1CD28@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54C933E6.6010605@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1D146@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54CAAA0D.8040105@kitware.com>
 <B690D45ED8AB4146AE3D908EB41D0DA121E1E194@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54CAB002.6060301@kitware.com>
Message-ID: <CY1PR0301MB07132E1E5CD07F632DE23AE398300@CY1PR0301MB0713.namprd03.prod.outlook.com>

Hi Robert,

For applications you might not need the VS_WINRT_COMPONENT, but for libraries setting it vs not does have some differences. The main one being that you produce a WinMD file when set. If you look at the new project dialog when creating a Windows Store component, you have 2 types DLL & Windows Runtime Component, this is what the VS_WINRT_COMPONENT flag defines. By default we want to keep the same functionality that we had before and only turn DLLs into WinRT components when you explicitely set it.

I've got it on my agenda to update the VSWinStorePhone project to be a little more complicated and incorporate multiple simple components which should test this functionality a little more.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Thursday, January 29, 2015 2:11 PM
To: Robert Goulet
Cc: cmake-developers at cmake.org; Gilles Khouzam
Subject: Re: [cmake-developers] Windows Store generated solution also containing win32 console app?

On 01/29/2015 04:52 PM, Robert Goulet wrote:
> That sounds silly, but how do I merge patches with git?

Read up on interactive rebase: "git rebase -i".

> Not setting VS_WINRT_COMPONENT on an executable at all, when system 
> name is 'WindowsStore', will produce an executable with everything 
> properly set as a Windows Store app. I don't use VS_WINRT_COMPONENT 
> (except for my new special case to turn it off explicitly) and 
> everything seems to work properly. Essentially, if you set system name 
> to 'WindowsStore', then all projects are assumed to have the Windows 
> Store Support turned ON in Visual Studio.

Hmm...I'm reconsidering the explicit OFF approach.

Gilles, Tests/VSWinStorePhone/CMakeLists.txt does:

 set_property(TARGET ${EXE_NAME} PROPERTY VS_WINRT_COMPONENT TRUE)

What does this cover?  What does it mean to have this on Store?

Thanks,
-Brad


From Gilles.Khouzam at microsoft.com  Thu Jan 29 18:11:50 2015
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Thu, 29 Jan 2015 23:11:50 +0000
Subject: [cmake-developers] Fix for Windows Store warning APPX1901: The
 DefaultLanguage property is either missing from the project file or does
 not have a value.
In-Reply-To: <54CA9077.6000902@kitware.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1DDA0@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54CA9077.6000902@kitware.com>
Message-ID: <CY1PR0301MB071383413344671213E13FE898300@CY1PR0301MB0713.namprd03.prod.outlook.com>

Thanks Robert.

-----Original Message-----
From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King
Sent: Thursday, January 29, 2015 11:57 AM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Fix for Windows Store warning APPX1901: The DefaultLanguage property is either missing from the project file or does not have a value.

On 01/29/2015 01:45 PM, Robert Goulet wrote:
> Here's a patch to fix a warning
> 
> This patch also fix an indentation error in the vcxproj.

Applied, thanks:

 VS: Add missing newlines to .vcxproj generation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c5574a1

 VS: Set default language in generated Windows Phone and Store projects
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=500794b0

-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

From Robert.Goulet at autodesk.com  Fri Jan 30 10:35:28 2015
From: Robert.Goulet at autodesk.com (Robert Goulet)
Date: Fri, 30 Jan 2015 15:35:28 +0000
Subject: [cmake-developers] Fix for Windows Store warning APPX1901: The
 DefaultLanguage property is either missing from the project file or does
 not have a value.
In-Reply-To: <CY1PR0301MB071383413344671213E13FE898300@CY1PR0301MB0713.namprd03.prod.outlook.com>
References: <B690D45ED8AB4146AE3D908EB41D0DA121E1DDA0@005-TK5MPN4-042.MGDADSK.autodesk.com>
 <54CA9077.6000902@kitware.com>
 <CY1PR0301MB071383413344671213E13FE898300@CY1PR0301MB0713.namprd03.prod.outlook.com>
Message-ID: <B690D45ED8AB4146AE3D908EB41D0DA121E1E8FF@005-TK5MPN4-042.MGDADSK.autodesk.com>

Hi Gilles, Brad,

There's also another warning I'd like to fix. When compiling from the command-line, it generates warning APPX2102: File 'VisualStudioEdition' is not found or is not an executable file. I found that simply adding /p:VisualStudioEdition="Microsoft Visual Studio 2012 Ultimate" on the CMake build command-line fixes the warning. This does not happen when building from within the IDE. Someone else already reported this problem outside of CMake: http://www.interact-sw.co.uk/iangblog/2013/07/29/fix-appx2102.

I think we should fix it directly within CMake with something like the patch I propose below. However, as the comment says, this would be set all the time since we do not have access to know if we are building for Windows Store/Phone at that time in CMake. I tried it on a regular Win32 app and it doesn't seems to affect anything. In fact, we can even set the value of VisualStudioEdition to anything and it doesn't seems to have any effect, as long as it is defined to something. So before I send a proper patch file, what's your thoughts on this? Thanks!


diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx
index 50d7640..e454270 100644
--- a/Source/cmGlobalVisualStudio10Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Generator.cxx
@@ -568,6 +568,13 @@ void cmGlobalVisualStudio10Generator::GenerateBuildCommand(
   makeCommand.push_back(configArg);
   makeCommand.push_back(std::string("/p:VisualStudioVersion=")+
                         this->GetIDEVersion());
+
+  // Normally this is only needed for Windows Store/Phone apps when building from command-line.
+  // Fixes warning APPX2102: : File 'VisualStudioEdition' is not found or is not an executable file.
+  makeCommand.push_back(std::string("/p:VisualStudioEdition=\"")+
+                        this->GetName()+
+                        std::string("\""));
+  
   makeCommand.insert(makeCommand.end(),
                      makeOptions.begin(), makeOptions.end());
 }

-----Original Message-----
From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] 
Sent: Thursday, January 29, 2015 6:12 PM
To: Brad King; Robert Goulet
Cc: cmake-developers at cmake.org
Subject: RE: [cmake-developers] Fix for Windows Store warning APPX1901: The DefaultLanguage property is either missing from the project file or does not have a value.

Thanks Robert.

-----Original Message-----
From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King
Sent: Thursday, January 29, 2015 11:57 AM
To: Robert Goulet
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Fix for Windows Store warning APPX1901: The DefaultLanguage property is either missing from the project file or does not have a value.

On 01/29/2015 01:45 PM, Robert Goulet wrote:
> Here's a patch to fix a warning
> 
> This patch also fix an indentation error in the vcxproj.

Applied, thanks:

 VS: Add missing newlines to .vcxproj generation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c5574a1

 VS: Set default language in generated Windows Phone and Store projects
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=500794b0

-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

From nicolasbock at gmail.com  Fri Jan 30 12:50:59 2015
From: nicolasbock at gmail.com (Nicolas Bock)
Date: Fri, 30 Jan 2015 10:50:59 -0700
Subject: [cmake-developers] New module: CheckFortranCompilerFlag.cmake
Message-ID: <CAPMKG4B4XnWp6Kq4ypDYFZubz_=5kicp+NKLBZ6kuzPDCObJ4w@mail.gmail.com>

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.

Thanks,

nick

# - Check whether the Fortran compiler supports a given flag.
# CHECK_Fortran_COMPILER_FLAG(<flag> <var>)
#  <flag> - the compiler flag
#  <var>  - variable to store the result
# This internally calls the check_fortran_source_compiles macro and
# sets CMAKE_REQUIRED_DEFINITIONS to <flag>.
# See help for CheckFortranSourceCompiles for a listing of variables
# that can otherwise modify the build.
# The result only tells that the compiler does not give an error message when
# it encounters the flag. If the flag has any effect or even a specific one is
# beyond the scope of this module.

#=============================================================================
# Copyright 2006-2011 Kitware, Inc.
# Copyright 2006 Alexander Neundorf <neundorf at kde.org>
# Copyright 2011 Matthias Kretz <kretz at kde.org>
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=============================================================================
# (To distribute this file outside of CMake, substitute the full
#  License text for the above reference.)

include(${CMAKE_SOURCE_DIR}/cmake-scripts//CheckFortranSourceCompiles.cmake)

macro (CHECK_Fortran_COMPILER_FLAG _FLAG _RESULT)
   set(SAFE_CMAKE_REQUIRED_DEFINITIONS "${CMAKE_REQUIRED_DEFINITIONS}")
   set(CMAKE_REQUIRED_DEFINITIONS "${_FLAG}")
   # Normalize locale during test compilation.
   set(_CheckFortranCompilerFlag_LOCALE_VARS LC_ALL LC_MESSAGES LANG)
   foreach(v ${_CheckFortranCompilerFlag_LOCALE_VARS})
     set(_CheckFortranCompilerFlag_SAVED_${v} "$ENV{${v}}")
     set(ENV{${v}} C)
   endforeach()
   CHECK_Fortran_SOURCE_COMPILES("program test\nstop\nend program
test" ${_RESULT}
     # Some compilers do not fail with a bad flag
     FAIL_REGEX "command line option .* is valid for .* but not for C" # GNU
     FAIL_REGEX "unrecognized .*option"                     # GNU
     FAIL_REGEX "unknown .*option"                          # Clang
     FAIL_REGEX "ignoring unknown option"                   # MSVC
     FAIL_REGEX "warning D9002"                             # MSVC, any lang
     FAIL_REGEX "option.*not supported"                     # Intel
     FAIL_REGEX "invalid argument .*option"                 # Intel
     FAIL_REGEX "ignoring option .*argument required"       # Intel
     FAIL_REGEX "[Uu]nknown option"                         # HP
     FAIL_REGEX "[Ww]arning: [Oo]ption"                     # SunPro
     FAIL_REGEX "command option .* is not recognized"       # XL
     FAIL_REGEX "WARNING: unknown flag:"                    # Open64
     )
   foreach(v ${_CheckFortranCompilerFlag_LOCALE_VARS})
     set(ENV{${v}} ${_CheckFortranCompilerFlag_SAVED_${v}})
     unset(_CheckFortranCompilerFlag_SAVED_${v})
   endforeach()
   unset(_CheckFortranCompilerFlag_LOCALE_VARS)

   set (CMAKE_REQUIRED_DEFINITIONS "${SAFE_CMAKE_REQUIRED_DEFINITIONS}")
endmacro ()

From sriram.r at vit.in  Sat Jan 31 06:04:59 2015
From: sriram.r at vit.in (Sriram Rajan)
Date: Sat, 31 Jan 2015 11:04:59 +0000
Subject: [cmake-developers] CFLAGS merged during CMake process
In-Reply-To: <db2ce709bc11f6a86fc57d8617e888c0@cloudmailn6.netcore.co.in>
References: <db2ce709bc11f6a86fc57d8617e888c0@cloudmailn6.netcore.co.in>
Message-ID: <084da137ebbae5c19d7c0cfd0e64c812@cloudmailn6.netcore.co.in>

I observed that Cflags were corrupted during the cmake
I am working on a simple libxml example code from http://www.xmlsoft.org/examples/xpath2.c (http://www.xmlsoft.org/examples/xpath2.c). For some reason, my current working directory is prepended without a space ' '.
     CMakeFiles/nmapWrapper.dir/flags.make:C_FLAGS = -I/Users/sriram/xmlparse/-I/Appl... 
Removing this from the flags results in a successfull compilation:
$ cc -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libxml2 `xml2-config --libs` xpath2.c -o xpath2
Thanks,
Sriram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150131/99b741fe/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150131/99b741fe/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xpath2Config.h.in
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150131/99b741fe/attachment.ksh>

From mantis at public.kitware.com  Sat Jan 31 11:34:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 31 Jan 2015 11:34:07 -0500
Subject: [cmake-developers] [CMake 0015384]: Rules are disappeared from
	solution (VS12) after touching any CMakeLists.txt file
Message-ID: <99dae537e22f568fa836e46bbbc3b14a@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15384 
====================================================================== 
Reported By:                Egor P.
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15384
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-01-31 11:34 EST
Last Modified:              2015-01-31 11:34 EST
====================================================================== 
Summary:                    Rules are disappeared from solution (VS12) after
touching any CMakeLists.txt file
Description: 
I have several custom commands and custom target which depends on them.
After initial cmake run custom command rules correctly appear in VS projects.
After any changes in CMakeLists.txt file and cmake run, those rules disappear
from project (and solution).
The change can be trivial: just add an empty line or a comment.

I noticed it depends on existence of file.
1) run cmake; rules are in solution
2) first build (files are generated by custom rules - commands); rules are in
solution
3) add new line to root (any) CMakeLists.txt file, save
4) run cmake or build; RULES ARE DISAPPEARED!!! <------------

Now any changes to CMakeLists.txt does not make rules appear.
How to do this?

5) Delete files generated during build
6) Repeat p.3
7) run cmake or build; RULES ARE APPEARED!!! <------------

I'm not sure, maybe this behavior is expected, BUT...
When I clean solution via VS (generated files are deleted now) and then I press
rebuild, it does not rebuild custom files (commands)! Because there is no rules
at solution and cmake is not run to check this issue and add this rules again.
This causes build errors etc.
The only way now to regenerate rules is to (!) touch cmake file and run cmake
command.


Steps to Reproduce: 
1) svn co svn://svn.code.sf.net/p/firebird/code/firebird/trunk firebird
2) Put 'sed' in your PATH (can be taken from 'git' package).
3) cmake -H. -Bwin
4) Run win/firebird.sln
5) Look at 'databases' project in 'Boot/Custom build steps' solution dir. It
contains several rules in '/databases/CMake Rules/*': help.fdb.rule,
metadata.fdb.rule, msg.fdb.rule, security.fdb.rule.
6) Build solution (takes 5-10 minutes).
7) Touch firebird/src/CMakeLists.txt (add an empty line)
8) Re-run 'cmake' command or build 'ZERO_BUILD' project in solution.
9) Look at 'Boot/Custom build steps/databases/CMake Rules/*' again! There are no
files listed above. !!!

These rules are declared in 'src/CMakeLists.txt', lines 90-185.

10) Delete 'win/src/*.fdb'
11) Repeat p.7
12) Re-run 'cmake' command or build 'CMake Targets/ZERO_BUILD' project in
solution. Rule files are appeared. !!!

Additional Information: 
I cannot reproduce this on simple small cmake configuration, so providing real
case.
On simple example the rules do not disappear.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-01-31 11:34 Egor P.        New Issue                                    
======================================================================