Undeclared dependency in cc on prelude

[jberdine]

I am seeing build failures that appear to be caused by the cc package implementation using the stdlib without declaring a dependency on it, and doing so creates a circular dependency.

• skiplang/cc/src/utils.sk uses System
• System is defined in skiplang/prelude/src/stdlib/other/System.sk
• System needs the skargo dep line: std = { path = "../prelude" }
• adding that to skiplang/cc/Skargo.toml creates a circular dependency

[beauby]

System needs the skargo dep line: std = { path = "../prelude" }

This is not exact. The behavior of skc is to imply a dependency on std by default (which in practice will be resolved to the libstd.sklib from the tool chain, which breaks the dependency cycle), and declaring an explicit dependency on std should only be needed when using a different version of std (in practice, declaring an explicit dependency on std will allow using a modified std without rebuilding the whole tool chain).

Do you have a reproducible example/CI trace where the build fails?

[jberdine]

Ok thanks for the clarification. Maybe I mis-identified.

The failure is reproducible for me:

• git clean -Xdf
• checkout 05f2646 and build docker images using the bin/build_docker_images.sh script
• checkout 8745e47
• make -C skipruntime-ts build

This fails with the message:

> @skipruntime/[email protected] build
> tsc && skargo build -r --target wasm32-unknown-unknown --lib --manifest-path=../native/Skargo.toml --out-dir=./dist/src/

    Compiling: cc v0.1.0 [lib] (/Users/josh/skip/skiplang/cc)
error: command exited with non-zero status

Caused by:
  process did not exit successfully: `skc` (exit status: 2)
  --- stdout

  --- stderr
  File "/Users/josh/skip/skiplang/cc/src/utils.sk", line 63, characters 6-11:
  Unbound module: System
  61 |     stdout: (String) -> void = _ -> void,
  62 |     stderr: (String) -> void = _ -> void,
  63 |   ): System.CompletedProcess {
     |      ^^^^^^
  64 |     System.popen{

[beauby]

Thanks, looking into it!

[jberdine]

Curiously (to me), the same steps do not fail if building from the commit used for the docker images. But nothing jumped out at me in that PR that would change things here. I figured that before we were just getting lucky with build ordering.