openkal-musl 0.3.1: name the implementation by version, because a published package must (#3)

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.

Author: Sunrisepeak

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

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.
 #

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"