Re: [cmake-developers] confusing documentation: VS_WINRT_EXTENSIONS

2013-09-02 Thread Brad King
On 09/02/2013 11:42 AM, Daniel Pfeifer wrote: > The target property VS_WINRT_EXTENSIONS is documented as: "Can be set > to enable C++/CX language extensions." > Is that really what this property does? [snip] > So my question again: Does VS_WINRT_EXTENSIONS really enable C++/CX? I hope > not. This

[cmake-developers] confusing documentation: VS_WINRT_EXTENSIONS

2013-09-02 Thread Daniel Pfeifer
Hi, The target property VS_WINRT_EXTENSIONS is documented as: "Can be set to enable C++/CX language extensions." Is that really what this property does? I am trying to build a C++ project (no C++/CX) for ARM with Visual Studio 2012. As an example, I took the following code: http://msdn.mic

Re: [cmake-developers] CMakeLists.txt needs to be undone.

2013-09-02 Thread Matthew Woehlke
On 2013-09-02 11:15, Matthew Woehlke wrote: On 2013-08-31 20:42, outro pessoa wrote: It's that simple. 1. I know that this isn't the traverso mailing list. 2. There is no response; and, therefore, it is up to me to fix it. 3. Resetting vorbis/vorbisfile.h to accept the FreeBSD paths does not wor

Re: [cmake-developers] CMakeLists.txt needs to be undone.

2013-09-02 Thread Matthew Woehlke
On 2013-08-31 20:42, outro pessoa wrote: It's that simple. 1. I know that this isn't the traverso mailing list. 2. There is no response; and, therefore, it is up to me to fix it. 3. Resetting vorbis/vorbisfile.h to accept the FreeBSD paths does not work. 4. Contacting the former maintainers yield

Re: [cmake-developers] c++ feature detection and usage requirements

2013-09-02 Thread Brad King
On 09/02/2013 02:03 AM, Stephen Kelly wrote: > Brad King wrote: >> I think a better name may be "language features" rather than >> "compiler features" > > I don't agree with that. > [good arguments] Okay, agreed. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at

Re: [cmake-developers] INTERFACE_LIBRARY target type

2013-09-02 Thread Daniel Pfeifer
> 4) The target_* commands always need to be invoked with an explicit > INTERFACE option. > Maybe PUBLIC should be allowed too (providing the same effect)? I don't really have a rationale. I just wrote PUBLIC a few times by accident. That might be a hint for a more intuitive interface. -- Powered