On Friday, 20 July 2018 22:38:10 PDT Bogdan Vatra via Development wrote: > > 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. > > You really hate QBS don't you ? :)
No, I don't. I've never tried it, not even to bother looking at what a source file looks like, so how could I hate it? All I have are requirements and mine are that it should be easy to build and to fix problems. Because there will be problems. I'm too old to spend time learning how to debug a new buildsystem. I have better things to do. I'd just as soon give up and move on to greener pastures than to bash my head against buildsystem problems again. > Anyway IMHO is more important to have a clean, nice and easy to use syntax > and to be tooling friendly than 1.b. Well, I disagree. If you can't compile the build tool, what use is it to have the nicest language? It's inaccessible. Note I didn't say that the tool shouldn't be *part* of qtbase, like qmake is. I just thought that the objective was to eventually do away with that, to avoid having to bootstrap a tool at the moment of configure -- a tool that becomes more complex with each release. The point on requiring Qt source was that one would need to download and extract qtbase, putting it alongside the tool, just so it can be built. Instead of doing that, I suggest copying the files that one needs into the tool's source tree and packaging those for its release. -- 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
