vrmAdapterMocopi's standalone build is unverified since it grew a platform link, so the quality bar's claim is stated rather than measured

[snkmcb]

The quality bar in docs/roadmap/README.md
asks that every bundle "builds standalone against installed packages, not just
composed in the workspace tree", and the mocopi adapter's scaffold commit
(2026-08-09) recorded that it did.

#111 changed what that claim covers and did not re-run the check: the adapter
now links ws2_32 on Windows, and cmake/vrmAdapterMocopiConfig.cmake.in was
edited to explain why no find_dependency accompanies it. Both are exactly the
kind of thing a standalone configure exercises and a composed build does not —
the composed build resolves in-tree targets and never reads the installed
package config at all.

The risk is genuinely low: ws2_32 is a raw SDK library name rather than an
imported target, so there should be nothing for a consumer to resolve. That is a
prediction, and this repository's convention is that a prediction goes in an
issue rather than in a claim.

What closing this looks like

cmake --install build/<target> --prefix <scratch>/prefix --config Release
cmake -S adapters/liveCapture/mocopi -B <scratch>/standalone `
      -G "Visual Studio 17 2022" -A x64 `
      -DCMAKE_PREFIX_PATH="<ost-runtime-prefix>;<scratch>/prefix"
cmake --build <scratch>/standalone --config Release

<ost-runtime-prefix> is pxr_DIR from the workspace CMakeCache.txt. The VS
generator finds its own toolset, so no vcvars and no ost toolchain file — note
that ost env sets no compiler, which is why a Ninja configure under it
fails with No CMAKE_CXX_COMPILER could be found and is not the route here.

Worth doing on a POSIX host too, and there it checks something Windows cannot:
that the absence of a platform link is right. The adapter adds no
Threads::Threads — deliberately, since it carries no DatagramQueue and its
check_boundaries.py allowlist refuses the name — so a Linux or macOS standalone
build is what would reveal a std::mutex-shaped dependency arriving by accident
through motionCore or motionRuntime.

Why this is not urgent

Nothing ships an adapter standalone today: ost 0.21.0 has no per-library
packaging command and adapters are deliberately outside the aggregate product
(WORKSPACE.md §5), which is
tracked separately as a v0.7.0 carry-over. So this is a verification gap in a
stated claim rather than a broken path for a user.

[snkmcb]

The Windows half is measured (2026-08-29), and the premise has moved

Ran the recipe above against main at 2e4156e, outside any ost session.

cmake --install build/cy2026-windows-x86_64-py313-usd --prefix <scratch>/prefix --config Release
cmake -S adapters/liveCapture/mocopi -B <scratch>/build -G "Visual Studio 18 2026" -A x64 \
      -DCMAKE_PREFIX_PATH="<ost-runtime-prefix>;<scratch>/prefix"
cmake --build <scratch>/build --config Release
ctest --test-dir <scratch>/build -C Release

• The installed package configs answered, which is the path a composed build
  never opens: motionCore_DIR, motionRuntime_DIR and liveTransport_DIR all
  resolved into <scratch>/prefix/lib/cmake/…, and pxr_DIR into the runtime.
• Configure and build are clean — the library, mocopi_record, and all six
  test binaries.
• 20 of 20 tests pass in that tree under plain ctest, including the three
  that bind a loopback socket.
• It compiled with a different toolchain than the workspace build: MSVC
  19.51.36256.0 / toolset 14.51.36231 against the runtime's 14.4x. That is
  the second thing a standalone run buys, and worth naming because a stricter
  local toolset has produced a false alarm here before.

The ws2_32 this issue was raised about is no longer on the adapter's link
line. OSC-2 moved the socket into liveTransport, so the adapter links
motionCore, motionRuntime and liveTransport and nothing else, and the
platform names travel in liveTransport's exported target. The prediction the
issue made still came out right — a raw SDK library name costs a consumer
nothing — it is just being made one package further down now.

One correction to the recipe

-G "Visual Studio 17 2022" fails on this host:

CMake Error at CMakeLists.txt:20 (project):
  Generator

    Visual Studio 17 2022

  could not find any instance of Visual Studio.

Visual Studio was upgraded in place to 18 (2026), and
C:\Program Files\Microsoft Visual Studio\2022\ is still there and empty beside
the populated 18\ — the same upgrade and the same empty directory behind the
dumpbin locator fix in the unreleased changelog. -G "Visual Studio 18 2026"
is the current spelling, and a CMakeCache.txt from an earlier attempt has to be
removed rather than reconfigured over.

What the POSIX run is now for, which is more than it was

It is no longer "does the absence of a platform link hold up". Since OSC-2 the
two platforms take different kinds of name:

	link	reached through an installed config by
Windows	ws2_32, a raw SDK library name	nothing — it travels in INTERFACE_LINK_LIBRARIES
POSIX	Threads::Threads, an imported target	find_dependency(Threads), guarded if(NOT WIN32) in liveTransportConfig.cmake.in

So the Windows run exercises the easy half by construction and skips that
find_dependency branch entirely. The POSIX half is an unresolved-imported-target
question — the exact class PR #141 found sitting in both adapters' configs for
osc::osc while all 17 lanes were green, because a composed build and
ost library build resolve every target in-tree and never open a config file.
liveTransport's guard looks right by reading, and reading is what the osc
one had going for it too.

check_boundaries.py now cross-checks each adapter's link line against its
config template, which catches a missing find_dependency. It cannot catch a
present one that does not resolve on the platform it is guarded for. That is what
is left here.