Build without Bazel

[the-moog]

Is there a possibility to use a simple procedure to build even a minimal Bazel that could build a more complete version, without the very large dependencies, or with a JRE rather than a JDK?

Consider the dilema: I want to be able to use Verible on a cluster system. We have zero admin rights on that system, and can't install binaries. Though we can build from source in our user areas. We have zero write capability outside of that and no way to use namespaces or fusemount

We need to build Verible to match the CPUs on the cluster.

Verible needs Bazel or use nix package manager

Nix wants to write to root owned locations - no joy.

Bazel it is then....

But we can't install a binary. So, we need to build Bazel...

It seems Bazel needs Java/jdk. The required JDK is very new and unsupported by the cluster, which is rarely updated due to the need to support development going back years.

We do have system wide as well as local bison, yacc, etc. IE the rest of the GCC 'build essentials' across multiple version. The cluster uses GNU Environment Modules and runs on RHEL.

Other than taking yet another diversion and attempting to build the entire JDK, is there another route?

[hzeller]

Unfortunately, we currently have not an alternative build system, so bazel it is for now. I suspect a JRE might be sufficient, but have not tested difference JDK vs. JRE.

Bazel does not need to be the latest, we regularly test that it compiles with a slightly older bazel 4 if that helps; though I suspect it might still need a newer Java version than what it sounds like you have available.

An alternative could maybe to use Bazel on a different machine and then cross-compile to your target platform, so that you only have to copy the final artifacts to your cluster. I have never tried that, but this might be something to explore.

We also have binaries x86 and arm64 releases compiled from head from the github CI ( https://github.com/chipsalliance/verible/releases ) for various platforms. Some of them even statically linked for least requirements from the system. They are just binaries in a tar, so you can install them anywhere, no need to be admin. But sounds like you can't use them because of some no-foreign-binaries policy.

[the-moog]

I tried it with the JRE that exists in the RHEL release in use. No joy, it blows up as it tries to build while missing libraries and tools.

I also tried an old JDK and that went as expected. The problem is our division support some very old legacy chips and tools so they don't like upgrading things. :-( I'd have to jump a series of complex hoops to get permission to use a binary. It's possible but, even if granted, could take months (e.g. I asked for git >1.x and that took 6 months). I am verible on WSL fine, but WSL can't run the tool chains as they are licensed to the grid. I'll have to continue editing locally and committing remotely to builds. I hoped to be able to introduce this as a step towards CI and enforcing style and content through some Git Hooks.

Perhaps I'll see if they will install a newer JDK - they are often fine with 'commercial' binaries, just a bit worried (and I agree) about arbitrary apps downloaded from places like GitHub, et al...

Maybe M$/GH will implement some sort of reputable signed build system some day....There may even be money in that somehow....

[hzeller]

Sorry to hear the pain just getting something compiled; I have heard and seen several similar unfortunate stories with engineers working in hardware development tied to very old installations.

Would it be possible to install a modern Linux system on one of your work machines and compile there ? Then you have a fully trusted binary with all the build-process happening on your machine. To be able to copy it to the 'sensitive' machines, you can also fully statically link the binaries, so that you don't rely on shared libraries that are out-dated on the older installation:

bazel build -c opt --config=create_static_linked_executables :install-binaries

Then push the resulting binaries to the limited remote machines. It does sound like you would still face some red-tape in your organization, but since each step is fully traceable, it might be easier to argue (It is even better than the 'commercial' binaries as you have at least compiled all the stuff yourself).

For local editing, you could use the language server to have some local assistance with linting and formatting.

[the-moog]

Would it be possible to install a modern Linux system on one of your work machines and compile there ?

Annoyingly, no, I don't have one. Even if we did we'd not be able to run binaries from it on the grid. Apparently we can get a cloudy VM if we do some sort of dance. I believe the Android devs work that way, but we are way too far in the basement to get that supported. Apart from the embedded systems that we design design and support I either use the grid or WSL. Apparently it used to be easier but since Samsung got hacked our IT have got uber paranoid.

I'd love to have an argument with somebody about this but in such a large organisation it's impossible to even know who to start one with, at least not without raising ones head above the divider and that could go one of two ways.

I have a slight update, in that I found an install of a newer Java, buried in a folder that is not on the list of apps in modules, but it's the runtime not the JDK, so can't be used to build a newer JDK. I tried the old 1.8 JDK and even building a fresh 1.8 it fails in the way only Java can.

I will continue trying to lobby for a newer JDK, as at least the grid is managed by our office rather than the US, though that will change very soon.