On 09/10/2014 11:49 AM, Stephen Kelly wrote:
> target_link_libraries(mylib cmake::android-16)
Interesting idea. These could be predefined in the Platform/Android.cmake
module. However, I do not think the current ANDROID_API property will be
outdated by such a design, so I think we can keep it as-is for now and
consider an INTERFACE feature when things have matured somewhat.
>> The property activates creation of a .apk.
>
> The approach I prototyped for BB10 .bar packages was to generate them with
> cpack.
In the current work, the goal is to let Nsight Tegra handle everything
from the generated .vcxproj file.
> 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()
I don't see any reason the properties could not just always be set by
the project. The ones not relevant to the current cross-compiling
target would simply be ignored.
>> However, each of these platforms requires some kind of app manifest
>
> 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.
Perhaps, but not for a while. Authors targeting mobile devices will
need very specific control over the manifest files, packaging, and
signing. Only when we see lots of duplication across manifests for
different targets should we consider such abstraction.
> Are you still thinking of a 'pure'-Lua-based (not via
> CMakeLists which loads Lua somehow) system as an end-goal?
No, but I wouldn't rule it out forever.
> 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
[snip]
> whether find_package would need multiple modes of operation etc.
The fundamental problem with supporting multiple architectures is
that pretty much all of CMake is designed to support one architecture
at a time. Modules/*, CMakeCache.txt, etc. are all built around only
finding, using, and building one artifact per library (OS X universal
binaries work with multiple architectures because they are still only
one file). I think even your "toolchain scope" approach would end
up being used in practice to wrap the entire CMakeLists.txt file.
The only approach I can think of that solves this without being a
complete rewrite is to support multiple separate configuration
passes, with separate CMakeCache.txt and everything as now, but that
all feed in to a single generation step. (Note the separate config
passes could be independent and perhaps run in threads.)
> 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?
I don't mean anything in particular except that we should not constrain
ourselves to solving the problem with the current CMake language only.
-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
