Re: [cmake-developers] Modern cross-platform buildsystem design requirements
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
Re: [cmake-developers] Modern cross-platform buildsystem design requirements
Hi Steve, 2014-09-10 0:32 GMT+02:00 Stephen Kelly steve...@gmail.com: I wonder what a cmake-based buildsystem would look like for a collection of executables/targets which should be built for multiple ... I would generalize even more and finish the sentence with options at once. This includes Debug/Release, Shared/Static, PlatformA/PlatformB, etc. With usage-requirements we now can propagate properties from dependees to dependents. What about the other direction? Imagine this: add_library(foo STATIC foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) add_executable(myexe main.cpp) target_link_libraries(myexe foo) A static library foo is used both in a shared library and in an executable. Depending on the platform it should be build twice: once with PIC, once without. Another example: We sometimes run code generators as custom buildsteps. add_library(foo foo.cpp) add_executable(codegen codegen.cpp) # set_target_properties(codegen PROPERTIES BUILD_FOR_HOST 1) target_link_libraries(codegen foo) add_custom_command(OUTPUT source.cpp COMMAND codegen) add_executable(myexe source.cpp) target_link_libraries(myexe foo) When crosscompiling, we need the codegenerator for the host platform (This would need some target property). But more interestingly, the library foo should be built for both the host and the target(s). Thank you for starting that discussion! -- Daniel -- 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
Re: [cmake-developers] Modern cross-platform buildsystem design requirements
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
[cmake-developers] Modern cross-platform buildsystem design requirements
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
