Closed GoogleCodeExporter closed 8 years ago
Aha, I'll bet that relates to the new rounding script. That CFBundleShortVersion
string is a tricky one.
Thanks for the report.
Original comment by m4d...@gmail.com
on 8 Feb 2009 at 6:32
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
Original comment by jtxdriggers
on 8 Feb 2009 at 6:55
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. :)
Original comment by toeloo...@googlemail.com
on 8 Feb 2009 at 10:04
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 ?
Original comment by mnemonic...@gmail.com
on 9 Feb 2009 at 5:01
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.
Original comment by m4d...@gmail.com
on 9 Feb 2009 at 12:33
I've made the change in r68 of the unstable branch, can you verify if this
fixes the
issue?
Original comment by m4d...@gmail.com
on 9 Feb 2009 at 1:16
It's fixed now, thanks
Original comment by mnemonic...@gmail.com
on 9 Feb 2009 at 1:37
Original comment by m4d...@gmail.com
on 10 Feb 2009 at 10:59
I was far too hasty in closing this one, it's not fixed as of r69. Keep using
68 at
this stage.
Original comment by m4d...@gmail.com
on 10 Feb 2009 at 11:16
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?
Original comment by m4d...@gmail.com
on 10 Feb 2009 at 11:53
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.
Original comment by m4d...@gmail.com
on 10 Feb 2009 at 2:04
[deleted comment]
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.
Original comment by mnemonic...@gmail.com
on 10 Feb 2009 at 2:09
But, if that's too complex to do, by just supporting 2.2 would be fine.
Original comment by mnemonic...@gmail.com
on 10 Feb 2009 at 2:13
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.
Original comment by damien.c...@gmail.com
on 10 Feb 2009 at 9:43
Attachments:
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.
Original comment by m4d...@gmail.com
on 11 Feb 2009 at 1:47
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.
Original comment by jtxdriggers
on 11 Feb 2009 at 3:14
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?
Original comment by m4d...@gmail.com
on 11 Feb 2009 at 11:45
[deleted comment]
[deleted comment]
[deleted comment]
Here it's
http://developer.apple.com/documentation/developertools/conceptual/softwaredistr
ibution4/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
Original comment by mnemonic...@gmail.com
on 11 Feb 2009 at 6:59
Original issue reported on code.google.com by
mnemonic...@gmail.com
on 8 Feb 2009 at 3:34