Rework post-build to support multiple executables #14953

The 'post build' functions are made visible by adding the mbed-os subdirectory. This is not ideal as any components in mbed-os wishing to call the functions must be added after the functions are defined. To improve modularity move these functions to a separate CMake script. We include the post build CMake script in app.cmake for now so we don't break user's projects.

When building greentea tests, each test is an executable with its own output binary path. This is also the case when a user project produces multiple executables. But the current implementation of post-build operations always assumes there's only one executable, at the root of the build directory. The post-build command depends on Mbed target, and it always takes the the executable we build as an input file. To achieve this, we let each Mbed target (that has a post-build command) define a function function(mbed_post_build_function target) which takes a CMake executable target as an argument from which it can get its binary path using generator expressions. It generates and adds to the passed executable target a post-build custom command. Notes: * The function name needs to be exact, because CMake only supports literal function calls - CMake can't dereference a function name from a variable. To avoid multiple definitions of this function, each Mbed target needs to guard it with a macro to check if the user is building this Mbed target. * `mbed_post_build_function()` is a function, but it is usually defined by another macro rather than a parent function, because nesting functions would make many variables inaccessible inside the innermost `mbed_post_build_function()`. * There's no more need to force regenerate images. Previously, post- build commands were custom *targets* which always got to run, so we force regenerated images on every build to avoid patching an image that's already been patched once on previous build. Now post-build commands are custom *commands* of the same executable target, and they are only run if the executable target itself is rebuilt.

The CMake macro `mbed_post_build_psoc6_merge_hex()` takes the name of a Cypress target and an optional Cortex-M0 hex image as arguments. The proper way to define and parse optional arguments of a function or macro is `cmake_parse_arguments()`, which allows the caller to indicate what they are passing rather than rely on an argument's relative position within `${ARGN}` which is not rigorous. Also, avoid duplicating the common part of the post build command when the optional argument is passed/not passed.

Add a test to build two executables in two directories under a single project.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rework post-build to support multiple executables #14953

Rework post-build to support multiple executables #14953

Commits on Jul 22, 2021