build: Remove bitness suffix from Windows installer #32132

1. 
   hebasto commented at 2:20 pm on March 24, 2025: member

   Since support for 32-bit Windows has been dropped, the suffix is no longer necessary.
2. build: Remove bitness suffix from Windows installer

   Since support for 32-bit Windows has been dropped, the suffix is no
   longer necessary.

   fb2b05b125
3. hebasto added the label Windows on Mar 24, 2025
4. hebasto added the label Build system on Mar 24, 2025
5. 
   DrahtBot commented at 2:20 pm on March 24, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32132.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	l0rinc, hodlinator, laanwj

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

6. in share/setup.nsi.in:1 in fb2b05b125

   0@@ -1,4 +1,4 @@
   1-Name "@CLIENT_NAME@ (64-bit)"
   2+Name "@CLIENT_NAME@"
   

   ---

   ---

   

   l0rinc commented at 2:34 pm on March 24, 2025:

   Does the message below (written 11 years ago) still make sense now that there’s no “64 bit version Windows installer”, just a “Windows installer”?

     MessageBox MB_OK|MB_ICONSTOP "Cannot install 64-bit version on a 32-bit system."

   ---

   

   hebasto commented at 2:49 pm on March 24, 2025:

   Considering the condition that triggers this message, the latter is correct. However, the condition itself may now be outdated.

   This code does not affect the UX, so there’s no harm in leaving it as is for now.

7. 
   l0rinc commented at 2:34 pm on March 24, 2025: contributor

   utACK fb2b05b1259d3e69e6e675adfa30b429424c7625
8. hodlinator approved
9. 
   hodlinator commented at 8:20 pm on March 24, 2025: contributor

   ACK fb2b05b1259d3e69e6e675adfa30b429424c7625

   We still have things like x86_64-w64-mingw32/bitcoin-94967c353ed8-win64-setup-unsigned.exe in build output, but I understand wanting to defer those until later.

10. 
    laanwj commented at 1:32 pm on March 25, 2025: member

    We still have things like x86_64-w64-mingw32/bitcoin-94967c353ed8-win64-setup-unsigned.exe

    i don’t think this is what you mean here, win64 could definitely just be win, but for completeness’s sake: architecture tuples like x86_64-w64-mingw32 are set in stone, there’s no leeway to remove bitness where those are directly included.

11. laanwj approved
12. 
    laanwj commented at 1:35 pm on March 25, 2025: member

    ACK fb2b05b1259d3e69e6e675adfa30b429424c7625 Thought we already made this change long ago, but apparently one was missed.
13. 
    hodlinator commented at 1:45 pm on March 25, 2025: contributor

    i don’t think this is what you mean here, win64 could definitely just be win, but for completeness’s sake: architecture tuples like x86_64-w64-mingw32 are set in stone, there’s no leeway to remove bitness where those are directly included.

    Was thinking x86_64-windows-mingw would be sufficient, and on par with x86_64-linux-gnu. What sets them in stone?

14. 
    laanwj commented at 1:58 pm on March 25, 2025: member

    Was thinking x86_64-windows-mingw would be sufficient, and on par with x86_64-linux-gnu. What sets them in stone?

    gcc (and the mingw project itself, in this case). The idea is that every OS-architecture combination has a unique, unambiguous tuple. In practice there is some ambiguity (this is the magic config.sub deals with, to “normalize” it) but it’s not a good thing to mess with in general.

15. fanquake merged this on Mar 27, 2025
16. fanquake closed this on Mar 27, 2025

    ---

17. hebasto deleted the branch on Mar 27, 2025

Contributors
hebasto DrahtBot l0rinc hodlinator laanwj

Labels
Windows Build system