On 09/09/2014 06:32 PM, Stephen Kelly wrote: > I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an > attribute to mark an executable specially so that it is built with > appropriate flags for the WinRT platform.
Yes. It is similar to the WIN32_EXECUTABLE target property. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 > Building executables as libraries (2014-03-21) FYI, in my Github fork you can see a WIP branch adding support for NVIDIA's Nsight Tegra Visual Studio Edition. It links executables as shared libraries unless they are marked with an ANDROID_GUI target property. The property activates creation of a .apk. > Today, I think 'cross-platform' includes a few mobile platforms as first- > class targets, and cross-compiling is part of what cross-platform means. So, > I wonder what a cross-platform buildsystem necessarily looks like today, and > whether it can be done better/abstracted with more first class features. Good question. I think support for each mobile target will have to be added on an incremental basis. If some common themes emerge over time then perhaps we can identify some abstractions. However, each of these platforms requires some kind of app manifest, and that is a different file/format for each target platform. Projects will at least have to add such manifest files for each platform they want to support. > I'm reminded of the previous proposal for multiple toolchain use. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 > > Partly that discussion was aborted because we already had the large topic of > designing and implementing usage-requirements to deal with. As that is now > complete as designed, it might be worthwhile to re-consider and > discuss/design how multiple toolchains could be used at once, whether that > would require or benefit from a new language for cmake (another orthogoal > known possible future-direction for cmake) etc. The main challenge here is that CMake exposes a lot of information about "the one" toolchain per language selected during configuration in the CMake language as variables. Your "toolchain scope" proposal would provide a context for code that will see the toolchain information for each enabled target toolchain. However, perhaps it would be better in the long run to consider something more declarative and with a new language. When cross-compiling it is common to build some tools for the host system to be used during the build itself. There is always exactly one host platform, so perhaps we can design a new mode of support for cross-compiling that configures "the one" toolchain for the *host* system only. Then provide some kind of declarative or delayed-until- generate-time specification, perhaps using a new language, for the cross-compiled pieces. Eventually that spec could be used for the host system too. -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
