search

atlassian / bazel-tools

Reusable bits for Bazel
Apache License 2.0
113 stars 36 forks source link

Remove cfg host. #44

Closed Globegitter closed 5 years ago

Globegitter commented 6 years ago

Having cfg="host" caused some of our transitive dependencies to be rebuilt unnecessarily. Even though I am not entirely sure why reading here: https://docs.bazel.build/versions/master/skylark/rules.html#configurations, it states Otherwise, executables that are used at runtime (e.g. as part of a test) should be built for the target configuration. In this case, specify cfg="target" in the attribute..

That sounds to me quite clearly that if we want to set it then we should set it to cfg="target". What do you think?

ash2k commented 6 years ago

I believe the current value is correct. bazel run runs the binary it on the same machine where bazel is executed. So that binary and all the transitive binaries that are executed by that binary must be built for the host platform/configuration.

https://docs.bazel.build/versions/master/skylark/rules.html#configurations, it states Otherwise, executables that are used at runtime (e.g. as part of a test) should be built for the target configuration. In this case, specify cfg="target" in the attribute..

This is really confusing. Tests are executed on the host machine (or, in case of the remote execution, on the remote machine) but not on the target. 😕

Also see this page https://docs.bazel.build/versions/master/platforms.html

I think we need someone who actually understands it all very well to explain what we should do here. So far I think we've ran into a current limitation of Bazel where it is not possible to properly express what we want to do. See the discussion in the email thread I linked in the other PR.

ash2k commented 6 years ago

It is not clear to me how platforms and the cfg attribute interact.

ash2k commented 6 years ago

Don't get me wrong please, I'd like to get this issue fixed, but I'm afraid it is not possible with todays Bazel. But I'm also not an expert, so maybe I'm just missing something.

Globegitter commented 5 years ago

@ash2k Sorry for the long silence - I have been a bit more busy the last two weeks than I had hoped. As far as I understand target and host can be the same thing and specifying cfg = target can still mean that it is compatible with the host, if your target is the host. cfg = host seems to me for things that should always run on the host like a compiler or code generator etc. Which does not seem to me like that is what we want for commands (maybe we want to execute these commands on a different host).

There is also an interesting note on this problem here: https://github.com/vistarmedia/rules_js#a-word-about-bazel-configurations

Having said all that, I am not an expert on this either and getting someone else to weigh on this would probably be beneficial. And as a note, internally we are running this now with cfg = host removed and we have not had any issue so far.

ash2k commented 5 years ago

@Globegitter

And as a note, internally we are running this now with cfg = host removed and we have not had any issue so far.

Are you doing cross-compilation in that case? Because that is where I expect it to break. e.g. target is linux_amd64 but host is darwin_amd64 in my case. And obviously I'll not be able to run a linux binary on mac.

Globegitter commented 5 years ago

@ash2k I have indeed not tried it on a mac - I will get one of our macs and provide you with some feedback.

ash2k commented 5 years ago

Please re-open if you have new information.

Globegitter commented 5 years ago

@ash2k This is coming up now again. To me cfg=target still seems correct because the binary is only executed using bazel run. So in the case of doing cross-compilation I would want this binary to be able to run on my target platform and not my host platform. Why do cross-compilation then? Then just compile the target for your local platform. Or maybe there is something obvious I am missing here.