From 58ec484fc11034c00ba23f6dfcdf9838d0060432 Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Thu, 20 Aug 2026 12:06:51 +0800 Subject: [PATCH] openkal-musl 0.3.1: name the implementation by version, because a published package must The manifest named the implementation of openkal for each system by a path. That is right in a working tree that has the three repositories side by side, and it is wrong in a package: a path names a directory that exists where the manifest was written and nowhere else, so a consumer resolving this package from the index was handed a dependency pointing at nothing --- reported as "path dependency 'openkal-linux' has no mcpp.toml", inside the registry's own store. It is named by version now, with the feature travelling beside it, because a program above this library carries no other runtime and that is what the feature states. The defect was found by resolving the package the way a stranger would, from a store with no local copy of it. That check exists for exactly this: a working tree masks every mistake in a manifest's dependencies, because the tree is what the manifest was written against. tools/working-trees.sh rewrites the implementation reference as well as the specification's, so that continuous integration goes on asserting what it is for --- that these sources and that implementation as written today work together --- while the published manifest says what a published manifest must. --- README.md | 2 +- mcpp.toml | 8 ++++---- tools/working-trees.sh | 13 +++++++++++++ 3 files changed, 18 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index d6ac886..55695ce 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ the claim can be checked rather than repeated. ```toml [dependencies] -openkal-musl = "0.3.0" +openkal-musl = "0.3.1" ``` It names no implementation and no platform: a C library is the one consumer that diff --git a/mcpp.toml b/mcpp.toml index 580bd43..8e9da87 100644 --- a/mcpp.toml +++ b/mcpp.toml @@ -1,7 +1,7 @@ [package] namespace = "mcpplibs" name = "openkal-musl" -version = "0.3.0" +version = "0.3.1" description = "musl 1.2.5 redirected onto openkal: one C library, ported once, above every implementation of the specification rather than above one kernel." license = "Apache-2.0" authors = ["mcpplibs"] @@ -23,13 +23,13 @@ openkal = "0.5.1" # # The consequence for a program is that it names this package and nothing else. [target.'cfg(os = "linux")'.dependencies] -openkal-linux = { path = "../openkal-linux", features = ["standalone"] } +openkal-linux = { version = "0.5.1", features = ["standalone"] } [target.'cfg(os = "macos")'.dependencies] -openkal-macos = { path = "../openkal-macos", features = ["standalone"] } +openkal-macos = { version = "0.3.1", features = ["standalone"] } [target.'cfg(windows)'.dependencies] -openkal-windows = { path = "../openkal-windows", features = ["standalone"] } +openkal-windows = { version = "0.1.1", features = ["standalone"] } # The feature macros musl's own build establishes. # diff --git a/tools/working-trees.sh b/tools/working-trees.sh index ca61c14..4bb618a 100755 --- a/tools/working-trees.sh +++ b/tools/working-trees.sh @@ -69,4 +69,17 @@ point() { point "$here/mcpp.toml" point "$beside/$implementation/mcpp.toml" +# And this package's own reference to the implementation. It names a version, +# because a published package must: a path names a directory that exists in the +# working tree it was written in and nowhere else, and a consumer resolving from +# the index would be handed a manifest pointing at nothing. The feature travels +# with the version, because a program above this library carries no other +# runtime and that is what the feature states. +impl_path="$(native "$beside/$implementation")" +sed "s|^$implementation = .*$|$implementation = { path = \"$impl_path\", features = [\"standalone\"] }|" \ + "$here/mcpp.toml" > "$here/mcpp.toml.next" +mv "$here/mcpp.toml.next" "$here/mcpp.toml" +echo "pointed this package at $implementation's working tree" +sed -n '/^\[target/,/^$/p' "$here/mcpp.toml" + echo "$implementation"