Brad King wrote: > 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.
I notice there is also a ANDROID_API target property. Presumably that allows things like foreach(api 16 19) add_library(mylib-android-${api} mylib.cpp) set_property(TARGET mylib-android-${api} PROPERTY ANDROID_API ${api}) endforeach() I wonder if it would instead make sense to provide some INTERFACE targets with INTERFACE_ANDROID_API set and then target_link_libraries(mylib cmake::android-16) for example. This has the disadvantage of requiring the android-${api} targets to be predefined, but maybe a use-story of set(CMAKE_ANDROID_APIS 16 19) include(CMakeAndroidTargets) would avoid a need to hardcode them. The INTERFACE_ANDROID_API, along with compatibility requirements, would prevent mistakes (?) like add_library(lib1 ...) add_library(lib2 ...) set_property(TARGET lib1 PROPERTY ANDROID_API 16) set_property(TARGET lib1 PROPERTY ANDROID_API 19) target_link_libraries(lib1 lib2) # Not the same API version. > The property activates creation of a .apk. The approach I prototyped for BB10 .bar packages was to generate them with cpack. https://gitorious.org/cmake/steveires-cmake/commit/c7715486 This has the effect that the description of build-targets and their dependencies etc is mostly 'normal' and free from BB10-specific stuff, and there is a list of cpack/BAR-related variables in the cpack section of the CMakeLists (where there could also be a list of cpack/android-related variables). Should there be some merging of functionality from cpack into cmake? > >> 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. It seems that with these changes, a project aiming to be 'cross-platform' would end up writing a macro like macro(set_properties_for_platform tgt) if (CROSS_COMPILING) if (ANDROID) set_property(TARGET ${tgt} ...) elseif (BLACKBERRY) set_property(TARGET ${tgt} ...) elseif (WinRT) set_property(TARGET ${tgt} ...) endif() endif() endmacro() # This now looks 'normal' and 'cross platform' add_executable(hello_world main.cpp) # Call this for each target: set_properties_for_platform(hello_world) That's assuming such a macro has all the information it would need to set the appropriate properties... > 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. Do each such files have the same or similar content? Author, url, siging key etc? That might be a good avenue to explore for a cross-platform abstraction. > >> 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. Yes, perhaps. A new language creates a lot of sunk-cost for people porting and learning it though of course. There would need to be enough justification for doing it. This could be designed to be part of that justification. I think there may be other justifications for designing a new language too. Are you still thinking of a 'pure'-Lua-based (not via CMakeLists which loads Lua somehow) system as an end-goal? I believe part of the motivation for qbs (the next Qt build tool) is multiple architecture support, which I believe is preferred by some to create Android APKs targeting multiple architectures http://blog.qt.digia.com/blog/2014/03/26/qt-weekly-3-qt-for-android-tips-and-tricks/#comment-1193255 So, that's at least how this stuff in this thread fits together and can be considered together. I don't understand the motivation to put multiple architectures into one package (everyone downloading the package gets N-1 times the amount of stuff they need), but so it is. Anyway the above problem is not solved with the suggestion below. > 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. Yes, that would be a good intermediate goal. There are many interesting design requirements even for that, such as the example from Daniel of building a library for both host and target, and whether find_package would need multiple modes of operation etc. For example, in a single cmake buildsystem I would need two Qt5Core packages - one host used by a generator and one target. Currently there is only one cache and one possible Qt5Core_DIR etc. When you refer to 'a new language' here, do you mean in the same sense of how generator expressions were a new language (without a departure from the current cmake language as a whole), or do you mean something different? 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