On 2018-08-01 04:24, Jason Newton wrote: > On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: >> On 2018-07-21 19:52, Jason Newton wrote: >>> I wanted to mention that this is on my mind alot for a few years days >>> as a user for a plethora of libraries. My conclusion for the build >>> system with the brightest future is bazel [...] >> >> No. Just, *no*. >> >> Persistent build server? Java? No, thanks. > > This is an option, you can keep it in a preference file, or you can > use it as a command line switch to not use this.
...and how many naïve users that "just want to build Qt" are going to know about that? > As for java in the loop - this is a a build system, how much does it > matter with what it is written in if the implementation is good? ...because Java is an *enormous* added dependency for something that *ought* to be light-weight. >> Maybe it's gotten better, but last I knew, bazel had no notion of >> "installing" software, which is just a non-starter. It's also heavily >> optimized for Google's internal usage, and (partly as a result) >> basically does not play at all nicely with software that's intended to >> exist in an open source, package-managed ecosystem. > > The convention is that projects using it embrace that and don't care > about the most system packages if they can get away with it. Which is *exactly backwards* from what an open source package should be doing (but typical of *proprietary* software). In fact, it's the very antithesis of (L)GPL. Bazel encourages practices that are *bad* for software that wants to play nicely in an open source ecosystem. >> On a related note, "hermetic builds" is pretty ironic. Your *build* >> might be hermetic, but bazel itself is *far* from... it's very reliant >> on putting all its garbage in "magic locations" in your home directory, >> unlike most build tools that only need to write to your build directory. >> Again, *not* friendly for anyone that needs to build Qt as an external >> dependency. > > Actually that's just a default location - the output location you're > talking about is the outputRoot/output_base setting: > https://docs.bazel.build/versions/master/output_directories.html Again, stuff that users that want it to Just Work aren't going to know about. And/or that consumers of Qt are going to have to (know to) muck with. With other build systems, this isn't an issue *in the first place*. >>> -Ability to build external libraries from source >> >> Yeah... no. Building third party libraries yourself is *evil*. And a >> great way to piss off package maintainers. No open source project should >> *EVER* rely on, or preferably even use by default, this ability. > > It is not evil in any way. Every disto, ever, disagrees. > Bazel doesn't deal with system packages in a first class way. Right. And this is a big problem for an open source package. > -Analysis tools for the dependencies, like graphviz, but also memory > usage and timing info. A legitimate profiler, have a look: > https://docs.bazel.build/versions/master/skylark/performance.html > https://www.kchodorow.com/blog/2015/09/18/build-y-u-go-slow/ > (admittedly few online examples of this output and this is looks > different now IIRC) > -Does a good job of controlling verbosity while keeping the user > informed on the running targets being processed concurrently while > giving a quick way to hop out, go serial or show commands executed > -Workable, like cmake workable, visual studio generator, and xcode outputs. > -clion has a plugin good direct plugin for it, though more will follow > and they tried to make it easy for IDEs to incorporate ( > https://blog.bazel.build/2016/06/10/ide-support.html we can agree it'd > be create if more build systems did this, right? > https://docs.bazel.build/versions/master/ide.html for fuller list ) Pretty much all of which you *also* have with CMake/ninja... -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development