Make Windows build system straightforward to use

[NuraliMedeu]

• [x] Provide a general summary of the issue in the Title above.
• [x] Before you open an issue, please check if a similar issue already exists or has been closed before.

When reporting a bug/issue:

• [ ] Screenshot

  None

• [x] The FontForge version and the operating system you're using

  • FontForge 20201107
  • Windows 11 Pro 21H2 Build 22000.376

• [x] The behavior you expect to see, and the actual behavior

  I expect the Windows build system to compile a fully functioning standalone FontForge executable, just like the build system on any Linux distribution or macOS.

  Instead, if I use option 1 (see below), it builds a nonfunctional fontforge.exe. Using option 2 (see below), it compiles a fontforge.exe that can't work without copying all the DLLs in <MSYS2 installation path>\<environment>\bin into its directory. It's similar to issue #4356, but applies to all DLLs, not just libffi-6.dll.

  Also, the executable's theme resembles Windows 3.1, and following this FAQ at the FontForge Windows builds project's SourceForge page didn't help me.

• [x] Steps to reproduce the behavior

  • Prerequisites
  1. Install Chocolatey on Windows from its official website.
  2. Install MSYS2 via Chocolatey in Administrator PowerShell:

     Admin PS> choco install msys2

  3. Install all the dependencies mentioned in INSTALL.md on MSYS2 via pacman in Administrator PowerShell:

     # pacman --sync --refresh --sysupgrade
     # pacman --sync <environment>-<architecture>-libjpeg-turbo
     # pacman --sync <environment>-<architecture>-libtiff
     # pacman --sync <environment>-<architecture>-libpng
     # pacman --sync <environment>-<architecture>-freetype
     # pacman --sync <environment>-<architecture>-giflib
     # pacman --sync <environment>-<architecture>-gtk3
     # pacman --sync <environment>-<architecture>-libxml2
     # pacman --sync <environment>-<architecture>-pango
     # pacman --sync <environment>-<architecture>-cairo
     # pacman --sync <environment>-<architecture>-libspiro
     # pacman --sync <environment>-<architecture>-python
     # pacman --sync <environment>-<architecture>-ninja
     # pacman --sync <environment>-<architecture>-cmake
     # pacman --sync base-devel
     # pacman --sync <environment>-<architecture>-gettext

  • Option 1: @jtanx's custom Windows build script on MSYS2
  4. Follow all the instructions here starting from step 4.

  5. If your Windows username contains spaces, edit the build script ff-build.sh as follows.

     • Enclose every string variable that contains a path with your user folder in double quotation marks (i.e. "$FFROOT").
     • By default, bash splits strings at any whitespace. To make the for loop at line 535 split the string containing the paths to the required libraries only at newline characters, temporarily set bash's IFS internal field separator variable to '\n':

       IFS=$'\n'
       for f in $fflibs; do
         # ...
       done
       unset IFS

  • Option 2: CMake + Ninja on MSYS2

    4. Follow all the instructions here.

• [x] Possible solution/fix/workaround

  • Organize and configure the Windows build system to be as reliable as the Linux or the macOS one.
  • Merge the required parts of the FontForge Windows builds repo into this one and archive that repo to remove confusion for new users.
  • Clearly document every single step necessary to set up, run, and troubleshoot the Windows build system both inside this repo and on the official website.

When you open an issue for a change/improvement/feature request:

• [x] A description of the problem you're trying to solve, including why you think this is a problem

  The Windows build system for FontForge is confusing and unreliable. The documentation in this repo doesn't clearly explain how to install the build dependencies on Windows, although the easiest way to do it is through MSYS2. (Cygwin and WSL don't count because by default they compile Linux binaries, not Windows ones.)

  Even assuming that a new Windows user of the FontForge repo knows that the guide in this repo's wiki can be followed using MSYS2, the Windows download section of FontForge's official website links to a completely different Windows build guide, which adds to the confusion.

  Also, considering that both of those methods of building FontForge give unsatisfactory results, the user is left bewildered as to how the existing release builds of FontForge for Windows are actually compiled.

  This is a problem because Windows users of FontForge inexperienced in building C projects and/or new to how this project's code is organized cannot reliably build a custom version of FontForge for their needs, such as fully enabling the Python extension modules fontforge and psMat.

• [x] If the feature changes current behavior, reasons why your solution is better

  Despite that abandoning the FontForge Windows builds repo may cause inconveniences for its current users in the beginning, I think it's better for the project in the long run, because it will remove confusion about which repo to use to build FontForge for Windows and will help bring new maintainers for the Windows port of the project.

• [x] Possible solution/fix/workaround

  The same as above.

[jtanx]

Nope, sorry, not going to compile the third party dependencies ourselves just to statically link them. Even if you managed to do that you would still have to contend with all the other resource files.

The build system right now is no more difficult to use as it is on Linux/macOS if you're using msys2; all fontforgebuilds is doing right now is doing a bit extra to make an installer/standalone bundle.

[NuraliMedeu]

Nonetheless, the compiled executable has a Windows 3.1-like theme.

Also, sorry for forgetting to mention this in the issue, but the Python modules fontforge.pyd and psMat.pyd that I compiled didn't work at all.

How can these problems be solved?

[ctrlcctrlv]

The theme issue can almost certainly not be solved to your satisfaction. FontForge does not use Windows’ GUI primitives, from any era. It uses its own primitives. GDraw is themable, but there's no "not reminiscent of 1998" theme.

Regarding #3981, it vaguely reminds me of issue #3981. Is your issue the same?

[NuraliMedeu]

Sorry, I should have been more specific. The executable downloaded from https://fontforge.org has a different theme than the executable that I compiled from the source. I want to know how to theme FontForge so it looks like the release version.

Also, regarding the Python modules, yes, issue #3981 is similar to my situation, but whenever I try to import the modules, the error says something along the lines of the modules being corrupted or invalid (I can't recall the exact message because I don't have access to my computer right now).

[jtanx]

You haven't mentioned how you built it or how you're running it. The theme requires the files from share. If you used the fontforgebuilds script, it would have dumped everything into the ReleasePackage folder.

If you're using msys2 directly, you would need to install it first so that everything is in the right place.

[NuraliMedeu]

I mentioned it in "Steps to reproduce the behavior" above. I tried building it both ways. Using ff-build.sh, even after I edited it to accomodate a user folder with spaces in it, completely failed. The binaries in the ReleasePackage folder ran neither from the File Explorer, nor PowerShell, nor the MSYS2 bash.

When I used MSYS2 directly, I installed the compiled binary, but it didn't launch properly until I copied all of the DLLs from MSYS2 to the the working directory of fontforge.exe.

[jtanx]

Install your msys2 to a path that doesn't contain spaces, you're just asking for trouble with that.

[NuraliMedeu]

MSYS2 is installed outside of my user folder, so its path has no spaces.

[jtanx]

Well in your OP you said you modified your script. Is that still the case? What are the error messages? You haven't posted anything useful to debug anything.

[jtanx]

Also if you've installed it in msys2, you have to launch it from your msys2 shell, not just double click on the binary

[NuraliMedeu]

Well in your OP you said you modified your script. Is that still the case? What are the error messages? You haven't posted anything useful to debug anything.

The fontforgebuilds script uses the path of the cloned repository, which was inside my user folder, hence many paths stored inside the script had spaces in them. I don't place files I work on outside of my user folder, so instead I edited the script to accomodate spaced paths. I had already debugged all of the errors in the script myself, so there is nothing to show here.

Also if you've installed it in msys2, you have to launch it from your msys2 shell, not just double click on the binary

OK, but if I remember correctly, it also didn't run from MSYS2 bash until I manually placed the DLLs.

I forgot some of the specific details like this because I tried building FontForge with Python extensions enabled a few days ago, then deleted my build after I learned that I can use the release build of FontForge with disabled Python extensions to patch my monospace fonts using Nerd Fonts' font-patcher script. Despite my initial problem being solved, I decided to create this issue anyway because I think the build system for FontForge on Windows needs to be at least better documented to avoid such build problems.

[jtanx]

I don't place files I work on outside of my user folder, so instead I edited the script to accomodate spaced paths.

MSYS2 is installed outside of my user folder, so its path has no spaces.

Gee well that's splitting hairs. I've already said that having paths with spaces is just cause for pain, so if you don't want to listen to me then you're on your own there.

I had already debugged all of the errors in the script myself, so there is nothing to show here.

You have literally not posted any error messages or what's not working e.g. with your python modules or how you're using it, so there is nothing I can help you with; I'm not a mind reader.

If you want help you need to be posting logs and as much information as possible, not just 'an error occurred' or 'it doesn't work'.

Like I said, building fontforge in msys2 is as simple as any other package you'll find in that ecosystem. If you don't know how to build and use packages in msys2, that's outside the scope of this project.

[NuraliMedeu]

If you want help you need to be posting logs and as much information as possible, not just 'an error occurred' or 'it doesn't work'.

I will post more information in a few days.

Like I said, building fontforge in msys2 is as simple as any other package you'll find in that ecosystem. If you don't know how to build and use packages in msys2, that's outside the scope of this project.

I agree, but I think that in the CMake guide in this repo's Wiki you should:

1. mention that MSYS2 is recommended for Windows, and
2. put links to relevant outside documentation that explains how to build a package on MSYS2.

This will help inexperienced newcomers like me a lot.

[ctrlcctrlv]

Thank you, that advice sounds reasonable enough, so I added this line to that wiki page:

Note: On Windows, the above commands should be run in MSYS2; ffbuild.sh can help with dependency management (from fontforge/fontforgebuilds).

@jtanx may want to tweak the wording. :-)

[NuraliMedeu]

Thank you very much, @ctrlcctrlv !

[ctrlcctrlv]

I realized while working on another project that even among developers MSYS2 penetration is not as high as I'd assumed, a lot of free software in Win32 expects to be built instead with vcpkg and Visual Studio (MSVC), sometimes Chocolatey. So, I think your intuition that we shouldn't expect developers to be familiar with/assume MSYS2 is right.