mirror of
https://github.com/logos-co/logos-plugin-qt.git
synced 2026-08-27 08:51:07 +00:00
Dario LipicarandClaude Opus 5
8846fc5626
externalLibCopies flattens each external library into the module's ./lib so CMake's find_library can see it, but it only ever reads <drv>/lib. A library that follows the WINDOWS convention ships its runtime half in bin/ -- that is CMake's own RUNTIME destination, and what openssl, postgres and every autotools port in nixpkgs do. For those, the staged lib/ ends up holding the import library or the static archive but no .dll, and LogosModule.cmake then hard-fails with "found no companion DLL in .../lib" -- or, worse, silently links the static archive instead. Take that library's own .dll from bin/ as well. Matching only *.dll keeps this inherently Windows-only (no native package ships one in bin/), so no platform flag has to be threaded in and a native build provably cannot pick up a stray executable. Only THIS library's files are copied, never all of bin/: the dependency DLLs that nixpkgs' win-dll-link hook stages there must stay symlinks, created by the postFixup pass below. Copying them as real files would make $out/lib look complete while leaving the Nix closure empty again -- a PE embeds no store paths, so those symlinks are the only thing the reference scanner can see. Verified by cross-building logos-delivery-module for x86_64-windows against a logos-delivery that installs its .dll to bin/: the plugin links the import library, and loads and dispatches on real Windows. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
logos-plugin-qt
The Qt-specific build logic (CMake module, plugin compilation, header generation) as a standalone backend that logos-module-builder delegates to.
This enables swapping the plugin technology without changing the module builder or individual modules.