MicroPython uses string interning, purpose of this preprocessing which must basically be done after any change to any of the source files is to scan the source for identifiers like MP_QSTR_xxx and then add the representation for string xxx to the header qstrdefs.generated.h. Which in turn is included by the code, so it can resolve MP_QSTR_xxx to the actual string. I'm not sure if you can use another compiler to generate it than the one you're using for building te source.
mpversion.h is another generated header, generated by makeversionhdr.py.

But can't you use the existing makefiles, eventually adding some tweaks? Or at least parts of it? It might be less work than rewriting major parts from scratch.

I have abandon this project due to the complexity of transferring some files (macro's) from Gnu to IAR
This software was not written with professional software engineering in mind and it needs quit lot of work to transfer to another programming environment.
Hope someone ells have time to transfer it to a professional working environment (keill or IAR) as it can benefit many other's

This software was not written with professional software engineering in mind

With all due respect, sorry but that is nonsense. Your claim seems to be "this project doesn't work with my particular toolset so it's bad". Thereby ignoring it does work with a myriad of other, more widespread toolsets. Please correct me if I'm wrong.

It was written for C99. Any proper compiler supporting most of C99 can be used. As such, MicroPython can be compiled with clang, gcc and msvc. And possibly others which weren't tested. To get around some platform/compiler specifics, some parts will be compiled conditionally. Now obvisouly the authors do not have time nor money to buy and test with every single possible comiler out there. So if a new compiler needs to be used possibly some things need adjusting. Calling that a lack of "professional software engineering" is simply incorrect.

Same story for the generation of the header files: written originally to work with a few select compilers, mainly gcc. It took me a relatively small amount of time to get it to work msvc. So instead of complaining there was a lack of professionalism, to me this actually showed the opposite: because of the way this was implemented I could easily get it to work with a completely different compiler than gcc.

Now that was just about compilers. On to the build system. The authors chose gnu make. Not a bad choice seeing how widespread gnu make is. Calling that a lack of "professional software engineering" simply because gnu make does not happen to be that particular - possibly rather obscure - buildsystem which you use yourself, is again incorrect. It would be the same as calling out your project being unprofessional for not using gnu make. Also incorrect. And again note that getting the whole project building and running with a completely different system, msbuild instead of make, was relatively easy. So transferring it to use some other toolset is definitely possible.