Hi, 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.
This reminds me of this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 Building executables as libraries (2014-03-21) and I wonder again if a generic solution would be possible to design. I wonder what a cmake-based buildsystem would look like for a collection of executables/targets which should be built for multiple of these 'modern, extra attribute-requiring' platforms. Until a few years ago, add_library(foo foo.cpp) add_executable(myexe main.cpp) target_link_libraries(myexe foo) was all that was needed for what we then called 'cross-platform' - it is a sufficient description to generate buildsystems to generate a working library and executable on first-class targets Windows/Linux/Mac and also cross-compiling, given an appropriate toolchain file. 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. I guess in addition to the above, there would need to be something like a wrapper macro around add_executable to set the appropriate target properties, and possibly use a platform-specific condition for whether to actually create an executable or a PIC shared library (as described in the above thread). Is there any known real-world project aiming to build for those varieties of platforms so we can see what abstraction is needed? According to http://www.cmake.org/Wiki/CMake_Cross_Compiling#FAQ.2FPotential_Problems "If you build software for PS3, you build software for two architectures, for the PowerPC and for the cells." That information seems to come from: http://www.cmake.org/pipermail/cmake/2008-January/018937.html I was reminded of the above by http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/50389 I don't know how common it is to use cmake in those industries/environments, but if multiple toolchains are needed, 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 manual at Help/manual/cmake-toolchains.7.rst contains several sample toolchain files for Unix. It would be good to have some sample toolchain files using the new WinRT stuff, setting the toolset and CMAKE_GENERATOR_PLATFORM to see how that all fits together now with VisualStudio. ] 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
