Hi,

While digging the clean issue brought up by Soby, I started wondering if external dependency handling would be better in a slightly different way. There is a lot of hack in the build system around including the psa-arch test project, mostly to work around cmake limitations on namespaces and symbol separation. A stronger barrier could eliminate the mess. In TS we use the following pattern (let’s call it “Internal Project”):

• External dependencies are fetched with fetch_content()
• Right after the fetch, execute_process() is called to start the build of the component. So external component builds configuration time.
• The project get’s installed into a directory and the main project is using the installed content, possibly through find_package().
• Benefits:
• This gives a stronger separation, elimination any name clash between the main project and the external dependency. Also global settings cannot collide like when a dependency sets CMAKE_BUILD_TYPE.
• Faster main project build times, as external projects are only built once.
• Makes it more “natural” to use an externally built binary for an external component. This might be handy from QA perspective if binary releases are going to happen. (If ever of course.)
• Strong separation could allow using different version of the same tools for components. (i.e. main project is built with GCC, component with IAR.)
• Drawbacks:
• It is harder to develop the external component together with tf-m s tracking changes is more difficult. Might be a problem if debugging tf-m vs external component interaction. This should be rare and might be an acceptable issue.
• It is unnatural to run builds configuration time in cmake world.
• Configuration phase will take longer.
• Since the build happens right where the external component is added (point A), cmake execution flow might need to be different to ensure all information needed to configure the external component is present at point A.
• Since external component is built by a separated cmake run, tool detection happens separate. This means the same tools will be searched for multiple times. Initial cache files can be a workaround.

This is very similar to how external projects work in cmake, but makes better integration possible. The main project can use information from the dependency as it’s source and output files become available configuration time. In turn external project changes are harder to track.

/George