Hello Having spent far too much time trying to figure out why crappy buildsystems cause failures in distros (like TensorFlow or libvpx - see https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to make sure this doesn't happen to Qt 6. For that, I'd like to add the following extra requirements to the buildsystem we choose to use. This is in addition to the functionality requirements.
These apply to the buildsystem at the time of Qt's the switch to it. 1) Ease of obtention a) Must be packaged by all major package managers where Qt 6 is expected to be relevant. That is, it must be available as a package in: - ArchLinux - Debian testing - Gentoo - Fedora current and previous - openSUSE current and previous - Ubuntu LTS released more than 6 months prior - Homebrew (macOS) I'll take care of Clear Linux, but we apply the "two major distros" rule, so I won't be first. It would be nice to have it in vcpkg/nuget/whatever MSVC uses and FreeBSD ports tree too. b) Must be easily compiled from source on a standard system installation. All of its dependencies must come from the system's package manager and there must be no cyclic dependencies. That is, it cannot require itself to build and it must not depend on Qt, either in source form or binary. c) Must not require too-recent version in order to compile Qt. The versions found in (a) must be sufficient to build Qt 6.0 and this must continue throughout Qt 6's lifetime. 2) Track record a) Must be used by roughly a dozen packages in major distros. I'm not saying all of them have to have a dozen, not even that one of them has a dozen. But all of the ones listed above must have at least one and there must be a dozen distinct packages in total. b) At least one package must have been continuously packaged for two years. One for an RPM distro and one for a .deb distro. c) At least one package of comparable complexity to qtbase, packaged by the three of the six Linux distros I listed. I'm looking for: - compiling certain files with different compiler flags - several third-party dependencies, some required, others optional - lots of configure-time options - installing several different types of targets (binaries, libraries, plugins, arch-dependent files, arch-independent files, documentation, translations, etc.) - obeying distro-supplied options (compiler & linker flags, compiler selection [ccache, icecc, clang], debuginfo split, stripping, etc.) 3) Community support a) Thriving community to ask for help to, whenever issues happen. b) One packager for .deb and one for RPM that will vouch for the buildsystem. I don't think I am being unreasonable. I am being strict, though. I'll put my money where my mouth is: as soon as the requirements are met, I will begin using it and contributing to it, finding out where there may be shortcomings and supplying fixes if possible, bug reports if not. But until then, I will pretend it doesn't exist and will ignore the branch that uses it to build. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
