Building a static library on Windows

[spl]

I'm trying to build a static library on Windows (using MSVC). Given that I'm not that familiar with cmake and building on Windows, I'm a bit lost in the dark. But perhaps you can help me shed some light on the problem.

First, here's what I run:

$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF ..
$ cmake --build . --config Release

With this, I get a number of errors:

CustomBuild:
  Error copying file (if different) from "C:/Users/travis/build/spl/graphite/build/src/Release/graphite2.dll" to "C:/Users/travis/build/spl/graphite/build/tests/bittwiddling/Release".
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(209,5): error MSB6006: "cmd.exe" exited with code 1. 
...
Link:
  C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\travis\build\spl\graphite\build\tests\examples\Release\clusters.exe" /INCREMENTAL:NO /NOLOGO ..\..\src\Release\graphite2.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:"C:/Users/travis/build/spl/graphite/build/tests/examples/Release/clusters.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Users/travis/build/spl/graphite/build/tests/examples/Release/clusters.lib" /MACHINE:X86 /SAFESEH  /machine:X86 clusters.dir\Release\cluster.obj
cluster.obj : error LNK2019: unresolved external symbol __imp__gr_face_destroy referenced in function _main [C:\Users\travis\build\spl\graphite\build\tests\examples\clusters.vcxproj]
cluster.obj : error LNK2019: unresolved external symbol __imp__gr_make_file_face referenced in function _main
...

Now, if I make the following change (inspired by microsoft/vcpkg#3102 and the fix-static-build.patch):

diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -82,11 +82,13 @@ if (BUILD_SHARED_LIBS)
 endif()
 
 add_subdirectory(src)
+if (FALSE)
 add_subdirectory(tests)
 add_subdirectory(doc)
 if (NOT GRAPHITE2_NFILEFACE)
     add_subdirectory(gr2fonttest)
 endif()
+endif()

the build is successful.

Is that the right change to make? If so, can CMakeLists.txt be updated with flags to support this? If not, what should I be doing differently or what can be done to support a static build on Windows?

[tim-eves]

Do you already have -⁠DGRAPHITE2_NFILEFACE=OFF? I assume so as the examples test shouldn't get built unless that's the case. You can also get a more targeted approach by setting -⁠DGRAPHITE2_NFILEFACE=ON As that will prevent any test code that depends on the fileface from being built (at the expense of being unavailable in your static lib). If you cannot get a clean build and make test with -⁠DGRAPHITE2_NFILEFACE=ON, then there are definitely issues.
I'll try to reproduce here in the mean time.

[spl]

Do you already have -⁠DGRAPHITE2_NFILEFACE=OFF?

The build log shows:

-- File Face support: enabled

I'm building on Travis-CI, so you can see the build history there.

[spl]

With -⁠DGRAPHITE2_NFILEFACE=ON and without the aforementioned changes to CMakeLists.txt, the build still fails. I get 7 errors instead of 124, and most of them are linking errors (LNK2019).

[spl]

Also, I should have mentioned this, in case it matters: Travis-CI is using Visual Studio 15 2017.

[AntumDeluge]

I think I am having the same or a similar issue, but I am building with MSYS2/MinGW. See my report here: msys2/MINGW-packages#5619

Edit: I am trying to build version 1.3.13.

[AntumDeluge]

I was able to resolve my issue by patching the CMake configurations. See here: msys2/MINGW-packages#5619 (comment)

The patch may not work for everyone as there are other patches applied in the MSYS2/MinGW-w64 package before mine. But I was able to come up with it looking over this patch for version 1.3.10.

[spl]

@AntumDeluge Thanks for adding your voice to this issue.

It seems like the changes to CMakeLists.txt are rather straightforward for a static MSVC/MinGW build. Would the maintainers have time to look into this before the next release? @tim-eves?