Attila spaketh: <snip>, I understand that for Qt, as an application framework,
> the goal is to produce a set of executables/libraries that leverage the Qt > modules. The focus here is obviously on whether you want to make a > GNU/Linux > binary, a Win32 binary, etc. However, the QtSDK (to my mind) has a slightly > different focus, with the output (in case of mobile platforms - for now) > being > *distribution*, *firmware*, or, implicitly even *device* specific packages. > This > latter goal is a lot newer and (in my impression) not entirely embraced. > IMHO, this is a brilliant observation. > <snip>, > In my case, some of my Qt projects have reached a larger number of targets > and > special cases/optimizations (7+, with no sign of decreasing). I think this growing-target-complexity will similarly do nothing but *increase*: That is the whole point of "re-use", as Qt is a "run-anywhere" concept, and we will have ever-increasing target platforms and product configuration requirements. <snip, build hacks, maybe a few main branches> This is a very real problem. I would very much like to see discussion on this topic (rich targets for differently configured platforms as handled by the build system, as opposed to historic "#if Q_OS" hacks.) Fundamentally, the "#if Q_OS" hacks won't be sufficient going forward IMHO because they logically represent the "flat list" of resolved states after a combinatorial explosion of options (see list below). It's too painful to maintain that flat list, especially since it should be logically "sparse" given the set of *actual* targets which are relevant to the developer (a rich/large number of targets, but we do not target all possible combinations). Thoughts, comments, disagreements welcome. > IMHO, this is a "tip-of-the-iceberg" discussion as we dig into what's required to consider for "build targets" as it relates to our combinatorial explosion of intended targets: *- different OS targets *- different platform/device/mobile targets (kind of like OS, but different, often requires cross-compiling) *- different modules used/excluded *- different optimizations *- different product-specific configurations *- different device-specific configurations *- ?? Of course, we're talking Qt: We want code re-use. That means we write it once, and have (with "little" effort) a very rich set of target deployment options (e.g., multiple OS desktops, multiple mobile platforms, and even embedded.) As Qt expands its greater module granularity, and adds QML bundling/deployment technologies (currently being investigated), this gets much more interesting and non-trivial. > PS. Disclaimer: I fully intend on making a blog post about this and the > feedback I gather here :) Please post a link to your post -- I'm very interested in this discussion and your thoughts. --charley
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
