<html><head></head><body><div>Eric,</div><div><br></div><div>Thanks for the feedback. See comments below.</div><div><br></div><div>On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div>This has some common design issue as my proposal:</div><div>enable_cross_target(...)<br></div><div>for which Eike has valuable doubt:</div><div><a href="https://cmake.org/pipermail/cmake-developers/2018-November/030919.html" target="_blank">https://cmake.org/pipermail/cmake-developers/2018-November/030919.html</a> </div></div></div></div></div></div></blockquote></div></div></blockquote><div><br></div><div>If you're talking about the issue of specifying multiple toolchain files on the command line, I'm imagining a design like this:</div><div><br></div><div>add_toolchain(TargetToolchain FILE ${CMAKE_TOOLCHAIN_FILE_TARGET})</div><div><br></div><div>and then specify it on the command line with:</div><div><br></div><div>cmake ../src -DCMAKE_TOOLCHAIN_FILE=/path/to/host/toolchain.cmake -DCMAKE_TOOLCHAIN_FILE_TARGET=/path/to/target/toolchain.cmake</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>So if you want to build both for host and cross toolchain you'll have to explicitely </div><div>add_executable/library(MyLibrary TOOLCHAIN DEFAULT)</div><div><div>add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)</div><div><br></div><div>If you follow the previously referred discussion you cannot assume that one lib/exe</div><div>built for a toolchain is not built for another toolchain as well.</div></div></div></div></div></div></blockquote></div></div></blockquote><div><br></div><div>If you want to build the same target with multiple toolchains then I think you're better off declaring them as different targets, with different TOOLCHAINs but the same source files, etc.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div class="gmail_quote"><div>... sorry wrong key pressed...</div><div><br></div><div>CMake could perfectly automatically create the new "TOOLCHAIN" object by loading the very</div><div>same toolchain file as we have today. We could simple add a new variable</div><div>CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name them as he wants.</div><div>When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain.</div></div></div></div></div></div></blockquote></div></div>
</blockquote><div><br></div><div>My vision for this feature is that the project specifies the names of the toolchains that it's expecting, and the toolchain file is agnostic of this - it simply sets the properties of the toolchain named ${CMAKE_SELECTED_TOOLCHAIN}.</div><div><br></div><div>If you want to have a variable number of toolchains, you could do something like this:</div><div><br></div><div>set(PROJECT_TARGET_TOOLCHAIN_NAMES "" CACHE STRING "Names of toolchains")</div><div>foreach(i ${PROJECT_TARGET_TOOLCHAIN_NAMES})</div><div> add_toolchain(${i} FILE ${CMAKE_TOOLCHAIN_FILE_${i}})</div><div> add_executable(foo-${i} TOOLCHAIN ${i} ...) # Build a copy of foo for each target platform</div><div>endforeach()</div><div><br></div><div>Kyle</div></body></html>