On Tue, Mar 31, 2015 at 03:17:59AM +0300, Andrew Knight wrote: > For the past few months, I've been tinkering with using QBS to build > the Qt libs we use in our projects. > that was risky ... if i actually had the time to do what i wanted, you'd have duplicated quite some work. anyway, busy me, lucky you. ;)
> The reason I'm posting is to just make it known that we (meaning my > colleagues and I) are actively working on this, > that's excellent news. what i'm interested in (possibly even more): how much effort do you guys want to spend on improving qbs itself? considering https://bugreports.qt.io/browse/QBS-70's longish list of dependencies required for a *clean* qbs-based qt build system, quite some work lies ahead. > - The repository itself is just a collection of QBS files (and maybe a > few JS files as well as some pre-built artifacts I haven't bothered > writing rules for yet). That means it is designed to work with a > separate checkout (or even tarballs) of Qt sources (e.g. qt5.git). I > would also like to see it not tied to any particular Qt version, but to > support a range of Qt releases to allow quick switching between Qt > sources (read: branching of the repo is not tightly tied to the Qt version). > i understand your motivation for this, but from my perspective it's a total no-go - it's an utter maintenance nightmare. i'd create throw-away wip/qbs-5.5 (and later wip/qbs-dev) branches in all relevant qt repos straight away. support for multiple versions can be achieved the usual way: merge from -5.5 to -dev. > - There are two "prerequisite" steps to building Qt modules: > (1) build the host tools (using the host's profile) > Host tools can be reused for every target profile you decide to build > the framework for. > that's something i want to do independently from migrating to qbs. there are some challenges though, in particular how qmake ties it all together with its properties. the inverse conclusion is that this *should* not be a prerequisite for building with qbs, and i'd prefer to not have it unless we (you ;) solve the problem upstream before that. > (2) create a configuration file with all the various switches. > The configuration file (let's call it qtconfig.json) is basically a > portable configure command line. > well, that's what i wanted to do for the time being as well. in fact, i'd have been even cheaper than you: just use the existing configures and extract the relevant information from the generated .pri files. the reason for that is the thread you linked to yourself: whatever you hack up now will probably need a lot of rewriting when properly modularized configure support is implemented in qbs. i haven't thought much beyond qtbase, of course. :D > It would at least be cool, to see this step also install the Qt module > configurations into a new QBS profile (perhaps as a replacement to > qbs-setup-qt, see [0]), as that might allow reusing more of QBS's > existing Qt module support. > not exactly ... that's something that should be created as a side effect of instantiating QtModule, etc. - https://bugreports.qt.io/browse/QBS-268 > qmake isn't even built with this setup, but a stand-in binary called > qhost pacifies the need for querying qmake variables. > well, that's obviously not going to fly for upstreaming, as qmake and everything around it is part of the qt api. but rectifying that as such is trivial. the challenges start with the decoupling of host and target qmake, as noted above. regards _______________________________________________ QBS mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
