At a quick glance this seems to be an m2r bug: https://github.com/sphinx-doc/sphinx/issues/8705. m2r seems to be abandoned, switching to m2r2 might be a workaround, as that seems to have a fix merged.
For now the best might be to stick to the documented package versions. I am wondering if the requirements file should be more strict on Spninx version.

Fix is merged to integration and master. (https://git.trustedfirmware.org/TS/trusted-services.git/commit/?h=refs/heads/main&id=840696b9ac1ba6aa9ccd024ca9dc3b4be12bf837)

Fix is on review here: https://review.trustedfirmware.org/c/TS/trusted-services/+/9379

Blocked by https://developer.trustedfirmware.org/T901

After the initial investigation I found two possible approaches to the task:

Fix merged as daf2efdaa78.

For more context see https://review.trustedfirmware.org/c/TS/trusted-services/+/8310/comment/5e4373b3_998e475f/

Fix is available here: https://review.trustedfirmware.org/c/TS/trusted-services/+/9046

This was introduced by change: d80f856adf59.
That change makes deployments targeting the "arm-linux" environment accept non Linux specific GCC binaries like "aarch64-none-elf-gcc". Since these GCC builds are not bundled with a standard library built with Linux support, compilation errors arise due to missing Linux kernel headers.

I think tags in the subject of the commit message are problematic in general. Since commits are expected to capture "logical unit of change", the granularity of tags and commit scope often mismatches. While not mandated in the "Contributors Guide" sections, some commits indeed use tags already (i.e. libc, spmd, docs, etc..). What if a "logical unit of change" affects multiple components (i.e. a fix affects both libc and spmd)?

This page lists cmake versions available in different Linux distributions.
https://gitlab.kitware.com/cmake/community/-/wikis/CMake-Versions-on-Linux-Distros

In T228#6978, @CJKay wrote:

Snapcraft distributes builds for the latest stable versions of CMake: https://snapcraft.io/cmake

Perhaps consider recommended it be installed through that? On Ubuntu it is as simple as sudo snap install cmake --classic.

Fix has been merged.

I think we shall discuss the issue internally with the team first.

What's wrong with virtualenv? How does it hurt the user experience?

Using pip instead of the Linux distributions package manager is considered bad practice because:

• may end up having two version of a package installed which can trigger problems. (Packages installed by pip are not visible to apt and vice-versa.)
• some pip packages have binary components. Some versions of these components may be not compatible to other binaries installed on the machine. This means only some versions of such pip packages are compatible with a specific distro.

Fix merged.

Patch-set with the fix: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1884/

Fix was merged.

Can you please create a pull request with the fix?

Can you please double check you modification? Line 84-88 should be:

if(_SPHINX_VERSION)
        if(_SPHINX_VERSION MATCHES ".*sphinx-build[^0-9.]*([0-9.]+).*")
		string(REGEX REPLACE ".*sphinx-build ([0-9.]+).*" "\\1" SPHINX_VERSION "${_SPHINX_VERSION}")
	endif()
endif()

Note: there was a patch pushed to work around the issue. See commit: https://git.trustedfirmware.org/trusted-firmware-m.git/commit/BuildMbedtls.cmake?id=a0f505c659e2af2ffa278d215045add711f7f2d8
The workaround only helps when the build is run from git-bash (or Msys/Msys2) or cygwin but will fail when building from cmd.exe (ln command not available).

Process documentation has been merged (https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=5c87323db941c3470eb4d4998981ced8b33cf84c) and process is in place.

Newer versions of sphinx seem to print the version as:

$ sphinx-build.exe --version
sphinx-build 2.1.2

I think the ) character is making the reqexp on this line https://git.trustedfirmware.org/trusted-firmware-m.git/tree/cmake/FindSphinx.cmake#n85 fail to match.
Can you please check if changing line 85 like this helps?: if(_SPHINX_VERSION MATCHES ".*sphinx-build[^0-9.]*([0-9.]+).*")

The same issue seems to affect mbedcrypto and this commit has the fix: https://github.com/ARMmbed/mbed-crypto/pull/118/commits/7346b312e12a54d77608fc6bb8aa3c55cf046d90
In TF-M build instructions (https://git.trustedfirmware.org/trusted-firmware-m.git/about/docs/user_guides/tfm_build_instruction.rst ) the following dependencies are defined:

1. mbedtls v2.7.9
2. mbedcrypto v1.1.0

@jainvikas8: Thank you for volunteering! Please create a patch to fix the documentation.

That's a valid point, the documentation needs to be fixed.

Based on my investigations this is not a bug and no fix is needed.

Summary:

It is wrong to set PLANTUML_JAR_PATH as export PLANTUML_JAR_PATH="~/plantuml/plantuml.jar" and instead export PLANTUML_JAR_PATH=~/plantuml/plantuml.jar shall be used (Note: quotation marks removed).

For the design proposal published to the TSC please refer to the archive of the TSC mailing-list: https://lists.trustedfirmware.org/mailman/listinfo/tsc .

Fix was merged.

Fix was merged.

It seems the fix has been merged to mbedtls development branch. (See it https://github.com/ARMmbed/mbedtls/commit/7346b312e12a54d77608fc6bb8aa3c55cf046d90?diff=unified).
We may be able to update supported mbedtls version after the next mdbedtls release.

I tested the behavior and found the following:

• if GNUARM_PATH is set to point to the /bin directory of the GNUARM install tree, then the compiler is found ok. This behavior is not matching the documentation in FindGnuArm.cmake.
• if GNUARM_PATH is set as mentioned above, but there is another version available on the PATH, then the one on the PATH gets used.

A related change seems to be: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/862/

Turned to be a documentation update task. Fixed in https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/661/ .

No. T95 needs deeper investigation to check what cmake version the fix supports and if all aspects are addressed. Response files not only affect the linker but the archiver too.
There was an important bugfix for response file handling merged into cmake 3.9 so we might need to drop support for anything below 3.10.

The response file problem is another ticket. See https://developer.trustedfirmware.org/T95

and what error do you get?

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.