<offtop_mode_on> What you wrote reminds me how government officials spent budget money for the new cars in my country. They write specific tender documentation that fits only one car, say Chevrolet Tahoe (for example, "the car that fits 9 people, has leather interior and has the power of 200hp»). The argumentation is the same - here’s the requirements, who cares that the only one overpriced car fits in them. <offtop_mode_off>
I have several other requirements for the buildsystem. 1. IDE integration. I really need the IDE know the correct CXX flags for each separate file in my project - that is includes, c++ version and so on. Currently i’m using a generated CMake file at my work and the integration with Qt Creator is awful, i’m using IDE just as a simple text editor - syntax highlighting breaks because IDE can’t find some headers (however, goto definition works for them). 2. Support for cross-compilation and deploying Android/iOS. I’ve used a GYP at work for a QML-based app. I spent a whole week porting Qt application for iOS writing those unreadable gyp files. Not sure if CMake will be much easier, AFAIK, neither QBS nor CMake have full support for iOS and Android deployment in Qt Creator (so i can just press «run» and IDE will do everything for me). However, i don’t see big problems in implementing this with QBS (i made several small patches and i can say that the codebase is neat). However, I won’t be the guy who volunteer to do anything in CMake. Yes, CMake has much more users than QBS, however, how many of them will volunteer to work with CMake’s Qt Creator integration? 5 people? 10? We will end with a separate team of Qt guys working on CMake’s integration with Qt and it’s tools. So the question is - is it easier to port QBS to be built without Qt or to use CMake with Qt? I pay my 2 cents for QBS. > 21 июля 2018 г., в 5:35, Thiago Macieira <[email protected]> > написал(а): > > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
