| Message ID | 20200604205226.14518-1-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [for-4.14,RFC] docs/support-matrix: Gross bodge to unbreak docs rendering | expand |
On 04/06/2020 21:52, Andrew Cooper wrote: > The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a > while. commitish_version() pulls an old version of xen/Makefile out of > history, and uses the xenversion rule. > > Currently, this fails with: > > tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory > > which is because the Makefile legitimately references Kbuild.include with a > relative rather than absolute path. > > Rearrange $CWD of the make rune to be in xen/ > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > --- > CC: George Dunlap <George.Dunlap@eu.citrix.com> > CC: Ian Jackson <ian.jackson@citrix.com> > CC: Jan Beulich <JBeulich@suse.com> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Wei Liu <wl@xen.org> > CC: Julien Grall <julien@xen.org> > CC: Anthony PERARD <anthony.perard@citrix.com> > CC: Paul Durrant <paul@xen.org> > > This is obviously not a proper fix. It will break in an unfixable way if we > ever delete a file from the xen/ build system. > > I don't think pulling a makefile out of history and expecting it to work in > the current working tree is a reasonable expectation. Actually - it occurs to me that we only want the major and minor number. I think it is reasonable to expect that those will always be plain numbers, and we can grep them directly out of the file, rather than feeding the thing to make. Thoughts? ~Andrew > --- > docs/support-matrix-generate | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate > index a3d93321f1..2a1c3fad57 100755 > --- a/docs/support-matrix-generate > +++ b/docs/support-matrix-generate > @@ -102,8 +102,8 @@ commitish_version () { > esac > > git cat-file blob "$commitish:$versionfile" >"$tmp_versionfile" > - version=$(make --no-print-directory -C docs \ > - -f "${tmp_versionfile#docs/}" xenversion) > + version=$(make --no-print-directory -C xen \ > + -f "../${tmp_versionfile}" xenversion) > case "$version" in > *.*.*) version="${version%.*}" ;; > esac
On 04.06.2020 22:58, Andrew Cooper wrote: > On 04/06/2020 21:52, Andrew Cooper wrote: >> The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a >> while. commitish_version() pulls an old version of xen/Makefile out of >> history, and uses the xenversion rule. >> >> Currently, this fails with: >> >> tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory >> >> which is because the Makefile legitimately references Kbuild.include with a >> relative rather than absolute path. >> >> Rearrange $CWD of the make rune to be in xen/ >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> --- >> CC: George Dunlap <George.Dunlap@eu.citrix.com> >> CC: Ian Jackson <ian.jackson@citrix.com> >> CC: Jan Beulich <JBeulich@suse.com> >> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> CC: Stefano Stabellini <sstabellini@kernel.org> >> CC: Wei Liu <wl@xen.org> >> CC: Julien Grall <julien@xen.org> >> CC: Anthony PERARD <anthony.perard@citrix.com> >> CC: Paul Durrant <paul@xen.org> >> >> This is obviously not a proper fix. It will break in an unfixable way if we >> ever delete a file from the xen/ build system. >> >> I don't think pulling a makefile out of history and expecting it to work in >> the current working tree is a reasonable expectation. > > Actually - it occurs to me that we only want the major and minor number. > > I think it is reasonable to expect that those will always be plain > numbers, and we can grep them directly out of the file, rather than > feeding the thing to make. > > Thoughts? I was about to ask why we don't do that. Jan
Andrew Cooper writes ("Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering"):
> Actually - it occurs to me that we only want the major and minor number.
>
> I think it is reasonable to expect that those will always be plain
> numbers, and we can grep them directly out of the file, rather than
> feeding the thing to make.
>
> Thoughts?
I would be happy with that approach.
The alternative would be to move these settings into a separate
makefile where we promise that support-matrix-generate's assumption
(that you can make -f just-that-file and get sensible behaviour) is
going to be kept true.
Perhaps I should apologise for perpetrating the existing now-broken
code. But there was no less insane official way of getting the
version out without checking out the whole tree...
Ian.
Jan Beulich writes ("Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering"):
> I was about to ask why we don't do that.
When I wrote the code in question, I was afraid that this makefile
would change in a way that would break that approach. Unfortunately
it seems I guessed wrong and instead it changed in a way that broke
the approach I took instead.
So +1 to this.
Ian.
diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate index a3d93321f1..2a1c3fad57 100755 --- a/docs/support-matrix-generate +++ b/docs/support-matrix-generate @@ -102,8 +102,8 @@ commitish_version () { esac git cat-file blob "$commitish:$versionfile" >"$tmp_versionfile" - version=$(make --no-print-directory -C docs \ - -f "${tmp_versionfile#docs/}" xenversion) + version=$(make --no-print-directory -C xen \ + -f "../${tmp_versionfile}" xenversion) case "$version" in *.*.*) version="${version%.*}" ;; esac
The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a while. commitish_version() pulls an old version of xen/Makefile out of history, and uses the xenversion rule. Currently, this fails with: tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory which is because the Makefile legitimately references Kbuild.include with a relative rather than absolute path. Rearrange $CWD of the make rune to be in xen/ Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: George Dunlap <George.Dunlap@eu.citrix.com> CC: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <JBeulich@suse.com> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Wei Liu <wl@xen.org> CC: Julien Grall <julien@xen.org> CC: Anthony PERARD <anthony.perard@citrix.com> CC: Paul Durrant <paul@xen.org> This is obviously not a proper fix. It will break in an unfixable way if we ever delete a file from the xen/ build system. I don't think pulling a makefile out of history and expecting it to work in the current working tree is a reasonable expectation. --- docs/support-matrix-generate | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)