[Development] Platform Content Selection

[Mohamed Fawzi]

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.com at qt-project.org [development-bounces+fawzi.mohamed=digia.com at qt-project.org] on behalf of Attila Csipa [qt at csipa.in.rs]
Sent: Wednesday, January 09, 2013 11:58 AM
To: development at 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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development