Vcpkg port or manual install does not work when cross compiling to Emscripten

[amodiopescefaro]

If you try to use the Vcpkg port of Magnum to cross compile to emscripten there are a lot of roadblocks.

1. corrade_rc is not found, this I think can be solved using vcpkg host dependencies
2. if you patch the first problem and you're able to use it in a project find_package(Corrade/Magnum) will still fail

I don't think this can be 100% solved only in the vcpkg port file, it seems there's something strange in the cross compilation itself.

If i use the project as a submodule (without installing) everything works, but cross compiling it as a library to later include in another project manually or with vcpkg always fails.

[mosra]

Hi, this is something I have to look into. AFAIK you're the first to attempt to use the vcpkg packages on Emscripten, so far vcpkg users were mostly on Windows and a few on Linux/macOS.

1. Yes, I heard of those, but have no idea how to use them, will need to investigate (the vcpkg packages were mostly contributed by external devs, so I'm very far from being a "vcpkg expert", haha).

2. I suppose the main root cause is that Magnum's Emscripten toolchain uses a *.bc extension for libraries but vcpkg does not, which then makes the find_package() fail because even though the libraries are there, the Find module looks for a different extension. This could hopefully be a simple fix in Magnum's Emscripten toolchain — from the top of my head something like the following applied to the toolchains/ submodule could work, assuming you use it in your project as well?

diff --git a/modules/Platform/Emscripten.cmake b/modules/Platform/Emscripten.cmake
index 890e8b0..503d06e 100644
--- a/modules/Platform/Emscripten.cmake
+++ b/modules/Platform/Emscripten.cmake
@@ -21,9 +21,11 @@ set(CMAKE_STATIC_LIBRARY_PREFIX "")
 set(CMAKE_STATIC_LIBRARY_SUFFIX ".bc")
 set(CMAKE_EXECUTABLE_SUFFIX ".js")
 
-# Prefixes/suffixes for finding libraries
-set(CMAKE_FIND_LIBRARY_PREFIXES "")
-set(CMAKE_FIND_LIBRARY_SUFFIXES ".bc")
+# Prefixes/suffixes for finding libraries. Magnum's own Emscripten toolchain
+# uses Foo.bc, but external toolchains (such as libraries built with vcpkg) use
+# the classical libFoo.a, so check for both.
+set(CMAKE_FIND_LIBRARY_PREFIXES ";lib")
+set(CMAKE_FIND_LIBRARY_SUFFIXES ".bc;.a")
 
 # Disable annoying warning about absolute includes
 string(APPEND CMAKE_CXX_FLAGS " -Wno-warn-absolute-paths")

Sorry that it's just a hasty untested patch, but maybe it's enough to fix this part :) What's the timeframe you'd like to have this solved? By the end of the week or early next week I could have more time to look into this and ensure the Emscripten port of the vcpkg package works.

---

Besides that, I feel that I have a responsibility to warn you before you get too dependent on vcpkg for serious work (production builds, ...) — I know of at least three teams that relied heavily on vcpkg for Magnum and other dependencies and ultimately had to switch away or fork it entirely. Basically every vcpkg upgrade broke some package for them and it was just an endless time sink of submitting vcpkg patches, fighting to get them merged, and then discovering that some sweeping change caused the fixes to get reverted again. (Emscripten itself is another unpredictable source of entropy, some versions simply do not work or are backwards incompatible, and I'm not sure if vcpkg can be told to stay on a particular Emscripten version.)

• A middle-ground solution could be to use vcpkg only for 3rd party dependencies and have Magnum & related projects as CMake subprojects. That way you don't need to update vcpkg so often while it's still possible to pull latest Magnum changes without breaking the rest.
• Another option is to have something like a Docker image with a trusted Emscripten version and prebuilt Magnum and other dependencies. I remember @Squareys told me they use Docker internally for Wonderland Engine web builds and I think we could figure out a way how to share this if you'd be interested in going this direction.

[amodiopescefaro]

Hi, thanks for the fast answer.
I'll see if I can try your fix and maybe prepare a PR here or on the vcpkg repo.
About vcpkg after many test I think is the less problematic system because all of them brake something (Hunter, Conan, ...) but at least I can keep a working fork of vcpkg that works and periodically merge the upstream and test as vcpkg has no server side component. And with the last versioning and registry updates I think most of the stability problems are more or less solved.

We can continue to use vcpkg for other dependencies and submodules for magnum for the future, it's not a big deal, but if we're able to standardize just one system for deps in the long term it would be better.

So no big time constraint, it's not a critical issue, we can take all the time needed to find and test the best solution.

Thanks

[mosra]

The above patch that makes lib*.a libraries searched for in addition to *.bc is pushed as of mosra/toolchains@01d78b0, the toolchain submodule is updated since 14477c8.

Updating the vcpkg port to include Emscripten-specific libraries is tracked in #607. I don't think there's anything else to do here, so closing as resolved.