How does (runtime) Bazel obtain the platform repo?

[Jasper Siepkes]

Hi all!

I maintain an Illumos (Solaris fork) port of Bazel [1] and am currently working on updating the port to Bazel 5.1.1 (coming from 4.1.0).

I can build and run Bazel 5.1.1 on Illumos. However when Bazel is executed it ends up with a vanilla 'platform' 0.0.4 repo without the changes to add illumos. I'm having a hard time understanding how Bazel obtains the 'platform' repo when it is executed. The modifications made to the "platforms" definition [2] in the "distdir_deps.bzl" file simply don't carry over to runtime. It doesn't matter if I use the patch directive or point it to a forked repo with changes.

I've verified the platform definition file is still vanilla by checking the contents of "~/.cache/bazel/_bazel_root/7558a64af10a6eb79f74e70211660103/external/platforms/os/BUILD" after Bazel was executed.

Can somebody shed some light on how Bazel obtains the platform definitions during runtime?

[1] https://github.com/siepkes/bazel-smartos/tree/smartos-5.1.1
[2] https://github.com/siepkes/bazel-smartos/blob/78ba57cb1bb4bc0f1600738afb04d141db3b5a12/distdir_deps.bzl#L22

Kind regards,

Jasper

[Tony Aiuto]

+Ara Nguyen 

On Sun, Aug 7, 2022 at 8:31 PM 'Jasper Siepkes' via bazel-dev <baze...@googlegroups.com> wrote:

Hi all!

I maintain an Illumos (Solaris fork) port of Bazel [1] and am currently working on updating the port to Bazel 5.1.1 (coming from 4.1.0).

Nice. Just curious.  Why not 5.2.

 

I can build and run Bazel 5.1.1 on Illumos. However when Bazel is executed it ends up with a vanilla 'platform' 0.0.4 repo without the changes to add illumos. I'm having a hard time understanding how Bazel obtains the 'platform' repo when it is executed. The modifications made to the "platforms" definition [2] in the "distdir_deps.bzl" file simply don't carry over to runtime. It doesn't matter if I use the patch directive or point it to a forked repo with changes.

 

I've verified the platform definition file is still vanilla by checking the contents of "~/.cache/bazel/_bazel_root/7558a64af10a6eb79f74e70211660103/external/platforms/os/BUILD" after Bazel was executed.

Can somebody shed some light on how Bazel obtains the platform definitions during runtime?

There is a bug about this which I can't find right now. Bazel uses a baked in version rather than getting

it from the repo. We're working on that.  The thing we have to do is get the platforms we use for building bazel

decoupled from what users see at runtime.

 

[1] https://github.com/siepkes/bazel-smartos/tree/smartos-5.1.1
[2] https://github.com/siepkes/bazel-smartos/blob/78ba57cb1bb4bc0f1600738afb04d141db3b5a12/distdir_deps.bzl#L22

Kind regards,

Jasper

--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/702593ea-9f1b-4d05-af38-ab9dbbd34c9en%40googlegroups.com.

[Jasper Siepkes]

Hi!

Thanks for your reply! I've added mine inline.

On Monday, 8 August 2022 at 02:56:12 UTC+2 ai...@google.com wrote:

+Ara Nguyen 

On Sun, Aug 7, 2022 at 8:31 PM 'Jasper Siepkes' via bazel-dev <baze...@googlegroups.com> wrote:

Hi all!

I maintain an Illumos (Solaris fork) port of Bazel [1] and am currently working on updating the port to Bazel 5.1.1 (coming from 4.1.0).

Nice. Just curious.  Why not 5.2.

I ported Bazel to Illumos because I need it to build Envoy (on Illumos). So I usually port the versions which Envoy specifically uses. I realize 5.2 should work too in this case but in order to stay on the safe side and not bump in to issues (or better said: even more issues ;-) I usually just stick to the specific version Envoy uses.

 

 

I can build and run Bazel 5.1.1 on Illumos. However when Bazel is executed it ends up with a vanilla 'platform' 0.0.4 repo without the changes to add illumos. I'm having a hard time understanding how Bazel obtains the 'platform' repo when it is executed. The modifications made to the "platforms" definition [2] in the "distdir_deps.bzl" file simply don't carry over to runtime. It doesn't matter if I use the patch directive or point it to a forked repo with changes.

 

I've verified the platform definition file is still vanilla by checking the contents of "~/.cache/bazel/_bazel_root/7558a64af10a6eb79f74e70211660103/external/platforms/os/BUILD" after Bazel was executed.

Can somebody shed some light on how Bazel obtains the platform definitions during runtime?

There is a bug about this which I can't find right now. Bazel uses a baked in version rather than getting

it from the repo. We're working on that.  The thing we have to do is get the platforms we use for building bazel

decoupled from what users see at runtime.

That might even confuse me more ;-). The version which is baked-in is then not the one defined in "distdir_deps.bzl" (as far as I can tell). So where in Bazel's source does it specify where to obtain the platform definitions from to bake-in for runtime? 

Somewhat related: When I did the 4.1.1 port I just changed "distdir_deps.bzl" to use a different platform repo and everything worked as intended. So I'm guessing this is a mechanism which changed in 5.X ?

[Ara Nguyen]

Hi Jasper, 

Please see my answer below in blue

On Monday, August 8, 2022 at 2:56:27 AM UTC-4 jas...@siepkes.nl wrote:

Hi!

Thanks for your reply! I've added mine inline.

On Monday, 8 August 2022 at 02:56:12 UTC+2 ai...@google.com wrote:

+Ara Nguyen 

On Sun, Aug 7, 2022 at 8:31 PM 'Jasper Siepkes' via bazel-dev <baze...@googlegroups.com> wrote:

Hi all!

I maintain an Illumos (Solaris fork) port of Bazel [1] and am currently working on updating the port to Bazel 5.1.1 (coming from 4.1.0).

Nice. Just curious.  Why not 5.2.

I ported Bazel to Illumos because I need it to build Envoy (on Illumos). So I usually port the versions which Envoy specifically uses. I realize 5.2 should work too in this case but in order to stay on the safe side and not bump in to issues (or better said: even more issues ;-) I usually just stick to the specific version Envoy uses.

 

 

I can build and run Bazel 5.1.1 on Illumos. However when Bazel is executed it ends up with a vanilla 'platform' 0.0.4 repo without the changes to add illumos. I'm having a hard time understanding how Bazel obtains the 'platform' repo when it is executed. The modifications made to the "platforms" definition [2] in the "distdir_deps.bzl" file simply don't carry over to runtime. It doesn't matter if I use the patch directive or point it to a forked repo with changes.

 

I've verified the platform definition file is still vanilla by checking the contents of "~/.cache/bazel/_bazel_root/7558a64af10a6eb79f74e70211660103/external/platforms/os/BUILD" after Bazel was executed.

Can somebody shed some light on how Bazel obtains the platform definitions during runtime?

There is a bug about this which I can't find right now. Bazel uses a baked in version rather than getting

it from the repo. We're working on that.  The thing we have to do is get the platforms we use for building bazel

decoupled from what users see at runtime.

That might even confuse me more ;-). The version which is baked-in is then not the one defined in "distdir_deps.bzl" (as far as I can tell). So where in Bazel's source does it specify where to obtain the platform definitions from to bake-in for runtime? 

Somewhat related: When I did the 4.1.1 port I just changed "distdir_deps.bzl" to use a different platform repo and everything worked as intended. So I'm guessing this is a mechanism which changed in 5.X ?

 The platform 0.0.4 repo came from here for Bazel 5.1.1 so the version which is baked-in is the one defined in bazel/distdir_deps.bzl. You mentioned previously about porting Bazel 5.1.1 on Illumos. Do you have a PR link for this that I can take a look at why your patch directive did not work? I recently dealt with patching external deps for Bazel and the ordering in the WORKSPACE file does matter when it comes to patching. 

[Jasper Siepkes]

Hi Ara,

After your reply I decided to go over everything again and long story short; my issue is not a Bazel problem. The issue is caused by the Envoy Bazel build overriding the platform via a transitive dependency on the platform repo. I assumed (<-- my mistake right there ;-) a transitive "platform" dependency wouldn't override the one in Bazel. I worked around it by explicitly adding the modified platform repo to the Envoy build.

Thanks for your help and insights!

Kind regards,

Jasper