rules_cc icon indicating copy to clipboard operation
rules_cc copied to clipboard

Require `data` on `cc_sysroot`?

Open keith opened this issue 1 year ago • 8 comments

With cc_sysroot it's valid to provide just something like this:

cc_sysroot(
    name = "sysroot",
    sysroot = "@sdk//:dir",
)

Without actually propagating the files to the actions that rely on this. As far as I can tell the expected use of this is actually do provide the data alongside this:

cc_sysroot(
    name = "sysroot",
    data = ["@sdk//:all_files"],
    sysroot = "@sdk//:dir",
)

Which makes me wonder if this should be required on the cc_sysroot macro to make it more clear what attribute is expected for this?

keith avatar Sep 22 '24 20:09 keith

@matts1 wdyt?

pzembrod avatar Jan 13 '25 11:01 pzembrod

Hmm, I wouldn't normally be opposed to it, but it'd be a breaking change, and there might be some use cases for not providing the data attribute.

Maybe we could add a warning instead of an error?

matts1 avatar Jan 13 '25 12:01 matts1

Also @armandomontanez fyi

pzembrod avatar Jan 13 '25 12:01 pzembrod

Just wondering: Would a warning actually yield a benefit?

If it's a breaking change but the right thing to do, it'd be something for Bazel 9. In that case a warning likely would be a proper first step. Question, since I'm new to the space: If we added a warning, would we have a way of noticing if it triggers for anyone out there, so we could learn whether there is a use case for not providing the data attribute?

pzembrod avatar Jan 13 '25 12:01 pzembrod

Hmm, I wouldn't normally be opposed to it, but it'd be a breaking change, and there might be some use cases for not providing the data attribute.

Oh is there a purpose of having a sysroot without this?

Just wondering: Would a warning actually yield a benefit?

IMO the benefit, and why I filed this at the time, was because when you're ramping up on these rules writing a new toolchain, that not being required but not doing anything seems to be a distraction, so requiring it would clarify the behavior, since it seems like it is always required?

keith avatar Jan 13 '25 18:01 keith

Oops this slipped through my inbox somehow. IMO data should implicitly be set here so you can simply do the obvious thing of

cc_sysroot(
    name = "sysroot",
    sysroot = "@sdk//:dir",
)

After all, this is a helper macro designed to simplify things. From there, either a user-specified data should clobber that default, or it should extend the set of included runfiles. I'm leaning towards clobbering, but no particularly strong preference since it's such a tiny helper.

armandomontanez avatar Jan 13 '25 18:01 armandomontanez

ah yea a default might be nice, but I guess there probably isn't a standard expectation we could have for what that label would be?

keith avatar Jan 13 '25 18:01 keith

Yeah, I think a default would probably be the right solution, since it's non-breaking. You can default it to the sysroot attribute (it has type directory, so it's a valid label).

Oh is there a purpose of having a sysroot without this?

Absolutely, though it isn't common. You can have a sysroot flag declared here, but conditionally include various aspects of it at various times. For example, you could write:

subdirectory(
  name = "includes",
  parent = "@sdk//:dir",
  path = "usr/include",
)

cc_args(
  name = "include_args",
  actions = ["compile_actions"],
  data = [":includes"],
  args = ["-I..."]
  ...
)

cc_args(
  name = "shared_libs_args",
  data = [":shared_libs"],
  actions = [":link_actions"],
  ...

matts1 avatar Jan 13 '25 22:01 matts1