Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote: BTW, I think a better name may be language features rather than compiler features because we are declaring features of language versions and variants, not of the compilers. I don't agree with that. We are enumerating/introspecting the features of the compiler. The fact that the compiler is following a standard for its features is/should be irrelevant to the interface, and to the list of features. I've seen a few projects debating the useless question of 'Can we use C++11 now?', which eventually or quickly turns into the useful question of 'What features can we use from our compiler, given our minimum requirements?'. That's actually the same question they've always had to ask. They didn't consider questions like 'can we use C++98 now?', but 'can we use member templates now?'. The answer often being 'Yes, if we don't support MSVC6 anymore - it does not have that feature'. Such a view also justifies using the non-language-standard MSVC 'sealed' keyword in place of 'final' for 'the final feature', as the features are compatible. There may be other cases of such compatibility from non-standard compiler- provided features (which influenced the standard presumably). It is only in the implementation that we need to deal with compiler support for the features. Contrarily I say, it is only in the implementation that we need to consider the language-standard support for the features, because that is where the implementation needs to know (for some compilers) the standard the feature was introduced in, in order to pass the correct -std= argument. The language standard does not appear in the interface I've proposed, because it is irrelevant. The only relevant information is the minimum compiler requirements of the project. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014385]: integrate emacs cmake-mode with ELPA
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14385 == Reported By:Peter Eisentraut Assigned To: == Project:CMake Issue ID: 14385 Category: Development Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-09-02 02:12 EDT Last Modified: 2013-09-02 02:12 EDT == Summary:integrate emacs cmake-mode with ELPA Description: Please find the attached patch which makes two enhancements to cmake-mode.el: - Add some required headers to the file can act as a proper ELPA package and be installed by, say, package-install-file. - Add autoload cookies, so that auto-mode-alist is automatically set up when using ELPA. == Issue History Date ModifiedUsername FieldChange == 2013-09-02 02:12 Peter EisentrautNew Issue 2013-09-02 02:12 Peter EisentrautFile Added: cmake-mode.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INTERFACE_LIBRARY target type
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 by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
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 http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMakeLists.txt needs to be undone.
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 yields no result. Context, please? Your message doesn't provide nearly enough information for us to have any idea what you are talking about. What do you mean undone? For that matter, what problem are you having? What are these prior communications you allude to that have received no response? (Also, expecting an immediate reply during a weekend - especially a holiday weekend - is a bit unreasonable...) -- Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMakeLists.txt needs to be undone.
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 work. 4. Contacting the former maintainers yields no result. Context, please? Your message doesn't provide nearly enough information for us to have any idea what you are talking about. What do you mean undone? For that matter, what problem are you having? What are these prior communications you allude to that have received no response? (Also, expecting an immediate reply during a weekend - especially a holiday weekend - is a bit unreasonable...) Oh, okay, I found your post to the user list. Not everyone that reads the devel list also reads the user list (or, as in my case, reads it first :-) ), so you should still mention that context to avoid confusion. That said, based on your original message to the other list, your question does not appear appropriate for the devel list; please stick to the user list, and please allow a reasonable period of time for replies before sending additional 'bump' messages. -- Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] confusing documentation: VS_WINRT_EXTENSIONS
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.microsoft.com/en-us/library/hh973459 Building on the command line in a Visual Studio prompt works fine: cl.exe wrl-test.cpp runtimeobject.lib Note that the /ZW switch is not required, because no WinRT language extensions are used! Next, I tried to build it in the VS2012 ARM CrossTools Command Prompt. Calling cl.exe like above yields the following error: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338) : fatal error C1189: #error : Compiling Desktop applications for the ARM platform is not supported. Setting the api family to app solves this: cl.exe -DWINAPI_FAMILY=WINAPI_PARTITION_APP wrl-test.cpp runtimeobject.lib Note again, that /ZW is not used. Next, I wanted to compile the project with cmake. Using the Visual Studio 11 generator, it works. Using the Visual Studio 11 ARM generator, CMake fails to determine the compiler ID. The file CompilerIdCXX.log contains the familiar message: Compiling Desktop applications for the ARM platform is not supported. I guess the api family needs to be set to app here too. So my question again: Does VS_WINRT_EXTENSIONS really enable C++/CX? I hope not. cheers, Daniel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] confusing documentation: VS_WINRT_EXTENSIONS
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 was contributed here: http://www.cmake.org/Bug/view.php?id=12930 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e01aefd http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c9ae472 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0ae381c I don't know more than that. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
