Re: [PATCH 0/3] Asciidoctor fixes for 2.48.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 20, 2024 at 06:42:21PM -0800, Junio C Hamano wrote:
> Martin Ågren <martin.agren@xxxxxxxxx> writes:
> 
> > The Asciidoctor build of the documentation regressed a bit with
> > a38edab7c8 (Makefile: generate doc versions via GIT-VERSION-GEN,
> > 2024-12-06).
> >
> > I think these issues and fixes are fairly orthogonal to the recent
> > discussions beginning at [1], with fixes being discussed beginning at
> > [2]. I've tested these here patches on top of that series' v1 [2]
> > rebased onto a38edab7c8, as well as on top of its recent v3 [3] as
> > applied on the indicated base-commit.
> >
> > With these patches, I can use
> >
> >   make USE_ASCIIDOCTOR=YesPlease doc
> >
> > and
> >
> >   ./doc-diff --asciidoctor <...> <...>
> >
> > with similar results as pre-a38edab7c8.
> >
> > On top of current master [4], these patches help, but for "doc-diff",
> > the GIT_VERSION injection is still broken (as expected, that's why
> > [1,2,3] exist). These here patches don't refer to doc-diff or those
> > other patches [2,3] and could go in independently or on top.
> >
> > These patches are based on [3] applied on its indicated base-commit.
> >
> > [1] https://lore.kernel.org/git/20241218113324.GA594795@xxxxxxxxxxxxxxxxxxxxxxx/
> >
> > [2] https://lore.kernel.org/git/20241219-b4-pks-git-version-via-environment-v1-0-9393af058240@xxxxxx/
> >
> > [3] https://lore.kernel.org/git/20241220-b4-pks-git-version-via-environment-v3-0-1fd79b52a5fb@xxxxxx/
> >
> > [4] v2.48.0-rc0-38-gff795a5c5e
> 
> Thanks.  [2][3] are something we have to have before we can tag 2.48
> to have a healthy build with the usual Makefile; so is a working
> Asciidoctor based documentation generation, so building your doc
> toolchain fixes on top of the fixes for 'GIT-VERSION-GEN' does not
> give us any practical problem.
> 
> Thanks for a fix.  Will queue.

Thanks indeed, the changes look good to me.

I guess my key learning is to do largish patch series like the build
refactorings in smaller increments next time. I considered doing it
several times while implementing the series, but shied away from it. I
guess it would have been easier for everyone involved and would have led
to fewer issues though if I did split it up.

So thanks to all the people that are helping out in this context!

Patrick




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux