Closed j3parker closed 4 years ago
"🤷" is a decent reaction to this diff.
This is the problem, as I see it:
cc_binary
which is a rulebazel run
/bazel test
csharp_binary(name="foo")
to have all those C# providers with transitive dep info etc.Solution:
cc_binary
first. It needs to know the relative path to the eventual DLL but only needs it at runtime, not compile timecsharp_binary_private
so that it can use it for DefaultInfo.executable
"Cool" thing: I think if you bazel build foo
it won't compile the C++ wrapper.... only if you bazel run
(or otherwise need DefaultInfo.executable
).
Not important but neat when Bazel does good things.
This relates to issue #71. We need to move these to macros because we need an extra cc_binary target for each DLL to generate a wrapper exe that will run the exe/DLL with the dotnet runtime. This part is a bit messy but easy so I'm doing it in it's own PR.
I'm worried about keeping the documentation up to date: https://github.com/Brightspace/rules_csharp/blob/master/docs/APIReference.md Starlark generates documentation differently for macros vs. rules (rule attributes have "static types" (e.g. label list) unlike macros. As a user of these rules I don't think we want that distinction for these rules. I think it will be easy to hack this because the way we generate docs we have the ability to do basically whatever. We could always generate fake docs-only rules (that don't do anything) that have the right args and docstrings to get Starlark to do what we want. I'm going to open up a separate issue for this because it's a lower priority for me and this change should be docs-neutral anyway.
As a bonus, we will now generate runtime.config.json files for tests which @jimevans noticed we were missing.