Hello Karel,
Am 16.07.23 um 00:07 schrieb Karel Gardas:
Hello,
Christian mentioned Zephyr west tool as one of good/possible candidates
for RTEMS tree modularization especially with regarding to HALs and
other 3rd party libraries.
I mentioned it as one of three tools that I know that solve similar
problems (Google `repo` from Android, `west` from Zephyr and the feeds
from OpenWRT). And clearly I haven't made clear enough what my goal was:
I don't want to suggest that we jump on a random tool and use that. What
I wanted is that we take a look at the reasons why the tools exist and
evaluate whether we - as RTEMS project - have similar problems that have
been solved with the tool. You wanted to avoid the academic debate in an
earlier mail, so I didn't start to go into more details of every reason.
But now there is a second prototype with a different tool so most likely
we have to compare some more.
West has the best documentation why they created that tool:
https://docs.zephyrproject.org/latest/develop/west/why.html
R1. Keeping code out of the main repo. That has advantages and
disadvantages. And I'm not sure what's more important. Main advantage is
that it makes more clear what is RTEMS and what is some external source.
Main disadvantage is most likely that it is a bit more difficult to
integrate it into the release process. If it's only one repo, the
release will be to check out the submodules and archive everything as
one big file. With multiple separate repos, we have to create one file
for every repo. Additionally, a user has to download all archives to
build the release version. So most likely that adds complexity.
R2. Tool, that users can use. Depends quite heavily on the workflow and
use case of the user. RTEMS has a tendency to not adopt new tools
easily, especially if they have to be used by the end user. So that
could be a disadvantage.
R3. Allow to override repos in custom distributions. Not sure whether
that is useful for us as a project.
R4. Continuous tracking of a HEAD or commit-based tracking. Git does the
commit-based tracking and I already said that I wouldn't be happy about
continuous tracking of a branch. So that wouldn't be a reason for me.
From my point of view, what we can learn from that tool is two things:
A) We should take a look whether putting the code in the repo is a
disadvantage in some situations. I think size of releases and licenses
could be two. Licenses can be most likely solved with a clear directory
structure where external libs are in one subdirectory with a good
description.
B) Do we need to support use cases, where a user wants to replace one
submodule version by another version without having to create a private
fork of RTEMS?
C) Do we need to support use cases where we don't want to track fixed
commit IDs but the HEAD of a branch instead?
For Google repo, I didn't find the original reasons. What I did find are
some comparisons with submodules like
https://www.edureka.co/blog/git-submodules-versus-googles-repo-tool
Sounds like the main intention is to make working with multiple repos
simpler and integrate well with Gerrit and Jenkins. Beneath that, they
heavily support tracking HEADs of branches.
Main point to learn:
Again: C)
D) We should be careful how we handle submodules so that the usage is as
simple as possible. So that's part of how we integrate it in our build
system.
E) We maybe can get problems on a future CI/CD integration.
The OpenWRT Feeds: https://openwrt.org/docs/guide-developer/feeds
I think the main reason why they use that are:
1. Allow to track a HEAD of a branch instead of a certain commit ID. Not
something that I would want for HALs.
2. Allow a user to add additional feeds. That's similar to the point 3
of `west`.
I think the main point to learn is basically the same as B) and C).
Best regards
Christian
For comparison with my previous git submodulization of RTEMS/stm32H7
I've also westernized the same in a similar way. Yes, it is intended to
remove CMSIS v4 *just* to proof compilation is working with CMSIS 5 from
outside module! This is just dirty PoC nothing more. A tree structure
looks a bit different as (folowing zephyr example) I keep modules
outside the rtems tree. Hence result for west init command below is tree:
modules/hal/stm32h7/stm32h7xx_hal_driver
modules/hal/stm32h7/cmsis_device_h7
modules/hal/stm32h7/CMSIS_5
rtems/...
So if you like to see thing, then install west:
$ pip3 install --user west
$ export PATH=$PATH:$HOME/.local/bin
go into some testing directory and:
$ west init -m https://github.com/karelfv/rtems --mr
rtems-west-stm32h7-hal rtems-workspace
$ cd rtems-workspace/
$ west update
Compilation again produces working samples. In comparison with git
submodule approach I find west a bit more civilized (user friendly).
Nothing is shooting in my own feet etc.
What may resonate in RTEMS devs is:
- yaml format for module configuration
- west implemented in python3
- west extensible
It probably will not be big issue to implement custom:
- west bsplist
- west bspdefaults
- west configure
- west build
which would just delegate to waf for actual work if needed...
Comments welcome!
Karel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
