On Sat, Dec 22, 2018 at 10:58 AM Torsten Robitzki <tors...@robitzki.de> wrote:
> Hi, > > > Am 17.12.2018 um 21:18 schrieb Kyle Edwards via cmake-developers < > cmake-developers@cmake.org>: > > > > Then, executables and libraries could have a toolchain specified: > > > > add_executable(BuildUtility TOOLCHAIN DEFAULT ...) > > add_library(MyLibrary TOOLCHAIN CrossToolchain …) > > or even toolchains: > > add_library(feature1 TOOLCHAINS CrossToolChain HostToolChain) > > add_executable(Firmware TOOLCHAIN CrossToolChain) > target_link_libraries(Firmware feature1) > > add_executable(Test_Feature1 TOOLCHAIN HostToolChain) > target_link_libraries(Test_Feature1 feature1) > > A nice feature would be to let toolchain propagate along the dependency > graph defined by `target_link_libraries`. So in the example above, the > TOOLCHAINS option to `add_library` would be optional, because the target > Firmware requires feature1 to be build with CrossToolChain and > Test_Feature1 to be build with HostToolChain. Which requires the build to > have different binary directories for every toolchain. (Which for me is an > indication that having multidimensional build types would be the more > natural way to go) > > How would different binary directories for every toolchain work? CMAKE_CURRENT_BINARY_DIR wouldn't even be accurate let alone all of the code that tracks these things. Using target_compile_options() and file level compile options would have to use generator expressions to pass the correct flags to the correct toolchain. If TOOLCHAINS is specified and the CMakeLists.txt file only contains the library target then nothing is built because there is nothing linking against it? Offhand it seems to me that adding multiple binary directories based on which toolchain was used is a larger change to the infrastructure then adapting a generator to use multiple toolchains in its output. > What I’m still missing is support to define dependencies between different > targets (build by different toolchains), so that I can describe that I > require a tool that is build with the HostToolChain, to generate a file > that is required by the part of the build, that is using the > CrossToolChain. And, of cause, if the source of that tool changes, that > tool have to be rebuild and the generated file from the CrossToolChain part > of the build have to be rebuild. > > All the commands already support this. add_executable() rebuilds the host tool if the source file change for the tool is updated. add_custom_command() runs whenever any target specified in DEPENDS is rebuilt. So in this case you specify the custom command to run the host tool and generate the output and set DEPENDS to host tool target. If the host tool is updated due to a source file change then the tool is rebuilt and the file is regenerated. The cross toolchain target that uses the generated file rebuilds because the timestamp on generated file was updated.
-- 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