On Thu, Apr 02, 2015 at 12:31:48AM +0300, Andrew Knight wrote: > On 04/01/2015 05:58 PM, Oswald Buddenhagen wrote: > > how much effort do you guys want to spend on improving qbs itself? > > I think we would be interested in helping out, especially if it > improves life for us and/or our customers. We are invested in QBS > already, after all. > excellent. you can/should get an overview of what the "vision" is by familiarizing yourself with qbs' suggestion list in jira. you know where to find us to discuss details. :)
> My crusade to git rm the .pro files from our repositories is largely > complete... (*evil laugh*) > :D > The nice thing about QBS is that you can do a lot with globs and > exclusions, so it's easier to do something like this in that sense. > that's actually the first thing i'll criticize about the implementation. :P while qbs makes it easy (and reliable) to use globs, it's still a weird thing to do, especially when you have a configurable build system - exclusions are literally backwards. of course, file lists with insane amounts of quotes and commas are ugly as well, which is why https://bugreports.qt.io/browse/QBS-58 exists. > >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. > > Yes, I guess we can pretty much follow the qmake model here, with the > top-level project living in qtbase > well, the top-level project lives in qt5.git. which is not where (the real) configure lives. which makes it immediately obvious why a monolithic centralized configure is a flawed design. > One thing I like about the centralized approach (i.e. putting the > project(s) in qt5.git) is that the directory structure more easily > take on a different shape. For example, qtbase's and qtwayland's > platform project files could share the same hierarchy. You lose that > with submodules. You also lose it if you are boring and follow the > source hierarchy. > i can understand how this is appealing when all you do is a buildsystem, but for a "regular" developer (who just wants to make minimal changes while writing actual code) this is part of the nightmare i've been talking about. > Is there is already a way to create a QBS profile (using multiplexing) > that lets you specify the compiler/sdk for host tools and a separate > combo for the target platform? That's another problem I've chosen to > ignore thus far, but Christian has suggested that it might be doable > already. > yes, you specify the profiles property in a product. you'd bind it to project.hostProfile (which, arguably, should be predefined - cf. the "self-aware" qbs you mentioned). > configure is basically a long list of flags, most of them booleans, > and some attempts to guess what you want. > that's mostly the status quo in qt, but it's really way insufficient. the configuration step should also churn out modules with fully qualified headers and libraries. > It seems like a really handy thing for allowing flipping a few bits > and rebuilding only the parts of Qt which are affected, and something > that QBS should be really good at. That's what started this exercise > in the first place; to be able to disable some arbitrary Qt feature > and (quickly) see what breaks. > yes, but having a text file where you do that after configuring (adjusting to the environment) is basically a hack. ideally, you'd flip the bits that interest you via properties you pass to qbs *before* the project gets configured. passing these properties in a json/qml file instead of individually would certainly have some appeal. so would some more specialized command line (like the current configure), and so would an interactive frontend (like ccmake). > >not exactly ... that's something that should be created as a side effect > >of instantiating QtModule, etc. - https://bugreports.qt.io/browse/QBS-268 > > Yes, that's exactly the feature I was looking for :-) It would be nice to get > to the point where "installing Qt" just means running qbs-setup-qt <magic> and > pointing to your source tree. Then, Qt itself is built bit-by-bit based on > your projects' dependencies... > that's different. if you want to make qt part of your project, you'd just refer to qt as a subproject. this does not need any exported module configs, and will already work out of the box. > >>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. > > I'm sure that bothers you more than it bothers me. I mean, requiring qbs > already means requiring a pre-built host tool. > that's besides the point. qmake must stay until qt6 for our users. the presumption that you don't need qmake if you build qt with qbs falls flat latest when building with qbs becomes the only option. which will be very soon after the build system is complete. > Anyway, thanks for the feedback so far. I guess we could/should start with a > qbs wip branch in one repo (qtbase, presumably) to get the party started. The > other repositories can follow when there's a reasonable baseline established. > indeed. qtbase//wip/qbs-5.5 exists now (which means that there will be at least curious, probably skeptical, and possibly hostile voices to be heard soon). _______________________________________________ QBS mailing list QBS@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs