| Message ID | 09f34b27d576d1067cc38eaa202aebebb0478cff.1742317309.git-series.marmarek@invisiblethingslab.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Improve reproducibility of build artifacts | expand |
On Tue, Mar 18, 2025 at 06:01:56PM +0100, Marek Marczykowski-Górecki wrote: > From: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> > > It makes the build reproducible with fileordering flags > > Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> > --- > docs/xen-headers | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/xen-headers b/docs/xen-headers > index 8c434d77e20e..98ffe814500b 100755 > --- a/docs/xen-headers > +++ b/docs/xen-headers > @@ -331,7 +331,7 @@ sub output_index () { > <h2>Starting points</h2> > <ul> > END > - foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} or $a->{Title} cmp $b->{Title} } @incontents) { > + foreach my $ic (sort { $a->{Href} cmp $b->{Href} } @incontents) { Why is `Seq` been ignored? As I understand, the index is supposed to use it as first ordering key. Comment in that same file: # extra syntax: # `incontents <seq> <shortname> <anchor text html>... # make a table of contents entry; they # will be sorted by increasing seq, and # shortname will be used as the anchor target Also, we already have a fix for reproducible build: e18dadc5b709 ("docs: use predictable ordering in generated documentation") Would it be enough to replace `Title` by `Href` for the second sorting key instead? Thanks,
On Wed, Mar 19, 2025 at 11:19:33AM +0000, Anthony PERARD wrote: > On Tue, Mar 18, 2025 at 06:01:56PM +0100, Marek Marczykowski-Górecki wrote: > > From: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> > > > > It makes the build reproducible with fileordering flags > > > > Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> > > --- > > docs/xen-headers | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/docs/xen-headers b/docs/xen-headers > > index 8c434d77e20e..98ffe814500b 100755 > > --- a/docs/xen-headers > > +++ b/docs/xen-headers > > @@ -331,7 +331,7 @@ sub output_index () { > > <h2>Starting points</h2> > > <ul> > > END > > - foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} or $a->{Title} cmp $b->{Title} } @incontents) { > > + foreach my $ic (sort { $a->{Href} cmp $b->{Href} } @incontents) { > > Why is `Seq` been ignored? As I understand, the index is supposed to use > it as first ordering key. > > Comment in that same file: > # extra syntax: > # `incontents <seq> <shortname> <anchor text html>... > # make a table of contents entry; they > # will be sorted by increasing seq, and > # shortname will be used as the anchor target > > Also, we already have a fix for reproducible build: > e18dadc5b709 ("docs: use predictable ordering in generated documentation") > > Would it be enough to replace `Title` by `Href` for the second sorting > key instead? Hmm, right. It looks like this may be not needed anymore, as long as title is unique (it looks like it is right now).
diff --git a/docs/xen-headers b/docs/xen-headers index 8c434d77e20e..98ffe814500b 100755 --- a/docs/xen-headers +++ b/docs/xen-headers @@ -331,7 +331,7 @@ sub output_index () { <h2>Starting points</h2> <ul> END - foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} or $a->{Title} cmp $b->{Title} } @incontents) { + foreach my $ic (sort { $a->{Href} cmp $b->{Href} } @incontents) { $o .= "<li><a href=\"$ic->{Href}\">$ic->{Title}</a></li>\n"; } $o .= "</ul>\n";