As was basically decided already a while ago, remove - in the simplest
possible way - the archiving of both qemu-s and mini-os from tarball
generation.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is the simplistic approach; I'm sure this could now be done quite a
bit more efficiently. I also expect there's no longer a need to run
./configure ahead of the invocation of this script, but since I have no
idea why it was needed earlier on, I'm not removing that here from the
doc. I further expect that the subtree-force-update-all prereq could
also be dropped from the two involved Makefile goals. As that
intermediate goal isn't used for any other purpose, the question there
would be whether there's any reason to retain it. IOW all cleanup that's
probably better done separately, by someone actually using all of that
machinery.

--- a/tools/misc/mktarball
+++ b/tools/misc/mktarball
@@ -1,6 +1,6 @@
 #!/bin/bash
 #
-# mktarball: Make a release tarball (including xen, qemu, and qemu-traditional)
+# mktarball: Make a release tarball (including just xen)
 #
 # Takes 2 arguments, the path to the dist directory and the version
 set -ex
@@ -29,26 +29,6 @@ mkdir -p $tdir
 
 git_archive_into $xen_root $tdir/xen-$desc
 
-# We can't use git_archive_into with qemu upstream because it uses
-# git-submodules.  git-submodules are an inherently broken git feature
-# which should never be used in any circumstance.  Unfortunately, qemu
-# upstream uses them.  Relevantly for us, git archive does not work
-# properly when there are submodules.
-(
-    cd $xen_root/tools/qemu-xen-dir-remote
-    # if it's not clean, the qemu script will call `git stash' !
-    git --no-pager diff --stat HEAD
-    scripts/archive-source.sh $tdir/xen-$desc/tools/qemu-xen.tar
-    cd $tdir/xen-$desc/tools
-    mkdir qemu-xen
-    tar <qemu-xen.tar Cxf qemu-xen -
-    rm qemu-xen.tar
-)
-
-git_archive_into $xen_root/tools/qemu-xen-traditional-dir-remote $tdir/xen-$desc/tools/qemu-xen-traditional
-
-git_archive_into $xen_root/extras/mini-os-remote $tdir/xen-$desc/extras/mini-os
-
 GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc
 
 echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"

On Thu, Aug 01, 2024 at 05:46:37PM +0200, Jan Beulich wrote:
> This is the simplistic approach; I'm sure this could now be done quite a
> bit more efficiently. I also expect there's no longer a need to run
> ./configure ahead of the invocation of this script, but since I have no
> idea why it was needed earlier on, I'm not removing that here from the
> doc. I further expect that the subtree-force-update-all prereq could
> also be dropped from the two involved Makefile goals. As that
> intermediate goal isn't used for any other purpose, the question there
> would be whether there's any reason to retain it. IOW all cleanup that's
> probably better done separately, by someone actually using all of that
> machinery.

The ./configure step might not be needed anymore since
00691c6c90b2 ("tools: Allow to make *-dir-force-update without ./configure")
and `make src-tarball-release` works without issue, without running
./configure that is.

And yes, `subtree-force-update-all` prereq could be dropped from
"src-tarbal%" targets in this patch. I've just tried, and the produced
tarball is the same without or with the prereq.

As for removing the rule "subtree-force-update-all", I don't think
that's a good idea at all. As long as Xen's build systems is cloning
subtrees we need to keep the rule. Those subtrees aren't going away
anytime soon, especially mini-os for stubdom.

Cheers,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On 02.08.2024 11:29, Anthony PERARD wrote:
> As for removing the rule "subtree-force-update-all", I don't think
> that's a good idea at all. As long as Xen's build systems is cloning
> subtrees we need to keep the rule. Those subtrees aren't going away
> anytime soon, especially mini-os for stubdom.

So you expect people might be using that goal from the command line?
Fair enough to keep it if so. I simply didn't think a goal with this
long a name would be intended for manual use.

Jan

On Fri, Aug 02, 2024 at 11:34:53AM +0200, Jan Beulich wrote:
> On 02.08.2024 11:29, Anthony PERARD wrote:
> > As for removing the rule "subtree-force-update-all", I don't think
> > that's a good idea at all. As long as Xen's build systems is cloning
> > subtrees we need to keep the rule. Those subtrees aren't going away
> > anytime soon, especially mini-os for stubdom.
> 
> So you expect people might be using that goal from the command line?
> Fair enough to keep it if so. I simply didn't think a goal with this
> long a name would be intended for manual use.

Well, there's "subtree-force-update" described in `make help`, intended
to be used by developers. The "-all" variate update every subtree
regardless whether they are enable with ./configure or not. I did confuse the
two when replying, so I don't know if "-all" variate is still useful or
not.

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech