#55 Support for iPhone in XCode and xcodebuildsettings feature

4.2.1
open
starkos
None
5
2014-08-26
2010-06-11
Stephane
No

I am submitting a patch to allow basic support to build for the iPhone platform. It currently only generate valid solution for libraries (there is no such thing as a command line tool on the iPhone :-) )

Also, I added a really function called xcodebuildsettings. This let you specify the xcode build settings like you normally do in a .xcconfig file. This alone brings a lot to the xcode generator. You can use it like the "defines" or "files" keyword.

An example on how to use it:
xcodebuildsettings
{
"ARCHS = (i386, x86_64)",
"VALID_ARCHS = (i386, x86_64)",
"SDKROOT = macosx10.5",
"ONLY_ACTIVE_ARCH = NO",
}

With this I am able to change the SDKROOT and also I am able to generate a Universal Binary (intel only 32bit-64bit excluding ppc). This is only the tip of the iceberg, you can do many other things like exclude file in certain configs only:
'EXCLUDED_SOURCE_FILE_NAMES = ("*Proxy*", "Command*")'

I also change the way xcode id were generated to use only math.random calls and no os.time() call. Same functionality can be achieved by calling math.randomseed(1234) at the beginning of your premake4.lua script. This way if you generate twice in a row the same projects and it produce the same results.

I hope to see my change in next release of premake4. I have just finished migrated all my xcode project to premake and my teammate found premake4 so amazing that we want to migrate all the rest of our codebase too as soon as possible (Wii, PS3, XBox, Windows).

Let me know if you have any concerns with my changes or you want to discuss about it.

Discussion

  • Stephane
    Stephane
    2010-06-11

     
    Attachments
  • starkos
    starkos
    2010-09-15

    A heads up, in case I'm not the one to apply this patch: it doesn't really add iPhone support, rather it adds the ability to specify Xcode specific project variables. When we implement this, we should also provide the same ability to Visual Studio (and...?)

    Also: I have already implemented the change to the Xcode ID generation, removing the timestamp. Though it might be useful to set the random seed from the project's UUID if present so that the IDs will always be the same if a UUID is set.

     
  • Stephane
    Stephane
    2010-09-15

    A note on your "heads up":

    I have been able to generate WindowedApp with the xcodebuildsettings feature for the iphone.

    xcodebuildsettings
    {
    "INFOPLIST_FILE = info.plist",
    'CODE_SIGN_IDENTITY = "iPhone Developer"',
    'OTHER_LDFLAGS = ("-framework",Foundation,"-framework",UIKit)',
    "SDKROOT = iphoneos4.0",
    }

    It doesn't generate interface builder files, however I don't use interface builder since there a ways to create windows and views programmatically.

    With this only feature we are generating all our cross-platform project for mac and iphone, including UI apps.

     
  • John Suarez
    John Suarez
    2010-11-05

    hello Stephane - I am new to PreMake and wanted to generate a sample xcode project for iPhone. As I am new there really are no examples for this. I was hoping you could provide a complete sample that I can use as a template. I am running the Windows version.

     
  • starkos
    starkos
    2011-08-29

    • assigned_to: nobody --> starkos
     
  • starkos
    starkos
    2011-08-30

    I'd like to see this using the new key-value API type:

    xcodebuildsettings {
    ["INFOPLIST_FILE"] = "info.plist",
    ["CODE_SIGN_IDENTITY"] = "iPhone Developer",
    ["OTHER_LDFLAGS"] = { "-framework Foundation", -framework UIKit" },
    ["SDKROOT"] = "iphoneos4.0"
    }

    This is a little more expressive (you can use a table of values, like OTHER_LDFLAGS), allows for faster lookups when looking for existing values, and doesn't rely on splitting on "=" during processing.

    Also would very much like to see this for Visual Studio.

    It's a good feature. If you can't make these changes I'll have a go at it myself.

     
  • Stephane
    Stephane
    2011-09-08

    Project variables is something really useful. Visual Studio, XCode and makefile could make really good use of it, I don't know about the other IDE that premake supports.

     
  • SDKROOT, ARCHS, and INFOPLIST_FILE (and probably CODE_SIGN_IDENTITY) are not Xcode-specific - these properties could be straightforwardly implemented for GMake also.

     
  • BTW I fully support an idea of project variables.

     

  • Anonymous
    2012-04-03

    I don't know exactly what is blocking the commit of the great patch, but basically it also fixes the broken XCode 4.3.2 support (missing SDKROOT)

     
  • starkos
    starkos
    2012-04-03

    What happens when multiple xcodebuildsettings blocks are specified? How should key conflicts be handled? How would this syntax be extended to handle the other toolsets that Premake supports? How would this work with removexcodebuildsettings()?

     

  • Anonymous
    2012-04-03

    >>How would this work with removexcodebuildsettings()?
    Seems to co-exist fine.

    >>What happens when multiple xcodebuildsettings blocks are specified?
    Need to test, but likely works fine./

    >>How should key conflicts be handled?
    Document that the behaviour is unspecified?

    >>How would this syntax be extended to handle the other toolsets that Premake supports?
    What other tools are referred?

    Right now all those settings were hard-coded, so a way to override them is great and has been due for 2 years.

     

  • Anonymous
    2012-04-03

    By the way, I will test a bit more, but I think it is not good to keep on holding back this patch, without providing an alternative for such a long period of time.

     
  • starkos
    starkos
    2012-04-03

    > What other tools are referred?

    How about Visual Studio? Should it be like this?

    vstudiocompilesettings
    {
    "<FloatingPointModel>Strict</FloatingPointModel>"
    }

    If it is, that means that each element name needs to be parsed out to see if has been overridden. And it seems error-prone. Would it better like this?

    vstudiocompilesettings
    {
    FloatingPointModel = "Strict"
    }

    I personally would prefer the latter, which makes your example:

    xcodebuildsettings
    {
    ARCHS = "(i386, x84_64)",
    VALID_ARCHS = "(i386, x84_64)",
    SDKROOT = "macosx10.5",
    ONLY_ACTIVE_ARCH = "NO"
    }

    Using this approach, it would be possible to detect and handle multiple occurrences of a setting (two different configurations that set SDKROOT, for instance). And it the values could potentially be syntax-checked, to avoid putting invalid values into the project, or just to catch typos in your scripts.

    I am working on changes to premake-dev which will make it easier to define these APIs, and will handle key collisions within them; those will start showing up in the next day or two, time permitting. Though the purpose of the changes is to support mapping configurations between different projects, it will be useful for this feature as well.