Aha, I'll bet that relates to the new rounding script. That CFBundleShortVersion
string is a tricky one.

Thanks for the report.

Perhaps you can add an if statement to define a new toolchain_version variable.

if CFBundleShortVersion == 2.2.0.9, then toolchain_version_new = 2.2.1, else
toolchain_version_new = toolchain_version

then use toolchain_version_new wherever it needs to be placed. simple and dirty. just
like all my little fixes. haha

jtxdriggers could by right. If we can't trust the apple CFBundleShortVersion it will
be easier to write a mapping function.

It won't be dirty if we have something like SDK_VERSION=`sdk_version_by_short_version
$CFBundleShortVersion`.

But I like the rounding function. Some months ago I didn't know that awk is a kind of
programming language. :)

I didn't realize that both of CFBundleShortVersionString does have the same string in
version.plist.

So, I guess this will always produce the same SDK version for 2.2 and 2.2.1.

Maybe it could be solved by checking the BuildVersion and/or SourceVersion too ?

Thanks for looking into that, I can see that there is very little difference in the
version numbering which possibly is a problem. I would like to avoid getting into
BuildVersion and SourceVersion because they're not generic enough and can't be
derived from the main version number, nor do they appear to be totally sequential. I
suppose we could probably map full version numbers to SourceVersion ones, but I'm
hoping to avoid that at this stage.

I am inclined to modify the version checking function and treat "2.2.1" and "2.2" as
equals, although this might get us into a mess later. Do note, however that in
switching to 2.2.1 I didn't make any changes apart from the version number,
everything else built the same. I'm going to try that first and we'll see how we go.

I've made the change in r68 of the unstable branch, can you verify if this fixes the
issue?

It's fixed now, thanks

(No comment was entered for this change.)

I was far too hasty in closing this one, it's not fixed as of r69. Keep using 68 at
this stage.

Okay so I've been looking into this and starting to wonder: should we even support
minor revisions like this one? Perhaps we should be sticking to 2.2 since pretty much
anything built for it is going to work on 2.2.1 unless there's a really specific
dependency on something that's changed, which seems very unlikely to me.

I'm considering that perhaps we should not support building specifically for
toolchain 2.2.1 and instead we should just look for the pkg file iPhoneSDK{target
version}.pkg in the dmg and skip the whole version detection using plists. This is
going to require a certain amount of reworking to the version logic but I think it's
the way to go.

What's the consensus on this?

I've made the changes I described in comment 10 and they're now available at r70 in
the unstable branch. Can everyone please verify if this works for them? I'd like to
get this merged into the trunk soon since at this stage it's broken from the previous
version modifications.

I would prefer the idea that, if we use a 2.2.1 firmware then we should use toolchain
2.2.1. So we could support the latest features in 2.2.1 firmware (if there's any). 

Though, as I examined the iPhone SDK image, the only thing that differentiate 2.2.1
from 2.2 aside from the plist information (SourceVersion and BuildVersion) is the
original dmg filename.

But, if that's too complex to do, by just supporting 2.2 would be fine. 

Hi,

For the SDK named "iphone_sdk_for_iphone_os_2.2.19m2621afinal.dmg", the version
returned in the bundle is 2.2.0.9000000000, and the directory inside the mnt point
reads 2.2.1.

If we consider this as a RC-like versioning, the attached patch against r68 could
make sense. Its purpose is to detect and rename x.y.z.900000...0 versions by
x.y.(z+1). With this patch, one may use TOOLCHAIN_VERSION="2.2.1" or still use the
current TOOLCHAIN_VERSION="2.2".

Any comments are welcome, especially considering the new policy introduced in
check_environment in r70.

toolchain-221vercheck.patch 2.4 KB   Download

Thanks for the patch damien. We originally had a similar approach, but the problem is
that Apple hasn't changed the version number for 2.2.1 in the .plist files. For both
2.2 and 2.2.1, CFBundleShortVersionString is 2.2.0.9000000000. That means that a 2.2
SDK is treated as a 2.2.1 which is incorrect. Hence the current quick fix, which
doesn't allow building specifically for 2.2.1.

I think to satisfy everybody the best approach would be to change the way we detect
the version of the SDK. The most accurate way seems to be to inspect the xar Payload
of each .pkg file and look for a folder titled iPhone{version}.sdk. Perhaps to ensure
that the dmg provided meets a minimum standard we could compare the
CFBundleShortVersionString with the toolchain version but failure only produces a
warning message. This comparison could help guide the script for which Payload file
to search for the folder and I suppose from there it could simply search each Payload
until it finds the right folder.

The algorithm is something like:
Check plist CFBundleShortVersionString and compare such that 2.2 and 2.2.1 are
considered "equal" versions.
    a. If the result is that the SDK is newer than the toolchain version, look for
the appropriate version folder using the first two digits of the toolchain version
(ex: Toolchain is 2.0.1 and we're using SDK 2.2, look for iPhoneSDK2_0.pkg)
    b. If the result is that the SDK is older than the toolchain version, fail and
tell the user to upgrade their SDK.
    c. If the result is that both are equal versions, check for a package called
iPhoneSDK{first two digits of TOOLCHAIN_VERSION}.pkg. This will indicate whether the
SDK is for a .1 revision of the toolchain version (ex: 2.2.1) or is a full number
version (2.2). To clarify: SDK dmg 2.2.1 has a package for SDK 2.2 called
iPhoneSDK2_2.pkg and the 2.2.1 package is named iPhoneSDKHeadersAndLibs.pkg, while in
SDK 2.2 the package for 2.2 is named iPhoneSDKHeadersAndLibs.pkg

Using this method we can accurately detect the appropriate package for the toolchain,
as long as Apple continues on the same versioning scheme (i.e. the next release is
2.3, not 2.2.2). It's a bit nasty but as I see it it should work. Currently this
logic is partially implemented in r71, but 3-digit versions are still disallowed.

The alternative is to do as mnemonic.fx suggested and check the build version. This
is the most accurate method but it means we need to map build versions to revisions
using a list of some kind. This may be problematic since we have no way of predicting
future build numbers and thus can't produce a generic algorithm to detect the
appropriate package to use.

From my experience, the difference between the 2.2 and 2.2.1 firmwares are small, but
significant. When using the 2.2.1 SDK with the 2.2 firmware, cctools compiled fine,
but gcc failed to make. However, simply using the 2.2.1 firmware instead lead to an
extremely clean compile for both cctools and gcc.

A simple way to get the exact version number would be to just ask for the user's
input as soon as the user started toolchain.sh. User input is required for sudo and
logging in to the Apple dev site, as well as other small instances (like if certain
files exist, should they be recopied). Then read the version number from
version.plist, and if the version numbers are too dissimilar, then terminate the script.

Fix committed at unstable r72 and tested with toolchain and SDK combinations of
versions 2.2 and 2.2.1. Can everyone please confirm if they're happy with this so we
can try to merge across to the trunk?

Here it's 

http://developer.apple.com/documentation/developertools/conceptual/softwaredistribution4/SoftwareDistribution4.pdf

It's old (about 2 years ago), but it does explain the way Apple's Installer interpret
versions from version.plist.

So it's using a 5-tuple version, which consist of:

CFBundleShortVersionString.SourceVersion.BuildVersion