> > > Charley spaketh: > <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). >
Ben respondeth: > I have to quite disagree. The #if Q_OS stuff compliments the build system > and is > quite required. > > For example, <snip, good example of product on multiple platforms> > <snip>, As with any tool, it can - of course - be misused; but it has very > appropriate > and valid uses that are not possible using other methods. > I agree there. I didn't intend to assert the #if Q_OS should be deprecated, but rather, that it would be insufficient (by itself) going forward. The issue I see is the mix-and-match problem when building for different platforms, modules, features, devices, etc. Using the preprocessor is an important tool, but I don't think all these mix-and-match problems can be best solved with *only* that tool as we currently do. And, I would much rather test for a Qt Define like Q_OS_WIN32 instead of > having > to test for compiler and target specific defines (e.g. _MSC_VER and > _WIN32). It > makes that kind of stuff so much more legible and straight forward. > Agreed. --charley
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
