4 ms·

>generated sources, multi-language projects, and building third-party dependencies from source What is special about how Bazel does these? I have never had a p

>generated sources, multi-language projects, and building third-party dependencies from source What is special about how Bazel does these? I have never had a problem doing any of this in CMake, or Meson. In my experience the only reason to pick any over the other is because they tend to vary wildly in supporting certain compiler toolchains for non C/C++ projects.

gravypod 6y ago
Bazel generates reproducible builds by default and is very cache friendly. It forces hermetic build and test environments; each build/test gets it's own sandbox that only contains and preserves deps and outputs. It's not magically different than CMake and Meson, it just works in a way that I never every think "maybe make clean will fix this". I can trust it to work regardless of the changes. You can also, out of the box, use remote build/test execution & remote caching shared between Devs and CI. It's also VCS aware and uses that to help prune down change sets to make builds faster.
- jcelerier 6y ago
  > It forces hermetic build and test environments; how would that ever work if you want to build software to be packaged in a linux distro where your software has to comply with $VERSION of every library provided by the distro ?
  - steeve 6y ago
    It is focused on producing static (or mostly static) binaries. Obviously not everything can be in the sandbox, but in the Bazel world, it takes over the build of all your dependencies (as it is also a package overlay).
  - gravypod 6y ago
    Bazel isn't really designed for dynamic linking applications. You can include system libraries if you need: https://groups.google.com/g/bazel-discuss/c/Ndd820uaq2U https://groups.google.com/g/bazel-discuss/c/Ndd820uaq2U You'd also need to make sure everything is marked as `linkstatic=false`, but I'm not sure if that would work correctly. But, in the end of the day, you're going against the grain of bazel here. Bazel expects to statically link everything to make distribution to heterogeneous environments simpler.
    - jcelerier 6y ago
      right, but then understand that if someone wants to create a software for which a goal is to be packaged & distributed by e.g. Debian, homebrew, msys2, Fedora, CentOS..., this is an absolute non-starter.
rfoo 6y ago
Haven't used Meson, but if you know a nice way to cross compile a project with generated source I'd like to know. More specifically, I'd like the following things happen: 1. Compile flatc with the host compiler since we have to run it later, the FlatBuffers schema compiler which compiles .fbs schemas to .cpp, just like protoc of protobuf. 2. Run the flatc on all my .fbs schemas. 3. Compile the output of 2 with the cross-compiler for the target. With Bazel it can automatically detect the fact that it is going to run the flatc on the same box so it would be compiled with the host compiler. With CMake it seems impossible since it does not have a concept of "build host", so my current solution is to add the FlatBuffers repo via ExternalProject_Add twice, once for host configuration with a patch to change its CMake target namespace prefix to "flatbuffers_host" (because apparently this is not possible to override later) to avoid name collision, once for the target configuration, then change every reference of flatc in my project to "flatbuffers_host::flatc".

gravypod 6y ago

Bazel generates reproducible builds by default and is very cache friendly. It forces hermetic build and test environments; each build/test gets it's own sandbox that only contains and preserves deps and outputs. It's not magically different than CMake and Meson, it just works in a way that I never every think "maybe make clean will fix this". I can trust it to work regardless of the changes. You can also, out of the box, use remote build/test execution & remote caching shared between Devs and CI. It's also VCS aware and uses that to help prune down change sets to make builds faster.

jcelerier 6y ago
> It forces hermetic build and test environments; how would that ever work if you want to build software to be packaged in a linux distro where your software has to comply with $VERSION of every library provided by the distro ?
- steeve 6y ago
  It is focused on producing static (or mostly static) binaries. Obviously not everything can be in the sandbox, but in the Bazel world, it takes over the build of all your dependencies (as it is also a package overlay).
- gravypod 6y ago
  Bazel isn't really designed for dynamic linking applications. You can include system libraries if you need: https://groups.google.com/g/bazel-discuss/c/Ndd820uaq2U https://groups.google.com/g/bazel-discuss/c/Ndd820uaq2U You'd also need to make sure everything is marked as `linkstatic=false`, but I'm not sure if that would work correctly. But, in the end of the day, you're going against the grain of bazel here. Bazel expects to statically link everything to make distribution to heterogeneous environments simpler.
  - jcelerier 6y ago
    right, but then understand that if someone wants to create a software for which a goal is to be packaged & distributed by e.g. Debian, homebrew, msys2, Fedora, CentOS..., this is an absolute non-starter.

rfoo 6y ago

Haven't used Meson, but if you know a nice way to cross compile a project with generated source I'd like to know. More specifically, I'd like the following things happen: 1. Compile flatc with the host compiler since we have to run it later, the FlatBuffers schema compiler which compiles .fbs schemas to .cpp, just like protoc of protobuf. 2. Run the flatc on all my .fbs schemas. 3. Compile the output of 2 with the cross-compiler for the target. With Bazel it can automatically detect the fact that it is going to run the flatc on the same box so it would be compiled with the host compiler. With CMake it seems impossible since it does not have a concept of "build host", so my current solution is to add the FlatBuffers repo via ExternalProject_Add twice, once for host configuration with a patch to change its CMake target namespace prefix to "flatbuffers_host" (because apparently this is not possible to override later) to avoid name collision, once for the target configuration, then change every reference of flatc in my project to "flatbuffers_host::flatc".