The main.c for the template is still targeting SDL1.2. Here
is the patch to make it work for SDL1.3 (I’m hoping
the mailing lists accepts attachments.)
In this patch I have also changed the shell script that
assembles the Template. Since there is now only one lib
target (same name for “device” and “simulator” version)
I copy the simulator library to the destination with
the name libSDLSimulator.a. This is not a satisfactory
solution, because both libraries are included in the project
while only one is needed (depending on the selected
environment). However, I’m not fluent with Xcode to
say what a better solution would be.
Your changes are in, thanks!On Fri, Jan 28, 2011 at 1:57 AM, Kees Bakker <kees.bakker at xs4all.nl> wrote:
Hi,
The main.c for the template is still targeting SDL1.2. Here
is the patch to make it work for SDL1.3 (I’m hoping
the mailing lists accepts attachments.)
In this patch I have also changed the shell script that
assembles the Template. Since there is now only one lib
target (same name for “device” and “simulator” version)
I copy the simulator library to the destination with
the name libSDLSimulator.a. This is not a satisfactory
solution, because both libraries are included in the project
while only one is needed (depending on the selected
environment). However, I’m not fluent with Xcode to
say what a better solution would be.
The article in the following link gives a good workaround
to setup the xcode project with the two libraries. We can even
use the same name (in different directories of course). The trick
is to only link one of the two depending on the selection of "device"
or “simulator”.
Other than that, I am not a fan of Xcode, to put it mildly.
Kind regards,
Kees BakkerOn 28 Jan, 2011, at 19:38 , Sam Lantinga wrote:
Your changes are in, thanks!
On Fri, Jan 28, 2011 at 1:57 AM, Kees Bakker <@Kees_Bakker> wrote:
Hi,
The main.c for the template is still targeting SDL1.2. Here
is the patch to make it work for SDL1.3 (I’m hoping
the mailing lists accepts attachments.)
In this patch I have also changed the shell script that
assembles the Template. Since there is now only one lib
target (same name for “device” and “simulator” version)
I copy the simulator library to the destination with
the name libSDLSimulator.a. This is not a satisfactory
solution, because both libraries are included in the project
while only one is needed (depending on the selected
environment). However, I’m not fluent with Xcode to
say what a better solution would be.
you can also do that by draggin the sdl xcode project inside your
xcode one, and then after expanding it you can drag the sdl library
under the “link binaries” phase of your target – this will reduce
clutter under your file list and automatically link the correct
version (device/simulator | debug/release)
bye
VittorioOn Fri, Jan 28, 2011 at 9:18 PM, Kees Bakker <kees.bakker at xs4all.nl> wrote:
Great.
The article in the following link gives a good workaround
to setup the xcode project with the two libraries. We can even
use the same name (in different directories of course). The trick
is to only link one of the two depending on the selection of "device"
or “simulator”.
Other than that, I am not a fan of Xcode, to put it mildly. http://iphoneincubator.com/blog/xcode/how-to-add-multiple-static-library-files-with-different-architectures-to-xcode
Kind regards,
Kees Bakker
On 28 Jan, 2011, at 19:38 , Sam Lantinga wrote:
Your changes are in, thanks!
On Fri, Jan 28, 2011 at 1:57 AM, Kees Bakker <kees.bakker at xs4all.nl> wrote:
Hi,
The main.c for the template is still targeting SDL1.2. Here
is the patch to make it work for SDL1.3 (I’m hoping
the mailing lists accepts attachments.)
In this patch I have also changed the shell script that
assembles the Template. Since there is now only one lib
target (same name for “device” and “simulator” version)
I copy the simulator library to the destination with
the name libSDLSimulator.a. This is not a satisfactory
solution, because both libraries are included in the project
while only one is needed (depending on the selected
environment). However, I’m not fluent with Xcode to
say what a better solution would be.
-EricOn 1/28/11, Kees Bakker <kees.bakker at xs4all.nl> wrote:
Hi,
The main.c for the template is still targeting SDL1.2. Here
is the patch to make it work for SDL1.3 (I’m hoping
the mailing lists accepts attachments.)
In this patch I have also changed the shell script that
assembles the Template. Since there is now only one lib
target (same name for “device” and “simulator” version)
I copy the simulator library to the destination with
the name libSDLSimulator.a. This is not a satisfactory
solution, because both libraries are included in the project
while only one is needed (depending on the selected
environment). However, I’m not fluent with Xcode to
say what a better solution would be.
Yes, this is actually a good approach, especially since Apple has
really crippled the iOS side of the Xcode toolchain for things like
3rd party libraries (especially dynamic libraries which causes pain
and hurt when dealing with LGPL licenses and technical things like
Obj-C class categories). Of course there are also some trade-offs as
well like rebuilding all of SDL for your project.
Both a prebuilt static lib and referencing the entire Xcode project
have their own merits. I’m indecisive about which to do so I think I
will ultimately will be documenting both ways.
My previous response does the prebuilt Universal libSDL.a way with the
iOS Xcode project template. However, for actually building the SDL
satellites (SDL_ttf (and freetype), SDL_image, etc), I will be doing
the reference approach. I’m in the process of utilizing the Mercurial
subrepo feature for this.
-EricOn 1/31/11, Vittorio G. <vitto.giova at yahoo.it> wrote:
you can also do that by draggin the sdl xcode project inside your
xcode one, and then after expanding it you can drag the sdl library
under the “link binaries” phase of your target – this will reduce
clutter under your file list and automatically link the correct
version (device/simulator | debug/release)