linux-kernel - Re: [PATCH 0/6] Some improvements for the doc build system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250622060015.76a0b29a@foz.lan>
Date: Sun, 22 Jun 2025 06:00:15 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Jonathan Corbet <corbet@....net>
Cc: Linux Doc Mailing List <linux-doc@...r.kernel.org>,
 linux-kernel@...r.kernel.org, Akira Yokosawa <akiyks@...il.com>
Subject: Re: [PATCH 0/6] Some improvements for the doc build system

Em Sat, 21 Jun 2025 13:39:09 -0600
Jonathan Corbet <corbet@....net> escreveu:

> Mauro Carvalho Chehab <mchehab+huawei@...nel.org> writes:
> 
> > Hi Jon,
> >
> > This series contain some patches from my parser-yaml one that
> > aren't directly related to it. It basically addresses some issues
> > at the build system. It also adds a script that I wrote with the
> > purpose of checking backward problems when building against
> > older toolchains.
> >
> > IMO, the best is to merge and apply it before the YAML series.  
> 
> OK, I've applied it, but ... someday, I think the test_doc_build tool
> should be properly documented and put somewhere under tools/testing.

I added a better documentation for the tool at the v2.

With regards to move to tools, I'm not certain about it as I can see
advantages and disadvantages. 

Creating a new directory to have just one tool on it seems overkill
to me. Also, it is easier to type "scripts/..." than 
"tools/testing/build/..." :-)

There is another aspect: while doing conf.py and Documentation/Makefile
cleanup, I noticed that there are still lots of hacks inside them,
that are there from the early days when we adopted Sphinx. Perhaps
it could make sense to move part of the logic there to this new
build tool, which could, for instance, replace the logic inside
scripts/sphinx-pre-install and get rid of some magic at the Makefile
like the one which handles SPHINXDIRS.

So, at least for now, I would prefer to keep it under scripts.

Thanks,
Mauro