native "<target>" "<path>" in a package's package.ludic; the compiler records the libraries of every package a program imports and writes them into the IR (; ludic-native:), so ludicc -o, ludic build, ludic test and ludic bundle all link one list. macOS: an rpath to the package and to Contents/Frameworks, where ludic bundle copies and signs each library and drops the build machine's rpath. Windows: the import library, the .dll copied beside the exe (--natives-out for the bundle). tools/native/lib.sh builds from a pinned, checksummed source with clang on both machines; ludic.nativeecho is the worked example; the shim rules are in packages/README.md. Linked at build time rather than dlopen (docs/PACKAGES.md says why). Reseeded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
10 lines
721 B
Markdown
10 lines
721 B
Markdown
bump: minor
|
|
type: feat
|
|
**A package can carry a native library.** `native "<target>" "<path>"` in a package's
|
|
`package.ludic` names a C/C++ library per target (`macos-arm64`, `windows-x64`, ...). The
|
|
compiler records the libraries of every package a program imports, and every link - `ludicc -o`,
|
|
`ludic build`, `ludic test`, `ludic bundle` - links them: on macOS with an rpath to the package
|
|
and to `Contents/Frameworks`, where `ludic bundle` places and signs them; on Windows through the
|
|
import library, the `.dll` copied beside the executable. `tools/native/lib.sh` builds a library
|
|
from a pinned, checksummed source; `ludic.nativeecho` is the worked example, and
|
|
`packages/README.md` says what a shim may pass across.
|