Having a release build with only the required files seems like a good idea, if one uses a search path based approach one can remove all non reachable duplicates, and then either store the used one again in the file system, or pack them in a QRC...
Fawzi ________________________________________ From: development-bounces+fawzi.mohamed=digia....@qt-project.org [development-bounces+fawzi.mohamed=digia....@qt-project.org] on behalf of Attila Csipa [q...@csipa.in.rs] Sent: Wednesday, January 09, 2013 11:58 AM To: development@qt-project.org Subject: Re: [Development] Platform Content Selection On 08-Jan-13 18:54, Alan Alpert wrote: >> It seems to me that this is a problem which can/should be solved at the >> build system level. > > I had the impression that it shouldn't be solved at the build system > level (even though it can be). That breaks QML as an interpreted > language, which is a nice benefit for on-device development (among > other things). You will want to go build level at least for the release builds, since this data could include images and such, so shipping ALL UIs for ALL devices in ALL distributables sounds like a huge overkill. That's why I said QRC is coincidentally very useful in terms of distribution, too. > Do you have an example of how this could be done? Specifically, > something that could select a different settings.js file for SameGame > without having to go through the C++ executable? It actually sounds awfully close to the itch that I have with the lack of QML introspection and the whole dynamic import story - i.e. now you put it in a Component/Loader, have it fail if it's not the right one, then load something else, rinse and repeat. It really is the same root cause - you can't specify "the import/value you require" because there is no single "required" version, I need/want to support several of them. > The ugliest hack is to just run the C preprocessor over your files and > pepper them with ifdefs. I know there are plenty of ways for > resourceful developers to overcome this problem, but the point of Qt > is to make it easier. Which is exactly why it a bit sad that we have all these different syntaxes and approaches for the same purpose (of compile or runtime selection of code/resources). Qmake has one way, C another, QML/JS doesn't do ifdefs at all, and then there are other types of files you might want to customize (bar-descriptor.xml, spec, you name it)... Looking at my own cross-platform/multi-device projects, the ones I had the least problems with were sadly those that "ifdeffed" by switching git branches with a bit of help from a QtCreator plugin. Not sure if that counts as worse than using the C preprocessor or the sed stuff you mentioned. Dark side? Certainly, but it *was* quicker, easier and if you're into git, more seductive. If I had a way of doing the same within Qt, I would, but currently Qt as such is not making it easier. Best regards, Attila _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
