bazel-ios/rules_ios

Issues w/stardoc + bzlmod: currently runnning stardoc w/o bzlmod

jerrymarino opened this issue · 3 comments

I ran into some unexplainable bugs that didn't exist after rebasing the rules_apple 3.x.x bump on the latest changes which updated stardoc a couple days ago

Please find some of the other issues which are also reported to stardoc: bazelbuild/stardoc#192

Opaque errors when some "bzl_libraries" are missing transitive files

If you revert some of the fixes I made to the "bzl_library" doc targets we have you can find them. It isn't clear why some of these errors are popping and stardoc gives no actionable output to me. Perhaps it's related to the issue below "Mirroring the entire include structure into bzl_library"

This is the largest issue I ran into: with the latest change we broke down several "bzl_library" targets for each file so it is quite easy to run into this situation when changing imports.

Non-actionable errors missing how to import misc files from transitive deps

bazel-out/darwin-opt-exec-2B5CBBC6/bin/docs/app_clip_doc_stardoc '--input=@@//rules:app_clip.bzl' '--?> workspace_name=_main' '--output=bazel-out/darwin-dbg/bin/docs/app_clip_doc.raw')

Configuration: 522a85f38684f2efaef2b90a82a9ce08d5355dfc2131858996e59ade94cbf161

Execution platform: @local_config_platform//:host

com.google.devtools.build.skydoc.SkydocMain$StarlarkEvaluationException: File
/private/var/tmp/_bazel_runner/c2342bca25695567c8c3f3be166b56b3/execroot/_main/bazel-out/darwin-opt-exec-
2B5CBBC6/bin/docs/app_clip_doc_stardoc.runfiles/rules_apple3.0.0/apple/internal/transition_support.bzl imported
'@build_bazel_apple_support//configs:platforms.bzl', yet
/private/var/tmp/_bazel_runner/c2342bca25695567c8c3f3be166b56b3/execroot/_main/bazel-out/darwin-opt-exec-
B5CBBC6/bin/docs/app_clip_doc_stardoc.runfiles/apple_support~1.10.1/configs/platforms.bzl
was not found.
at com.google.devtools.build.skydoc.SkydocMain.recursiveEval(SkydocMain.java:449)
at com.google.devtools.build.skydoc.SkydocMain.recursiveEval(SkydocMain.java:445)
at com.google.devtools.build.skydoc.SkydocMain.recursiveEval(SkydocMain.java:445)
at com.google.devtools.build.skydoc.SkydocMain.recursiveEval(SkydocMain.java:445)

It isn't obvious from the output why exactly is it trying to load this missing file or how should we fix it: /private/var/tmp/_bazel_runner/c2342bca25695567c8c3f3be166b56b3/execroot/_main/bazel-out/darwin-opt-exec- 2B5CBBC6/bin/docs/app_clip_doc_stardoc.runfiles/apple_support~1.10.1/configs/platforms.bzl 🤔

Reference: https://github.com/bazel-ios/rules_ios/actions/runs/6568570441/job/17843180059

We are copying the entire include structure into bzl_library

Every time we have a import it is now seemingly replicated into a bzl_library. We should find a better way around this, as it makes developing on this repo a huge pain with how it is setup.

@luispadron I noticed we ended up closing this out but from my angle but we still don't have a solution to this part

We are copying the entire include structure into bzl_library

Every time we have a import it is now seemingly replicated into a bzl_library. We should find a better way around this, as it makes developing on this repo a huge pain with how it is setup.

Maybe that could be a separate issue/discussion but I left a comment here about how we could generate these declarations: #785 (comment)

I dont think we should work around this by creating some large bzl_library though, that seems to go against what others in the community are doing.

Ok thanks, I mainly re-opened the issue because I noticed we still had the problem here, which we started seeing this issue only after updating the dependency

"some large bzl_library" in practice is a marginal number of files; and in-practice I didn't see any downsides to doing this way and it was vastly simpler than introducing another program to generate them like gazelle.