Fix Meson builds for Visual Studio

[fanc999]

Hi,

This PR attempts to update the Meson build files to build Glyphy with Visual Studio (and possibly others compilers that attempt to be MSVC-like such as clang-cl), by doing the following:

Please note that this depends on PR #46 for a complete build and currently supports static builds only. DLL builds are for another PR (#48). I will try to look at converting the stringize script into Python, but I think that is for yet another PR. So a shell script interpreter from Cygwin or MSYS2 is required at the moment.

• Use CMake to find FreeType, which uses a different naming (and versioning scheme, if we use that in the future). Basically, it does the manual header and .lib search for us in a rather decent and comprehensive way. Not sure about GLUT or GLEW though, although I was able to have Meson find them on my system without further intervention. HarfBuzz, on the other hand, has the pkg-config files we need from its Meson build.
• Define NOMINMAX since we don't want min and max defined in windows.h to get in our way.
• Define _USE_MATH_DEFINES since we need access to the _M_SQRT* (and so forth) macros in math.h as supplied from Visual Studio.
• Save some time for MSVC builds by not checking for CXXFlags or linker flags that are clearly for GCC-esque compilers.

With blessings, thank you!

[eli-schwartz]

• Use CMake to find FreeType, which uses a different naming (and versioning scheme, if we use that in the future).

Hmm, that seems like a bug which freetype2 should fix.

On the other hand, freetype2.pc is installed by the cmake build as well, so it should be usable even on Windows...

[fanc999]

Hi @eli-schwartz,

Yes, I am aware of that, but then the pkg-config files installed by FreeType's CMake build system is not workable out of the box, for instance, it expects zlib.pc, which does not come automatically from ZLib's build system for Visual Studio. I am not too confident in tinkering with that since that is also shared with its autotools build system.

CMake has a built-in mechanism to help us find FreeType1, so I think the naming would be on their side, not FreeType.

Thanks for the notes though.

[eli-schwartz]

CMake does NOT have a builtin mechanism to find FreeType. It doesn't have a builtin mechanism to find freetype either, which is what this PR implements. It does have a builtin mechanism to find Freetype.

(Why does freetype's upstream CMakeLists.txt install freetype-config.cmake and freetype2.pc, instead of freetype2-config.cmake and freetype2.pc? This is definitely on the freetype side, not the CMake side.)

(Yes, Windows optionally supports case sensitive filesystem handling, this distinction actually does matter.)

Anyway, Meson 0.60.0 allows specifying multiple names for a dependency, for e.g. when pkg-config and cmake names disagree. This would have also allowed adding freetype as a meson subproject, which the current version does not allow since on Windows it will always do dependency('freetype') and that does not match the name of the dependency which freetype's meson.build exports.

Incidentally use of subproject wraps would allow building both freetype and zlib through the standard dependency names, irrespective of zlib's build system for Visual Studio. :)

[fanc999]

Hi @eli-schwartz,

Actually, it does :). If you will, you can see a FindFreetype.cmake in the CMake installation directory, under $(CMAKE_INST_DIR)\share\cmake-$(CMAKE_VERSION)\modules, which is what CMake uses to find FreeType, which is actually manually locating the FreeType headers and .lib's in our case. So, to prove things, I took out the (non-working) freetype2.pc (sadly, subproject wraps have patches to the deps that help in the pkg-config regard, but they would not have existed in the vanilla sources), and moved away the CMake config files for FreeType from $(prefix)\lib\cmake, this is what I got, as in the attached file, indicating FreeType was indeed found by CMake.

meson-ft2-snippet.txt

If at one point we do require Meson 0.60.0 or later, I think we could use the multiple names you suggested, which I think is a reasonable way for this situation.

Thanks though.

[eli-schwartz]

Again, that is "Freetype", with exactly title casing, no lowercase and no caps in the middle of the word.

Also again, Windows has optional case sensitivity, so you cannot rely on using the incorrect case and having it work anyway.

That's the first point I was trying to make here.

The second point I was trying to make is that your PR causes a regression for users who include libglyphy as a subproject wrap together with freetype2. Even though freetype2 is built and linked internally, libglyphy will link a second external copy of all symbols, which will likely clash, because it uses a different dependency name and therefore doesn't respect the global dependency cache.