[Development] Qt 6 buildsystem support requirements

[Matthew Woehlke]

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