Hi,

I tried to dig deeper into this, but the cmake command used by Soby fails for me. " [ 33%] Performing patch step for 'psa_arch_tests-populate' error: patch failed: api-tests/platform/targets/tgt_dev_apis_tfm_an521/nspe/pal_driver_intf.c:128 ... "

It would be nice to understand why cmake fails to clean properly, but well, I cannot deep-dive due to the above. What I wanted to check is if https://cmake.org/cmake/help/v3.15/prop_tgt/ADDITIONAL_CLEAN_FILES.html could be used to get "make clean" remove the psa-arch test binary directory. But:

* I am not sure which build directory is used. I have the feeling we use ${CMAKE_CURRENT_BINARY_DIR}/psa_api_tests and not psa_arch_tests_BINARY_DIR, which would be build\lib\ext\psa_arch_tests-build. Strange. * ADDITIONAL_CLEAN_FILES was introduced in cmake v3.15 and if my memories are correct tf-m allows an older version if not using IAR.

Soby: can you please test if ADDITIONAL_CLEAN_FILES works? This solution would give a more streamlined.

/George

From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Anton Komlev via TF-M Sent: 12 October 2020 23:00 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] New TF-M Build doesn't track config changes

Hi,

Thanks Soby for sorting it out.

Sounds like a right way to go and cleanall shall do that job. For me it looks like an exceptional case while the main scenario for a daily development shall be the one, described by Karl : downloaded dependencies explicitly specified by paths outside of TF-M tree via command line, or via project config file (suggested).

And true, both cases shall be explicitly documented.

Hope it helps, Anton

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 17:29 To: Gyorgy Szing <Gyorgy.Szing@arm.commailto:Gyorgy.Szing@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] New TF-M Build doesn't track config changes

Thanks Karl, Gyorgy for your inputs.

I agree with the principle that `BUILD` shall be only folder the cmake modifies. The trouble is, after a `make clean`, there are still artefacts from the previous configuration which affects the new build and gives the wrong output. Hence the suggestion to introduce a `cleanall` custom target which endeavours to clean the all the remnant config information from previous build and leave auto cloned dependant repositories untouched (or maybe print some status info).

Does that sound like a good plan then ?

Best Regards Soby Mathew

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 12 October 2020 06:29 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] New TF-M Build doesn't track config changes

Hi,

I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too.

So the correct operation (in my opinion) is to make the dependency download work in the following way:

* If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...) * If not cmake shall do the fetch.

This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean.

As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation.

/George

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Karl Zhang via TF-M Sent: 10 October 2020 08:14 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] New TF-M Build doesn't track config changes

Hi Soby,

I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit.

The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario.

-DMBEDCRYPTO_PATH=

-DTFM_TEST_REPO_PATH=

-DMCUBOOT_PATH=

-DPSA_ARCH_TESTS_PATH=

There is an example from CI for build command: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBui...

cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m

BR

Karl

________________________________ From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, October 2, 2020 8:40 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] New TF-M Build doesn't track config changes

Hi,

With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either.

The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below:

/* Build secure regressions test suite */

$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install

/* reconfigure and build PSA Crypto API test suite */

$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install

Built binary is still for regression test suite.

There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this.

Best Regards

Soby Mathew