On Sun, 19 Jan 2025 at 16:19, Gerald Pfeifer <ger...@pfeifer.com> wrote: > > On Sun, 29 Dec 2024, Jonathan Wakely wrote: > > On Sun, 29 Dec 2024, 13:55 Gerald Pfeifer wrote: > >> something tells me this is not the full extent of this issue. Something > >> to dig into when I find more time. > > I think the explanation for this is simple, and not likely to be part of a > > bigger issue. It should be easy to check, just delete all files under > > doc/html/manual and regenerate them. Any files which are not recreated are > > orphaned and should have been removed by previous commits (as this file > > should have been). > > Indeed, this is one half of the equation. Is this something you could give > a try? (My Docbook stack isn't fully in place.)
I tried it an there are no more orphaned files, so looks like you got 'em all. > > The other challenge, however, is that even when files disappear from > libstdc++-v3/doc/html/ they will still remain on the web site. > > Here is the culprit, from maintainer-scripts/update_web_docs_libstdcxx_git > > # checkout all the HTML files, get down into an interesting directory > git -C $GITROOT archive master $GETTHIS | tar xf - > cd $GETTHIS > > # copy the tree to the onlinedocs area, preserve directory structure > find . -depth -print | cpio -pd $WWWDIR 2>&1 | egrep -v "$FILTER" > > This copies existing files over into the overall web site instead of > properly mirroring it (with rsync or the like). In other words, it's > incremental, no way to ever remove anything. > > Would this work (as we need) if we replace > find . -depth -print | cpio -pd $WWWDIR 2>&1 > by > rsync -ahv . $WWWDIR 2>&1 > ? Is -avh right? Isn't -h the help output? We don't want to delete all the Doxygen-generated files under $WWWDIR. We could do rsync with deletion in the $WWWDIR/manual subdir, but not for all of $WWWDIR.
