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.
>
> > I'm asking because the fedora spec file initializes a new git repo in order
> > to apply
> > patches so the script exits with 0.
>
> 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.
Not a problem with qemu, I'm just wondering if this behavior is still the most
sensible for git-submodule.sh
[...]
