Bug 25716 - Generated doxygen docs cause problems for Windows due to case-insensitive filesystem
Summary: Generated doxygen docs cause problems for Windows due to case-insensitive fil...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: build (show other bugs)
Version: 9.1
: P2 normal
Target Milestone: 10.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-23 18:05 UTC by Freddie Chopin
Modified: 2020-07-18 19:24 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Proposed patch for PR25716 (416 bytes, patch)
2020-06-19 14:18 UTC, Paul Carroll
Details | Diff
Accepted version of patch (447 bytes, patch)
2020-07-08 14:22 UTC, Paul Carroll
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Freddie Chopin 2020-03-23 18:05:32 UTC
Doxygen docs for GDB contain these two files:
frame-apply.html
Frame-Apply.html

Their names differ only in case (their contents are obviously different), so when dumping such package on an case-insensitive filesystem (like quite frequently on Windows) you end up with just one of these files, serving as both.
Comment 1 Paul Carroll 2020-06-19 14:15:29 UTC
We ran into this same problem.  I've identified the problem as being a new @anchor in the gdb.texinfo file.  The solution is to remove the @anchor(frame apply) and then modify the 2 @xref's that refer to that anchor.  When I do that, the 'frame-apply.html' file is not created (using texi2html).  I will attach my proposed patch, which should solve this issue.
Comment 2 Paul Carroll 2020-06-19 14:18:41 UTC
Created attachment 12626 [details]
Proposed patch for PR25716

This patch removes a new @anchor(frame apply) and modifies the 2 @xref's that refer to it, so as to avoid the creation of multiple files that are only different by case.  This will avoid issues with Windows.
Comment 3 Simon Marchi 2020-06-19 15:03:00 UTC
Hi Paul,

Would you mind sending the patch on the gdb-patches mailing list?  Our documentation maintainer will be able to review it there.

See: https://sourceware.org/gdb/wiki/ContributionChecklist
Comment 4 Paul Carroll 2020-06-22 18:04:17 UTC
I posted the patch to gdb-patches.  I guess we'll see when there is a comment.
Comment 5 Simon Marchi 2020-06-22 18:05:17 UTC
(In reply to Paul Carroll from comment #4)
> I posted the patch to gdb-patches.  I guess we'll see when there is a
> comment.

Thanks.  Don't hesitate to ping after ~ 2 weeks if you don't get an answer.
Comment 6 Paul Carroll 2020-07-08 14:22:58 UTC
Created attachment 12687 [details]
Accepted version of patch

It looks like Andrew Burgess accepted my slightly-revised patch yesterday:

https://sourceware.org/pipermail/gdb-patches/2020-July/170256.html

Now to see about getting it applied...
Comment 7 Paul Carroll 2020-07-08 19:11:34 UTC
Eli Zaretskii also cleared the patch today.
https://sourceware.org/pipermail/gdb-patches/2020-July/170270.html

So I would think nothing should prevent applying the patch.
Comment 8 Sourceware Commits 2020-07-13 19:36:11 UTC
The master branch has been updated by Sandra Loosemore <sandra@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ed788fee02b844266283a5faa66ba64c5b4739ea

commit ed788fee02b844266283a5faa66ba64c5b4739ea
Author: Paul Carroll <pcarroll@codesourcery.com>
Date:   Mon Jul 13 12:31:05 2020 -0700

    Fix frame-apply.html collision in GDB manual.
    
    The addition of an anchor for the "frame apply" command was causing
    the HTML documentation to include files named both "frame-apply.html"
    and "Frame-Apply.html", which collide on case-insensitive file
    systems.  This patch removes the redundant anchor and adjusts the two
    xrefs to it.
    
    2020-07-13 Paul Carroll <pcarroll@codesourcery.com>
    
            PR gdb/25716
    
            gdb/doc/
            * gdb.texinfo (Frame Apply): Remove anchor for 'frame
            apply' and adjust xrefs to it.
Comment 9 Paul Carroll 2020-07-15 21:14:18 UTC
I would think this issue could be closed now, although perhaps it depends on whether anyone else has verified the fix.
Comment 10 Joel Brobecker 2020-07-18 19:24:39 UTC
Let's just close it. The author can re-open if he finds it's not fixed
for him.