[QBS] Thoughts about processor architecture

[Jake Thomas Petroules]

I was having some thoughts about QBS' handling of different processor architectures. This is mainly related to QBS-13 and QBS-192.

As a recap, 13 is Darwin fat binary support, and 192 is my suggestions for the implementation of a qbs.targetArchitectures property
which would tell the architecture you are compiling for.

Currently I believe QBS has a single 'architecture' property which is set by the profile and tells the architecture that the compiler
will generate code for.

I think we need 3 properties, and this suggestion both deviates from and overlaps the one I outlined in QBS-192.

First off is `qbs.supportedArchitectures`. This variable would hold a list of all architectures that the compiler can generate code for.
It would be read only. For most compilers this would only contain a single architecture, like currently. The platforms it would really
affect are OS X and iOS, for which the former may support both 32 and 64 bit variants of x86 and ppc, and the latter, several variants
of arm (armv5, armv6, armv7 and armv7s in varying versions of the toolchain I believe), and x86 (simulator). I'm not sure how you
detect a list of supported archs but this one should be fairly simple to do, and could be set in the profile at toolchain setup time.

Also, could we perhaps have some sort of validation scheme that checks whether the compiler referenced by a profile has changed?
For example, let's say you're on OS X 10.6 -- your gcc supports i386, x86_64, ppc, and ppc64. Then you upgrade to Lion and your QBS
configuration comes along with it... once you upgrade Xcode, gcc should still be at the same path but now it only supports i386 and x86_64
so your configuration is wrong. So... should we perhaps check this at runtime instead? Or is there a way we can invalidate if a checksum
of the compiler binary changes, or something like that?

Second is `qbs.defaultArchitectures`. This variable would hold a list of the architectures that the compiler will generate by default. It would be
read only. For every platform I know of, this would only be a single value (even on Mac). But perhaps if Apple ports OS X to ARM, they'll change
the clang default to compile universal x86_64 + armv8 binaries. Making this a list keeps us future-proof. This is also the hardest property to
populate, because as I said in QBS-192, the default architecture(s) that the compiler compiles for is dependent on a *lot* of different conditions,
including but not limited to the operating system version, CPU, system settings, etc.

Similarly, this might be better to check at runtime seeing as this depends on so many things that could change underneath, even without the
compiler binary itself moving a bit.

Lastly is `qbs.targetArchitectures`. This variable would default to the value of `qbs.defaultArchitectures` and would be read-write, allowing the
developer to specify which architectures they would like to compile for. If any of the values in this list is NOT contained in `qbs.supportedArchitectures`,
or it is empty, QBS should throw an error.

This property could be quite nice to use since a developer could configure it to be quite flexible, i.e. compiling for all architectures the compiler supports
`qbs.targetArchitectures: qbs.supportedArchitectures` or compiling for whichever Intel architectures the compiler supports:

qbs.targetArchitectures: {
	var archs = []
	if (qbs.supportedArchitectures.indexOf('x86') !== -1)
		archs.push('x86')
	if (qbs.supportedArchitectures.indexOf('x86_64') !== -1)
		archs.push('x86_64')
	return archs
}

In practice that gives you the default Intel architecture on most platforms, and an Intel fat binary for OS X... or an error on anything non-Intel.

As Ossi suggested, we could use property groups with an arch selector to ensure that the correct flags get passed for the correct architectures,
which would work regardless of whether a particular compiler can build for multiple architectures.

I believe this design would be very flexible and future proof. I'm interested to hear some feedback on what the rest of you think of this.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petroules at petroules.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20130320/ed26e495/attachment.html>