mkrules.cmake: get_target_property(... COMPILE_DEFINITIONS) falls back to "MICROPY_CPP_DEF-NOTFOUND"
Port, board and/or hardware
N/A
MicroPython version
N/A, master
Reproduction
If you succeed in building a CMake port of MicroPython (ie: a dynamic library built with CMake from the embed port leveraging the existing cmake tooling) then setting no compiler definitions on ${MICROPY_TARGET} will result in this line of mkrules.cmake failing back to a "NOTFOUND" state:
get_target_property(MICROPY_CPP_DEF ${MICROPY_TARGET} COMPILE_DEFINITIONS)
This then pollutes the build and results in a stream of errors:
1 warning generated.
1 warning generated.
In file included from <built-in>:418:
<command line>:1:24: warning: ISO C99 requires whitespace after the macro name [-Wc99-extensions]
#define MICROPY_CPP_DEF-NOTFOUND 1
Setting any definitions fixes this, eg:
target_compile_definitions(${MICROPY_TARGET} PRIVATE DUMMY)
This is an extremely rare occurrence that involves monkeying around with MicroPython tooling while trying to bring up a CMake-ified embed port, but I'm raising it here for posterity.
It may be worthwhile adding a check for ${MICROPY_CPP_DEF} STREQUAL "MICROPY_CPP_DEF-NOTFOUND" and skipping the loop that appends MICROPY_CPP_FLAGS.
Code of Conduct
Yes, I agree
py/mkrules.cmake: Force build mpversion.h and frozen_content.c.
This ensures that all builds unconditionally run makeversionhdr.py and makemanifest.py to generate mpversion.h and frozen_content.c respectively. This now matches the Makefile behavior, and in particular this fixes the issue on ESP32 builds that changes in code-to-be-frozen will cause the build to update. Both these already tools know not to touch their output if there is no change.
Fixes #7753 (and several reports in discussions)
This work was funded through GitHub Sponsors.