4 ms·
> I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel By the sake of God no. The last thing I need to compile Qt is a giganti
by adev_ 7y ago
> I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel
By the sake of God no.
The last thing I need to compile Qt is a gigantic framework requiring the JVM.
Plus the fact Bazel has so many side effect that that even quantum physics experiments looks more reproducible: Just try to compile tensorflow and enjoy the fun.
Stick to CMake, thanks.
- weberc2 7y agoI get not wanting a JVM (although all else equal I’ll take the JVM dependency any day over CMake), but how is CMake _more_ reproducible than Bazel? The latter builds in a clean room, Make does not.
- adev_ 7y ago> how is CMake _more_ reproducible than Bazel? Because CMake contrary to Bazel do not break its retro-compatibility in its options and config every two minor versions ? > The latter builds in a clean room, Make does not. Sandboxing should be the concern of the package manager / deployment pipeline, Not the build system concern. That just makes things redundant and painful to debug.
- weberc2 7y ago> Because CMake contrary to Bazel do not break its retro-compatibility in its options and config every two minor versions ? Lol that’s only recently true. CMake was infamous for breaking compatibility. Anyway, Bazel was pre-1.0 until just now, so of course expect some instability. > Sandboxing should be the concern of the package manager / deployment pipeline, Not the build system concern. That just makes things redundant and painful to debug. It makes things specifically very easy to debug. Not everyone enjoys troubleshooting issues on their machine due to their local environment.