Skip to content

0.1.0-dev.4

0.1.0-dev.4: Fix: resolve bundled PDFium library from a Pub-workspace root (#5)
@dedickinson dedickinson tagged this 22 Aug 04:04 
When `dart test` runs from a workspace *member* package, the native-assets
pipeline stages the bundled PDFium library to the *workspace root*
`.dart_tool/lib/`, not the package's own `.dart_tool/lib/`. The runtime loader
(`_openLibrary`) previously probed only the current directory's
`.dart_tool/lib/`, so a PDFium call issued from a spawned isolate — which cannot
see the test runner's `LD_LIBRARY_PATH` and so cannot use the bare-name
fallback — failed with `cannot open shared object file: No such file or
directory`.

This surfaced under Dart 3.13 in the kmdb workspace's PDF vault indexing:
`dart test` (run from `packages/kmdb_cli`) stages `libpdfium.so` to the
workspace root `.dart_tool/lib/`, but `_openLibrary` looked in the package dir
and missed it. betto_pdfium's own CI never exercised this because its test
suite injects an explicit dylib path via `nativeDylibPath()`.

- Add `dartToolLibCandidates(startDir, libName)`: walks up from the working
  directory, yielding each ancestor's `.dart_tool/lib/<libName>` nearest-first.
  Covers both the single-package layout (staged in cwd) and the workspace
  layout (staged in an ancestor root).
- Use it in the Linux, macOS, and Windows branches of `_openLibrary` in place
  of the single `$cwd/.dart_tool/lib/` probe.
- Add unit tests for the walk-up (ordering, ancestor inclusion, root
  termination, library-name embedding). The helper is pure and testable, so it
  is not under the platform `coverage:ignore` region.

Version stays at 0.1.0-dev.4; bump to 0.1.0 (WI-9) once CI is green.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Assets 2
Loading