Re: [PATCH] git-submodule.sh: allow running in validate mode without previous update

[Nina Schoetterl-Glausch <nsg@linux.ibm.com>]

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 <nsg@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?

> 
> 
> [...]