[QBS] Thoughts about processor architecture

[Oswald Buddenhagen]

On Wed, Mar 20, 2013 at 08:44:30PM -0400, Jake Thomas Petroules wrote:
> I was having some thoughts about QBS' handling of different processor architectures. This is mainly related to QBS-13 and QBS-192.
> 
> First off is `qbs.supportedArchitectures`. This variable would hold a list of all architectures that the compiler can generate code for.
>
it should be a list of lists. the elements ought to be elements which look
exactly like what ends up in targetArchitecture. otherwise you'd end up
with "arm, x86, sse3, simulator" and similar, most of which simply are
not valid combinations.

the point is here that this multi-architecture magic should be "meta",
built as an extra layer on top of a normal project. in fact, we are
talking about disjoint build configurations, which are "magically"
joined into a single build at a point past evaluating the projects "the
normal way". this enables supporting both fat binaries (mac) and fat
packages (android) with the same project format.

we have been discussing virtually the same problem in the context of the
dreaded debug_and_release (and shared_and_static) builds as well. in
every case it is aggregating multiple builds into one deployment target
(with shared data, and sometimes shared (typically combined) binaries).

i'm not sure in how far the projects themselves should be able to
specify such aggregation in the first place. as it is about build
configurations, it is technically something that should come from the
outside. think "profiles".