libmupdf initial port

[glachancecmaisonneuve]

-For some reason the linting process kept nagging at me until I set both VCPKG_LIBRARY_LINKAGE and VCPKG_CRT_LINKAGE to static.
-While creating the port, I saw that sumatrapdf actually builds a non-static version of this library. The source provided by libmupdf.org are all geared towards a static build. The non-static sumatrapdf build of libmupdf seems pretty intricate and involves a custom module-definition file for the linker and something I don't quite grasp yet having to do with a resource file. I guess what I'm asking is "how hard should I try to provide a non-static build" for this port?

[ras0219-msft]

Thanks for the PR!

If the upstream sources seem totally incompatible with a non-static build, then it's fine to simply force the library linkage to static. However, I am somewhat concerned about the linting issue; generally portfiles shouldn't be switching the CRT linkage because it will likely result in unusable binaries.

Since you're providing a replacement buildsystem anyway (the vcxproj), it would be far shorter and cleaner to use CMake. Here are a few examples to show how easy that is to do: [1] [2] [3].

[1] https://github.com/Microsoft/vcpkg/blob/790c3777b7eaf3c8d1894abc2694038e2858141d/ports/speexdsp/CMakeLists.txt
[2] https://github.com/Microsoft/vcpkg/blob/81bb33dc3ee677d4167e0480d1f2d522756e7f24/ports/pqp/CMakeLists.txt
[3] https://github.com/Microsoft/vcpkg/blob/319dd85ebcb248dce51c4e8ea9c94e6e6bdd4d4c/ports/libstemmer/CMakeLists.txt

[glachancecmaisonneuve]

Since you're providing a replacement buildsystem anyway (the vcxproj)

I get that vcxproj at very little cost, by running vcupgrade (or devenv /upgrade) on the provided project, made-for-older-msbuild vcproj. I would script it rather than provide the upgraded project manually I could find a reliable way to do so. Even better would be the ability to force msbuild to build the older vcproj project files but no combination of switches have ever allowed me to do so without first upgrading to vcXproj project file first (this last statement can get confusing since the vcproj extension was recently recycled. I am referring to project files created under visual studio 10 or under).

generally portfiles shouldn't be switching the CRT linkage because it will likely result in unusable binaries

Let me double check on that one.

[glachancecmaisonneuve]

About having to set VCPKG_CRT_LINKAGE:

• What I wrote needs some clarification: I only get linting problems when vcpkg expects a dynamic library but I provide a static one instead of failing. For example the command vcpkg install libmupdf:x64-windows should fail, however it does not by virtue of the port file adjusting the build to static (set VCPKG_LIBRARY_LINKAGE static).
• Asking for (and getting) a static build works without linting issues every time. vcpkg install libmupdf:x64-windows-static
• The resulting packages vcpkg/packages/libmupdf-x64-static and vcpkg/packages/libmupdf-x64 folders and byte-to-byte compare identical.

If I only set VCPKG_LIBRARY_LINKAGE static, the linting process complains that it

Expected Debug,Dynamic crt linkage but [...] got [...] Debug,Static

To me the linking process is as close as you can get to real magic. Any advice on how to proceed further?

[slyshykO]

Maybe this article https://www.codeproject.com/Articles/1190061/Compiling-MuPDF-DLL-to-Render-and-Edit-PDF-Documen can help make a DLL build.

[glachancecmaisonneuve]

I won't make any further modifications on this pull request because I don't have the expertise to maintain a cmake build system for this (or any) library. I also didn't want to close the branch because that would likely mean losing what Robert commited.

[ras0219-msft]

Thanks!