In my test environment I could not re-create any failure. Can you please provide more details about your case?

After extensive testing no blocking issues could be identified and this effort turned to be a documentation update. See https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/661/
All mentioned cmake versions work fine win the build-system..

Thanks for the PR!

What is going to happen?
We had a discussion with the tech leads and decided to go forward with the current workaround. Meanwhile I contacted the mbedtls team to see when they can fix the issue. When mbdtls is fixed we will disable the workaround and update the documentation and thus support the latest version.

For me this seems to be an mbedtls bug. See: https://github.com/ARMmbed/mbedtls/issues/1496

What CMake version are you using?

As a workaround try to make the path shorter. I refer to the directory where the tf-m, the mbedtls and the CMSIS5 working copy is as "work root" hereafter.
For this on windows:

• you can use the subst command map the work root to a drive letter.
• use the mklink command to link (hard link or junction point) the work root into c:\

Changes in review: https://review.trustedfirmware.org/#/q/topic:Doxygen_support+(status:open+OR+status:merged)

Fix in review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/590/

Note: cmake release CMake 3.9.0-rc1 has an important bugfix for response file handling. Fixing this issue shall be done after build-system is updated to support latest cmake version. See T228.

First:
I wonder what cmake version you used when testing this change. According to my investigations 3.7 and the up-to-date version works different. Also there is an open issue for ARMCLang and response files: See: https://gitlab.kitware.com/cmake/cmake/issues/18457
Please add some details about your tests.

After some investigation there seems to be multiple valid environment variable settings available for Keil. Depending on the license type either no configuration is needed, and Keil "automagically" solves the problem based on licensing configuration done in the IDE, or the environment variables need to be set properly.
In tfm_sw_requirement.md we already state (line 17) "Note* ARM compiler specific environment variable may need updating based on specific products and licenses as explained in ...". I think we can not go further than this, since compiler licensing is out of scope for the project, and we already pointed users to the appropriate source of information.
In reflection of all this I plan to take two actions:

1. The licensing configuration check shall be removed from the build system. The warning shall be eliminated when the environment variables are missing sine this is a valid configuration.
2. Discussion shall be stared to decide how to modify the documentation. It seems to be impossible to come up with something which works for all possible scenarios and licence types, so the change shall focus on making the note mentioned above more visible. In addition it is worth to consider adding a wiki page about this where we list working settings for specific environments.