Lingkai Dong 351680fb18 Rework post-build to support multiple executables ... 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.		2021-07-22 17:31:22 +01:00
..
LPC.py	NXP: Query precise application names in post build	2021-03-04 10:28:22 +00:00
mbed_set_post_build_nxp.cmake	Rework post-build to support multiple executables	2021-07-22 17:31:22 +01:00