Is there anyone planning to create premake support for iPhone/iPad?
I know it has been asked in the past, but as iOS importance seems to be growing, I wanted to know an up-to-date answer, so...
Google shows https://bitbucket.org/nickgravelyn/premake-ios
Are there any other examples/projects/hacks for iOS support?
Thanks!
Erwin
Share
There's this patch.
I'm also very interested in this support.
At the moment my Mac doesn't have OSX installed, but I can test this later.
Hello,
there is another patch and an extended version on this fork that supports iOS to some extent. It allows generating Xcode projects for iOS only (not multiple platforms in one project) and has only been tested with a static library project so far.
I'll go into some details of the implementation now, in the hope that someone with a deeper knowledge of premake can understand and help with the open issues.
Basically, three properties must be set in order to target iOS in an Xcode project:
I implemented this as an
iOSplatform that is only understood by Xcode for now (see changeset).However, using this
iOSplatform has some caveats. If you want to create an iOS-only project, premake will also enforce theNativearchitecture. I'm not sure about the rationale of this behavior and for me it got in the way, so I disabled it (see changeset).Also, if you specify multiple platforms in your premake script, e.g.
platforms { "iOS", "x32" }, I didn't get something likeconfiguration "iOS"to work as expected. Again, I don't know if this is a bug or a feature of howplatformis implemented (are platform-specific configurations only supposed to be evaluated when--platformis specified on the command line?).I just noticed that starkos has already commented on the patch, apparently there will be improvements of platform/architecture support. Let's see how that turns out. :)
Cheers,
Guido
I'm hoping to share some changes to the platform API soon.
Hi,
I have used your premake platform before and I was very pleased with the results.
Now I am considering to use it for a new Android/iOS 2d framework instead of those nasty (limited) ndk makefiles or halfbaked cmake android/ios toolchains.
Since its been almost a month since your last post in this thread I couldn't help but wonder... how are thing coming along? :) Id be thrilled to take Premake out for a drive and see if I can get my android project going.
Regards,
Wouter
Check out the http://bitbucket.org/premake/premake-dev, there has been lots of activity there of late. Information on the in-progress platforms API is on the wiki there.
...or its GitHub mirror: https://github.com/annulen/premake (branch 'master')
Alright I managed to get a working android toolchain going. It was actually quite easy. I simply generated gmake files and set the compiler paths to that of the android standalone toolchain and it works flawlessly.
My only issue now is to get this working with XCode 4.3 and have it generate iOS projects. (I have multiple static libraries that represent components of my engine and an app project that requires those).
How would I go about it by now? I noticed the premake-ios repo vanished from bitbucket and the patch probably wont work anymore. Any ideas or anyone with some experience on this? If not, I will probably just create the projects by hand (which I am trying not to).
Regards,
Wouter
I don't think there is a good solution for Premake iOS projects right now. Once I get Xcode action ported to the new platforms APIs it should not be difficult to add, certainly much simpler than trying to hack something into the current 4.4 code.
Do you have some estimate for XCode action/new platform API and when premake supports iOS out of the box?
Lack of iOS support is a show stopper and I'm concerned we have to wait years for it.
Is there anything we can do to help?
The next step would be to port the Xcode4 action to the new APIs in premake-dev. Once that is done, adding iOS support should be straightforward.
My roadmap right now is fixing the vpath stuff, adding token replacement, and porting the Gmake action to the new APIs (in addition to getting 4.4 released). I would love to have iOS support for my own projects, but those things have to get checked off first (for me).
I wanted to link to my reply to http://industriousone.com/topic/premake-support-ios-iphone-ipad but the system doesn't let me link to an individual posting in that thread, so here the copy for now:
I forked the latest https://bitbucket.org/bitshifter/premake-dev into github and applied the patch that enabled iPhone support manually:
https://github.com/erwincoumans/premake-dev-iphone-xcode4/commit/0c7dcf8...
This 2010 patch adds iPhone support by manual allowing to modify the xcodebuildsettings, and this also fixes the XCode 4.3.2 problem (adding SDKROOT=macosx;)
In case others want the premake4 working for XCode 4.3.2 and iPhone/iOS,
see https://github.com/erwincoumans/premake-dev-iphone-xcode4 and download
precompiled Mac OSX premake4 binary in the download section of that repo.
It works fine here and the patch is applied to your premake-dev repo.
Can you let me know what you mean by the new APIs?
Very cool! I managed to get my project working in xcode by manually adding files as I go and set defines etc myself. But this is of course a lot handier. I will try it out as soon as I get back to the iOS part of my project :)
Regards Wouter
Can you let me know what you mean by the new APIs?
The new platform/architecture system that is currently being built in premake-dev.
How close is bitshifter's repository to premake-stable? Would it be feasible to create patch that could be applied to 4.4?
Is there any info/discussion threads about this new platform/architecture system somewhere, that describe the benefits of this new system?
It is likely trivial to apply those changes to premake-stable too, it is just that I'm not familar with 'HG'. It would be great to have this patch applied.
>It is likely trivial to apply those changes to premake-stable too, it is just that I'm not familar with 'HG'
Than you can use my git mirror to rebase changes:
https://github.com/annulen/premake
Sure, here is my pull request: https://github.com/annulen/premake/pull/1
You might also want to add some documentation about the feature to override xcodebuildsettings. From the original patch:
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
{
"INFOPLIST_FILE = info.plist",
'CODE_SIGN_IDENTITY = "iPhone Developer"',
'OTHER_LDFLAGS = ("-framework",Foundation,"-framework",UIKit)',
"SDKROOT = iphoneos",
}
I have different vision on xcodebuildsettings thingy.
Any kind of IDE project I'm aware of (VS, Xcode) and Makefiles have variables which can be built-in or user-defined. I think Premake should give a possibility to assign this variables from project, e.g.
BTW, Info.plist and SDKROOT parameters are by no means Xcode-specific - they can be used e.g. by gmake on Mac.
I have a lot of dreams too, but not time to implement those all, hence this patch.
This outstanding issue has been open for 2 years now, blocked by visions without action.
It is just a few lines of code removing some hardcoded settings out of the xcodebuildsettings, that's all.
We need to be more pragmatic in my opinion. When do you implement your vision?
If everyone agrees with above plan (@stakos: what do you think?) it should be (relatively) easy to implement it on top of your patch.
1. Rename 'xcodebuildsettings' to 'variables' (better name? prjvariables, internalvariables, ...)
2. Make its kind keyvalue instead of list., adjust xcode_common.lua accordingly.
3. (Optionally) Add new config-level APIs "sdkroot" and "infoplist", doing the same thing for Xcode as assigning aforementioned variables. Later it could be implemented for gmake too.
1) I prefer 'buildsettings' over 'internalvariables', it is more clear. One of the points is that those buildsettings can override build-in defaults, so you might want to reflect that in the naming?
2) The other suggestions, keyvalue sounds good but it depends on the new API so we have to wait for that and someone who is willing to adjust the code to the new API.
(3) I don't see the benefit of making a few build settings (sdkroot, infoplist) special as 'config-level' API?
1) "buildsettings" name creates artificial distinction between built-in variables, and new variables we can define with the same syntax (and there's no reliable way for Premake to distinguish between "new" variable and unknown "build setting"). "Build settings" is what you specify through usual Premake API.
2) keyvalue is in stable already (see vpaths)
3) see above - they aren't Xcode specific
That is why i like 'xcodebuildsettings' because it tells the user that the setting ends up in the XCode buildsettings section and not somewhere else.
In your proposal, how can the user choose if your 'variables' end up in the xcodebuildsettings section (for XCode) or not?
Thanks,
Erwin
>That is why i like 'xcodebuildsettings' because it tells the user that the setting ends up in the XCode buildsettings section and not somewhere else.
Understood. However, this maybe too low-level detail - first of all, this values end up as Xcode project variables.
>In your proposal, how can the user choose if your 'variables' end up in the xcodebuildsettings section (for XCode) or not?
Using configuration "xcode*" as in example above (yes, you can use action names there [1]). Actually you may hit a bug in Premake when trying to do so but it needs to be fixed.
[1] http://industriousone.com/configuration
Note that the current key-value implementation will merge the values on a key collision. This would give you an array of two values for SDKROOT:
Also, some tools (i.e. Visual Studio) have separate compile and link blocks, in addition to resource compilers, deployment tools and more. A single "build settings" isn't going to be enough in those cases.
The xcodebuildsettings was not a generic solution, it was purely created for XCode, to add or override the existing hardcoded build settings.The current patch will replace the existing, build-in build settings if there is a key conflict, which seems a good idea. Another issue is that the user might want to control if string values are surrounded by double quotes or no quotes. The patch allows this.
Anyway, I'm happy with my forked version, and once premake4 catches up in the future I'll look at it again.
Thanks for all the feedback!
>The xcodebuildsettings was not a generic solution, it was purely created for XCode
AFAIU, we prefer not to add APIs working only for one of actions.
Yeah, I'm undecided on the name. On the one hand, the values are absolutely targeted to a particular tool, so "xcodebuildsettings" makes sense. But then do we have "visualstudiobuildsettings"? And in that case, VS200x has different settings than 201x…it gets ugly.
So I'm currently leaning toward a generic name like "buildsettings".
But there is still the issue of build phases: compile vs. link vs. resource compiling vs. something else. Should we have "buildsettings", "linksettings", "resourcebuildsettings", and whatever else?
Why not something as generatorsettings (as in the project / makefiles generator), idesettings (even though makefiles etc. are not an IDE) or buildtoolsettings?
Good job guys btw!