On 6/21/23 16:20, Nina Schoetterl-Glausch wrote:
On Wed, 2023-06-21 at 16:07 +0200, Nina Schoetterl-Glausch wrote:
On Tue, 2023-06-20 at 22:44 +0200, Paolo Bonzini wrote:
Il mar 20 giu 2023, 19:35 Nina Schoetterl-Glausch <n...@linux.ibm.com> ha
scritto:
+ modules="$modules $m"
+ grep $m $substat > /dev/null 2>&1 || $GIT submodule status $module
>> $substat
+ else
+ echo "warn: ignoring non-existent submodule $m"
What is the rational for ignoring non-existing submodules, i.e. how do the
arguments to
the script go stale as you say in the patch description?
For example when a Makefile calls the script before the Makefile itself is
rebuilt.
Ah thanks. Can this still happen, roms/SLOF being the only
remaining build time user of submodules,
as per 1f468152fb ("build: remove git submodule handling from main
makefile")? pc-bios/s390-ccw/Makefile explicitly names roms/SLOF,
so if that were removed, the Makefile would
need to be fixed anyway.
Yeah it cannot happen but I'm thinking it's sensible behavior in
principle. It also matches "git submodule update", which doesn't return
an error if the required path is not a submodule.
You mean it succeeds even if roms/SLOF is empty?
Yeah, it does:
%prep
%autosetup -n qemu-%{version}%{?rcstr} -S git_am
Which I does a git init, git add ., git commit, so no submodules exist
and git-submodule.sh ignores every maybe_module.
Also the official source tar does include roms/SLOF, so they won't run into
problems.
I used the spec file with a tar generated by archive-source.sh which doesn't
package roms/SLOF.
How is the official tar generated?
It's generated with scripts/make-release.
Paolo
