Earlier quoted context omitted.
Let us know when Meson gets first class support on Eclipse CDT, Clion, Qt Creator, KDevelop, Android Studio, VSCode and Visual Studio.
OK, ping me in 3 years.
Surely. I have seen too many carriages drive by.
Bazel Release 1.0
171–180 of 180 posts
Re: Bazel Release 1.0
#172Earlier quoted context omitted.
Google just tests the living Jesus out of everything, and only versions a few core packages such as protobufs, grpc, and other packages used by pretty much everybody (this is called the "crust"). Everything else is tip of tree, and things are automatically re-tested using checked-in tests if they are affected by your changelist. You basically can't submit if you break anything. So in a way, Google doesn't need "versi…
> Blaze (at Google) is also not just a build system, but also an interface to a much larger distributed build and test backend, which lets you rebuild everything from the kernel upwards in seconds (by caching petabytes of build products at thousands of possible revisions), serves up source code views for developer workstations (code is not stored there either), and sustains the scale of distributed testing needed for…
>> mechanisms for managing out of source dependencies is just flat out clunky
I'm not sure I agree. You can reference arbitrary, versioned out of tree deps via WORKSPACE file. You can pull from git at tag or revision, you can pull from cloud storage, maven, pypi, etc. Just about any realistic scenario is supported, and those that aren't yet are easily scriptable using a restricted python-like extension language.
Re: Bazel Release 1.0
#173Re: Bazel Release 1.0
#174Earlier quoted context omitted.
Surely. I have seen too many carriages drive by.
Actually, there’s already an excellent Meson plugin for VSCode, and a pretty good one for Qt Creator, so I hope you’re a fan of losing bets :p
So far, everyone that has bet against CMake has lost to overtake it.
Scons, qmake, waf, premake, Gradle C++, MSBuild, ...
I know which horse to bet on.
Re: Bazel Release 1.0
#175Earlier quoted context omitted.
Actually, there’s already an excellent Meson plugin for VSCode, and a pretty good one for Qt Creator, so I hope you’re a fan of losing bets :p
So far, everyone that has bet against CMake has lost to overtake it. Scons, qmake, waf, premake, Gradle C++, MSBuild, ... I know which horse to bet on.
Scons and qmake both predate CMake. It’s weird to characterize them as trying to “overtake” CMake; that’s not really a thing I think happened. As a matter of fact, there was a time when qmake was a better option; it was a fairly complete Makefile generator that had good support for subprojects and out of tree builds.
Then again, this is all irrelevant. What these projects all had to offer at one point is historical. Qt has to leave qmake because of qmake. During that time they evaluated many options, including a fairly innovative design called qbs - Qt Build System. In the end, the choice of CMake makes a lot of sense, as it is clearly the best available choice that had ecosystem support. Qt is unlikely to switch build systems again soon.
This entire argument has happened before, but instead of meson vs CMake it was CMake vs autoconf. The thing is, I suspect CMake will still exist even as Meson inevitably continues to gain traction, just as autoconf (unfortunately) exists today.
There is, in fact, room for more C++ build systems, and almost definitely room for better interop. (Meson and CMake have some interop today.)
Re: Bazel Release 1.0
#176Earlier quoted context omitted.
Yes. My guess is that over a long enough period of time, the internal build system will migrate to Bazel. But I don’t think it will happen soon. Large migrations are always a pain, but Bazel does make it easier (since you can isolate dependencies very well and migrate bottom-up). I don’t work there, but I have talked to Googlers working on build systems.
Bazel is just the open source name of the internal Google build system, it is the same codebase.
From what I understand, the two tools have some very significant differences at this point. They may be the same codebase in a broad sense, and may share a lot of code, but I bet they are using something like Copybara to synchronize them.
Re: Bazel Release 1.0
#177Earlier quoted context omitted.
I'd like to get a good grasp of the differences between Bazel and Buck. I've used the Bazel but not Buck - most descriptions of Buck describe it as being pretty similar to Bazel. (Also, that's a very interesting paper, will read in depth.)
From a historical perspective: Bazel is the open sourced version of Blaze, google's internal build system. Buck is Facebook's open source version of their own implementation of a Blaze-like system. Pants was built as an open source implementation of Buck, before Buck was open sourced. From a bird's eye view, knowing this history of their creators, I would guess that Bazel is more complicated internally, its API has a…
one of the biggest differences between buck and bazel is,
when you want to write new build rules(to support your specific use case or to support an unsupported language etc):
- in buck you should update the buck code itself(you should touch so many places in JAVA) - whereas in bazel, you can extend bazel with starlark(subset of python) language and do all sorts of things like supporting whole new language. without touching even a tiny bit into bazel core.
This was the main reason my company is switching to bazel from buck
Re: Bazel Release 1.0
#178Earlier quoted context omitted.
Can it do "bulletproof", repeatable incremental builds? I'm asking because I don't see how it would be able to, unless the toolchain is wired into your build system _at least_ as deeply as it is in Bazel.
So bazel and brazil solve similar but very distinct problems. bazel is solving the problem of fast, repeatable, "bulletproof" builds for (very large) monolithic repos, whereas brazil is solving for fast, repeatable, "bulletproof" builds for (very large) collections of repositories or packages. brazil is EXTREMELY agnostic to what happens within any given package build, with the associated tooling primarily focused on…
Perforce effectively provided this interface as long as you stuck to packages within the same depot. Multi-package reviews and commits were very natural. The git migration eliminated that and moved the concern up to build time selection of versions. Not terrible, but definitely less convenient.
Re: Bazel Release 1.0
#179Bazel 1.0 announcement on Google Open Source blog: https://opensource.googleblog.com/2019/10/bazel-reaches-10-m...
Provides more details on 1.0 changes and long term plans
Re: Bazel Release 1.0
#180I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel, but that's probably strongly conditioned on the quality of Windows support. Qt Co. have indicated that CMake is the most likely replacement for qmake in Qt 6, which would be a lateral change at best. Is anyone using Bazel to ship cross-platform GUI applications?
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)
Being written in Java is essentially a non-issue. Bazel ships as a binary that self-extracts a JRE for its own use. You don't have to install Java unless you want to build Java apps.
The real issue for highly reusable products like Qt is portability of the build tool. CMake works on the long tail of OSes, some of which do not have any usable JRE available. That limits the ability to use Bazel as the only build tool.
For Bazel to be useful to projects like Qt (and other horizontal libraries like openssl, ICU, curl, ...) one would need a system for generating CMakefiles from BUILD files. The developers of those apps could use Bazel to improve build and test scaling, and then generate CMake (or other build tool) files as part of their packaging and distribution. I don't propose that this is an easy thing to do - all rules would need translation into other languages - just that it is a path which may benefit some projects.