On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
> So it would be something like project( [TOOLCHAIN
> [LANGUAGES] [...]) where TOOLCHAIN
> and its supported languages can be repeated for each tool chain. i.e
> project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross
> LANGUAGES c)
I think this sounds about right.
> But isn't this all (or mostly) cached so you don't have to redo all this when
> regenerating build files. I guess it would be CMAKE_<toolchain>_<lang>_* ?
Good point about caching, I did not think of that. Perhaps we need some
separate caching mechanism for toolchain properties - or perhaps the
properties could be loaded from undocumented cache variables defined
only for CMake's internal use.
> What about conflicting build types when building a host tool target vs the
> cross compiler target?
> For instance the host tool may (should?) be built as a release project
> (default optimization levels) but the cross compiler project could be built
> as a debug project (so you can debug it with no optimizations)?
> I guess it would then be CMAKE__BUILD_TYPE and then targets using that
> toolchain would be built with that build type.
I think that both host and cross targets would be built with the same
build type. If you're using a multi-config generator like VS or Xcode,
how do you specify which combination of configs you want? It's simpler
if every target is built as the same type, whether it's host or cross.
Think about it - the current system already expects that every target
in the project is built as the same build type. There's no way to
specify "foo is built as debug, bar is built as release." Why would
this assumption change just because we add a multi-toolchain mechanic?
> On the other hand this doesn't really help anyone working with mixed build
> systems. What you can't do in a straight forward manner is host tool
> development with Visual Studio or Eclipse, execute it and use it's results
> with a cross compiler (that uses Ninja or Makefiles) targeting an embedded
> system.
Every target would be built by the same generator regardless of whether
it's a host or cross target. So if you select the VS generator, both
the host tools and the embedded software would be built in VS (if this
is possible.) Likewise for Ninja and Make.
> In this case I think that what you want is to easily control multiple
> projects using different build systems, the inter-dependencies, and
> easily specify that external project A produces a file for external
> project B. Ideally you would be in the root of the build folder and
> type 'cmake --build .' and have it take care of everything with
> minimal extraneous build tool executions or sometimes even invoking
> the build tool in parallel for external projects that don't depend on
> each other.
>
If you want to build different parts of the software with different
generators (build systems) then you're better off using a superbuild
with ExternalProject. The intent of this proposal is to allow users to
build both host tools and cross-compiled software in the same build
tree with the same generator.
As an example of a real-world project, I would like to emulate the
Linux kernel's separation of host and cross compiler. The vast majority
of files in the kernel source tree are built with a single cross
compiler, while a very small set of host tools are built with the host
compiler. Both the host tools and the kernel itself are built using the
same Makefile, and there's no ExternalProject-like separation between
them. The kernel's buildsystem only supports Makefiles and can't
generate Ninja, VS, etc., but if it did, then both the host tools and
the kernel would be built with the same Ninja files/VS solution. I
don't remember whether it supports building the host tools and kernel
as separate types (debug vs release), but for sake of simplicity, I'd
rather not try to support that, especially in multi-config generators.
Kyle
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
