Hi,
Build environment provisioning (and dependency management) is a larger topic and sub-modules can only solve a small part of it. There is definitely room for improvement in this area, but as far as I can see sub-modules are a sub optimal answer. Some of the issues which came to my mind: 1. The user experience of sub-modules is sometimes quirky. For example it is a headache if you have to switch between branches where one of the branches does not have a specific sub-module. 2. With sub-modules you can not have complex dependencies. I.e.: when one platform needs a dependency and another not, or you need two version of a dependency, or a different version for two platforms. 3. It is easy to see on what the repo having the sub-module depends, but the other direction is not. It is hard to see what is using a module. 4. The validness of tests are limited if you use source code. Longer term it would be nice to allow using tested binaries of tf-m dependencies and sub-modules can not handle this need. 5. Flexibility. If we use sub-modules, then the version control and the dependency handling "layers" get bounded. For tf-m developers this might not be an issue but for integrators it can be.
Can you please explain the problem you see a bit more? Zephyr is using cmake and you could use the External_project or the FetchContent module to get all needed dependencies. Also nothing really stops you to use sub-modules in the Zephyr repo to get tf-m and all it's dependencies.
/George
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Kevin Townsend via TF-M Sent: 26 November 2019 19:23 To: Kumar Gala kumar.gala@linaro.org Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies?
Hi,
I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases.
I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it?
Kevin
On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m@lists.trustedfirmware.org> wrote:
How would a git repo with some submodules preclude any of the things you mentioned? I guess my initial thought is that there would be an “uber” repo in which TFM, CMSIS and mbedcrypto would all be sub-modules.
There’s also the option of using cmake ExternalProject ( https://cmake.org/cmake/help/latest/module/ExternalProject.html?highli ght=external )
Or west
https://pypi.org/project/west/
- k
On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M <
tf-m@lists.trustedfirmware.org> wrote:
Hi,
Initial idea was to keep the external dependencies clearly visible (from
code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed.
'repo' was considered as well, but repo tool doesn't work on
windows(last I checked).
Thanks, Ashu
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Kumar
Gala via TF-M
Sent: 10 July 2019 09:50 To: Andrej Butok andrey.butok@nxp.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies?
There can always be a fork of the sources kept in TF-M repos to handle
the case of needing local modifications for some reason.
- k
On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <
tf-m@lists.trustedfirmware.org> wrote:
Hi Kevin,
Only if 100% of the external project source code is used without
change.
Even if it is valid now, nobody will give you this guarantee in future.
Regards, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Kevin
Townsend via TF-M
Sent: Wednesday, July 10, 2019 10:41 AM To: Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org Subject: [TF-M] Using git submodules for dependencies?
Hi,
I'm currently working on integrating TF-M into Zephyr and getting TF-M
working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library.
Was the idea of git submodules for dependencies considered and rejected? Using sub-modules would reduce the number of setup steps required, and
pair external dependency versions with specific TF-M commits/releases.
There may be a valid reason this approach was rejected, but it seems
like a sensible option on the surface?
Best regards, Kevin Townsend -- TF-M mailing list TF-M@lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca ndrey.butok%40nxp.com%7C04856a3b68604d01153208d705124e6a%7C686ea1d3bc2 b4c6fa92cd99c5c301635%7C0%7C0%7C636983448498201722&sdata=IjOFM44xG bA2Zgrj%2F2VSmHEYLuXvMzqS7HH6h7gekF4%3D&reserved=0
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m