On non-Windows, we use libxml2 and llvm/lib/WindowsManifest/ to merge manifests. On Windows, libxml2 usually doesn't exist, so we rely on mt.exe being on PATH. The way forward is probably to use msxml on Windows instead of libxml2, since that's always around. I have prototyped this a bit at https://reviews.llvm.org/D42910 but it's incomplete. Once this is done, lld-link.exe no longer relies on PATH and the only env var it relies on is LIB, which can be passed via /libpath:. So once this is done, no special env needs to be set to be able to run lld-link -- once we have this, we can stop running lld-link.exe under `ninja -t msvc` in the chrome/win build on win hosts. (We already don't need it on non-win hosts.)
Have you considered using XmlLite? It is supposed to be faster than MSXML: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms752838%28v%3dvs.85%29#xmllite-usage-scenarios
IIRC I looked at it and it was a SAX-style parser while MSXML has a DOM mode, which seemed more appropriate for a tool whose purpose is to merge together a bunch of XML trees. Manifest files are tiny, so programming ergonomics is more important than speed. MSXML's ergonomics are pretty bad, but XmlLite doesn't look much better in that regard. I'm not married to MSXML, but it seemed like the least bad alternative to me. It's as always very possible that I missed something :-)
Couldn't we still just use libxml? It doesn't "usually" exist, but we could statically link against it no? Then, if your build environment detects libxml2, it uses libxml2 (same code that is currently in use for the non-Windows path, so no real changes required), if it doesn't it uses mt.exe (same code that is currently in use for the Windows path).
We could. It makes building LLVM harder though, and we'd have to keep the 'libxml not found' codepath around. Imho MSXML has a larger initial cost but is a better end state.
I changed my mind on this and I now agree with zturner's proposal to use libxml (and its dep libiconv). The main reason is that that way, lld-link will produce the same output on linux and on windows, which seems nice.