[cmake-developers] C|CXX Standards Handling

[Daniel Wirtz]

Hello CMake Developers,

i've recently encountered an issue with the CMake [CMAKE_]C_STANDARD 
settings. (same for CXX)
For initial background see 
http://public.kitware.com/pipermail/cmake/2015-September/061546.html


Basically, CMake silently continues to configure past any 
set(CMAKE_C_STANDARD ) command even if CMake does

not have any information on the necessary flags for the current compiler.
In my case, i've had that issue with the SUPERLU_DIST package and Intel 
14.xx compilers.
The configure stage would go fine but the compile breaks complaining 
about all sorts of weird things, from
which it was far from obvious it was because of the missing -std=c99 
flag. Especially as i've entrusted CMake to
handle that situation as i've also specified 
set(CMAKE_C_STANDARD_REQUIRED YES).


I know there's standard flags information right now only for gnu and 
clang, and having them included for all
supported compilers will be a different issue. but i suggest to include 
the following into cmake:


- if there is no standards information for the given compiler, issue a 
warning to tell the developer just that.
- if additionally XX_REQUIRED is set on cmake or target level, throw a 
fatal error on configure time as cmake cannot ensure

  to set the correct flags required for the requested C standard.

of course, this wont save the user the trouble of finding the correct 
flags for the current compiler for himself, but at least
it's a more informed action than just wondering why suddenly everything 
breaks which went fine on GNU.


this will clearly be redundant once all supported compilers have the 
necessary information, but would also
makes cmake more robust in case new compilers come in without having the 
standards info contained at the beginning.


Cheers
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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[Brad King]

On 09/15/2015 10:09 AM, David Gobbi wrote:
> The first is trivial, it simply adds Python 3.5 and 3.6 to the search list.
> 
> The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion
> for PYTHON_INCLUDE_DIR.

Thanks.  I've applied these two:

 FindPython{Interp,Libs}: Add versions 3.5 and 3.6
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2db092b1

 FindPythonLibs: Remove PYTHON_INCLUDE_PATH as input
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c57334fa

> The third does two important things: 1) it fixes bugs for searching for
> specific versions of the libs and headers for framework installs of
> Python on OS X, and 2) it doesn't search for the include directory
> until after library has been found, so that it can use the library
> version to direct the search for the include directory.

This patch conflicts with post-3.3 changes in CMake 'master'.  Please
rebase on the above-applied commits and revise accordingly.

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[David Gobbi]

On Wed, Sep 16, 2015 at 7:03 AM, Brad King  wrote:

> On 09/15/2015 10:09 AM, David Gobbi wrote:
> > The first is trivial, it simply adds Python 3.5 and 3.6 to the search
> list.
> >
> > The second removes the long-deprecated PYTHON_INCLUDE_PATH as a
> suggestion
> > for PYTHON_INCLUDE_DIR.
>
> Thanks.  I've applied these two:
>
>  FindPython{Interp,Libs}: Add versions 3.5 and 3.6
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2db092b1
>
>  FindPythonLibs: Remove PYTHON_INCLUDE_PATH as input
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c57334fa
>
> > The third does two important things: 1) it fixes bugs for searching for
> > specific versions of the libs and headers for framework installs of
> > Python on OS X, and 2) it doesn't search for the include directory
> > until after library has been found, so that it can use the library
> > version to direct the search for the include directory.
>
> This patch conflicts with post-3.3 changes in CMake 'master'.  Please
> rebase on the above-applied commits and revise accordingly.
>

I've attached the rebased patch.  It looks like someone had already
fixed the framework library search issue, so this new patch only changes
the search for the include dirs.

Cheers,
 - David


0001-FindPythonLibs-Match-include-dir-to-library-version.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake user-provided manifest files

[Brad King]

On 09/14/2015 04:16 PM, Brad King wrote:
> I think our path forward here is to teach the Makefile and Ninja
> generators how to add user-specified manifest files to the "mt"
> invocations as outlined above.

I've drafted support for this in all generators, with a test:

 Add support for *.manifest source files with MSVC tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74fee403

Please try it out.

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[Brad King]

On 09/16/2015 10:00 AM, David Gobbi wrote:
> this new patch only changes the search for the include dirs.

Thanks.  Rather than calling find_path twice, the first call could
just use HINTS instead of PATHS.  HINTS are meant for this use case:
searching paths detected from the system in some manner.  They are
searched before the generic system and environment paths.  Does that
work for your use case?

Also, why does the second call not use the same list of suffixes?

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[Brad King]

On 09/16/2015 11:39 AM, Brad King wrote:
> On 09/16/2015 10:00 AM, David Gobbi wrote:
>> this new patch only changes the search for the include dirs.
> 
> Thanks.  Rather than calling find_path twice, the first call could
> just use HINTS instead of PATHS.  HINTS are meant for this use case:
> searching paths detected from the system in some manner.  They are
> searched before the generic system and environment paths.  Does that
> work for your use case?
> 
> Also, why does the second call not use the same list of suffixes?

Meanwhile I split out the OS X framework path fix:

 FindPythonLibs: Fix OS X framework include directory search path
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea2db3bb

Please check that it looks correct on its own.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] compute-default-dialect topic

[Stephen Kelly]

Brad King wrote:

> The default dialect computed with the compiler id may not be the
> same as the effective default dialect when CMAKE_CXX_FLAGS is
> considered.  One may build with -std=c++11, for example, thus
> making the dialect used for compilation different than the raw
> compiler default even when CMake does not add a -std= flag.

Thanks for that info!

I pushed another fixup which may disable the test in that case, and may also 
disable it with GNU 6 and other compilers with default standard >= 11.

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] C|CXX Standards Handling

[Stephen Kelly]

Brad King wrote:

> On 09/16/2015 03:56 AM, Daniel Wirtz wrote:
>> Basically, CMake silently continues to configure past any
>> set(CMAKE_C_STANDARD ) command even if CMake does
>> not have any information on the necessary flags for the current compiler.
> 
> For reference, this was discussed during the original design in
> this thread:
> 
>  target_compile_features remaining issues, 2014-04-21 13:16:16 GMT
>  
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812/focus=9996
> 
> IIRC it led to the creation of _STANDARD_REQUIRED.  Read through
> that thread for more details.

I think _STANDARD_REQUIRED is not related to what Daniel described. 
Daniel is talking about using a compiler for which no features are recorded 
at all afaik.

>> - if additionally XX_REQUIRED is set on cmake or target level, throw a
>> fatal error on configure time as cmake cannot ensure
>>to set the correct flags required for the requested C standard.
> 
> Steve, do you remember if/why/where we decided to ignore these properties
> on compilers for which know language standard levels or features are
> known?

A brief search didn't reveal the relevant mailing list thread. I think it 
was to avoid everyone having to wrap target_compile_features() calls in 
conditions to avoid errors with unsupported compilers, and with unsupported 
versions of supported compilers. When the feature was initially added, it 
did not cover as large a matrix as today.

There is information about adding support for compile features at 

 
http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#adding-compile-features

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015747]: Regression: -Wno-dev doesn't work any more in CMake 3.4

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15747 
== 
Reported By:James Johnston
Assigned To:
== 
Project:CMake
Issue ID:   15747
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-16 16:04 EDT
Last Modified:  2015-09-16 16:04 EDT
== 
Summary:Regression:  -Wno-dev doesn't work any more in CMake
3.4
Description: 
The -Wno-dev option doesn't work any more in CMake 3.4.

Tested on the master branch, commit ID febeabbf0b221a19bd4bf16ba7620af22d8dba17

Steps to Reproduce: 
1.  Create a simple CMakeLists.txt like this:

cmake_minimum_required(VERSION 3.3.0 FATAL_ERROR)
project(DevWarn)
configure_file(infile outfile dummy_arg)

2.  Try to configure it with -Wno-dev:

cmake "-GVisual Studio 9 2008" -Wno-dev ..\DevWarn

3.  Observe the following error...


CMake Warning (dev) at CMakeLists.txt:3 (configure_file):
  configure_file called with unknown argument(s):

   dummy_arg

This warning is for project developers.  Use -Wno-dev to suppress it.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-16 16:04 James Johnston New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] compute-default-dialect topic

[Brad King]

On 09/16/2015 02:22 PM, Stephen Kelly wrote:
>> The default dialect computed with the compiler id may not be the
>> same as the effective default dialect when CMAKE_CXX_FLAGS is
>> considered.
> 
> I pushed another fixup which may disable the test in that case, and may also 
> disable it with GNU 6 and other compilers with default standard >= 11.

That may fix the trouble for CMake's test suite, but might this
also be a problem for projects in general?  Actually this could
be an existing problem whether CMake computes or memorizes the
raw compiler default.  If we're making decisions about what flags
to add based on CMAKE__STANDARD_DEFAULT, but the user has
already specified their own -std= flags in CMAKE__FLAGS,
might we end up with the incorrect standard level, or multiple
flags?

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] compute-default-dialect topic

[Brad King]

On 09/16/2015 03:00 PM, Stephen Kelly wrote:
> I ran cmake with -DCMAKE_CXX_FLAGS=-std=c++11.
> 
> The result is that a default of 11 is computed (with my branch) for the 
> CXX_STANDARD_DEFAULT because of the CMAKE_CXX_FLAGS=-std=c++11,

Right.  I forgot that we honor CMAKE__FLAGS for the compiler id:

 
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=v3.3.1#l24

That eliminates my concern.  The use of multiple flags is not a big
problem because the right one wins, and the user did ask for the "loser"
to be there even though the project knows how to add the latter.

>  -std=c++11   -std=gnu++11
> 
> appears instead, which is consistent with the design of CompileFeatures. 
> Arguably the -std=gnu++11 should not be added in that case, but changing 
> that existing behavior would be a different topic.

Yes, and it can be done later if found to be necessary.

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

Re: [cmake-developers] compute-default-dialect topic

[Stephen Kelly]

Brad King wrote:

> On 09/16/2015 02:22 PM, Stephen Kelly wrote:
>>> The default dialect computed with the compiler id may not be the
>>> same as the effective default dialect when CMAKE_CXX_FLAGS is
>>> considered.
>> 
>> I pushed another fixup which may disable the test in that case, and may
>> also disable it with GNU 6 and other compilers with default standard >=
>> 11.
> 
> That may fix the trouble for CMake's test suite, but might this
> also be a problem for projects in general?  Actually this could
> be an existing problem whether CMake computes or memorizes the
> raw compiler default.  If we're making decisions about what flags
> to add based on CMAKE__STANDARD_DEFAULT, but the user has
> already specified their own -std= flags in CMAKE__FLAGS,
> might we end up with the incorrect standard level, or multiple
> flags?

Multiple flags, apparently.

I made a project with 

 target_compile_features(hello PRIVATE cxx_decltype_auto) # -std=c++14

and built it with GNU 5.1(default dialect 98).

I ran cmake with -DCMAKE_CXX_FLAGS=-std=c++11.

The result is that a default of 11 is computed (with my branch) for the 
CXX_STANDARD_DEFAULT because of the CMAKE_CXX_FLAGS=-std=c++11, but 14 is 
the requirement, so

 -std=c++11   -std=gnu++14

appears on the command line. The latter 'wins' in this case.

If I instead use 

 target_compile_features(hello PRIVATE cxx_static_assert) # -std=c++11

Then 

 -std=c++11   -std=gnu++11

appears instead, which is consistent with the design of CompileFeatures. 
Arguably the -std=gnu++11 should not be added in that case, but changing 
that existing behavior would be a different topic.

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015748]: Regression: get_target_property dies if a source file does not exist

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15748 
== 
Reported By:James Johnston
Assigned To:
== 
Project:CMake
Issue ID:   15748
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-16 18:20 EDT
Last Modified:  2015-09-16 18:20 EDT
== 
Summary:Regression:  get_target_property dies if a source
file does not exist
Description: 
Previously, in CMake 3.3, one could call get_target_property to retrieve the
deprecated LOCATION target property even if not all source files exist yet. 
Now, in CMake master branch (commit febeabbf0b221a19bd4bf16ba7620af22d8dba17)
this does not work under some conditions.  The bug is a little tricky to isolate
into a test case - e.g. not all calls to get_target_property will die. (e.g. if
you call get_target_property from the same dir that creates the target, it seems
to work).  I am also not sure if the LOCATION property is the only target
property affected by this.

Even though LOCATION is deprecated, this matters because very recent OpenCV
versions still use it (e.g. in OpenCV/cmake/OpenCVGenPkgconfig.cmake).

Steps to Reproduce: 
1.  Create file CMakeLists.txt with this contents:

cmake_minimum_required(VERSION 2.6.3)
project(SourceTest)
add_subdirectory(subdir)
# Critical: this needs to happen in root CMakeLists.txt and not inside
# the subdir.
get_target_property(mypath Hello LOCATION_${CMAKE_BUILD_TYPE})
# Now we create the file later, so you can see, ultimately no error should
# happen e.g. during generate phase:
configure_file(subdir/Hello.c.in ${CMAKE_CURRENT_BINARY_DIR}/subdir/Hello.c)

2.  Create subdir/CMakeLists.txt with this contents:

add_executable(Hello ${CMAKE_CURRENT_BINARY_DIR}/Hello.c)

3.  The contents of subdir/Hello.c can be a simple Hello World program.
(actually the contents do not matter to repro this bug since you don't get to
compile phase...).

4.  Configure the project:

cmake -GNinja ../SourceTest

5.  I get this error:

CMake Error at subdir/CMakeLists.txt:1 (add_executable):
  Cannot find source file:

C:/Users/JamesJ/Documents/Repositories/OI3D-2/SourceTest-build/subdir/Hello.
c

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx


-- Configuring incomplete, errors occurred!
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-16 18:20 James Johnston New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] xcode7-defaults-to-c11 topic

[Gregor Jasny via cmake-developers]

Hi,

On 15/09/15 20:24, Stephen Kelly wrote:
> I have merged a Konsole output compute-default-dialect to next for
> testing which implements the automatic detection. Please test it to see
> if it works with xcode 7.

The CompileFeatures test does pass:

$ git describe
v3.3.1-3005-gf1591ef

I compiled and tested with

$ export DEVELOPER_DIR=/Applications/Xcode7.app/Contents/Developer
$ mkdir _build_xcode7 && cd $_
$ cmake -DCMAKE_OSX_SYSROOT=macosx10.11
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.10 -GXcode ..
$ xcodebuild
$ bin/Debug/ctest --verbose -R CompileFeatures

Thanks,
Gregor
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake user-provided manifest files

[James Johnston]

> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Wednesday, September 16, 2015 20:13
> To: James Johnston; 'Gilles Khouzam'
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] CMake user-provided manifest files
> 
> On 09/16/2015 03:43 PM, James Johnston wrote:
> > So the problem is the current directory when linking is going to be
> > root CMAKE_BINARY_DIR, and the relative path "DPIAware.manifest" will
> > attempt to be used, which of course isn't there as it needs to look in
> > "subdir\DPIAware.manifest".
> 
> This should fix that:
> 
>  fixup! Add support for *.manifest source files with MSVC tools
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e78b5408
> 
> I'll also work on integrating your test case.
> 
> Thanks,
> -Brad

That fixed it; just tested building a pile of projects with both Ninja and
VS2008 generators (with VS2008 used with Ninja). 

Best regards,

James Johnston

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015749]: Make the URL option of ExternalProject_Add to accept lists

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15749 
== 
Reported By:Ilya
Assigned To:
== 
Project:CMake
Issue ID:   15749
Category:   CMake
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-16 22:51 EDT
Last Modified:  2015-09-16 22:51 EDT
== 
Summary:Make the URL option of ExternalProject_Add to accept
lists
Description: 
It would be handy if one could specify a bunch of mirrors for a specific
dependency.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-16 22:51 Ilya   New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[David Gobbi]

On Wed, Sep 16, 2015 at 9:41 AM, Brad King  wrote:

> On 09/16/2015 11:39 AM, Brad King wrote:
> > On 09/16/2015 10:00 AM, David Gobbi wrote:
> >> this new patch only changes the search for the include dirs.
> >
> > Thanks.  Rather than calling find_path twice, the first call could
> > just use HINTS instead of PATHS.  HINTS are meant for this use case:
> > searching paths detected from the system in some manner.  They are
> > searched before the generic system and environment paths.  Does that
> > work for your use case?
> >
> > Also, why does the second call not use the same list of suffixes?
>
> Meanwhile I split out the OS X framework path fix:
>
>  FindPythonLibs: Fix OS X framework include directory search path
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea2db3bb
>
> Please check that it looks correct on its own.


Thanks, looks fine.  I've modified my patch so that it only calls find_path
once.
It uses HINTS to search for the includes in the same prefix as where the
library
was found, which is probably the best place to start.  I've left the
framework dirs
in PATHS because we don't necessarily want them to have priority, we just
want to have them in the search path.

 - David


0001-FindPythonLibs-Match-include-dir-to-library-version.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] compute-default-dialect topic

[Brad King]

Steve,

In regard to this topic:

 Project: Determine default language dialect for the compiler.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77691638

 fixup! Project: Determine default language dialect for the compiler.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=10e937ad

 fixup! Project: Determine default language dialect for the compiler.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ba7ade5f

The default dialect computed with the compiler id may not be the
same as the effective default dialect when CMAKE_CXX_FLAGS is
considered.  One may build with -std=c++11, for example, thus
making the dialect used for compilation different than the raw
compiler default even when CMake does not add a -std= flag.

This is done for CMake itself on some dashboard builds:

 https://open.cdash.org/viewNotes.php?buildid=4011828
 set(RR_FLAGS_C "${RR_FLAGS_COMMON} -std=c11")
 set(RR_FLAGS_CXX "${RR_FLAGS_COMMON} -std=c++11 -stdlib=libc++")
 set(ENV{CFLAGS} "${RR_WARNINGS_C} ${RR_FLAGS_C}")
 set(ENV{CXXFLAGS} "${RR_WARNINGS_CXX} ${RR_FLAGS_CXX}")
 ...
 CMake_NO_C_STANDARD:BOOL=1
 CMake_NO_CXX_STANDARD:BOOL=1

These builds are where the RunCMake.CompileFeatures test failed
with this topic.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] C|CXX Standards Handling

[Brad King]

On 09/16/2015 03:56 AM, Daniel Wirtz wrote:
> Basically, CMake silently continues to configure past any 
> set(CMAKE_C_STANDARD ) command even if CMake does
> not have any information on the necessary flags for the current compiler.

For reference, this was discussed during the original design in
this thread:

 target_compile_features remaining issues, 2014-04-21 13:16:16 GMT
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812/focus=9996

IIRC it led to the creation of _STANDARD_REQUIRED.  Read through
that thread for more details.

> there's standard flags information right now only for gnu and clang

The list of supported compilers is available in the manual:

 
http://www.cmake.org/cmake/help/v3.3/manual/cmake-compile-features.7.html#supported-compilers

It includes GNU, Clang, AppleClang, MSVC, and SunPro right now.

> - if there is no standards information for the given compiler, issue a 
> warning to tell the developer just that.

See above thread for why it silently decays.

> - if additionally XX_REQUIRED is set on cmake or target level, throw a 
> fatal error on configure time as cmake cannot ensure
>to set the correct flags required for the requested C standard.

Steve, do you remember if/why/where we decided to ignore these properties
on compilers for which know language standard levels or features are
known?

-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