From pasanen.tuukka at gmail.com  Thu Oct  1 00:56:11 2015
From: pasanen.tuukka at gmail.com (Tuukka Pasanen)
Date: Thu, 1 Oct 2015 07:56:11 +0300
Subject: [cmake-developers] CMake Find modules out of the CMake tree
In-Reply-To: <CAPB8=n_u7DG-iQ9sc-L5GnEj4qSW0TD1pUMWT39ewsZMmGw3xA@mail.gmail.com>
References: <560B8271.4090306@gmail.com> <560BF037.8070203@kitware.com>
 <20150930151137.GA30573@megas.khq.kitware.com>
 <CAPB8=n_u7DG-iQ9sc-L5GnEj4qSW0TD1pUMWT39ewsZMmGw3xA@mail.gmail.com>
Message-ID: <560CBCEB.6020800@gmail.com>

Hello,
As said there ain't official Cmake for SDL2-family and several other. I 
don't believe we are experts of most of them but just wondering should 
there be some kind common effort to provide some of them in same place 
and try to push them upstream projects?

Sincerely,
Tuukka

30.09.2015, 18:45, Tam?s Ken?z kirjoitti:
> > but I doubt the non-CMake ones generate SDL2Config.cmake files.
>
> neither of them generates, not even the CMake one
>
> On Wed, Sep 30, 2015 at 5:11 PM, Ben Boeckel <ben.boeckel at kitware.com 
> <mailto:ben.boeckel at kitware.com>> wrote:
>
>     On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote:
>     > With regard to SDL2, the proper way to make it find-able with
>     CMake is
>     > for SDL2 to provide a CMake packaging files themselves as part
>     of their
>     > own distribution (since they build with CMake):
>
>     Just to note, SDL2 also has build systems for ~every buildsystem out
>     there (VS projects, Xcode projects, Android.mk, autotools, premake,
>     etc.). I *think* those are for ease-of-embedding, but I doubt the
>     non-CMake ones generate SDL2Config.cmake files.
>
>     --Ben
>     --
>
>     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/20151001/b38a9b3b/attachment-0001.html>

From konstantin at podsvirov.pro  Thu Oct  1 02:29:06 2015
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Thu, 01 Oct 2015 09:29:06 +0300
Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015
In-Reply-To: <198581438094978@web29o.yandex.ru>
References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com>
 <35881437659256@web4h.yandex.ru> <1975171437723971@web22h.yandex.ru>
 <55B653D0.4020001@kitware.com> <198581438094978@web29o.yandex.ru>
Message-ID: <825181443680946@web21o.yandex.ru>

Hi all! Modern master alive! :-)

It's been almost a month and it's time to upgrade:

3.3.20150901 CMake => CMake 3.3.20151001

Dear friends, I have a question and call for help.

With my assistance the project has an option for component installation project:

CMake_INSTALL_COMPONENTS

Unfortunately not all files found your component.
The files to be installed without specifying a component fall into 'Unspecified' component.
Need to parse them out and assign them to the component context.

Now have the components:

- cmake;
- ctest;
- cpack;
- cmake-gui;
- sphinx-man;
- sphinx-html;
- sphinx singlehtml;
- sphinx-qthelp

and General for everything else

Is Unspecified;

A list of unaccounted for 'Unspecified' of files to install on the Window is attached.

Links to the installers were specified earlier (see below).


On 28.07.2015, 17:49, "Konstantin Podsvirov" <konstantin at podsvirov.pro>:
> Hi dear CMake developers!
>
> 27.07.2015, 18:52, "Brad King" <brad.king at kitware.com>:
>> On 07/24/2015 03:46 AM, Konstantin Podsvirov wrote:
>>> To solve the problem you run cmake-gui is now possible with the
>>> the following changes:
>>
>> Applied as two separate commits with minor tweaks:
>>
>> cmake-gui: Install Qt5 Windows platform plugin
>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f0155b
>>
>> CMake: Add option CMake_INSTALL_DEPENDENCIES
>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962
>
> Code now in 'master' branch.
>
> Thanks, Brad!
>
> Meet/install/CMake built modern update on MSVC2015 c QtDialog based on Qt 5.5 from today :-)
>
> Windows 32bit:
>
> http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe
>
> Windows 64bit:
>
> http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe
>
> cmake-gui should work now, but if not, then update your system and install
>
> Visual C++ Redistributable for Visual Studio 2015 from the link below:
>
> http://www.microsoft.com/en-us/download/details.aspx?id=48145
>
> As always, questions and suggestions are welcome.

--
Regards,
Konstantin Podsvirov
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Unspecified.txt
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151001/cf677193/attachment-0001.txt>

From roman.wueger at gmx.at  Thu Oct  1 04:07:07 2015
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 1 Oct 2015 10:07:07 +0200
Subject: [cmake-developers] Rename suffix of Mac OS Framework
Message-ID: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at>

Hello,

at the moment I build my frameworks with the following property:

set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE)

If my project is called "Test" for example, then a folder structure with the name "Test.framework" is created.

Is there a way to rename the suffix ".framework"?

Thanks in advance

Best regards
Roman

From brad.king at kitware.com  Thu Oct  1 09:04:41 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 01 Oct 2015 09:04:41 -0400
Subject: [cmake-developers] [Patch] Adding Windows 10 support
In-Reply-To: <BY2PR0301MB0709783E766FFE134FA504B8984D0@BY2PR0301MB0709.namprd03.prod.outlook.com>
References: <CY1PR0301MB0713B463C16F2D9A54E2D630986C0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <CY1PR0301MB07134343059556427A7A3F1398510@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com>
 <CY1PR0301MB07130168F70CB7CD370AF27398500@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56001D8D.3070703@kitware.com>
 <CY1PR0301MB071395BB2B57A573817F29AD98440@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56029D3D.80405@kitware.com>
 <CY1PR0301MB071358CF694A53D1810CF4F998440@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <5602B44E.5030309@kitware.com>
 <CY1PR0301MB071379965C5A8834928E96D298440@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56045E6C.30904@kitware.com>
 <CY1PR0301MB0713BC6DD52B916733E6556998420@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56059800.5050502@kitware.com>
 <CY1PR0301MB07133819428762CF7077B22A984F0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <BY2PR0301MB0709783E766FFE134FA504B8984D0@BY2PR0301MB0709.namprd03.prod.outlook.com>
Message-ID: <560D2F69.7000309@kitware.com>

On 09/30/2015 05:05 PM, Gilles Khouzam wrote:
> simply use the SystemVersion to determine the version of
> the Windows 10 SDK to use.
> 
> Now, by default on Windows 10 host devices with Visual Studio 2015,
> the latest SDK will be used.

Looks good, thanks.  I've applied the series with minor tweaks:

 cmSystemTools: Add VersionCompareGreater helper
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ebdf64d

 Allow CMAKE_SYSTEM_VERSION to be set without CMAKE_SYSTEM_NAME
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6653b235

 VS: Add hook to initialize Windows platform settings
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6b35d0b

 VS: Add support for selecting the Windows 10 SDK
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45c06c1d

Please test to make sure it all works for you still.

Thanks,
-Brad


From ben.boeckel at kitware.com  Thu Oct  1 10:14:00 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 1 Oct 2015 10:14:00 -0400
Subject: [cmake-developers] CMake Find modules out of the CMake tree
In-Reply-To: <560CBCEB.6020800@gmail.com>
References: <560B8271.4090306@gmail.com> <560BF037.8070203@kitware.com>
 <20150930151137.GA30573@megas.khq.kitware.com>
 <CAPB8=n_u7DG-iQ9sc-L5GnEj4qSW0TD1pUMWT39ewsZMmGw3xA@mail.gmail.com>
 <560CBCEB.6020800@gmail.com>
Message-ID: <20151001141400.GA16368@megas.khq.kitware.com>

On Thu, Oct 01, 2015 at 07:56:11 +0300, Tuukka Pasanen wrote:
> As said there ain't official Cmake for SDL2-family and several other. I 
> don't believe we are experts of most of them but just wondering should 
> there be some kind common effort to provide some of them in same place 
> and try to push them upstream projects?

I think such an effort would be good. I don't think it should be in
upstream CMake though (the modules would be tied to CMake's release
cycle and CMake would be tied to backwards compat even when upstream
ships a proper config file).

--Ben

From brad.king at kitware.com  Thu Oct  1 12:54:42 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 01 Oct 2015 12:54:42 -0400
Subject: [cmake-developers] CMake 3.4 feature freeze on 2015-10-01
In-Reply-To: <55F04ADB.1000003@kitware.com>
References: <55F04ADB.1000003@kitware.com>
Message-ID: <560D6552.2050108@kitware.com>

On 09/09/2015 11:06 AM, Brad King wrote:
> The feature freeze in 'master' for CMake 3.4 will be on Oct 1, 2015.
> I will announce a freeze in 'next' sometime in the preceding week so
> that we can get any remaining dashboard trouble cleaned up.

In order to get 'master' ready to branch for 3.4, 'next' is now frozen
to new features.  We're still working through some dashboard cleanup
that may take another few days.  After 3.4 is branched I'll announce
when post-3.4 development in 'next' is open.

Meanwhile the following types of changes are still welcome in 'next':

* Documentation updates
* Regression fixes
* Fixes for bugs in features new to 3.4

Thanks,
-Brad


From pasanen.tuukka at gmail.com  Thu Oct  1 13:28:50 2015
From: pasanen.tuukka at gmail.com (Tuukka Pasanen)
Date: Thu, 1 Oct 2015 20:28:50 +0300
Subject: [cmake-developers] CMake Find modules out of the CMake tree
In-Reply-To: <20151001141400.GA16368@megas.khq.kitware.com>
References: <560B8271.4090306@gmail.com> <560BF037.8070203@kitware.com>
 <20150930151137.GA30573@megas.khq.kitware.com>
 <CAPB8=n_u7DG-iQ9sc-L5GnEj4qSW0TD1pUMWT39ewsZMmGw3xA@mail.gmail.com>
 <560CBCEB.6020800@gmail.com> <20151001141400.GA16368@megas.khq.kitware.com>
Message-ID: <560D6D52.5080809@gmail.com>

Hello,
With upstream I meant per project (try to get Cmake files part of 
project) not upstream CMake (because it would more flexible to have it 
with out release cycle) but let's see if I can bake something up if 
no-one refuses.

Tuukka

01.10.2015, 17:14, Ben Boeckel kirjoitti:
> On Thu, Oct 01, 2015 at 07:56:11 +0300, Tuukka Pasanen wrote:
>> As said there ain't official Cmake for SDL2-family and several other. I
>> don't believe we are experts of most of them but just wondering should
>> there be some kind common effort to provide some of them in same place
>> and try to push them upstream projects?
> I think such an effort would be good. I don't think it should be in
> upstream CMake though (the modules would be tied to CMake's release
> cycle and CMake would be tied to backwards compat even when upstream
> ships a proper config file).
>
> --Ben


From mantis at public.kitware.com  Thu Oct  1 19:15:06 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 1 Oct 2015 19:15:06 -0400
Subject: [cmake-developers] [CMake 0015762]: bootstrap fails on OS X 10.10.5
	(Yosemite)
Message-ID: <c5854476c542f594af05b6e555cec1b9@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15762 
====================================================================== 
Reported By:                Damian Rouson
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15762
Category:                   CMake
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-01 19:15 EDT
Last Modified:              2015-10-01 19:15 EDT
====================================================================== 
Summary:                    bootstrap fails on OS X 10.10.5 (Yosemite)
Description: 
Below is the tail of the output from running "./bootstrap --prefix=${PWD}" on OS
X 10.10.5 (Yosemite).  The same command completes successfully on Linux
(Lubuntu).

Damian

g++ 
-I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk
-I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source
 
-I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk
-c
/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx
-o cmBootstrapCommands1.o
In file included from /usr/include/dispatch/dispatch.h:51:0,
                 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
                 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
                 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
                 from
/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmFindProgramCommand.cxx:16,
                 from
/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx:52:
/usr/include/dispatch/object.h:143:15: error: expected unqualified-id before '^'
token
 typedef void (^dispatch_block_t)(void);
               ^
/usr/include/dispatch/object.h:143:15: error: expected ')' before '^' token
/usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not been
declared
   dispatch_block_t notification_block);
   ^
make: *** [cmBootstrapCommands1.o] Error 1
---------------------------------------------
Error when bootstrapping CMake:
Problem while running make
---------------------------------------------
Log of errors:
/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk/cmake_bootstrap.log


Steps to Reproduce: 
#!/bin/bash
version=3.3
wget http://www.cmake.org/files/v$version/cmake-$version.0-1-src.tar.bz2 &&
tar xvjf cmake-$version.0-1-src.tar.bz2 &&
tar xvjf cmake-$version.0.tar.bz2 &&
cd cmake-$version.0  &&
./bootstrap --prefix=${PWD} >&1 | tee build.log

Additional Information: 
The results from running the above script are viewable at
https://github.com/sourceryinstitute/AdHoc/blob/master/src/cmake/bug-xxxx/build.log
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-01 19:15 Damian Rouson  New Issue                                    
2015-10-01 19:15 Damian Rouson  File Added: cmake_bootstrap.log                 
  
======================================================================


From mantis at public.kitware.com  Fri Oct  2 03:52:17 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 2 Oct 2015 03:52:17 -0400
Subject: [cmake-developers] [CMake 0015763]: Cannot find appropriate C
	compiler on this system
Message-ID: <63b8228effa21c4bf2c0a2877d773106@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15763 
====================================================================== 
Reported By:                diaobk
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15763
Category:                   CMakeSetup
Reproducibility:            have not tried
Severity:                   minor
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-10-02 03:52 EDT
Last Modified:              2015-10-02 03:52 EDT
====================================================================== 
Summary:                    Cannot find appropriate C compiler on this system
Description: 
Error when bootstrapping CMake:
Cannot find appropriate C compiler on this system.
Please specify one using environment variable CC.
See cmake_bootstrap.log for compilers attempted.

---------------------------------------------
Log of errors: /home/kjlv/Software/cmake-3.2.2/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------------------------------------------
cmake_bootstrap.log says :
Try: icc
Line: icc  cmake_bootstrap_16681_test.c -o cmake_bootstrap_16681_test
----------  file   -----------------------

#ifdef __cplusplus
# error "The CMAKE_C_COMPILER is set to a C++ compiler"
#endif

#include<stdio.h>

#if defined(__CLASSIC_C__)
int main(argc, argv)
  int argc;
  char* argv[];
#else
int main(int argc, char* argv[])
#endif
{
  printf("%d%c", (argv != 0), (char)0x0a);
  return argc-1;
}

------------------------------------------
ld: final link failed: No space left on device
Test failed to compile

Change to gcc doesn't work.

 gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20070115 (SUSE Linux)


g++ -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20070115 (SUSE Linux)


icc -v
icc version 13.1.0 (gcc version 4.1.2 compatibility)

 icpc -v
icpc version 13.1.0 (gcc version 4.1.2 compatibility)




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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-02 03:52 diaobk         New Issue                                    
======================================================================


From tamas.kenez at gmail.com  Fri Oct  2 07:40:08 2015
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Fri, 2 Oct 2015 13:40:08 +0200
Subject: [cmake-developers] script mode current directory
Message-ID: <CAPB8=n-CxSZYBbpEnWG=5tdnuiSsipUC3kdXpG1+Z-Ck-9o1SA@mail.gmail.com>

In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
variables are set to the current working directory.

Is this something we can rely on and it could be added to the documentation?

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151002/c3b98faa/attachment.html>

From d3ck0r at gmail.com  Fri Oct  2 08:00:08 2015
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 2 Oct 2015 05:00:08 -0700
Subject: [cmake-developers] script mode current directory
In-Reply-To: <CAPB8=n-CxSZYBbpEnWG=5tdnuiSsipUC3kdXpG1+Z-Ck-9o1SA@mail.gmail.com>
References: <CAPB8=n-CxSZYBbpEnWG=5tdnuiSsipUC3kdXpG1+Z-Ck-9o1SA@mail.gmail.com>
Message-ID: <CAA2GJqVzDi8NicMkZFkC2c5KFcwtn3CNjo15AQbd4830cnhEDg@mail.gmail.com>

On Fri, Oct 2, 2015 at 4:40 AM, Tam?s Ken?z <tamas.kenez at gmail.com> wrote:
> In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
> variables are set to the current working directory.
>

if CMAKE_[CURRENT]_SOURCE_DIR is current directory; you're doing
something wrong :)   That implies that you're doing an in-source build
which is actually less than supported.

cmake --build <dir> allows specifying where the output goes... so; no,
it's prossible that it will never be the 'current' directory.

> Is this something we can rely on and it could be added to the documentation?
>
> Tamas
>
> --
>
> 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  Fri Oct  2 08:45:43 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 02 Oct 2015 08:45:43 -0400
Subject: [cmake-developers] script mode current directory
In-Reply-To: <CAA2GJqVzDi8NicMkZFkC2c5KFcwtn3CNjo15AQbd4830cnhEDg@mail.gmail.com>
References: <CAPB8=n-CxSZYBbpEnWG=5tdnuiSsipUC3kdXpG1+Z-Ck-9o1SA@mail.gmail.com>
 <CAA2GJqVzDi8NicMkZFkC2c5KFcwtn3CNjo15AQbd4830cnhEDg@mail.gmail.com>
Message-ID: <560E7C77.4010105@kitware.com>

On 10/02/2015 08:00 AM, J Decker wrote:
> On Fri, Oct 2, 2015 at 4:40 AM, Tam?s Ken?z wrote:
>> In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
>> variables are set to the current working directory.
> 
> if CMAKE_[CURRENT]_SOURCE_DIR is current directory; you're doing
> something wrong :)   That implies that you're doing an in-source build

Tamas is not doing a build at all but instead running

 cmake -P myscript.cmake

and checking the values of these variables.  Yes, the four variables
are meant to be the current working directory in script mode.  This
should be added to the documentation, but such a patch should also
come with an update to the test suite, perhaps in RunCMake/CommandLine,
that covers the behavior explicitly.

-Brad


From brad.king at kitware.com  Fri Oct  2 10:02:23 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 02 Oct 2015 10:02:23 -0400
Subject: [cmake-developers] [Patch] Adding Windows 10 support
In-Reply-To: <560D2F69.7000309@kitware.com>
References: <CY1PR0301MB0713B463C16F2D9A54E2D630986C0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com>
 <CY1PR0301MB07130168F70CB7CD370AF27398500@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56001D8D.3070703@kitware.com>
 <CY1PR0301MB071395BB2B57A573817F29AD98440@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56029D3D.80405@kitware.com>
 <CY1PR0301MB071358CF694A53D1810CF4F998440@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <5602B44E.5030309@kitware.com>
 <CY1PR0301MB071379965C5A8834928E96D298440@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56045E6C.30904@kitware.com>
 <CY1PR0301MB0713BC6DD52B916733E6556998420@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <56059800.5050502@kitware.com>
 <CY1PR0301MB07133819428762CF7077B22A984F0@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <BY2PR0301MB0709783E766FFE134FA504B8984D0@BY2PR0301MB0709.namprd03.prod.outlook.com>
 <560D2F69.7000309@kitware.com>
Message-ID: <560E8E6F.6010208@kitware.com>

On 10/01/2015 09:04 AM, Brad King wrote:
> Looks good, thanks.  I've applied the series with minor tweaks:

After a C++98 compilation fix and some documentation updates,
this is now in 'master':

 Help: Improve CMAKE_SYSTEM_{NAME,VERSION} variable documentation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70688609

 Allow CMAKE_SYSTEM_VERSION to be set without CMAKE_SYSTEM_NAME
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b31ac171

 cmSystemTools: Add VersionCompareGreater helper
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61c472a2

 VS: Add hook to initialize Windows platform settings
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dfc4c5f

 VS: Add support for selecting the Windows 10 SDK (#15670)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f077996

Thanks,
-Brad


From Gilles.Khouzam at microsoft.com  Fri Oct  2 15:07:22 2015
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Fri, 2 Oct 2015 19:07:22 +0000
Subject: [cmake-developers] [Patch] Adding Windows 10 Universal app support
Message-ID: <CY1PR0301MB0713861934D430CFC93420D0984B0@CY1PR0301MB0713.namprd03.prod.outlook.com>

This patch adds Windows Universal (store) app support. Just like Windows 8.0 and Windows 8.1, this will
allow to produce a Windows 10 Store application (there are no more Phone apps as they are the same now).

>From the commit message:
This change adds support for Windows 10 Universal (Store) Applications.

A Windows 10 Universal Application can be targeted by setting:
CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0
There are no WindowsPhone apps, universal apps target both phone and store.
Specifying the CMAKE_SYSTEM_VERSION to be 10.0 will use the latest Windows
10 SDK installed. If you want to specify a specific SDK, you can make
CMAKE_SYSTEM_VERSION be more specific (10.0.10240.0 for RTM for example).


New Properties Added:
VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION: Target Property.
Specifies the minimum version of the OS that the project can target.

VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSIONS,
VS_IOT_EXTENSIONS_VERSION: Target property. When specifying these properties
a reference to the version of the SDK specified will be added to the
target allowing to target the extended functionality in a universal project.
To match the version of the SDK being used, use
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION

VS_IOT_STARTUP_TASK: Target property. Specifies that the target should be
built as an IOT continuous background task.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151002/1c1c4f63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Windows-10-Universal-Store-Apps.patch
Type: application/octet-stream
Size: 35006 bytes
Desc: 0001-Windows-10-Universal-Store-Apps.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151002/1c1c4f63/attachment-0001.obj>

From konstantin at podsvirov.pro  Fri Oct  2 17:02:07 2015
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Sat, 03 Oct 2015 00:02:07 +0300
Subject: [cmake-developers] [Development] [ANNOUNCE] DaD's House! (Beta)
In-Reply-To: <2890901441908544@web7o.yandex.ru>
References: <1448651441822370@web21h.yandex.ru>
 <1137391441890143@web29h.yandex.ru>
 <VI1PR02MB0622654A745ED751A901E6E5F1510@VI1PR02MB0622.eurprd02.prod.outlook.com>
 <2256851441891098@web5m.yandex.ru>
 <VI1PR02MB06221D03D79CEF92E81610DEF1510@VI1PR02MB0622.eurprd02.prod.outlook.com>
 <2819371441894379@web23g.yandex.ru>
 <CANLz8R7P9f5TiHMBvWy=za-3Ee4T=Sdy-JSbkF2KgF8ftS+Lmw@mail.gmail.com>
 <2890901441908544@web7o.yandex.ru>
Message-ID: <48571443819727@web12m.yandex.ru>

Some time passed and DaD's House was much more informative!

Now on the website, you can:
- See the list of modules provided by a specific installer;
- See the list of all build-specific module;
- Show details on specific build of the specific module.

See "Details" links.

Perhaps this is the first ever web-based interface to view the information
from QtIFW binary repository.

Welcome once again DaD's House:

http://dad.podsvirov.pro

Good luck everyone!

10.09.2015, 21:09, "Konstantin Podsvirov" <konstantin at podsvirov.pro>:
> Hi, Jean-Christophe Fillion-Robin (the short name?)!
>
> Thanks for Your reply. You gave a lot of valuable advice.
>
> 10.09.2015, 17:59, "Jean-Christophe Fillion-Robin" <jchris.fillionr at kitware.com>:
>> Hi Konstantin,
>>
>> Thanks for sharing your work with the community.
>
> I'm glad to be helpful.
> Thank You for giving the community such a useful tool like CMake.
>
>> Given the exhaustive list of modules provided within the installers, I
>> can appreciate the effort.
>
> I agree, thanks for the rating.
> It really is now a lot of work.
>
> But now better order and it was good.
>
> Early in the development of their projects I was trying to find ABI compatible
> binaries for dependent modules. And pretty soon I realized that this is not always possible.
>
> Then I began to study dependent projects and try to build them yourself. Then for each project I reinvent the wheel on
> adding dependencies during development and deployment.
>
> Meanwhile I already owned a nice CMake and he helped me a lot.
>
> Routine work became more and more. I tried a few different frames to create the installers - they were all completely different and I didn't like.
>
> When QtIFW, then I read its documentation and stasis realized that his
> need to make friends with CMake (or Vice versa).
>
> This was the prerequisite for the appearance of Dad's project.
>
> It's just tie a big story, which I hope some will live with me together.
>
>> That said, as you may know, downloading unsigned binaries to build
>> applications is not an option for a lot of us.
>
> Yes, I understand that. The trust of our users is very important.
> But as one cartoon character: I'm not a magician - I'm just learning.
>
> Well I know how to build projects of their own and others :-)
>
> To sign application I haven't learned.
> We are talking about signing applications or installers themselves within modules?
>
>> Here are few initial suggestions to improve your platform:
>>
>> * transition the website to https
>
> It's all about the confidence of users, as mentioned above.
> I need to get the certificate.
> Understandable comment. Will try to organize.
>
>> * reference the version of each packages/modules bundled in the
>> respective installers
>
> I thought about it. You are not the first who comes to me!
> The list of available module versions and can be seen by running the particular setup on the feature selection page, but that's not enough.
> Of course, users want to see it before downloading the installer.
> The proposal was adopted. I'll think how to do it.
>
>> * provide the a how to understand the different between
>> stable/testing/unstable
>
> For a quick start, I refer everyone to the website of the Debian community
>
> http://debian.org
>
> I will try to add a description on the website.
>
>> * document the convention to integrate the different module in our
>> existing project. For example, for CMake, did you write a
>> <Module>Config.cmake file with each project [1] ? And similar question
>> for qmake ?
>
> I plan to have a section on the website with more detailed information for each module.
> Now on the page with the list of modules I have provided a link to the native source of information.
>
> The need to create a CMake configuration for modules is controversial.
> Each project is independent and most of them are family managed by CMake scripts. Provide Some package configurations to import. Some can be found with the Find modules distributed by CMake.
>
> Presents the installers are just transferral these projects
> a local directory of the user. Further, their use is no different, from say download from the original site.
>
>> Good luck,
>> Jc
>
> Thanks for valuable advice.
>
> I'm doing a project in my spare time. And I will try to improve it and continue to share with the community.
>
> Now I'm building modules in an automated way. Not always the case goes smoothly. Some modules require minor tweaks.
> The real CI is still far. But I hope with time I'll come to that.
>
> I apologize for linguistic errors. English is not my native language.
>
>> [1] http://www.cmake.org/cmake/help/git-next/manual/cmake-packages.7.html
>>
>> On Thu, Sep 10, 2015 at 10:12 AM, Konstantin Podsvirov
>> <konstantin at podsvirov.pro> wrote:
>>> 10.09.2015, 16:41, "Mitch Curtis" <mitch.curtis at theqtcompany.com>:
>>>>> From: Konstantin Podsvirov [mailto:konstantin at podsvirov.pro]
>>>>>
>>>>> By clicking on the link, you will be able to get the installer is the same
>>>>> as the QtSDK and a few clicks to get the binaries, libraries and linking
>>>>> headers of any of the participating modules.
>>>>
>>>> But what am I even clicking the link for? What service does this thing provide?
>>>
>>> For example, You want to create a very large and useful application which uses a lot of dependencies.
>>> And you want to deploy it on the Windows.
>>>
>>> You go to the site:
>>>
>>> http://dad.podsvirov.pro
>>>
>>> Download appropriate to your development environment setup.
>>>
>>> Quickly and easily install any required dependent modules and receives a development environment, local deployment and testing.
>>>
>>> When you're finished designing, you can create compatible with this environment the installer to install your application on other machines.
>>>
>>> Main technologies:
>>> * Development languages: C, C++ (Qt, Qml, Quick) and other
>>> * Project management: CMake, but can use other
>>> * Creating installer based QtIFW (CMake allows you to automate the process of creating an installer).
>>>
>>> I answered Your question?
>>>
>>> Regards,
>>> Konstantin Podsvirov
>
> Regards,
> Konstantin Podsvirov
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Regards,
Konstantin Podsvirov

From ctracey at nvidia.com  Fri Oct  2 17:27:31 2015
From: ctracey at nvidia.com (Colin Tracey)
Date: Fri, 2 Oct 2015 21:27:31 +0000
Subject: [cmake-developers] [PATCH] add options to set the bitmap for NSIS
	installer left side
Message-ID: <f5cd6ec456a14f92b03f57fc19692717@HQMAIL108.nvidia.com>

>From 5cd81e17a51c5dc74e494c39a5f496f8e54a5bbf Mon Sep 17 00:00:00 2001
From: Colin Tracey <ctracey at nvidia.com>
Date: Fri, 25 Sep 2015 15:06:08 -0500
Subject: [PATCH] add options to set the bitmap for NSIS installer left side

set MUI_WELCOMEFINISHPAGE_BITMAP
set MUI_UNWELCOMEFINISHPAGE_BITMAP
---
Modules/NSIS.template.in              |  2 ++
Source/CPack/cmCPackNSISGenerator.cxx | 18 ++++++++++++++++++
2 files changed, 20 insertions(+)

diff --git a/Modules/NSIS.template.in b/Modules/NSIS.template.in
index 76310af..1ef3d28 100644
--- a/Modules/NSIS.template.in
+++ b/Modules/NSIS.template.in
@@ -542,6 +542,8 @@ FunctionEnd
; Define some macro setting for the gui
@CPACK_NSIS_INSTALLER_MUI_ICON_CODE@
@CPACK_NSIS_INSTALLER_ICON_CODE@
+ at CPACK_NSIS_INSTALLER_MUI_WELCOMEFINISH_CODE@
+ at CPACK_NSIS_INSTALLER_MUI_UNWELCOMEFINISH_CODE@
@CPACK_NSIS_INSTALLER_MUI_COMPONENTS_DESC@
@CPACK_NSIS_INSTALLER_MUI_FINISHPAGE_RUN_CODE@
diff --git a/Source/CPack/cmCPackNSISGenerator.cxx b/Source/CPack/cmCPackNSISGenerator.cxx
index 6cdda28..5f8d7aa 100644
--- a/Source/CPack/cmCPackNSISGenerator.cxx
+++ b/Source/CPack/cmCPackNSISGenerator.cxx
@@ -158,6 +158,24 @@ int cmCPackNSISGenerator::PackageFiles()
                             installerIconCode.c_str());
     }
+  if (this->IsSet("CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP"))
+    {
+    std::string installerBitmapCode = "!define MUI_WELCOMEFINISHPAGE_BITMAP \"";
+    installerBitmapCode += this->GetOption("CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP");
+    installerBitmapCode += "\"\n";
+    this->SetOptionIfNotSet("CPACK_NSIS_INSTALLER_MUI_WELCOMEFINISH_CODE",
+                            installerBitmapCode.c_str());
+    }
+
+  if (this->IsSet("CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP"))
+    {
+    std::string installerBitmapCode = "!define MUI_UNWELCOMEFINISHPAGE_BITMAP \"";
+    installerBitmapCode += this->GetOption("CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP");
+    installerBitmapCode += "\"\n";
+    this->SetOptionIfNotSet("CPACK_NSIS_INSTALLER_MUI_UNWELCOMEFINISH_CODE",
+                            installerBitmapCode.c_str());
+    }
+
   if(this->IsSet("CPACK_NSIS_MUI_FINISHPAGE_RUN"))
     {
     std::string installerRunCode = "!define MUI_FINISHPAGE_RUN \"$INSTDIR\\";
--
1.9.5.github.0


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151002/178bbc73/attachment.html>

From francesco.romano.1987 at gmail.com  Sat Oct  3 04:51:59 2015
From: francesco.romano.1987 at gmail.com (Francesco Romano)
Date: Sat, 3 Oct 2015 10:51:59 +0200
Subject: [cmake-developers] [Patch] Updated FindMatlab.cmake for Matlab
	R2015b
Message-ID: <CCACAFB3-7FD3-4F24-AAB0-80267E4C4281@gmail.com>

Added support to Matlab 8.6 (R2015b)

Attached is the patch.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Updated-FindMatlab.cmake-to-find-Matlab-R2015b.patch
Type: application/octet-stream
Size: 641 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151003/f7cdd28b/attachment.obj>
-------------- next part --------------


Thank you
Francesco

From francesco.romano.1987 at gmail.com  Sat Oct  3 05:00:17 2015
From: francesco.romano.1987 at gmail.com (Francesco Romano)
Date: Sat, 3 Oct 2015 11:00:17 +0200
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
Message-ID: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>

Dear all,
I don?t know if this is the right mailing list (or maybe cmake users was better?) to post before opening an issue in the CMake bug tracker.

We have an issue with CMake in OS X ([1]) in one of our project.
The issue arose for a coincidence because Xcode 7 ships with the 10.11 SDK and not with the 10.10 SDK, while our systems are still in 10.10.
Making the long story short I needed to set the variable `CMAKE_OSX_DEPLOYMENT_TARGET` to 10.10 and this was done after the first ?project? call.
This works if the generator is Xcode, but not if it is Unix Makefiles.
I restricted the issue to lie in the following if in DarwinInitialize.cmake (lines 48-51)

elseif("${CMAKE_GENERATOR}" MATCHES Xcode
       OR CMAKE_OSX_DEPLOYMENT_TARGET
       OR CMAKE_OSX_ARCHITECTURES MATCHES "[^;]"
       OR NOT EXISTS "/usr/include/sys/types.h")

Now, the question is: why the Unix Makefile should  not  need the variable ?CMAKE_OSX_SYSROOT? but only if the deployment target is not set?
Shouldn?t be correct to set anyway the sysroot (which by the way can be easily found because Xcode is present on the machine)?
Btw: we also build .app with makefiles. Shouldn?t this need the sysroot?

Thanks for the clarification.
Francesco


[1] https://github.com/robotology/yarp/issues/592

From mantis at public.kitware.com  Sat Oct  3 11:40:32 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 3 Oct 2015 11:40:32 -0400
Subject: [cmake-developers] [CMake 0015765]: FindOpenSSL.cmake does not
	honor OPENSSL_ROOT_DIR
Message-ID: <11a6446eb181b1268b2182e052d6e868@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15765 
====================================================================== 
Reported By:                Wayne Stambaugh
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15765
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-03 11:40 EDT
Last Modified:              2015-10-03 11:40 EDT
====================================================================== 
Summary:                    FindOpenSSL.cmake does not honor OPENSSL_ROOT_DIR
Description: 
This has been broken for as long as the KiCad project has been using OpenSSL. 
When you define OPENSSL_ROOT_DIR to point to the mingw builds of OpenSSL, it
always returns the libraries installed in the windows system path (if installed)
which results in link errors.  I'm hoping you will consider applying the
attached patch or at least fixing the current behavior on mingw.  This patch
only honors the OPENSSL_ROOT_DIR.  It does not find the openssl version
installed in /mingw without configuration.  That is yet another issue.

Steps to Reproduce: 
Create a simple cmakelist.txt with findopenssl.  Open the msys shell.  Run
`cmake -G "MSYS Makefiles" -DOPENSSL_ROOT_PATH=/path_to_mingw
path_to_cmake_file`.  If FindOpenSSL is successful, the output on my system
shows:

-- Found OpenSSL: C:/Program Files (x86)/Intel/iCLS
Client/ssleay32.dll;C:/Program Files (x86)/Intel/iCLS Client/libeay32.dll (found
version "1.0.2d")

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-03 11:40 Wayne StambaughNew Issue                                    
2015-10-03 11:40 Wayne StambaughFile Added:
find-openssl-cmake-3.3-mingw-fix.patch                    
======================================================================


From mantis at public.kitware.com  Sat Oct  3 18:02:58 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 3 Oct 2015 18:02:58 -0400
Subject: [cmake-developers] [CMake 0015766]: Fails to infer
	CMAKE_ASM_COMPILER with CC='ccache gcc'
Message-ID: <b31b1376c7d6868315be38474340a38d@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15766 
====================================================================== 
Reported By:                NAKAMURA Takumi
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15766
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-03 18:02 EDT
Last Modified:              2015-10-03 18:02 EDT
====================================================================== 
Summary:                    Fails to infer CMAKE_ASM_COMPILER with CC='ccache
gcc'
Description: 
For CMAKE_C_COMPILER, "gcc" is fed to the first in the argument.
In contrast, "gcc" disappears for CMAKE_ASM_COMPILER.

Of course, it works if ASM is explicitly specified without ccache.

Steps to Reproduce: 
project(Test C ASM)
cmake_minimum_required(VERSION 2.8.12.2)
add_executable(Test foo.c bar.S)

# CC=ccache\ gcc cmake .

# make
[ 66%] Building ASM object CMakeFiles/Test.dir/bar.S.o
/usr/bin/ccache    -o CMakeFiles/Test.dir/bar.S.o -c
/home/tnakamura/fio/ninja/xxx/bar.S
/usr/bin/ccache: invalid option -- 'o'
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-03 18:02 NAKAMURA TakumiNew Issue                                    
======================================================================


From mantis at public.kitware.com  Sun Oct  4 05:56:58 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 4 Oct 2015 05:56:58 -0400
Subject: [cmake-developers] [CMake 0015767]: FindBoost not appropriate for
	header-only modules
Message-ID: <e9a94c753d489e76d90001c91a731ba0@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15767 
====================================================================== 
Reported By:                Joachim Wuttke
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15767
Category:                   Modules
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-04 05:56 EDT
Last Modified:              2015-10-04 05:56 EDT
====================================================================== 
Summary:                    FindBoost not appropriate for header-only modules
Description: 
FindBoost is not appropriate for boost modules that comprise but an include
header, and no compiled library. Using FindBoost for such modules raises an
inappropriate error.

Minimal solution: state the above in the doc page FindBoost.html.

Preferred solution: add support header-only modules to FindBoost
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-04 05:56 Joachim Wuttke New Issue                                    
======================================================================


From steveire at gmail.com  Sun Oct  4 10:47:40 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 04 Oct 2015 16:47:40 +0200
Subject: [cmake-developers] CXX_STANDARD and linking
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
Message-ID: <mure6c$sp4$1@ger.gmane.org>

Brad King wrote:

> On 09/28/2015 03:20 PM, Brad King wrote:
>> for now we should look at turning off all language standard and
>> compile feature support for SolarisStudio when not hosted on Linux.
> 
> Done here:
> 
>  Features: Disable support for Oracle SolarisStudio on non-Linux
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73
> 
>  Tests: Suppress WriteCompilerDetectionHeader failure on SunPro
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594
> 
> I also made a fix for Linux:
> 
>  Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d
> 
> Steve, please review these changes.

Thanks, I've put some thought into this now.

The existing CMake feature deals with compilation, but does not deal with 
linking. 

We pass -std=foo when compiling but not when linking. In the case of GNU and 
Clang, this works because the standard library binary is the same regardless 
of that flag. I did some experiements, and 

* passing no -std flag
* passing -std=c++11
* passing -std=gnu++11

each resulted in invoking collect2 or ld with identical parameters for GNU 
and Clang in respective situations.

For Solaris, the situation is different. My understanding of standard 
libraries there is summarized here:

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c69ec6f

Namely, we can pass -std=c++03 or -std=c++11 in the the compile step to use 
specific dialect features for compilation, but to specify the 
appropriate/corresponding standard library (the GNU one) we also need to 
specify one of those flags at link time.

Currently cmake has no feature for specifying flags to use at link time for 
a particular standard library. This missing feature is also apparent when 
noting that we can specify a particular standard library to Clang by using 
the -stdlib=libc++ or -stdlib=libstdc++ flags. Using GNU we can specify the 
flag -nodefaultlibs to avoid automatic linking with libstdc++ and then 
specify additional flags to compile and link to libc++ if we wish.

This is the same missing feature whether talking about SolarisStudio, GNU, 
or Clang.

I think the current state is that CMake-compile-features can work with 
SolarisStudio to specify compile flags, but CMake currently has no feature 
for inferring link flags as a result of that. That is, the responsibility 
for specifying the link flags remains with the user for now. 

So, is this thread really about a bug, or is it a feature request? 

Perhaps those commits should be reverted. I see no reason for SolarisStudio 
on linux to behave any differently than on solaris, so the commit relating 
to that is probably not appropriate. When testing the compiler on linux, it 
is possible that I was operating as if the link flags were user 
responsibility and had configured my environment accordingly (though I don't 
remember).

I wrote here some ideas of a design for specifying the standard library to 
use: 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296

Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the 
linker, we should work more on a design like the above way to specify a 
standard library. 

The compile features can imply a default and a set of allowed alternatives 
(for example, compiling with cxx_static_assert implies the use of stdlibc++ 
or libc++ with Clang by default but there is a way to use the other 
instead).  The COMPATIBLE_INTERFACE features may also be used to ensure that 
targets which link together all use the same standard library.

Thanks,

Steve.



From steveire at gmail.com  Sun Oct  4 10:49:17 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 4 Oct 2015 14:49:17 +0000 (UTC)
Subject: [cmake-developers] Importing platform SDK libraries without a
	full path
References: <555DE535.4020707@kitware.com> <mjv4fr$aal$1@ger.gmane.org>
 <5564BCB2.2000600@kitware.com> <mk2no4$qsk$1@ger.gmane.org>
 <5565C35B.9090108@kitware.com> <mk5334$19u$1@ger.gmane.org>
 <55662CE2.4090002@kitware.com> <mk5elk$4ir$1@ger.gmane.org>
 <55688316.3040306@kitware.com>
Message-ID: <loom.20151004T164752-225@post.gmane.org>

Brad King <brad.king at ...> writes:

> >> Actually I think this can and should be done for INTERFACE libraries
> >> even without IMPORTED_LIBNAME.  I'll look at factoring this part out
> >> into a preceding commit.
> > 
> > Cool, I think reviewing that separately would be preferable. 
> > 
> > I'm interested to see what it looks like without IMPORTED_LIBNAME and where 
> > the default mapping will come from then, or if there just won't be a
default 
> > mapping until the INTERFACE library becomes 'particular' to something else 
> > with IMPORTED_LIBNAME.
> 
> I agree.  We should resolve configuration mapping for INTERFACE
> libraries first.
> 
> I need to revert the 'imported-interface-libname' topic from 'next'
> in preparation for the 3.3 freeze anyway.  After that we can return
> first to INTERFACE configuration mapping and later to link items.

I wonder if you plan do resolve this part in the coming cycle? I think
resolving that part would help me to understand the rest of your proposal in
the thread.

Thanks,

Steve.



From daniel.wirtz at simtech.uni-stuttgart.de  Mon Oct  5 06:50:41 2015
From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz)
Date: Mon, 5 Oct 2015 12:50:41 +0200
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
Message-ID: <56125601.8090300@simtech.uni-stuttgart.de>

Hey all,

thanks for the feedback, i've included most of it.

Regarding the configure/build issue: that indeed is inconvenient and may 
cause irritation. on the other side, if there has been git activity 
fussing with any source files affecting the build, cmake will run again 
and hence capture the possibly new git info. so the case where you 
change the revision after configure to an extent where cmake will not 
automatically re-run is uncommon, at least for my guessing.
however, i've included an explicit warning in the docs to raise awareness.

i'm happy to provide a suitable procedure that is flexible enough; 
providing scripts that configure files (like with sprokit) seems too 
specific as people might want to have a single "config.h" file or so 
containing more than just the git info.
i've thought about the possibility to generate an explicit 
"git_version.h" file to include, but that 1) restricts possible 
languages and 2) will require an extra build target that is run each 
build etc. any thoughts?

Daniel

Signed-off-by: Daniel Wirtz <daniel.wirtz at simtech.uni-stuttgart.de>
---
  Modules/FindGit.cmake | 145 
+++++++++++++++++++++++++++++++++++++++++++++++---
  1 file changed, 138 insertions(+), 7 deletions(-)

diff --git a/Modules/FindGit.cmake b/Modules/FindGit.cmake
index b4f7b4b..e8a86f5 100644
--- a/Modules/FindGit.cmake
+++ b/Modules/FindGit.cmake
@@ -2,28 +2,75 @@
  # FindGit
  # -------
  #
+# This module helps finding a local Git_ installation and provides 
convenience functions for common Git queries.
  #
+# .. _Git: http://git-scm.com/
  #
-# The module defines the following variables:
+# Defined variables
+# """""""""""""""""
  #
-# ::
+# :variable:`GIT_EXECUTABLE`
+#    Path to Git_ command line client
+# :variable:`GIT_FOUND`
+#    True if the Git_ command line client was found
+# :variable:`GIT_VERSION_STRING`
+#    The version of Git_ found (since CMake 2.8.8)
+#
+# Defined functions
+# """""""""""""""""
+#
+# For convenience, the module provides the additional functions
+#
+# :command:`git_get_revision`
+#     Get commit revision number information. +#
+# :command:`git_get_branch` +#     Get current branch information.
  #
-#    GIT_EXECUTABLE - path to git command line client
-#    GIT_FOUND - true if the command line client was found
-#    GIT_VERSION_STRING - the version of git found (since CMake 2.8.8)
+# **WARNING**
  #
-# Example usage:
+# If you use those functions at *configure* time and checkout a 
different Git_ revision after running :manual:`cmake(1)`,
+# the information from :command:`git_get_revision` or 
:command:`git_get_branch` will be outdated.
+# If you need to be sure, we recommend using 
:command:`add_custom_command` or :command:`add_custom_target` in 
conjunction with
+# the :manual:`cmake(1)` script mode (:code:`-P`) to ensure the Git_ 
information is obtained at *build* time.  +# +#
+# Example usage
+# """""""""""""
  #
  # ::
  #
  #    find_package(Git)
  #    if(GIT_FOUND)
  #      message("git found: ${GIT_EXECUTABLE}")
+#      git_get_branch(GITBRANCH)
+#      message("current branch at ${CMAKE_CURRENT_SOURCE_DIR}: 
${GITBRANCH}")
  #    endif()
+#
+# Details
+# """""""
+#
+# .. variable:: GIT_EXECUTABLE
+#
+#    Returns the full path to the Git_ executable to use in e.g. 
:command:`add_custom_command` like
+#
+# ::
+#
+#        add_custom_command(COMMAND ${GIT_EXECUTABLE} clone 
https://github.com/myrepo mydir)
+#    +# .. variable:: GIT_FOUND
+#
+#    Boolean variable set to TRUE if a local Git_ was found, FALSE else.
+# +# .. variable:: GIT_VERSION_STRING
+#
+#    The output of :code:`git --version`
+
 
#=============================================================================
  # Copyright 2010 Kitware, Inc.
  # Copyright 2012 Rolf Eike Beer <eike at sf-mail.de>
+# Copyright 2015 Daniel Wirtz <daniel.wirtz at simtech-uni-stuttgart.de>
  #
  # Distributed under the OSI-approved BSD License (the "License");
  # see accompanying file Copyright.txt for details.
@@ -73,7 +120,91 @@ endif()
  # Handle the QUIETLY and REQUIRED arguments and set GIT_FOUND to TRUE if
  # all listed variables are TRUE
  -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+include(FindPackageHandleStandardArgs)
  find_package_handle_standard_args(Git
                                    REQUIRED_VARS GIT_EXECUTABLE
                                    VERSION_VAR GIT_VERSION_STRING)
+
+# Convenience Git repo & branch information functions
+
+#.rst:
+# .. command:: git_get_revision
+#
+# ::
+#
+#     git_get_revision(VARNAME
+#        [SHORT]
+#        [GIT_OPTIONS] <string>
+#        [WORKING_DIRECTORY] <directory>)
+#
+# Obtain Git_ revision information using the rev-parse_ command. 
Effectively calls :code:`rev-parse [GIT_OPTIONS] --verify -q HEAD`.
+#
+# ``VARNAME``
+#    The workspace variable name to assign the result to.
+#
+# ``SHORT``
+#    Optional. If set to TRUE, the short revision string will be 
returned. Otherwise, the full revision hash is returned.
+#
+# ``GIT_OPTIONS``
+#    Optional. Specify a string like :code:`"--sq"` to add to the 
options of the rev-parse_ command.
+#
+# .. _rev-parse: 
https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
+#
+# ``WORKING_DIRECTORY``
+#   The working directory at which to execute the git commands.
+#   If not specified, :variable:`CMAKE_CURRENT_SOURCE_DIR` is assumed. 
+function(git_get_revision VARNAME)
+    if (NOT GIT_FOUND)
+        message(FATAL_ERROR "Cannot use git_get_revision: Git was not 
found.")
+    endif()
+    +    cmake_parse_arguments(GIT "SHORT" 
"WORKING_DIRECTORY;GIT_OPTIONS" "" ${ARGN})
+    +    if(NOT GIT_WORKING_DIRECTORY OR "${GIT_WORKING_DIRECTORY}" 
STREQUAL "")
+        set(GIT_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
+    endif()
+    execute_process(COMMAND ${GIT_EXECUTABLE} rev-parse ${GIT_OPTIONS} 
--verify -q HEAD
+        OUTPUT_VARIABLE RES
+        ERROR_VARIABLE ERR
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+        WORKING_DIRECTORY ${GIT_WORKING_DIRECTORY})
+    set(${VARNAME} ${RES} PARENT_SCOPE)
+    if (ERR)
+        message(WARNING "Issuing Git command '${GIT_EXECUTABLE} 
rev-parse --verify -q HEAD' failed: ${ERR}")
+    endif()
+endfunction()
+
+#.rst:
+# .. command:: git_get_branch
+#
+# ::
+#
+#     git_get_branch(VARNAME
+#        [WORKING_DIRECTORY] <directory>)
+#
+# ``VARNAME``
+#    The workspace variable name to assign the result to.
+#
+# ``WORKING_DIRECTORY``
+#   The working directory at which to execute the git commands.
+#   If not specified, :variable:`CMAKE_CURRENT_SOURCE_DIR` is assumed.
+function(git_get_branch VARNAME)
+    if (NOT GIT_FOUND)
+        message(FATAL_ERROR "Cannot use git_get_branch: Git was not 
found.")
+    endif()
+    +    cmake_parse_arguments(GIT "" "WORKING_DIRECTORY" "" ${ARGN})
+
+    if(NOT GIT_WORKING_DIRECTORY OR "${GIT_WORKING_DIRECTORY}" STREQUAL "")
+        set(GIT_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
+    endif()
+    execute_process(COMMAND ${GIT_EXECUTABLE} symbolic-ref -q HEAD
+        OUTPUT_VARIABLE RES
+        ERROR_VARIABLE ERR
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+        WORKING_DIRECTORY ${GIT_WORKING_DIRECTORY})
+    if (ERR)
+        message(WARNING "Issuing Git command '${GIT_EXECUTABLE} 
symbolic-ref -q HEAD' failed: ${ERR}")
+    endif()
+    set(${VARNAME} ${RES} PARENT_SCOPE)
+endfunction()
\ No newline at end of file
-- 
1.9.1


From eike at sf-mail.de  Mon Oct  5 07:05:22 2015
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 05 Oct 2015 13:05:22 +0200
Subject: [cmake-developers]
 =?utf-8?q?added_get=5Fgit=5Frevision_and_get?=
 =?utf-8?q?=5Fgit=5Fbranch_commands_as_follow-up_to_cmake=40cmake=2Eorg?=
In-Reply-To: <56125601.8090300@simtech.uni-stuttgart.de>
References: <56125601.8090300@simtech.uni-stuttgart.de>
Message-ID: <c15e5f76d5e8b1b5cb2dbe849497a709@sf-mail.de>

> +    endif()
> +    set(${VARNAME} ${RES} PARENT_SCOPE)
> +endfunction()
> \ No newline at end of file

Bug ;)

From pascal.bach at siemens.com  Mon Oct  5 09:35:31 2015
From: pascal.bach at siemens.com (Pascal Bach)
Date: Mon, 5 Oct 2015 15:35:31 +0200
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
In-Reply-To: <56125601.8090300@simtech.uni-stuttgart.de>
References: <56125601.8090300@simtech.uni-stuttgart.de>
Message-ID: <56127CA3.8010102@siemens.com>

Hi Daniel

I just wanted to let you know that I was planing to bring a git versioning script upstream soon.
It is based on the following sequence of commands: https://github.com/bufferoverflow/proxyme/blob/master/CMakeLists.txt#L5

It tries to generate a version string of the following form: {git-tag} ({git-hash}-{dirty}).

It will try to do the best possible to figure out the tag:
-    If on a valid tag: v1.1.0 (f567657)
-    If no tag but clean workdir: undefined (f567657)
-    If not tag and working tree with uncommited changes: undefined (f567657-dirty)

This -dirty convention is the same as used by u-boot and the linux kernel.
Maybe you can incorperate these ideas into your solution too.

Regards
Pascal

Am 05.10.2015 um 12:50 schrieb Daniel Wirtz:
> Hey all,
>
> thanks for the feedback, i've included most of it.
>
> Regarding the configure/build issue: that indeed is inconvenient and may cause irritation. on the other side, if there has been git activity fussing with any source files affecting the build, cmake will run again and hence capture the possibly new git info. so the case where you change the revision after configure to an extent where cmake will not automatically re-run is uncommon, at least for my guessing.
> however, i've included an explicit warning in the docs to raise awareness.
>
> i'm happy to provide a suitable procedure that is flexible enough; providing scripts that configure files (like with sprokit) seems too specific as people might want to have a single "config.h" file or so containing more than just the git info.
> i've thought about the possibility to generate an explicit "git_version.h" file to include, but that 1) restricts possible languages and 2) will require an extra build target that is run each build etc. any thoughts?
>
> Daniel
>
> Signed-off-by: Daniel Wirtz <daniel.wirtz at simtech.uni-stuttgart.de>
> ---
>  Modules/FindGit.cmake | 145 +++++++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 138 insertions(+), 7 deletions(-)
>
> diff --git a/Modules/FindGit.cmake b/Modules/FindGit.cmake
> index b4f7b4b..e8a86f5 100644
> --- a/Modules/FindGit.cmake
> +++ b/Modules/FindGit.cmake
> @@ -2,28 +2,75 @@
>  # FindGit
>  # -------
>  #
> +# This module helps finding a local Git_ installation and provides convenience functions for common Git queries.
>  #
> +# .. _Git: http://git-scm.com/
>  #
> -# The module defines the following variables:
> +# Defined variables
> +# """""""""""""""""
>  #
> -# ::
> +# :variable:`GIT_EXECUTABLE`
> +#    Path to Git_ command line client
> +# :variable:`GIT_FOUND`
> +#    True if the Git_ command line client was found
> +# :variable:`GIT_VERSION_STRING`
> +#    The version of Git_ found (since CMake 2.8.8)
> +#
> +# Defined functions
> +# """""""""""""""""
> +#
> +# For convenience, the module provides the additional functions
> +#
> +# :command:`git_get_revision`
> +#     Get commit revision number information. +#
> +# :command:`git_get_branch` +#     Get current branch information.
>  #
> -#    GIT_EXECUTABLE - path to git command line client
> -#    GIT_FOUND - true if the command line client was found
> -#    GIT_VERSION_STRING - the version of git found (since CMake 2.8.8)
> +# **WARNING**
>  #
> -# Example usage:
> +# If you use those functions at *configure* time and checkout a different Git_ revision after running :manual:`cmake(1)`,
> +# the information from :command:`git_get_revision` or :command:`git_get_branch` will be outdated.
> +# If you need to be sure, we recommend using :command:`add_custom_command` or :command:`add_custom_target` in conjunction with
> +# the :manual:`cmake(1)` script mode (:code:`-P`) to ensure the Git_ information is obtained at *build* time.  +# +#
> +# Example usage
> +# """""""""""""
>  #
>  # ::
>  #
>  #    find_package(Git)
>  #    if(GIT_FOUND)
>  #      message("git found: ${GIT_EXECUTABLE}")
> +#      git_get_branch(GITBRANCH)
> +#      message("current branch at ${CMAKE_CURRENT_SOURCE_DIR}: ${GITBRANCH}")
>  #    endif()
> +#
> +# Details
> +# """""""
> +#
> +# .. variable:: GIT_EXECUTABLE
> +#
> +#    Returns the full path to the Git_ executable to use in e.g. :command:`add_custom_command` like
> +#
> +# ::
> +#
> +#        add_custom_command(COMMAND ${GIT_EXECUTABLE} clone https://github.com/myrepo mydir)
> +#    +# .. variable:: GIT_FOUND
> +#
> +#    Boolean variable set to TRUE if a local Git_ was found, FALSE else.
> +# +# .. variable:: GIT_VERSION_STRING
> +#
> +#    The output of :code:`git --version`
> +
>
> #=============================================================================
>  # Copyright 2010 Kitware, Inc.
>  # Copyright 2012 Rolf Eike Beer <eike at sf-mail.de>
> +# Copyright 2015 Daniel Wirtz <daniel.wirtz at simtech-uni-stuttgart.de>
>  #
>  # Distributed under the OSI-approved BSD License (the "License");
>  # see accompanying file Copyright.txt for details.
> @@ -73,7 +120,91 @@ endif()
>  # Handle the QUIETLY and REQUIRED arguments and set GIT_FOUND to TRUE if
>  # all listed variables are TRUE
>  -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
> +include(FindPackageHandleStandardArgs)
>  find_package_handle_standard_args(Git
>                                    REQUIRED_VARS GIT_EXECUTABLE
>                                    VERSION_VAR GIT_VERSION_STRING)
> +
> +# Convenience Git repo & branch information functions
> +
> +#.rst:
> +# .. command:: git_get_revision
> +#
> +# ::
> +#
> +#     git_get_revision(VARNAME
> +#        [SHORT]
> +#        [GIT_OPTIONS] <string>
> +#        [WORKING_DIRECTORY] <directory>)
> +#
> +# Obtain Git_ revision information using the rev-parse_ command. Effectively calls :code:`rev-parse [GIT_OPTIONS] --verify -q HEAD`.
> +#
> +# ``VARNAME``
> +#    The workspace variable name to assign the result to.
> +#
> +# ``SHORT``
> +#    Optional. If set to TRUE, the short revision string will be returned. Otherwise, the full revision hash is returned.
> +#
> +# ``GIT_OPTIONS``
> +#    Optional. Specify a string like :code:`"--sq"` to add to the options of the rev-parse_ command.
> +#
> +# .. _rev-parse: https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
> +#
> +# ``WORKING_DIRECTORY``
> +#   The working directory at which to execute the git commands.
> +#   If not specified, :variable:`CMAKE_CURRENT_SOURCE_DIR` is assumed. +function(git_get_revision VARNAME)
> +    if (NOT GIT_FOUND)
> +        message(FATAL_ERROR "Cannot use git_get_revision: Git was not found.")
> +    endif()
> +    +    cmake_parse_arguments(GIT "SHORT" "WORKING_DIRECTORY;GIT_OPTIONS" "" ${ARGN})
> +    +    if(NOT GIT_WORKING_DIRECTORY OR "${GIT_WORKING_DIRECTORY}" STREQUAL "")
> +        set(GIT_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
> +    endif()
> +    execute_process(COMMAND ${GIT_EXECUTABLE} rev-parse ${GIT_OPTIONS} --verify -q HEAD
> +        OUTPUT_VARIABLE RES
> +        ERROR_VARIABLE ERR
> +        OUTPUT_STRIP_TRAILING_WHITESPACE
> +        WORKING_DIRECTORY ${GIT_WORKING_DIRECTORY})
> +    set(${VARNAME} ${RES} PARENT_SCOPE)
> +    if (ERR)
> +        message(WARNING "Issuing Git command '${GIT_EXECUTABLE} rev-parse --verify -q HEAD' failed: ${ERR}")
> +    endif()
> +endfunction()
> +
> +#.rst:
> +# .. command:: git_get_branch
> +#
> +# ::
> +#
> +#     git_get_branch(VARNAME
> +#        [WORKING_DIRECTORY] <directory>)
> +#
> +# ``VARNAME``
> +#    The workspace variable name to assign the result to.
> +#
> +# ``WORKING_DIRECTORY``
> +#   The working directory at which to execute the git commands.
> +#   If not specified, :variable:`CMAKE_CURRENT_SOURCE_DIR` is assumed.
> +function(git_get_branch VARNAME)
> +    if (NOT GIT_FOUND)
> +        message(FATAL_ERROR "Cannot use git_get_branch: Git was not found.")
> +    endif()
> +    +    cmake_parse_arguments(GIT "" "WORKING_DIRECTORY" "" ${ARGN})
> +
> +    if(NOT GIT_WORKING_DIRECTORY OR "${GIT_WORKING_DIRECTORY}" STREQUAL "")
> +        set(GIT_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
> +    endif()
> +    execute_process(COMMAND ${GIT_EXECUTABLE} symbolic-ref -q HEAD
> +        OUTPUT_VARIABLE RES
> +        ERROR_VARIABLE ERR
> +        OUTPUT_STRIP_TRAILING_WHITESPACE
> +        WORKING_DIRECTORY ${GIT_WORKING_DIRECTORY})
> +    if (ERR)
> +        message(WARNING "Issuing Git command '${GIT_EXECUTABLE} symbolic-ref -q HEAD' failed: ${ERR}")
> +    endif()
> +    set(${VARNAME} ${RES} PARENT_SCOPE)
> +endfunction()
> \ No newline at end of file


From mantis at public.kitware.com  Mon Oct  5 10:13:25 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 5 Oct 2015 10:13:25 -0400
Subject: [cmake-developers] [CMake 0015768]: install command does not
	install symbolic link for a versioned shared library
Message-ID: <a03bd1d4d6247a6527f725eff26c7d90@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15768 
====================================================================== 
Reported By:                Francis ANDRE
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15768
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-05 10:13 EDT
Last Modified:              2015-10-05 10:13 EDT
====================================================================== 
Summary:                    install command does not install symbolic link for a
versioned shared library
Description: 
Hi

This command
install(
    TARGETS "${target_name}" EXPORT "${target_name}Targets"
    LIBRARY DESTINATION lib${LIB_SUFFIX}
    ARCHIVE DESTINATION lib${LIB_SUFFIX}
    RUNTIME DESTINATION bin
    INCLUDES DESTINATION include
    )

install the lib shared library with a symbolic link on Linux while it does not
install a symbolic link on the archive on Cygwin, neither he does install a
symbolic link on the runtime destination

Steps to Reproduce: 
1/ Build a shared library on Cygwin
2/ install it
3/ No symbolic link are defined for the archive library, nor for the shared
library.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-05 10:13 Francis ANDRE  New Issue                                    
======================================================================


From raffi.enficiaud at free.fr  Mon Oct  5 10:19:11 2015
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Mon, 5 Oct 2015 16:19:11 +0200
Subject: [cmake-developers] [Patch] Updated FindMatlab.cmake for Matlab
	R2015b
In-Reply-To: <CCACAFB3-7FD3-4F24-AAB0-80267E4C4281@gmail.com>
References: <CCACAFB3-7FD3-4F24-AAB0-80267E4C4281@gmail.com>
Message-ID: <98388CCB-1AF1-4D9D-BDB8-DB76EA48BBD2@free.fr>

Thanks,

I think Brad already applied your patch (so thanks Brad!)

Best,
Raffi


> On 03 Oct 2015, at 10:51, Francesco Romano <francesco.romano.1987 at gmail.com> wrote:
> 
> Added support to Matlab 8.6 (R2015b)
> 
> Attached is the patch.
> 
> 
> <0001-Updated-FindMatlab.cmake-to-find-Matlab-R2015b.patch>
> 
> Thank you
> Francesco-- 
> 
> 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  Mon Oct  5 10:37:39 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 5 Oct 2015 10:37:39 -0400
Subject: [cmake-developers] [CMake 0015769]: Change of CMakeLists.txt
	doesn't trigger reconfigure
Message-ID: <1ca07866774f1e006f043586d7ffde93@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15769 
====================================================================== 
Reported By:                Ruslan Baratov
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15769
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-05 10:37 EDT
Last Modified:              2015-10-05 10:37 EDT
====================================================================== 
Summary:                    Change of CMakeLists.txt doesn't trigger reconfigure
Description: 
`cmake --build` command doesn't trigger reconfiguration of the project on OS X
when CMakeLists.txt changed.

Example:

add_executable(foo foo.cpp) # file foo.cpp exists

cmake -H. -B_builds
cmake --build _builds
# OK

change:
add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
cmake --build _builds
# expected error, but no error reported

Ready-to-run example can be found:
https://github.com/forexample/cmake-osx-no-reconfigure-bug

Log from OS X machine:
* https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171

Log for similar test on Linux machine:
* https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953

CMake on Linux machine run reconfigure command and report an error:
  cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
  -- Configuring done
  CMake Error at CMakeLists.txt:4 (add_executable):
    Cannot find source file:
      boo.cpp

same error expected on OS X machine
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-05 10:37 Ruslan Baratov New Issue                                    
======================================================================


From brad.king at kitware.com  Mon Oct  5 11:27:26 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 05 Oct 2015 11:27:26 -0400
Subject: [cmake-developers] [Patch] Updated FindMatlab.cmake for Matlab
 R2015b
In-Reply-To: <CCACAFB3-7FD3-4F24-AAB0-80267E4C4281@gmail.com>
References: <CCACAFB3-7FD3-4F24-AAB0-80267E4C4281@gmail.com>
Message-ID: <561296DE.7030603@kitware.com>

On 10/03/2015 04:51 AM, Francesco Romano wrote:
> Added support to Matlab 8.6 (R2015b)

Applied, thanks:

 FindMatlab: Add support for Matlab R2015b
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2775768f

-Brad

From brad.king at kitware.com  Mon Oct  5 11:27:33 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 05 Oct 2015 11:27:33 -0400
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
Message-ID: <561296E5.60300@kitware.com>

On 10/03/2015 05:00 AM, Francesco Romano wrote:
> I don't know if this is the right mailing list

This is a good place since it concerns a new OS X release.

> I needed to set the variable `CMAKE_OSX_DEPLOYMENT_TARGET` to 10.10 and this
> was done after the first "project" call.

That should be right, though I cannot say for sure without seeing the code.
Typically we do not have the project code set this value but instead add
it to the CMake command line when building for deployment:

 -DCMAKE_OSX_DEPLOYMENT_TARGET=10.10

> elseif("${CMAKE_GENERATOR}" MATCHES Xcode
>        OR CMAKE_OSX_DEPLOYMENT_TARGET
>        OR CMAKE_OSX_ARCHITECTURES MATCHES "[^;]"
>        OR NOT EXISTS "/usr/include/sys/types.h")
> 
> Now, the question is: why the Unix Makefile should  not  need the
> variable "CMAKE_OSX_SYSROOT" but only if the deployment target is not set?
> Shouldn't be correct to set anyway the sysroot (which by the way can be
> easily found because Xcode is present on the machine)?

The Unix Makefiles generator also supports the Xcode command-line tools,
third-party compilers, etc. that all build for the host system.  If you
are explicitly building for deployment then you should specify

 -DCMAKE_OSX_SYSROOT=/path/to/10.10/SDK

The Xcode generator searches for a sysroot even when not using an
explicit deployment target because Xcode always wants one specified
and does not support the pure command-line tools.

-Brad


From brad.king at kitware.com  Mon Oct  5 11:27:46 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 05 Oct 2015 11:27:46 -0400
Subject: [cmake-developers] [Patch] Adding Windows 10 Universal app
	support
In-Reply-To: <CY1PR0301MB0713861934D430CFC93420D0984B0@CY1PR0301MB0713.namprd03.prod.outlook.com>
References: <CY1PR0301MB0713861934D430CFC93420D0984B0@CY1PR0301MB0713.namprd03.prod.outlook.com>
Message-ID: <561296F2.1090506@kitware.com>

On 10/02/2015 03:07 PM, Gilles Khouzam wrote:
> This patch adds Windows Universal (store) app support.

Thanks.

I think mapping version "10.0" with no further components to the
latest SDK is a good idea not just for universal apps but also for
desktop.  I split that out into a separate change:

 VS: Select latest Windows 10 SDK if no specific version was requested
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45812111

Then I split the rest of the changes up into a few more commits:

 VS: Select Windows 10 Store SDK and toolset for VS 2015
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1b87d72

 MSVC: Add system libs for WindowsStore on VS 2015
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c426183

 VS: Refactor indentation of LinkLibraryDependencies
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2798dbda

 VS: Add support for Windows 10 Universal (Store) Applications
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1be2f12c

Finally I updated a bit more documentation:

 Help: Document Windows 10 Universal Applications in cmake-toolchains(7)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2402bb8c

This is all now in 'master' and in the 'release' branch for 3.4.

-Brad


From brad.king at kitware.com  Mon Oct  5 11:27:56 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 05 Oct 2015 11:27:56 -0400
Subject: [cmake-developers] CMake 3.4 feature freeze on 2015-10-01
In-Reply-To: <560D6552.2050108@kitware.com>
References: <55F04ADB.1000003@kitware.com> <560D6552.2050108@kitware.com>
Message-ID: <561296FC.8040205@kitware.com>

On 10/01/2015 12:54 PM, Brad King wrote:
> I'll announce when post-3.4 development in 'next' is open.

I've branched 'release' for 3.4.  The repository is now open for
post-3.4 development.  Please rebase any open topics on 'master'
before merging to 'next'.

> * Documentation updates
> * Regression fixes
> * Fixes for bugs in features new to 3.4

These types of changes may still be accepted to 'release' during
the 3.4 release candidate cycle.  The 3.4 release is now closed
to new features and general bug fixes.

-Brad

From brad.king at kitware.com  Mon Oct  5 11:31:04 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 05 Oct 2015 11:31:04 -0400
Subject: [cmake-developers] Rename suffix of Mac OS Framework
In-Reply-To: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at>
References: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at>
Message-ID: <561297B8.2010507@kitware.com>

On 10/01/2015 04:07 AM, Roman W?ger wrote:
> set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE)
> 
> Is there a way to rename the suffix ".framework"?

Not currently.  It is hard-coded here:

 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGeneratorTarget.cxx;hb=679a5d21#l2981

What is the use case for changing the framework extension?
Doing so breaks the basic layout defined in "man ld":

     -framework name[,suffix]
                 This option tells the linker to search for `name.frame-
                 work/name' the framework search path.  If the optional
                 suffix is specified the framework is first searched for
                 the name with the suffix and then without (e.g. look
                 for `name.framework/name_suffix' first, if not there
                 try `name.framework/name').

-Brad


From tamas.kenez at gmail.com  Mon Oct  5 16:36:41 2015
From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=)
Date: Mon, 5 Oct 2015 22:36:41 +0200
Subject: [cmake-developers] script mode current directory
In-Reply-To: <560E7C77.4010105@kitware.com>
References: <CAPB8=n-CxSZYBbpEnWG=5tdnuiSsipUC3kdXpG1+Z-Ck-9o1SA@mail.gmail.com>
 <CAA2GJqVzDi8NicMkZFkC2c5KFcwtn3CNjo15AQbd4830cnhEDg@mail.gmail.com>
 <560E7C77.4010105@kitware.com>
Message-ID: <CAPB8=n8URmAu-voH6PitKaMAYwUOeF8uJc9XW=ho-OT1MR5-6A@mail.gmail.com>

Here is the patch which documents and tests those 4 variables in script
mode, based on master:
-----------


>From f1a6f5e258321317a8086d0538e0a3240d980731 Mon Sep 17 00:00:00 2001
From: Tamas Kenez <tamas.kenez at gmail.com>
Date: Mon, 5 Oct 2015 22:12:30 +0200
Subject: [PATCH] Document and test CMAKE_[CURRENT_](BINARY|SOURCE)_DIR in
 script mode

---
 Help/variable/CMAKE_BINARY_DIR.rst             |  5 +++++
 Help/variable/CMAKE_CURRENT_BINARY_DIR.rst     |  5 +++++
 Help/variable/CMAKE_CURRENT_SOURCE_DIR.rst     |  8 ++++++++
 Help/variable/CMAKE_SOURCE_DIR.rst             |  8 ++++++++
 Tests/RunCMake/CommandLine/P_working-dir.cmake | 14 ++++++++++++++
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake  |  5 +++++
 6 files changed, 45 insertions(+)
 create mode 100644 Tests/RunCMake/CommandLine/P_working-dir.cmake

diff --git a/Help/variable/CMAKE_BINARY_DIR.rst
b/Help/variable/CMAKE_BINARY_DIR.rst
index f8dd8ab..3b323b7 100644
--- a/Help/variable/CMAKE_BINARY_DIR.rst
+++ b/Help/variable/CMAKE_BINARY_DIR.rst
@@ -6,3 +6,8 @@ The path to the top level of the build tree.
 This is the full path to the top level of the current CMake build
 tree.  For an in-source build, this would be the same as
 :variable:`CMAKE_SOURCE_DIR`.
+
+When run in -P script mode, CMake sets the variables
+:variable:`CMAKE_BINARY_DIR`, :variable:`CMAKE_SOURCE_DIR`,
+:variable:`CMAKE_CURRENT_BINARY_DIR` and
+:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.
diff --git a/Help/variable/CMAKE_CURRENT_BINARY_DIR.rst
b/Help/variable/CMAKE_CURRENT_BINARY_DIR.rst
index cc3b639..40496b5 100644
--- a/Help/variable/CMAKE_CURRENT_BINARY_DIR.rst
+++ b/Help/variable/CMAKE_CURRENT_BINARY_DIR.rst
@@ -8,3 +8,8 @@ processed by cmake.  Each directory added by
:command:`add_subdirectory` will
 create a binary directory in the build tree, and as it is being
 processed this variable will be set.  For in-source builds this is the
 current source directory being processed.
+
+When run in -P script mode, CMake sets the variables
+:variable:`CMAKE_BINARY_DIR`, :variable:`CMAKE_SOURCE_DIR`,
+:variable:`CMAKE_CURRENT_BINARY_DIR` and
+:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.
diff --git a/Help/variable/CMAKE_CURRENT_SOURCE_DIR.rst
b/Help/variable/CMAKE_CURRENT_SOURCE_DIR.rst
index db063a4..728291e 100644
--- a/Help/variable/CMAKE_CURRENT_SOURCE_DIR.rst
+++ b/Help/variable/CMAKE_CURRENT_SOURCE_DIR.rst
@@ -5,3 +5,11 @@ The path to the source directory currently being processed.

 This the full path to the source directory that is currently being
 processed by cmake.
+
+When run in -P script mode, CMake sets this variable to the current
+working directory.
+
+When run in -P script mode, CMake sets the variables
+:variable:`CMAKE_BINARY_DIR`, :variable:`CMAKE_SOURCE_DIR`,
+:variable:`CMAKE_CURRENT_BINARY_DIR` and
+:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.
diff --git a/Help/variable/CMAKE_SOURCE_DIR.rst
b/Help/variable/CMAKE_SOURCE_DIR.rst
index 3df0226..3644bbb 100644
--- a/Help/variable/CMAKE_SOURCE_DIR.rst
+++ b/Help/variable/CMAKE_SOURCE_DIR.rst
@@ -6,3 +6,11 @@ The path to the top level of the source tree.
 This is the full path to the top level of the current CMake source
 tree.  For an in-source build, this would be the same as
 :variable:`CMAKE_BINARY_DIR`.
+
+When run in -P script mode, CMake sets this variable to the current
+working directory.
+
+When run in -P script mode, CMake sets the variables
+:variable:`CMAKE_BINARY_DIR`, :variable:`CMAKE_SOURCE_DIR`,
+:variable:`CMAKE_CURRENT_BINARY_DIR` and
+:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.
diff --git a/Tests/RunCMake/CommandLine/P_working-dir.cmake
b/Tests/RunCMake/CommandLine/P_working-dir.cmake
new file mode 100644
index 0000000..4ea0293
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/P_working-dir.cmake
@@ -0,0 +1,14 @@
+if(NOT IS_DIRECTORY "${EXPECTED_WORKING_DIR}")
+  message(FATAL_ERROR "EXPECTED_WORKING_DIR is not a directory:
${EXPECTED_WORKING_DIR}")
+endif()
+
+foreach(d CMAKE_BINARY_DIR CMAKE_CURRENT_BINARY_DIR CMAKE_SOURCE_DIR
CMAKE_CURRENT_SOURCE_DIR)
+  if(NOT DEFINED ${d})
+    message(FATAL_ERROR "${d} is not defined")
+  endif()
+  if(EXPECTED_WORKING_DIR STREQUAL "${${d}}")
+    message(STATUS "${d} is the expected working directory
(${EXPECTED_WORKING_DIR})")
+  else()
+    message(FATAL_ERROR "${d} = \"${${d}}\" is not the expected working
directory (${EXPECTED_WORKING_DIR})")
+  endif()
+endforeach()
diff --git a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
index cef6368..3cc9225 100644
--- a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
+++ b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
@@ -22,6 +22,11 @@ run_cmake_command(G_bad-arg ${CMAKE_COMMAND} -G
NoSuchGenerator)
 run_cmake_command(P_no-arg ${CMAKE_COMMAND} -P)
 run_cmake_command(P_no-file ${CMAKE_COMMAND} -P nosuchscriptfile.cmake)

+set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/P_working-dir-build)
+file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
+run_cmake_command(P_working-dir ${CMAKE_COMMAND}
-DEXPECTED_WORKING_DIR=${RunCMake_TEST_BINARY_DIR} -P
${RunCMake_SOURCE_DIR}/P_working-dir.cmake)
+unset(RunCMake_TEST_BINARY_DIR)
+
 run_cmake_command(build-no-dir
   ${CMAKE_COMMAND} --build)
 run_cmake_command(build-no-cache
-- 
2.2.1


On Fri, Oct 2, 2015 at 2:45 PM, Brad King <brad.king at kitware.com> wrote:

> On 10/02/2015 08:00 AM, J Decker wrote:
> > On Fri, Oct 2, 2015 at 4:40 AM, Tam?s Ken?z wrote:
> >> In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
> >> variables are set to the current working directory.
> >
> > if CMAKE_[CURRENT]_SOURCE_DIR is current directory; you're doing
> > something wrong :)   That implies that you're doing an in-source build
>
> Tamas is not doing a build at all but instead running
>
>  cmake -P myscript.cmake
>
> and checking the values of these variables.  Yes, the four variables
> are meant to be the current working directory in script mode.  This
> should be added to the documentation, but such a patch should also
> come with an update to the test suite, perhaps in RunCMake/CommandLine,
> that covers the behavior explicitly.
>
> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151005/3ef93a70/attachment.html>

From ctracey at nvidia.com  Mon Oct  5 18:59:30 2015
From: ctracey at nvidia.com (Colin Tracey)
Date: Mon, 5 Oct 2015 22:59:30 +0000
Subject: [cmake-developers] Add more options for NSIS installer artwork
Message-ID: <43cc964ca30f4dd2ad1399a68cad4021@HQMAIL108.nvidia.com>

Hi cmake-developers,

(first of all, this is my first patch submission, so guidance is appreciated, thanks).

I sent a similar patch as plain text in an email to the list last Friday, but after observing the email traffic It looks like you prefer attachments.  I also added documentation to this one.

The spirit of the change is to expose the NSIS option for bitmap artwork that is used for the left side of the windows installer/uninstaller  (documented here: http://nsis.sourceforge.net/Docs/Modern%20UI/Readme.html).  It really allows the user to make the installer generated by cpack a lot nicer looking than the default.

Any and all feedback welcome!
Thanks,
-Colin


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151005/f680f0a2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-options-to-set-the-bitmap-for-NSIS-installer-lef.patch
Type: application/octet-stream
Size: 2946 bytes
Desc: 0001-add-options-to-set-the-bitmap-for-NSIS-installer-lef.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151005/f680f0a2/attachment-0001.obj>

From mantis at public.kitware.com  Mon Oct  5 20:39:51 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 5 Oct 2015 20:39:51 -0400
Subject: [cmake-developers] [CMake 0015770]: newer version have an
	additional directory a tarsal generated under mac
Message-ID: <d97375b5078550f113c71514be5a3ad1@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15770 
====================================================================== 
Reported By:                Charles Doutriaux
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15770
Category:                   CMake
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-05 20:39 EDT
Last Modified:              2015-10-05 20:39 EDT
====================================================================== 
Summary:                    newer version have an additional directory a tarsal
generated under mac
Description: 
some travels generated on Mac get untarred differently since version 3.2

Steps to Reproduce: 
download tarball at:
http://uvcdat.llnl.gov/cdat/resources/x264-snapshot-20150921-2245-stable.tar.gz

This tarsal contains mac "." files including on in the top directory:
-rwxr-xr-x  0 fries2 38282     222 Sep 21 13:45
./._x264-snapshot-20150921-2245-stable
drwxr-xr-x  0 fries2 38282       0 Sep 21 13:45
x264-snapshot-20150921-2245-stable/
-rw-r--r--  0 fries2 38282     222 Sep 21 13:45
x264-snapshot-20150921-2245-stable/._.gitignore
-rw-r--r--  0 fries2 38282     364 Sep 21 13:45
x264-snapshot-20150921-2245-stable/.gitignore
-rw-r--r--  0 fries2 38282     222 Sep 21 13:45
x264-snapshot-20150921-2245-stable/._AUTHORS
-rw-r--r--  0 fries2 38282    2000 Sep 21 13:45
x264-snapshot-20150921-2245-stable/AUTHORS
-rwxr-xr-x  0 fries2 38282     222 Sep 21 13:45
x264-snapshot-20150921-2245-stable/._common


This makes CMake untag the project with one additional directory in version 3.2
and higher

Additional Information: 
cmake module:

  SOURCE_DIR ${x264_source}

see:
https://github.com/UV-CDAT/uvcdat/blob/master/CMake/cdat_modules/x264_external.cmake
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-05 20:39 Charles DoutriauxNew Issue                                    
======================================================================


From ddomenichelli at drdanz.it  Tue Oct  6 07:51:14 2015
From: ddomenichelli at drdanz.it (Daniele E. Domenichelli)
Date: Tue, 6 Oct 2015 13:51:14 +0200
Subject: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11
Message-ID: <5613B5B2.7020201@drdanz.it>

Hello,

Starting with some recent update on my system that updated sigc++ from
2.4.0 to 2.6.1, I noticed that a few GTK2Targets tests depending on
sigc++ are failing.
According to the sigc++ changelog, starting with version 2.5.1, sigc++
requires c++11 enabled, hence this patch.


  FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
  https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f06bd1e


Can you please review it?



Cheers,
 Daniele

From mfgalimullin at yandex.ru  Tue Oct  6 08:22:53 2015
From: mfgalimullin at yandex.ru (=?koi8-r?B?7cHS08XM2CDnwczJzdXMzMnO?=)
Date: Tue, 06 Oct 2015 15:22:53 +0300
Subject: [cmake-developers] automatically download library
Message-ID: <579971444134173@web23j.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151006/efcfbc0d/attachment.html>

From cmake-2015 at ryandesign.com  Tue Oct  6 08:33:20 2015
From: cmake-2015 at ryandesign.com (Ryan Schmidt)
Date: Tue, 6 Oct 2015 07:33:20 -0500
Subject: [cmake-developers] automatically download library
In-Reply-To: <579971444134173@web23j.yandex.ru>
References: <579971444134173@web23j.yandex.ru>
Message-ID: <DF826CD4-D8FF-4C9C-9AC0-7C0BD2EFD65B@ryandesign.com>


On Oct 6, 2015, at 7:22 AM, ??????? ?????????? wrote:

> I'm student of the University LETI and as a masrer's thesis I want to develop an extension to CMake. It is expected that this extension will automatically download missing library if instruction such as ?find_package (Boost COMPONENTS system thread REQUIRED)? can not find the package. Could you give me some advices where to begin and which the best direction to design, develop and whether to do it?

If you need that for some special purpose, go for it, but it's probably not a behavior most users would expect, and it's definitely a behavior that would have to be disabled in any software installed by a package management system. (The package management system would want to be in control of what gets downloaded.)



From daniel.wirtz at simtech.uni-stuttgart.de  Tue Oct  6 08:46:37 2015
From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz)
Date: Tue, 6 Oct 2015 14:46:37 +0200
Subject: [cmake-developers] automatically download library
In-Reply-To: <579971444134173@web23j.yandex.ru>
References: <579971444134173@web23j.yandex.ru>
Message-ID: <5613C2AD.9070208@simtech.uni-stuttgart.de>

Hey,

so i've been working on a quite large build system for OpenCMISS, which 
in turn consumes about 30 external packages itself.
the main repo (and cmake logic) can be found here: 
https://github.com/OpenCMISS/manage (branch v1.0).
feel free to have a look around and use some of the logic. essentially, 
it performs checks using find_package and then downloads
the components from our github repos & builds them if not found.

however, such an integration with many many components, difficult 
interoperability and (thus far) unclear origin of the packages that 
should be automatically
installed (you'll need some sort of database / list for that) is quite a 
thing for a masters thesis. not to speak of incompatibilities with other 
system libraries that those
automatically downloaded packages might want to use.
as for ideas, there's the maven concept: https://maven.apache.org/. it's 
not cmake, but it also deals with the "is package there, if not, i know 
where to get & build it" issue.

good luck :-)

Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044

On 10/06/2015 02:22 PM, ??????? ?????????? wrote:
>
> Hello!
> I'm student of the University LETI and as a masrer'sthesis I want to 
> developan extension to CMake. It is expected that this extension will 
> automatically download missinglibrary ifinstruction such as 
> ?find_package (Boost COMPONENTS system thread REQUIRED)? can not find 
> the package. Could you give me some advices where to begin and which 
> the best direction to design, developand whether to do it?
>
> --
> Kind regards,
> Marsel Galimullin.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151006/4e2a0f7d/attachment.html>

From brad.king at kitware.com  Tue Oct  6 08:59:41 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 08:59:41 -0400
Subject: [cmake-developers] automatically download library
In-Reply-To: <579971444134173@web23j.yandex.ru>
References: <579971444134173@web23j.yandex.ru>
Message-ID: <5613C5BD.7040309@kitware.com>

On 10/06/2015 08:22 AM, ??????? ?????????? wrote:
> automatically download missing library if instruction such as
> find_package (Boost COMPONENTS system thread REQUIRED) can not
> find the package.

In general this is outside the scope of a build system and falls
in the domain of package management.  I do not think this approach
is a good fit for CMake's find_package infrastructure as proposed.

FYI, CMake already has some features to help people build projects
without manually installing all dependencies ahead of time.  See
ExternalProject and superbuilds for example:

 http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html

-Brad


From brad.king at kitware.com  Tue Oct  6 09:13:49 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 09:13:49 -0400
Subject: [cmake-developers] Add more options for NSIS installer artwork
In-Reply-To: <43cc964ca30f4dd2ad1399a68cad4021@HQMAIL108.nvidia.com>
References: <43cc964ca30f4dd2ad1399a68cad4021@HQMAIL108.nvidia.com>
Message-ID: <5613C90D.9000906@kitware.com>

On 10/05/2015 06:59 PM, Colin Tracey wrote:
> I sent a similar patch as plain text in an email to the list last
> Friday, but after observing the email traffic It looks like you
> prefer attachments.  I also added documentation to this one.

Inline patches are fine and slightly preferred for me personally
because it is easier to quote hunks while commenting.  I simply
hadn't caught up with all list traffic yet.

Anyway, the change looks good and I've applied it with minor
tweaks:

 CPackNSIS: Add options to set the bitmap for NSIS installer left side
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3758af12

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct  6 09:35:33 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 09:35:33 -0400
Subject: [cmake-developers] script mode current directory
In-Reply-To: <CAPB8=n8URmAu-voH6PitKaMAYwUOeF8uJc9XW=ho-OT1MR5-6A@mail.gmail.com>
References: <CAPB8=n-CxSZYBbpEnWG=5tdnuiSsipUC3kdXpG1+Z-Ck-9o1SA@mail.gmail.com>	<CAA2GJqVzDi8NicMkZFkC2c5KFcwtn3CNjo15AQbd4830cnhEDg@mail.gmail.com>	<560E7C77.4010105@kitware.com>
 <CAPB8=n8URmAu-voH6PitKaMAYwUOeF8uJc9XW=ho-OT1MR5-6A@mail.gmail.com>
Message-ID: <5613CE25.9000602@kitware.com>

On 10/05/2015 04:36 PM, Tam?s Ken?z wrote:
> Here is the patch which documents and tests those 4 variables

Great, thanks.  Applied with minor tweaks:

 Document and test CMAKE_[CURRENT_](BINARY|SOURCE)_DIR in script mode
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bb908b1

-Brad


From francesco.romano.1987 at gmail.com  Tue Oct  6 09:49:13 2015
From: francesco.romano.1987 at gmail.com (Francesco Romano)
Date: Tue, 6 Oct 2015 15:49:13 +0200
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <561296E5.60300@kitware.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com>
Message-ID: <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>

Thanks Brad for the answer.

Maybe I did not understand correctly your answers.
I?ll use as an example two use cases (which by the way are where we detected the issue)
- Compilation of the project. 
I want the user to be able to compile the project on its machine (so build system = deployment system). Of course I can document that he has to explicitly pass the variable to cmake, but it does not seem too user friendly to me
- Brew formula.
I have to use ruby to detect the user platform and configure the arguments to cmake accordingly.

I also want to add that this issue arose with Xcode 7. Indeed Apple ships now (first the first time) only the 10.11 SDK, even if the system is 10.10. And this is what is causing the issue, because cmake automatically set the deployment target to match the sdk and not the build system. The compiled applications are not executable by the system then.

Hope I clarified :)

Ciao
Francesco



> On 05 Oct 2015, at 17:27, Brad King <brad.king at kitware.com> wrote:
> 
> On 10/03/2015 05:00 AM, Francesco Romano wrote:
>> I don't know if this is the right mailing list
> 
> This is a good place since it concerns a new OS X release.
> 
>> I needed to set the variable `CMAKE_OSX_DEPLOYMENT_TARGET` to 10.10 and this
>> was done after the first "project" call.
> 
> That should be right, though I cannot say for sure without seeing the code.
> Typically we do not have the project code set this value but instead add
> it to the CMake command line when building for deployment:
> 
> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.10
> 
>> elseif("${CMAKE_GENERATOR}" MATCHES Xcode
>>       OR CMAKE_OSX_DEPLOYMENT_TARGET
>>       OR CMAKE_OSX_ARCHITECTURES MATCHES "[^;]"
>>       OR NOT EXISTS "/usr/include/sys/types.h")
>> 
>> Now, the question is: why the Unix Makefile should  not  need the
>> variable "CMAKE_OSX_SYSROOT" but only if the deployment target is not set?
>> Shouldn't be correct to set anyway the sysroot (which by the way can be
>> easily found because Xcode is present on the machine)?
> 
> The Unix Makefiles generator also supports the Xcode command-line tools,
> third-party compilers, etc. that all build for the host system.  If you
> are explicitly building for deployment then you should specify
> 
> -DCMAKE_OSX_SYSROOT=/path/to/10.10/SDK
> 
> The Xcode generator searches for a sysroot even when not using an
> explicit deployment target because Xcode always wants one specified
> and does not support the pure command-line tools.
> 
> -Brad
> 


From brad.king at kitware.com  Tue Oct  6 10:00:44 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 10:00:44 -0400
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com> <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
Message-ID: <5613D40C.1060609@kitware.com>

On 10/06/2015 09:49 AM, Francesco Romano wrote:
> - Compilation of the project. 
> I want the user to be able to compile the project on its machine
> (so build system = deployment system). Of course I can document
> that he has to explicitly pass the variable to cmake, but it
> does not seem too user friendly to me

Your project should not be setting CMAKE_OSX_DEPLOYMENT_TARGET
in its code.  If you don't set this then CMAKE_OSX_SYSROOT is
not needed.  Both are meant to be set by end users.  If the
deployment target is their own machine then neither needs to
be set and it should just work.

> - Brew formula.
> I have to use ruby to detect the user platform and configure
> the arguments to cmake accordingly.

If the build targets the current system then again there is no
need to set either variable.  Or, you can set both by using a
symbolic SDK name rather than the path.  For example:

 -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9
 -DCMAKE_OSX_SYSROOT=macosx10.9

> I also want to add that this issue arose with Xcode 7.
> Indeed Apple ships now (first the first time) only the 10.11 SDK,
> even if the system is 10.10. And this is what is causing the issue,
> because cmake automatically set the deployment target to match
> the sdk and not the build system.

Okay, that looks like the underlying issue.  The
Modules/Platform/Darwin-Initialize.cmake module will have
to be taught about this case to do the right thing by default
if it does not already.

Gregor, do you mind taking a look at this?

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct  6 11:05:56 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 11:05:56 -0400
Subject: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11
In-Reply-To: <5613B5B2.7020201@drdanz.it>
References: <5613B5B2.7020201@drdanz.it>
Message-ID: <5613E354.7040704@kitware.com>

On 10/06/2015 07:51 AM, Daniele E. Domenichelli wrote:
> According to the sigc++ changelog, starting with version 2.5.1, sigc++
> requires c++11 enabled, hence this patch.

Thanks.

> +* Starting with sigc++ 2.5.1, c++11 must be enabled in order to use
> +  sigc++.

Generally we don't do release notes for bug fixes, but this is somewhat
of a new feature since it enables C++11 automatically for the client
project.  Please word the release note as a feature that the imported
target provides.

> +            set_property(TARGET GTK2::sigc++ PROPERTY INTERFACE_COMPILE_FEATURES cxx_alias_templates cxx_lambdas)

Nice.  Please add a comment to explain that these are the features
needed by clients in order to include the project headers.

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct  6 11:27:50 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 11:27:50 -0400
Subject: [cmake-developers] CXX_STANDARD and linking
In-Reply-To: <mure6c$sp4$1@ger.gmane.org>
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org>
Message-ID: <5613E876.4010603@kitware.com>

On 10/04/2015 10:47 AM, Stephen Kelly wrote:
> So, is this thread really about a bug, or is it a feature request? 

I think it has become a feature request to select link flags for language
standard levels.  It is conflated with a bug fix because the link flags
are needed to support existing features on Solaris.

> Perhaps those commits should be reverted. I see no reason for SolarisStudio 
> on linux to behave any differently than on solaris, so the commit relating 
> to that is probably not appropriate.

I don't want CMake to generate broken builds by default.  We *know* it
goes wrong on Solaris and cannot possibly work without user intervention.
If a problem comes up on Linux too we can deal with it as necessary.

> I wrote here some ideas of a design for specifying the standard library to 
> use: 
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296

Is that the right link?  I don't see discussion of -stdlib= in that message.

> Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the 
> linker, we should work more on a design like the above way to specify a 
> standard library. 

Yes, but the -std= and -stdlib= flags are different from the full
LINK_OPTIONS discussion because they are meant specifically for the
front end and not for the linker (never "-Wl,").  Also they need
to be selected by CMake rather than propagated as a flag specified
by project code.

> The compile features can imply a default and a set of allowed alternatives 
> (for example, compiling with cxx_static_assert implies the use of stdlibc++ 
> or libc++ with Clang by default but there is a way to use the other 
> instead).  The COMPATIBLE_INTERFACE features may also be used to ensure that 
> targets which link together all use the same standard library.

Originally I was thinking we should just use the same -std= for linking
that we do for compilation, but don't we currently support compiling
different targets at different standard levels and then linking them?
In that case we will certainly need more sophisticated logic for
selecting the link flag.

BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently
mutate the configure step result by setting target properties like
<LANG>_STANDARD during generation.  Also, this is done with one "config"
value which may not be appropriate in multi-config generators.

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct  6 11:30:21 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 11:30:21 -0400
Subject: [cmake-developers] Importing platform SDK libraries without a
 full path
In-Reply-To: <loom.20151004T164752-225@post.gmane.org>
References: <555DE535.4020707@kitware.com> <mjv4fr$aal$1@ger.gmane.org>
 <5564BCB2.2000600@kitware.com> <mk2no4$qsk$1@ger.gmane.org>
 <5565C35B.9090108@kitware.com> <mk5334$19u$1@ger.gmane.org>
 <55662CE2.4090002@kitware.com> <mk5elk$4ir$1@ger.gmane.org>
 <55688316.3040306@kitware.com> <loom.20151004T164752-225@post.gmane.org>
Message-ID: <5613E90D.40901@kitware.com>

On 10/04/2015 10:49 AM, Stephen Kelly wrote:
>> I need to revert the 'imported-interface-libname' topic from 'next'
>> in preparation for the 3.3 freeze anyway.  After that we can return
>> first to INTERFACE configuration mapping and later to link items.
> 
> I wonder if you plan do resolve this part in the coming cycle? I think
> resolving that part would help me to understand the rest of your proposal in
> the thread.

I don't know if/when I'll ever have time to return to that work :(

If LINK_ITEMS/LINK_OPTIONS were to move forward independently
then the features discussed there would no longer be needed.
OTOH the design may run into similar challenges.

-Brad


From robert.maynard at kitware.com  Tue Oct  6 11:43:11 2015
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 6 Oct 2015 11:43:11 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!
Message-ID: <CAFzjYVrPqkGUFCs0AN8cFtq01PHdFwHOv6AC2m7KN2QD0QPg7Q@mail.gmail.com>

I am proud to announce the first CMake 3.4 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.4

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.4/release/3.4.html

Some of the more significant features of CMake 3.4 are:

* The "if()" command learned a new "TEST" operator that evaluates to
  true if a given test name has been defined by the "add_test()"
  command.  See policy "CMP0064".

* The "install(DIRECTORY)" command "DESTINATION" option learned to
  support "generator expressions".

* The "install(FILES)" command "DESTINATION" option learned to
  support "generator expressions".

* CMake learned to honor "*.manifest" source files with MSVC tools.
  Manifest files named as sources of ".exe" and ".dll" targets will be
  merged with linker-generated manifests and embedded in the binary.


Deprecated and Removed Features:

* The "CMakeExpandImportedTargets" module is now documented as
  deprecated.  See module documentation for an explanation.

* The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect.
  Previously it was partially implemented and unreliable.

CMake 3.4 Release Notes
***********************

Changes made since CMake 3.3 include the following.


New Features
============


Generators
----------

* The "Visual Studio 14 2015" generator learned to select a Windows
  10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and
  the SDKs available on the host.

* CMake learned rudimentary support for the Apple Swift language.
  When using the "Xcode" generator with Xcode 6.1 or higher, one may
  enable the "Swift" language with the "enable_language()" command or
  the "project()" command (this is an error with other generators or
  when Xcode is too old).  Then one may list ".swift" source files in
  targets for compilation.


Commands
--------

* The "find_program()" command learned a "NAMES_PER_DIR" option to
  consider all given "NAMES" in each directory before moving on to the
  next directory.

* The "get_filename_component()" command learned a new "BASE_DIR"
  subcommand.  This is used to specify a base directory when
  calculating an absolute path from a relative path.

* The "if()" command learned a new "TEST" operator that evaluates to
  true if a given test name has been defined by the "add_test()"
  command.  See policy "CMP0064".

* The "install(DIRECTORY)" command "DESTINATION" option learned to
  support "generator expressions".

* The "install(FILES)" command "DESTINATION" option learned to
  support "generator expressions".

* The "string()" command learned a new "APPEND" subcommand.


Variables
---------

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools like distcc and ccache along with the
  compiler for "C" and "CXX" languages.  See the
  "CMAKE_<LANG>_COMPILER_LAUNCHER" variable and
  "<LANG>_COMPILER_LAUNCHER" target property for details.

* New "CMAKE_LINK_SEARCH_START_STATIC" and
  "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to
  initialize the "LINK_SEARCH_START_STATIC" and
  "LINK_SEARCH_END_STATIC" target properties, respectively.


Properties
----------

* Visual Studio Generators learned to support additonal target
  properties to customize projects for NVIDIA Nsight Tegra Visual
  Studio Edition:

  * "ANDROID_ANT_ADDITIONAL_OPTIONS"

  * "ANDROID_ARCH"

  * "ANDROID_ASSETS_DIRECTORIES"

  * "ANDROID_JAR_DEPENDENCIES"

  * "ANDROID_JAR_DIRECTORIES"

  * "ANDROID_JAVA_SOURCE_DIR"

  * "ANDROID_NATIVE_LIB_DEPENDENCIES"

  * "ANDROID_NATIVE_LIB_DIRECTORIES"

  * "ANDROID_PROCESS_MAX"

  * "ANDROID_PROGUARD"

  * "ANDROID_PROGUARD_CONFIG_PATH"

  * "ANDROID_SECURE_PROPS_PATH"

  * "ANDROID_SKIP_ANT_STEP"

  * "ANDROID_STL_TYPE"

* The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and
  "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support
  "generator expressions".

* The "SOURCE_DIR" and "BINARY_DIR" target properties were
  introduced to allow project code to query where a target is defined.

* The "OUTPUT_NAME" target property and its variants learned to
  support "generator expressions".

* A "TARGET_MESSAGES" global property was added to tell the Makefile
  Generators whether to generate commands to print output after each
  target is completed.

* On Windows with MS-compatible tools, CMake learned to optionally
  generate a module definition (".def") file for "SHARED" libraries.
  See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property.


Modules
-------

* The "ExternalProject" module "ExternalProject_Add()" function
  "GIT_SUBMODULES" option now also limits the set of submodules that
  are initialized in addition to the prior behavior of limiting the
  set of submodules that are updated.

* The "ExternalProject" module learned new "USES_TERMINAL" arguments
  for giving steps exclusive terminal access.  This is useful with the
  "Ninja" generator to monitor CMake superbuild progress and prevent
  CPU oversubscription.

* The "FindBISON" module "BISON_TARGET" macro learned a new
  "DEFINES_FILE" option to specify a custom output header to be
  generated.

* The "FindHDF5" module learend a new "HDF5_PREFER_PARALLEL" option
  allowing users to specify that a parallel HDF5 tool is preferred if
  both are available.

* The "FindIce" module now provides imported targets.

* The "FindJava" module learned to optionally find the "idlj" and
  "jarsigner" tools.

* The "FindOpenSSL" module now provides imported targets.

* The "FindOpenSSL" module learned a new "OPENSSL_USE_STATIC_LIBS"
  option to search only for static libraries.

* The "FindPkgConfig" learned a new "pkg_get_variable()" command
  which may be used to query for arbitrary variables from a package
  (such as for related tools or data and plugin install paths).

* The "FindProtobuf" module gained a new
  "protobuf_generate_python()" function to generate python sources
  from ".proto" files.

* The "FindTIFF" module learned to search separately for debug and
  release variants.

* The "FindwxWidgets" module learned to support version requests.

* The "FindXercesC" module learned to search separately for debug
  and release variants.

* The "FindZLIB" module learned to search separately for debug and
  release variants.

* The "GNUInstallDirs" module learned special default values for
  certain installation prefixes according to the GNU Coding Standards
  and the Filesystem Hierarchy Standard.

* The "UseJava" module "add_jar" function learned to support
  response files (e.g. "@srcs.txt") for source specification.

* The "UseJava" module "install_jar" function learned new
  "DESTINATION" and "COMPONENT" options to specify the corresponding
  "install()" command options.

* The "UseJava" module gained a new "create_javah" function to
  create C headers from Java classes.


Generator Expressions
---------------------

* A new "$<SHELL_PATH:...>" "generator expression" has been added.


CTest
-----

* CTest learned to optionally measure the CPU load during parallel
  testing and avoid starting tests that may cause the load to exceed a
  given threshold.  See the "ctest(1)" command "--test-load" option,
  the "TestLoad" setting of the CTest Test Step, the "CTEST_TEST_LOAD"
  variable, and the "TEST_LOAD" option of the "ctest_test()" command.

* "ctest(1)" learned options "--test-output-size-passed" and "--
  test- output-size-failed" to customize the limit on test output size
  submitted when running as a Dashboard Client.


CPack
-----

* The "CPackDeb" module learned to set package dependencies per
  component.  See variables:

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS"

* The "CPack" module learned to package empty directories.

* The "CPack" module gained a new setting,
  "CPACK_VERBATIM_VARIABLES", which can be used to ensure the cpack
  program receives the settings' values exactly as they were set, even
  if they contain CMake-special characters. For compatibility, it's
  off by default.


Other
-----

* The "Compile Features" functionality is now aware of features
  supported by GNU C compilers on Windows.

* CMake learned to honor "*.manifest" source files with MSVC tools.
  Manifest files named as sources of ".exe" and ".dll" targets will be
  merged with linker-generated manifests and embedded in the binary.

* The Concurrent Fortran 77 compiler is now supported. Its "compiler
  id" is "CCur".

* "cmake(1)" gained a new "--trace-expand" command line option that
  is like "--trace" but expands variable references in the output.


Deprecated and Removed Features
===============================

* The "CMakeExpandImportedTargets" module is now documented as
  deprecated.  See module documentation for an explanation.

* The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect.
  Previously it was partially implemented and unreliable.


Other Changes
=============

* The "CheckFunctionExists", "CheckLibraryExists",
  "CheckSymbolExists", and "FindThreads" modules learned to work in
  environments where only CXX is enabled.

* The "CPackDeb" module now correctly excludes symlinks during
  package checksum calculation.

* The "CPackDeb" no longer uses fakeroot and system tar program for
  packaging.

* The "CPack" module no longer mangles settings with CMake-special
  characters when they're used as defaults for other settings. The
  macro "cpack_set_if_not_set", which was responsible for this, is now
  deprecated.

* CMake no longer links executables with flags to export symbols
  unless the "ENABLE_EXPORTS" target property is set. See policy
  "CMP0065".

* The "SONAME" field is no longer set for "MODULE" libraries created
  with the "add_library()" command.  "MODULE" libraries are meant for
  explicit dynamic loading at runtime. They cannot be linked so
  "SONAME" is not useful.

From ddomenichelli at drdanz.it  Tue Oct  6 12:20:30 2015
From: ddomenichelli at drdanz.it (Daniele E. Domenichelli)
Date: Tue, 6 Oct 2015 18:20:30 +0200
Subject: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11
In-Reply-To: <5613E354.7040704@kitware.com>
References: <5613B5B2.7020201@drdanz.it> <5613E354.7040704@kitware.com>
Message-ID: <5613F4CE.8010500@drdanz.it>

Thanks Brad for the review.

I updated the topic according to your comments. The new commit is this:

  FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
  https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33eb8fa


On 06/10/2015 17:05, Brad King wrote:
>> +            set_property(TARGET GTK2::sigc++ PROPERTY INTERFACE_COMPILE_FEATURES cxx_alias_templates cxx_lambdas)
> 
> Nice.  Please add a comment to explain that these are the features
> needed by clients in order to include the project headers.

I examined the headers a bit more and found out that c++11 is used a lot
more than I was expecting:

* cxx_lambdas is _not_ required (the lambda that I noticed was actually
  in a comment).

* at least these features are required:
   - cxx_alias_templates
   - cxx_auto_type
   - cxx_decltype
   - cxx_deleted_functions
   - cxx_noexcept
   - cxx_nullptr
   - cxx_right_angle_brackets
   - cxx_rvalue_references
   - cxx_variadic_templates

* The <type_traits> header is required, but I don't think that there is
  a feature for that. Also checking if the header exists it is not
  good, because (at least for gcc) it does exist, but including it with
  c++11 disabled will cause an #error. Is there a way for c++11 headers?

* std::move is used in the headers, but I'm not sure if there is a
  feature for that.



I updated the set_property command accordingly, but I'm not 100% sure
that there aren't other c++11 features used, because I just had a quick
look at the headers.



Cheers,
 Daniele

From brad.king at kitware.com  Tue Oct  6 13:25:16 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 06 Oct 2015 13:25:16 -0400
Subject: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11
In-Reply-To: <5613F4CE.8010500@drdanz.it>
References: <5613B5B2.7020201@drdanz.it> <5613E354.7040704@kitware.com>
 <5613F4CE.8010500@drdanz.it>
Message-ID: <561403FC.9010307@kitware.com>

On 10/06/2015 12:20 PM, Daniele E. Domenichelli wrote:
> I updated the topic according to your comments. The new commit is this:
> 
>   FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
>   https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33eb8fa

LGTM.

> I'm not 100% sure that there aren't other c++11 features used

Future versions could add more anyway.  This list should be
sufficient to get C++11 enabled.

Thanks,
-Brad


From ben.boeckel at kitware.com  Tue Oct  6 14:37:32 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 6 Oct 2015 14:37:32 -0400
Subject: [cmake-developers] CXX_STANDARD and linking
In-Reply-To: <mure6c$sp4$1@ger.gmane.org>
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com>
 <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org>
Message-ID: <20151006183732.GD12841@megas.khq.kitware.com>

On Sun, Oct 04, 2015 at 16:47:40 +0200, Stephen Kelly wrote:
> The existing CMake feature deals with compilation, but does not deal with 
> linking. 

A generic target_link_options() is necessary for other things as well,
such as:

  * -fsanitize=address needs to be passed to the linker to add -lasan
    (similar for other sanitizers);
  * -pg -ftest-coverage -fprofile-arcs needs to be passed to the
    linker for adding profiling information.

--Ben

From ben.boeckel at kitware.com  Tue Oct  6 17:41:51 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 6 Oct 2015 17:41:51 -0400
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
In-Reply-To: <56125601.8090300@simtech.uni-stuttgart.de>
References: <56125601.8090300@simtech.uni-stuttgart.de>
Message-ID: <20151006214151.GA26620@megas.khq.kitware.com>

On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> thanks for the feedback, i've included most of it.
> 
> Regarding the configure/build issue: that indeed is inconvenient and may 
> cause irritation. on the other side, if there has been git activity 
> fussing with any source files affecting the build, cmake will run again 
> and hence capture the possibly new git info. so the case where you 
> change the revision after configure to an extent where cmake will not 
> automatically re-run is uncommon, at least for my guessing.
> however, i've included an explicit warning in the docs to raise awareness.

Well, without depending on every file in the source tree, it will just
be wrong rather than causing excess configure runs. Adding something
like "configure this file at build time" setup would need to be the
basis though (basically porting and cleaning up sprokit_configure_file()
into CMake as deferred_configure_file() or something similar would work).

> i'm happy to provide a suitable procedure that is flexible enough; 
> providing scripts that configure files (like with sprokit) seems too 
> specific as people might want to have a single "config.h" file or so 
> containing more than just the git info.

The sprokit mechanism configures any file using code to determine some
of the variables at build time. It is by no means limited to just header
files. The code injection is a little clunky (being a string and all),
but it could also be changed to an include() statement with an extra
depends on that included file. In fact, with include(), adding support
for SVN, Mercurial and others would be pretty simple as well rather than
duplicating all this for each revision system.

> i've thought about the possibility to generate an explicit 
> "git_version.h" file to include, but that 1) restricts possible 
> languages and 2) will require an extra build target that is run each 
> build etc. any thoughts?

Well, you will indeed never have a "nothing to do" build with such a
target, but such information is effectively derived from "this depends
on every file in the tree tracked by git as well as the .git/HEAD,
.git/index, and .git/refs/tags/* files" so "always something to do"
isn't that far off. The step (in sprokit) takes ~0 time to run
anyways[1], so speed isn't an issue.

--Ben

[1]45 build trees took < 2 seconds, so figuring for some overhead for
exec() of ninja itself and ninja scanning, the overhead for checking the
git revision is < .05s for a smallish source tree. Something like
webkit's git mirror could take a while though.

From ddomenichelli at drdanz.it  Wed Oct  7 03:26:02 2015
From: ddomenichelli at drdanz.it (Daniele E. Domenichelli)
Date: Wed, 7 Oct 2015 09:26:02 +0200
Subject: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11
In-Reply-To: <561403FC.9010307@kitware.com>
References: <5613B5B2.7020201@drdanz.it> <5613E354.7040704@kitware.com>
 <5613F4CE.8010500@drdanz.it> <561403FC.9010307@kitware.com>
Message-ID: <5614C90A.1050400@drdanz.it>

On 06/10/2015 19:25, Brad King wrote:
> On 10/06/2015 12:20 PM, Daniele E. Domenichelli wrote:
>> I updated the topic according to your comments. The new commit is this:
>>
>>   FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
>>   https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33eb8fa
> 
> LGTM.


Merged into next.

Thanks,
 Daniele

From daniel.wirtz at simtech.uni-stuttgart.de  Wed Oct  7 04:03:21 2015
From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz)
Date: Wed, 7 Oct 2015 10:03:21 +0200
Subject: [cmake-developers] Moving from Module to Target-based linking
Message-ID: <5614D1C9.4080506@simtech.uni-stuttgart.de>

Hey all,

is there any development going on towards providing FindXXX.cmake 
wrapper modules that "convert" MODULE-mode results into CONFIG style 
imported targets to consume?
correct me if i'm wrong here, but as more and more projects are being 
cmake'ified and the config-mode is far more robust to
manage package-interdependencies, wouldn't it fuel this progress if 
there was some sort of automatic imported target creation possible?

i've attached a template that is cmake-configured and has thus far been 
able to work with all the 3rd party packages we've got involved (it's 
also got some specific stuff - ignore).
it basically invokes the module mode and sets found libraries and paths 
to an imported target (named after what was looked for)
which then can be consumed, much like the generated config files do.

if this is of general interest, i'm happy for some feedback and 
suggestions how that could be of use in CMake.

- Daniel

-- 
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindXXX.template.cmake
Type: text/x-cmake
Size: 9385 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151007/7aa9f67c/attachment-0001.bin>

From mantis at public.kitware.com  Wed Oct  7 04:32:02 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Oct 2015 04:32:02 -0400
Subject: [cmake-developers] [CMake 0015771]: GHS-MULTI Generator Uses Macros
	in GPJs Uncompatible With Older Versions
Message-ID: <d37db5a37a60b772865082b797fd9c2e@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15771 
====================================================================== 
Reported By:                iainmeikle
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15771
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-07 04:32 EDT
Last Modified:              2015-10-07 04:32 EDT
====================================================================== 
Summary:                    GHS-MULTI Generator Uses Macros in GPJs Uncompatible
With Older Versions
Description: 
The GHS-MULTI generator adds the following to generated GPJ files:

{optgroup=GhsCommonOptions}.

Other than this, the GPJ files appear to work OK with older versions. This can
be alleviated by adding the following instead.

{isdefined(optgroup)}{optgroup=GhsCommonOptions}

Steps to Reproduce: 
Use quite an old version of their tool chain.

Additional Information: 
Unable to provide specific version information for the tool chain used.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-07 04:32 iainmeikle     New Issue                                    
======================================================================


From roman.wueger at gmx.at  Wed Oct  7 04:48:04 2015
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Wed, 7 Oct 2015 10:48:04 +0200
Subject: [cmake-developers] Rename suffix of Mac OS Framework
In-Reply-To: <561297B8.2010507@kitware.com>
References: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at>
 <561297B8.2010507@kitware.com>
Message-ID: <03EBF395-0BA4-40FB-B835-70DB7297621A@gmx.at>

Hi Brad,

A use case for example is when an InDesign plugin should be developed. The InDesign plugin on Mac OS is a framework with the file extension ".InDesignPlugin".

It works if the "Xcode" generator is used and the target property "XCODE_ATTRIBUTE_WRAPPER_EXTENSION" is set to "InDesignPlugin".
But it doesn't work if the "Unix Makefiles" generator is used.

See also https://cmake.org/Bug/view.php?id=14742

Best Regards
Roman

> Am 05.10.2015 um 17:31 schrieb Brad King <brad.king at kitware.com>:
> 
>> On 10/01/2015 04:07 AM, Roman W?ger wrote:
>> set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE)
>> 
>> Is there a way to rename the suffix ".framework"?
> 
> Not currently.  It is hard-coded here:
> 
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGeneratorTarget.cxx;hb=679a5d21#l2981
> 
> What is the use case for changing the framework extension?
> Doing so breaks the basic layout defined in "man ld":
> 
>     -framework name[,suffix]
>                 This option tells the linker to search for `name.frame-
>                 work/name' the framework search path.  If the optional
>                 suffix is specified the framework is first searched for
>                 the name with the suffix and then without (e.g. look
>                 for `name.framework/name_suffix' first, if not there
>                 try `name.framework/name').
> 
> -Brad
> 

From mantis at public.kitware.com  Wed Oct  7 09:10:17 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Oct 2015 09:10:17 -0400
Subject: [cmake-developers] [CMake 0015772]: snprintf on msvc14 compiler
Message-ID: <043f53286f1c4f9c967885701a62eb00@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15772 
====================================================================== 
Reported By:                Garcia Sylvain
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15772
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-07 09:10 EDT
Last Modified:              2015-10-07 09:10 EDT
====================================================================== 
Summary:                    snprintf on msvc14 compiler
Description: 
The CheckFunctionExits module does not detect the new msvc14's snprintf
function.


Steps to Reproduce: 
Run 'cmake -G"Visual Studio 14 2015" .' on the attached CMakeLists.txt
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-07 09:10 Garcia Sylvain New Issue                                    
2015-10-07 09:10 Garcia Sylvain File Added: CMakeLists.txt                    
======================================================================


From gjasny at googlemail.com  Wed Oct  7 09:57:03 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Wed, 7 Oct 2015 14:57:03 +0100
Subject: [cmake-developers] Patch: install universal iOS libraries
In-Reply-To: <5603CC15.5070201@yahoo.com>
References: <5603CC15.5070201@yahoo.com>
Message-ID: <561524AF.4070509@googlemail.com>

Hello,

thank you for working on this. This is really hairy stuff.

On 24/09/15 11:10, Ruslan Baratov via cmake-developers wrote:
> Patches help to install universal iOS (device + simulator) libraries by
> triggering some extra instructions (build + fuse) after "regular"
> library installation finished. This behavior controlled by CMake
> variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.

some general remarks:

* iOS is not the only platform where the simulator / device situation is
problematic. Others are now watchOS and the upcoming tvOS (see
xcodebuild -showsdks). So it would make sense to replace the ios naming
in the method signatures with something more general.

* Does the patches handle Bundles and Frameworks properly?

* This functionality should be limited to XCODE Generator

0001-

* Could you make the CMAKE_IOS_INSTALL_UNIVERSAL_LIBS a two staged
property like CMAKE_INSTALL_RPATH / INSTALL_RPATH. That way one would be
able to enable this behavior for only some targets

0002-CMake-module-for-universal-iOS-library-install

* Could you avoid to hard-code architecture names like i386 or armv7 in
the module?

* In Xcode 7 (and maybe earlier) I see the following environment
variables when I install for Device:

> export CORRESPONDING_SIMULATOR_PLATFORM_NAME=iphonesimulator
> export CORRESPONDING_SIMULATOR_SDK_NAME=iphonesimulator9.0
> export SUPPORTED_PLATFORMS="iphonesimulator iphoneos"
> export SDK_NAME=iphoneos9.0

for Simulator:

> export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
> export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
> export SDK_NAME=iphonesimulator9.0

Could you use those variables to avoid hardcoding iphoneos/simulator in
the module?

> +  install_universal_ios_remove_arch("${dev_libpath}" "i386")
> +  install_universal_ios_remove_arch("${dev_libpath}" "x86_64")

Doing it the other way round (keeping only what's needed) looks saner to me.

> +  install_universal_ios_remove_arch("${dev_libpath}" ...)
> +
> +  install_universal_ios_remove_arch("${sim_libpath}" ...)
> +
> +  set(cmd lipo -create ${src} ${dst} -output ${dst})

Would it be possible to just add selected architectures from src to dst
(via lipo -replace)? That way you would save some disk i/o and would
make the pruning step for src superfluous.

Thanks,
Gregor

From ddomenichelli at drdanz.it  Wed Oct  7 10:15:50 2015
From: ddomenichelli at drdanz.it (Daniele E. Domenichelli)
Date: Wed, 7 Oct 2015 16:15:50 +0200
Subject: [cmake-developers] [Review Request] New module: IncludeUrl
Message-ID: <56152916.1060801@drdanz.it>

Hello all,

Please review the "IncludeUrl" topic[1] that adds a new "IncludeUrl"
module. This module adds the include_url command that is useful to
download and include other CMake modules from a given url.

[1]https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/IncludeUrl


The main use case for such a module is for groups that have several
projects or CMake scripts, handled by different developers, that import
the same CMake module that is sometimes updated, and they want to keep
these files synchronized in all the projects. This is very hard to
achieve when the developers are many and don't care too much about the
build system. Instead of adding this file to each project, this module
allows to put it somewhere, and automatically download and include it
when required. This is not optimal in some cases, for example when
network is not available, when packaging a project using build machines
that may not have access to the network, or basically any case in which
file(DOWNLOAD) is not optimal, but it can be useful in several other
cases, for example for projects that are not going to be packaged any
time soon, or that already depend on the network for some reason (e.g.
ExternalProject) and for CMake scripts.

This module has 3 main operation modes:

* Normal mode: Always try to download the latest version of the file,
  but if the download fails use the last version available.
* DOWNLOAD_ONCE mode: Download the file the only first time or (if used
  in combination with EXPECTED_HASH or EXPECTED_MD5) when the hash
  mismatches.
* DOWNLOAD_ALWAYS mode: Never use a previously downloaded version of
  the file. If used with OPTIONAL can be used for a module that is not
  available all the time and should not be included in case the
  download fails.



The topic comes with a broad set of unit tests. I tested only on local
files, because I assume that the download part is already tested enough
with unit tests for the file(DOWNLOAD) command. Also for now I tested it
only on linux, therefore I expect some failure on other platforms...

Thanks.



Regards,
 Daniele

From mantis at public.kitware.com  Wed Oct  7 15:08:57 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Oct 2015 21:08:57 +0200
Subject: [cmake-developers] [CMake 0015773]: Transitive config-specific
	compile features may be buggy
Message-ID: <408901d04a9f1a393055907b2d8bbe18@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15773 
====================================================================== 
Reported By:                Stephen Kelly
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15773
Category:                   CMake
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-07 21:08 CEST
Last Modified:              2015-10-07 21:08 CEST
====================================================================== 
Summary:                    Transitive config-specific compile features may be
buggy
Description: 

>From the mailing list:

> BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently
> mutate the configure step result by setting target properties like
> <LANG>_STANDARD during generation.  Also, this is done with one "config"
> value which may not be appropriate in multi-config generators.

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-07 21:08 Stephen Kelly  New Issue                                    
======================================================================


From steveire at gmail.com  Wed Oct  7 15:09:42 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 07 Oct 2015 21:09:42 +0200
Subject: [cmake-developers] CXX_STANDARD and linking
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org> <5613E876.4010603@kitware.com>
Message-ID: <mv3qln$mq2$1@ger.gmane.org>

Brad King wrote:

> On 10/04/2015 10:47 AM, Stephen Kelly wrote:
>> So, is this thread really about a bug, or is it a feature request?
> 
> I think it has become a feature request to select link flags for language
> standard levels.  

Not the language standard level, but the standard library to compile with 
and link with. 

It just happens that the way to link to the correct library on SolarisStudio 
is -std=c++11 (or -std=c++03 which presumably also links to the same 
libstdc++.so shipped with SolarisStudio; but I just note this for 
completeness). Also, I agree that we should pass -std=c++11 when linking 
with GNU too, which is why it looks like 'language standard level', but it 
is not because the language has no relevance at link time.

>> Perhaps those commits should be reverted. I see no reason for
>> SolarisStudio on linux to behave any differently than on solaris, so the
>> commit relating to that is probably not appropriate.
> 
> I don't want CMake to generate broken builds by default.  We *know* it
> goes wrong on Solaris and cannot possibly work without user intervention.
> If a problem comes up on Linux too we can deal with it as necessary.

I'm pretty sure the situation on linux is the same as on Solaris.

Stephen Kelly wrote:
> It is possible that I was operating as if the link flags were user
> responsibility and had configured my environment accordingly (though I
> don't remember).



>> I wrote here some ideas of a design for specifying the standard library
>> to use:
>> 
>>  
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296
> 
> Is that the right link?  I don't see discussion of -stdlib= in that
> message.

Gmane is not currently resolving the link. You might be right that there is 
no mention of -stdlib= flags, but I think there is mention of CMake 
providing IMPORTED targets which supply INTERFACE_ properties. I was 
referring to the design of cmake providing such IMPORTED targets, and indeed 
that design should allow the user to specify the library to link with, and 
that should add -stdlib= flags where appropriate.

>> Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the
>> linker, we should work more on a design like the above way to specify a
>> standard library.
> 
> Yes, but the -std= and -stdlib= flags are different from the full
> LINK_OPTIONS discussion because they are meant specifically for the
> front end and not for the linker (never "-Wl,").  

Yes, I think previous design discussion (possibly the one linked above) 
included a TOOLCHAIN_OPTIONS property for cases like this and -pthread etc.

> Also they need
> to be selected by CMake rather than propagated as a flag specified
> by project code.

Yes, or some combination of both being possible.

>> The compile features can imply a default and a set of allowed
>> alternatives (for example, compiling with cxx_static_assert implies the
>> use of stdlibc++ or libc++ with Clang by default but there is a way to
>> use the other
>> instead).  The COMPATIBLE_INTERFACE features may also be used to ensure
>> that targets which link together all use the same standard library.
> 
> Originally I was thinking we should just use the same -std= for linking
> that we do for compilation, but don't we currently support compiling
> different targets at different standard levels and then linking them?

As I wrote, this is not about 'linking with a language standard level', 
which is not a concept which has meaning.  This is about 'which standard 
library binary do we link to?'. In the case of GNU, we link to libstdc++.so. 

If we would link some targets to libstdc++ and others to libc++ we could not 
use them together because the standard library implementations are not 
binary compatibile with each other.  See also what I wrote before about 
using COMPATIBLE_INTERFACE properties to diagnose this at cmake time.

> BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently
> mutate the configure step result by setting target properties like
> <LANG>_STANDARD during generation.  Also, this is done with one "config"
> value which may not be appropriate in multi-config generators.

Interesting. I've filed a bug here:

 http://public.kitware.com/Bug/view.php?id=15773

Thanks,

Steve.



From steveire at gmail.com  Wed Oct  7 15:22:02 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 07 Oct 2015 21:22:02 +0200
Subject: [cmake-developers] CXX_STANDARD and linking
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org> <5613E876.4010603@kitware.com>
Message-ID: <mv3rcq$2f3$1@ger.gmane.org>

Brad King wrote:

> I don't want CMake to generate broken builds by default.  We *know* it
> goes wrong on Solaris and cannot possibly work without user intervention.

Just some more on this:

The CMake 3.3 behavior of this is the same as it has always been since 
introducing compile-features for SolarisStudio. 

Any users aware that compile-features only affect compilation will have 
added the link flag themselves with one of the already available mechanims. 
Such users will be affected by this CMake 3.4 change.

For the build of CMake itself on Solaris, we should probably add the 
required link flag until there is a porcelian feature for it (in 
CompileFlags.cmake?).

I'm also not confident in commit v3.4.0-rc1~10^2~1 (Features: Fix C++98 
flags on Oracle SolarisStudio 12.4 on Linux, 2015-09-30) because it will 
mean that 'c++98 mode' on Solaris 12.4 is forced to use libstdc++ instead of 
stlport4 or libCstd (rougewave). I'm not sure of the implications of that.

So, it might be best to revert that commit and its parent.

Thanks,

Steve.



From steveire at gmail.com  Wed Oct  7 15:28:36 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 07 Oct 2015 21:28:36 +0200
Subject: [cmake-developers] Visual Studio 6/7 removal
Message-ID: <mv3rp4$2f3$2@ger.gmane.org>


Hi,

The CMake 3.3 notes deprecation of VS 6/7 generators. 

 https://cmake.org/cmake/help/v3.3/release/3.3.html

Can they be removed in the CMake 3.5 cycle, or is that intended for a later 
release?

Thanks,

Steve.




From mantis at public.kitware.com  Wed Oct  7 17:49:45 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Oct 2015 17:49:45 -0400
Subject: [cmake-developers] [CMake 0015774]: CTest result submission over
	http fails to set Content-Type header which runs afoul of
	ModSecurity rules
Message-ID: <ebb50f857b58e1c13d3881020aa33808@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15774 
====================================================================== 
Reported By:                Derek Bruening
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15774
Category:                   CTest
Reproducibility:            always
Severity:                   block
Priority:                   low
Status:                     new
====================================================================== 
Date Submitted:             2015-10-07 17:49 EDT
Last Modified:              2015-10-07 17:49 EDT
====================================================================== 
Summary:                    CTest result submission over http fails to set
Content-Type header which runs afoul of ModSecurity rules
Description: 
On some web hosting providers, ModSecurity rules are in place that prevent using
CTest with a CDash installation on that provider.  The particular rule looks
like this (pieces removed for anonymity):

ModSecurity: Access denied with code 406 (phase 2). Match of "rx ^0$" against
"REQUEST_HEADERS:Content-Length" required. [msg "Request Containing Content, but
Missing Content-Type header"] [uri "/CDash/submit.php"]

CTest runs show this error:

Submit files (using http)
   Using HTTP submit method
   Drop site:http://<mysite>/CDash/submit.php?project=<myproject>
   Error when uploading file: <mypath>/Testing/20151005-0900/Build.xml
   Error message was: The requested URL returned error: 406 Not Acceptable
   Problems when submitting via HTTP

The same 406 error is seen using curl -T:

# curl -T <mypath>/Testing/20151007-0900/Build.xml
http://<mysite>/CDash/submit.php?project=<myproject>
<head><title>Not Acceptable!</title></head><body><h1>Not Acceptable!</h1><p>An
appropriate representation of the requested resource could not be found on this
server. This error was generated by Mod_Security.</p></body></html>

These hosting providers do not allow any method of disabling particular rules or
ModSecurity in general.

While we can debate the merits of this rule, it is simple to work around by
providing a Content-Type header.  E.g., curl -d works:

# curl -d @<mypath>/Testing/20151007-0900/Build.xml
http://<mysite>/CDash/submit.php?project=<myproject>
<cdash version="2.2.2">
  <status>OK</status>
  <message></message>
  <md5>...</md5>
</cdash>

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-07 17:49 Derek Bruening New Issue                                    
======================================================================


From bruening at google.com  Wed Oct  7 18:07:02 2015
From: bruening at google.com (Derek Bruening)
Date: Wed, 7 Oct 2015 18:07:02 -0400
Subject: [cmake-developers] [PATCH] set Content-Type in ctest http file
	uploads
Message-ID: <CAO1ikSaKdugpXuYqHwOiUZXTbx+LHo6tAc94p=XToAoU8G4iCg@mail.gmail.com>

The attached patch fixes https://cmake.org/Bug/view.php?id=15774
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151007/f035907f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CTest-set-Content-Type-header-for-http-file-upload.patch
Type: text/x-patch
Size: 3507 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151007/f035907f/attachment.bin>

From mantis at public.kitware.com  Wed Oct  7 18:35:00 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Oct 2015 18:35:00 -0400
Subject: [cmake-developers] [CMake 0015775]: Ninja will unnecessarily relink
	on windows if a library exports no symbols
Message-ID: <e761fb35d79f2877acb6b2f30f80820f@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15775 
====================================================================== 
Reported By:                James Johnston
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15775
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-07 18:34 EDT
Last Modified:              2015-10-07 18:34 EDT
====================================================================== 
Summary:                    Ninja will unnecessarily relink on windows if a
library exports no symbols
Description: 
This is very similar to the issue reported by Nils Gladitz:
0015666: Ninja may unnecessarily relink on windows
http://public.kitware.com/Bug/view.php?id=15666

However, my test case does not work on CMake 3.4.0-rc1 either.  In this
situation, the issue arises when the library exports no symbols.

My test case is almost identical to the one from Nils, except notice that
test.cpp is now a blank file: I don't export any symbols.  If the project does
not export any symbols, the linker *will not emit a LIB file at all.*

It initially sounds non-sensical, but not exporting any symbols is not as
uncommon as one might think; some examples:

 * It is common that a .NET C++/CLR project will not export unmanaged symbols,
as it is exporting directly through the DLL (i.e. no LIB file).
 * A DLL being used for the purpose of storing Win32 resources would not export
any symbols.
 * Some 3rd-party libraries (e.g. FLANN) happily seem to link an empty
library...

Steps to Reproduce: 
My test case, as you can see it's basically the same as Nils in
http://public.kitware.com/Bug/view.php?id=15666 except no symbols:

CMakeLists.txt
--------------

# Using CMake 3.4.0-rc1 here:
cmake_minimum_required(VERSION 3.4)

project(Foo CXX)

if(NOT EXISTS test.cpp)
    # Unlike Nils, I emit no symbols at all here:
    file(WRITE test.cpp "")
endif()

add_custom_target(touch
    COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_SOURCE_DIR}/test.cpp
)

add_library(foo SHARED test.cpp)

Procedure:
----------

1.  Configure with Ninja from a Visual C++ 2008 command prompt.  (Other VC++
versions will likely exhibit the same issue).
2.  ninja   # builds as expected
3.  ninja   # continues to build
4.  ninja -d explain

ninja explain: output foo.lib doesn't exist
ninja explain: foo.dll is dirty
[1/1] Linking CXX shared library foo.dll
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-07 18:34 James Johnston New Issue                                    
======================================================================


From mantis at public.kitware.com  Wed Oct  7 20:05:37 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 7 Oct 2015 20:05:37 -0400
Subject: [cmake-developers] [CMake 0015776]: 3.3.4 RC 1 Asserts when running
	on ITK 4.8.0
Message-ID: <969c2b961839153539d5c14c53abc145@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15776 
====================================================================== 
Reported By:                Rick Frank
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15776
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-07 20:05 EDT
Last Modified:              2015-10-07 20:05 EDT
====================================================================== 
Summary:                    3.3.4 RC 1 Asserts when running on ITK 4.8.0
Description: 
Running CMake on ITK asserts in Runtime Library and prints the following:

Performing Test InitOnceExecuteOnce - Success
Checking for appropriate format for 64 bit long:
Width with l64 failed with result: 3
File:minkernel\crts\ucrt\inc\corecrt_internal_stdio_outout.h 
Line 2480

Steps to Reproduce: 
Running CMake on ITK 4.8.0 
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-07 20:05 Rick Frank     New Issue                                    
2015-10-07 20:05 Rick Frank     File Added: Capture.PNG                      
======================================================================


From ruslan_baratov at yahoo.com  Wed Oct  7 20:37:00 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Thu, 8 Oct 2015 03:37:00 +0300
Subject: [cmake-developers] Patch: install universal iOS libraries
In-Reply-To: <561524AF.4070509@googlemail.com>
References: <5603CC15.5070201@yahoo.com> <561524AF.4070509@googlemail.com>
Message-ID: <5615BAAC.4040202@yahoo.com>

On 07-Oct-15 16:57, Gregor Jasny wrote:
> Hello,
>
> thank you for working on this. This is really hairy stuff.
>
> On 24/09/15 11:10, Ruslan Baratov via cmake-developers wrote:
>> Patches help to install universal iOS (device + simulator) libraries by
>> triggering some extra instructions (build + fuse) after "regular"
>> library installation finished. This behavior controlled by CMake
>> variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.
> some general remarks:
>
> * iOS is not the only platform where the simulator / device situation is
> problematic. Others are now watchOS and the upcoming tvOS (see
> xcodebuild -showsdks). So it would make sense to replace the ios naming
> in the method signatures with something more general.
It cames from PlatformIsAppleIos.
>
> * Does the patches handle Bundles and Frameworks properly?
No. At least for now it's designed to be used only for libraries 
(cmInstall_{STATIC,SHARED,MODULE}_LIBRARY). I don't think it make sense 
to extend this feature for Bundles (simulator architectures are useless 
in AppStore and will be rejected). If Bundle use Framework with 
simulator architectures it will be rejected too. Though it make sense to 
create "development" version of Framework with simulator archs but we 
need to resign it after fuse procedure (libs are not signed).

I'm planning to try to make such patches for Frameworks next.
>
> * This functionality should be limited to XCODE Generator
Fixed.
>
> 0001-
>
> * Could you make the CMAKE_IOS_INSTALL_UNIVERSAL_LIBS a two staged
> property like CMAKE_INSTALL_RPATH / INSTALL_RPATH. That way one would be
> able to enable this behavior for only some targets
Implemented. But I'm not sure it make sense. Can you describe scenario 
when it can be helpful?
>
> 0002-CMake-module-for-universal-iOS-library-install
>
> * Could you avoid to hard-code architecture names like i386 or armv7 in
> the module?

Ok. Added function to get "real" architectures by parsing `lipo -info`. 
If it's not equal to the one specified by SDK then needless archs removed.

>
> * In Xcode 7 (and maybe earlier) I see the following environment
> variables when I install for Device:
>
>> export CORRESPONDING_SIMULATOR_PLATFORM_NAME=iphonesimulator
>> export CORRESPONDING_SIMULATOR_SDK_NAME=iphonesimulator9.0
>> export SUPPORTED_PLATFORMS="iphonesimulator iphoneos"
>> export SDK_NAME=iphoneos9.0
> for Simulator:
>
>> export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
>> export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
>> export SDK_NAME=iphonesimulator9.0
> Could you use those variables to avoid hardcoding iphoneos/simulator in
> the module?
I see CORRESPONDING_*_SDK_NAME variables in Xcode 7.0 but not in 6.4.
>
>> +  install_universal_ios_remove_arch("${dev_libpath}" "i386")
>> +  install_universal_ios_remove_arch("${dev_libpath}" "x86_64")
> Doing it the other way round (keeping only what's needed) looks saner to me.
>
>> +  install_universal_ios_remove_arch("${dev_libpath}" ...)
>> +
>> +  install_universal_ios_remove_arch("${sim_libpath}" ...)
>> +
>> +  set(cmd lipo -create ${src} ${dst} -output ${dst})
> Would it be possible to just add selected architectures from src to dst
> (via lipo -replace)? That way you would save some disk i/o and would
> make the pruning step for src superfluous.
This is kind of "unusual" situation. In most cases this command will 
just exit with "no such architecture" error (and ignored). I've added a 
warning message if unexpected arch detected.

Rebased version of patches attached.
Github fork: https://github.com/ruslo/CMake/commits/pr.ios.universal.2

Thanks, Ruslo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Get-target-name-for-universal-iOS-library-install.patch
Type: text/x-patch
Size: 2610 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151008/af50ea83/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-CMake-module-for-universal-iOS-library-install.patch
Type: text/x-patch
Size: 11912 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151008/af50ea83/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Universal-iOS-library-install.patch
Type: text/x-patch
Size: 2833 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151008/af50ea83/attachment-0002.bin>

From mantis at public.kitware.com  Thu Oct  8 06:06:13 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 8 Oct 2015 06:06:13 -0400
Subject: [cmake-developers] [CMake 0015777]: The define constant _DEBUG
	should be defined implicitly when target build is Debug
Message-ID: <33dfa2c18cdb1c7c2ec8277bd998c738@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15777 
====================================================================== 
Reported By:                Francis ANDRE
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15777
Category:                   CMake
Reproducibility:            always
Severity:                   feature
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-10-08 06:06 EDT
Last Modified:              2015-10-08 06:06 EDT
====================================================================== 
Summary:                    The define constant _DEBUG should be defined
implicitly when target build is Debug
Description: 
Hi

As the constant NDEBUG is implicitly defined for a Release build, the constant
_DEBUG should be also implicitly defined for a Debug build.

Currently, implicit constant are define as below:

-- CMAKE_CXX_FLAGS_DEBUG:=-g
-- CMAKE_CXX_FLAGS_RELEASE:=-O3 -DNDEBUG
-- CMAKE_CXX_FLAGS_MINSIZEREL:=-Os -DNDEBUG
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO:=-O2 -g -DNDEBUG

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-08 06:06 Francis ANDRE  New Issue                                    
======================================================================


From ryan.pavlik at gmail.com  Thu Oct  8 08:58:33 2015
From: ryan.pavlik at gmail.com (Ryan Pavlik)
Date: Thu, 08 Oct 2015 12:58:33 +0000
Subject: [cmake-developers] Moving from Module to Target-based linking
In-Reply-To: <5614D1C9.4080506@simtech.uni-stuttgart.de>
References: <5614D1C9.4080506@simtech.uni-stuttgart.de>
Message-ID: <CAAm+CDLxkTDoxt=C=_x-1_mZqyMdzZC2_EhcKJL5txxWjfD-SA@mail.gmail.com>

That's an interesting script. If you look at the bundled modules, some are
gradually being converted to use imported targets: off the top of my head,
I know glut is one. Not sure a template like yours will make it into the
standard distribution, there are just too many special cases and weird
libraries, but it certainly could be helpful in the conversion process.

One bug I noticed in your template: while it's converting frameworks to
link differently (a catch I recently hit, as apparently linking to the
library symlinks by full path no longer works), it's also stripping all
location information from them, so it will only work with frameworks
already in the search path, if I'm not mistaken.

Happy to learn the correct way to make an imported target for a found
framework if someone cares to enlighten :)

Ryan

On Wed, Oct 7, 2015, 3:04 AM Daniel Wirtz <
daniel.wirtz at simtech.uni-stuttgart.de> wrote:

> Hey all,
>
> is there any development going on towards providing FindXXX.cmake
> wrapper modules that "convert" MODULE-mode results into CONFIG style
> imported targets to consume?
> correct me if i'm wrong here, but as more and more projects are being
> cmake'ified and the config-mode is far more robust to
> manage package-interdependencies, wouldn't it fuel this progress if
> there was some sort of automatic imported target creation possible?
>
> i've attached a template that is cmake-configured and has thus far been
> able to work with all the 3rd party packages we've got involved (it's
> also got some specific stuff - ignore).
> it basically invokes the module mode and sets found libraries and paths
> to an imported target (named after what was looked for)
> which then can be consumed, much like the generated config files do.
>
> if this is of general interest, i'm happy for some feedback and
> suggestions how that could be of use in CMake.
>
> - Daniel
>
> --
> Dr. Daniel Wirtz
> Dipl. Math. Dipl. Inf.
> SRC SimTech
> Pfaffenwaldring 5a
> +49 711 685 60044
>
> --
>
> 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/20151008/af9f36e3/attachment.html>

From ryan.pavlik at gmail.com  Thu Oct  8 09:10:54 2015
From: ryan.pavlik at gmail.com (Ryan Pavlik)
Date: Thu, 08 Oct 2015 13:10:54 +0000
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
In-Reply-To: <20151006214151.GA26620@megas.khq.kitware.com>
References: <56125601.8090300@simtech.uni-stuttgart.de>
 <20151006214151.GA26620@megas.khq.kitware.com>
Message-ID: <CAAm+CD+s1dv3GKhfZo+bYkhP71NN1JYn0UCZYThGZGLvGnotNQ@mail.gmail.com>

Just wanted to mention that a similar module I wrote is my most popular
stack overflow post and had seen a number of pull requests and
acknowledgements, so it's seemingly widely used. While it's slightly more
complicated than required (when i first wrote it, I thought you had to use
the configured file to get it generated) it does pretty reliably work,
including with submodules. I'm happy to relicense it for inclusion with
CMake. (Bsl should be more permissive anyway)
SO answer: http:// <http://stackoverflow.com/a/4318642/265522>
stackoverflow.com <http://stackoverflow.com/a/4318642/265522>
/a/4318642/265522 <http://stackoverflow.com/a/4318642/265522>

Module: https
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
://
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
github.com
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
/
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
rpavlik
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
/
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
cmake-modules
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
/blob/master/
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>
GetGitRevisionDescription.cmake
<https://github.com/rpavlik/cmake-modules/blob/master/GetGitRevisionDescription.cmake>

Sample usage in practice:
https
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>://
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>
github.com
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>
/OSVR/
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>
OSVR-Core
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>
/blob/master/
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>
cmake-local
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>/
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>
Version.cmake
<https://github.com/OSVR/OSVR-Core/blob/master/cmake-local/Version.cmake>

One addition I would have liked to have but haven't had time to do yet: the
ability to have a add custom command-based build time generation, instead
of our in addition to the CMake time generation. Some projects take a very
long time to generate, may cause visual studio to needlessly reload project
files, and you may only want the revision for a header file anyway. As you
can imagine, this would share much implementation with the configure time
code, and the prerequisite refactoring is why I haven't gotten around to
doing it yet.

Hope this is useful and saves some time reinventing wheels.

Ryan

On Tue, Oct 6, 2015, 4:41 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> > thanks for the feedback, i've included most of it.
> >
> > Regarding the configure/build issue: that indeed is inconvenient and may
> > cause irritation. on the other side, if there has been git activity
> > fussing with any source files affecting the build, cmake will run again
> > and hence capture the possibly new git info. so the case where you
> > change the revision after configure to an extent where cmake will not
> > automatically re-run is uncommon, at least for my guessing.
> > however, i've included an explicit warning in the docs to raise
> awareness.
>
> Well, without depending on every file in the source tree, it will just
> be wrong rather than causing excess configure runs. Adding something
> like "configure this file at build time" setup would need to be the
> basis though (basically porting and cleaning up sprokit_configure_file()
> into CMake as deferred_configure_file() or something similar would work).
>
> > i'm happy to provide a suitable procedure that is flexible enough;
> > providing scripts that configure files (like with sprokit) seems too
> > specific as people might want to have a single "config.h" file or so
> > containing more than just the git info.
>
> The sprokit mechanism configures any file using code to determine some
> of the variables at build time. It is by no means limited to just header
> files. The code injection is a little clunky (being a string and all),
> but it could also be changed to an include() statement with an extra
> depends on that included file. In fact, with include(), adding support
> for SVN, Mercurial and others would be pretty simple as well rather than
> duplicating all this for each revision system.
>
> > i've thought about the possibility to generate an explicit
> > "git_version.h" file to include, but that 1) restricts possible
> > languages and 2) will require an extra build target that is run each
> > build etc. any thoughts?
>
> Well, you will indeed never have a "nothing to do" build with such a
> target, but such information is effectively derived from "this depends
> on every file in the tree tracked by git as well as the .git/HEAD,
> .git/index, and .git/refs/tags/* files" so "always something to do"
> isn't that far off. The step (in sprokit) takes ~0 time to run
> anyways[1], so speed isn't an issue.
>
> --Ben
>
> [1]45 build trees took < 2 seconds, so figuring for some overhead for
> exec() of ninja itself and ninja scanning, the overhead for checking the
> git revision is < .05s for a smallish source tree. Something like
> webkit's git mirror could take a while though.
> --
>
> 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/20151008/d32461cd/attachment.html>

From ben.boeckel at kitware.com  Thu Oct  8 10:37:45 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 8 Oct 2015 10:37:45 -0400
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
In-Reply-To: <CAAm+CD+s1dv3GKhfZo+bYkhP71NN1JYn0UCZYThGZGLvGnotNQ@mail.gmail.com>
References: <56125601.8090300@simtech.uni-stuttgart.de>
 <20151006214151.GA26620@megas.khq.kitware.com>
 <CAAm+CD+s1dv3GKhfZo+bYkhP71NN1JYn0UCZYThGZGLvGnotNQ@mail.gmail.com>
Message-ID: <20151008143745.GC3347@megas.khq.kitware.com>

On Thu, Oct 08, 2015 at 13:10:54 +0000, Ryan Pavlik wrote:
> One addition I would have liked to have but haven't had time to do yet: the
> ability to have a add custom command-based build time generation, instead
> of our in addition to the CMake time generation. Some projects take a very
> long time to generate, may cause visual studio to needlessly reload project
> files, and you may only want the revision for a header file anyway. As you
> can imagine, this would share much implementation with the configure time
> code, and the prerequisite refactoring is why I haven't gotten around to
> doing it yet.

FYI, this is what sprokit's code does (based on
sprokit_configure_file[1]). I honestly don't think configure time git
information is all that useful anyways, so build-time generation is the
only way sprokit does it (and it handles tarball builds just fine too).

--Ben

[1]https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake#L73

From mfgalimullin at yandex.ru  Thu Oct  8 11:06:40 2015
From: mfgalimullin at yandex.ru (Marsel Galimullin)
Date: Thu, 8 Oct 2015 18:06:40 +0300
Subject: [cmake-developers] automatically download library
In-Reply-To: <DF826CD4-D8FF-4C9C-9AC0-7C0BD2EFD65B@ryandesign.com>
References: <579971444134173@web23j.yandex.ru>
 <DF826CD4-D8FF-4C9C-9AC0-7C0BD2EFD65B@ryandesign.com>
Message-ID: <56168680.2070206@yandex.ru>

The idea is that CMake has possibility to contact with package managers 
for download necessary libraries.
If ?find_package? can?t find a library, it need to call apt-get install.
Example:
     auto_downland(apt-get)
     find_package (Boost COMPONENTS system thread REQUIRED)


06.10.2015 15:33, Ryan Schmidt wrote:
> On Oct 6, 2015, at 7:22 AM, ??????? ?????????? wrote:
>
>> I'm student of the University LETI and as a masrer's thesis I want to develop an extension to CMake. It is expected that this extension will automatically download missing library if instruction such as ?find_package (Boost COMPONENTS system thread REQUIRED)? can not find the package. Could you give me some advices where to begin and which the best direction to design, develop and whether to do it?
> If you need that for some special purpose, go for it, but it's probably not a behavior most users would expect, and it's definitely a behavior that would have to be disabled in any software installed by a package management system. (The package management system would want to be in control of what gets downloaded.)
>
>

-- 
Kind regards,
Marsel Galimullin.


From daniel.wirtz at simtech.uni-stuttgart.de  Thu Oct  8 11:16:33 2015
From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz)
Date: Thu, 8 Oct 2015 17:16:33 +0200
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
In-Reply-To: <20151008143745.GC3347@megas.khq.kitware.com>
References: <56125601.8090300@simtech.uni-stuttgart.de>
 <20151006214151.GA26620@megas.khq.kitware.com>
 <CAAm+CD+s1dv3GKhfZo+bYkhP71NN1JYn0UCZYThGZGLvGnotNQ@mail.gmail.com>
 <20151008143745.GC3347@megas.khq.kitware.com>
Message-ID: <561688D1.6050400@simtech.uni-stuttgart.de>

Yo,

@ben / "I honestly don't think configure time git information is all 
that useful anyways"
in our scenario, the configure time information is actually more 
relevant. we use the "superbuild" scheme and also provide
a "support" target that collects configuration info and variables if 
something goes wrong during builds. therein, the git information is 
crucial for us
if we want to track down the errors they encounter.
of course, this doesn't mean the build-time info is irrelevant.

@ben / "support for SVN, Mercurial and others"
so are we talking about a "GetCVSInfo"-type module here? if so, i think 
this will quickly grow too big and tedious to handle.
people change cvs systems for their source rarely, and changing the 
couple of commands upon cvs switching seems the more tidy way down the 
road (to me)

@ryan
thanks for mentioning.. now we kinda have three propositions regarding 
git version info "out there".

this leads me to the question on how the decision making process within 
the CMake devs is ideally organized?
should there be some "specifications" on what should be possible?

Daniel

Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044

On 10/08/2015 04:37 PM, Ben Boeckel wrote:
> On Thu, Oct 08, 2015 at 13:10:54 +0000, Ryan Pavlik wrote:
>> One addition I would have liked to have but haven't had time to do yet: the
>> ability to have a add custom command-based build time generation, instead
>> of our in addition to the CMake time generation. Some projects take a very
>> long time to generate, may cause visual studio to needlessly reload project
>> files, and you may only want the revision for a header file anyway. As you
>> can imagine, this would share much implementation with the configure time
>> code, and the prerequisite refactoring is why I haven't gotten around to
>> doing it yet.
> FYI, this is what sprokit's code does (based on
> sprokit_configure_file[1]). I honestly don't think configure time git
> information is all that useful anyways, so build-time generation is the
> only way sprokit does it (and it handles tarball builds just fine too).
>
> --Ben
>
> [1]https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake#L73


From brad.king at kitware.com  Thu Oct  8 11:23:35 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 11:23:35 -0400
Subject: [cmake-developers] Visual Studio 6/7 removal
In-Reply-To: <mv3rp4$2f3$2@ger.gmane.org>
References: <mv3rp4$2f3$2@ger.gmane.org>
Message-ID: <56168A77.9040205@kitware.com>

On 10/07/2015 03:28 PM, Stephen Kelly wrote:
> The CMake 3.3 notes deprecation of VS 6/7 generators. 
> 
> Can they be removed in the CMake 3.5 cycle, or is that intended for a later 
> release?

I had intended to remove them in 3.6 so that one year notice will
have been given.

-Brad


From brad.king at kitware.com  Thu Oct  8 11:23:30 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 11:23:30 -0400
Subject: [cmake-developers] Moving from Module to Target-based linking
In-Reply-To: <CAAm+CDLxkTDoxt=C=_x-1_mZqyMdzZC2_EhcKJL5txxWjfD-SA@mail.gmail.com>
References: <5614D1C9.4080506@simtech.uni-stuttgart.de>
 <CAAm+CDLxkTDoxt=C=_x-1_mZqyMdzZC2_EhcKJL5txxWjfD-SA@mail.gmail.com>
Message-ID: <56168A72.6050608@kitware.com>

On 10/08/2015 08:58 AM, Ryan Pavlik wrote:
> Happy to learn the correct way to make an imported target for a found
> framework if someone cares to enlighten :)

There is an example in FindGLUT.  Ideally find_library should be taught
to find the "foo.framework/foo" file instead of the "foo.framework"
directory but that will require a policy and some other changes to
accomplish.

> On Wed, Oct 7, 2015, 3:04 AM Daniel Wirtz wrote:
>> is there any development going on towards providing FindXXX.cmake
>> wrapper modules that "convert" MODULE-mode results into CONFIG style
>> imported targets to consume?

We'd like to head in that direction but there is no plan for a dedicated
sweep through all modules by upstream devs.  We're depending on users
to contribute conversions for the modules they need.

-Brad


From brad.king at kitware.com  Thu Oct  8 11:23:40 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 11:23:40 -0400
Subject: [cmake-developers] [PATCH] set Content-Type in ctest http file
 uploads
In-Reply-To: <CAO1ikSaKdugpXuYqHwOiUZXTbx+LHo6tAc94p=XToAoU8G4iCg@mail.gmail.com>
References: <CAO1ikSaKdugpXuYqHwOiUZXTbx+LHo6tAc94p=XToAoU8G4iCg@mail.gmail.com>
Message-ID: <56168A7C.50608@kitware.com>

On 10/07/2015 06:07 PM, Derek Bruening via cmake-developers wrote:
> The attached patch fixes https://cmake.org/Bug/view.php?id=15774

Thanks, applied:

 CTest: Set Content-Type header for http file upload (#15774)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b700612

-Brad


From brad.king at kitware.com  Thu Oct  8 11:23:43 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 11:23:43 -0400
Subject: [cmake-developers] automatically download library
In-Reply-To: <56168680.2070206@yandex.ru>
References: <579971444134173@web23j.yandex.ru>
 <DF826CD4-D8FF-4C9C-9AC0-7C0BD2EFD65B@ryandesign.com>
 <56168680.2070206@yandex.ru>
Message-ID: <56168A7F.3080307@kitware.com>

On 10/08/2015 11:06 AM, Marsel Galimullin wrote:
> The idea is that CMake has possibility to contact with package managers 
> for download necessary libraries.
> If ?find_package? can?t find a library, it need to call apt-get install.
> Example:
>      auto_downland(apt-get)
>      find_package (Boost COMPONENTS system thread REQUIRED)

This does not provide enough information to know what package to install.
This problem is not in scope for a build system.  Another tool should
be used to install dependencies ahead of time before running CMake.
The source tree could come with some kind of dependency spec file for
such a tool to use but this would be independent of the build system.

-Brad


From brad.king at kitware.com  Thu Oct  8 11:38:00 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 11:38:00 -0400
Subject: [cmake-developers] CXX_STANDARD and linking
In-Reply-To: <mv3rcq$2f3$1@ger.gmane.org>
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org> <5613E876.4010603@kitware.com>
 <mv3rcq$2f3$1@ger.gmane.org>
Message-ID: <56168DD8.6050302@kitware.com>

On 10/07/2015 03:22 PM, Stephen Kelly wrote:
> The CMake 3.3 behavior of this is the same as it has always been since 
> introducing compile-features for SolarisStudio. 

Well that behavior was broken.  We never had a nightly dashboard for it.
Now I got nightly testing set up and it fails many tests without my changes.

I should have insisted that a 12.4 dashboard client be working
before the features support for it was ever merged to 'master'.
Then we would have found this before broken support was ever
released.

> Any users aware that compile-features only affect compilation will have 
> added the link flag themselves with one of the already available mechanims. 
> Such users will be affected by this CMake 3.4 change.

Since no one complained about this problem before I'm not concerned.
Even if users have this case they were adding workarounds before and
can add different ones now (like just adding -std=c++11 manually).
The whole feature was DOA.

> For the build of CMake itself on Solaris, we should probably add the 
> required link flag until there is a porcelian feature for it (in 
> CompileFlags.cmake?).

This is done already by adding -std=c++03 to CMAKE_CXX_FLAGS.
When CMAKE_CXX_STANDARD is set to 11 then the build breaks when
using CMake 3.3.  It is only building now with CMake_NO_CXX_STANDARD
or with 3.4's reversion of the broken support.

> I'm also not confident in commit v3.4.0-rc1~10^2~1 (Features: Fix C++98 
> flags on Oracle SolarisStudio 12.4 on Linux, 2015-09-30) because it will 
> mean that 'c++98 mode' on Solaris 12.4 is forced to use libstdc++ instead of 
> stlport4 or libCstd (rougewave). I'm not sure of the implications of that.

Without that change CMake fails to generate complaining that
CMAKE_CXX98_EXTENSION_COMPILE_OPTION is not set.  Do you have
another solution for that?

> So, it might be best to revert that commit and its parent.

Or we should revert SolarisStudio compiler features completely even
on Linux.  It was apparently never implemented or tested properly.
Until stdlib selection is implemented then it cannot work.

-Brad


From cmake-2015 at ryandesign.com  Thu Oct  8 11:41:09 2015
From: cmake-2015 at ryandesign.com (Ryan Schmidt)
Date: Thu, 8 Oct 2015 10:41:09 -0500
Subject: [cmake-developers] automatically download library
In-Reply-To: <56168680.2070206@yandex.ru>
References: <579971444134173@web23j.yandex.ru>
 <DF826CD4-D8FF-4C9C-9AC0-7C0BD2EFD65B@ryandesign.com>
 <56168680.2070206@yandex.ru>
Message-ID: <2B45E15F-8F82-4BB1-9A40-18C63F3C308C@ryandesign.com>


On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:

> The idea is that CMake has possibility to contact with package managers for download necessary libraries.
> If ?find_package? can?t find a library, it need to call apt-get install.
> Example:
>    auto_downland(apt-get)
>    find_package (Boost COMPONENTS system thread REQUIRED)

I understand the idea, and I'm telling you that if you need this for your own personal project -- one that will never be included in a package management system -- then do whatever you like. But if you are proposing this as something that should be included in cmake, and you are suggesting that it could be used by any project that wants to -- even in projects that might someday be included in a package management system -- then I can tell you that this would not be welcomed by the people who maintain those package management systems. I am such a person. If I were tasked with the request to add to my package management system a project that wanted to control the installation of its own dependencies, or that in some other way tried to be in charge of downloading its dependencies, I would either have to rip all that code out, or more likely I would reject the request to add that project as being too labor-intensive. It is the package management system's job to download and install dependencies, not the job of the project's build system.


From brad.king at kitware.com  Thu Oct  8 11:48:06 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 11:48:06 -0400
Subject: [cmake-developers] [Review Request] New module: IncludeUrl
In-Reply-To: <56152916.1060801@drdanz.it>
References: <56152916.1060801@drdanz.it>
Message-ID: <56169036.1040300@kitware.com>

On 10/07/2015 10:15 AM, Daniele E. Domenichelli wrote:
> Please review the "IncludeUrl" topic[1] that adds a new "IncludeUrl"
> module. This module adds the include_url command that is useful to
> download and include other CMake modules from a given url.

I wish you had come asking about this proposal to hold discussion
before going through all the work to implement this.  I do not
think this is a good idea as proposed, at least for deployment
with upstream CMake.

> The main use case for such a module is for groups that have several
> projects or CMake scripts, handled by different developers, that import
> the same CMake module that is sometimes updated, and they want to keep
> these files synchronized in all the projects. This is very hard to
> achieve when the developers are many and don't care too much about the
> build system. Instead of adding this file to each project, this module
> allows to put it somewhere, and automatically download and include it
> when required.

This means the module is not versioned with the includers and could
break them with an update.  If EXPECTED_HASH is used then the includer
must be modified whenever there is an update anyway.  If EXPECTED_HASH
is not used then you're running code downloaded over a network with
no chance to check it.

Instead the common files can come with some external package and found
with find_package.  Then at least some versioning can be done.  See
KDE's extra-cmake-modules for example.

-Brad


From ben.boeckel at kitware.com  Thu Oct  8 11:54:38 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 8 Oct 2015 11:54:38 -0400
Subject: [cmake-developers] added get_git_revision and get_git_branch
 commands as follow-up to cmake@cmake.org
In-Reply-To: <561688D1.6050400@simtech.uni-stuttgart.de>
References: <56125601.8090300@simtech.uni-stuttgart.de>
 <20151006214151.GA26620@megas.khq.kitware.com>
 <CAAm+CD+s1dv3GKhfZo+bYkhP71NN1JYn0UCZYThGZGLvGnotNQ@mail.gmail.com>
 <20151008143745.GC3347@megas.khq.kitware.com>
 <561688D1.6050400@simtech.uni-stuttgart.de>
Message-ID: <20151008155438.GA32188@megas.khq.kitware.com>

On Thu, Oct 08, 2015 at 17:16:33 +0200, Daniel Wirtz wrote:
> @ben / "I honestly don't think configure time git information is all 
> that useful anyways"
> in our scenario, the configure time information is actually more 
> relevant. we use the "superbuild" scheme and also provide
> a "support" target that collects configuration info and variables if 
> something goes wrong during builds. therein, the git information is 
> crucial for us
> if we want to track down the errors they encounter.
> of course, this doesn't mean the build-time info is irrelevant.

OK, that info is useful there, but *those* results should not end up in
the build itself. The documentation needs to be clear about this.

> @ben / "support for SVN, Mercurial and others"
> so are we talking about a "GetCVSInfo"-type module here? if so, i think 
> this will quickly grow too big and tedious to handle.

No, just that you could say any of:

    configure_revision_info(git "${source}" "${dest}")
    configure_revision_info(cvs "${source}" "${dest}")
    configure_revision_info(hg "${source}" "${dest}")

and then the generated file does:

    include("RevisionExtract_${source_control}")

so that other source control systems can have "get relevant info"
modules to run at build time rather than baking git magic into the file
directly.

--Ben

From mantis at public.kitware.com  Thu Oct  8 12:03:44 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 8 Oct 2015 12:03:44 -0400
Subject: [cmake-developers] [CMake 0015778]: Support BOOST_LIBRARYDIR_DEBUG
	and BOOST_LIBRARYDIR_RELEASE
Message-ID: <29c437427d02f5d3b69b75e37fbe1ca4@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15778 
====================================================================== 
Reported By:                KindDragon
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15778
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-08 12:03 EDT
Last Modified:              2015-10-08 12:03 EDT
====================================================================== 
Summary:                    Support BOOST_LIBRARYDIR_DEBUG and
BOOST_LIBRARYDIR_RELEASE
Description: 
I want use my compiled Boost where debug and release libraries stored in
different directories

Steps to Reproduce: 
You can't set different BOOST_LIBRARYDIR for debug and release configurations
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-08 12:03 KindDragon     New Issue                                    
======================================================================


From brad.king at kitware.com  Thu Oct  8 13:24:02 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 08 Oct 2015 13:24:02 -0400
Subject: [cmake-developers] CXX_STANDARD and linking
In-Reply-To: <56168DD8.6050302@kitware.com>
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org> <5613E876.4010603@kitware.com>
 <mv3rcq$2f3$1@ger.gmane.org> <56168DD8.6050302@kitware.com>
Message-ID: <5616A6B2.4010400@kitware.com>

On 10/08/2015 11:38 AM, Brad King wrote:
> On 10/07/2015 03:22 PM, Stephen Kelly wrote:
>> The CMake 3.3 behavior of this is the same as it has always been since 
>> introducing compile-features for SolarisStudio. 
> 
> Well that behavior was broken.  We never had a nightly dashboard for it.
> Now I got nightly testing set up and it fails many tests without my changes.

OTOH I should not have rushed in this change for 3.4.  We can just let
it act as 3.3 did and no one will be worse off.  Then we can pick this
up in post-3.4 development.  Reverted for now:

 Revert topic 'compiler-features-solaris'
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897

I've scheduled this for the 'release' branch for 3.4.0-rc2.

-Brad


From ddomenichelli at drdanz.it  Thu Oct  8 14:28:33 2015
From: ddomenichelli at drdanz.it (Daniele E. Domenichelli)
Date: Thu, 8 Oct 2015 20:28:33 +0200
Subject: [cmake-developers] [Review Request] New module: IncludeUrl
In-Reply-To: <56169036.1040300@kitware.com>
References: <56152916.1060801@drdanz.it> <56169036.1040300@kitware.com>
Message-ID: <5616B5D1.4090302@drdanz.it>

Hello Brad,

thanks for your comments.


On 08/10/2015 17:48, Brad King wrote:
> I wish you had come asking about this proposal to hold discussion
> before going through all the work to implement this.

We've been successfully using this module for about 2 years now and we
will continue to use it anyway, so I did not waste time... We just
thought that this module could be useful for other people, so most of
the work was just adding the unit tests, and it was worth doing it,
because I ended up fixing several bugs that came out. ;)



> I do not think this is a good idea as proposed, at least for
> deployment with upstream CMake.

I understand this is a quite controversial module, but I would like to
stress that this is something that can already be done using CMake just
by executing file(DOWNLOAD) and include(), this module just makes it
easy to do it. Whether this is a security issue or not is up to how this
module is used.

Also note that the ExternalProject module does something that is
conceptually very similar, i.e. downloads some code from somewhere on
the internet, and includes it in your project. Unfortunately
ExternalProject does not allow you to do it at configure time*, but only
at build time, that means you cannot, for example, use a module from ECM
in your build system unless it is installed.


* Actually I managed to do that, but it is a quite ugly solution that
requires ~100 lines of CMake code.



>> The main use case for such a module is for groups that have several
>> projects or CMake scripts, handled by different developers, that import
>> the same CMake module that is sometimes updated, and they want to keep
>> these files synchronized in all the projects. This is very hard to
>> achieve when the developers are many and don't care too much about the
>> build system. Instead of adding this file to each project, this module
>> allows to put it somewhere, and automatically download and include it
>> when required.
> 
> This means the module is not versioned with the includers and could
> break them with an update.

Of course this depends a lot on the content of the file. A simple file
containing just a few variables, will hardly break with an update. A
more complicated file containing macros or functions might break, but
this could also happen if you have your module in some external package,
and you update the package version.



> If EXPECTED_HASH is used then the includer must be modified whenever
> there is an update anyway.

Yes, indeed. This is useful if you depend on a specific version of a
file and don't want to use a new version even if the module is updated.
For example you could use a raw file at a specific git revision if you
want to be sure that the file you are using will never change.
Of course you could include it in your project, but this increases code
duplication* and makes a lot less clear what is happening. Where does
the file come from? Which version is it? Was it updated upstream and if
it was, where can I get the latest version of the file? Does it have
local changes?


* It is quite interesting to note that in order to reduce the code
duplication, we duplicated this module in several places, good reason
for wanting it upstream! :)



> If EXPECTED_HASH is not used then you're running code downloaded over a
> network with no chance to check it.

You can still use the TLS_VERIFY to verify the https server certificate
to ensure that the origin of the file is the one you are expecting.

Also the same thing could happen for a package downloaded using
ExternalProject, if someone added malicious code in the CMakeLists.txt
of one project, when you run "make", the project is downloaded and
configured, hence the malicious code is executed without giving you the
chance to check it.



> Instead the common files can come with some external package and found
> with find_package.  Then at least some versioning can be done.  See
> KDE's extra-cmake-modules for example.

That means adding an extra dependencies to the build system. The user
will have to install it _before_ installing your software, and to keep
it updated. Also having modules that depend on different versions of the
package becomes complicated.


In a research environment, the software development cycle is heavily
driven by project or paper deadlines. Academic research products are
scientific papers, not code. Researchers are not software engineers, and
they don't want to waste time on the build system or handling
dependencies issues.
Imagine you create a demo module doing something very cool that uses one
module from package X. You commit your code somewhere, write a paper,
and then forget about it for years. Time passes and at some point
someone else reads your paper and wants to try it, but meanwhile he has
several other packages that depend on a newer version of X and since the
code won't compile, he will not try your code and of course he will not
waste time on it and he will not cite your paper in his work.



Another possible application is for CDash build machines. In CMake you
have a script that describes the machine and the build flags, and then
just includes a cmake_common.cmake script that must be downloaded and
updated by the user (even though it's not updated very often).
If for some reason in your project you have to change this script often
(for example because you use CDash with subprojects, and you must update
the list of the modules whenever a project is added or removed), using
this module you could ensure that all the machines are always building
using the latest version of the script without manual intervention.



I hope I made myself clear about the reasons why I believe this is a
useful module and a good candidate for being upstream, but if you still
think that this is not a good idea, I will withdraw my proposal, no
offence taken :)



Cheers,
 Daniele


From marc.chevrier at sap.com  Fri Oct  9 04:14:03 2015
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Fri, 9 Oct 2015 08:14:03 +0000
Subject: [cmake-developers] CXX_STANDARD and linking
In-Reply-To: <5616A6B2.4010400@kitware.com>
References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com>
 <56056725.5050503@kitware.com>
 <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com>
 <56097C16.3020301@kitware.com> <muc16s$i16$1@ger.gmane.org>
 <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com>
 <mure6c$sp4$1@ger.gmane.org> <5613E876.4010603@kitware.com>
 <mv3rcq$2f3$1@ger.gmane.org> <56168DD8.6050302@kitware.com>
 <5616A6B2.4010400@kitware.com>
Message-ID: <9525C66B-5436-4A90-A57B-21C83BA98BCC@sap.com>

No problem for me to keep broken behavior of SolarisStudio.
Let me know when C++ Standard support including linking part is implemented, I can help you to validate it on Solaris SPARC.

Thanks.

Marc




On 08/10/15 19:24, "cmake-developers on behalf of Brad King" <cmake-developers-bounces at cmake.org on behalf of brad.king at kitware.com> wrote:

>On 10/08/2015 11:38 AM, Brad King wrote:
>> On 10/07/2015 03:22 PM, Stephen Kelly wrote:
>>> The CMake 3.3 behavior of this is the same as it has always been since 
>>> introducing compile-features for SolarisStudio. 
>> 
>> Well that behavior was broken.  We never had a nightly dashboard for it.
>> Now I got nightly testing set up and it fails many tests without my changes.
>
>OTOH I should not have rushed in this change for 3.4.  We can just let
>it act as 3.3 did and no one will be worse off.  Then we can pick this
>up in post-3.4 development.  Reverted for now:
>
> Revert topic 'compiler-features-solaris'
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897
>
>I've scheduled this for the 'release' branch for 3.4.0-rc2.
>
>-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 hobbsk at ohio.edu  Fri Oct  9 10:06:53 2015
From: hobbsk at ohio.edu (Kevin H. Hobbs)
Date: Fri, 9 Oct 2015 10:06:53 -0400
Subject: [cmake-developers] ITK NIfTI broken Oct 6
Message-ID: <5617C9FD.9010702@ohio.edu>

The ITK dashboard builds on bubbles, murron, and k450e all started
failing at the configure step on October 6.

These builds all use the development version of CMake.

There were no remarkable changes in ITK that night, however there were
some interesting updates to CMake.

The errors are in the third party library NIfTI and look like this :

CMake Error at
Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "znz".


CMake Error at
Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:28 (install):
  install FILES given no DESTINATION!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151009/da4e8472/attachment.sig>

From roman.wueger at gmx.at  Fri Oct  9 11:51:12 2015
From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=)
Date: Fri, 9 Oct 2015 17:51:12 +0200
Subject: [cmake-developers] Xcode build settings and BullseyeCoverage
Message-ID: <1a3b01d102aa$541715f0$fc4541d0$@gmx.at>

Hello,

 

I?m trying to configure and build a project with the ?Xcode? generator and
the bullseye coverage tool.

Without the bullseye coverage tool it works fine but if I want to use it I
had to do the following workaround:
http://www.bullseye.com/help/tool-xcode.html

 

In short words, the clang and clang++ ExecPath would be changed from ?clang?
=> ?$(PLATFORM_DEVELOPER_BIN_DIR)/clang? and ?clang++? =>
?$(PLATFORM_DEVELOPER_BIN_DIR)/clang++?

 

Before I made the changes, CMake finds clang/clang++ under
?/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch
ain/usr/bin/clang?, with the changes CMake tries to find clang/clang++ under
?/Applications/Xcode.app/Contents/Developer/usr/bin/clang? which doesn?t
exist.

And I got the following error:

 

-- The C compiler identification is unknown

-- The CXX compiler identification is unknown

CMake Error at CMakeLists.txt:3 (project):

  No CMAKE_C_COMPILER could be found.

 

 

 

CMake Error at CMakeLists.txt:3 (project):

  No CMAKE_CXX_COMPILER could be found.

 

 

 

-- Configuring incomplete, errors occurred!

 

 

However, without the changes I could build the project with ?cmake ?build .
-- -showBuildSettings? which gives me the following information

 

.

.

.

    PLATFORM_DEVELOPER_APPLICATIONS_DIR =
/Applications/Xcode.app/Contents/Developer/Applications

    PLATFORM_DEVELOPER_BIN_DIR =
/Applications/Xcode.app/Contents/Developer/usr/bin

    PLATFORM_DEVELOPER_LIBRARY_DIR =
/Applications/Xcode.app/Contents/Developer/Library

    PLATFORM_DEVELOPER_SDK_DIR =
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develop
er/SDKs

    PLATFORM_DEVELOPER_TOOLS_DIR =
/Applications/Xcode.app/Contents/Developer/Tools

    PLATFORM_DEVELOPER_USR_DIR =
/Applications/Xcode.app/Contents/Developer/usr

    PLATFORM_DIR =
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform

.

.

.

 

Why doesn?t find CMake Xcode with the modified path?

 

Is there also a way to set generator specific things during configure time?

At the moment it is only possible with the build command: ?cmake -build . --
PLATFORM_DEVELOPER_BIN_DIR=PointToSomething? which sets the build settings
for Xcode

 

 

Thanks in advance

 

Best Regards

Roman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151009/e41ffd47/attachment-0001.html>

From mfgalimullin at yandex.ru  Fri Oct  9 09:16:02 2015
From: mfgalimullin at yandex.ru (=?UTF-8?B?0JzQsNGA0YHQtdC70Ywg0JPQsNC70LjQvNGD0LvQu9C40L0=?=)
Date: Fri, 9 Oct 2015 16:16:02 +0300
Subject: [cmake-developers] automatically download library
In-Reply-To: <2B45E15F-8F82-4BB1-9A40-18C63F3C308C@ryandesign.com>
References: <579971444134173@web23j.yandex.ru>
 <DF826CD4-D8FF-4C9C-9AC0-7C0BD2EFD65B@ryandesign.com>
 <56168680.2070206@yandex.ru>
 <2B45E15F-8F82-4BB1-9A40-18C63F3C308C@ryandesign.com>
Message-ID: <5617BE12.6070306@yandex.ru>

Thanks for your comments.

08.10.2015 18:41, Ryan Schmidt ?????:
> On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:
>
>> The idea is that CMake has possibility to contact with package managers for download necessary libraries.
>> If ?find_package? can?t find a library, it need to call apt-get install.
>> Example:
>>     auto_downland(apt-get)
>>     find_package (Boost COMPONENTS system thread REQUIRED)
> I understand the idea, and I'm telling you that if you need this for your own personal project -- one that will never be included in a package management system -- then do whatever you like. But if you are proposing this as something that should be included in cmake, and you are suggesting that it could be used by any project that wants to -- even in projects that might someday be included in a package management system -- then I can tell you that this would not be welcomed by the people who maintain those package management systems. I am such a person. If I were tasked with the request to add to my package management system a project that wanted to control the installation of its own dependencies, or that in some other way tried to be in charge of downloading its dependencies, I would either have to rip all that code out, or more likely I would reject the request to add that project as being too labor-intensive. It is the package management system's job to download and install dependencies, not the job of the project's build system.
>

-- 
Kind regards,

Marsel Galimullin.



From ruslan_baratov at yahoo.com  Fri Oct  9 18:00:09 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Sat, 10 Oct 2015 01:00:09 +0300
Subject: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp
 checks use only 1s resolution
In-Reply-To: <6934fe0768634bce98b2955754827845@cmake.org>
References: <6934fe0768634bce98b2955754827845@cmake.org>
Message-ID: <561838E9.1060102@yahoo.com>

On 08-Oct-15 21:03, Mantis Bug Tracker wrote:
> The following issue has been ASSIGNED.
> ======================================================================
> https://cmake.org/Bug/view.php?id=15769
> ======================================================================
> Reported By:                Ruslan Baratov
> Assigned To:                Brad King
> ======================================================================
> Project:                    CMake
> Issue ID:                   15769
> Category:                   CMake
> Reproducibility:            always
> Severity:                   minor
> Priority:                   normal
> Status:                     resolved
> Target Version:             CMake 3.5
> Resolution:                 fixed
> Fixed in Version:           CMake 3.5
> ======================================================================
> Date Submitted:             2015-10-05 10:37 EDT
> Last Modified:              2015-10-08 14:03 EDT
> ======================================================================
> Summary:                    OS X: Filesystem timestamp checks use only 1s
> resolution
> Description:
> `cmake --build` command doesn't trigger reconfiguration of the project on OS X
> when CMakeLists.txt changed.
>
> Example:
>
> add_executable(foo foo.cpp) # file foo.cpp exists
>
> cmake -H. -B_builds
> cmake --build _builds
> # OK
>
> change:
> add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
> cmake --build _builds
> # expected error, but no error reported
>
> Ready-to-run example can be found:
> https://github.com/forexample/cmake-osx-no-reconfigure-bug
>
> Log from OS X machine:
> * https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171
>
> Log for similar test on Linux machine:
> * https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953
>
> CMake on Linux machine run reconfigure command and report an error:
>    cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
>    -- Configuring done
>    CMake Error at CMakeLists.txt:4 (add_executable):
>      Cannot find source file:
>        boo.cpp
>
> same error expected on OS X machine
> ======================================================================
>
> ----------------------------------------------------------------------
>   (0039511) Brad King (manager) - 2015-10-05 14:45
>   https://cmake.org/Bug/view.php?id=15769#c39511
> ----------------------------------------------------------------------
> I can reproduce this when running 'make' directly without 'cmake --build':
>
>   -cmake --build _builds
>   +(cd _builds; make)
>
> The problem is that the filesystem and/or make tool seem to have 1s timestamp
> resolution.  If I change the script to do "sleep 1" before the last "cp
> CMakeBad.txt CMakeLists.txt" then it works.
>
> ----------------------------------------------------------------------
>   (0039512) Brad King (manager) - 2015-10-05 14:52
>   https://cmake.org/Bug/view.php?id=15769#c39512
> ----------------------------------------------------------------------
> The issue may be where CMake decides whether it needs to re-run:
>
>   https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147
>
> The STAT_HAS_ST_MTIM code path may not be taken on this platform.
>
> ----------------------------------------------------------------------
>   (0039513) Brad King (manager) - 2015-10-05 14:54
>   https://cmake.org/Bug/view.php?id=15769#c39513
> ----------------------------------------------------------------------
> Indeed, on OS X "struct stat" has:
>
>   struct timespec st_mtimespec;
>
> instead of
>
>   struct timespec st_mtim;
>
> ----------------------------------------------------------------------
>   (0039518) Brad King (manager) - 2015-10-06 13:27
>   https://cmake.org/Bug/view.php?id=15769#c39518
> ----------------------------------------------------------------------
> For reference, I've started a fix for this on the KWSys side here:
>
>   http://review.source.kitware.com/20258/
>
> ----------------------------------------------------------------------
>   (0039519) Brad King (manager) - 2015-10-06 14:04
>   https://cmake.org/Bug/view.php?id=15769#c39519
> ----------------------------------------------------------------------
> It looks like the underlying HFS filesystem only has 1s resolution:
>
>   https://en.wikipedia.org/wiki/HFS_Plus
>
> This may not be possible to fix without a "sleep 1" in the test script.
>
> ----------------------------------------------------------------------
>   (0039548) Brad King (manager) - 2015-10-08 14:01
>   https://cmake.org/Bug/view.php?id=15769#c39548
> ----------------------------------------------------------------------
> After the KWSys side learned to use st_mtimespec I've updated CMake too:
>
>   cmFileTimeComparison: Port to OS X nanosecond times
>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407
>
> ----------------------------------------------------------------------
>   (0039549) Brad King (manager) - 2015-10-08 14:03
>   https://cmake.org/Bug/view.php?id=15769#c39549
> ----------------------------------------------------------------------
> Marking as resolved because the proper API for ns resolution is now used.
> However in practice the underlying filesystem may limit the resolution anyway.
>   
>
> Issue History
> Date Modified    Username       Field                    Change
> ======================================================================
> 2015-10-05 10:37 Ruslan Baratov New Issue
> 2015-10-05 14:45 Brad King      Note Added: 0039511
> 2015-10-05 14:52 Brad King      Note Added: 0039512
> 2015-10-05 14:53 Brad King      Summary                  Change of
> CMakeLists.txt doesn't trigger reconfigure => OS X: Filesystem timestamp checks
> use only 1s resolution
> 2015-10-05 14:54 Brad King      Note Added: 0039513
> 2015-10-06 13:27 Brad King      Note Added: 0039518
> 2015-10-06 14:04 Brad King      Note Added: 0039519
> 2015-10-08 14:01 Brad King      Note Added: 0039548
> 2015-10-08 14:03 Brad King      Note Added: 0039549
> 2015-10-08 14:03 Brad King      Assigned To               => Brad King
> 2015-10-08 14:03 Brad King      Status                   new => resolved
> 2015-10-08 14:03 Brad King      Resolution               open => fixed
> 2015-10-08 14:03 Brad King      Fixed in Version          => CMake 3.5
> 2015-10-08 14:03 Brad King      Target Version            => CMake 3.5
> ======================================================================
>
Hi,

While viewing changes you've made I found an "interesting" behaviour of 
CMake's install procedure. Since it's not about this bug exactly I'm 
moving it to 'cmake-developers' list. Function 
cmFileTimeComparisonInternal::TimesDiffer use only limited number of 
digits of timestamp and used in install step. This may lead to the 
similar bugs.

Here is the result of my white-box testing skills:
script: 
https://github.com/forexample/cmake-header-install-bug/blob/master/run-test.sh
log: 
https://travis-ci.org/forexample/cmake-header-install-bug/builds/84592318

    -- Up-to-date:
    /Users/travis/build/forexample/cmake-header-install-bug/_install/include/foo.hpp
    1c1
    < Bad
    ---
     > Good
    Error: file not installed!

So installed foo.hpp file is not updated. This may be quite surprising 
in automated tools like git-bisect. Also I've found 
`CMAKE_INSTALL_ALWAYS` environment variable but it's not documented.

Thanks, Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151010/95c0f40c/attachment.html>

From ruslan_baratov at yahoo.com  Fri Oct  9 19:02:15 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Sat, 10 Oct 2015 02:02:15 +0300
Subject: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp
 checks use only 1s resolution
In-Reply-To: <561838E9.1060102@yahoo.com>
References: <6934fe0768634bce98b2955754827845@cmake.org>
 <561838E9.1060102@yahoo.com>
Message-ID: <56184777.4070301@yahoo.com>

On 10-Oct-15 01:00, Ruslan Baratov via cmake-developers wrote:
> On 08-Oct-15 21:03, Mantis Bug Tracker wrote:
>> The following issue has been ASSIGNED.
>> ======================================================================
>> https://cmake.org/Bug/view.php?id=15769  
>> ======================================================================
>> Reported By:                Ruslan Baratov
>> Assigned To:                Brad King
>> ======================================================================
>> Project:                    CMake
>> Issue ID:                   15769
>> Category:                   CMake
>> Reproducibility:            always
>> Severity:                   minor
>> Priority:                   normal
>> Status:                     resolved
>> Target Version:             CMake 3.5
>> Resolution:                 fixed
>> Fixed in Version:           CMake 3.5
>> ======================================================================
>> Date Submitted:             2015-10-05 10:37 EDT
>> Last Modified:              2015-10-08 14:03 EDT
>> ======================================================================
>> Summary:                    OS X: Filesystem timestamp checks use only 1s
>> resolution
>> Description:
>> `cmake --build` command doesn't trigger reconfiguration of the project on OS X
>> when CMakeLists.txt changed.
>>
>> Example:
>>
>> add_executable(foo foo.cpp) # file foo.cpp exists
>>
>> cmake -H. -B_builds
>> cmake --build _builds
>> # OK
>>
>> change:
>> add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
>> cmake --build _builds
>> # expected error, but no error reported
>>
>> Ready-to-run example can be found:
>> https://github.com/forexample/cmake-osx-no-reconfigure-bug
>>
>> Log from OS X machine:
>> *https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171
>>
>> Log for similar test on Linux machine:
>> *https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953
>>
>> CMake on Linux machine run reconfigure command and report an error:
>>    cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
>>    -- Configuring done
>>    CMake Error at CMakeLists.txt:4 (add_executable):
>>      Cannot find source file:
>>        boo.cpp
>>
>> same error expected on OS X machine
>> ======================================================================
>>
>> ----------------------------------------------------------------------
>>   (0039511) Brad King (manager) - 2015-10-05 14:45
>>   https://cmake.org/Bug/view.php?id=15769#c39511  
>> ----------------------------------------------------------------------
>> I can reproduce this when running 'make' directly without 'cmake --build':
>>
>>   -cmake --build _builds
>>   +(cd _builds; make)
>>
>> The problem is that the filesystem and/or make tool seem to have 1s timestamp
>> resolution.  If I change the script to do "sleep 1" before the last "cp
>> CMakeBad.txt CMakeLists.txt" then it works.
>>
>> ----------------------------------------------------------------------
>>   (0039512) Brad King (manager) - 2015-10-05 14:52
>>   https://cmake.org/Bug/view.php?id=15769#c39512  
>> ----------------------------------------------------------------------
>> The issue may be where CMake decides whether it needs to re-run:
>>
>>   https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147
>>
>> The STAT_HAS_ST_MTIM code path may not be taken on this platform.
>>
>> ----------------------------------------------------------------------
>>   (0039513) Brad King (manager) - 2015-10-05 14:54
>>   https://cmake.org/Bug/view.php?id=15769#c39513  
>> ----------------------------------------------------------------------
>> Indeed, on OS X "struct stat" has:
>>
>>   struct timespec st_mtimespec;
>>
>> instead of
>>
>>   struct timespec st_mtim;
>>
>> ----------------------------------------------------------------------
>>   (0039518) Brad King (manager) - 2015-10-06 13:27
>>   https://cmake.org/Bug/view.php?id=15769#c39518  
>> ----------------------------------------------------------------------
>> For reference, I've started a fix for this on the KWSys side here:
>>
>>   http://review.source.kitware.com/20258/  
>>
>> ----------------------------------------------------------------------
>>   (0039519) Brad King (manager) - 2015-10-06 14:04
>>   https://cmake.org/Bug/view.php?id=15769#c39519  
>> ----------------------------------------------------------------------
>> It looks like the underlying HFS filesystem only has 1s resolution:
>>
>>   https://en.wikipedia.org/wiki/HFS_Plus
>>
>> This may not be possible to fix without a "sleep 1" in the test script.
>>
>> ----------------------------------------------------------------------
>>   (0039548) Brad King (manager) - 2015-10-08 14:01
>>   https://cmake.org/Bug/view.php?id=15769#c39548  
>> ----------------------------------------------------------------------
>> After the KWSys side learned to use st_mtimespec I've updated CMake too:
>>
>>   cmFileTimeComparison: Port to OS X nanosecond times
>>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407  
>>
>> ----------------------------------------------------------------------
>>   (0039549) Brad King (manager) - 2015-10-08 14:03
>>   https://cmake.org/Bug/view.php?id=15769#c39549  
>> ----------------------------------------------------------------------
>> Marking as resolved because the proper API for ns resolution is now used.
>> However in practice the underlying filesystem may limit the resolution anyway.
>>   
>>
>> Issue History
>> Date Modified    Username       Field                    Change
>> ======================================================================
>> 2015-10-05 10:37 Ruslan Baratov New Issue
>> 2015-10-05 14:45 Brad King      Note Added: 0039511
>> 2015-10-05 14:52 Brad King      Note Added: 0039512
>> 2015-10-05 14:53 Brad King      Summary                  Change of
>> CMakeLists.txt doesn't trigger reconfigure => OS X: Filesystem timestamp checks
>> use only 1s resolution
>> 2015-10-05 14:54 Brad King      Note Added: 0039513
>> 2015-10-06 13:27 Brad King      Note Added: 0039518
>> 2015-10-06 14:04 Brad King      Note Added: 0039519
>> 2015-10-08 14:01 Brad King      Note Added: 0039548
>> 2015-10-08 14:03 Brad King      Note Added: 0039549
>> 2015-10-08 14:03 Brad King      Assigned To               => Brad King
>> 2015-10-08 14:03 Brad King      Status                   new => resolved
>> 2015-10-08 14:03 Brad King      Resolution               open => fixed
>> 2015-10-08 14:03 Brad King      Fixed in Version          => CMake 3.5
>> 2015-10-08 14:03 Brad King      Target Version            => CMake 3.5
>> ======================================================================
>>
> Hi,
>
> While viewing changes you've made I found an "interesting" behaviour 
> of CMake's install procedure. Since it's not about this bug exactly 
> I'm moving it to 'cmake-developers' list. Function 
> cmFileTimeComparisonInternal::TimesDiffer use only limited number of 
> digits of timestamp and used in install step. This may lead to the 
> similar bugs.
>
> Here is the result of my white-box testing skills:
> script: 
> https://github.com/forexample/cmake-header-install-bug/blob/master/run-test.sh
> log: 
> https://travis-ci.org/forexample/cmake-header-install-bug/builds/84592318
>
>     -- Up-to-date:
>     /Users/travis/build/forexample/cmake-header-install-bug/_install/include/foo.hpp
>     1c1
>     < Bad
>     ---
>     > Good
>     Error: file not installed!
>
> So installed foo.hpp file is not updated. This may be quite surprising 
> in automated tools like git-bisect. Also I've found 
> `CMAKE_INSTALL_ALWAYS` environment variable but it's not documented.
>
And the main difference is that it affects Linux platform too: 
https://travis-ci.org/forexample/cmake-header-install-bug/builds/84601213
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151010/d5af7e8e/attachment-0001.html>

From ruslan_baratov at yahoo.com  Fri Oct  9 20:11:45 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Sat, 10 Oct 2015 03:11:45 +0300
Subject: [cmake-developers] automatically download library
In-Reply-To: <579971444134173@web23j.yandex.ru>
References: <579971444134173@web23j.yandex.ru>
Message-ID: <561857C1.2000205@yahoo.com>

On 08-Oct-15 18:06, Marsel Galimullin wrote:
> The idea is that CMake has possibility to contact with package 
> managers for download necessary libraries.
> If ?find_package? can?t find a library, it need to call apt-get install.
> Example:
>     auto_downland(apt-get)
>     find_package (Boost COMPONENTS system thread REQUIRED) 
re:{possibility to contact with package managers} *if* you have a 
suitable package manager. And even if you have one result may differs 
for different platforms, e.g.:

* OSX, brew install boost => 1.58
* Ubuntu, apt-get install boost-dev => 1.54

Note that 'find_package(Boost)' can find any user-installed libraries or 
non-host packages for cross-compile, like building Android on Linux, or 
iOS on OSX (both issues can be solved by using ExternalProject + 
superbuild). If you and your users are okay with that then it's should 
be not so hard to implement this CMake module.

On 06-Oct-15 15:22, Marsel Galimullin wrote:
>
> Hello!
> I'm student of the University LETI and as a masrer'sthesis I want to 
> developan extension to CMake. It is expected that this extension will 
> automatically download missinglibrary ifinstruction such as 
> ?find_package (Boost COMPONENTS system thread REQUIRED)? can not find 
> the package. Could you give me some advices where to begin and which 
> the best direction to design, developand whether to do it?
>
So with all this peculiarities I've described above this will be not 
such an easy task as you might expect. You can start one from scratch 
for education or fun (or both) but if you want to do some really helpful 
stuff my advice to you is to feed "cmake package manager" request to 
your web search engine and investigate existing solutions.

On 08-Oct-15 18:41, Ryan Schmidt wrote:
> On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:
>
>> The idea is that CMake has possibility to contact with package managers for download necessary libraries.
>> If ?find_package? can?t find a library, it need to call apt-get install.
>> Example:
>>     auto_downland(apt-get)
>>     find_package (Boost COMPONENTS system thread REQUIRED)
> I understand the idea, and I'm telling you that if you need this for your own personal project -- one that will never be included in a package management system -- then do whatever you like. But if you are proposing this as something that should be included in cmake, and you are suggesting that it could be used by any project that wants to -- even in projects that might someday be included in a package management system -- then I can tell you that this would not be welcomed by the people who maintain those package management systems. I am such a person. If I were tasked with the request to add to my package management system a project that wanted to control the installation of its own dependencies, or that in some other way tried to be in charge of downloading its dependencies, I would either have to rip all that code out, or more likely I would reject the request to add that project as being too labor-intensive. It is the package management system's job to download and install dependencies, not the job of the project's build system.
>
re:{I would either have to rip all that code out, or more likely I would 
reject the request to add that project as being too labor-intensive} 
this can be solved easily by adding option which is set to OFF by default:

option(USE_SUPERTOOL "Download host packages automatically" OFF)
function(auto_download ...)
   if(NOT USE_SUPERTOOL)
     # do nothing
     return()
   endif()
   # do install
endfunction()
auto_download(...) # by default do nothing
find_package(Boost COMPONENT system thread REQUIED) # find the packages 
you are expecting

On 08-Oct-15 18:23, Brad King wrote:
> On 10/08/2015 11:06 AM, Marsel Galimullin wrote:
>> The idea is that CMake has possibility to contact with package managers
>> for download necessary libraries.
>> If ?find_package? can?t find a library, it need to call apt-get install.
>> Example:
>>       auto_downland(apt-get)
>>       find_package (Boost COMPONENTS system thread REQUIRED)
> This does not provide enough information to know what package to install.
> This problem is not in scope for a build system.  Another tool should
> be used to install dependencies ahead of time before running CMake.
> The source tree could come with some kind of dependency spec file for
> such a tool to use but this would be independent of the build system.
>
> -Brad
>
re:{The source tree could come with some kind of dependency spec file 
for such a tool to use but this would be independent of the build 
system} As the one who is using such approach in my product I disagree 
with that completely :) CMake code and dependencies are in fact coupled 
strongly. For example:

    option(USE_GUI "Use some GUI for this project" OFF)
    if(USE_GUI)
       if(WIN32)
         option(USE_QT "Use Qt GUI" ON)
       else()
         option(USE_WXWIDGETS "Use WxWidgets GUI" ON)
       endif()

       # check at least one and not both

       if(USE_QT)
         find_package(Qt5Widgets REQUIED)
         target_compile_definitions(... USE_QT_GUI)
       else()
         find_package(WxWidgets REQUIRED)
         target_compile_definitions(... USE_WXWIDGETS_GUI)
       endif()
    endif()

    if(USE_SECURITY)
       find_package(OpenSSL REQUIRED)
       target_compile_definitions(... USE_OPENSSL)
    endif()

    if(BUILD_TESTS)
       find_package(GTest REQUIRED)
       ...
    endif()

    if(GENERATE_DOCUMENTATION)
       find_package(Doxygen REQUIRED)
       ...
    endif()

So instead of violating DRY and duplicating this information in some 
*newly* created format for spec file, like:

       option(USE_GUI) && WINDOWS && option(USE_QT): Qt
       option(USE_GUI) && !WINDOWS && option(USE_QT): WxWidgets
       option(USE_GUI) && WINDOWS && option(USE_WXWIDGETS): WxWidgets
       ...
       option(USE_SECURITY): OpenSSL
       option(BUILD_TESTS): GTest
       option(GENERATE_DOCUMENTATION): Doxygen

We can use CMake code:

       if(USE_QT)
         install_package(Qt)
         find_package(Qt5Widgets REQUIED)
         target_compile_definitions(... USE_QT_GUI)
       else()
         install_package(WxWidgets)
         find_package(WxWidgets REQUIRED)
         target_compile_definitions(... USE_WXWIDGETS_GUI)
       endif()


I think spec files used in many package managers because of obstructions 
that are not applying to CMake or which CMake is able to solve, some 
examples:
* python requirements.txt - no need to have a built system at all
* cocoapods - it's hard to customize/extend Xcode project to support it 
(one of the reason why such tools like CMake exist)
* brew/apt-get/emerge - (don't have any spec files actually, set 
dependencies in README file) because widely used tools like Makefile is 
not designed to do even a simple task like finding libraries, other 
tools like autotools are too complex to extend/use (again, that's why 
CMake exist)
* ... your examples here ...

Cheers, Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151010/9f46c6eb/attachment.html>

From gjasny at googlemail.com  Sat Oct 10 08:34:23 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Sat, 10 Oct 2015 14:34:23 +0200
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <5613D40C.1060609@kitware.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com> <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
 <5613D40C.1060609@kitware.com>
Message-ID: <561905CF.7070007@googlemail.com>

On 06/10/15 16:00, Brad King wrote:
> Okay, that looks like the underlying issue.  The
> Modules/Platform/Darwin-Initialize.cmake module will have
> to be taught about this case to do the right thing by default
> if it does not already.
> 
> Gregor, do you mind taking a look at this?

Sure. Ironically I just upgraded my workstation to 10.11 some minutes
before :(

What will be the desired behavior here?

At work we always use the lastest SDK (by omitting the versioned suffix)
and just set the deployment target. Works good since some years.

But I guess we want to be more conservative here and stick to old
behavior. How about adding a rule at the end that:

if (SDK is newer than host) && (is not set CMAKE_OSX_DEPLOYMENT_TARGET)
  set CMAKE_OSX_DEPLOYMENT_TARGET=<host version>
endif()

Thanks,
Gregor

From mantis at public.kitware.com  Sat Oct 10 14:12:29 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 10 Oct 2015 14:12:29 -0400
Subject: [cmake-developers] [CMake 0015780]: Dependencies relative to
	/usr/include are ignored
Message-ID: <8e72ff5cbf2bd32fd14533127d894919@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15780 
====================================================================== 
Reported By:                Kjell Irgens
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15780
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-10 14:12 EDT
Last Modified:              2015-10-10 14:12 EDT
====================================================================== 
Summary:                    Dependencies relative to /usr/include are ignored
Description: 
Include files which are included relative to /usr/include (or
/usr/local/include) do not end up in depend.make.  I do not know if this is some
kind of optimization to speed up dependency checking, but there should at least
be some way to ensure that a specific subdirectory of /usr/include (like
/usr/include/curl in the example below) is included.

The way it works on unix-like systems now, some external projects (like gtk)
have include dependencies checked while others (like curl) do not.  This is not
very consistent.

This may of course be a Fedora-specific problem, I have not checked that.


Steps to Reproduce: 
CMakeLists.txt:

cmake_minimum_required (VERSION 3.2)
project(mytest VERSION 1.0)
set(PROJECT_RELEASE rc2)
include_regular_expression("^.*$" "^.*$")
find_package (CURL REQUIRED)
add_executable (a.out main.cpp)

main.cpp:

#include <curl/curl.h>
int main() {return 0;}


Then run:
cmake .
make

Output of make:
CMake Error: Cannot find file "curl/curl.h".
[ 50%] Building CXX object CMakeFiles/a.out.dir/main.cpp.o
[100%] Linking CXX executable a.out

ls -l /usr/include/curl/curl.h
-rw-r--r--. 1 root root 89014 Dec 28  2014 /usr/include/curl/curl.h


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-10 14:12 Kjell Irgens   New Issue                                    
======================================================================


From info at takar.nl  Sat Oct 10 15:37:38 2015
From: info at takar.nl (Tamar Kranenburg)
Date: Sat, 10 Oct 2015 21:37:38 +0200
Subject: [cmake-developers] [FindPostgreSQL] Search for version 9.5
Message-ID: <4F305B1E-44BD-4A60-B111-B3BAB83EC89B@takar.nl>

Hi all,

PostgreSQL 9.5 beta 1 is released a few days ago, a final release is expected in the coming months. This small patch adds version 9.5 to the search suffixes.

Regards,
Tamar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindPostgreSQL-Search-for-version-9.5.patch
Type: application/octet-stream
Size: 876 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151010/cd2190f3/attachment.obj>

From gjasny at googlemail.com  Sun Oct 11 06:17:30 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Sun, 11 Oct 2015 12:17:30 +0200
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <561905CF.7070007@googlemail.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com> <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
 <5613D40C.1060609@kitware.com> <561905CF.7070007@googlemail.com>
Message-ID: <561A373A.4090907@googlemail.com>

Hi Francesco,

On 10/10/15 14:34, Gregor Jasny wrote:
> On 06/10/15 16:00, Brad King wrote:
>> Okay, that looks like the underlying issue.  The
>> Modules/Platform/Darwin-Initialize.cmake module will have
>> to be taught about this case to do the right thing by default
>> if it does not already.

> if (SDK is newer than host) && (is not set CMAKE_OSX_DEPLOYMENT_TARGET)
>   set CMAKE_OSX_DEPLOYMENT_TARGET=<host version>
> endif()

Could you please give the following patch to Darwin-Initialize.cmake a try?

https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=d61c6689c7380c810e060fed6bf3a0b9fbfd41d0

Brad: If we would set in line 33 the CMAKE_OSX_DEPLOYMENT_TARGET cache
variable only if ENV{MACOSX_DEPLOYMENT_TARGET} actually exists we could
get rid of the FORCE attribute later. Would that make sense?

Thanks,
Gregor

From mantis at public.kitware.com  Sun Oct 11 14:37:40 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 11 Oct 2015 14:37:40 -0400
Subject: [cmake-developers] [CMake 0015781]: FindFlex should have a
	DEFINES_FILE option in analogue with FIndBison
Message-ID: <803faacd59d99fef2cb09d84001066e4@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15781 
====================================================================== 
Reported By:                Jeeves
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15781
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   low
Status:                     new
====================================================================== 
Date Submitted:             2015-10-11 14:37 EDT
Last Modified:              2015-10-11 14:37 EDT
====================================================================== 
Summary:                    FindFlex should have a DEFINES_FILE option in
analogue with FIndBison
Description: 
Flex, like Bison, has the option to use a custom header name (%option
header-file="...") which if employed means that FLEX_TARGET built files don't
get properly cleaned.

To fix this, the macro FLEX_TARGET should have the same DEFINES_FILE option as
BISON_TARGET, to override the default header file name.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-11 14:37 Jeeves         New Issue                                    
======================================================================


From roman.wueger at gmx.at  Sun Oct 11 14:55:18 2015
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Sun, 11 Oct 2015 20:55:18 +0200
Subject: [cmake-developers] Xcode build settings and BullseyeCoverage
In-Reply-To: <561907DD.7010806@googlemail.com>
References: <1a3b01d102aa$541715f0$fc4541d0$@gmx.at>
 <561907DD.7010806@googlemail.com>
Message-ID: <08D3B01B-37D2-4751-8F42-D203EF77CAF9@gmx.at>

Thanks,

If anyone is interested, the guys from bullseye updated their website and the coverage is working now.

Best Regards

Von meinem iPhone gesendet

> Am 10.10.2015 um 14:43 schrieb Gregor Jasny <gjasny at googlemail.com>:
> 
> Hello,
> 
>> On 09/10/15 17:51, Roman W?ger wrote:
>> I?m trying to configure and build a project with the ?Xcode? generator and
>> the bullseye coverage tool.
>> 
>> Without the bullseye coverage tool it works fine but if I want to use it I
>> had to do the following workaround:
>> http://www.bullseye.com/help/tool-xcode.html
> 
> IMHO this workaround is way to hackish for a paid tool. The proper thing
> for Bullseye would be to provide a touchless way of intercepting all
> compiler invocations like for example Fortify or Coverity provides. You
> would be able to call it like this:
> 
>  $ bullseye xcodebuild
> 
> It would trace compiler invocations from xcodebuild and all childs.
> 
>> And I got the following error:
>> 
>> 
>> 
>> -- The C compiler identification is unknown
>> 
>> -- The CXX compiler identification is unknown
>> 
>> CMake Error at CMakeLists.txt:3 (project):
>> 
>>  No CMAKE_C_COMPILER could be found.
> 
>> Is there also a way to set generator specific things during configure time?
>> 
>> At the moment it is only possible with the build command: ?cmake -build . --
>> PLATFORM_DEVELOPER_BIN_DIR=PointToSomething? which sets the build settings
>> for Xcode
> 
> I have not tested it, but maybe you could add
>   -DCMAKE_C_COMPILER=$(xcrun -find clang) -DCMAKE_CXX_COMPILER=$(xcrun
> -find clang++)
> 
> to the cmake command line at configuration time.
> 
> Thanks,
> Gregor

From mantis at public.kitware.com  Sun Oct 11 20:30:01 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 11 Oct 2015 20:30:01 -0400
Subject: [cmake-developers] [CMake 0015782]: "--build" a generated test
	driver for Visual Studio 2015 fail because tests are not linked
Message-ID: <602f1832ab7fd139e0a6058696a2f0ba@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15782 
====================================================================== 
Reported By:                Dario Oliveri
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15782
Category:                   CMake
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-11 20:30 EDT
Last Modified:              2015-10-11 20:30 EDT
====================================================================== 
Summary:                    "--build" a generated test driver for Visual Studio
2015 fail because tests are not linked
Description: 
After some trial and error I believe the issue is a bug in Cmake where
generating a test driver results in a project file (tests.vcxproj) that cannot
be built directly with cmake (basically it don't links the tests object files to
the generated test driver, so I believe the bug is in the solution/project
generator).

The current workaround is using some other frameworks and manually adding test
files instead of generating a test driver from a GLOB.




Steps to Reproduce: 
the script I run from project folder are:

- mkdir build
- cd build
- cmake -G "Visual Studio 14 2015" ..

Building a regular target WORKS:

- cmake --build . --target libInfectorpp2 --config Release

Building ALL or test targets DO NOT WORK:
- cmake --build . --target ALL_BUILD --config Release


This is the "CONSOLE LOG" of the above scripts:
https://ci.appveyor.com/project/Darelbi/infectorpp2/build/1.0.38

this is the github project (where CMakeLists.txt is located):
https://github.com/Darelbi/Infectorpp2

No need to download the project, the console log already shows the log.

Additional Information: 
I need to get "TESTS.EXE" executable build from console using Cmake and the
"--build" build command because I'm using a Continuos Integration server and
hence I need to build the library and the tests executable at each commit, and I
also need to run tests  at each commit.

Actually there's no valid target for building the tests executable.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-11 20:30 Dario Oliveri  New Issue                                    
======================================================================


From mantis at public.kitware.com  Mon Oct 12 10:32:03 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 12 Oct 2015 16:32:03 +0200
Subject: [cmake-developers] [CMake 0015783]: ALIASED_TARGET property is
	always set
Message-ID: <90164c4a18525f2f390a4a150662240c@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15783 
====================================================================== 
Reported By:                Daniele E. Domenichelli
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15783
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-12 16:32 CEST
Last Modified:              2015-10-12 16:32 CEST
====================================================================== 
Summary:                    ALIASED_TARGET property is always set
Description: 
The ALIASED_TARGET property is always set even if no alias is associated to a
target. 

Steps to Reproduce: 
Using this CMakeLists.txt

---
cmake_minimum_required(VERSION 3.2)
project(test C)

file(WRITE ${CMAKE_BINARY_DIR}/test.c "int main(int argc, char *argv[]) { return
0; }\n")
add_executable(test_exe ${CMAKE_BINARY_DIR}/test.c)

get_property(_aliased_target_set TARGET test_exe PROPERTY ALIASED_TARGET SET)
if(_aliased_target_set)
  message(STATUS "ALIASED_TARGET is set for target test_exe")
  get_property(_aliased_target_value TARGET test_exe PROPERTY ALIASED_TARGET)
  message(STATUS "    ALIASED_TARGET = \"${_aliased_target_value}\"")
else()
  message(STATUS "ALIASED_TARGET is NOT set for target test_exe")
endif()

include (CMakePrintHelpers)
cmake_print_properties(TARGETS test_exe PROPERTIES ALIASED_TARGET)


add_executable(Test::test_exe ALIAS test_exe)

get_property(_aliased_target_set TARGET Test::test_exe PROPERTY ALIASED_TARGET
SET)
if(_aliased_target_set)
  message(STATUS "ALIASED_TARGET is set for target Test::test_exe")
  get_property(_aliased_target_value TARGET Test::test_exe PROPERTY
ALIASED_TARGET)
  message(STATUS "    ALIASED_TARGET = \"${_aliased_target_value}\"")
else()
  message(STATUS "ALIASED_TARGET is NOT set for target Test::test_exe")
endif()

include (CMakePrintHelpers)
cmake_print_properties(TARGETS Test::test_exe PROPERTIES ALIASED_TARGET CICCIO)
---




The actual output is

-- ALIASED_TARGET is set for target test_exe
--     ALIASED_TARGET = "_aliased_target_value-NOTFOUND"
--
 Properties for TARGET test_exe:
   test_exe.ALIASED_TARGET = "property-NOTFOUND"

-- ALIASED_TARGET is set for target Test::test_exe
--     ALIASED_TARGET = "test_exe"
--
 Properties for TARGET Test::test_exe:
   Test::test_exe.ALIASED_TARGET = "test_exe"



The expected output is

-- ALIASED_TARGET is NOT set for target test_exe
--
 Properties for TARGET test_exe:
   test_exe.ALIASED_TARGET = <NOTFOUND>

-- ALIASED_TARGET is set for target Test::test_exe
--     ALIASED_TARGET = "test_exe"
--
 Properties for TARGET Test::test_exe:
   Test::test_exe.ALIASED_TARGET = "test_exe"


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-12 16:32 Daniele E. DomenichelliNew Issue                               
    
======================================================================


From mantis at public.kitware.com  Mon Oct 12 10:32:41 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 12 Oct 2015 10:32:41 -0400
Subject: [cmake-developers] [CMake 0015784]: The WiX patch file parser
	ignores text nodes.
Message-ID: <2b4d9a4c56d2dd0dd03a7b627e44f9ec@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15784 
====================================================================== 
Reported By:                Ronny Kr?ger
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15784
Category:                   CPack
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-12 10:32 EDT
Last Modified:              2015-10-12 10:32 EDT
====================================================================== 
Summary:                    The WiX patch file parser ignores text nodes.
Description: 
The following xml fragment is supposed to run the "test" action after the
installer has finished but only if the product is not installed.

<nowiki><code xml>
  <CPackWiXPatch>
    <CPackWiXFragment Id="#PRODUCT">
      <CustomAction Id = "test" ... />
      <InstallExecuteSequence>
        <Custom Action="test" Before="InstallFinalize">NOT INSTALLED</Custom>
      </InstallExecuteSequence>
    </CPackWiXFragment>
  </CPackWiXPatch>
</nowiki>

Unfortunately this xml does not get completely through to WiX because the patch
parser ignores the text node below the "Custom" node which contains the
conditions on which the action is to be run.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-12 10:32 Ronny Kr?ger   New Issue                                    
======================================================================


From brad.king at kitware.com  Mon Oct 12 11:00:25 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 11:00:25 -0400
Subject: [cmake-developers] [Review Request] New module: IncludeUrl
In-Reply-To: <5616B5D1.4090302@drdanz.it>
References: <56152916.1060801@drdanz.it> <56169036.1040300@kitware.com>
 <5616B5D1.4090302@drdanz.it>
Message-ID: <561BCB09.7060709@kitware.com>

On 10/08/2015 02:28 PM, Daniele E. Domenichelli wrote:
> We've been successfully using this module for about 2 years now and we
> will continue to use it anyway, so I did not waste time...

I'm glad to hear that.

> I understand this is a quite controversial module, but I would like to
> stress that this is something that can already be done using CMake just
> by executing file(DOWNLOAD) and include(), this module just makes it
> easy to do it. Whether this is a security issue or not is up to how this
> module is used.

That makes sense, though I feel this may be a niche use case and would
prefer to hear more general interest.  If there is interest then for
upstream rather than a module perhaps this could be built in to the
include() command.

-Brad


From brad.king at kitware.com  Mon Oct 12 11:00:30 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 11:00:30 -0400
Subject: [cmake-developers] [FindPostgreSQL] Search for version 9.5
In-Reply-To: <4F305B1E-44BD-4A60-B111-B3BAB83EC89B@takar.nl>
References: <4F305B1E-44BD-4A60-B111-B3BAB83EC89B@takar.nl>
Message-ID: <561BCB0E.4090108@kitware.com>

On 10/10/2015 03:37 PM, Tamar Kranenburg wrote:
> This small patch adds version 9.5 to the search suffixes.

Thanks, applied:

 FindPostgreSQL: Search for version 9.5
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5225e004

I've also queued this for merge to 'release' for 3.4.0-rc2.

-Brad


From brad.king at kitware.com  Mon Oct 12 11:00:34 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 11:00:34 -0400
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <561A373A.4090907@googlemail.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com> <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
 <5613D40C.1060609@kitware.com> <561905CF.7070007@googlemail.com>
 <561A373A.4090907@googlemail.com>
Message-ID: <561BCB12.2060707@kitware.com>

On 10/11/2015 06:17 AM, Gregor Jasny wrote:
>> if (SDK is newer than host) && (is not set CMAKE_OSX_DEPLOYMENT_TARGET)
>>   set CMAKE_OSX_DEPLOYMENT_TARGET=<host version>
>> endif()

That logic looks right to me.

> Could you please give the following patch to Darwin-Initialize.cmake a try?
> 
> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=d61c6689c7380c810e060fed6bf3a0b9fbfd41d0

Francesco, does that resolve this for you?

> Brad: If we would set in line 33 the CMAKE_OSX_DEPLOYMENT_TARGET cache
> variable only if ENV{MACOSX_DEPLOYMENT_TARGET} actually exists we could
> get rid of the FORCE attribute later. Would that make sense?

The reason it is cached there is so that the initial selection is
cached persistently across runs.  One could refactor the logic to
use a normal variable at first and then cache the value later
once the final value is selected.

I think the FORCE approach is a good fixup to backport to 3.4.
The rest of the refactoring can be done in 'master' only, please.

Thanks,
-Brad


From francesco.romano.1987 at gmail.com  Mon Oct 12 11:15:10 2015
From: francesco.romano.1987 at gmail.com (Francesco Romano)
Date: Mon, 12 Oct 2015 17:15:10 +0200
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <561BCB12.2060707@kitware.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com> <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
 <5613D40C.1060609@kitware.com> <561905CF.7070007@googlemail.com>
 <561A373A.4090907@googlemail.com> <561BCB12.2060707@kitware.com>
Message-ID: <A58EB6F4-44EF-4E56-AB2B-8BC04ECDD0DA@gmail.com>

Hi
Sorry for the delay.

I tried it and it worked.
Thanks guys!

Francesco


> On 12 Oct 2015, at 17:00, Brad King <brad.king at kitware.com> wrote:
> 
> On 10/11/2015 06:17 AM, Gregor Jasny wrote:
>>> if (SDK is newer than host) && (is not set CMAKE_OSX_DEPLOYMENT_TARGET)
>>>  set CMAKE_OSX_DEPLOYMENT_TARGET=<host version>
>>> endif()
> 
> That logic looks right to me.
> 
>> Could you please give the following patch to Darwin-Initialize.cmake a try?
>> 
>> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=d61c6689c7380c810e060fed6bf3a0b9fbfd41d0
> 
> Francesco, does that resolve this for you?
> 
>> Brad: If we would set in line 33 the CMAKE_OSX_DEPLOYMENT_TARGET cache
>> variable only if ENV{MACOSX_DEPLOYMENT_TARGET} actually exists we could
>> get rid of the FORCE attribute later. Would that make sense?
> 
> The reason it is cached there is so that the initial selection is
> cached persistently across runs.  One could refactor the logic to
> use a normal variable at first and then cache the value later
> once the final value is selected.
> 
> I think the FORCE approach is a good fixup to backport to 3.4.
> The rest of the refactoring can be done in 'master' only, please.
> 
> Thanks,
> -Brad
> 


From brad.king at kitware.com  Mon Oct 12 13:09:21 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 13:09:21 -0400
Subject: [cmake-developers] ITK NIfTI broken Oct 6
In-Reply-To: <5617C9FD.9010702@ohio.edu>
References: <5617C9FD.9010702@ohio.edu>
Message-ID: <561BE941.6060500@kitware.com>

On 10/09/2015 10:06 AM, Kevin H. Hobbs wrote:
> The ITK dashboard builds on bubbles, murron, and k450e all started
> failing at the configure step on October 6.
> 
> CMake Error at
> Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "znz".

Kevin, thanks for reporting this promptly.

Steve, this bisects to:

 cmMakefile: Move invokation to initialize snapshot.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f716460e

Here is a small test case:

 $ cat CMakeLists.txt
 cmake_minimum_required(VERSION 3.3)
 project(Subdir NONE)
 subdirs(dir)
 set(variable value)

 $ cat dir/CMakeLists.txt
 message("variable='${variable}'")

Prior to this change the variable would have the right value in
the subdirectory.  Now it is not set.  Please take a look.

Thanks,
-Brad

From ryan.pavlik at gmail.com  Mon Oct 12 13:17:56 2015
From: ryan.pavlik at gmail.com (Ryan Pavlik)
Date: Mon, 12 Oct 2015 17:17:56 +0000
Subject: [cmake-developers] Moving from Module to Target-based linking
In-Reply-To: <56168A72.6050608@kitware.com>
References: <5614D1C9.4080506@simtech.uni-stuttgart.de>
 <CAAm+CDLxkTDoxt=C=_x-1_mZqyMdzZC2_EhcKJL5txxWjfD-SA@mail.gmail.com>
 <56168A72.6050608@kitware.com>
Message-ID: <CAAm+CDKPsEUzE2-Fw5cOX6ibHQuMHV2O0stB8ffGPMkaqP5_+w@mail.gmail.com>

Apparently the approach in FindGLUT does not work with the latest Mac build
tools, the file referenced is no longer a symlinks to the library but a
text metadata file, as I'm told by a Mac contributor to an open source
project I maintain. I was under the impression that it was a known issue,
perhaps it was not filed yet as a bug.  (cf.
https://github.com/OSVR/OSVR-Core/pull/232#issuecomment-147109322 )


Ryan

On Thu, Oct 8, 2015, 10:23 AM Brad King <brad.king at kitware.com> wrote:

> On 10/08/2015 08:58 AM, Ryan Pavlik wrote:
> > Happy to learn the correct way to make an imported target for a found
> > framework if someone cares to enlighten :)
>
> There is an example in FindGLUT.  Ideally find_library should be taught
> to find the "foo.framework/foo" file instead of the "foo.framework"
> directory but that will require a policy and some other changes to
> accomplish.
>
> > On Wed, Oct 7, 2015, 3:04 AM Daniel Wirtz wrote:
> >> is there any development going on towards providing FindXXX.cmake
> >> wrapper modules that "convert" MODULE-mode results into CONFIG style
> >> imported targets to consume?
>
> We'd like to head in that direction but there is no plan for a dedicated
> sweep through all modules by upstream devs.  We're depending on users
> to contribute conversions for the modules they need.
>
> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151012/14243a21/attachment.html>

From steveire at gmail.com  Mon Oct 12 13:48:04 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 12 Oct 2015 19:48:04 +0200
Subject: [cmake-developers] ITK NIfTI broken Oct 6
References: <5617C9FD.9010702@ohio.edu> <561BE941.6060500@kitware.com>
Message-ID: <mvgrok$cc5$1@ger.gmane.org>

Brad King wrote:

> Prior to this change the variable would have the right value in
> the subdirectory.  Now it is not set.  Please take a look.

This command has been documented as deprecated for a long time.

I notice this command is not covered by a policy.

 https://cmake.org/cmake/help/v3.3/manual/cmake-commands.7.html#deprecated-commands

Pushed:

 Subdirs: Initialize from parent before configuring.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2

Thanks,

Steve.


From hobbsk at ohio.edu  Mon Oct 12 13:33:15 2015
From: hobbsk at ohio.edu (Kevin H. Hobbs)
Date: Mon, 12 Oct 2015 13:33:15 -0400
Subject: [cmake-developers] ITK NIfTI broken Oct 6
In-Reply-To: <561BE941.6060500@kitware.com>
References: <5617C9FD.9010702@ohio.edu> <561BE941.6060500@kitware.com>
Message-ID: <561BEEDB.1020608@ohio.edu>

On 10/12/2015 01:09 PM, Brad King wrote:
> On 10/09/2015 10:06 AM, Kevin H. Hobbs wrote:
>> The ITK dashboard builds on bubbles, murron, and k450e all started
>> failing at the configure step on October 6.
>>
>> CMake Error at
>> Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install):
>>   install TARGETS given no LIBRARY DESTINATION for shared library target
>>   "znz".
> 
> Kevin, thanks for reporting this promptly.
> 

Brad,

You're welcome.

I'm sorry for my impatient cross posting to the ITK developer's list.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151012/7b7c25ca/attachment.sig>

From brad.king at kitware.com  Mon Oct 12 14:23:05 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 14:23:05 -0400
Subject: [cmake-developers] ITK NIfTI broken Oct 6
In-Reply-To: <mvgrok$cc5$1@ger.gmane.org>
References: <5617C9FD.9010702@ohio.edu> <561BE941.6060500@kitware.com>
 <mvgrok$cc5$1@ger.gmane.org>
Message-ID: <561BFA89.4010705@kitware.com>

On 10/12/2015 01:48 PM, Stephen Kelly wrote:
> This command has been documented as deprecated for a long time.
>
> I notice this command is not covered by a policy.

Back when 3.0 deprecated a swath of old commands with policies
we decided that subdirs() was too widely used to warn about
(along with so many of the other commands that got policies).
With that batch over we could reconsider.  OTOH we still
generate subdirs() commands in CTestTestfile.cmake files for
"ctest" to use, though CTest re-implements the command itself
IIRC.

>  Subdirs: Initialize from parent before configuring.
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2

Great, thanks.

Doesn't that mean that subdirs()-specified directories now
InitializeFromParent twice?

-Brad

From steveire at gmail.com  Mon Oct 12 14:28:49 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 12 Oct 2015 20:28:49 +0200
Subject: [cmake-developers] ITK NIfTI broken Oct 6
References: <5617C9FD.9010702@ohio.edu> <561BE941.6060500@kitware.com>
 <mvgrok$cc5$1@ger.gmane.org> <561BFA89.4010705@kitware.com>
Message-ID: <mvgu51$h43$1@ger.gmane.org>

Brad King wrote:

> On 10/12/2015 01:48 PM, Stephen Kelly wrote:
>> This command has been documented as deprecated for a long time.
>>
>> I notice this command is not covered by a policy.
> 
> Back when 3.0 deprecated a swath of old commands with policies
> we decided that subdirs() was too widely used to warn about
> (along with so many of the other commands that got policies).
> With that batch over we could reconsider.  OTOH we still
> generate subdirs() commands in CTestTestfile.cmake files for
> "ctest" to use, though CTest re-implements the command itself
> IIRC.

I've seen this, but haven't looked into it.

>>  Subdirs: Initialize from parent before configuring.
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2
> 
> Great, thanks.
> 
> Doesn't that mean that subdirs()-specified directories now
> InitializeFromParent twice?

Yes, but that doesn't matter because the second one will overwrite the 
effect of the first one. It's just part of the cost if you use deprecated 
commands.

Thanks,

Steve.



From brad.king at kitware.com  Mon Oct 12 15:40:12 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 15:40:12 -0400
Subject: [cmake-developers] re-install timestamp comparison (was: OS X:
 Filesystem timestamp checks use only 1s resolution)
In-Reply-To: <56184777.4070301@yahoo.com>
References: <6934fe0768634bce98b2955754827845@cmake.org>
 <561838E9.1060102@yahoo.com> <56184777.4070301@yahoo.com>
Message-ID: <561C0C9C.20309@kitware.com>

On 10/09/2015 07:02 PM, Ruslan Baratov wrote:
> On 10-Oct-15 01:00, Ruslan Baratov via cmake-developers wrote:
>> cmFileTimeComparisonInternal::TimesDiffer use only limited number of
>> digits of timestamp and used in install step.
>>
> And the main difference is that it affects Linux platform too

IIRC that is done for the case that one installs from one
filesystem to another and they each have different timestamp
resolution.  If we don't round the times then they may always
differ and inefficiently re-install everything every time.

Ideally we would detect the resolution available on each
filesystem and truncate only to the lower resolution of the
two.  Perhaps one could at least detect when the source and
destination are on the same filesystem and do no truncation.

Another approach would be to try writing the destination
file time to see if it changes.  If so then re-install
and set the time again.  This would happen only when really
on filesystems with different time resolutions because
otherwise the file times would match.  This way a failure
to re-install would occur only on a truly 1s filesystem.

-Brad


From brad.king at kitware.com  Mon Oct 12 15:50:56 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Oct 2015 15:50:56 -0400
Subject: [cmake-developers] Issue on CMAKE_OSX_SYSROOT
In-Reply-To: <A58EB6F4-44EF-4E56-AB2B-8BC04ECDD0DA@gmail.com>
References: <D31898FC-BB9F-49BB-BF3C-EE71B811A812@gmail.com>
 <561296E5.60300@kitware.com> <9B126D0A-B617-4AB3-B558-FEAB583EC4FC@gmail.com>
 <5613D40C.1060609@kitware.com> <561905CF.7070007@googlemail.com>
 <561A373A.4090907@googlemail.com> <561BCB12.2060707@kitware.com>
 <A58EB6F4-44EF-4E56-AB2B-8BC04ECDD0DA@gmail.com>
Message-ID: <561C0F20.2030103@kitware.com>

On 10/12/2015 11:15 AM, Francesco Romano wrote:
> I tried it and it worked.

Great, thanks for testing.

I rebased on 'release' and merged to 'next':

 Xcode: Adjust deployment target SDK version to host version
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24aafbde

I've queued this for merge to 'release' for inclusion in
3.4.0-rc2 since it is an environmental regression.

Thanks,
-Brad


From neundorf at kde.org  Mon Oct 12 17:00:52 2015
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 12 Oct 2015 23:00:52 +0200
Subject: [cmake-developers] Generating buildsystem metadata from CMake
In-Reply-To: <mp0kqa$m51$2@ger.gmane.org>
References: <CACHsx4+H4taM+Zt8EFp1LXuLrbR_PMvk_FUHGr6uymPwADWK7Q@mail.gmail.com>
 <CACcA1RpnTpu9dmbqMcY0JaC=LEg6mEGOJ-hgp57UNQJH2FCZVw@mail.gmail.com>
 <mp0kqa$m51$2@ger.gmane.org>
Message-ID: <18064283.mhOPgK010o@tuxedo.neundorf.net>

Hi,

On Saturday, July 25, 2015 20:33:46 Stephen Kelly wrote:
> Aleix Pol wrote:
> > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly
> > 
> > <steveire at gmail.com> wrote:
> >> Stephen Kelly wrote:
> >>> The aim is to generate a structured file containing metadata 
relating
> >>> the buildsystem.
> >> 
> >> I've been quiet on this thread for a while, so I think it is time for an
> >> update.
> >> 
> >> I became more ambitious in mid March and started prototyping a
> >> more-complete design for CMake IDE integration.
> > 
> > Hi Stephen,
> > Is there any news on the subject?
> 
> I have been working on cleaning up cmake
> 
>  $ git log --oneline --author=steveire --since="April 1" | wc -l
>  472
> 
> I've made lots of progress toward separating the configure and 
generation
> steps (required prerequisite for server features), but no working 
prototype
> ready to show yet I'm afraid.

Maybe this is of interest: the Eclipse CDT developers are currently 
working on improved support for cmake:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html

But if I understand them correctly, this is not about improving support for 
projects which use cmake without eclipse, but to use cmake as the tool 
to generate the makefiles in Eclipse projects. But maybe I got that 
wrong.

Alex

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

From Geoffrey.Viola at asirobots.com  Tue Oct 13 01:06:40 2015
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Tue, 13 Oct 2015 05:06:40 +0000
Subject: [cmake-developers] GHS MULTI generator link with
	RUNTIME_OUTPUT_DIRECTORY patch
Message-ID: <BLUPR0701MB198798EE0D60E0A41543436E89300@BLUPR0701MB1987.namprd07.prod.outlook.com>

Attached is a patch to allow the GHS MULTI generator to link a library when it's directory has changed via the RUNTIME_OUTPUT_DIRECTORY.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com


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-GHS-MULTI-generator-link-with-RUNTIME_OUTPUT_DIRECTO.PATCH
Type: application/octet-stream
Size: 2390 bytes
Desc: 0001-GHS-MULTI-generator-link-with-RUNTIME_OUTPUT_DIRECTO.PATCH
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151013/c153b5f0/attachment.obj>

From Geoffrey.Viola at asirobots.com  Tue Oct 13 01:17:52 2015
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Tue, 13 Oct 2015 05:17:52 +0000
Subject: [cmake-developers] BUILD_TESTING when cross compiling
Message-ID: <BLUPR0701MB19871CB33491386CED27619689300@BLUPR0701MB1987.namprd07.prod.outlook.com>

I've been looking into testing the GHS MULTI generator more and want to reuse tests, if possible. In https://github.com/Kitware/CMake/blob/master/Tests/CMakeLists.txt, I see a lot of general purpose tests blocked by the BUILD_TESTING variable. In particular, I'm interested in running the LinkDirectory and OutDir tests.  Should I expect all these tests to run when it won't be able to run the code on the host machine? What is the best way to make CTest run those tests with the GHS MULTI generator and not the default one?


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com



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.

From mantis at public.kitware.com  Tue Oct 13 02:59:00 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 13 Oct 2015 02:59:00 -0400
Subject: [cmake-developers] [CMake 0015785]: Support "generator expressions"
	in "install(CODE)"
Message-ID: <1b6a29c07f63c31b03dfd51875cd50f8@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15785 
====================================================================== 
Reported By:                SunBlack
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15785
Category:                   CMake
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-13 02:59 EDT
Last Modified:              2015-10-13 02:59 EDT
====================================================================== 
Summary:                    Support "generator expressions" in "install(CODE)"
Description: 
With CMake 3.4 "install(FILES)" and "install(DIRECTORY)" learned to support
"generator expressions" in command "DESTINATION". But it would be helpful if
"install(CODE)" support "generator expressions" too.

An usecase could be:
<code>
INSTALL(CODE "
   include(BundleUtilities)
   fixup_bundle($<TARGET_FILE_DIR:${PROJECT_NAME}> \"\" \"\")
   " COMPONENT Runtime
)
</code>
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-13 02:59 SunBlack       New Issue                                    
======================================================================


From mantis at public.kitware.com  Tue Oct 13 07:32:46 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 13 Oct 2015 07:32:46 -0400
Subject: [cmake-developers] [CMake 0015786]: FindMatlab / matlab_add_mex
	does not work with 64-bit Matlab Version - Version detected
	as 32-bit Matlab
Message-ID: <cb74ae4050cc6401aea786de377d4c87@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15786 
====================================================================== 
Reported By:                Kerstin Keller
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15786
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-13 07:32 EDT
Last Modified:              2015-10-13 07:32 EDT
====================================================================== 
Summary:                    FindMatlab / matlab_add_mex does not work with
64-bit Matlab Version - Version detected as 32-bit Matlab
Description: 
I have installed a 64bit Matlab Version (2015a) and CMake 3.3.2. 
When writing a simple CMakeLists.txt script

cmake_minimum_required(VERSION 3.3)
project(easy_example)
find_package(MATLAB REQUIRED)

include_directories(Matlab_INCLUDE_DIRS)

matlab_add_mex(
  NAME easy_example
  SRC easy_example.cpp
)

It cannot find the mex library. The Output is

-- Could NOT find Matlab (missing:  Matlab_MEX_LIBRARY) (found version "8.5")
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:
Matlab_MEX_LIBRARY
    linked by target "easy_example" in directory
D:/SourceCode/Matlab/easy_example
-- Configuring incomplete, errors occurred!


Steps to Reproduce: 
Try to run 

find_package(MATLAB REQUIRED)

and then use

matlab_add_mex(
...
)

with a 64-bit Matlab Version.

Additional Information: 
Digging a little into the FindMatlab.cmake script, and outputted the directories
where it searches for the directories (l.1342).

message(STATUS "The include dir ${MATLAB_INCLUDE_DIR_TO_LOOK}")
message(STATUS "The library dir ${_matlab_lib_dir_for_search}")

This gives me the following Output

-- The include dir C:/LegacyApp/Matlab15a/R2015a_64bit/extern/include
-- The library dir
C:/LegacyApp/Matlab15a/R2015a_64bit/extern/lib/win32/microsoft

However, as my Matlab Version is 64bit, it library dir should be 
C:/LegacyApp/Matlab15a/R2015a_64bit/extern/lib/win64/microsoft

This can be traced back to line 1276, where I added another message Output:
if(_matlab_64Build)
  set(_matlab_current_suffix ${_matlab_bin_suffix_64bits})
  message(STATUS "64bit Matlab")
else()
  set(_matlab_current_suffix ${_matlab_bin_suffix_32bits})
  message(STATUS "32bit Matlab")
endif()

CMake falsely detects a 32bit Matlab Version
-- 32bit Matlab

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-13 07:32 Kerstin Keller New Issue                                    
======================================================================


From mantis at public.kitware.com  Tue Oct 13 08:31:36 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 13 Oct 2015 08:31:36 -0400
Subject: [cmake-developers] [CMake 0015787]: Please add note about
	<INCLUDES> change to 3.4 release notes
Message-ID: <017a13250170bfda59d21a26d2ac716c@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15787 
====================================================================== 
Reported By:                James Crosby
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15787
Category:                   CMake
Reproducibility:            N/A
Severity:                   major
Priority:                   urgent
Status:                     new
====================================================================== 
Date Submitted:             2015-10-13 08:31 EDT
Last Modified:              2015-10-13 08:31 EDT
====================================================================== 
Summary:                    Please add note about <INCLUDES> change to 3.4
release notes
Description: 
CMake 3.4 includes this change:
https://github.com/Kitware/CMake/commit/c736de7b284ecc93bac48106e88417e0e6c92ad6
which splits out <INCLUDES> from <FLAGS> in the CMAKE_C_COMPILE_OBJECT command.

All toolchain descriptions which override this command need to be updated to
work correctly with CMake 3.4, but this is not clearly documented anywhere, it
seems like it should be a major item in the release notes!
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-13 08:31 James Crosby   New Issue                                    
======================================================================


From brad.king at kitware.com  Tue Oct 13 10:03:20 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Oct 2015 10:03:20 -0400
Subject: [cmake-developers] GHS MULTI generator link with
 RUNTIME_OUTPUT_DIRECTORY patch
In-Reply-To: <BLUPR0701MB198798EE0D60E0A41543436E89300@BLUPR0701MB1987.namprd07.prod.outlook.com>
References: <BLUPR0701MB198798EE0D60E0A41543436E89300@BLUPR0701MB1987.namprd07.prod.outlook.com>
Message-ID: <561D0F28.8000101@kitware.com>

On 10/13/2015 01:06 AM, Geoffrey Viola wrote:
> Attached is a patch to allow the GHS MULTI
[snip]
> +      const char* runtimeOutputDir =
> +        tg->GetProperty("RUNTIME_OUTPUT_DIRECTORY");

The generator should not have to deal with such properties directly.
There are internal APIs to get the output locations.  The have been
on cmTarget but are currently being moved to cmGeneratorTarget.  See
other generators for use of things like GetFullPath.

-Brad


From brad.king at kitware.com  Tue Oct 13 10:03:25 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Oct 2015 10:03:25 -0400
Subject: [cmake-developers] BUILD_TESTING when cross compiling
In-Reply-To: <BLUPR0701MB19871CB33491386CED27619689300@BLUPR0701MB1987.namprd07.prod.outlook.com>
References: <BLUPR0701MB19871CB33491386CED27619689300@BLUPR0701MB1987.namprd07.prod.outlook.com>
Message-ID: <561D0F2D.8020600@kitware.com>

On 10/13/2015 01:17 AM, Geoffrey Viola wrote:
> Tests/CMakeLists.txt
[snip]
> run when it won't be able to run the code on the host machine?

Many of the tests end with a step that verifies that a built
executable can run.  Several tests build tools that generate
sources.  In both cases we expect to be testing for the host.

> What is the best way to make CTest run those tests with the
> GHS MULTI generator and not the default one?

One can configure CMake with

  -G <any-generator>
  -D CMake_TEST_EXTERNAL_CMAKE=c:/path/to/cmake-build/bin/Debug

to tell it to run the test suite using the "cmake" tool in the
given directory.  That will test with the given generator instead
of trying to build CMake with it.

Some work would be needed to make this work for cross-compiling.
Essentially the tests of interest need to be ported to avoid
running anything on the host.

-Brad


From brad.king at kitware.com  Tue Oct 13 11:34:39 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Oct 2015 11:34:39 -0400
Subject: [cmake-developers] ITK NIfTI broken Oct 6
In-Reply-To: <mvgrok$cc5$1@ger.gmane.org>
References: <5617C9FD.9010702@ohio.edu> <561BE941.6060500@kitware.com>
 <mvgrok$cc5$1@ger.gmane.org>
Message-ID: <561D248F.2040605@kitware.com>

On 10/12/2015 01:48 PM, Stephen Kelly wrote:
>  Subdirs: Initialize from parent before configuring.
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2

It seems that problem was covering another one:

 CMake Error: File /.../Modules/ThirdParty/GDCM/src/gdcm/Source/gdcmByteValue.cxx does not exist.
 CMake Error at Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEncodingDefinition/CMakeLists.txt:27 (configure_file):
   configure_file Problem configuring file

The actual source file that exists is:

 Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEncodingDefinition/gdcmByteValue.cxx

The configure_file call is:

 configure_file(
    ${CMAKE_CURRENT_SOURCE_DIR}/${src}
    ${CMAKE_CURRENT_BINARY_DIR}/strict_${src}
    COPYONLY
    )

Therefore we see that CMAKE_CURRENT_SOURCE_DIR is incorrectly set.
This CMakeLists.txt file is again entered by the subdirs() command
in the parent directory.

Bisecting this required cherry-picking the above fix onto every
version tested.  However, the result points to:

 Set the current dirs on the snapshot before creating the cmMakefile.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=360e4e1d

as the culprit.

-Brad

From mantis at public.kitware.com  Tue Oct 13 11:47:09 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 13 Oct 2015 11:47:09 -0400
Subject: [cmake-developers] [CMake 0015788]: Error during export target,
	which has additional defined include directories with
	target_include_directories
Message-ID: <cda22c2213bfe1a0874b60ac232bbf6c@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15788 
====================================================================== 
Reported By:                SunBlack
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15788
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-13 11:47 EDT
Last Modified:              2015-10-13 11:47 EDT
====================================================================== 
Summary:                    Error during export target, which has additional
defined include directories with target_include_directories
Description: 
If you have a static library and want to add necessary include directories with
target_include_directories so users of this library just need to add library
with target_link_libraries (and don't need to add includes with
include_directories), I currently got

%%Configuring done
CMake Error in CMakeLists.txt:
  Target "myProject" INTERFACE_INCLUDE_DIRECTORIES property contains path:

    "D:/myProjectDir/myIncludeDir"

  which is prefixed in the source directory.


Generating done%%

Source code:
%%cmake_minimum_required(VERSION 3.3)

project(myProject)

add_library(${PROJECT_NAME}
	mySourceDir/test.cpp
	myIncludeDir/test.h
)

target_include_directories(${PROJECT_NAME} PUBLIC "myIncludeDir")

install(TARGETS ${PROJECT_NAME}
    EXPORT MyTargets
    ARCHIVE DESTINATION lib
)

install(EXPORT MyTargets DESTINATION cmake)%%

This message don't occurs, if I remove install.

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-13 11:47 SunBlack       New Issue                                    
======================================================================


From brad.king at kitware.com  Tue Oct 13 13:46:25 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Oct 2015 13:46:25 -0400
Subject: [cmake-developers] genex-generator-objects topic
Message-ID: <561D4371.8080306@kitware.com>

Steve,

Last night's RunCMake.include test failures bisect to:

 cmMakefile: Store container of cmExportBuildFileGenerators.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5925f99c

A clang sanitizer build output is below.  Please take a look.

Thanks,
-Brad


WRITE of size 8 at 0x6110000aee80 thread T0
    #0 0xcfeff3 in cmExportBuildFileGenerator::Compute(cmLocalGenerator*) /.../Source/cmExportBuildFileGenerator.cxx:29:12
    #1 0xeb18a4 in cmGlobalGenerator::ComputeBuildFileGenerators() /.../Source/cmGlobalGenerator.cxx:1238:7
    #2 0xeb1c6d in cmGlobalGenerator::Compute() /.../Source/cmGlobalGenerator.cxx:1272:3
    #3 0xa2cac5 in cmake::Generate() /.../Source/cmake.cxx:1609:8
    #4 0xa28abd in cmake::Run(std::vector<std::string, std::allocator<std::string> > const&, bool) /.../Source/cmake.cxx:1596:9
    #5 0x7809bc in do_cmake(int, char const* const*) /.../Source/cmakemain.cxx:330:13
    #6 0x77e002 in main /.../Source/cmakemain.cxx:190:13
    #7 0x7f7185ab2ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
    #8 0x6b5e57 in _start (/home/kitware/My Builds/cmake-build-clang/bin/cmake+0x6b5e57)

0x6110000aee80 is located 192 bytes inside of 200-byte region [0x6110000aedc0,0x6110000aee88)
freed by thread T0 here:
    #0 0x77bab0 in operator delete(void*) /projects/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:94
    #1 0xd04441 in cmExportBuildFileGenerator::~cmExportBuildFileGenerator() /.../Source/cmExportBuildFileGenerator.h:29:7
    #2 0xe9a810 in cmGlobalGenerator::GenerateImportFile(std::string const&) /.../Source/cmGlobalGenerator.cxx:237:5
    #3 0xbbe513 in cmIncludeCommand::InitialPass(std::vector<std::string, std::allocator<std::string> > const&, cmExecutionStatus&) /.../Source/cmIncludeCommand.cxx:130:5
    #4 0xb5a963 in cmCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) /.../Source/cmCommand.h:68:12
    #5 0x84dadc in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /.../Source/cmMakefile.cxx:321:11
    #6 0x8517fb in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /.../Source/cmMakefile.cxx:627:5
    #7 0x861379 in cmMakefile::Configure() /.../Source/cmMakefile.cxx:1683:3
    #8 0x861eef in cmMakefile::ConfigureSubDirectory(cmMakefile*) /.../Source/cmMakefile.cxx:1746:3
    #9 0x862d97 in cmMakefile::AddSubDirectory(std::string const&, std::string const&, bool, bool) /.../Source/cmMakefile.cxx:1785:5
    #10 0xac8f74 in cmAddSubDirectoryCommand::InitialPass(std::vector<std::string, std::allocator<std::string> > const&, cmExecutionStatus&) /.../Source/cmAddSubDirectoryCommand.cxx:124:3
    #11 0xb5a963 in cmCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) /.../Source/cmCommand.h:68:12
    #12 0x84dadc in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /.../Source/cmMakefile.cxx:321:11
    #13 0x8517fb in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /.../Source/cmMakefile.cxx:627:5
    #14 0x850bff in cmMakefile::ReadDependentFile(char const*, bool) /.../Source/cmMakefile.cxx:537:3
    #15 0xbbe794 in cmIncludeCommand::InitialPass(std::vector<std::string, std::allocator<std::string> > const&, cmExecutionStatus&) /.../Source/cmIncludeCommand.cxx:146:5
    #16 0xb5a963 in cmCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) /.../Source/cmCommand.h:68:12
    #17 0x84dadc in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /.../Source/cmMakefile.cxx:321:11
    #18 0x8517fb in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /.../Source/cmMakefile.cxx:627:5
    #19 0x861379 in cmMakefile::Configure() /.../Source/cmMakefile.cxx:1683:3
    #20 0xea61e2 in cmGlobalGenerator::Configure() /.../Source/cmGlobalGenerator.cxx:1126:3
    #21 0xa26b6b in cmake::ActualConfigure() /.../Source/cmake.cxx:1418:3
    #22 0xa2484c in cmake::Configure() /.../Source/cmake.cxx:1201:13
    #23 0xa28a82 in cmake::Run(std::vector<std::string, std::allocator<std::string> > const&, bool) /.../Source/cmake.cxx:1575:13
    #24 0x7809bc in do_cmake(int, char const* const*) /.../Source/cmakemain.cxx:330:13
    #25 0x77e002 in main /.../Source/cmakemain.cxx:190:13
    #26 0x7f7185ab2ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287

previously allocated by thread T0 here:
    #0 0x77b470 in operator new(unsigned long) /projects/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:62
    #1 0xc5300c in cmExportCommand::InitialPass(std::vector<std::string, std::allocator<std::string> > const&, cmExecutionStatus&) /.../Source/cmExportCommand.cxx:212:38
    #2 0xb5a963 in cmCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) /.../Source/cmCommand.h:68:12
    #3 0x84dadc in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /.../Source/cmMakefile.cxx:321:11
    #4 0x8517fb in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /.../Source/cmMakefile.cxx:627:5
    #5 0x861379 in cmMakefile::Configure() /.../Source/cmMakefile.cxx:1683:3
    #6 0x861eef in cmMakefile::ConfigureSubDirectory(cmMakefile*) /.../Source/cmMakefile.cxx:1746:3
    #7 0x862d97 in cmMakefile::AddSubDirectory(std::string const&, std::string const&, bool, bool) /.../Source/cmMakefile.cxx:1785:5
    #8 0xac8f74 in cmAddSubDirectoryCommand::InitialPass(std::vector<std::string, std::allocator<std::string> > const&, cmExecutionStatus&) /.../Source/cmAddSubDirectoryCommand.cxx:124:3
    #9 0xb5a963 in cmCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) /.../Source/cmCommand.h:68:12
    #10 0x84dadc in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /.../Source/cmMakefile.cxx:321:11
    #11 0x8517fb in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /.../Source/cmMakefile.cxx:627:5
    #12 0x850bff in cmMakefile::ReadDependentFile(char const*, bool) /.../Source/cmMakefile.cxx:537:3
    #13 0xbbe794 in cmIncludeCommand::InitialPass(std::vector<std::string, std::allocator<std::string> > const&, cmExecutionStatus&) /.../Source/cmIncludeCommand.cxx:146:5
    #14 0xb5a963 in cmCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) /.../Source/cmCommand.h:68:12
    #15 0x84dadc in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /.../Source/cmMakefile.cxx:321:11
    #16 0x8517fb in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /.../Source/cmMakefile.cxx:627:5
    #17 0x861379 in cmMakefile::Configure() /.../Source/cmMakefile.cxx:1683:3
    #18 0xea61e2 in cmGlobalGenerator::Configure() /.../Source/cmGlobalGenerator.cxx:1126:3
    #19 0xa26b6b in cmake::ActualConfigure() /.../Source/cmake.cxx:1418:3
    #20 0xa2484c in cmake::Configure() /.../Source/cmake.cxx:1201:13
    #21 0xa28a82 in cmake::Run(std::vector<std::string, std::allocator<std::string> > const&, bool) /.../Source/cmake.cxx:1575:13
    #22 0x7809bc in do_cmake(int, char const* const*) /.../Source/cmakemain.cxx:330:13
    #23 0x77e002 in main /.../Source/cmakemain.cxx:190:13
    #24 0x7f7185ab2ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287

From steveire at gmail.com  Tue Oct 13 15:01:16 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 13 Oct 2015 21:01:16 +0200
Subject: [cmake-developers] genex-generator-objects topic
References: <561D4371.8080306@kitware.com>
Message-ID: <mvjkds$q17$1@ger.gmane.org>

Brad King wrote:

> Steve,
> 
> Last night's RunCMake.include test failures bisect to:
> 
>  cmMakefile: Store container of cmExportBuildFileGenerators.
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5925f99c
> 
> A clang sanitizer build output is below.  Please take a look.

Looks like unique_ptrs would really help.

I've fixed it up I think.

Thanks,

Steve.



From steveire at gmail.com  Tue Oct 13 15:20:44 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 13 Oct 2015 21:20:44 +0200
Subject: [cmake-developers] Generating buildsystem metadata from CMake
References: <CACHsx4+H4taM+Zt8EFp1LXuLrbR_PMvk_FUHGr6uymPwADWK7Q@mail.gmail.com>
 <CACcA1RpnTpu9dmbqMcY0JaC=LEg6mEGOJ-hgp57UNQJH2FCZVw@mail.gmail.com>
 <mp0kqa$m51$2@ger.gmane.org> <18064283.mhOPgK010o@tuxedo.neundorf.net>
Message-ID: <mvjlic$4lm$1@ger.gmane.org>

Alexander Neundorf wrote:

> Maybe this is of interest: the Eclipse CDT developers are currently
> working on improved support for cmake:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
> http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html

Yes, I noticed that too a few days ago.

My work should make reading the CMakeLists.txt file not necessary, as they 
seem to intend to do.

I'll ping them when I have something to show.

Thanks,

Steve.



From steveire at gmail.com  Tue Oct 13 18:40:56 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 14 Oct 2015 00:40:56 +0200
Subject: [cmake-developers] ITK NIfTI broken Oct 6
References: <5617C9FD.9010702@ohio.edu> <561BE941.6060500@kitware.com>
 <mvgrok$cc5$1@ger.gmane.org> <561D248F.2040605@kitware.com>
Message-ID: <mvk19o$utm$1@ger.gmane.org>

Brad King wrote:

> Therefore we see that CMAKE_CURRENT_SOURCE_DIR is incorrectly set.
> This CMakeLists.txt file is again entered by the subdirs() command
> in the parent directory.

What a mess...

Thanks for bisecting. I fixed this by pushing part of a branch which I was 
intending to start to merge soon anyway.

Thanks,

Steve.



From mantis at public.kitware.com  Wed Oct 14 11:07:24 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Oct 2015 11:07:24 -0400
Subject: [cmake-developers] [CMake 0015789]: Enable ANSI colors when
	CLICOLOR_FORCE is set to 1
Message-ID: <8ddb1afd84ef2cb8eaf12f0bca03c152@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15789 
====================================================================== 
Reported By:                Jan Niklas Hasse
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15789
Category:                   (No Category)
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-14 11:07 EDT
Last Modified:              2015-10-14 11:07 EDT
====================================================================== 
Summary:                    Enable ANSI colors when CLICOLOR_FORCE is set to 1
Description: 
Hi!

I have set up a build server which uses CMake and Makefiles on Windows using
nmake. The build server pipes the output of both, so there's no colored output.
But when I set the environment variable TERM to "xterm" nmake prints the
messages like "Building xy" colored.

On my Linux build server this doesn't work however. I guess because the CMake
generated Makefile checks if isatty returns true (which would mean the output
isn't piped).

As there are situation where one wants to have colored output even if piped, it
would be great, if CMake supported some kind of environment variable to force it
on all platforms. As I was tired of all the different names, I've set up a page,
which summarizes a possible standard name: http://bixense.com/clicolors/

What do you think about CMake to outputting ANSI colored text when
CLICOLOR_FORCE is set to 1? Thanks :)
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-14 11:07 Jan Niklas HasseNew Issue                                    
======================================================================


From mantis at public.kitware.com  Wed Oct 14 12:48:31 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Oct 2015 12:48:31 -0400
Subject: [cmake-developers] [CMake 0015790]: Updating GIT_SUBMODULES of
	already cloned repo will not init them
Message-ID: <ee29628d401e8b31a200aeb15168fd8f@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15790 
====================================================================== 
Reported By:                Ilya
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15790
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-14 12:48 EDT
Last Modified:              2015-10-14 12:48 EDT
====================================================================== 
Summary:                    Updating GIT_SUBMODULES of already cloned repo will
not init them
Description: 
If project added via ExternalProject_Add that specifies GIT_URL and
GIT_SUBMODULES was already cloned, adding new module to GIT_SUBMODULES will not
cause cmake to fetch it. Instead it will fail with the following error:

Submodule path 'Resources' not initialized
Maybe you want to use 'update --init'?

Steps to Reproduce: 
1. Add ExternalProject_Add that specifies both GIT_URL and GIT_SUBMODULES
2. Generate and build
3. Append another submodule to GIT_SUBMODULES
4. Build again
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-14 12:48 Ilya           New Issue                                    
======================================================================


From mantis at public.kitware.com  Wed Oct 14 17:26:43 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 14 Oct 2015 17:26:43 -0400
Subject: [cmake-developers] [CMake 0015791]: Error configuring 3D Slicer
	with CMake 3.4.0-rc1
Message-ID: <3e45f9df061178277877f19287927106@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15791 
====================================================================== 
Reported By:                Mikael Brudfors
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15791
Category:                   CCMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-14 17:26 EDT
Last Modified:              2015-10-14 17:26 EDT
====================================================================== 
Summary:                    Error configuring 3D Slicer with CMake 3.4.0-rc1
Description: 
When configuring 3D Slicer in CMake 3.4.0-rc1 I get the below error, which is
not present when using earlier versions of CMake.

CMake Error at C:/Program Files
(x86)/CMake/share/cmake-3.4/Modules/ExternalProject.cmake:1742 (message):
  error: git version 1.6.5 or later required for 'git submodule update
  --recursive': git_version=''
Call Stack (most recent call first):
  C:/Program Files
(x86)/CMake/share/cmake-3.4/Modules/ExternalProject.cmake:2429
(_ep_add_download_command)
  CMake/ExternalProjectAddSource.cmake:77 (ExternalProject_Add)
  CMake/ExternalProjectAddSource.cmake:205 (ExternalProject_Add_Source)
  SuperBuild.cmake:174 (Slicer_Remote_Add)
  CMakeLists.txt:670 (include)

Steps to Reproduce: 
Set source to 3D Slicer source code, press configure.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-14 17:26 Mikael BrudforsNew Issue                                    
======================================================================


From Geoffrey.Viola at asirobots.com  Wed Oct 14 22:18:49 2015
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Thu, 15 Oct 2015 02:18:49 +0000
Subject: [cmake-developers] Removed unnecessary flags in GHS MULTI Generation
Message-ID: <BLUPR0701MB1987CD04D3E5F6A0D6465F01893E0@BLUPR0701MB1987.namprd07.prod.outlook.com>

Attached is a diff to stop producing "{optgroup=GhsCommonOptions}" in the generated .gpj files coming from CMake with the "Green Hills MULTI" generator. It is a patch to fix a bug reported at https://public.kitware.com/Bug/view.php?id=15771.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com



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-Removed-extra-flag-to-GHS-MULTI-compiler.patch
Type: application/octet-stream
Size: 1868 bytes
Desc: 0001-Removed-extra-flag-to-GHS-MULTI-compiler.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151015/6ecc1bb3/attachment.obj>

From mantis at public.kitware.com  Thu Oct 15 04:49:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 15 Oct 2015 04:49:07 -0400
Subject: [cmake-developers] [CMake 0015792]: Bad escaping of parentheses in
	POST_BUILD events if Ninja generator used
Message-ID: <cb292009f71b15300592e356016a7f57@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15792 
====================================================================== 
Reported By:                Pavel Solodovnikov
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15792
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-15 04:49 EDT
Last Modified:              2015-10-15 04:49 EDT
====================================================================== 
Summary:                    Bad escaping of parentheses in POST_BUILD events if
Ninja generator used
Description: 
CMake generates wrong post-build events if it contains parentheses: they are not
escaped at all (e.g., copy some build artefacts to a directory that contains
parens).

I've attached a small example to reproduce the issue.

================= BEGIN EXAMPLE
    cmake_minimum_required(VERSION 2.8.11)

    project(example)
    add_library(ex abc.cpp)
    add_custom_command(TARGET ex POST_BUILD VERBATIM COMMAND cp -f "libex.a"
"mydir (abc)")
================= END EXAMPLE

After running cmake, we can easily observe that parentheses are not escaped
properly in post build event:

57 build libex.a: CXX_STATIC_LIBRARY_LINKER__ex CMakeFiles/ex.dir/abc.cpp.o
   OBJECT_DIR = CMakeFiles/ex.dir
   POST_BUILD = cd /mnt/sources/work/cmake_parens_test && cp -f libex.a mydir\
(abc)
   PRE_LINK = :
   TARGET_COMPILE_PDB = CMakeFiles/ex.dir/
   TARGET_FILE = libex.a
   TARGET_PDB = libex.pdb

It leads to build errors since it's not valid shell syntax:

FAILED: : && /home/prog/Downloads/cmake-3.4.0-rc1-Linux-i386/bin/cmake -E remove
libex.a && /bin/ar qc libex.a  CMakeFiles/ex.dir/abc.cpp.o && /bin/ranlib
libex.a && cd /mnt/sources/work/cmake_parens_test && cp -f libex.a mydir\ (abc)
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `: &&
/home/prog/Downloads/cmake-3.4.0-rc1-Linux-i386/bin/cmake -E remove libex.a &&
/bin/ar qc libex.a  CMakeFiles/ex.dir/abc.cpp.o && /bin/ranlib libex.a && cd
/mnt/sources/work/cmake_parens_test && cp -f libex.a mydir\ (abc)'
ninja: build stopped: subcommand failed.

It is possible to workaround this by using VERBATIM option in POST_BUILD event,
though.

Tested with the latest CMake v.3.4.0 rc1 (I just couldn't select it in "Product
Version" dropdown list, so I left CMake 3.3.2 there).

Steps to Reproduce: 
1) Extract attached example.tar
2) Run "cmake -G "Ninja" ." inside extracted dir.
3) Examine produced build.ninja file.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-15 04:49 Pavel SolodovnikovNew Issue                                    
2015-10-15 04:49 Pavel SolodovnikovFile Added: cmake_parens_test.tar            
       
======================================================================


From brad.king at kitware.com  Thu Oct 15 10:08:33 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 15 Oct 2015 10:08:33 -0400
Subject: [cmake-developers] Removed unnecessary flags in GHS MULTI
	Generation
In-Reply-To: <BLUPR0701MB1987CD04D3E5F6A0D6465F01893E0@BLUPR0701MB1987.namprd07.prod.outlook.com>
References: <BLUPR0701MB1987CD04D3E5F6A0D6465F01893E0@BLUPR0701MB1987.namprd07.prod.outlook.com>
Message-ID: <561FB361.2010608@kitware.com>

On 10/14/2015 10:18 PM, Geoffrey Viola wrote:
> Attached is a diff to stop producing "{optgroup=GhsCommonOptions}"

Thanks, applied:

 GHS: Remove extra flag to GHS MULTI compiler (#15771)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ce7ccafc

-Brad


From mantis at public.kitware.com  Thu Oct 15 12:09:06 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 15 Oct 2015 12:09:06 -0400
Subject: [cmake-developers] [CMake 0015793]: nmake "U1095" too long command
	line error
Message-ID: <7b832647adf9c7374840ba19be491185@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15793 
====================================================================== 
Reported By:                M.B.
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15793
Category:                   CMake
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-15 12:09 EDT
Last Modified:              2015-10-15 12:09 EDT
====================================================================== 
Summary:                    nmake "U1095" too long command line error
Description: 
Building a library for android on windows with nmake I encountered the error
"NMAKE: fatal error U1095 expanded command line '...really_long_line...' too
long"

The problem was fixed by setting cmake to use response files e.g.
SET(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS).
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-15 12:09 M.B.           New Issue                                    
======================================================================


From mantis at public.kitware.com  Thu Oct 15 13:12:05 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 15 Oct 2015 13:12:05 -0400
Subject: [cmake-developers] [CMake 0015794]: The Xcode generator consumes
	all arguments beginning with "-O" even when they're not
	optimization flags.
Message-ID: <a2fc081fd97c73e7965fcad4c437b91b@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15794 
====================================================================== 
Reported By:                Davy Durham
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15794
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-15 13:12 EDT
Last Modified:              2015-10-15 13:12 EDT
====================================================================== 
Summary:                    The Xcode generator consumes all arguments beginning
with "-O" even when they're not optimization flags.
Description: 
cmake, when generating Xcode projects, attempts to translate optimization (i.e.
arguments starting with -O?) flags into the proper Xcode project file setting.
 In doing so, it removes all arguments beginning with "-O" from the
CMAKE_CXX_FLAGS and CMAKE_C_FLAGS variables and they do not get passed to the
OTHER_CPLUSPLUSFLAGS and OTHER_CFLAGS values in the Xcode project.  However
flags such as "-ObjC" and "-ObjC++" get incorrectly stripped out of the
generated project.

I have attached a patch file that addresses the issue by ignoring arguments that
begin with -O which are longer than 3 characters. (two files, one for cmake-3.1
and the other for git master)

Steps to Reproduce: 
For a CMakeLists.txt file containing:

  cmake_minimum_required(VERSION 3.0.2)
  project(foo)
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ObjC++")
  add_executable(foo foo.cpp)

running: cmake -G Xcode <path>  results in a generated
foo.xcodeproj/project.pbxproj file
This file's OTHER_CPLUSPLUSFLAGS= value ought to contain -ObjC++, but it does
not.


Additional Information: 
One can work around the issue by adding adding quotes around the argument which
Xcode strips off but cmake doesn't check for (it technically should.. another
bug?)

Example:
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} \"-ObjC++\"")

This is a fragile work around and may not work as it currently does in future
versions of cmake and Xcode
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-15 13:12 Davy Durham    New Issue                                    
======================================================================


From ddurham at bomgar.com  Thu Oct 15 13:16:50 2015
From: ddurham at bomgar.com (Davy Durham)
Date: Thu, 15 Oct 2015 12:16:50 -0500
Subject: [cmake-developers] cmake Xcode bug clobbering -ObjC/-ObjC++ flags
Message-ID: <561FDF82.5050703@bomgar.com>

Bug filed here: https://cmake.org/Bug/view.php?id=15794
Patch file against git master HEAD attached to this email.

Acceptable?

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fixed-an-issue-where-the-Xcode-generated-was-clobber.patch
Type: text/x-patch
Size: 3529 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151015/c76b46dc/attachment.bin>

From ruslan_baratov at yahoo.com  Thu Oct 15 15:58:29 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Thu, 15 Oct 2015 22:58:29 +0300
Subject: [cmake-developers] Filesystem timestamp checks
Message-ID: <56200565.3070909@yahoo.com>

Originally from: https://cmake.org/Bug/view.php?id=15769

Here is the scenario of not triggering rebuild of project while 
CMakeLists.txt changed:
1. Create CMakeLists.txt (modification time 100 units)
2. Run generate (create project from scratch): `cmake -H. -B_builds`. 
Takes 5 units, Makefile created with modification time 105
3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt 
modification time 105
4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is 
not "newer" then Makefile (105) there will be no regenerate command run 
and Makefile remains the same

Error can be easily reproduced on Apple HFS file system with unit = 1s 
(I hit this problem doing changes even manually) but in general that's 
the "feature" of native make tool + file system date resolution. Here is 
the similar test for Linux with ext4:
Test: https://github.com/forexample/date-resolution-test
Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483

There are a lot of scenarios where such problems can occurs, e.g. 
installing files (reproducible on OSX and Linux):
* https://cmake.org/pipermail/cmake-developers/2015-October/026692.html

One more with sources:
* Create foo.cpp (100) which build executable foo
* Run generate and build foo (105)
* Modify foo.cpp "immediately" -> foo.cpp (105)
* Run build (may be repeated N times): cmake --build _builds, no changes (!)
* Run regenerate (may be repeated N times): cmake -H. -B_builds, no 
changes (!)

My excerpts from bug:

     > I wouldn't expect every tool that can create a file to have an
    option to sleep after creating it.
    There is no need to sleep after each file creation it should be
    enough to sleep after generate/build step. I.e. in `cmake -H.
    -B_builds` and `cmake --build _builds` commands, but not in `cmake -E`.

    So experiencing such problems on other file systems just a matter of
    test and hardware capabilities which lead to
    unpredictable/unrepeatable bugs and makes it VERY hard to debug
    (e.g. to fix first test /*not the first, see example with sources*/
    it's not even enough to just re-run `cmake -H. -B_builds` - you
    should remove your build directory or touch files one more time
    after some pause). Again I understand that it's not a problem in
    CMake but if there is any chance to apply some "guarding"
    functionality it should be used. I'll take a look more deeply next
    week and will report my thoughts.

Any other ideas?

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151015/cae72671/attachment.html>

From ben.boeckel at kitware.com  Thu Oct 15 23:36:01 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 15 Oct 2015 23:36:01 -0400
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <56200565.3070909@yahoo.com>
References: <56200565.3070909@yahoo.com>
Message-ID: <20151016033601.GA16810@bronto-burt.dev.benboeckel.net>

On Thu, Oct 15, 2015 at 22:58:29 +0300, Ruslan Baratov via cmake-developers wrote:
> Test: https://github.com/forexample/date-resolution-test
> Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483
<snip>
> Any other ideas?

I patched make locally to output the mtimes used when it fails this[1].
The times are the same down to the nanosecond. I had originally thought
that may be make isn't using nanosecond precision, but it does.

I think the kernel and/or filesystem may be taking shortcuts here. There
is no way (I can think of) that a file can have the exact same filestamp
when there's a fork/exec in between modifications; those operations just
take too long.

--Ben

[1]Make's internal debugging is too slow and never triggers the bug;
same with using gdb with a script.

From mantis at public.kitware.com  Fri Oct 16 10:41:34 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 16 Oct 2015 10:41:34 -0400
Subject: [cmake-developers] [CMake 0015795]: pkg_check_modules produces
	incorrect results depending on contents of CMakeCache.txt
Message-ID: <59e50f9a335f73c8ae1b5a973ecc6ea0@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15795 
====================================================================== 
Reported By:                Sam Thursfield
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15795
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-16 10:41 EDT
Last Modified:              2015-10-16 10:41 EDT
====================================================================== 
Summary:                    pkg_check_modules produces incorrect results
depending on contents of CMakeCache.txt
Description: 
I got bitten by a bug involving pkg_check_modules.

If I run cmake, then edit my CMakeLists.txt to change the parameters passed to
pkg_check_modules, and rerun cmake, it ignores the change that I made to
CMakeLists.txt. I needed to delete the CMakeCache.txt file to get the right
results.

This seems like a cache invalidation bug to me -- a change in the parameters
passed to to pkg_check_modules() should cause the cached values to be
invalidated.

I've attached a small script that reproduces the issue.

Steps to Reproduce: 
Use attached script. It uses the 'avahi' library as an example, so needs the
avahi-devel or libavahi-dev package (or whatever else your distro calls it) to
be installed. Any two pkg-config modules will trigger the same error.

Output on my machine:

Creating initial CMakeLists.txt
Avahi libs should be: avahi-gobject
AVAHI LIBS: avahi-gobject;avahi-common;avahi-client;avahi-glib;glib-2.0

Updating pkg_check_modules call
Avahi libs should be:
avahi-gobject;avahi-common;avahi-client;avahi-glib;glib-2.0
AVAHI LIBS: avahi-gobject;avahi-common;avahi-client;avahi-glib;glib-2.0

Removing cache and trying again
Avahi libs should be:
avahi-gobject;avahi-common;avahi-client;avahi-glib;glib-2.0
AVAHI LIBS: avahi-gobject;avahi-common;avahi-client;avahi-glib;glib-2.0

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-16 10:41 Sam Thursfield New Issue                                    
2015-10-16 10:41 Sam Thursfield File Added: testcase.sh                      
======================================================================


From mantis at public.kitware.com  Fri Oct 16 16:40:08 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 16 Oct 2015 16:40:08 -0400
Subject: [cmake-developers] [CMake 0015796]: ExternalProject_Add should
	support resuming of downloads
Message-ID: <00e5a87a7d388d450e06f5044c5a67ae@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15796 
====================================================================== 
Reported By:                Ilya
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15796
Category:                   CMake
Reproducibility:            sometimes
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-16 16:40 EDT
Last Modified:              2015-10-16 16:40 EDT
====================================================================== 
Summary:                    ExternalProject_Add should support resuming of
downloads
Description: 
Sometimes download may hang up for a large file. CMake should automatically
attempt to resume download.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-16 16:40 Ilya           New Issue                                    
======================================================================


From mantis at public.kitware.com  Sat Oct 17 04:52:36 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 17 Oct 2015 04:52:36 -0400
Subject: [cmake-developers] [CMake 0015797]: PROPERTY CXX_STANDARD does not
	work with custom arm-none-eabi-g++
Message-ID: <3e20198d82a7b1f0e337022af777f7ce@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15797 
====================================================================== 
Reported By:                nano
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15797
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-17 04:52 EDT
Last Modified:              2015-10-17 04:52 EDT
====================================================================== 
Summary:                    PROPERTY CXX_STANDARD does not work with custom
arm-none-eabi-g++
Description: 
When the CMakeForceCompiler module is used to set a new compiler for cross
compilation the CXX_STANDARD property does not work. arm-none-eabi-g++ is
launched without -std=c++11. No errors or warnings are shown even though
CXX_STANDARD_REQUIRED is set.


Steps to Reproduce: 
cmake_minimum_required(VERSION 3.3)
include(CMakeForceCompiler)

set(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++ GNU)

project(bug)
add_executable(bug bug.cpp)
set_property(TARGET bug PROPERTY CXX_STANDARD 11)
set_property(TARGET bug PROPERTY CXX_STANDARD_REQUIRED ON)

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-17 04:52 nano           New Issue                                    
======================================================================


From michael.scott250 at gmail.com  Sun Oct 18 07:59:53 2015
From: michael.scott250 at gmail.com (Michael Scott)
Date: Sun, 18 Oct 2015 12:59:53 +0100
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <5605B36C.4080707@gmail.com>
References: <5605B36C.4080707@gmail.com>
Message-ID: <562389B9.5050906@gmail.com>

Hi Brad,

I was thinking of coming back to issue of the deprecation and author 
message options, now that CMake 3.4 has been released, is now a suitable 
time for it?

I was thinking of ideas and one came to mind, how does the following sound?

We modify cmake::IssueMessage to check the relevant CMake variables to 
determine if the message should be output and at which level, we try to 
get the script provided values if possible but handle the case where we 
can't. We also modify IssueMessage to use 
cmSystemTools::SetFatalErrorOccured (or SetErrorOccured if that's 
preferred) if a warning has been turned into an error. Finally we modify 
the users of IssueMessage, to check the error occured state using 
cmSystemTools, and use that to determine if an error has occured (rather 
than the message level going into IssueMessage) and if the return value 
should be changed accordingly.

Cheers,
Michael

From mantis at public.kitware.com  Sun Oct 18 15:35:14 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 18 Oct 2015 15:35:14 -0400
Subject: [cmake-developers] [CMake 0015798]: add_test page ought to specify
	what constitutes a valid test
Message-ID: <003eb33b5c0e11def926f4dd50d3204c@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15798 
====================================================================== 
Reported By:                Joachim Wuttke
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15798
Category:                   Documentation
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-18 15:35 EDT
Last Modified:              2015-10-18 15:35 EDT
====================================================================== 
Summary:                    add_test page ought to specify what constitutes a
valid test
Description: 
https://cmake.org/cmake/help/v3.4/command/add_test.html describes the command
?add_test? which has a parameter ?COMMAND? to ?specify the test
command-line?.

It would be appropriate to provide an explanation (or/and a link to an
explanation) of what constitutes a valid test command.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-18 15:35 Joachim Wuttke New Issue                                    
======================================================================


From gjasny at googlemail.com  Sun Oct 18 17:01:17 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Sun, 18 Oct 2015 23:01:17 +0200
Subject: [cmake-developers] cmake Xcode bug clobbering -ObjC/-ObjC++
	flags
In-Reply-To: <561FDF82.5050703@bomgar.com>
References: <561FDF82.5050703@bomgar.com>
Message-ID: <5624089D.7050109@googlemail.com>

On 15/10/15 19:16, Davy Durham wrote:
> Bug filed here: https://cmake.org/Bug/view.php?id=15794
> Patch file against git master HEAD attached to this email.
> 
> Acceptable?

I responded to the bug report itself:
https://cmake.org/Bug/view.php?id=15794#c39625

Two questions for the CMake developers:

1) I'd like to add an Unit Test for the ExtractFlagRegex function. Could
you please tell me where to add it?

2) Do you consider ExtractFlagRegex generic enough to be moved somewhere
else?

Thanks,
Gregor

From mantis at public.kitware.com  Mon Oct 19 07:31:25 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 19 Oct 2015 07:31:25 -0400
Subject: [cmake-developers] [CMake 0015799]: Way to pass git options for
	cloning in ExternalProject_Add
Message-ID: <cce4546f4747214c3dda2ccedd6d1148@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15799 
====================================================================== 
Reported By:                gonzalobg88 at gmail.com
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15799
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-19 07:31 EDT
Last Modified:              2015-10-19 07:31 EDT
====================================================================== 
Summary:                    Way to pass git options for cloning in
ExternalProject_Add
Description: 
AFAIK there is no way to pass git options while cloning repositories with
ExternalProject_Add.

Cloning git repositories can take a very long time. Git has options that make
cloning instantaneous if e.g. only one revision is required. For example:
--depth 1 clones only the latest revision very fast.

I would like to be able to pass options to git clone since that would
significantly improve my build times, which right now spend a very long time
cloning the whole history of multiple git repositories. 
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-19 07:31 gonzalobg88 at gmail.comNew Issue                                 
  
======================================================================


From brad.king at kitware.com  Mon Oct 19 09:30:21 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Oct 2015 09:30:21 -0400
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <56200565.3070909@yahoo.com>
References: <56200565.3070909@yahoo.com>
Message-ID: <5624F06D.3010902@kitware.com>

On 10/15/2015 03:58 PM, Ruslan Baratov wrote:
> 3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt modification time 105
> 4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is not "newer"
> then Makefile (105) there will be no regenerate command run and Makefile remains the same
> 
> Error can be easily reproduced on Apple HFS file system with unit = 1s (I hit this problem doing changes even manually) but in general that's the "feature" of native make tool + file system date resolution. Here is the similar test for Linux with ext4:
> Test: https://github.com/forexample/date-resolution-test
> Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483

This is a fundamental limitation of buildsystems that use file timestamps.
Your example shows that even plain "make" has this problem.  One simply
must use a workflow that does not involve changing files "immediately".
It's not that bad.  When manually entering commands it is very hard to
type that fast.  When scripting commmands the script can delay where
needed.

> There are a lot of scenarios where such problems can occurs, e.g. installing files (reproducible on OSX and Linux):
> * https://cmake.org/pipermail/cmake-developers/2015-October/026692.html

This is a separate issue because it is about CMake truncating timestamps
rather than the filesystem doing it.

-Brad


From brad.king at kitware.com  Mon Oct 19 09:39:15 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Oct 2015 09:39:15 -0400
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <562389B9.5050906@gmail.com>
References: <5605B36C.4080707@gmail.com> <562389B9.5050906@gmail.com>
Message-ID: <5624F283.9040900@kitware.com>

On 10/18/2015 07:59 AM, Michael Scott wrote:
> I was thinking of coming back to issue of the deprecation and author 
> message options, now that CMake 3.4 has been released, is now a suitable 
> time for it?

Yes.  Early in the development cycle is best.

> We modify cmake::IssueMessage to check the relevant CMake variables to 
> determine if the message should be output and at which level, we try to 
> get the script provided values if possible but handle the case where we 
> can't.

cmake::IssueMessage does not have access to variables because it has no
specific scope.  It can only pay attention to global (cached) settings.
I think having local CMAKE_WARN_DEPRECATED/CMAKE_ERROR_DEPRECATED vars
can be left as specific to the message() command (and perhaps other
IssueMessage callers as deemed appropriate per-case).  Otherwise we
should just have one global setting.

> We also modify IssueMessage to use 
> cmSystemTools::SetFatalErrorOccured (or SetErrorOccured if that's 
> preferred) if a warning has been turned into an error. Finally we modify 
> the users of IssueMessage, to check the error occured state using 
> cmSystemTools, and use that to determine if an error has occured (rather 
> than the message level going into IssueMessage) and if the return value 
> should be changed accordingly.

I realized we don't actually have to make warning=>error conversion
immediately stop processing.  We just need to make sure the process
exit code is changed.  We may not have to update all callers to
achieve this; it would only be an optimization.  OTOH perhaps we
should defer this part until after the main warning control
command-line options are worked out.

Thanks,
-Brad


From ddomenichelli at drdanz.it  Mon Oct 19 09:46:24 2015
From: ddomenichelli at drdanz.it (Daniele E. Domenichelli)
Date: Mon, 19 Oct 2015 15:46:24 +0200
Subject: [cmake-developers] [Review Request] New module: IncludeUrl
In-Reply-To: <561BCB09.7060709@kitware.com>
References: <56152916.1060801@drdanz.it> <56169036.1040300@kitware.com>
 <5616B5D1.4090302@drdanz.it> <561BCB09.7060709@kitware.com>
Message-ID: <5624F430.3030901@drdanz.it>

Hello Brad,

On 12/10/2015 17:00, Brad King wrote:
>> I understand this is a quite controversial module, but I would like to
>> stress that this is something that can already be done using CMake just
>> by executing file(DOWNLOAD) and include(), this module just makes it
>> easy to do it. Whether this is a security issue or not is up to how this
>> module is used.
>
> That makes sense, though I feel this may be a niche use case and would
> prefer to hear more general interest.  If there is interest then for
> upstream rather than a module perhaps this could be built in to the
> include() command.


Apparently there is no interest in this feature, therefore I'll withdraw
my patch.
Anyway, a hard coded solution would not work for me, since at the moment
I'm stuck supporting CMake 2.8.9 and will not be able to use features
from the next CMake version for a very long time.


Cheers,
 Daniele


From mantis at public.kitware.com  Mon Oct 19 09:54:54 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 19 Oct 2015 09:54:54 -0400
Subject: [cmake-developers] [CMake 0015801]: FindCUDA.cmake incorrectly
	includes cu file dependencies
Message-ID: <29975b978202ee9934eda7f090762741@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15801 
====================================================================== 
Reported By:                tomwar
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15801
Category:                   Modules
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-19 09:54 EDT
Last Modified:              2015-10-19 09:54 EDT
====================================================================== 
Summary:                    FindCUDA.cmake incorrectly includes cu file
dependencies
Description: 
FindCuda.cmake line 399 include(${dependency_file}). Includes file that is
changed everytime during build process. Everytime when NVCC compiles some cu
file it generates new depends file (*_generated_*.cu.obj.depend) for it that
contains cu file dependencies (eg h files or other #included files). As I
checked in other cmake projects dependencies files (generate.stamp.depend)
contain only reference to other cmake fiels that it depends. I couldn't find
reference to source code files in generate.stamp.depend which makes sense. As
FindCuda adds such source code file dependency that is changed on compilation
time, it coused that after every build ZERO_CHECK triggers reconfiguration of
whole project which if you have enabled parallel build might coused crash of
MSBuild application or crash of build process b/c one thread is configuring
whole project and another is still compiling or linking different one. If in
other generate.stamp.depend files that were generated by cmake I couldn't find
any #included .h file dependency i would suggest to remove whole this
functionality from FindCUDA.cmake.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-19 09:54 tomwar         New Issue                                    
======================================================================


From brad.king at kitware.com  Mon Oct 19 10:46:21 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Oct 2015 10:46:21 -0400
Subject: [cmake-developers] CMakeForceCompiler
In-Reply-To: <5601BC6B.7000205@kitware.com>
References: <55F9A678.1010800@kitware.com> <mtcc0b$mt3$1@ger.gmane.org>
 <55F9B4D4.5060400@kitware.com> <mtce89$uqf$1@ger.gmane.org>
 <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com>
 <mtsdnr$9ae$1@ger.gmane.org> <5601BC6B.7000205@kitware.com>
Message-ID: <5625023D.5050103@kitware.com>

On 09/22/2015 04:39 PM, Brad King wrote:
> I think it should be deprecated if possible.  First we must
> provide alternatives for all its use cases though.

I'm not familiar with any cases that cannot be supported in
other ways so I decided to deprecate the module now:

 CMakeForceCompiler: Deprecate this module and its macros
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6

This will at least call attention to the problems with this
module and hopefully bring to light any remaining use cases
that require it.

-Brad


From brad.king at kitware.com  Mon Oct 19 11:12:18 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Oct 2015 11:12:18 -0400
Subject: [cmake-developers] CMakeForceCompiler
In-Reply-To: <5625023D.5050103@kitware.com>
References: <55F9A678.1010800@kitware.com> <mtcc0b$mt3$1@ger.gmane.org>
 <55F9B4D4.5060400@kitware.com> <mtce89$uqf$1@ger.gmane.org>
 <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com>
 <mtsdnr$9ae$1@ger.gmane.org> <5601BC6B.7000205@kitware.com>
 <5625023D.5050103@kitware.com>
Message-ID: <56250852.7070501@kitware.com>

On 10/19/2015 10:46 AM, Brad King wrote:
>  CMakeForceCompiler: Deprecate this module and its macros
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6

After fixing a typo in the commit message:

 CMakeForceCompiler: Deprecate this module and its macros
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed77504d

-Brad


From steveire at gmail.com  Mon Oct 19 15:02:59 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 19 Oct 2015 21:02:59 +0200
Subject: [cmake-developers] CMakeForceCompiler
References: <55F9A678.1010800@kitware.com> <mtcc0b$mt3$1@ger.gmane.org>
 <55F9B4D4.5060400@kitware.com> <mtce89$uqf$1@ger.gmane.org>
 <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com>
 <mtsdnr$9ae$1@ger.gmane.org> <5601BC6B.7000205@kitware.com>
 <5625023D.5050103@kitware.com> <56250852.7070501@kitware.com>
Message-ID: <n03ep3$fle$1@ger.gmane.org>

Brad King wrote:

> On 10/19/2015 10:46 AM, Brad King wrote:
>>  CMakeForceCompiler: Deprecate this module and its macros
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6
> 
> After fixing a typo in the commit message:
> 
>  CMakeForceCompiler: Deprecate this module and its macros
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed77504d

You're using message(DEPRECATION) - no one will see the warning message you 
added. 

I think message(DEPRECATION) is broken by design and should not be used 
until it warns by default. I think we might have discussed that design 
choice at the time of adding it, but a brief search did not find it.

Thanks,

Steve.



From brad.king at kitware.com  Mon Oct 19 15:19:43 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Oct 2015 15:19:43 -0400
Subject: [cmake-developers] CMakeForceCompiler
In-Reply-To: <n03ep3$fle$1@ger.gmane.org>
References: <55F9A678.1010800@kitware.com> <mtcc0b$mt3$1@ger.gmane.org>
 <55F9B4D4.5060400@kitware.com> <mtce89$uqf$1@ger.gmane.org>
 <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com>
 <mtsdnr$9ae$1@ger.gmane.org> <5601BC6B.7000205@kitware.com>
 <5625023D.5050103@kitware.com> <56250852.7070501@kitware.com>
 <n03ep3$fle$1@ger.gmane.org>
Message-ID: <5625424F.8070004@kitware.com>

On 10/19/2015 03:02 PM, Stephen Kelly wrote:
> You're using message(DEPRECATION) - no one will see the warning message you 
> added. 

At least now we can point at the documentation when someone asks about it.

> I think message(DEPRECATION) is broken by design and should not be used 
> until it warns by default.

We should fix that interface instead of declaring that it should never
be used.  There is active discussion in another thread about activating
deprecation warnings:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13798/focus=14738

This could be raised over there.

-Brad


From brad.king at kitware.com  Mon Oct 19 15:56:42 2015
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Oct 2015 15:56:42 -0400
Subject: [cmake-developers] CMakeForceCompiler
In-Reply-To: <5625023D.5050103@kitware.com>
References: <55F9A678.1010800@kitware.com> <mtcc0b$mt3$1@ger.gmane.org>
 <55F9B4D4.5060400@kitware.com> <mtce89$uqf$1@ger.gmane.org>
 <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com>
 <mtsdnr$9ae$1@ger.gmane.org> <5601BC6B.7000205@kitware.com>
 <5625023D.5050103@kitware.com>
Message-ID: <56254AFA.8020606@kitware.com>

On 10/19/2015 10:46 AM, Brad King wrote:
> This will at least call attention to the problems with this
> module and hopefully bring to light any remaining use cases
> that require it.

For reference, an additional problem is discussed here:

 https://cmake.org/Bug/view.php?id=15797#c39641

The try_compile calls in CMakeTest<LANG>Compiler.cmake
fail when extra sources, flags, or a linker file are needed
for a specific architecture.

-Brad


From ruslan_baratov at yahoo.com  Mon Oct 19 18:56:47 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 20 Oct 2015 04:56:47 +0600
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <5624F06D.3010902@kitware.com>
References: <56200565.3070909@yahoo.com> <5624F06D.3010902@kitware.com>
Message-ID: <5625752F.3010608@yahoo.com>

On 19-Oct-15 19:30, Brad King wrote:
> On 10/15/2015 03:58 PM, Ruslan Baratov wrote:
>> 3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt modification time 105
>> 4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is not "newer"
>> then Makefile (105) there will be no regenerate command run and Makefile remains the same
>>
>> Error can be easily reproduced on Apple HFS file system with unit = 1s (I hit this problem doing changes even manually) but in general that's the "feature" of native make tool + file system date resolution. Here is the similar test for Linux with ext4:
>> Test: https://github.com/forexample/date-resolution-test
>> Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483
> This is a fundamental limitation of buildsystems that use file timestamps.
> Your example shows that even plain "make" has this problem.  One simply
> must use a workflow that does not involve changing files "immediately".
> It's not that bad.  When manually entering commands it is very hard to
> type that fast.  When scripting commmands the script can delay where
> needed.
I've already heard all this arguments and can only reply mine again :)
* I've hit this while doing manual changes for Xcode project on Apple's 
HFS with 1s resolution
* I don't want to patch every script. To be precise I prefer to "Fix 
something in one place so it works 100% and forget about it" then "Every 
time I start creating script I should remember that..."

>> There are a lot of scenarios where such problems can occurs, e.g. installing files (reproducible on OSX and Linux):
>> * https://cmake.org/pipermail/cmake-developers/2015-October/026692.html
> This is a separate issue because it is about CMake truncating timestamps
> rather than the filesystem doing it.
Well yes, I was not very accurate with this statement, but in general 
it's very similar (if CMake truncation precision == file system date 
resolution then we have same situation) and "sleeping-guard" will fix it 
too.

As I've mentioned I have a wrapper already so I've applied the "sleep" 
functionality there. It fix all issues of 1-3 test case, so this is 
closed for me now.

Thanks, Ruslo

From mantis at public.kitware.com  Tue Oct 20 03:30:12 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 20 Oct 2015 03:30:12 -0400
Subject: [cmake-developers] [CMake 0015802]: CMake crashes in creating build
	files for JsonCpp
Message-ID: <4e9f86d8ac4505335d3b1817be00cc17@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15802 
====================================================================== 
Reported By:                Lukas Pioch
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15802
Category:                   CMake
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-20 03:30 EDT
Last Modified:              2015-10-20 03:30 EDT
====================================================================== 
Summary:                    CMake crashes in creating build files for JsonCpp
Description: 
CMake 3.4 crashes in creating the build files for a project named JsonCpp on a
old commit. The current master of JsonCpp builds.
Tested the steps with the current git version of CMake and the problem still
exists.

On a older version like CMake 3.2 no crash occurs.

Steps to Reproduce: 
1) Clone JsonCpp:
git clone https://github.com/open-source-parsers/jsoncpp.git

2) Checkout older commit in a other branch:
git checkout -b cmake_test 81cf237

3) Run:
cmake .
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-20 03:30 Lukas Pioch    New Issue                                    
======================================================================


From mantis at public.kitware.com  Tue Oct 20 03:49:40 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 20 Oct 2015 03:49:40 -0400
Subject: [cmake-developers] [CMake 0015803]: FindCUDA.cmake should propagate
	value of COMPILE_PDB_OUTPUT_DIRECTORY{_CONFIG} to NVCC
Message-ID: <ef5ed787d412a630ed19183c74f21a6b@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15803 
====================================================================== 
Reported By:                tomwar
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15803
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-20 03:49 EDT
Last Modified:              2015-10-20 03:49 EDT
====================================================================== 
Summary:                    FindCUDA.cmake should propagate value of
COMPILE_PDB_OUTPUT_DIRECTORY{_CONFIG} to NVCC
Description: 
FindCUDA.cmake function CUDA_WRAP_SRCS should respect
COMPILE_PDB_OUTPUT_DIRECTORY property and COMPILE_PDB_OUTPUT_DIRECTORY_{CONFIG}
if set and propagate value of this property to invocation of NVCC with option
-Xcompiler \"/Fd{COMPILE_PDB_OUTPUT_DIRECTORY}\"
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-20 03:49 tomwar         New Issue                                    
======================================================================


From mantis at public.kitware.com  Tue Oct 20 05:32:16 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 20 Oct 2015 05:32:16 -0400
Subject: [cmake-developers] [CMake 0015804]: FindPkgConfig pkg_check_modules
	command should return full path to shared libraries in
	_LIBRARIES variable
Message-ID: <267aacea6a8af4ca29ae4a3dd0564534@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15804 
====================================================================== 
Reported By:                Sam Thursfield
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15804
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-20 05:32 EDT
Last Modified:              2015-10-20 05:32 EDT
====================================================================== 
Summary:                    FindPkgConfig pkg_check_modules command should
return full path to shared libraries in _LIBRARIES variable
Description: 
CMake seems to encourage using absolute paths to shared libraries.

>From link_directories() documentation:

       Note that this command is rarely necessary.  Library locations returned
       by find_package() and find_library() are absolute  paths.   Pass  these
       absolute  library  file  paths  directly to the target_link_libraries()
       command.  CMake will ensure the linker finds them.

However, the FindPkgConfig module doesn't follow this, and instead returns just
the names of libraries, plus a linker path. Since CMake makes it awkward to
propagate the linker path, so the end result is that if you have a package
installed in a non-standard library path, things break.

Steps to Reproduce: 
An example pkg-config file:

  cmake_minimum_required(VERSION 3.3.2)

  find_package(PkgConfig REQUIRED)

  pkg_check_modules(ZLIB zlib REQUIRED)

  message("ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
  message("ZLIB_LIBRARY_DIRS: ${ZLIB_LIBRARY_DIRS}")

Output:

  ZLIB_LIBRARIES: z
  ZLIB_LIBRARY_DIRS: /usr/lib64

Expected output:

  ZLIB_LIBRARIES: /usr/lib64/libz.so


Additional Information: 
I'm aware that in the case of Zlib there is a FindZLib module, and /usr/lib64 is
in my library search path in any case. This is just an example. The painful case
is where I had to build a library from source myself and then install it into a
non-standard prefix.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-20 05:32 Sam Thursfield New Issue                                    
======================================================================


From ben.boeckel at kitware.com  Tue Oct 20 11:42:09 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 20 Oct 2015 11:42:09 -0400
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <5625752F.3010608@yahoo.com>
References: <56200565.3070909@yahoo.com> <5624F06D.3010902@kitware.com>
 <5625752F.3010608@yahoo.com>
Message-ID: <20151020154209.GA16182@megas.khq.kitware.com>

On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers wrote:
> * I don't want to patch every script. To be precise I prefer to "Fix 
> something in one place so it works 100% and forget about it" then "Every 
> time I start creating script I should remember that..."

The "one place" would be make and (probably) ninja, not CMake as your
example indicates.

--Ben

From ruslan_baratov at yahoo.com  Tue Oct 20 15:53:42 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 21 Oct 2015 01:53:42 +0600
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <20151020154209.GA16182@megas.khq.kitware.com>
References: <56200565.3070909@yahoo.com> <5624F06D.3010902@kitware.com>
 <5625752F.3010608@yahoo.com> <20151020154209.GA16182@megas.khq.kitware.com>
Message-ID: <56269BC6.5080402@yahoo.com>

On 20-Oct-15 21:42, Ben Boeckel wrote:
> On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers wrote:
>> * I don't want to patch every script. To be precise I prefer to "Fix
>> something in one place so it works 100% and forget about it" then "Every
>> time I start creating script I should remember that..."
> The "one place" would be make and (probably) ninja, not CMake as your
> example indicates.
It's not a make or ninja issue. It's combination of "bad" date 
resolution, fast changing of file and performance of native build tool.
I can't reproduce scenario with source change on NTFS with Visual Studio 
generator, probably because Visual Studio is slow enough and play the 
role of "sleeping-guard". However I can reproduce same test on FAT32. 
And I've said already I can reproduce it on HFS with Xcode generator.

Cheers, Ruslo

From ruslan_baratov at yahoo.com  Tue Oct 20 17:03:00 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 21 Oct 2015 03:03:00 +0600
Subject: [cmake-developers] [Patch] Documentation file(GLOB): ordering note
Message-ID: <5626AC04.6090502@yahoo.com>

Add a note that order of files is not defined
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Documentation-file-GLOB-order-is-not-guaranteed.patch
Type: text/x-patch
Size: 1194 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151021/bd183a31/attachment.bin>

From mantis at public.kitware.com  Tue Oct 20 17:18:20 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 20 Oct 2015 17:18:20 -0400
Subject: [cmake-developers] [CMake 0015805]: pkg_get_variable from
	FindPkgConfig should honour search path from CMAKE_PREFIX_PATH
Message-ID: <c8943f38d43fb6ce70f98dd12a62819d@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15805 
====================================================================== 
Reported By:                Sam Thursfield
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15805
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-20 17:18 EDT
Last Modified:              2015-10-20 17:18 EDT
====================================================================== 
Summary:                    pkg_get_variable from FindPkgConfig should honour
search path from CMAKE_PREFIX_PATH
Description: 
The pkg_get_variable function from FindPkgConfig.cmake that is added in CMake
3.4.0 is really useful! However, it needs to honour the same search path as
pkg_check_modules, otherwise it doesn't work when packages are not installed in
standard prefixes

Steps to Reproduce: 
Use attached test case

Expected output:

Magic word is: xyzzy

Actual output:

Package cmake-pkgconfig-test was not found in the pkg-config search path.
Perhaps you should add the directory containing `cmake-pkgconfig-test.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cmake-pkgconfig-test' found
CMake Error at CMakeLists.txt:15 (message):
  Did not pick up magic_word variable from cmake-pkgconfig-test.pc


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-20 17:18 Sam Thursfield New Issue                                    
2015-10-20 17:18 Sam Thursfield File Added: cmake-pkg-get-variable-testcase.sh  
                 
======================================================================


From ben.boeckel at kitware.com  Tue Oct 20 17:25:11 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 20 Oct 2015 17:25:11 -0400
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <56269BC6.5080402@yahoo.com>
References: <56200565.3070909@yahoo.com> <5624F06D.3010902@kitware.com>
 <5625752F.3010608@yahoo.com>
 <20151020154209.GA16182@megas.khq.kitware.com>
 <56269BC6.5080402@yahoo.com>
Message-ID: <20151020212511.GA5819@megas.khq.kitware.com>

On Wed, Oct 21, 2015 at 01:53:42 +0600, Ruslan Baratov wrote:
> On 20-Oct-15 21:42, Ben Boeckel wrote:
> > On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers wrote:
> >> * I don't want to patch every script. To be precise I prefer to "Fix
> >> something in one place so it works 100% and forget about it" then "Every
> >> time I start creating script I should remember that..."
> > The "one place" would be make and (probably) ninja, not CMake as your
> > example indicates.
> It's not a make or ninja issue.

Doesn't your example Makefile without CMake in the loop show this issue
without CMake being present though?

--Ben

From ruslan_baratov at yahoo.com  Tue Oct 20 17:45:48 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 21 Oct 2015 03:45:48 +0600
Subject: [cmake-developers] Filesystem timestamp checks
In-Reply-To: <20151020212511.GA5819@megas.khq.kitware.com>
References: <56200565.3070909@yahoo.com> <5624F06D.3010902@kitware.com>
 <5625752F.3010608@yahoo.com> <20151020154209.GA16182@megas.khq.kitware.com>
 <56269BC6.5080402@yahoo.com> <20151020212511.GA5819@megas.khq.kitware.com>
Message-ID: <5626B60C.9020703@yahoo.com>

On 21-Oct-15 03:25, Ben Boeckel wrote:
> On Wed, Oct 21, 2015 at 01:53:42 +0600, Ruslan Baratov wrote:
>> On 20-Oct-15 21:42, Ben Boeckel wrote:
>>> On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers wrote:
>>>> * I don't want to patch every script. To be precise I prefer to "Fix
>>>> something in one place so it works 100% and forget about it" then "Every
>>>> time I start creating script I should remember that..."
>>> The "one place" would be make and (probably) ninja, not CMake as your
>>> example indicates.
>> It's not a make or ninja issue.
> Doesn't your example Makefile without CMake in the loop show this issue
> without CMake being present though?
Yes. I mean "It's not **only** a make or ninja issue" so fixing make 
will not help. I'm pretty sure this "feature" is reproducible using any 
generator if file system date resolution is bad enough.

From mantis at public.kitware.com  Tue Oct 20 18:34:09 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 20 Oct 2015 18:34:09 -0400
Subject: [cmake-developers] [CMake 0015806]: The Xcode generator consumes
	all arguments beginning with "-g"
Message-ID: <d747ea0d9f7750d8e5e59707f5bf9891@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15806 
====================================================================== 
Reported By:                Ching Ping Sun
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15806
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-20 18:34 EDT
Last Modified:              2015-10-20 18:34 EDT
====================================================================== 
Summary:                    The Xcode generator consumes all arguments beginning
with "-g"
Description: 
cmake, when generating Xcode projects, attempts to translate arguments starting
with -g? flags into the proper Xcode project file setting. In doing so, it
removes all arguments beginning with "-g" from the CMAKE_CXX_FLAGS_DEBUG and
CMAKE_C_FLAGS_DEBUG variables and they do not get passed to the
OTHER_CPLUSPLUSFLAGS and OTHER_CFLAGS values in the Xcode project.

I have attached 2 files to reproduce this situation. (one CMakeLists.txt, one 
foo.cpp as a build source), in CMakeLists.txt, the -ftemplate-depth=1024 can be
translated to Xcode project settings, while the -gline-tables-only can not.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-20 18:34 Ching Ping Sun New Issue                                    
2015-10-20 18:34 Ching Ping Sun File Added: CMakeLists.txt                    
======================================================================


From nunomp at iol.pt  Wed Oct 21 05:26:30 2015
From: nunomp at iol.pt (nunomp at iol.pt)
Date: Wed, 21 Oct 2015 10:26:30 +0100
Subject: [cmake-developers] =?utf-8?q?CMAKE=5FFortran=5FSIMULATE=5FVERSION?=
Message-ID: <33ded6c33b5fc0b204b7212d00a41790@iol.pt>

 

Hi All, 

I am trying to track down a problem related to the
assignment of values to the MSVC_VERSION variable and I have a question:


How is the CMAKE_Fortran_SIMULATE_VERSION created? 

which source file
should I look for? 

I know about the file CMakeFortranCompiler.cmake.in
but it is not clear to me where the real value comes from. 

Any help
would be highly appreciated. 

Best regards, 

Nuno 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151021/01670f1a/attachment.html>

From brad.king at kitware.com  Wed Oct 21 08:54:38 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 21 Oct 2015 08:54:38 -0400
Subject: [cmake-developers] [Patch] Documentation file(GLOB): ordering
 note
In-Reply-To: <5626AC04.6090502@yahoo.com>
References: <5626AC04.6090502@yahoo.com>
Message-ID: <56278B0E.30802@kitware.com>

On 10/20/2015 05:03 PM, Ruslan Baratov via cmake-developers wrote:
> Add a note that order of files is not defined

Thanks, applied:

 Help: Document that file(GLOB*) order is undefined
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5a208f83

-Brad


From brad.king at kitware.com  Wed Oct 21 08:54:44 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 21 Oct 2015 08:54:44 -0400
Subject: [cmake-developers] CMAKE_Fortran_SIMULATE_VERSION
In-Reply-To: <33ded6c33b5fc0b204b7212d00a41790@iol.pt>
References: <33ded6c33b5fc0b204b7212d00a41790@iol.pt>
Message-ID: <56278B14.4060406@kitware.com>

On 10/21/2015 05:26 AM, nunomp at iol.pt wrote:
> How is the CMAKE_Fortran_SIMULATE_VERSION created?

Take a look at these files:

 Modules/CMakeDetermineCompilerId.cmake
 Modules/CMakeFortranCompilerId.F.in:

The INFO:simulate_version[] strings are used to extract the
value from a binary compiled with the Fortran compiler.

-Brad


From robert.maynard at kitware.com  Wed Oct 21 16:39:37 2015
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 21 Oct 2015 16:39:37 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.0-rc2 is now ready!
Message-ID: <CAFzjYVpsNvy8AEkJFcaykbFAHVXsH_gJTRBLcFCQ+x=qUrGLug@mail.gmail.com>

I am proud to announce the second CMake 3.4 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.4

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.4/release/3.4.html

Some of the more significant features of CMake 3.4 are:

* The "if()" command learned a new "TEST" operator that evaluates to
  true if a given test name has been defined by the "add_test()"
  command.  See policy "CMP0064".

* The "install(DIRECTORY)" command "DESTINATION" option learned to
  support "generator expressions".

* The "install(FILES)" command "DESTINATION" option learned to
  support "generator expressions".

* CMake learned to honor "*.manifest" source files with MSVC tools.
  Manifest files named as sources of ".exe" and ".dll" targets will be
  merged with linker-generated manifests and embedded in the binary.


Deprecated and Removed Features:

* The "CMakeExpandImportedTargets" module is now documented as
  deprecated.  See module documentation for an explanation.

* The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect.
  Previously it was partially implemented and unreliable.

CMake 3.4 Release Notes
***********************

Changes made since CMake 3.3 include the following.


New Features
============


Generators
----------

* The "Visual Studio 14 2015" generator learned to select a Windows
  10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and
  the SDKs available on the host.

* CMake learned rudimentary support for the Apple Swift language.
  When using the "Xcode" generator with Xcode 6.1 or higher, one may
  enable the "Swift" language with the "enable_language()" command or
  the "project()" command (this is an error with other generators or
  when Xcode is too old).  Then one may list ".swift" source files in
  targets for compilation.


Commands
--------

* The "find_program()" command learned a "NAMES_PER_DIR" option to
  consider all given "NAMES" in each directory before moving on to the
  next directory.

* The "get_filename_component()" command learned a new "BASE_DIR"
  subcommand.  This is used to specify a base directory when
  calculating an absolute path from a relative path.

* The "if()" command learned a new "TEST" operator that evaluates to
  true if a given test name has been defined by the "add_test()"
  command.  See policy "CMP0064".

* The "install(DIRECTORY)" command "DESTINATION" option learned to
  support "generator expressions".

* The "install(FILES)" command "DESTINATION" option learned to
  support "generator expressions".

* The "string()" command learned a new "APPEND" subcommand.


Variables
---------

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools like distcc and ccache along with the
  compiler for "C" and "CXX" languages.  See the
  "CMAKE_<LANG>_COMPILER_LAUNCHER" variable and
  "<LANG>_COMPILER_LAUNCHER" target property for details.

* New "CMAKE_LINK_SEARCH_START_STATIC" and
  "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to
  initialize the "LINK_SEARCH_START_STATIC" and
  "LINK_SEARCH_END_STATIC" target properties, respectively.


Properties
----------

* Visual Studio Generators learned to support additonal target
  properties to customize projects for NVIDIA Nsight Tegra Visual
  Studio Edition:

  * "ANDROID_ANT_ADDITIONAL_OPTIONS"

  * "ANDROID_ARCH"

  * "ANDROID_ASSETS_DIRECTORIES"

  * "ANDROID_JAR_DEPENDENCIES"

  * "ANDROID_JAR_DIRECTORIES"

  * "ANDROID_JAVA_SOURCE_DIR"

  * "ANDROID_NATIVE_LIB_DEPENDENCIES"

  * "ANDROID_NATIVE_LIB_DIRECTORIES"

  * "ANDROID_PROCESS_MAX"

  * "ANDROID_PROGUARD"

  * "ANDROID_PROGUARD_CONFIG_PATH"

  * "ANDROID_SECURE_PROPS_PATH"

  * "ANDROID_SKIP_ANT_STEP"

  * "ANDROID_STL_TYPE"

* The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and
  "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support
  "generator expressions".

* The "SOURCE_DIR" and "BINARY_DIR" target properties were
  introduced to allow project code to query where a target is defined.

* The "OUTPUT_NAME" target property and its variants learned to
  support "generator expressions".

* A "TARGET_MESSAGES" global property was added to tell the Makefile
  Generators whether to generate commands to print output after each
  target is completed.

* On Windows with MS-compatible tools, CMake learned to optionally
  generate a module definition (".def") file for "SHARED" libraries.
  See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property.


Modules
-------

* The "ExternalProject" module "ExternalProject_Add()" function
  "GIT_SUBMODULES" option now also limits the set of submodules that
  are initialized in addition to the prior behavior of limiting the
  set of submodules that are updated.

* The "ExternalProject" module learned new "USES_TERMINAL" arguments
  for giving steps exclusive terminal access.  This is useful with the
  "Ninja" generator to monitor CMake superbuild progress and prevent
  CPU oversubscription.

* The "FindBISON" module "BISON_TARGET" macro learned a new
  "DEFINES_FILE" option to specify a custom output header to be
  generated.

* The "FindHDF5" module learend a new "HDF5_PREFER_PARALLEL" option
  allowing users to specify that a parallel HDF5 tool is preferred if
  both are available.

* The "FindIce" module now provides imported targets.

* The "FindJava" module learned to optionally find the "idlj" and
  "jarsigner" tools.

* The "FindOpenSSL" module now provides imported targets.

* The "FindOpenSSL" module learned a new "OPENSSL_USE_STATIC_LIBS"
  option to search only for static libraries.

* The "FindPkgConfig" learned a new "pkg_get_variable()" command
  which may be used to query for arbitrary variables from a package
  (such as for related tools or data and plugin install paths).

* The "FindProtobuf" module gained a new
  "protobuf_generate_python()" function to generate python sources
  from ".proto" files.

* The "FindTIFF" module learned to search separately for debug and
  release variants.

* The "FindwxWidgets" module learned to support version requests.

* The "FindXercesC" module learned to search separately for debug
  and release variants.

* The "FindZLIB" module learned to search separately for debug and
  release variants.

* The "GNUInstallDirs" module learned special default values for
  certain installation prefixes according to the GNU Coding Standards
  and the Filesystem Hierarchy Standard.

* The "UseJava" module "add_jar" function learned to support
  response files (e.g. "@srcs.txt") for source specification.

* The "UseJava" module "install_jar" function learned new
  "DESTINATION" and "COMPONENT" options to specify the corresponding
  "install()" command options.

* The "UseJava" module gained a new "create_javah" function to
  create C headers from Java classes.


Generator Expressions
---------------------

* A new "$<SHELL_PATH:...>" "generator expression" has been added.


CTest
-----

* CTest learned to optionally measure the CPU load during parallel
  testing and avoid starting tests that may cause the load to exceed a
  given threshold.  See the "ctest(1)" command "--test-load" option,
  the "TestLoad" setting of the CTest Test Step, the "CTEST_TEST_LOAD"
  variable, and the "TEST_LOAD" option of the "ctest_test()" command.

* "ctest(1)" learned options "--test-output-size-passed" and "--
  test- output-size-failed" to customize the limit on test output size
  submitted when running as a Dashboard Client.


CPack
-----

* The "CPackDeb" module learned to set package dependencies per
  component.  See variables:

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES"

  * "CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS"

* The "CPack" module learned to package empty directories.

* The "CPack" module gained a new setting,
  "CPACK_VERBATIM_VARIABLES", which can be used to ensure the cpack
  program receives the settings' values exactly as they were set, even
  if they contain CMake-special characters. For compatibility, it's
  off by default.


Other
-----

* The "Compile Features" functionality is now aware of features
  supported by GNU C compilers on Windows.

* CMake learned to honor "*.manifest" source files with MSVC tools.
  Manifest files named as sources of ".exe" and ".dll" targets will be
  merged with linker-generated manifests and embedded in the binary.

* The Concurrent Fortran 77 compiler is now supported. Its "compiler
  id" is "CCur".

* "cmake(1)" gained a new "--trace-expand" command line option that
  is like "--trace" but expands variable references in the output.


Deprecated and Removed Features
===============================

* The "CMakeExpandImportedTargets" module is now documented as
  deprecated.  See module documentation for an explanation.

* The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect.
  Previously it was partially implemented and unreliable.


Other Changes
=============

* The "CheckFunctionExists", "CheckLibraryExists",
  "CheckSymbolExists", and "FindThreads" modules learned to work in
  environments where only CXX is enabled.

* The "CPackDeb" module now correctly excludes symlinks during
  package checksum calculation.

* The "CPackDeb" no longer uses fakeroot and system tar program for
  packaging.

* The "CPack" module no longer mangles settings with CMake-special
  characters when they're used as defaults for other settings. The
  macro "cpack_set_if_not_set", which was responsible for this, is now
  deprecated.

* CMake no longer links executables with flags to export symbols
  unless the "ENABLE_EXPORTS" target property is set. See policy
  "CMP0065".

* The "SONAME" field is no longer set for "MODULE" libraries created
  with the "add_library()" command.  "MODULE" libraries are meant for
  explicit dynamic loading at runtime. They cannot be linked so
  "SONAME" is not useful.

* The internal "CMAKE_<LANG>_COMPILE_OBJECT" rule variable now
  substitutes compiler include flags in a separate "<INCLUDES>"
  placeholder instead of the main "<FLAGS>" placeholder.

--------------------------------------------------------------------------
Changes made since CMake 3.4.0-rc1:

Brad King (6):
      Revert topic 'compiler-features-solaris'
      Help: Add release note about compile rule placeholder changes (#15787)
      ExternalProject: Fix Git version report in error message (#15791)
      ExternalProject: Always use CMake builtin FindGit (#15791)
      Help: Document add_test expectations of test command (#15798)
      CMake 3.4.0-rc2

Derek Bruening (1):
      CTest: Set Content-Type header for http file upload (#15774)

Gregor Jasny (1):
      Xcode: Adjust deployment target SDK version to host version

James Johnston (1):
      Help: Document that SHARED libraries must export a symbol (#15775)

Kevin Burge (1):
      cmake-mode.el: treat keywords as symbols

Kevin Wojniak (1):
      CPackWIX: fix typos in documentation

Ruslan Baratov (1):
      Help: Document that file(GLOB*) order is undefined

Stephen Kelly (1):
      cmIfCommand: Issue CMP0054 warning with appropriate context. (#15802)

Tamar Kranenburg (1):
      FindPostgreSQL: Search for version 9.5

From michael.scott250 at gmail.com  Wed Oct 21 18:01:38 2015
From: michael.scott250 at gmail.com (Michael Scott)
Date: Wed, 21 Oct 2015 23:01:38 +0100
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <5624F283.9040900@kitware.com>
References: <5624F283.9040900@kitware.com>
Message-ID: <56280B42.3060707@gmail.com>

> I think having local CMAKE_WARN_DEPRECATED/CMAKE_ERROR_DEPRECATED vars
> can be left as specific to the message() command (and perhaps other
> IssueMessage callers as deemed appropriate per-case).  Otherwise we
> should just have one global setting.
Okay that sounds good to me, makes the implementation simpler.

> We just need to make sure the process exit code is changed.
If this is the case then just ensuring that IssueMessage sets the fatal 
error occurred flag, on a (upgraded or not) author or deprecated error 
as planned, may achieve this as it looks like cmake::Generate changes 
its return code if the error flag is set, but perhaps I'm mistaken or 
other code paths don't have this behaviour. So I probably wouldn't feel 
confident on relying on just setting the flag in IssueMessage.

> We may not have to update all callers to
> achieve this; it would only be an optimization.  OTOH perhaps we
> should defer this part until after the main warning control
> command-line options are worked out.
That sounds sensible, I'll make the proposed changes to the cmake and 
cmMessageCommand classes first, get some adequate tests in and then move 
on to updating the callers. I don't think it'll be a massive task to 
update the callers so I'm not particularly worried about that part, 
hopefully there won't be any surprises though.

I'm aiming to get a first patch proposal done by the end of this week.

Cheers,
Michael





From mantis at public.kitware.com  Thu Oct 22 08:45:40 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 22 Oct 2015 08:45:40 -0400
Subject: [cmake-developers] [CMake 0015807]: Regex does not match last
	parenthesis if parenthesis is part of character set.
Message-ID: <92e436599df169ec7341b5ba656c8355@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15807 
====================================================================== 
Reported By:                maarten
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15807
Category:                   (No Category)
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-22 08:45 EDT
Last Modified:              2015-10-22 08:45 EDT
====================================================================== 
Summary:                    Regex does not match last parenthesis if parenthesis
is part of character set.
Description: 
The aim is to extract the content between two parentheses.

Example:
from the string "FUNCTION(ARG1, ARG2, ARG3) //COMMENT",
I want to extract "ARG1, ARG2, ARG3".

The normal behavior of CMake is to return all the matched characters.
In the case of a paranthesis as matched character, it does not return the
closing parenthesis.

For reference, I have added the expected behavior by replacing all parentheses
with underscores.

Steps to Reproduce: 
cmake_minimum_required(VERSION 3.3)

#Do the match with parentheses
string(REGEX MATCH "FUNCTION\(([^\)]+)\)" ARGUMENT "FUNCTION(ARG1, ARG2, ARG3)
//COMMENT")
message(STATUS "Result of regex match with parentheses: ${ARGUMENT}")

#Redo the match with the parentheses replaced with underscores
string(REGEX MATCH "FUNCTION_([^_]+)_" ARGUMENT "FUNCTION_ARG1, ARG2, ARG3_
//COMMENT")

message(STATUS "Result of regex match with underscores: ${ARGUMENT}")

Additional Information: 
Output of the CMakeLists.txt:
-- The C compiler identification is GNU 5.1.1
-- The CXX compiler identification is GNU 5.1.1
-- Check for working C compiler: /usr/lib64/ccache/cc
-- Check for working C compiler: /usr/lib64/ccache/cc -- 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: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Result of regex match with parentheses: FUNCTION(ARG1, ARG2, ARG3
-- Result of regex match with underscores: FUNCTION_ARG1, ARG2, ARG3_
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp

The result of the regex match with parentheses should be
FUNCTION(ARG1, ARG2, ARG3)
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-22 08:45 maarten        New Issue                                    
======================================================================


From brad.king at kitware.com  Thu Oct 22 10:23:21 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 22 Oct 2015 10:23:21 -0400
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <56280B42.3060707@gmail.com>
References: <5624F283.9040900@kitware.com> <56280B42.3060707@gmail.com>
Message-ID: <5628F159.3040400@kitware.com>

On 10/21/2015 06:01 PM, Michael Scott wrote:
>> should defer this part until after the main warning control
>> command-line options are worked out.
> That sounds sensible, I'll make the proposed changes to the cmake and 
> cmMessageCommand classes first, get some adequate tests in and then move 
> on to updating the callers.

Oops; actually by "this part" I was referring to the entire warning->error
upgrade feature.  Let's work out the command line options for the existing
deprecation warning/error options first and then extend capabilities as
a second step.  It will be easier to review in smaller pieces anyway.

Thanks,
-Brad


From rleigh at codelibre.net  Thu Oct 22 10:58:29 2015
From: rleigh at codelibre.net (rleigh at codelibre.net)
Date: Thu, 22 Oct 2015 15:58:29 +0100 (BST)
Subject: [cmake-developers] Fragile behaviour of msbuild when using Visual
 Studio solution/project generators
Message-ID: <92fb538b711dbd93993635d2c8f31f42.squirrel@g.mail.aa.net.uk>

I encountered an unexpected build failure in a superbuild project today,
and after investigation with the help of ngladitz on #cmake, we got to the
bottom of the problem.

http://blogs.msdn.com/b/dsvc/archive/2012/02/29/output-from-exec-task-resulting-in-build-failure.aspx

When cmake runs an external command in the build, if that command outputs
to stdout the strings "Error:" or "error:" this will *fail the build*
irrespective of the exit status of that command (!).  Looks like a
horrible design flaw in msbuild, but the implication is that this makes
the build quite fragile since any output at all, including test output,
output from custom tools and scripts etc., can all cause a build failure.

Examples:

http://pastebin.ca/3211683 - build failure due to "Error:" and "error:"
http://pastebin.ca/3211759 - build success with the output adjusted to
remove these strings
In both these cases, the tests all pass and ctest returns a zero exit status.

The msbuild <Exec> task can use IgnoreStandardErrorWarningFormat="true" to
suppress this behaviour.  It would probably be appropriate to enable this
for all uses other than maybe compiling and linking.  We seem to use
<CustomBuild>'s <Command> rather than <Exec>; if the flag works for both
elements that would be great, but I'm afraid I'm not an expert in the
internals of msbuild and I couldn't find any obvious documentation for
<CustomBuild>.  If this could be made to ignore what's on stdout/err when
running unit tests and other non-build/link tasks that would be really
great.


Regards,
Roger


From brad.king at kitware.com  Thu Oct 22 11:43:16 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 22 Oct 2015 11:43:16 -0400
Subject: [cmake-developers] Fragile behaviour of msbuild when using
 Visual Studio solution/project generators
In-Reply-To: <92fb538b711dbd93993635d2c8f31f42.squirrel@g.mail.aa.net.uk>
References: <92fb538b711dbd93993635d2c8f31f42.squirrel@g.mail.aa.net.uk>
Message-ID: <56290414.4010209@kitware.com>

On 10/22/2015 10:58 AM, rleigh at codelibre.net wrote:
> The msbuild <Exec> task can use IgnoreStandardErrorWarningFormat="true" to
> suppress this behaviour.  It would probably be appropriate to enable this
> for all uses other than maybe compiling and linking.

Yes, if it is possible.

> We seem to use <CustomBuild>'s <Command> rather than <Exec>

We use that because it is what the IDE uses when creating a project file
so using it makes the command visible in the IDE properties.  It also handles
all the dependencies and such instead of always executing, and is the only
way to get proper semantics we've found.  If no setting is available then
I think the solution is "don't do that" :(

> internals of msbuild and I couldn't find any obvious documentation for
> <CustomBuild>.

I'm not very familiar with it either.  I see something that looks like a
definition of the CustomBuild target type in files like these:

 c:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/Microsoft.CppCommon.targets
 c:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/V110/Microsoft.CppCommon.targets
 c:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/V120/Microsoft.CppCommon.targets
 c:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/V140/Microsoft.CppCommon.targets

-Brad


From JamesJ at motionview3d.com  Thu Oct 22 13:52:48 2015
From: JamesJ at motionview3d.com (James Johnston)
Date: Thu, 22 Oct 2015 17:52:48 -0000
Subject: [cmake-developers] Fragile behaviour of msbuild when using
	Visual Studio solution/project generators
In-Reply-To: <56290414.4010209@kitware.com>
References: <92fb538b711dbd93993635d2c8f31f42.squirrel@g.mail.aa.net.uk>
 <56290414.4010209@kitware.com>
Message-ID: <072301d10cf2$7773c5f0$665b51d0$@motionview3d.com>

> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of Brad King
> Sent: Thursday, October 22, 2015 15:43
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] Fragile behaviour of msbuild when using
> Visual Studio solution/project generators
> 
> > We seem to use <CustomBuild>'s <Command> rather than <Exec>
> 
> We use that because it is what the IDE uses when creating a project file
so
> using it makes the command visible in the IDE properties.  It also handles
all
> the dependencies and such instead of always executing, and is the only way
> to get proper semantics we've found.  If no setting is available then I
think
> the solution is "don't do that" :(
> 
> > internals of msbuild and I couldn't find any obvious documentation for
> > <CustomBuild>.
> 
> I'm not very familiar with it either.  I see something that looks like a
definition
> of the CustomBuild target type in files like these:
> 
>  c:/Program Files
> (x86)/MSBuild/Microsoft.Cpp/v4.0/Microsoft.CppCommon.targets
>  c:/Program Files
> (x86)/MSBuild/Microsoft.Cpp/v4.0/V110/Microsoft.CppCommon.targets
>  c:/Program Files
> (x86)/MSBuild/Microsoft.Cpp/v4.0/V120/Microsoft.CppCommon.targets
>  c:/Program Files
> (x86)/MSBuild/Microsoft.Cpp/v4.0/V140/Microsoft.CppCommon.targets

Summary: I think there is a solution but it isn't the prettiest; see below:

Ultimately, the VC tasks derive from Microsoft.Build.Utilities.ToolTask.  I
examined MSBuild 4.0 (newer versions may offer more flexibility):

1.  Private ToolTask.LogMessagesFromStandardError is called whenever the
process emits something on standard error.  It's a one liner function that
calls private LogMessagesFromStandardErrorOrOutput.
2.  ToolTask.LogMessagesFromStandardErrorOrOutput calls protected virtual
LogEventsFromTextOutput with the error/output line.
3.  ToolTask's virtual LogEventsFromTextOutput implementation calls base
class Task.Log.LogMessageFromText.  Task.Log is a TaskLoggingHelper type
property.  It itself is a read-only property so that a user can't swap out
that variable.
4.  Public TaskLoggingHelper.LogMessageFromText is where it starts getting
interesting.  It calls CanonicalError.Parse, which checks for magic "error"
and "warning" strings.  If either string is found, a regex is used and if
it's a match, then the function returns information about the parsed
error/warning.  There isn't a way to skip it that I can see.  If Parse
indicates that it parsed an error, you're guaranteed to have LogError called
instead of the normal LogMessage.

So as far as I can tell, anyone making an MSBuild task derived from ToolTask
(very common) is guaranteed to get this error parsing capability by default
whether they like it or not.

Unless they override virtual LogEventsFromTextOutput.  Which is what the
Exec task does.  Exec overrides LogEventsFromTextOutput so that it can honor
the IgnoreStandardErrorWarningFormat property, which is specific to the Exec
task.  If the user doesn't set that property, it will call
base.Log.LogMessageFromText (see above).  If they do set it, they always
just log it as a Message and do not try to parse it.

Unfortunately, the CustomBuild task and all of its base classes between
CustomBuild and ToolTask do not override LogEventsFromTextOutput.  So
CustomBuild will get the default ToolTask error parsing capability that
can't be flipped off any other way.  CustomBuild is totally unrelated to and
independent of Exec task, other than that both of them derive from ToolTask.

It looks like somebody else discusses it here:
http://aschultz.us/blog/archives/316

I'm not sure why MSBuild team put IgnoreStandardErrorWarningFormat in Exec
task instead of the base ToolTask class.  (Or at least provide protected
members to easily allow derived classes to control the behavior without
having to completely reimplement the functionality in
LogEventsFromTextOutput).  It doesn't seem like a smart design.  Maybe
somebody can encourage the MSBuild team to rectify this problem - e.g. by
adding something similar to IgnoreStandardErrorWarningFormat to ToolTask
would seem like a simple enough thing to do that won't break
compatibility...

In the meantime, probably the only way to use CustomBuild and dodge this
error parsing behavior is to write a new MSBuild task that derives from
CustomBuild and then overrides LogEventsFromTextOutput.  Normally MSBuild
tasks require a precompiled .NET assembly to be available like in the
.targets files Brad pointed out.  However in MSBuild 4 I guess there is a
way to put the task implementation inline in the project file: " MSBuild
Inline Tasks " https://msdn.microsoft.com/en-us/library/dd722601.aspx ----
however this solution might have some downsides and somebody would have to
experiment to see if they are tolerable: (1) how will the IDE project
properties, etc. react to the proposed "CMakeCustomBuild" task derived from
CustomBuild instead of "CustomBuild" directly? E.g. will it let you view/set
the task properties like normal still from the IDE? (2) the IDE might give
some annoying security warnings when opening the project since the project
file is basically executing arbitrary C# code, (3) adds complexity to the
CMake generator.

Best regards,

James Johnston


From nilsgladitz at gmail.com  Fri Oct 23 03:10:52 2015
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 23 Oct 2015 09:10:52 +0200
Subject: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU
Message-ID: <5629DD7C.6000103@gmail.com>

I switched from 3.2.1 to 3.4.0-rc2 on a Windows and a Linux dashboard 
client for a custom project.

On the Linux client parallel testing now loops with 100% CPU somewhere 
in cmCTestMultiProcessHandler::StartNextTests and 
cmCTestMultiProcessHandler::CheckOutput.

I don't have a proper stack trace on the windows client but it seems to 
hang there too.

Nils

From nilsgladitz at gmail.com  Fri Oct 23 03:23:47 2015
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 23 Oct 2015 09:23:47 +0200
Subject: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU
In-Reply-To: <5629DD7C.6000103@gmail.com>
References: <5629DD7C.6000103@gmail.com>
Message-ID: <5629E083.1030309@gmail.com>

On 10/23/2015 09:10 AM, Nils Gladitz wrote:
> I switched from 3.2.1 to 3.4.0-rc2 on a Windows and a Linux dashboard 
> client for a custom project.
>
> On the Linux client parallel testing now loops with 100% CPU somewhere 
> in cmCTestMultiProcessHandler::StartNextTests and 
> cmCTestMultiProcessHandler::CheckOutput.
>

I reduced it to this test case:

   cmake_minimum_required(VERSION 3.4)

   project(Foo NONE)

   enable_testing()

   add_test(NAME foo COMMAND command_not_found)
   set_property(TEST foo PROPERTY RUN_SERIAL ON)

   add_test(NAME bar COMMAND ${CMAKE_COMMAND} -E echo let_me_run)

The issue seems to exist for sequential ctest runs as well.

The breaking commit seems to be:
     07c550caa20d4b1d6ebc08269d744ff6a45c0a6d 
cmCTestMultiProcessHandler: Refactor RUN_SERIAL implementation

Nils

From nilsgladitz at gmail.com  Fri Oct 23 05:22:07 2015
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 23 Oct 2015 11:22:07 +0200
Subject: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian
	packages broken
Message-ID: <5629FC3F.8030904@gmail.com>

Given this test case:
   cmake_minimum_required(VERSION 3.3)

   project(Foo NONE)

   install(FILES CMakeLists.txt DESTINATION tmp)

   set(CPACK_DEBIAN_COMPRESSION_TYPE "xz")
   set(CPACK_PACKAGE_CONTACT "foo at bar.com")

   include(CPack)

A debian package created with:
     cpack -G DEB

Fails during installation with dpkg -i with:
   tar: Archive is compressed. Use -J option
   tar: Error is not recoverable: exiting now
   dpkg-deb: error: subprocess tar returned error exit status 2

The breaking commit seems to be:
     7044e8ee4baa8250fd9c4e915b13d53c7f543ea3 CPackDeb: use of 
libarchive and removal of fakeroot

 From the looks of it the contained "control.tar.gz" is now XZ 
compressed as well while it previously was gzip compressed.

Nils

From raffi.enficiaud at mines-paris.org  Fri Oct 23 06:04:55 2015
From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud)
Date: Fri, 23 Oct 2015 12:04:55 +0200
Subject: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian
	packages broken
In-Reply-To: <5629FC3F.8030904@gmail.com>
References: <5629FC3F.8030904@gmail.com>
Message-ID: <n0d0o5$dur$1@ger.gmane.org>

Le 23/10/15 11:22, Nils Gladitz a ?crit :
> Given this test case:
>    cmake_minimum_required(VERSION 3.3)
>
>    project(Foo NONE)
>
>    install(FILES CMakeLists.txt DESTINATION tmp)
>
>    set(CPACK_DEBIAN_COMPRESSION_TYPE "xz")
>    set(CPACK_PACKAGE_CONTACT "foo at bar.com")
>
>    include(CPack)
>
> A debian package created with:
>      cpack -G DEB
>
> Fails during installation with dpkg -i with:
>    tar: Archive is compressed. Use -J option
>    tar: Error is not recoverable: exiting now
>    dpkg-deb: error: subprocess tar returned error exit status 2
>
> The breaking commit seems to be:
>      7044e8ee4baa8250fd9c4e915b13d53c7f543ea3 CPackDeb: use of
> libarchive and removal of fakeroot
>
>  From the looks of it the contained "control.tar.gz" is now XZ
> compressed as well while it previously was gzip compressed.
>
> Nils

Fix attached! (based on current master a03c13a)
Thank you for the report.

Best,
Raffi

PS.: I will add the test later today
-------------- next part --------------
>From fd9693db2b4dcdf6cc9ce5320c009b7e20533756 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enficiaud at mines-paris.org>
Date: Fri, 23 Oct 2015 12:01:35 +0200
Subject: [PATCH] fixup! CPackDEB proper compression scheme for control.tar.gz

---
 Source/CPack/cmCPackDebGenerator.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx
index 93c94e2..04efb71 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -570,7 +570,7 @@ int cmCPackDebGenerator::createDeb()
       return 0;
       }
     cmArchiveWrite control_tar(fileStream_control_tar,
-                               tar_compression_type,
+                               cmArchiveWrite::CompressGZip,
                                "paxr");
 
     // sets permissions and uid/gid for the files
-- 
2.0.1


From brad.king at kitware.com  Fri Oct 23 10:52:30 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 23 Oct 2015 10:52:30 -0400
Subject: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU
In-Reply-To: <5629E083.1030309@gmail.com>
References: <5629DD7C.6000103@gmail.com> <5629E083.1030309@gmail.com>
Message-ID: <562A49AE.6050204@kitware.com>

On 10/23/2015 03:23 AM, Nils Gladitz wrote:
> I reduced it to this test case:
> 
>    cmake_minimum_required(VERSION 3.4)
> 
>    project(Foo NONE)
> 
>    enable_testing()
> 
>    add_test(NAME foo COMMAND command_not_found)
>    set_property(TEST foo PROPERTY RUN_SERIAL ON)
> 
>    add_test(NAME bar COMMAND ${CMAKE_COMMAND} -E echo let_me_run)
> 
> The issue seems to exist for sequential ctest runs as well.
> 
> The breaking commit seems to be:
>      07c550caa20d4b1d6ebc08269d744ff6a45c0a6d 
> cmCTestMultiProcessHandler: Refactor RUN_SERIAL implementation

Thanks.  Fixed:

 CTest: Fix regression in handling of a RUN_SERIAL test that fails
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e61973e1

I've queued this for merge to 'release' for 3.4.0-rc3.

-Brad


From brad.king at kitware.com  Fri Oct 23 11:04:51 2015
From: brad.king at kitware.com (Brad King)
Date: Fri, 23 Oct 2015 11:04:51 -0400
Subject: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian
 packages broken
In-Reply-To: <n0d0o5$dur$1@ger.gmane.org>
References: <5629FC3F.8030904@gmail.com> <n0d0o5$dur$1@ger.gmane.org>
Message-ID: <562A4C93.3010107@kitware.com>

On 10/23/2015 06:04 AM, Raffi Enficiaud wrote:
> Fix attached! (based on current master a03c13a)

Thanks.  I backported it to 'release' and applied:

 CPackDEB: Use proper compression scheme for control.tar.gz
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66178ae5

> PS.: I will add the test later today

Great.  We can add that when ready.

Thanks,
-Brad

From nilsgladitz at gmail.com  Fri Oct 23 11:22:30 2015
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 23 Oct 2015 17:22:30 +0200
Subject: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian
 packages broken
In-Reply-To: <n0d0o5$dur$1@ger.gmane.org>
References: <5629FC3F.8030904@gmail.com> <n0d0o5$dur$1@ger.gmane.org>
Message-ID: <562A50B6.6020306@gmail.com>

On 23.10.2015 12:04, Raffi Enficiaud wrote:
>
> Fix attached! (based on current master a03c13a)
> Thank you for the report.

Thank you for the quick fix!

Nils

From nilsgladitz at gmail.com  Fri Oct 23 11:23:16 2015
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 23 Oct 2015 17:23:16 +0200
Subject: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU
In-Reply-To: <562A49AE.6050204@kitware.com>
References: <5629DD7C.6000103@gmail.com> <5629E083.1030309@gmail.com>
 <562A49AE.6050204@kitware.com>
Message-ID: <562A50E4.3040003@gmail.com>

On 23.10.2015 16:52, Brad King wrote:
> Thanks.  Fixed:
>
>   CTest: Fix regression in handling of a RUN_SERIAL test that fails
>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e61973e1
>
> I've queued this for merge to 'release' for 3.4.0-rc3.
>
> -Brad

Thanks!

Nils


From gjasny at googlemail.com  Fri Oct 23 16:56:04 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Fri, 23 Oct 2015 22:56:04 +0200
Subject: [cmake-developers] Patch: install universal iOS libraries
In-Reply-To: <5615BAAC.4040202@yahoo.com>
References: <5603CC15.5070201@yahoo.com> <561524AF.4070509@googlemail.com>
 <5615BAAC.4040202@yahoo.com>
Message-ID: <562A9EE4.6080405@googlemail.com>

On 08/10/15 02:37, Ruslan Baratov wrote:
>>> export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
>>> export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
>>> export SDK_NAME=iphonesimulator9.0
>> Could you use those variables to avoid hardcoding iphoneos/simulator in
>> the module?
> I see CORRESPONDING_*_SDK_NAME variables in Xcode 7.0 but not in 6.4.

At least in Xcode 6.2 I the following variable defined:
SUPPORTED_PLATFORMS="iphonesimulator iphoneos"

It also seems to be set with Xcode 7.1
SUPPORTED_PLATFORMS="watchsimulator watchos"
SUPPORTED_PLATFORMS="appletvos appletvsimulator"

I'd really like to avoid coding any form of database into CMake.
Same for the architectures: In the end the user (or the Xcode default)
sets a list of VALID_ARCHS for device and simulator. Maybe you could use
this for filtering.

I'll reserve a day next week to exclusively work on this topic.

Thanks,
Gregor

From michael.scott250 at gmail.com  Sat Oct 24 04:46:49 2015
From: michael.scott250 at gmail.com (Michael Scott)
Date: Sat, 24 Oct 2015 09:46:49 +0100
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <5628F159.3040400@kitware.com>
References: <5628F159.3040400@kitware.com>
Message-ID: <562B4579.5060905@gmail.com>

Hi Brad,

> Let's work out the command line options for the existing
> deprecation warning/error options first and then extend capabilities as
> a second step.  It will be easier to review in smaller pieces anyway.
Okay no problem, I'll try and break the changes down into chunks for review.

I've made the first set of changes,  to reapply the series of previous 
changes for the -W options, along with some tweaks to improve the 
implementation and some additional tests for the changes. Let me know if 
there are any issues with the proposed changes. The changes in the patch 
for the Help files are the same as before, so they can probably be 
skimmed over to be honest, likewise the changes in cmMessageCommand are 
the same as before too.

The next stage would then be to add support for upgrading and 
downgrading warning and error messages depending on the state of the 
CMake variables, in the IssueMessage function, and update the callers of 
the function to check the error flag and take appropriate action.

Cheers,
Michael
-------------- next part --------------
From 8d7aae1411331b980bd5d7515e5f7326db5890cb Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott250 at gmail.com>
Date: Fri, 23 Oct 2015 19:48:58 +0100
Subject: [PATCH] Add -W options to control deprecation and author warnings and
 errors

Refactor the -Wdev and -Wno-dev options parser to use a generic -W
parser that follows the GCC pattern, which includes support for
-Werror=TYPE and -Wno-error=TYPE formats.

Add 'deprecated' warning options type, to allow setting
CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED via the -W options.

Add -Werror=dev and -Wno-error=dev options so that dev warning options
are in line with deprecated warning options. Use a new
CMAKE_SUPPRESS_DEVELOPER_ERRORS internal cache entry to store the above
new dev options persistently.

Add tests for new options and updated cmake documentation and release
notes to list new options.
---
 Help/manual/OPTIONS_BUILD.txt                      |  43 ++-
 Help/release/dev/cmake-W-options.rst               |  13 +
 Help/variable/CMAKE_ERROR_DEPRECATED.rst           |   8 +-
 Help/variable/CMAKE_WARN_DEPRECATED.rst            |   6 +-
 Source/cmMessageCommand.cxx                        |  14 +-
 Source/cmake.cxx                                   | 297 ++++++++++++++++++---
 Source/cmake.h                                     |  27 +-
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake      |  59 +++-
 Tests/RunCMake/CommandLine/W_bad-arg1-result.txt   |   1 +
 Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt   |   2 +
 Tests/RunCMake/CommandLine/W_bad-arg2-result.txt   |   1 +
 Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt   |   2 +
 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt   |   1 +
 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt   |   2 +
 Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt  |   4 +
 Tests/RunCMake/CommandLine/Wdeprecated.cmake       |   1 +
 Tests/RunCMake/CommandLine/Wdev-stderr.txt         |   2 +-
 Tests/RunCMake/CommandLine/Wdev.cmake              |   2 +-
 .../CommandLine/Werror_deprecated-result.txt       |   1 +
 .../CommandLine/Werror_deprecated-stderr.txt       |   4 +
 Tests/RunCMake/CommandLine/Werror_deprecated.cmake |   1 +
 Tests/RunCMake/CommandLine/Werror_dev-result.txt   |   1 +
 Tests/RunCMake/CommandLine/Werror_dev-stderr.txt   |   5 +
 Tests/RunCMake/CommandLine/Werror_dev.cmake        |   1 +
 Tests/RunCMake/CommandLine/Wno-deprecated.cmake    |   1 +
 Tests/RunCMake/CommandLine/Wno-dev.cmake           |   2 +-
 .../CommandLine/Wno-error_deprecated.cmake         |   2 +
 Tests/RunCMake/CommandLine/Wno-error_dev.cmake     |   2 +
 28 files changed, 447 insertions(+), 58 deletions(-)
 create mode 100644 Help/release/dev/cmake-W-options.rst
 create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated.cmake
 create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated.cmake
 create mode 100644 Tests/RunCMake/CommandLine/Werror_dev-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/Werror_dev-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/Werror_dev.cmake
 create mode 100644 Tests/RunCMake/CommandLine/Wno-deprecated.cmake
 create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake
 create mode 100644 Tests/RunCMake/CommandLine/Wno-error_dev.cmake

diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt
index 4207db4..b65b7c7 100644
--- a/Help/manual/OPTIONS_BUILD.txt
+++ b/Help/manual/OPTIONS_BUILD.txt
@@ -77,10 +77,49 @@
  Suppress developer warnings.
 
  Suppress warnings that are meant for the author of the
- CMakeLists.txt files.
+ CMakeLists.txt files. By default this will also turn off
+ deprecation warnings.
 
 ``-Wdev``
  Enable developer warnings.
 
  Enable warnings that are meant for the author of the CMakeLists.txt
- files.
+ files. By default this will also turn on deprecation warnings.
+
+``-Werror=dev``
+ Make developer warnings errors.
+
+ Make warnings that are meant for the author of the CMakeLists.txt
+ files errors. By default this will also turn on treatment of
+ deprecation warnings as errors.
+
+``-Wno-error=dev``
+ Make developer warnings not errors.
+
+ Make warnings that are meant for the author of the CMakeLists.txt
+ files not errors. By default this will also turn off treatment of
+ deprecation warnings as errors.
+
+``-Wdeprecated``
+ Enable deprecated macro and function warnings.
+
+ Enable warnings for usage of deprecated macros and functions, that
+ are meant for the author of the CMakeLists.txt files.
+
+``-Wno-deprecated``
+ Suppress deprecated macro and function warnings.
+
+ Suppress warnings for usage of deprecated macros and functions, that
+ are meant for the author of the CMakeLists.txt files.
+
+``-Werror=deprecated``
+ Make deprecated macro and function warnings errors.
+
+ Make warnings for usage of deprecated macros and functions, that
+ are meant for the author of the CMakeLists.txt files, errors.
+
+``-Wno-error=deprecated``
+ Make deprecated macro and function warnings not errors.
+
+ Make warnings for usage of deprecated macros and functions, that
+ are meant for the author of the CMakeLists.txt files, not errors.
diff --git a/Help/release/dev/cmake-W-options.rst b/Help/release/dev/cmake-W-options.rst
new file mode 100644
index 0000000..c0b51d0
--- /dev/null
+++ b/Help/release/dev/cmake-W-options.rst
@@ -0,0 +1,13 @@
+cmake-W-options
+---------------
+
+* The :variable:`CMAKE_ERROR_DEPRECATED` variable can now be set using the
+  ``-Werror=deprecated`` and ``-Wno-error=deprecated`` :manual:`cmake(1)`
+  options.
+
+* The :variable:`CMAKE_WARN_DEPRECATED` variable can now be set using the
+  ``-Wdeprecated`` and ``-Wno-deprecated`` :manual:`cmake(1)` options.
+
+* :manual:`cmake(1)` gained options ``-Werror=dev`` and ``-Wno-error=dev``
+  to control whether developer warnings intended for project authors
+  are treated as errors.
diff --git a/Help/variable/CMAKE_ERROR_DEPRECATED.rst b/Help/variable/CMAKE_ERROR_DEPRECATED.rst
index 277a4cc..59eb391 100644
--- a/Help/variable/CMAKE_ERROR_DEPRECATED.rst
+++ b/Help/variable/CMAKE_ERROR_DEPRECATED.rst
@@ -3,6 +3,10 @@ CMAKE_ERROR_DEPRECATED
 
 Whether to issue deprecation errors for macros and functions.
 
-If ``TRUE``, this can be used by macros and functions to issue fatal
-errors when deprecated macros or functions are used.  This variable is
+If ``TRUE``, then macros and functions can issue fatal errors when
+deprecated macros or functions are used. This variable is
 ``FALSE`` by default.
+
+These errors can be enabled with the ``-Werror=deprecated`` option, or
+disabled with the ``-Wno-error=deprecated`` option, when running
+:manual:`cmake(1)`.
diff --git a/Help/variable/CMAKE_WARN_DEPRECATED.rst b/Help/variable/CMAKE_WARN_DEPRECATED.rst
index 662cbd8..5c8ce88 100644
--- a/Help/variable/CMAKE_WARN_DEPRECATED.rst
+++ b/Help/variable/CMAKE_WARN_DEPRECATED.rst
@@ -4,4 +4,8 @@ CMAKE_WARN_DEPRECATED
 Whether to issue deprecation warnings for macros and functions.
 
 If ``TRUE``, this can be used by macros and functions to issue deprecation
-warnings.  This variable is ``FALSE`` by default.
+warnings.  This variable is ``TRUE`` by default.
+
+These warnings can be enabled with the ``-Wdeprecated`` option, or
+disabled with the ``-Wno-deprecated`` option, when running
+:manual:`cmake(1)`.
diff --git a/Source/cmMessageCommand.cxx b/Source/cmMessageCommand.cxx
index 2854a82..e09ba75 100644
--- a/Source/cmMessageCommand.cxx
+++ b/Source/cmMessageCommand.cxx
@@ -43,7 +43,19 @@ bool cmMessageCommand
     }
   else if (*i == "AUTHOR_WARNING")
     {
-    type = cmake::AUTHOR_WARNING;
+    if (!this->Makefile->IsOn("CMAKE_SUPPRESS_DEVELOPER_ERRORS"))
+      {
+      fatal = true;
+      type = cmake::AUTHOR_ERROR;
+      }
+    else if (!this->Makefile->IsOn("CMAKE_SUPPRESS_DEVELOPER_WARNINGS"))
+      {
+      type = cmake::AUTHOR_WARNING;
+      }
+    else
+      {
+      return true;
+      }
     ++i;
     }
   else if (*i == "STATUS")
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 7268241..4d4553a 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -127,8 +127,6 @@ cmake::cmake()
   this->WarnUnused = false;
   this->WarnUnusedCli = true;
   this->CheckSystemVars = false;
-  this->SuppressDevWarnings = false;
-  this->DoSuppressDevWarnings = false;
   this->DebugOutput = false;
   this->DebugTryCompile = false;
   this->ClearBuildSystem = false;
@@ -250,15 +248,70 @@ bool cmake::SetCacheArgs(const std::vector<std::string>& args)
         return false;
         }
       }
-    else if(arg.find("-Wno-dev",0) == 0)
+    else if(cmHasLiteralPrefix(arg, "-W"))
       {
-      this->SuppressDevWarnings = true;
-      this->DoSuppressDevWarnings = true;
+      std::string entry = arg.substr(2);
+      if (entry.empty())
+        {
+        ++i;
+        if (i < args.size())
+          {
+          entry = args[i];
+          }
+        else
+          {
+          cmSystemTools::Error(
+            "-W must be followed with [no-][error=]<name>.");
+          return false;
+        }
       }
-    else if(arg.find("-Wdev",0) == 0)
-      {
-      this->SuppressDevWarnings = false;
-      this->DoSuppressDevWarnings = true;
+
+      std::string name;
+      bool foundNo = false;
+      bool foundError = false;
+      unsigned int nameStartPosition = 0;
+
+      if (entry.find("no-", nameStartPosition) == 0)
+        {
+        foundNo = true;
+        nameStartPosition += 3;
+        }
+
+      if (entry.find("error=", nameStartPosition) == 0)
+        {
+        foundError = true;
+        nameStartPosition += 6;
+        }
+
+      name = entry.substr(nameStartPosition);
+      if (name.empty())
+        {
+        cmSystemTools::Error("No warning name provided.");
+        return false;
+        }
+
+      if (!foundNo && !foundError)
+        {
+        // -W<name>
+        this->WarningLevels[name] = std::max(this->WarningLevels[name],
+                                             WARNING_LEVEL);
+        }
+      else if (foundNo && !foundError)
+        {
+         // -Wno<name>
+         this->WarningLevels[name] = IGNORE_LEVEL;
+        }
+      else if (!foundNo && foundError)
+        {
+        // -Werror=<name>
+        this->WarningLevels[name] = ERROR_LEVEL;
+        }
+      else
+        {
+        // -Wno-error=<name>
+        this->WarningLevels[name] = std::min(this->WarningLevels[name],
+                                             WARNING_LEVEL);
+        }
       }
     else if(arg.find("-U",0) == 0)
       {
@@ -591,11 +644,7 @@ void cmake::SetArgs(const std::vector<std::string>& args,
       // skip for now
       i++;
       }
-    else if(arg.find("-Wno-dev",0) == 0)
-      {
-      // skip for now
-      }
-    else if(arg.find("-Wdev",0) == 0)
+    else if(arg.find("-W",0) == 0)
       {
       // skip for now
       }
@@ -1190,25 +1239,133 @@ int cmake::HandleDeleteCacheVariables(const std::string& var)
 
 int cmake::Configure()
 {
-  if(this->DoSuppressDevWarnings)
+  WarningLevel warningLevel;
+
+  if (this->WarningLevels.count("deprecated") == 1)
     {
-    if(this->SuppressDevWarnings)
+    warningLevel = this->WarningLevels["deprecated"];
+    if (warningLevel == IGNORE_LEVEL)
       {
-      this->
-        AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "TRUE",
-                      "Suppress Warnings that are meant for"
-                      " the author of the CMakeLists.txt files.",
-                      cmState::INTERNAL);
+      this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE",
+                          "Whether to issue deprecation warnings for"
+                          " macros and functions.",
+                          cmState::BOOL);
+      this->AddCacheEntry("CMAKE_ERROR_DEPRECATED", "FALSE",
+                          "Whether to issue deprecation errors for macros"
+                          " and functions.",
+                          cmState::BOOL);
       }
-    else
+    if (warningLevel == WARNING_LEVEL)
+      {
+      this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE",
+                          "Whether to issue deprecation warnings for"
+                          " macros and functions.",
+                          cmState::BOOL);
+      this->AddCacheEntry("CMAKE_ERROR_DEPRECATED", "FALSE",
+                          "Whether to issue deprecation errors for macros"
+                          " and functions.",
+                          cmState::BOOL);
+      }
+    else if (warningLevel == ERROR_LEVEL)
+      {
+      this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE",
+                          "Whether to issue deprecation warnings for"
+                          " macros and functions.",
+                          cmState::BOOL);
+      this->AddCacheEntry("CMAKE_ERROR_DEPRECATED", "TRUE",
+                          "Whether to issue deprecation errors for macros"
+                          " and functions.",
+                          cmState::BOOL);
+      }
+    }
+
+  if (this->WarningLevels.count("dev") == 1)
+    {
+    bool setDeprecatedVariables = false;
+
+    const char* cachedWarnDeprecated =
+           this->State->GetCacheEntryValue("CMAKE_WARN_DEPRECATED");
+    const char* cachedErrorDeprecated =
+           this->State->GetCacheEntryValue("CMAKE_ERROR_DEPRECATED");
+
+    // don't overwrite deprecated warning setting from a previous invocation
+    if (!cachedWarnDeprecated && !cachedErrorDeprecated)
+      {
+      setDeprecatedVariables = true;
+      }
+
+    warningLevel = this->WarningLevels["dev"];
+    if (warningLevel == IGNORE_LEVEL)
+      {
+      this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "TRUE",
+                          "Suppress Warnings that are meant for"
+                          " the author of the CMakeLists.txt files.",
+                          cmState::INTERNAL);
+      this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_ERRORS", "TRUE",
+                          "Suppress errors that are meant for"
+                          " the author of the CMakeLists.txt files.",
+                          cmState::INTERNAL);
+
+      if (setDeprecatedVariables)
+        {
+        this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE",
+                            "Whether to issue deprecation warnings for"
+                            " macros and functions.",
+                            cmState::BOOL);
+        this->AddCacheEntry("CMAKE_ERROR_DEPRECATED", "FALSE",
+                            "Whether to issue deprecation errors for macros"
+                            " and functions.",
+                            cmState::BOOL);
+        }
+      }
+    else if (warningLevel == WARNING_LEVEL)
       {
-      this->
-        AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "FALSE",
-                      "Suppress Warnings that are meant for"
-                      " the author of the CMakeLists.txt files.",
-                      cmState::INTERNAL);
+      this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "FALSE",
+                          "Suppress Warnings that are meant for"
+                          " the author of the CMakeLists.txt files.",
+                          cmState::INTERNAL);
+      this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_ERRORS", "TRUE",
+                          "Suppress errors that are meant for"
+                          " the author of the CMakeLists.txt files.",
+                          cmState::INTERNAL);
+
+      if (setDeprecatedVariables)
+        {
+        this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE",
+                            "Whether to issue deprecation warnings for"
+                            " macros and functions.",
+                            cmState::BOOL);
+        this->AddCacheEntry("CMAKE_ERROR_DEPRECATED", "FALSE",
+                            "Whether to issue deprecation errors for macros"
+                            " and functions.",
+                            cmState::BOOL);
+        }
+      }
+    else if (warningLevel == ERROR_LEVEL)
+      {
+      this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "FALSE",
+                          "Suppress Warnings that are meant for"
+                          " the author of the CMakeLists.txt files.",
+                          cmState::INTERNAL);
+      this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_ERRORS", "FALSE",
+                          "Suppress errors that are meant for"
+                          " the author of the CMakeLists.txt files.",
+                          cmState::INTERNAL);
+
+      if (setDeprecatedVariables)
+        {
+        this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE",
+                            "Whether to issue deprecation warnings for"
+                            " macros and functions.",
+                            cmState::BOOL);
+        this->AddCacheEntry("CMAKE_ERROR_DEPRECATED", "TRUE",
+                            "Whether to issue deprecation errors for macros"
+                            " and functions.",
+                            cmState::BOOL);
+        }
       }
     }
+
   int ret = this->ActualConfigure();
   const char* delCacheVars = this->State
                     ->GetGlobalProperty("__CMAKE_DELETE_CACHE_CHANGE_VARS_");
@@ -1539,6 +1696,10 @@ int cmake::Run(const std::vector<std::string>& args, bool noconfigure)
     {
     this->AddCMakePaths();
     }
+
+  // turn on author, and in turn deprecated, warnings (only) by default
+  this->WarningLevels["dev"] = WARNING_LEVEL;
+
   // Add any cache args
   if ( !this->SetCacheArgs(args) )
     {
@@ -2462,26 +2623,57 @@ bool cmake::PrintMessagePreamble(cmake::MessageType t, std::ostream& msg)
   else if(t == cmake::DEPRECATION_ERROR)
     {
     msg << "CMake Deprecation Error";
+
+    // if CMAKE_ERROR_DEPRECATED is on, show the message, otherwise suppress it
+    const char* errorDeprecated = this->State->GetCacheEntryValue(
+                                                "CMAKE_ERROR_DEPRECATED");
+    if(cmSystemTools::IsOff(errorDeprecated))
+      {
+      return false;
+      }
     }
   else if (t == cmake::DEPRECATION_WARNING)
     {
     msg << "CMake Deprecation Warning";
+
+    // if CMAKE_WARN_DEPRECATED is on, show the message, otherwise suppress it
+    const char* warnDeprecated = this->State->GetInitializedCacheValue(
+                                            "CMAKE_WARN_DEPRECATED");
+    if(cmSystemTools::IsOff(warnDeprecated))
+      {
+      return false;
+      }
     }
-  else
+  else if (t == cmake::AUTHOR_WARNING)
     {
-    msg << "CMake Warning";
-    if(t == cmake::AUTHOR_WARNING)
+    msg << "CMake Warning (dev)";
+
+    // if CMAKE_SUPPRESS_DEVELOPER_WARNINGS is on, suppress the message,
+    // otherwise show it
+    const char* suppressDevWarnings = this->State->GetCacheEntryValue(
+                                          "CMAKE_SUPPRESS_DEVELOPER_WARNINGS");
+    if(cmSystemTools::IsOn(suppressDevWarnings))
       {
-      // Allow suppression of these warnings.
-      const char* suppress = this->State->GetCacheEntryValue(
-                                        "CMAKE_SUPPRESS_DEVELOPER_WARNINGS");
-      if(suppress && cmSystemTools::IsOn(suppress))
-        {
-        return false;
-        }
-      msg << " (dev)";
+      return false;
       }
     }
+  else if (t == cmake::AUTHOR_ERROR)
+    {
+    msg << "CMake Error (dev)";
+
+    // if CMAKE_SUPPRESS_DEVELOPER_WARNINGS is on, suppress the message,
+    // otherwise show it
+    const char* suppressDevErrors = this->State->GetCacheEntryValue(
+                                          "CMAKE_SUPPRESS_DEVELOPER_ERRORS");
+    if(cmSystemTools::IsOn(suppressDevErrors))
+      {
+      return false;
+      }
+    }
+  else
+    {
+    msg << "CMake Warning";
+    }
   return true;
 }
 
@@ -2502,6 +2694,12 @@ void displayMessage(cmake::MessageType t, std::ostringstream& msg)
     msg <<
       "This warning is for project developers.  Use -Wno-dev to suppress it.";
     }
+  else if (t == cmake::AUTHOR_ERROR)
+    {
+    msg <<
+      "This error is for project developers. Use -Wno-error=dev to suppress "
+      "it.";
+    }
 
   // Add a terminating blank line.
   msg << "\n";
@@ -2525,7 +2723,8 @@ void displayMessage(cmake::MessageType t, std::ostringstream& msg)
   // Output the message.
   if(t == cmake::FATAL_ERROR
      || t == cmake::INTERNAL_ERROR
-     || t == cmake::DEPRECATION_ERROR)
+     || t == cmake::DEPRECATION_ERROR
+     || t == cmake::AUTHOR_ERROR)
     {
     cmSystemTools::SetErrorOccured();
     cmSystemTools::Message(msg.str().c_str(), "Error");
@@ -2557,6 +2756,11 @@ void cmake::IssueMessage(cmake::MessageType t, std::string const& text,
   backtrace.PrintCallStack(msg);
 
   displayMessage(t, msg);
+
+  if (t == cmake::DEPRECATION_ERROR || t == cmake::AUTHOR_ERROR)
+    {
+    cmSystemTools::SetFatalErrorOccured();
+    }
 }
 
 //----------------------------------------------------------------------------
@@ -2722,3 +2926,18 @@ void cmake::RunCheckForUnusedVariables()
     }
 #endif
 }
+
+void cmake::SetSuppressDevWarnings(bool b)
+{
+  // equivalent to -Wno-dev
+  if (b)
+    {
+    this->WarningLevels["dev"] = IGNORE_LEVEL;
+    }
+  // equivalent to -Wdev
+  else
+    {
+    this->WarningLevels["dev"] = std::max(this->WarningLevels["dev"],
+                                          WARNING_LEVEL);
+    }
+}
diff --git a/Source/cmake.h b/Source/cmake.h
index 9d28cba..8ac8897 100644
--- a/Source/cmake.h
+++ b/Source/cmake.h
@@ -59,6 +59,7 @@ class cmake
  public:
   enum MessageType
   { AUTHOR_WARNING,
+    AUTHOR_ERROR,
     FATAL_ERROR,
     INTERNAL_ERROR,
     MESSAGE,
@@ -68,6 +69,12 @@ class cmake
     DEPRECATION_WARNING
   };
 
+  enum WarningLevel
+  {
+    IGNORE_LEVEL,
+    WARNING_LEVEL,
+    ERROR_LEVEL
+  };
 
   /** \brief Describes the working modes of cmake */
   enum WorkingMode
@@ -271,6 +278,7 @@ class cmake
   void SetTrace(bool b) {  this->Trace = b;}
   bool GetTraceExpand() { return this->TraceExpand;}
   void SetTraceExpand(bool b) {  this->TraceExpand = b;}
+  void SetSuppressDevWarnings(bool b);
   bool GetWarnUninitialized() { return this->WarnUninitialized;}
   void SetWarnUninitialized(bool b) {  this->WarnUninitialized = b;}
   bool GetWarnUnused() { return this->WarnUnused;}
@@ -291,12 +299,6 @@ class cmake
   std::string const& GetCMakeEditCommand() const
     { return this->CMakeEditCommand; }
 
-  void SetSuppressDevWarnings(bool v)
-    {
-      this->SuppressDevWarnings = v;
-      this->DoSuppressDevWarnings = true;
-    }
-
   /** Display a message to the user.  */
   void IssueMessage(cmake::MessageType t, std::string const& text,
         cmListFileBacktrace const& backtrace = cmListFileBacktrace());
@@ -339,8 +341,7 @@ protected:
 
   cmGlobalGenerator *GlobalGenerator;
   cmCacheManager *CacheManager;
-  bool SuppressDevWarnings;
-  bool DoSuppressDevWarnings;
+  std::map<std::string, WarningLevel> WarningLevels;
   std::string GeneratorPlatform;
   std::string GeneratorToolset;
 
@@ -416,7 +417,15 @@ private:
   {"-T <toolset-name>", "Specify toolset name if supported by generator."}, \
   {"-A <platform-name>", "Specify platform name if supported by generator."}, \
   {"-Wno-dev", "Suppress developer warnings."},\
-  {"-Wdev", "Enable developer warnings."}
+  {"-Wdev", "Enable developer warnings."},\
+  {"-Werror=dev", "Make developer warnings errors."},\
+  {"-Wno-error=dev", "Make developer warnings not errors."},\
+  {"-Wdeprecated", "Enable deprecated macro and function warnings."},\
+  {"-Wno-deprecated", "Suppress deprecated macro and function warnings."},\
+  {"-Werror=deprecated", "Make deprecated macro and function warnings " \
+                         "errors."},\
+  {"-Wno-error=deprecated", "Make deprecated macro and function warnings " \
+                            "not errors."}
 
 #define FOR_EACH_C_FEATURE(F) \
   F(c_function_prototypes) \
diff --git a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
index 2d94e29..dc706e2 100644
--- a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
+++ b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
@@ -129,10 +129,67 @@ set(RunCMake_TEST_OPTIONS -Wno-dev)
 run_cmake(Wno-dev)
 unset(RunCMake_TEST_OPTIONS)
 
-set(RunCMake_TEST_OPTIONS -Wno-dev -Wdev)
+set(RunCMake_TEST_OPTIONS -Wdev)
 run_cmake(Wdev)
 unset(RunCMake_TEST_OPTIONS)
 
+set(RunCMake_TEST_OPTIONS -Werror=dev)
+run_cmake(Werror_dev)
+unset(RunCMake_TEST_OPTIONS)
+
+set(RunCMake_TEST_OPTIONS -Wno-error=dev)
+run_cmake(Wno-error_dev)
+unset(RunCMake_TEST_OPTIONS)
+
+# -Wdev should not override deprecated options if specified
+set(RunCMake_TEST_OPTIONS -Wdev -Wno-deprecated)
+run_cmake(Wno-deprecated)
+unset(RunCMake_TEST_OPTIONS)
+set(RunCMake_TEST_OPTIONS -Wno-deprecated -Wdev)
+run_cmake(Wno-deprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+# -Wdev should enable deprecated warnings as well
+set(RunCMake_TEST_OPTIONS -Wdev)
+run_cmake(Wdeprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+# -Werror=dev should enable deprecated errors as well
+set(RunCMake_TEST_OPTIONS -Werror=dev)
+run_cmake(Werror_deprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+set(RunCMake_TEST_OPTIONS -Wdeprecated)
+run_cmake(Wdeprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+set(RunCMake_TEST_OPTIONS -Wno-deprecated)
+run_cmake(Wno-deprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+set(RunCMake_TEST_OPTIONS -Werror=deprecated)
+run_cmake(Werror_deprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+set(RunCMake_TEST_OPTIONS -Wno-error=deprecated)
+run_cmake(Wno-error_deprecated)
+unset(RunCMake_TEST_OPTIONS)
+
+# Dev warnings should be on by default
+run_cmake(Wdev)
+
+# Deprecated warnings should be on by default
+run_cmake(Wdeprecated)
+
+# Conflicting -W options should honor the last value
+set(RunCMake_TEST_OPTIONS -Wdev -Wno-dev)
+run_cmake(Wno-dev)
+unset(RunCMake_TEST_OPTIONS)
+
+run_cmake_command(W_bad-arg1 ${CMAKE_COMMAND} -W)
+run_cmake_command(W_bad-arg2 ${CMAKE_COMMAND} -Wno-)
+run_cmake_command(W_bad-arg3 ${CMAKE_COMMAND} -Werror=)
+
 set(RunCMake_TEST_OPTIONS --debug-output)
 run_cmake(debug-output)
 unset(RunCMake_TEST_OPTIONS)
diff --git a/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt
new file mode 100644
index 0000000..e912728
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt
@@ -0,0 +1,2 @@
+CMake Error: -W must be followed with \[no-\]\[error=\]<name>.
+CMake Error: Problem processing arguments. Aborting.
diff --git a/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt
new file mode 100644
index 0000000..cc643df
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt
@@ -0,0 +1,2 @@
+CMake Error: No warning name provided.
+CMake Error: Problem processing arguments. Aborting.
diff --git a/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt
new file mode 100644
index 0000000..cc643df
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt
@@ -0,0 +1,2 @@
+CMake Error: No warning name provided.
+CMake Error: Problem processing arguments. Aborting.
diff --git a/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt b/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt
new file mode 100644
index 0000000..e9be1dc
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt
@@ -0,0 +1,4 @@
+^CMake Deprecation Warning at Wdeprecated.cmake:1 \(message\):
+  Some deprecated warning
+Call Stack \(most recent call first\):
+  CMakeLists.txt:3 \(include\)
diff --git a/Tests/RunCMake/CommandLine/Wdeprecated.cmake b/Tests/RunCMake/CommandLine/Wdeprecated.cmake
new file mode 100644
index 0000000..3142b42
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wdeprecated.cmake
@@ -0,0 +1 @@
+message(DEPRECATION "Some deprecated warning")
diff --git a/Tests/RunCMake/CommandLine/Wdev-stderr.txt b/Tests/RunCMake/CommandLine/Wdev-stderr.txt
index 92c1d23..88cfb3a 100644
--- a/Tests/RunCMake/CommandLine/Wdev-stderr.txt
+++ b/Tests/RunCMake/CommandLine/Wdev-stderr.txt
@@ -1,5 +1,5 @@
 ^CMake Warning \(dev\) at Wdev.cmake:1 \(message\):
-  Some Author Warning
+  Some author warning
 Call Stack \(most recent call first\):
   CMakeLists.txt:3 \(include\)
 This warning is for project developers.  Use -Wno-dev to suppress it.
diff --git a/Tests/RunCMake/CommandLine/Wdev.cmake b/Tests/RunCMake/CommandLine/Wdev.cmake
index e5026ef..756f31e 100644
--- a/Tests/RunCMake/CommandLine/Wdev.cmake
+++ b/Tests/RunCMake/CommandLine/Wdev.cmake
@@ -1,4 +1,4 @@
-message(AUTHOR_WARNING "Some Author Warning")
+message(AUTHOR_WARNING "Some author warning")
 
 # with -Wdev this will also cause an AUTHOR_WARNING message, checks that
 # messages issued outside of the message command, by other CMake commands, also
diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt b/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt b/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt
new file mode 100644
index 0000000..6acdc73
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt
@@ -0,0 +1,4 @@
+^CMake Deprecation Error at Werror_deprecated.cmake:1 \(message\):
+  Some deprecated warning
+Call Stack \(most recent call first\):
+  CMakeLists.txt:3 \(include\)
diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated.cmake b/Tests/RunCMake/CommandLine/Werror_deprecated.cmake
new file mode 100644
index 0000000..3142b42
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Werror_deprecated.cmake
@@ -0,0 +1 @@
+message(DEPRECATION "Some deprecated warning")
diff --git a/Tests/RunCMake/CommandLine/Werror_dev-result.txt b/Tests/RunCMake/CommandLine/Werror_dev-result.txt
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Werror_dev-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/Werror_dev-stderr.txt b/Tests/RunCMake/CommandLine/Werror_dev-stderr.txt
new file mode 100644
index 0000000..c6b4e74
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Werror_dev-stderr.txt
@@ -0,0 +1,5 @@
+^CMake Error \(dev\) at Werror_dev.cmake:1 \(message\):
+  Some author warning
+Call Stack \(most recent call first\):
+  CMakeLists.txt:3 \(include\)
+This error is for project developers. Use -Wno-error=dev to suppress it.$
diff --git a/Tests/RunCMake/CommandLine/Werror_dev.cmake b/Tests/RunCMake/CommandLine/Werror_dev.cmake
new file mode 100644
index 0000000..e05cf9d
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Werror_dev.cmake
@@ -0,0 +1 @@
+message(AUTHOR_WARNING "Some author warning")
diff --git a/Tests/RunCMake/CommandLine/Wno-deprecated.cmake b/Tests/RunCMake/CommandLine/Wno-deprecated.cmake
new file mode 100644
index 0000000..3142b42
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wno-deprecated.cmake
@@ -0,0 +1 @@
+message(DEPRECATION "Some deprecated warning")
diff --git a/Tests/RunCMake/CommandLine/Wno-dev.cmake b/Tests/RunCMake/CommandLine/Wno-dev.cmake
index d81b858..802b435 100644
--- a/Tests/RunCMake/CommandLine/Wno-dev.cmake
+++ b/Tests/RunCMake/CommandLine/Wno-dev.cmake
@@ -1,4 +1,4 @@
-message(AUTHOR_WARNING "Some Author Warning")
+message(AUTHOR_WARNING "Some author warning")
 
 # without -Wno-dev this will also cause an AUTHOR_WARNING message, checks that
 # messages issued outside of the message command, by other CMake commands, also
diff --git a/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake b/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake
new file mode 100644
index 0000000..676792a
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake
@@ -0,0 +1,2 @@
+# This should still produce a warning when -Wno-error=deprecated is specified
+message(DEPRECATION "Some deprecated warning")
diff --git a/Tests/RunCMake/CommandLine/Wno-error_dev.cmake b/Tests/RunCMake/CommandLine/Wno-error_dev.cmake
new file mode 100644
index 0000000..d43e4ed
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wno-error_dev.cmake
@@ -0,0 +1,2 @@
+# This should still produce a warning when -Wno-error=dev is specified
+message(AUTHOR_WARNING "Some author warning")
-- 
2.1.4


From ruslan_baratov at yahoo.com  Sun Oct 25 10:34:57 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Sun, 25 Oct 2015 20:34:57 +0600
Subject: [cmake-developers] Patch: install universal iOS libraries
In-Reply-To: <562A9EE4.6080405@googlemail.com>
References: <5603CC15.5070201@yahoo.com> <561524AF.4070509@googlemail.com>
 <5615BAAC.4040202@yahoo.com> <562A9EE4.6080405@googlemail.com>
Message-ID: <562CE891.4060209@yahoo.com>

On 24-Oct-15 02:56, Gregor Jasny wrote:
> On 08/10/15 02:37, Ruslan Baratov wrote:
>>>> export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
>>>> export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
>>>> export SDK_NAME=iphonesimulator9.0
>>> Could you use those variables to avoid hardcoding iphoneos/simulator in
>>> the module?
>> I see CORRESPONDING_*_SDK_NAME variables in Xcode 7.0 but not in 6.4.
> At least in Xcode 6.2 I the following variable defined:
> SUPPORTED_PLATFORMS="iphonesimulator iphoneos"
>
> It also seems to be set with Xcode 7.1
> SUPPORTED_PLATFORMS="watchsimulator watchos"
> SUPPORTED_PLATFORMS="appletvos appletvsimulator"
Implemented. Now module use environment variables PLATFORM_NAME and 
SUPPORTED_PLATFORMS to determine current SDK and corresponding SDK.

> Same for the architectures: In the end the user (or the Xcode default)
> sets a list of VALID_ARCHS for device and simulator. Maybe you could use
> this for filtering.
Just for the record hardcoded architectures was already removed by 
previous patch. Also I think we can't use VALID_ARCHS value since it's 
possible to have more architectures in installed library (`lipo -info` 
used for now).

Ruslo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Get-target-name-for-universal-iOS-library-install.patch
Type: text/x-patch
Size: 2610 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151025/4829f4c8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Make-module-for-universal-iOS-library-install.patch
Type: text/x-patch
Size: 11686 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151025/4829f4c8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Universal-iOS-library-install.patch
Type: text/x-patch
Size: 2833 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151025/4829f4c8/attachment-0002.bin>

From mantis at public.kitware.com  Sun Oct 25 22:24:41 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sun, 25 Oct 2015 22:24:41 -0400
Subject: [cmake-developers] [CMake 0015808]: POST_BUILD command for "Visual
	Studio 14 2015" generates superfluous "C:"
Message-ID: <0805af6e41a76e1d4bb65f2523acb219@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15808 
====================================================================== 
Reported By:                ovz
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15808
Category:                   CMake
Reproducibility:            always
Severity:                   block
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2015-10-25 22:24 EDT
Last Modified:              2015-10-25 22:24 EDT
====================================================================== 
Summary:                    POST_BUILD command for "Visual Studio 14 2015"
generates superfluous "C:"
Description: 
If I specify WORKING_DIRECTORY in add_custom_command(... POST_BUILD ..) the
following snippet is generated in Post-Build event code. Note that extra command
specifying just "C:" after expected cd command. 

setlocal
cd C:\__temp\src\cmake\post_build_work_dir\build\working_dir
if %errorlevel% neq 0 goto :cmEnd
C:
if %errorlevel% neq 0 goto :cmEnd




Steps to Reproduce: 
* Unpack post_build_work_dir.zip in attachment. 

* You can inspect contents of the build directory. These are CMake generated
files I get on my machine. 

* Clean up build directory

* Run commands

cd build
cmake -G "Visual Studio 14 2015" ..

* Open build/post_build_work_dir.sln

* In Visual Studio right-click on post_build_work_dir project. Select Properties

* Navigate to Configuration Properties > Build Events > Post-Build Event

* Note the extra "C:" command in the post-build event text





Additional Information: 
Here is full text of Post-Build event generated after following steps of
reproduction

setlocal
cd C:\__temp\src\cmake\post_build_work_dir\build\working_dir
if %errorlevel% neq 0 goto :cmEnd
C:
if %errorlevel% neq 0 goto :cmEnd
some_command
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-25 22:24 ovz            New Issue                                    
2015-10-25 22:24 ovz            File Added: post_build_work_dir.zip             
      
======================================================================


From marc.chevrier at sap.com  Mon Oct 26 09:22:14 2015
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Mon, 26 Oct 2015 13:22:14 +0000
Subject: [cmake-developers] [PATCH][CMAKE] C sources must use C Style
	comments
Message-ID: <FB509EF8-6353-4E7C-9993-110DF99E1A0A@sap.com>


Hi,

Attached is a small patch ensuring that c source is compiling even if C compiler (AIX xlc for example) does not support C++ Style comments.

Marc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151026/b08282d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-C-Style-comments-in-C-sources.patch
Type: application/octet-stream
Size: 929 bytes
Desc: 0001-Use-C-Style-comments-in-C-sources.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151026/b08282d5/attachment.obj>

From mantis at public.kitware.com  Mon Oct 26 11:54:00 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 26 Oct 2015 11:54:00 -0400
Subject: [cmake-developers] [CMake 0015809]: MSVC_VERSION is wrong
Message-ID: <dfdedbf2aa37e40de8bae9262a2be7e5@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15809 
====================================================================== 
Reported By:                Nuno
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15809
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-26 11:54 EDT
Last Modified:              2015-10-26 11:54 EDT
====================================================================== 
Summary:                    MSVC_VERSION is wrong
Description: 
In my setup I have installed VS 2010 through VS 2015 (except VS2012) and for
some reason when using the VS 2015 command line and the NMake generator the
value of MSVC_VERSION comes as 1800 instead of 1900. 

Also I have Intel Fortran 2013 and 2016 installed.

I have traced this issue to the file "Modules/Platform/windows-MSVC.cmake"
around line 62 where the variable MSVC_VERSION is set. 
The IF() statements fail except the Fortran one. And on that one
CMAKE_Fortran_SIMULATE_VERSION has a value of 18.0 and then this value is used.

It seems that this comes from Modules/CMakeFortranCompilerId.F.in.
I suggest that the Modules/CMakeFortranCompilerId.F.in gets updated. There is an
if statement where it checks for _MSC_VER >= 1800. The check for _MSC_VER >=
1900 should be added here for Visual Studio 2015 full support.

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-26 11:54 Nuno           New Issue                                    
======================================================================


From Joakim.Andersson at nordicsemi.no  Mon Oct 26 12:38:49 2015
From: Joakim.Andersson at nordicsemi.no (Andersson, Joakim)
Date: Mon, 26 Oct 2015 16:38:49 +0000
Subject: [cmake-developers] ARMCC toolchain support
Message-ID: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>

Hi.

Sorry, forgot to add the actual patch, here it is.
Attached is a patch that adds support for the ARMCC toolchain.

-Joakim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151026/eed6b029/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-ARMCC-toolchain-support.patch
Type: application/octet-stream
Size: 5783 bytes
Desc: 0001-Add-ARMCC-toolchain-support.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151026/eed6b029/attachment.obj>

From Joakim.Andersson at nordicsemi.no  Mon Oct 26 12:34:56 2015
From: Joakim.Andersson at nordicsemi.no (Andersson, Joakim)
Date: Mon, 26 Oct 2015 16:34:56 +0000
Subject: [cmake-developers] ARMCC toolchain support
Message-ID: <7B3613F124A9F94D99A4669BF47D619CAC71E866@mbx04.nvlsi.no>

Hi.

Attached is a patch that adds support for the ARMCC toolchain.

-Joakim

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

From taylor at braun-jones.org  Mon Oct 26 22:53:19 2015
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Mon, 26 Oct 2015 22:53:19 -0400
Subject: [cmake-developers] RFC: CMake precompiled header support and
 custom compiler based implementation
In-Reply-To: <CANZMcXrbbGaoRcLQDLXWC34u-2Z_w=XHZjfxAA67onMpqDeO6g@mail.gmail.com>
References: <A5D470F9-76AD-4758-AD48-582BC4B01FCC@java.pl>
 <20150302010209.GC17534@bronto-burt.dev.benboeckel.net>
 <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com>
 <CANZMcXqXzBq4Z05C_R1XZsHRs_evS7DYUJhDKBwou_jeF1qUtQ@mail.gmail.com>
 <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org>
 <CANZMcXrbbGaoRcLQDLXWC34u-2Z_w=XHZjfxAA67onMpqDeO6g@mail.gmail.com>
Message-ID: <CAKfKJYuR=CjkMFTCJhjw761-4_BfY=EbG-iTcRjGzuT9te5=gQ@mail.gmail.com>

What's the status of this PCH feature? Does it need testers? More design
input? I'd love to see this feature in a future CMake release. Willing to
help.

Cheers,
Taylor

On Fri, Mar 20, 2015 at 3:56 PM, Daniel Pfeifer <daniel at pfeifer-mail.de>
wrote:

> On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi <amine.khaldi at reactos.org>
> wrote:
> > Two requests please:
> >
> > * The option to use existing headers instead of autogenerated ones.
>
> That is an implementation detail. It should not make a difference
> whether the precompiled header is used through your existing header or
> through an autogenerated header that forward includes your existing
> header. This forward inclusion is important at least for GCC: The
> compiler searches for a .gch file in the same directory as the header
> file. Since we do not want this .gch file to be generated in the
> source directory for out-of-source builds, we need to put the header
> file into the build directory.
>
> Did I misunderstand your request and you meant "use an existing
> *precompiled* header", ie. provide a .pch or .gch file?
> My approach currently does not support that. Please let me know if
> that is what you meant.
>
> > * Implementing PCH support without additional targets. ReactOS already
> has like 1000+ targets, and we currently use PCH on almost all of them, so
> imagine if this official implementation doubles our targets number.
>
> I completely agree.
>
> One request that I can add:
>
> * It shall be visible in the IDE's settings that precompiled headers are
> used.
>
> Cheers, Daniel
> --
>
> 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/20151026/fca7186b/attachment.html>

From mantis at public.kitware.com  Tue Oct 27 01:29:38 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Oct 2015 01:29:38 -0400
Subject: [cmake-developers] [CMake 0015810]: FindPkgConfig.cmake: error
	returned to the user may be wrong when checking for package
	existence
Message-ID: <70ff8e9dc5a958131d796f242a2edea9@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15810 
====================================================================== 
Reported By:                bchretien
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15810
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-27 01:29 EDT
Last Modified:              2015-10-27 01:29 EDT
====================================================================== 
Summary:                    FindPkgConfig.cmake: error returned to the user may
be wrong when checking for package existence
Description: 
In some cases, CMake returns the following error:

-- Checking for module 'foo'
--   Package 'foo' not found

When the actual error returned by pkg-config is actually:

  Package 'bar', required by 'foo', not found

This seems related to https://cmake.org/Bug/view.php?id=14310, however I did not
have the exact same problem: CMake does stop with an error, just not the correct
one.

Steps to Reproduce: 
I used the same example as in https://cmake.org/Bug/view.php?id=14310

CMakeLists.txt
==============

cmake_minimum_required(VERSION 2.8)
include(FindPkgConfig)
pkg_check_modules(FOO REQUIRED foo)

foo.pc
======

Name: foo
Description: foo
Version: 0

Requires: bar
Cflags: -I/usr/include/foo

Steps
=====

# store both files in a directory
$ PKG_CONFIG_PATH=. cmake .

Expected
========

Failure, explaining that 'foo' was found but `bar` was not.

Current
======

Failure, explaining that 'foo' was not found.

Additional Information: 
I made a patch that solves this issue. Now, the actual error is forwarded to the
user, for instance:

-- Checking for module 'foo'
--   Package 'bar', required by 'foo', not found

For the standard case (i.e. the package was indeed not found), the CMake error
was:

-- Checking for module 'foo'
--   Package 'foo' not found

But with this patch, it now prints:

-- Checking for module 'foo'
--   No package 'foo' found
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-27 01:29 bchretien      New Issue                                    
2015-10-27 01:29 bchretien      File Added:
0001-FindPkgConfig-return-the-actual-error-when-a-package.patch                 
  
======================================================================


From Johannes.Asal at sick.de  Tue Oct 27 04:14:23 2015
From: Johannes.Asal at sick.de (Johannes Asal)
Date: Tue, 27 Oct 2015 09:14:23 +0100
Subject: [cmake-developers] Specifying a VS installation path explicitly
Message-ID: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>

Hi, 

I am trying to build a project using CMake and the VS 2010 generator on a 
buildserver running Jenkins. I want to clear all environment variables on 
the node to make sure that noone can influence builds by installing new 
software and thereby accidentally modifying the environment on the node. 
The problem is that CMake is unable to find Visual Studio (compiler id 
unknown) once I do that. I tried to find out which environment variables 
are needed to make it work but I gave up after 6 hours. There are too many 
and it doesn't make any sense to me why some of them are needed. 

My question is: How do I tell CMake to use a Visual Studio installed in a 
specific path? I know where it is installed on the buildserver so I just 
want to use that path instead of the complicated search routine which has 
so many environment dependencies. I tried setting CMAKE_MAKE_PROGRAM to 
the full MSBuild path but it didn't work. A Google search did not yield 
any results. 

Thanks a lot. 
- Johannes
Mit freundlichen Gr??en / Best regards

Johannes Asal
Entwicklungsingenieur Software | Identification & Measuring
Research & Development

SICK AG | Nimburger Str. 11 | 79276 Reute | Germany
Phone  +49 7641 469-1460 | Fax  | mailto:Johannes.Asal at sick.de | http://www.sick.de

SICK AG  |  Sitz: Waldkirch i. Br.  |  Handelsregister: Freiburg i. Br. HRB 
280355 
Vorstand: Dr. Robert Bauer (Vorsitzender)  |  Reinhard B?sl  |  Dr. Mats 
G?kstorp  |  Dr. Martin Kr?mer  |  Markus Vatter
Aufsichtsrat: Gisela Sick (Ehrenvorsitzende)  |  Klaus M. Bukenberger 
(Vorsitzender)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/1af2ff87/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/1af2ff87/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/1af2ff87/attachment-0001.jpe>

From brad.king at kitware.com  Tue Oct 27 09:14:21 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 09:14:21 -0400
Subject: [cmake-developers] use-correct-rcc-command-option topic
Message-ID: <562F78AD.40603@kitware.com>

Steve,

In regard to:

 Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1 (#15644)"
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08147a9a

The proper fix is to detect whether rcc supports --list or -list and user
the preferred one based on the version available, not to revert to the
broken state.  I will not merge the topic as-is.

-Brad

From brad.king at kitware.com  Tue Oct 27 09:14:27 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 09:14:27 -0400
Subject: [cmake-developers] [PATCH][CMAKE] C sources must use C Style
 comments
In-Reply-To: <FB509EF8-6353-4E7C-9993-110DF99E1A0A@sap.com>
References: <FB509EF8-6353-4E7C-9993-110DF99E1A0A@sap.com>
Message-ID: <562F78B3.2040100@kitware.com>

On 10/26/2015 09:22 AM, CHEVRIER, Marc wrote:
> Attached is a small patch ensuring that c source is compiling
> even if C compiler (AIX xlc for example) does not support
> C++ Style comments.

Wow, that's slipped through for 12 years.  Thanks:

 CheckForPthreads.c: Do not use C++-style comments in C source
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e166203f

-Brad


From brad.king at kitware.com  Tue Oct 27 09:27:59 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 09:27:59 -0400
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
Message-ID: <562F7BDF.3040606@kitware.com>

On 10/26/2015 12:38 PM, Andersson, Joakim wrote:
> Attached is a patch that adds support for the ARMCC toolchain.

Thanks.  It looks good except that I'd like to discuss of compiler id.
The name "ARMCC" appears to refer to the "armcc" command-line tool.
Our convention for the compiler id is to refer to the vendor or maintaining
organization behind the compiler.  Help/variable/CMAKE_LANG_COMPILER_ID.rst
lists the associated vendors and should be updated for this too.

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct 27 09:37:13 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 09:37:13 -0400
Subject: [cmake-developers] Specifying a VS installation path explicitly
In-Reply-To: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
Message-ID: <562F7E09.3050004@kitware.com>

On 10/27/2015 04:14 AM, Johannes Asal wrote:
> How do I tell CMake to use a Visual Studio installed in a specific path?

IIRC CMake uses Windows Registry entries to locate VS components.
I do not think we have any way to customize this.

-Brad


From brad.king at kitware.com  Tue Oct 27 09:42:16 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 09:42:16 -0400
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <562B4579.5060905@gmail.com>
References: <5628F159.3040400@kitware.com> <562B4579.5060905@gmail.com>
Message-ID: <562F7F38.2040907@kitware.com>

On 10/24/2015 04:46 AM, Michael Scott wrote:
> I've made the first set of changes,  to reapply the series of previous 
> changes for the -W options, along with some tweaks to improve the 
> implementation and some additional tests for the changes.

Thanks.  I see some hunks, including these:

> +``-Werror=dev``
> + Make developer warnings errors.
[snip]
> -    type = cmake::AUTHOR_WARNING;
> +    if (!this->Makefile->IsOn("CMAKE_SUPPRESS_DEVELOPER_ERRORS"))
> +      {
> +      fatal = true;
> +      type = cmake::AUTHOR_ERROR;
> +      }
> +    else if (!this->Makefile->IsOn("CMAKE_SUPPRESS_DEVELOPER_WARNINGS"))
> +      {
> +      type = cmake::AUTHOR_WARNING;
> +      }
> +    else
> +      {
> +      return true;
> +      }

that appear to be related to warning=>error upgrade options.
Didn't we just decide to not tackle this part yet?

-Brad

From Johannes.Asal at sick.de  Tue Oct 27 10:38:47 2015
From: Johannes.Asal at sick.de (Johannes Asal)
Date: Tue, 27 Oct 2015 15:38:47 +0100
Subject: [cmake-developers] Specifying a VS installation path explicitly
In-Reply-To: <562F7E09.3050004@kitware.com>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
 <562F7E09.3050004@kitware.com>
Message-ID: <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>

If it was actually using registry entries only for locating the VS 
installations it would be perfectly fine with me. But my observations 
indicate that it depends on environment variables as well. Could you point 
me to where that logic is implemented in the source code or the CMake 
modules?
Mit freundlichen Gr??en / Best regards

Johannes Asal
Entwicklungsingenieur Software | Identification & Measuring
Research & Development

SICK AG | Nimburger Str. 11 | 79276 Reute | Germany
Phone  +49 7641 469-1460 | Fax  | mailto:Johannes.Asal at sick.de | http://www.sick.de

SICK AG  |  Sitz: Waldkirch i. Br.  |  Handelsregister: Freiburg i. Br. HRB 
280355 
Vorstand: Dr. Robert Bauer (Vorsitzender)  |  Reinhard B?sl  |  Dr. Mats 
G?kstorp  |  Dr. Martin Kr?mer  |  Markus Vatter
Aufsichtsrat: Gisela Sick (Ehrenvorsitzende)  |  Klaus M. Bukenberger 
(Vorsitzender)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/4cc17ef5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/4cc17ef5/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/4cc17ef5/attachment-0001.jpe>

From brad.king at kitware.com  Tue Oct 27 11:03:27 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 11:03:27 -0400
Subject: [cmake-developers] Specifying a VS installation path explicitly
In-Reply-To: <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
 <562F7E09.3050004@kitware.com>
 <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
Message-ID: <562F923F.4070707@kitware.com>

On 10/27/2015 10:38 AM, Johannes Asal wrote:
> it depends on environment variables as well. Could you point me to
> where that logic is implemented in the source code or the CMake modules?

Please create a build tree under the environment in question and send me
(off list) a .zip file of what CMake puts in the build tree.  Just use
a simple CMakeLists.txt file like

 cmake_minimum_required(VERSION 3.3)
 project(TestVS C)

Thanks,
-Brad


From DLRdave at aol.com  Tue Oct 27 12:28:39 2015
From: DLRdave at aol.com (David Cole)
Date: Tue, 27 Oct 2015 12:28:39 -0400
Subject: [cmake-developers] Specifying a VS installation path explicitly
In-Reply-To: <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
 <562F7E09.3050004@kitware.com>
 <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
Message-ID: <CAKME8fFik4A7+Gu_CYMpGiRMmpOEcePg7iV3NURtKVRS7up1WQ@mail.gmail.com>

A simple source tree grep for "HKEY" (or even just "HK") will point you to
all the places CMake has registry key references in its source code...



On Tue, Oct 27, 2015 at 10:38 AM, Johannes Asal <Johannes.Asal at sick.de>
wrote:

> If it was actually using registry entries only for locating the VS
> installations it would be perfectly fine with me. But my observations
> indicate that it depends on environment variables as well. Could you point
> me to where that logic is implemented in the source code or the CMake
> modules?
>
> Mit freundlichen Gr??en / Best regards
>
> Johannes Asal
> Entwicklungsingenieur Software  |   Identification & Measuring Research &
> Development
>
>
>
> SICK AG  |  Nimburger Str. 11  |  79276 Reute  |  Germany
> Phone +49 7641 469-1460  |  Johannes.Asal at sick.de  |  http://www.sick.de
>
>
>
> SICK AG  |   Sitz: Waldkirch i. Br.  |   Handelsregister: Freiburg i. Br.
> HRB 280355
> Vorstand: Dr. Robert Bauer (Vorsitzender)  |  Reinhard B?sl  |  Dr. Mats
> G?kstorp  |  Dr. Martin Kr?mer  |  Markus Vatter
> Aufsichtsrat: Gisela Sick (Ehrenvorsitzende)  |  Klaus M. Bukenberger
> (Vorsitzender)
> --
>
> 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/20151027/e141cc78/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/e141cc78/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/e141cc78/attachment-0001.jpe>

From Joakim.Andersson at nordicsemi.no  Tue Oct 27 12:33:54 2015
From: Joakim.Andersson at nordicsemi.no (Andersson, Joakim)
Date: Tue, 27 Oct 2015 16:33:54 +0000
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <562F7BDF.3040606@kitware.com>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <562F7BDF.3040606@kitware.com>
Message-ID: <7B3613F124A9F94D99A4669BF47D619CAC71FA31@mbx04.nvlsi.no>

So just ARM then?
What about ARMCT (ARM Compiler Toolchain) to differentiate it from the ARM arch.
That's the name they use to refer to ARM compiler 5. The ARM compiler 6 is based on clang and is different again (command line tool is armclang).

-Joakim.

-----Original Message-----
From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King
Sent: 27. oktober 2015 14:28
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] ARMCC toolchain support

On 10/26/2015 12:38 PM, Andersson, Joakim wrote:
> Attached is a patch that adds support for the ARMCC toolchain.

Thanks.  It looks good except that I'd like to discuss of compiler id.
The name "ARMCC" appears to refer to the "armcc" command-line tool.
Our convention for the compiler id is to refer to the vendor or maintaining organization behind the compiler.  Help/variable/CMAKE_LANG_COMPILER_ID.rst
lists the associated vendors and should be updated for this too.

Thanks,
-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 Johannes.Asal at sick.de  Tue Oct 27 12:50:05 2015
From: Johannes.Asal at sick.de (Johannes Asal)
Date: Tue, 27 Oct 2015 17:50:05 +0100
Subject: [cmake-developers] Antwort: Re: Specifying a VS installation path
 explicitly
In-Reply-To: <CAKME8fFik4A7+Gu_CYMpGiRMmpOEcePg7iV3NURtKVRS7up1WQ@mail.gmail.com>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>	<562F7E09.3050004@kitware.com>
 <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
 <CAKME8fFik4A7+Gu_CYMpGiRMmpOEcePg7iV3NURtKVRS7up1WQ@mail.gmail.com>
Message-ID: <OF352A046C.07B2A6B8-ONC1257EEB.005AC046-C1257EEB.005C79D2@sick.de>

Sorry, I think my question wasn't clear enough. I was actually asking for 
the environment variable dependencies. I already found the place where the 
registry keys regarding VS are retrieved, but either the read routines for 
retrieving the registry keys depend on some environment variables or CMake 
is reading them itself which causes it to fail when running with empty 
environment. So let me rephrase the question like this: Are there 
hardcoded environment variable dependencies in CMake's source code that 
you are aware of or is all of the VS compiler identification logic 
implemented in the .cmake module files? In the latter case I could just 
work around my issue by patching these files. Otherwise I'd be out of 
luck.
Mit freundlichen Gr??en / Best regards

Johannes Asal
Entwicklungsingenieur Software | Identification & Measuring
Research & Development

SICK AG | Nimburger Str. 11 | 79276 Reute | Germany
Phone  +49 7641 469-1460 | Fax  | mailto:Johannes.Asal at sick.de | http://www.sick.de

SICK AG  |  Sitz: Waldkirch i. Br.  |  Handelsregister: Freiburg i. Br. HRB 
280355 
Vorstand: Dr. Robert Bauer (Vorsitzender)  |  Reinhard B?sl  |  Dr. Mats 
G?kstorp  |  Dr. Martin Kr?mer  |  Markus Vatter
Aufsichtsrat: Gisela Sick (Ehrenvorsitzende)  |  Klaus M. Bukenberger 
(Vorsitzender)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/6942bb1f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/6942bb1f/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151027/6942bb1f/attachment-0003.jpe>

From brad.king at kitware.com  Tue Oct 27 12:59:28 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 12:59:28 -0400
Subject: [cmake-developers] Antwort: Re: Specifying a VS installation
 path explicitly
In-Reply-To: <OF352A046C.07B2A6B8-ONC1257EEB.005AC046-C1257EEB.005C79D2@sick.de>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>	<562F7E09.3050004@kitware.com>	<OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
 <CAKME8fFik4A7+Gu_CYMpGiRMmpOEcePg7iV3NURtKVRS7up1WQ@mail.gmail.com>
 <OF352A046C.07B2A6B8-ONC1257EEB.005AC046-C1257EEB.005C79D2@sick.de>
Message-ID: <562FAD70.1020009@kitware.com>

On 10/27/2015 12:50 PM, Johannes Asal wrote:
> I was actually asking for the environment variable dependencies.

Actually I do not think the VS 2010 generator actually has any environment
variable dependencies.  It may be that VS itself needs some environment
variables set.  This is why seeing the actual error logs may help.

-Brad


From brad.king at kitware.com  Tue Oct 27 13:00:04 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 13:00:04 -0400
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <7B3613F124A9F94D99A4669BF47D619CAC71FA31@mbx04.nvlsi.no>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <562F7BDF.3040606@kitware.com>
 <7B3613F124A9F94D99A4669BF47D619CAC71FA31@mbx04.nvlsi.no>
Message-ID: <562FAD94.2080606@kitware.com>

On 10/27/2015 12:33 PM, Andersson, Joakim wrote:
> What about ARMCT (ARM Compiler Toolchain) to differentiate it
> from the ARM arch.
> That's the name they use to refer to ARM compiler 5.
> The ARM compiler 6 is based on clang and is different again
> (command line tool is armclang).

That sounds like we need two new compiler ids (even if only one
is implemented by this patch).  Is v5 based on GCC and v6 based
on Clang?  Are they versioned separately from the upstreams?
Perhaps then ARMGNU and ARMClang?

Thanks,
-Brad


From d3ck0r at gmail.com  Tue Oct 27 13:32:44 2015
From: d3ck0r at gmail.com (J Decker)
Date: Tue, 27 Oct 2015 10:32:44 -0700
Subject: [cmake-developers] Antwort: Re: Specifying a VS installation
	path explicitly
In-Reply-To: <562FAD70.1020009@kitware.com>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
 <562F7E09.3050004@kitware.com>
 <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
 <CAKME8fFik4A7+Gu_CYMpGiRMmpOEcePg7iV3NURtKVRS7up1WQ@mail.gmail.com>
 <OF352A046C.07B2A6B8-ONC1257EEB.005AC046-C1257EEB.005C79D2@sick.de>
 <562FAD70.1020009@kitware.com>
Message-ID: <CAA2GJqWux7Lpi9mdHNQ76Z9EJJGd9MA3y+oPiPKpCuXsgV_5Mg@mail.gmail.com>

Actually most of the logic is not in the source but in the modules
~/cmake/modules/platform/Windows-MSVC.cmake

can also use cmake --trace with maybe a simple cmake file to see what
it might use...

On Tue, Oct 27, 2015 at 9:59 AM, Brad King <brad.king at kitware.com> wrote:
> On 10/27/2015 12:50 PM, Johannes Asal wrote:
>> I was actually asking for the environment variable dependencies.
>
> Actually I do not think the VS 2010 generator actually has any environment
> variable dependencies.  It may be that VS itself needs some environment
> variables set.  This is why seeing the actual error logs may help.
>
> -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 steveire at gmail.com  Tue Oct 27 14:45:10 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 27 Oct 2015 19:45:10 +0100
Subject: [cmake-developers] ARMCC toolchain support
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <562F7BDF.3040606@kitware.com>
Message-ID: <n0ognn$oqd$1@ger.gmane.org>

Brad King wrote:

> Our convention for the compiler id is to refer to the vendor or
> maintaining
> organization behind the compiler. 

Is that "MDK" ?

+  set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_ARMCC "MDK-ARM")




From mantis at public.kitware.com  Tue Oct 27 14:45:55 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Oct 2015 14:45:55 -0400
Subject: [cmake-developers] [CMake 0015811]: Add support for resw files for
	Windows RT & Windows Phone platforms
Message-ID: <cf4144c68d8877329367d5362e917037@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15811 
====================================================================== 
Reported By:                Andrew S.
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15811
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-27 14:45 EDT
Last Modified:              2015-10-27 14:45 EDT
====================================================================== 
Summary:                    Add support for resw files for Windows RT & Windows
Phone platforms
Description: 
HI!

I have a problem with Visual Studio generator for resw files (xml files which
are used for app localisation). The generator writes <None ... element for a
resw file instead of <PRIResource ..

Fix is straightforward, see it here:

https://github.com/mad-rain/CMake/commit/afda6af62ad84bc96e1a0bf1d51da73ac94896fe

We have tested it - works just fine for our project.

I hope to see it merge before 3.4.0 release.

Thanks.



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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-27 14:45 Andrew S.      New Issue                                    
======================================================================


From steveire at gmail.com  Tue Oct 27 14:47:14 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 27 Oct 2015 19:47:14 +0100
Subject: [cmake-developers] ARMCC toolchain support
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
Message-ID: <n0ogri$oqd$2@ger.gmane.org>

Andersson, Joakim wrote:

> Hi.
> 
> Sorry, forgot to add the actual patch, here it is.
> Attached is a patch that adds support for the ARMCC toolchain.

I saw this:

+# add the target specific include directory:
+get_filename_component(_compilerDir "${CMAKE_ASM_COMPILER}" PATH)
+get_filename_component(_compilerDir "${_compilerDir}" PATH)
+include_directories("${_compilerDir}/inc" )

and I wondered if that include directory is something that can be determined 
by invoking the compiler, instead of hardcoding it?

Thanks,

Steve.



From steveire at gmail.com  Tue Oct 27 14:55:25 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 27 Oct 2015 19:55:25 +0100
Subject: [cmake-developers] use-correct-rcc-command-option topic
References: <562F78AD.40603@kitware.com>
Message-ID: <n0ohb2$5t6$1@ger.gmane.org>

Brad King wrote:

> Steve,
> 
> In regard to:
> 
>  Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1
>  (#15644)" https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08147a9a
> 
> The proper fix is to detect whether rcc supports --list or -list and user
> the preferred one based on the version available, not to revert to the
> broken state.

I consider CMake 3.4 to be the broken state. The patch reverted in that 
topic removed the use of a documented command line option and added the use 
of an undocumented command line option.

I don't see any reason to add maintenance burden for long-obsolete Qt 
versions to new CMake versions. Maintenance burden in CMake is already far 
beyond reasonable :). Adding conditions which are not tested, and which must 
be maintained in future refactoring is the mistake.

> I will not merge the topic as-is.

That's up to you. I wanted to stick my pin in the map on this as the person 
who wrote the feature :).

Thanks,

Steve.



From gjasny at googlemail.com  Tue Oct 27 14:56:57 2015
From: gjasny at googlemail.com (Gregor Jasny)
Date: Tue, 27 Oct 2015 19:56:57 +0100
Subject: [cmake-developers] Patch: install universal iOS libraries
In-Reply-To: <562CE891.4060209@yahoo.com>
References: <5603CC15.5070201@yahoo.com> <561524AF.4070509@googlemail.com>
 <5615BAAC.4040202@yahoo.com> <562A9EE4.6080405@googlemail.com>
 <562CE891.4060209@yahoo.com>
Message-ID: <562FC8F9.8070405@googlemail.com>

Hello,

I hope to have finished the review by end of this week.

On 25/10/15 15:34, Ruslan Baratov wrote:
> +  set(cmd lipo -info "${filename}")

Minor nitpick: lipo should probably be called via xcrun. Otherwise it
might not know how to handle new architectures.

Thanks,
Gregor

From brad.king at kitware.com  Tue Oct 27 15:00:10 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 15:00:10 -0400
Subject: [cmake-developers] use-correct-rcc-command-option topic
In-Reply-To: <n0ohb2$5t6$1@ger.gmane.org>
References: <562F78AD.40603@kitware.com> <n0ohb2$5t6$1@ger.gmane.org>
Message-ID: <562FC9BA.70508@kitware.com>

On 10/27/2015 02:55 PM, Stephen Kelly wrote:
> I wanted to stick my pin in the map on this as the person 
> who wrote the feature :).

As the person that wrote this feature I expect you to maintain it, please.
It doesn't work with Qt 5.0 and 5.1 without my changes.  Those are supported
versions of Qt.  What is missing is detecting when --list exists to support
newer versions of Qt.  Please implement that.  I've asked 4 times now
(including twice in the original bug report).

-Brad


From mantis at public.kitware.com  Tue Oct 27 15:29:49 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Oct 2015 15:29:49 -0400
Subject: [cmake-developers] [CMake 0015812]: Generator expressions to
	support test properties
Message-ID: <6f9c2a7ad568ece1b3815d8789264d0b@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15812 
====================================================================== 
Reported By:                Chris Green
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15812
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-27 15:29 EDT
Last Modified:              2015-10-27 15:29 EDT
====================================================================== 
Summary:                    Generator expressions to support test properties
Description: 
As part of a function (cet_test()) to define a test, I invoke add_test(), which
invokes a test wrapper script which needs to know the correct return code to use
if requirements are not satisfied for the test. The invoker of the cet_test()
function may set the SKIP_RETURN_CODE property on the test, and I need to be
able to take account of that. If we were talking about target properties, I
could quite happily say $<TARGET_PROPERTY:TGT,PROP> as part of the COMMAND
definition to add_test(). There does not appear to be an analogous
$<TEST_PROPERTY:TST,PROP> I can use to obtain SKIP_RETURN_CODE from the current
test properties.

Steps to Reproduce: 
Use add_test to invoke a COMMAND (echo, say) to which you try to pass the value
of SKIP_RETURN_CODE to the echo command. As of 3.3.2, there is no way that I can
find to do this.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-27 15:29 Chris Green    New Issue                                    
======================================================================


From mantis at public.kitware.com  Tue Oct 27 15:47:43 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Oct 2015 15:47:43 -0400
Subject: [cmake-developers] [CMake 0015813]: add_custom_command(COMMENT)
	force a newline in ninja printout
Message-ID: <d33e352b94377b8143ef6a1551db868b@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15813 
====================================================================== 
Reported By:                Chris Green
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15813
Category:                   CMake
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-27 15:47 EDT
Last Modified:              2015-10-27 15:47 EDT
====================================================================== 
Summary:                    add_custom_command(COMMENT) force a newline in ninja
printout
Description: 
Under normal circumstances (built-in targets and build commands, for instance),
ninja puts out to a terminal a line of the form:

[n/M] <message>

Which is overwritten unless there is output from the command. In the case of a
COMMENT message such as COMMENT "Doing important stuff" to an
add_custom_command, however, a newline at the end of the message is printed
rather than having the next progress message overwrite it.

Steps to Reproduce: 
Add a custom command whose COMMAND produces no output. Attach it to a target
with the ALL option activated and then run CMake with the Ninja generator.
Activate ninja and watch the progress print behavior. Then, add a COMMENT to the
custom command definition and observe the behavior when ninja is rerun.

Additional Information: 
This behavior was observed with ninja 1.6.0.

This behavior has not been tested with add_custom_target(COMMENT ...).
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-27 15:47 Chris Green    New Issue                                    
======================================================================


From steveire at gmail.com  Tue Oct 27 16:06:47 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 27 Oct 2015 21:06:47 +0100
Subject: [cmake-developers] Adding LFS define to build command line?
Message-ID: <n0olgo$9tg$1@ger.gmane.org>


Hi,

The build on AIX at

 https://open.cdash.org/viewBuildError.php?buildid=4072769

failed. The failure was fixed on the minor-cleanups branch. 

Looking at the error, it occurred while compiling the 
cmGeneratorExpressionNode.cxx file because at some points in the translation 
unit, a certain version of lseek64 was used, and at that point, another 
version was used. That happened because preprocessor '#defines' were not 
consistent. 

Removal of the cmMakefile.h include from cmGeneratorExpressionNode.h in the 
commit 'Remove some obsolete declarations' meant that the 
cmStandardIncludes.h file was not included before any other file including 
unistd.h. The cmStandardIncludes.h file includes the cmsys Configure.h file 
which contains particular defines.

Re-ordering the includes in cmGeneratorExpressionEvaluator.h, which is 
included by cmGeneratorExpressionNode.h means that cmStandardIncludes.h is 
included before any platform header.

This class of build breakage has occurred several times that I remember. 
Would it be possible to define the necessary preprocessor defines on the 
command line instead of relying on include order or headers? That would make 
this kind of thing not happen afaict.

Thanks,

Steve.



From steveire at gmail.com  Tue Oct 27 16:25:20 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 27 Oct 2015 21:25:20 +0100
Subject: [cmake-developers] use-correct-rcc-command-option topic
References: <562F78AD.40603@kitware.com> <n0ohb2$5t6$1@ger.gmane.org>
 <562FC9BA.70508@kitware.com>
Message-ID: <n0omjh$se5$1@ger.gmane.org>

Brad King wrote:

> On 10/27/2015 02:55 PM, Stephen Kelly wrote:
>> I wanted to stick my pin in the map on this as the person
>> who wrote the feature :).
> 
> As the person that wrote this feature I expect you to maintain it, please.

My idea of maintaining the feature included not adding conditionals for 
versions of Qt replaced years ago by newer Qt minor releases.

Years ago people used the qt5_add_resources macro, and as far as I'm 
willing/able to put time into, a programmer writing new code in 2015 based 
on Qt 5.1 can do that too.

This seems to be where you want things to be different, but I'm not going to 
test Qt 5.1 or do new work for supporting it :).

I'm also not going to add new automoc support for Qt 3, even though that is 
equally as supported (by upstream and by cmake) as Qt 5.1 is.

I think we understand each other, but we don't agree with each other. So, 
maybe that's the right point to drop this discussion thread :).

Thanks,

Steve.



From brad.king at kitware.com  Tue Oct 27 16:41:08 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 16:41:08 -0400
Subject: [cmake-developers] use-correct-rcc-command-option topic
In-Reply-To: <n0omjh$se5$1@ger.gmane.org>
References: <562F78AD.40603@kitware.com> <n0ohb2$5t6$1@ger.gmane.org>
 <562FC9BA.70508@kitware.com> <n0omjh$se5$1@ger.gmane.org>
Message-ID: <562FE164.2010400@kitware.com>

On 10/27/2015 04:25 PM, Stephen Kelly wrote:
> This seems to be where you want things to be different, but I'm not going to 
> test Qt 5.1 or do new work for supporting it :).

As of 3.4.0-rc2 the new work is to support future versions of Qt that
drop the -list option.  You don't need to test anything with 5.1.

> I think we understand each other, but we don't agree with each other.
> So, maybe that's the right point to drop this discussion thread :).

Well then CMake will break with a future version of Qt until it is
taught to detect support for --list or lack of -list.

I've spent a *huge* amount of time maintaining and updating the AUTORCC
feature since it was added, especially on Windows.  Please don't make
me spend time on this too.

-Brad

From brad.king at kitware.com  Tue Oct 27 16:43:11 2015
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Oct 2015 16:43:11 -0400
Subject: [cmake-developers] Adding LFS define to build command line?
In-Reply-To: <n0olgo$9tg$1@ger.gmane.org>
References: <n0olgo$9tg$1@ger.gmane.org>
Message-ID: <562FE1DF.2080201@kitware.com>

On 10/27/2015 04:06 PM, Stephen Kelly wrote:
> Would it be possible to define the necessary preprocessor defines on the 
> command line instead of relying on include order or headers? That would make 
> this kind of thing not happen afaict.

That would be a nice cleanup but it will require changes to KWSys
which then affect other non-CMake projects.  I have no time for
such maintenance work now.

-Brad


From mantis at public.kitware.com  Tue Oct 27 16:52:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Oct 2015 16:52:07 -0400
Subject: [cmake-developers] [CMake 0015814]: Feature request: Split
	compilation fase on preprocessor
Message-ID: <96fa5b9793b6e8f7b3c4b8ab1f077e8e@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15814 
====================================================================== 
Reported By:                Lagu
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15814
Category:                   (No Category)
Reproducibility:            have not tried
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-27 16:52 EDT
Last Modified:              2015-10-27 16:52 EDT
====================================================================== 
Summary:                    Feature request: Split compilation fase on
preprocessor
Description: 
Hi, here a feature request for optimizations, acutally we use a lot the
preprocessor options, cmake helps a lot with this but actually in the
development have a hight time's consume when we try to test or compile more
times with different options, so if it posible add an option to split the
compilations fase, first compile the project without the preprocessor, and then
compile with the requested options, i found in this page some options to do this
with gcc at least:
http://stackoverflow.com/questions/4049962/can-i-squeez-my-own-program-between-the-preprocessor-and-compiler

i'm very bad explaining this so i'll try to say with way too, first an example,
we have a foo project with a fuu-1 and fuu-2 preprocessor options, so if we want
compile the project we do:

cmake . -Dfuu-1=ON -Dfuu-2=ON

if we need both options, and then we do make and the project is compiled, but if
we want try other like

cmake . -Dfuu-1=ON -Dfuu-2=OFF

the project recompile the files with the modified preprocessor.
So the idea, first compile the project without the preprocessor options, then as
second phase compile with the options, so if we change some option when we use
make the compiler skip the first phase and only compile the preprocessor
options.

sorry my bad eng.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-27 16:52 Lagu           New Issue                                    
======================================================================


From steveire at gmail.com  Tue Oct 27 16:55:50 2015
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 27 Oct 2015 21:55:50 +0100
Subject: [cmake-developers] Adding LFS define to build command line?
References: <n0olgo$9tg$1@ger.gmane.org> <562FE1DF.2080201@kitware.com>
Message-ID: <n0oocn$p3f$1@ger.gmane.org>

Brad King wrote:

> On 10/27/2015 04:06 PM, Stephen Kelly wrote:
>> Would it be possible to define the necessary preprocessor defines on the
>> command line instead of relying on include order or headers? That would
>> make this kind of thing not happen afaict.
> 
> That would be a nice cleanup but it will require changes to KWSys
> which then affect other non-CMake projects.  I have no time for
> such maintenance work now.

Ok. Meanwhile I've squashed your fix into the commit introducing the need 
for it.

Thanks,

Steve.



From mantis at public.kitware.com  Tue Oct 27 17:19:21 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 27 Oct 2015 17:19:21 -0400
Subject: [cmake-developers] [CMake 0015815]: Intel MIC offload library
	creation (xiar option)
Message-ID: <d5083d18a18829f331629c2c3d1333f5@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15815 
====================================================================== 
Reported By:                Chuck Ritter
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15815
Category:                   Modules
Reproducibility:            have not tried
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-27 17:19 EDT
Last Modified:              2015-10-27 17:19 EDT
====================================================================== 
Summary:                    Intel MIC offload library creation (xiar option)
Description: 
Make does not automatically use xiar to create libraries when an Intel compiler
is specified. This can be overcome by setting CMAKE_AR=xiar, but still does not
accommodate creating MIC offload libraries:

https://software.intel.com/en-us/node/522513

Produces host libraries ok, but uses host ar utility.

Steps to Reproduce: 
Tested with Trillions

Additional Information: 
Intel 14.0 compiler (not part of the Composer XE Suite)
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-27 17:19 Chuck Ritter   New Issue                                    
======================================================================


From michael.scott250 at gmail.com  Tue Oct 27 18:59:06 2015
From: michael.scott250 at gmail.com (Michael Scott)
Date: Tue, 27 Oct 2015 22:59:06 +0000
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <562F7F38.2040907@kitware.com>
References: <562F7F38.2040907@kitware.com>
Message-ID: <563001BA.40809@gmail.com>

> that appear to be related to warning=>error upgrade options.
> Didn't we just decide to not tackle this part yet?

They were part of the original patch a while ago, so I left them in when 
I re-applied the proposed patch. Did you want to apply the changes piece 
by piece, or just the review the changes piece by piece? I can tailor 
the proposed patch(s) to suit either I imagine.

I realised that the patch has some somewhat conflicting changes in it, 
in that the cmMessageCommand code checks the Makefile for the variables, 
but the cmake code checks the cache. So when the user say turns on 
deprecated errors in the CMakeLists file, cmMessageCommand sets the 
messages as errors, but then the cmake code suppresses the message. So I 
need to fix that in the subsequent proposed patch(s). I was thinking of 
adding a boolean flag parameter to IssueMessage, default to false, to 
signal the method to not suppress messages based on the state of the 
CMake variables, but there's perhaps better ways to do this.

Cheers,
Michael

From ruslan_baratov at yahoo.com  Tue Oct 27 20:56:11 2015
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 28 Oct 2015 06:56:11 +0600
Subject: [cmake-developers] Patch: install universal iOS libraries
In-Reply-To: <562FC8F9.8070405@googlemail.com>
References: <5603CC15.5070201@yahoo.com> <561524AF.4070509@googlemail.com>
 <5615BAAC.4040202@yahoo.com> <562A9EE4.6080405@googlemail.com>
 <562CE891.4060209@yahoo.com> <562FC8F9.8070405@googlemail.com>
Message-ID: <56301D2B.9090105@yahoo.com>

On 28-Oct-15 00:56, Gregor Jasny wrote:
> Hello,
>
> I hope to have finished the review by end of this week.
>
> On 25/10/15 15:34, Ruslan Baratov wrote:
>> +  set(cmd lipo -info "${filename}")
> Minor nitpick: lipo should probably be called via xcrun. Otherwise it
> might not know how to handle new architectures.
Fixed, rebased patches attached.

Ruslo


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Get-target-name-for-universal-iOS-library-install.patch
Type: text/x-patch
Size: 2610 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151028/45fd4dcf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-CMake-module-for-universal-iOS-library-install.patch
Type: text/x-patch
Size: 12136 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151028/45fd4dcf/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Universal-iOS-library-install.patch
Type: text/x-patch
Size: 2833 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151028/45fd4dcf/attachment-0002.bin>

From daniel at pfeifer-mail.de  Wed Oct 28 04:57:23 2015
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Wed, 28 Oct 2015 09:57:23 +0100
Subject: [cmake-developers] RFC: CMake precompiled header support and
 custom compiler based implementation
In-Reply-To: <CAKfKJYuR=CjkMFTCJhjw761-4_BfY=EbG-iTcRjGzuT9te5=gQ@mail.gmail.com>
References: <A5D470F9-76AD-4758-AD48-582BC4B01FCC@java.pl>
 <20150302010209.GC17534@bronto-burt.dev.benboeckel.net>
 <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl>
 <54F762D3.8080608@kitware.com>
 <CANZMcXqXzBq4Z05C_R1XZsHRs_evS7DYUJhDKBwou_jeF1qUtQ@mail.gmail.com>
 <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org>
 <CANZMcXrbbGaoRcLQDLXWC34u-2Z_w=XHZjfxAA67onMpqDeO6g@mail.gmail.com>
 <CAKfKJYuR=CjkMFTCJhjw761-4_BfY=EbG-iTcRjGzuT9te5=gQ@mail.gmail.com>
Message-ID: <CANZMcXrf3RvFnjJU93p00ZEgHW7n9j9rXXmreNEVGkk9DFTw6Q@mail.gmail.com>

On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones
<taylor at braun-jones.org> wrote:
> What's the status of this PCH feature? Does it need testers? More design
> input? I'd love to see this feature in a future CMake release. Willing to
> help.

I haven't worked on it for quite some time as I currently don't have a
project which needs it.
But I agree that we should get it into CMake, even if it does not
support all generators yet.
Support for additional generators can be added successively.

I will rebase my branch to master on the weekend, ie port it to
cmGeneratorTarget.
Then you are free to help with review, testing, and additional generators.

Which generators are the most important for you?

-- Daniel

> Cheers,
> Taylor
>
> On Fri, Mar 20, 2015 at 3:56 PM, Daniel Pfeifer <daniel at pfeifer-mail.de>
> wrote:
>>
>> On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi <amine.khaldi at reactos.org>
>> wrote:
>> > Two requests please:
>> >
>> > * The option to use existing headers instead of autogenerated ones.
>>
>> That is an implementation detail. It should not make a difference
>> whether the precompiled header is used through your existing header or
>> through an autogenerated header that forward includes your existing
>> header. This forward inclusion is important at least for GCC: The
>> compiler searches for a .gch file in the same directory as the header
>> file. Since we do not want this .gch file to be generated in the
>> source directory for out-of-source builds, we need to put the header
>> file into the build directory.
>>
>> Did I misunderstand your request and you meant "use an existing
>> *precompiled* header", ie. provide a .pch or .gch file?
>> My approach currently does not support that. Please let me know if
>> that is what you meant.
>>
>> > * Implementing PCH support without additional targets. ReactOS already
>> > has like 1000+ targets, and we currently use PCH on almost all of them, so
>> > imagine if this official implementation doubles our targets number.
>>
>> I completely agree.
>>
>> One request that I can add:
>>
>> * It shall be visible in the IDE's settings that precompiled headers are
>> used.
>>
>> Cheers, Daniel
>> --
>>
>> 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 Joakim.Andersson at nordicsemi.no  Wed Oct 28 05:56:01 2015
From: Joakim.Andersson at nordicsemi.no (Andersson, Joakim)
Date: Wed, 28 Oct 2015 09:56:01 +0000
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <n0ogri$oqd$2@ger.gmane.org>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <n0ogri$oqd$2@ger.gmane.org>
Message-ID: <7B3613F124A9F94D99A4669BF47D619CAC71FB30@mbx04.nvlsi.no>

Let's see if we can bring some order to this.

There are two major Software packages that you can get from ARM, the Keil MDK-ARM and the ARM DS-5 Development Studio.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.swdev/index.html
The MDK-ARM comes with ARM Compiler 5 (armcc).
The ARM DS-5 comes with ARM compiler 5 (armcc), ARM Compiler 6 (armclang), and a GCC toolchain (arm-linux-gnueabihf-*).

So this line as actually wrong:
+  set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_ARMCC "MDK-ARM")
because if you invoke the armasm installed with ARM DS-5 it will say "DS-5"
It should be:
+  set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_ARMCC "ARM Compiler 5")

So that means that ARM actually has at least 3 different compilers, and my patches only cover ARM Compiler 5 (armcc). This is the only compiler I have access to and a license for and the only one that is used in my projects.

So in my opinion we either use a single compiler ID for all of the ARM-provided toolchains (something like ARMCT) or we use different compiler IDs per toolchain (ARMC5, ARMC6 and ARMGCC). It's likely that the ARM GCC toolchain doesn't actually require a new ID and may work directly with the current CMake support. ARM Compiler 6 would definitely require further investigation.

This can safely be removed, the toolchain knows about these paths.
+# add the target specific include directory:
+get_filename_component(_compilerDir "${CMAKE_ASM_COMPILER}" PATH)
+get_filename_component(_compilerDir "${_compilerDir}" PATH)
+include_directories("${_compilerDir}/inc" )

-Joakim Andersson

From mantis at public.kitware.com  Wed Oct 28 07:17:10 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 28 Oct 2015 07:17:10 -0400
Subject: [cmake-developers] [CMake 0015816]: When setting CMAKE_OSX_SYSROOT
	to macosx, CPack fails
Message-ID: <44a72141e07489a888040258f60f9099@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15816 
====================================================================== 
Reported By:                Nicolas Fran?ois
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15816
Category:                   CPack
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-28 07:17 EDT
Last Modified:              2015-10-28 07:17 EDT
====================================================================== 
Summary:                    When setting CMAKE_OSX_SYSROOT to macosx, CPack
fails
Description: 
On 10.11.1 and building against deployment target 10.9, the
CMAKE_OSX_DEPLOYMENT_TARGET must be set to 10.9 and so CMAKE_OSX_SYSROOT to
avoid the warning message from CMake.
Setting CMAKE_OSX_SYSROOT to macosx allows to select the latest SDK.
The compilation works and everything is fine.

But CPack fails because of the CPACK_OSX_SYSROOT variable set to
CMAKE_OSX_SYSROOT, hence macosx; instead of being set to _CMAKE_OSX_SYSROOT_PATH
which is the transformed variable in Darwin-Initialize.cmake.

Additional Information: 
Still in 3.4.0-rc2
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-28 07:17 Nicolas Fran?oisNew Issue                                    
======================================================================


From brad.king at kitware.com  Wed Oct 28 08:20:32 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Oct 2015 08:20:32 -0400
Subject: [cmake-developers] Add command line options for deprecation
 message control
In-Reply-To: <563001BA.40809@gmail.com>
References: <562F7F38.2040907@kitware.com> <563001BA.40809@gmail.com>
Message-ID: <5630BD90.3050802@kitware.com>

On 10/27/2015 06:59 PM, Michael Scott wrote:
> They were part of the original patch a while ago, so I left them in when 
> I re-applied the proposed patch. Did you want to apply the changes piece 
> by piece, or just the review the changes piece by piece? I can tailor 
> the proposed patch(s) to suit either I imagine.

The semantic challenges are in the warning=>error conversion so I'd like
to get the other parts reviewed and integrated first.

Thanks,
-Brad


From brad.king at kitware.com  Wed Oct 28 09:10:38 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Oct 2015 09:10:38 -0400
Subject: [cmake-developers] use-correct-rcc-command-option topic
In-Reply-To: <562FE164.2010400@kitware.com>
References: <562F78AD.40603@kitware.com> <n0ohb2$5t6$1@ger.gmane.org>
 <562FC9BA.70508@kitware.com> <n0omjh$se5$1@ger.gmane.org>
 <562FE164.2010400@kitware.com>
Message-ID: <5630C94E.7040700@kitware.com>

On 10/27/2015 04:41 PM, Brad King wrote:
> As of 3.4.0-rc2 the new work is to support future versions of Qt that
> drop the -list option.  You don't need to test anything with 5.1.
> 
> Well then CMake will break with a future version of Qt until it is
> taught to detect support for --list or lack of -list.

Please review these changes.  First we revert hard-coded `-list` in
the 3.4 release branch:

 Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1 (#15644)"
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b935db3a

and in master:

 Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1 (#15644)"
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=10e8ccf6

Then add the detection to get this fixed for 3.5:

 QtAutogen: Fix rcc invocation for Qt 5.0 and 5.1 (#15644)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e78fcc63

-Brad


From brad.king at kitware.com  Wed Oct 28 11:20:22 2015
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Oct 2015 11:20:22 -0400
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <7B3613F124A9F94D99A4669BF47D619CAC71FB30@mbx04.nvlsi.no>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <n0ogri$oqd$2@ger.gmane.org>
 <7B3613F124A9F94D99A4669BF47D619CAC71FB30@mbx04.nvlsi.no>
Message-ID: <5630E7B6.8060406@kitware.com>

On 10/28/2015 05:56 AM, Andersson, Joakim wrote:
> So that means that ARM actually has at least 3 different compilers,

Thank you for the explanation.

> and my patches only cover ARM Compiler 5 (armcc). This is the only
> compiler I have access to and a license for and the only one that
> is used in my projects.

Okay.  We don't need to implement support for any other compiler now,
but I'd like to choose the compiler ids now in case they need to be
distinct.

> So in my opinion we either use a single compiler ID for all of the
> ARM-provided toolchains (something like ARMCT) or we use different
> compiler IDs per toolchain (ARMC5, ARMC6 and ARMGCC).

Each compiler id corresponds to a particular stream of versions of
that compiler along with expectation that particular flags exist.
Given the compiler id one should know what CMAKE_C_COMPILER_VERSION
components mean.  This is why `Clang` and `AppleClang` are different
ids: their version numbers differ.

Currently you're detecting the compiler with:

   /* __ARMCC_VERSION = PVVbbbb */
 # define @PREFIX at COMPILER_VERSION_MAJOR @MACRO_DEC@(__ARMCC_VERSION/1000000)
 # define @PREFIX at COMPILER_VERSION_MINOR @MACRO_DEC@(__ARMCC_VERSION/10000 % 100)
 # define @PREFIX at COMPILER_VERSION_PATCH @MACRO_DEC@(__ARMCC_VERSION     % 10000)")

Do all the compilers define that?  Are they different?  Is there
another preprocessor definition that distinguishes them?  Do they
also define __GNUC__ and/or __clang__?

> It's likely that the ARM GCC toolchain doesn't actually require a
> new ID and may work directly with the current CMake support.

Yes, it is probably fine to identify it as "GNU".  Does it define
the __ARMCC_VERSION macro?

Thanks,
-Brad


From taylor at braun-jones.org  Wed Oct 28 13:09:23 2015
From: taylor at braun-jones.org (Taylor Braun-Jones)
Date: Wed, 28 Oct 2015 13:09:23 -0400
Subject: [cmake-developers] RFC: CMake precompiled header support and
 custom compiler based implementation
In-Reply-To: <CANZMcXrf3RvFnjJU93p00ZEgHW7n9j9rXXmreNEVGkk9DFTw6Q@mail.gmail.com>
References: <A5D470F9-76AD-4758-AD48-582BC4B01FCC@java.pl>
 <20150302010209.GC17534@bronto-burt.dev.benboeckel.net>
 <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com>
 <CANZMcXqXzBq4Z05C_R1XZsHRs_evS7DYUJhDKBwou_jeF1qUtQ@mail.gmail.com>
 <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org>
 <CANZMcXrbbGaoRcLQDLXWC34u-2Z_w=XHZjfxAA67onMpqDeO6g@mail.gmail.com>
 <CAKfKJYuR=CjkMFTCJhjw761-4_BfY=EbG-iTcRjGzuT9te5=gQ@mail.gmail.com>
 <CANZMcXrf3RvFnjJU93p00ZEgHW7n9j9rXXmreNEVGkk9DFTw6Q@mail.gmail.com>
Message-ID: <CAKfKJYumn5a1BGbABt67_X7WuH+WCOXbwKzQS_+FSoN0zO4TPw@mail.gmail.com>

On Wed, Oct 28, 2015 at 4:57 AM, Daniel Pfeifer <daniel at pfeifer-mail.de>
wrote:

> I will rebase my branch to master on the weekend, ie port it to
> cmGeneratorTarget.
> Then you are free to help with review, testing, and additional generators.
>

Great! Just let me know.


> Which generators are the most important for you?
>

For me, generators in order of most important to least are:

Ninja
Unix Makefiles
Visual Studio 12 2013

- Taylor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151028/07a9fdd1/attachment.html>

From mantis at public.kitware.com  Wed Oct 28 18:59:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 28 Oct 2015 15:59:07 -0700
Subject: [cmake-developers] [CMake 0015817]: XCode generated profiles for
	xcode 7.1 gets warning: Turn on "Enable Testability" When Debugging
Message-ID: <c86da9ea4a528def6be1edd9e27a934e@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15817 
====================================================================== 
Reported By:                Laurent Demailly
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15817
Category:                   CMake
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-28 15:59 PDT
Last Modified:              2015-10-28 15:59 PDT
====================================================================== 
Summary:                    XCode generated profiles for xcode 7.1 gets warning:
Turn on "Enable Testability" When Debugging
Description: 
cmake version 3.4.20151028-g2fd5fd

macos 10.10.5

xcode 7.1 (7B91b)


When opening the project you get a warning 'Turn on "Enable Testability" When
Debugging'



Steps to Reproduce: 
cmake version 3.4.20151028-g2fd5fd  (today's git trunk)

macos 10.10.5

xcode 7.1 (7B91b)


cmake ../wdt -G Xcode -DBUILD_TESTING=1

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-28 15:59 Laurent DemaillyNew Issue                                    
======================================================================


From mantis at public.kitware.com  Wed Oct 28 21:53:30 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 28 Oct 2015 21:53:30 -0400
Subject: [cmake-developers] [CMake 0015818]: The variable
	CMAKE_ASM_OUTPUT_EXTENSION is ignored when creating a compiled file
Message-ID: <714a67896400af154ee80081aa0da532@cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
https://cmake.org/Bug/view.php?id=15818 
====================================================================== 
Reported By:                maarten
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15818
Category:                   CMake
Reproducibility:            always
Severity:                   text
Priority:                   low
Status:                     new
====================================================================== 
Date Submitted:             2015-10-28 21:53 EDT
Last Modified:              2015-10-28 21:53 EDT
====================================================================== 
Summary:                    The variable CMAKE_ASM_OUTPUT_EXTENSION is ignored
when creating a compiled file
Description: 
The sdcc compiler has ".asm" extensions for the assembly files.
But cmake always assumes the ".s" extension.
https://github.com/Kitware/CMake/blob/d288b216af6864567354ccb05e85466fb57d46b0/Source/cmMakefileTargetGenerator.cxx#L802-L803

For a source file 'main.c', 'make help' shows the following targets:
... main.rel
... main.i
... main.s

Running 'make main.s' gives the following output:
Compiling C source to assembly CMakeFiles/proj1.dir/main.c.s

But in the CMakeFiles/proj1.dir, there is no 'main.c.s' file.
The generated assembly file is 'main.c.asm'


Steps to Reproduce: 
1) Create toolchain file with:
   - CMAKE_SYSTEM_NAME = Generic
   - CMAKE_ASM_SOURCE_FILE_EXTENSIONS = asm
   - CMAKE_C_C_CREATE_ASSEMBLY_SOURCE = "<CMAKE_C_COMPILER> <DEFINES> <FLAGS> -E
<SOURCE> > <PREPROCESSED_SOURCE>"
   - set CMAKE_C_COMPILER, CMAKE_FIND_ROOT_PATH, ...
2) Create a basic main.c
3) Create CMakeLists.txt, with
   - CMAKE_C_FLAGS = "-Werror --model-small -mmcs51 --opt-code-size"
4) Run CMake to generate the makefiles (using the toolchain)
5) Run "make help" (main.s will show up)
6) Run "make main.s" (main.asm will be created instead of main.s)
7) Run "make main.asm" (An error will be shown)

Additional Information: 
A simple sdcc config is attached.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-28 21:53 maarten        New Issue                                    
======================================================================


From Joakim.Andersson at nordicsemi.no  Thu Oct 29 05:28:43 2015
From: Joakim.Andersson at nordicsemi.no (Andersson, Joakim)
Date: Thu, 29 Oct 2015 09:28:43 +0000
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <5630E7B6.8060406@kitware.com>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <n0ogri$oqd$2@ger.gmane.org>
 <7B3613F124A9F94D99A4669BF47D619CAC71FB30@mbx04.nvlsi.no>
 <5630E7B6.8060406@kitware.com>
Message-ID: <7B3613F124A9F94D99A4669BF47D619CAC71FC5F@mbx04.nvlsi.no>

> Currently you're detecting the compiler with:
> 
>    /* __ARMCC_VERSION = PVVbbbb */
>  # define @PREFIX at COMPILER_VERSION_MAJOR @MACRO_DEC@(__ARMCC_VERSION/1000000)
>  # define @PREFIX at COMPILER_VERSION_MINOR @MACRO_DEC@(__ARMCC_VERSION/10000 % 100)
>  # define @PREFIX at COMPILER_VERSION_PATCH @MACRO_DEC@(__ARMCC_VERSION     % 10000)")
> 
> Do all the compilers define that?  Are they different?  Is there another preprocessor definition that distinguishes them?  Do they also define __GNUC__ and/or > __clang__?
I can't test the armclang defines, so the information I have about those comes from what I can read in its documentation.

armcc defines:
* __ARMCC_VERSION (version)
* __CC_ARM (1)
* __GNUC__ (version) (only if --gnu is passed as a commad line option)

armclang defines:
* __ARMCC_VERSION (version)
* __ARMCOMPILER_VERSION (version)
* __GNUC__ (version)
* Note that it does *not* define __clang__

arm-linux-gnueabihf-gcc defines:
* __GNUC__ (version)

So if we're interested in giving support only to armcc, then we could use _CC_ARM to find out whether we are actually invoking it, and then after __ARMCC_VERSION to find out the actual compiler version.

-Joakim

From mantis at public.kitware.com  Thu Oct 29 06:21:54 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 29 Oct 2015 06:21:54 -0400
Subject: [cmake-developers] [CMake 0015819]: CMake / Assembler header .ah
	file is not visibile
Message-ID: <db3f421108b86a36790ba8681a2314e4@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15819 
====================================================================== 
Reported By:                Jarek 83
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15819
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-29 06:21 EDT
Last Modified:              2015-10-29 06:21 EDT
====================================================================== 
Summary:                    CMake / Assembler header .ah file is not visibile
Description: 
I'm trying to setup Cmake to work with assembler code using qcc compiler from
QNX660. Currently .S files are compiling, but the header .ah files are not
visible and I get the output:

Error: can't open callout.ah for reading: No such file or directory
The current settings are:

set(CMAKE_AR "arm-unknown-nto-ar.exe" CACHE FILEPATH "QNX program" FORCE)
set(arch gcc_ntoarmv7le)
set(CMAKE_ASM_COMPILER qcc -V${arch} )
set(CMAKE_ASM_SOURCE_FILE_EXTENSIONS s;S )
set(CMAKE_ASM_COMPILE_OBJECT "<CMAKE_C_COMPILER> <DEFINES> -pipe -march=armv7-a
-mcpu=cortex-a8 -O1 -fomit-frame-pointer <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE
STRING "ASM compile command" FORCE )
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-29 06:21 Jarek 83       New Issue                                    
======================================================================


From mantis at public.kitware.com  Thu Oct 29 08:05:16 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 29 Oct 2015 08:05:16 -0400
Subject: [cmake-developers] [CMake 0015820]: lack of descrition of
	corresponding keys inside MACOSX_FRAMEWORK_INFO_PLIST and
	MACOSX_BUNDLE_INFO_PLIST
Message-ID: <d0b1bd722bf225378e83e4a5c64e67e9@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15820 
====================================================================== 
Reported By:                gang65
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15820
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-29 08:05 EDT
Last Modified:              2015-10-29 08:05 EDT
====================================================================== 
Summary:                    lack of descrition of corresponding keys inside
MACOSX_FRAMEWORK_INFO_PLIST and MACOSX_BUNDLE_INFO_PLIST
Description: 
Hello.

In following documentation there is description of target properties:
https://cmake.org/cmake/help/v3.0/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.html
and
https://cmake.org/cmake/help/v3.0/prop_tgt/MACOSX_FRAMEWORK_INFO_PLIST.html

The is no described what keys are corresponding to:

For MACOSX_FRAMEWORK_INFO_PLIST is:
MACOSX_FRAMEWORK_ICON_FILE
MACOSX_FRAMEWORK_IDENTIFIER
MACOSX_FRAMEWORK_SHORT_VERSION_STRING
MACOSX_FRAMEWORK_BUNDLE_VERSION

It will be very useful to add description of following keys, for example:
MACOSX_FRAMEWORK_ICON_FILE Key: "CFBundleIconFile"
MACOSX_FRAMEWORK_IDENTIFIER Key: "CFBundleIdentifier"
MACOSX_FRAMEWORK_SHORT_VERSION_STRING Key: "CFBundleShortVersionString"
MACOSX_FRAMEWORK_BUNDLE_VERSION Key: CFBundleVersion

The same for MACOSX_BUNDLE_INFO_PLIST.
MACOSX_BUNDLE_ICON_FILE Key: "CFBundleIconFile"
MACOSX_BUNDLE_IDENTIFIER Key: "CFBundleIdentifier"
MACOSX_BUNDLE_SHORT_VERSION_STRING Key: "CFBundleShortVersionString"
MACOSX_BUNDLE_BUNDLE_VERSION Key: CFBundleVersion
MACOSX_BUNDLE_INFO_STRING 
MACOSX_BUNDLE_GUI_IDENTIFIER
MACOSX_BUNDLE_LONG_VERSION_STRING Key: "CFBundleLongVersionString"
MACOSX_BUNDLE_BUNDLE_NAME Key: "CFBundleName"
MACOSX_BUNDLE_COPYRIGHT

etc..

The Info.plist is universal file (for every bundle), is it possible to create
only one list?
Also MACOSX_ prefix is very confusing, as Info.plist is also applicable for iOS,
and it looks the same.


Additional Information: 


Solution proposal:
Introduce new universal property BUNDLE_INFO_PLIST, with all possible
properties, which could be written into Info.plist:
BUNDLE_CF_ICON_FILE Key: "CFBundleIconFile"
BUNDLE_CF_IDENTIFIER Key: "CFBundleIdentifier"
BUNDLE_CF_SHORT_VERSION_STRING Key: "CFBundleShortVersionString"
BUNDLE_CF_BUNDLE_VERSION Key: CFBundleVersion
BUNDLE_NS_HUMAN_READABLE_COPYRIGHT Key: "NSHumanReadableCopyright"


More information about keys Core Foundation keys:
https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

https://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html

https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-29 08:05 gang65         New Issue                                    
======================================================================


From brad.king at kitware.com  Thu Oct 29 10:13:33 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Oct 2015 10:13:33 -0400
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <7B3613F124A9F94D99A4669BF47D619CAC71FC5F@mbx04.nvlsi.no>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <n0ogri$oqd$2@ger.gmane.org>
 <7B3613F124A9F94D99A4669BF47D619CAC71FB30@mbx04.nvlsi.no>
 <5630E7B6.8060406@kitware.com>
 <7B3613F124A9F94D99A4669BF47D619CAC71FC5F@mbx04.nvlsi.no>
Message-ID: <5632298D.40608@kitware.com>

On 10/29/2015 05:28 AM, Andersson, Joakim wrote:
> comes from what I can read in its documentation.

Thanks.  For reference, here are links to each that I found:

> armcc defines:
> * __ARMCC_VERSION (version)
> * __CC_ARM (1)
> * __GNUC__ (version) (only if --gnu is passed as a commad line option)

v4: http://infocenter.arm.com/help/topic/com.arm.doc.dui0491c/BABJFEFG.html
v5: http://infocenter.arm.com/help/topic/com.arm.doc.dui0472l/chr1359125007083.html

> armclang defines:
> * __ARMCC_VERSION (version)
> * __ARMCOMPILER_VERSION (version)
> * __GNUC__ (version)
> * Note that it does *not* define __clang__

v6: http://infocenter.arm.com/help/topic/com.arm.doc.dui0774c/chr1383660321827.html
__ARMCOMPILER_VERSION is a synonym for __ARMCC_VERSION.

The format of the version macros is documented as:

v4: PVVbbbb (decimal P=major, VV=minor, bbbb=build)
v5: PVVbbbb (decimal P=major, VV=minor, bbbb=build)
v6: nnnbbbb (decimal nnn=version, bbbb=build)
    6000654 = version 6.0 build 0654

The format for v6 looks plausibly the same as v4 and v5 but it is not clear.

According to their legacy RealView tools docs the format used to be different:

v3:  PVtbbb (decimal P=major, V=minor, t=patch, bbb=build)
     300503 = version 3.0.0 build 503
v4:  PVbbbb (decimal P=major, V=minor, bbbb=build)

Therefore if the value is not at least 1000000 then we must assume the
old format.  Please update your version extraction macros accordingly.

The corresponding command line option docs are:

 v4: http://infocenter.arm.com/help/topic/com.arm.doc.dui0491c/Cihbejbb.html
 v5: http://infocenter.arm.com/help/topic/com.arm.doc.dui0472l/chr1359124898004.html
 v6: http://infocenter.arm.com/help/topic/com.arm.doc.dui0774c/chr1383574213854.html

In v4 and v5 they refer to the compiler as `armcc` and in v6 they
refer to it as `armclang` and have a link to upstream LLVM/Clang.
It looks like they simply decided to change the underlying compiler.
Therefore I think we could use just `ARMCC` for both and make any
needed adaptations based on the version number.

> arm-linux-gnueabihf-gcc defines:
> * __GNUC__ (version)

That does look like plain GNU then.

> So if we're interested in giving support only to armcc, then we could
> use _CC_ARM to find out whether we are actually invoking it, and then
> after __ARMCC_VERSION to find out the actual compiler version.

Based on the above I think just using __ARMCC_VERSION is sufficient.
Please check the range to decide how to extract the version components.
We could also consider just not identifying it for < 1000000 and leave
support for legacy versions up to future development by anyone else
interested in them.

Thanks,
-Brad


From brad.king at kitware.com  Thu Oct 29 11:20:56 2015
From: brad.king at kitware.com (Brad King)
Date: Thu, 29 Oct 2015 11:20:56 -0400
Subject: [cmake-developers] Specifying a VS installation path explicitly
In-Reply-To: <562F923F.4070707@kitware.com>
References: <OF96010E27.C4E33851-ONC1257EEB.002D2B8C-C1257EEB.002D431E@sick.de>
 <562F7E09.3050004@kitware.com>
 <OF44D2927F.135C1A68-ONC1257EEB.004FA520-C1257EEB.0050748C@sick.de>
 <562F923F.4070707@kitware.com>
Message-ID: <56323958.3020500@kitware.com>

On 10/27/2015 11:03 AM, Brad King wrote:
> Please create a build tree under the environment in question and send me
> (off list) a .zip file of what CMake puts in the build tree.  Just use
> a simple CMakeLists.txt file like
> 
>  cmake_minimum_required(VERSION 3.3)
>  project(TestVS C)

Thanks for sending the file.  One can see in CMakeFiles/CMakeError.log
that the MS tools fail to build CMake's trivial compiler id test project:

> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(153,5): error MSB4018: The "CL" task failed unexpectedly.
> [E:\jenkins\jenkins_slave_bundles\workspace\BASE_BUNDLE_WIN\Libs\BASE\build\cmakeOutput\Win32\CMakeFiles\3.3.0-rc2\CompilerIdC\CompilerIdC.vcxproj]
> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(153,5): error MSB4018: System.TypeInitializationException:
> The type initializer for 'Microsoft.Build.Utilities.FileTracker' threw an exception. ---> System.ArgumentException: The path is not of a legal form.
> [E:\jenkins\jenkins_slave_bundles\workspace\BASE_BUNDLE_WIN\Libs\BASE\build\cmakeOutput\Win32\CMakeFiles\3.3.0-rc2\CompilerIdC\CompilerIdC.vcxproj]

You can open that CompilerIdC.vcxproj file in an editor to see how
simple/minimal it is.  Try building that directly with msbuild under
your test environment.  You'll have to figure out how to get that
working independent of CMake first.  I suggest using a binary search
on available environment variables between an empty environment and
the standard one that works normally.

-Brad


From mantis at public.kitware.com  Thu Oct 29 22:49:07 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 29 Oct 2015 22:49:07 -0400
Subject: [cmake-developers] [CMake 0015821]: Durango.cmake module disables
	regeneration of project files
Message-ID: <104be8f2354bcf3e2a1a7cd67157226a@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15821 
====================================================================== 
Reported By:                Ramon Zarazua B.
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15821
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-29 22:49 EDT
Last Modified:              2015-10-29 22:49 EDT
====================================================================== 
Summary:                    Durango.cmake module disables regeneration of
project files
Description: 
When generating Xbox One project files for Visual Studio, a ZERO_CHECK project
will not be generated. This is due to this variable setting in Durango.cmake


#There seems to be some issue with how CMake adds the
#dependency for the ZERO_CHECK PROJECT with XB1.
#keeps trying to add the assembly output.
#disabling for now.
set(CMAKE_SUPPRESS_REGENERATION TRUE)

This does not seem to be the case anymore, as I have been able to generate
projects with ZERO_CHECK just fine using CMake 3.2.1-r4 and 3.4-r1

Steps to Reproduce: 
Generate an Xbox One project file with the Visual Studio 2012 generator. The
resulting project will not have a ZERO_CHECK visual studio project as is the
default for all other platforms.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-29 22:49 Ramon Zarazua B.New Issue                                    
======================================================================


From johnstonj.public at codenest.com  Fri Oct 30 01:48:29 2015
From: johnstonj.public at codenest.com (James Johnston)
Date: Fri, 30 Oct 2015 05:48:29 -0000
Subject: [cmake-developers] RFC: CMake precompiled header support and
	custom compiler based implementation
Message-ID: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com>

> -----Original Message-----

> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]

> On Behalf Of Daniel Pfeifer

> Sent: Wednesday, October 28, 2015 08:57

> To: Taylor Braun-Jones

> Cc: CMake Developers

> Subject: Re: [cmake-developers] RFC: CMake precompiled header support 

> and custom compiler based implementation

> 

> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones <taylor at braun- 

> jones.org> wrote:

> > What's the status of this PCH feature? Does it need testers? More 

> > design input? I'd love to see this feature in a future CMake release.

> > Willing to help.

> 

> I haven't worked on it for quite some time as I currently don't have a

project

> which needs it.

> But I agree that we should get it into CMake, even if it does not 

> support

all

> generators yet.

> Support for additional generators can be added successively.

> 

> I will rebase my branch to master on the weekend, ie port it to 

> cmGeneratorTarget.

> Then you are free to help with review, testing, and additional generators.

> 

> Which generators are the most important for you?

 

I'd also love to see some progress on PCH support, though I haven't had much
time recently... I'd be quite happy to test however with the below compilers
and generators - all of which we would use PCH support with:

 

Generators:

 

* Ninja

* Visual Studio 2008 (eventually 2015)

* Although we're not currently using it, CMake would be pretty broken
without supporting: Unix Makefiles

 

Compilers:

 

* Visual C++ 2008 (eventually 2015): both Ninja and VS generators

* Embarcadero bcc32 compiler: Ninja

* GCC: Ninja

 

Best regards,

 

James Johnston

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

From Joakim.Andersson at nordicsemi.no  Fri Oct 30 10:02:51 2015
From: Joakim.Andersson at nordicsemi.no (Andersson, Joakim)
Date: Fri, 30 Oct 2015 14:02:51 +0000
Subject: [cmake-developers] ARMCC toolchain support
In-Reply-To: <5632298D.40608@kitware.com>
References: <7B3613F124A9F94D99A4669BF47D619CAC71F876@mbx04.nvlsi.no>
 <n0ogri$oqd$2@ger.gmane.org>
 <7B3613F124A9F94D99A4669BF47D619CAC71FB30@mbx04.nvlsi.no>
 <5630E7B6.8060406@kitware.com>
 <7B3613F124A9F94D99A4669BF47D619CAC71FC5F@mbx04.nvlsi.no>
 <5632298D.40608@kitware.com>
Message-ID: <7B3613F124A9F94D99A4669BF47D619CAC71FDD2@mbx04.nvlsi.no>

Thank you for all your input.
I have attached an updated patch.

> The format for v6 looks plausibly the same as v4 and v5 but it is not clear.
Yes, as far as I can see they are the same.

> Therefore if the value is not at least 1000000 then we must assume the old format.  Please update your version extraction macros accordingly.
Updated in patch

> Therefore I think we could use just `ARMCC` for both and make any needed adaptations based on the version number.
> We could also consider just not identifying it for < 1000000 and leave support for legacy versions up to future development by anyone else interested in them.
I think it is OK to identify them and let the people that use the legacy versions update if necessary.

-Joakim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-ARMCC-toolchain-support.patch
Type: application/octet-stream
Size: 6228 bytes
Desc: 0001-Add-ARMCC-toolchain-support.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151030/97aca16d/attachment.obj>

From mantis at public.kitware.com  Fri Oct 30 15:43:04 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 30 Oct 2015 15:43:04 -0400
Subject: [cmake-developers] [CMake 0015822]: Need method to autogenerate
	#undef macros created with generate_export_header
Message-ID: <ab4f8cb7f59d0f26985bad23818878e2@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15822 
====================================================================== 
Reported By:                mattwc
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15822
Category:                   (No Category)
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-30 15:43 EDT
Last Modified:              2015-10-30 15:43 EDT
====================================================================== 
Summary:                    Need method to autogenerate #undef macros created
with generate_export_header
Description: 
The generate_export_header creates a header file with several macros. Right now,
cmake users wishing to develop libraries must leak these headers to their users.
Having a cmake method to generate an "undef export" header file would solve
this.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-30 15:43 mattwc         New Issue                                    
======================================================================


From chris.bieneman at me.com  Fri Oct 30 15:05:46 2015
From: chris.bieneman at me.com (Chris Bieneman)
Date: Fri, 30 Oct 2015 12:05:46 -0700
Subject: [cmake-developers] Using CMake to bootstrap clang builtins
Message-ID: <C6735D86-47E2-4EBB-AC8B-ABD71AB6AFD2@me.com>

CMake-developers,

An issue with our compiler-rt CMake builds came to my attention yesterday, and I?m wondering how to best deal with it.

Compiler-rt is a bit of a special flower. One part of it is a bunch of runtime libraries, which are basically just dylibs and static archives, nothing to wonky. The other part of compiler-rt is the clang builtins library. That?s the complicated bit.

We do a bunch of checks throughout our cmake/config-ix.cmake file that test for compiler flags and supported architectures. This is all great except try_compile does exactly what we want for tests relating to the runtime libraries, but builtins are special. When we build the builtins we don?t care if the linker works. In fact, we only need the compiler and archiver to work, and there are situations where the linker won?t work. For example, the linker won?t work if you are bootstrapping a cross compiler from nothing.

In the bootstrapping scenario you have a host toolchain that you use to build a compiler that runs on host targeting another OS or architecture. Then you use that compiler to build the builtins. The linker is never invoked, which is important because the linker can?t succeed until you have a builtin library.

Here?s my question. Is there any equivalent of try_compile that will test building a static archive instead of an executable? I can hand roll something, but I?d prefer not to because we need try_compile and check_cxx_compiler_flag, and I suspect this could get complicated.

Thanks,
-Chris

From mantis at public.kitware.com  Sat Oct 31 14:46:06 2015
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 31 Oct 2015 14:46:06 -0400
Subject: [cmake-developers] [CMake 0015823]: FIND_LIBRARY &
	TARGET_LINK_LIBRARIES
Message-ID: <8ba8272ba0864cd8a7d614aa168c55ee@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=15823 
====================================================================== 
Reported By:                Anthony Ette
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15823
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-10-31 14:46 EDT
Last Modified:              2015-10-31 14:46 EDT
====================================================================== 
Summary:                    FIND_LIBRARY & TARGET_LINK_LIBRARIES
Description: 
On version 3.3.20150618.
I am not understanding the behavior of these two commands or am getting
inconsistent results.  Sometimes when the results of a found static library from
FIND_LIBRARY are passed to TARGET_LINK_LIBRARIES, it generates "/path/to/lib"
linker syntax BUT other times it produces a "-Wl,-Bstatic -llib -Wl,-Bdynamic"
syntax.  I've confirmed that both lib vars as returned from FIND_LIBRARY are
full paths to .a static archive files so how can the different handling at the
linker CLI be explained?

Steps to Reproduce: 
Unknown.  Some libs are handled one way and others are handled another.  The
only potential lead may be that they come from different paths on the file
system (say one from /usr/lib and another from /sim/lib/v67/ihawk).

Additional Information: 
None
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-10-31 14:46 Anthony Ette   New Issue                                    
======================================================================