I just noticed that the ESP32 port uses an absolute path for FFCONF_H:

as well as the Zephyr port:

that might be problematic. Is there a specific reason why absolute path is used instead of adding ${MICROPY_OOFATFS_DIR} as include directory and defining FFCONF_H as \"ffconf.h\"?

Is there a specific reason why absolute path is used instead of adding ${MICROPY_OOFATFS_DIR} as include directory and defining FFCONF_H as \"ffconf.h\"?

Because adding that as an include directory adds more files to the header search path, eg ff.h, which could clash with other included files. So making the include absolute makes it much less likely to clash with anything else.

FYI, here's how I'm doing SED escaping. Handles the expressions being changed:

set(FIRST_SED_EXPRESSION "s/^Q(.*)/\"&\"/")
set(SECOND_SED_EXPRESSION "s/^\\\"\\(Q(.*)\\)\\\"/\\1/")

if(CMAKE_HOST_WIN32)
    string(REPLACE "^" "^^" FIRST_SED_EXPRESSION ${FIRST_SED_EXPRESSION})
    string(REPLACE "&" "^&" FIRST_SED_EXPRESSION ${FIRST_SED_EXPRESSION})
    string(REPLACE "^" "^^" SECOND_SED_EXPRESSION ${SECOND_SED_EXPRESSION})
    string(REPLACE "&" "^&" SECOND_SED_EXPRESSION ${SECOND_SED_EXPRESSION})
endif()

...

cat ${MICROPY_QSTRDEFS_PY} ${MICROPY_QSTRDEFS_PORT} ${MICROPY_QSTRDEFS_COLLECTED} | sed ${FIRST_SED_EXPRESSION} | ${CMAKE_C_COMPILER} -E ${MICROPY_CPP_FLAGS} - | sed ${SECOND_SED_EXPRESSION} > ${MICROPY_QSTRDEFS_PREPROCESSED}

@pingemi that is neat, I like it more as it is easier to understand.

Unfortunately, Zephyr port won't build on Windows due to missing QDEFs in qstrdefs.generated.h:

QDEF(MP_QSTR_EACCES, 49719, 6, "EACCES")
QDEF(MP_QSTR_EADDRINUSE, 4375, 10, "EADDRINUSE")
QDEF(MP_QSTR_EAGAIN, 60448, 6, "EAGAIN")
QDEF(MP_QSTR_EALREADY, 5446, 8, "EALREADY")
QDEF(MP_QSTR_EBADF, 41825, 5, "EBADF")
QDEF(MP_QSTR_ECONNABORTED, 43815, 12, "ECONNABORTED")
QDEF(MP_QSTR_ECONNREFUSED, 11322, 12, "ECONNREFUSED")
QDEF(MP_QSTR_ECONNRESET, 64281, 10, "ECONNRESET")
QDEF(MP_QSTR_EEXIST, 44371, 6, "EEXIST")
QDEF(MP_QSTR_EHOSTUNREACH, 9606, 12, "EHOSTUNREACH")
QDEF(MP_QSTR_EINPROGRESS, 41114, 11, "EINPROGRESS")
QDEF(MP_QSTR_EINVAL, 65372, 6, "EINVAL")
QDEF(MP_QSTR_EIO, 42630, 3, "EIO")
QDEF(MP_QSTR_EISDIR, 20389, 6, "EISDIR")
QDEF(MP_QSTR_ENOBUFS, 34787, 7, "ENOBUFS")
QDEF(MP_QSTR_ENODEV, 26550, 6, "ENODEV")
QDEF(MP_QSTR_ENOENT, 25950, 6, "ENOENT")
QDEF(MP_QSTR_ENOMEM, 34212, 6, "ENOMEM")
QDEF(MP_QSTR_ENOTCONN, 55161, 8, "ENOTCONN")
QDEF(MP_QSTR_EOPNOTSUPP, 38828, 10, "EOPNOTSUPP")
QDEF(MP_QSTR_EPERM, 32746, 5, "EPERM")
QDEF(MP_QSTR_ETIMEDOUT, 63743, 9, "ETIMEDOUT")
...
QDEF(MP_QSTR_errno, 4545, 5, "errno")

They do exist in genhdr\qstr.i.last, genhdr\qstr\..., and genhdr\qstrdefs.collected.h but not in qstrdefs.generated.h on Windows. On Linux they are present within everything above and qstrdefs.preprocessed.h with qstrdefs.generated.h.

When missing QDEFs are added, then the build succeeds. Of course, the image won't run as expected that way.

It looks like all missing defines are related to errno.h. However, that header is included on both platforms and QSTR entries are present in genhdr\qstr.i.last from py/moduerrno.c.

Maybe somebody who is familiar with QDEFs generation can point me where to look further?

Correct QDEF's are generated and Zephyr port is successfully built on Windows when

1. sed expressions are fixed
2. "-DMP_CONFIGFILE=<mpconfigport.h>" has escaped < and > (i.e. "-DMP_CONFIGFILE=^<mpconfigport.h^>") - could be a problem for any port that defines MP_CONFIGFILE in a similar way to Zephyr port.

Updated to fix the aforementioned issues. Tested with #9335.

@pingemi I hope you don't mind that I followed suggested way by you for the sed expressions.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 

@GeorgeCGV

Glad you were able to make use of it!

I still have to figure out the right way to get manifest generation working on windows. It embeds the relative paths to each package (as far as I can tell, only for the help command) but doesn't love Windows paths. Currently converting Windows paths to unix paths but the bigger question for me is whether help() displaying paths actually makes sense. Python uses dots for subpackages rather than slashes.

@pingemi didn't get that far yet

It works, but not without issues...

As soon as < and > are escaped in the DMP_CONFIGFILE, the cmake VERBATIM command adds ", that results in the final command with "-DMP_CONFIGFILE=^<mpconfigport.h^>" that breaks the batch command that generates qstrdefs.preprocessed.h during the pre-processor execution.

When custom_command and the rest is modified to work without VERBATIM mode to avoid " around provided MP_CONFIGFILE, the cmake build fails with:

micropython/py/objexcept.c:284:49: error: 'MP_QSTR_errno' undeclared (first use in this function); did you mean 'MP_QSTR_trunc'?

the Q(errno) exists in the qstrdefs.collected.h and it is correctly escaped as "Q(errno)" in the qstrdefs.preprocessed.h. However, when running ninja, then produced qstrdefs.preprocessed.h has invalid define after preprocessor execution:

Q(
# 484 "<stdin>" 3
 (*__errno())
# 484 "<stdin>"
      )

Unfortunately, broken define doesn't appear when running generated command (from build.ninja) directly in the command line.

Without modification of "-DMP_CONFIGFILE=^<mpconfigport.h^>" to be -DMP_CONFIGFILE=^<mpconfigport.h^> the qstrdefs can be generated and the application runs. However, that works only with simple applications as preprocessor command fails.

Able to build and run µPython with lv-bindings with the latest changes.

I've also encountered #9281 and changes from current PR resolve the issue.

The PR stayed open for several years without any traction. The final decision was to move away from the µPython. Therefore, I close the PR.