Building in debug mode has multiple issues (fixes inside)

[ctrlcctrlv]

The script doesn't install $BINARY/gdb-{32,64}.exe. We need this patch:

diff --git a/ffbuild.sh b/ffbuild.sh
index 4e3edbf..648d808 100644
--- a/ffbuild.sh
+++ b/ffbuild.sh
@@ -541,7 +541,7 @@ if (($makedebug)); then
     log_note "Adding in debugging utilities..."
     cp -f "$PATCH/ffdebugscript.txt" "$RELEASE/" || bail "Couldn't copy debug script"
     cp -f "$PATCH/fontforge-debug.bat" "$RELEASE/" || bail "Couldn't copy fontforge-debug.bat"
-    cp -f "$BINARY/gdb-$ARCHNUM.exe" "$RELEASE/bin/gdb.exe" || bail "Couldn't copy GDB"
+    cp -f "/$MSYSTEM/bin/gdb.exe" "$RELEASE/bin/" || bail "Couldn't copy GDB"
     cp -f "$BINARY/wtee.exe" "$RELEASE/bin/" || bail "Couldn't copy wtee"
     cp -rf "$DBSYMBOLS" "$RELEASE/bin/" || bail "Couldn't copy debugging symbols"
 fi

wtee.exe is missing. I have no idea what it does, but putting this 2008 version in $BINARY fixed the problem for me.

The gdb data directory isn't detected for some reason, perhaps as a consequence of my decision to use MSYS2's gdb. Fix by running as e.g.:

./ReleasePackage/bin/gdb.exe --data-directory=/mingw64/share/gdb ./ReleasePackage/bin/fontforge.exe

Would you like a "Building on Windows" page on the FontForge wiki @jtanx ? I could write it.

[ctrlcctrlv]

I have another suggestion too @jtanx: because we are requiring users use the mingw64 GDB, and not the MSYS2 GDB, it will, as you noted on the Sourceforge wiki, not allow you to do certain things, such as deal with prompts. You incorrectly guessed that this was the fault of readline: no, it's because gdb.exe, like mingw64 Python REPL, etc., is expecting to be run in cmd.exe (or PowerShell, I suppose). Problems you didn't notice include ^D not working and arrow keys not working.

I recommend that we tell users who wish to debug to build in mintty.exe, but run in cmd.exe as:

cd c:\path\to\fontforge\bin
set PATH=C:\msys64\mingw64\bin;%PATH%
gdb.exe --data-directory=c:\msys64\mingw64\share\gdb fontforge.exe

I further recommend we tell users to download the MS-DOS console version of vim.exe to e.g. D:\vim82.

[ctrlcctrlv]

@frank-trampe Can you please make it possible to open issues on the repo in our organization? I'm not able to do so.

[jtanx]

When debugging, I never use the ReleasePackage folder any more, especially so since cmake. I cd into ffbuild/work/mingw32/fontforge/build and run or gdb fontforge directly out of there (I usually just call ffbuild once to configure the build, then cd in and run ninja directly). And yes, I normally use winpty too (which gets around having to use cmd.exe for interrupts to open).

The gdb in ReleasePackage was only ever used once or twice for debugging some issues (and where they likely could not build it themselves).

As for why I have issues here, this started out as a personal, unofficial project, but somehow eventually also became the official solution. Since I already had issues here, and I was effectively the only contributor, I've never bothered pushing the issues into the fontforge fork (which I basically just keep in sync with this repo, if I'm testing stuff out then I leave it behind). Note I still maintain the sourceforge builds from time to time.

[ctrlcctrlv]

@jtanx Thanks for the tips. I'd never heard of winpty, I ought to give that a try. I wrote fontforge/fontforge#4357 by just switching back and forth between mintty.exe and cmd.exe. Not the best experience, but it worked.

I also have been using the ReleasePackage dir. Your method seems sound though, and probably results in faster builds. Next time :-)

[frank-trampe]

It sounds like the sub-issue is resolved, but @jtanx understands the issue better than I do and can fix the configuration issue if still necessary.

[jtanx]

Sorry about the noise.

Edit:
Oh, now I remember, the other reason why the bash script is how it is is that I used to distribute with Equation's GDB because the msys2 gdb used to be broken, particularly on 32 bit.