Hello Karel,
Am 16.07.23 um 12:37 schrieb Karel Gardas:
On 7/16/23 10:03, o...@c-mauderer.de wrote:
Of course the revision from two months back has to be available in
the repo. It doesn't really matter whether it's on master because
the code just worked or whether it's a RTEMS specific branch because
adaptions have been necessary.
You "it doesn't really matter" worries me a little bit. I'm not sure
this functionality is even supported hence my question above if you
have tested it yourself.
Yes, I use that regularly. For an (old) example, take a look at a
branch in the repo that I use to test GSoC work:
https://gitlab.com/c-mauderer/rtems-bbb/-/tree/6
I have a libs/rtems-libbsd submodule there that uses the revision
c9474c0b which is on a cm/20200726_fix branch in my clone of
rtems-libbsd. In the .gitmodules the branch is still set to "master".
Despite that, git can find thre right commit ID.
Cool! So it didn't work for me due to (i) my git bug or (ii) my git
doesn't supporting whatever or simply due to (iii) me making silly
mistake somewhere.
Will need to recheck this. Thanks for the info!
Karel
Seems that we are not the only ones with a waf based build system that
want to manipulate submodules:
https://github.com/ArduPilot/ardupilot/pull/3592
The final solution seems to be a bit different. Their wscript in the
latest version has a "--no-submodule-update" parameter. So they decided
to just update the submodules every time. Can be interesting for users
because they don't have to care for outdated submodules if they pull a
new version.
But I think the problem with adding it as a fixed step is, that we have
a problem with the releases. A release tar ball is not a git repo
anymore. So a "git submodule init --update" or similar will not work. We
would need some mechanism to detect whether it's a git repo or not.
Best regards
Christian
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
