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.
>
> >
> > > 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
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?
>
>
> [...]
