151–160 of 180 posts
Earlier quoted context omitted.
Isn’t Bazel jre based? I don’t think that something like Qt will ever go for a build tool that requires the whole java runtime as a dependency. (Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)
Qt is moving to CMake for Qt6, they are already working on it. Qt6 release is planned in a year or so.
Earlier quoted context omitted.
> It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. most projects are using CMake nowadays : https://www.jetbrains.com/research/devecosystem-2018/cpp/
Most _C++_ projects are using CMake, but it has virtually no adoption among other mainstream languages, and given most open source is not C++, CMake definitely doesn't have any strong share of the open source market.
I am going to be hated and downvoted for that but let's go... Bazel, like Bucks and other, try to bring on table a build system / deployment system that is multi-language, multi-platform and developer oriented. A holy Graal that many developer ( like me ) looked for decade and that many (large) organizations more or less tried to do one day (and most failed) It is a good idea. It is a required tool to improve product…
1) bazel can be built with a self contained bundled paired down jvm, and possibly an executable using GraalVM but I don’t know anyone who tried that yet. 2) bazel can do offline compiles, and is actually built to run in sandboxes 3) bazel can act as a build system only and delegate to externa package managers Look at rules_nodejs for example and the managed_directories + yarn_install/npm_install rule 4) depend on alr…
I lost literally weeks of my life to make Bazel work in external build systems for tensorflow and others. And I am apparently not the only one : https://archive.fosdem.org/2018/schedule/event/how_to_make_p...
Then I don't allow you to tell me "not having used it".
All the answers you gave are "fixes" that have been made after the community complained. Fixes that were sometimes not even documented.
Earlier quoted context omitted.
Isn’t Bazel jre based? I don’t think that something like Qt will ever go for a build tool that requires the whole java runtime as a dependency. (Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)
CMake may have a longer history of being used by open source, but Meson has been growing in popularity for some important projects. I definitely prefer Meson to CMake. Bazel is also a great build system, but yeah, the JRE dependency will obviously make it less desirable for some users. Still, I hope people consider it anyways, because its focus on correctness is pretty great.
[0] https://github.com/mesonbuild/meson/blob/27c01dff01832fa9d0c... [1] https://github.com/mesonbuild/meson/issues/97#issuecomment-3...
How’s Bazel documentation these days for people who haven’t worked at Google? In April 2018, I tried to do a quick port of a tiny gsl::span-using toy app to absl::span, but I gave up, because Abseil wanted me to build my app using Bazel and Bazel docs seemed to assume that I already have some context that Googlers would have but I hadn’t. (I emphasize that this was a _quick_ attempt at a toy program and not about mak…
Earlier quoted context omitted.
> 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.
I 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.
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.
Earlier quoted context omitted.
> It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. most projects are using CMake nowadays : https://www.jetbrains.com/research/devecosystem-2018/cpp/
Most _C++_ projects are using CMake, but it has virtually no adoption among other mainstream languages, and given most open source is not C++, CMake definitely doesn't have any strong share of the open source market.
Earlier quoted context omitted.
It currently doesn't do fully hermetic configurations (as in, where it is impossible for any inputs to come outside of the project). Instead build2 does high-fidelity builds where it makes sure that if any of the inputs change (including options, environment, compiler itself, etc), the target gets rebuilt. See my reply to a sibling comment for some details. We do plan to add support for hermetic builds though it won'…
Does build2 handle the case where code has #include "foo.h" and then, after a successful build, you create a new file named "foo.h" in a directory earlier in the search path than the foo.h that was used in the previous compile?
In any case, in build2 this is "handled" by not including headers as "foo.h" but as , that is, with the project prefix. You can read more on this here: https://build2.org/build2-toolchain/doc/build2-toolchain-int... And the proper fix will hopefully come with C++20 modules.
Earlier quoted context omitted.
What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?
my organization's goals for java builds are consistency (we want to be able to build deterministic jars), reliability, and playing nicely with IDEs via tooling. given that, as far as i can tell, there's nothing so compelling that it's worth switching over your project or organization. the tooling around maven is so good, and the inertia so strong (for my organization anyway), that there's no real incentive to switch.…
- We actually made good use of Ant tasks and macros for having convention over configuration build infrastructure
- Maven was still on 1.0 beta releases, with incomplete support for the plugins we required
However this was more than 10 years ago, and nowadays I am yet to find something that beats Maven eco-system, specially given that I don't suffer from XML allergy, rather it is my favorite configuration format.
I cry a little beat every time I have to wait for Android Gradle builds.
Guess what, the upcoming Android Summit is enjoying yet another Gradle performance improvements talk. They can't get enough of them.
Earlier quoted context omitted.
Isn’t Bazel jre based? I don’t think that something like Qt will ever go for a build tool that requires the whole java runtime as a dependency. (Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)
CMake may have a longer history of being used by open source, but Meson has been growing in popularity for some important projects. I definitely prefer Meson to CMake. Bazel is also a great build system, but yeah, the JRE dependency will obviously make it less desirable for some users. Still, I hope people consider it anyways, because its focus on correctness is pretty great.
Meson will most likely be kept as the GTK, GNOME build system.