Re: [cmake-developers] iOS support

2014-10-01 Thread Florent Castelli
Thanks for the detailed information. My hackweek starts on Monday and I'll start working on these issues then. I'll work on finding a way to unify toolchain files for simulator and devices first. I don't think I'll try to work on iOS8 features since my company is shipping for iOS6 and there are so

Re: [cmake-developers] iOS support

2014-09-30 Thread Eric Wing
On 9/23/14, Florent Castelli florent.caste...@gmail.com wrote: Hi! My company is organizing soon a hack week where each employee is able to work on any project he wants. So, I've decided to work with Cmake and improve support for iOS to help the product team getting rid of manual project

Re: [cmake-developers] iOS support

2014-09-30 Thread Eric Wing
Thought of one more. I hate how the top, default target is ALL_BUILD. This is problematic for both Xcode and Visual Studio because when you use the big giant run button in the UI, the IDE is confused because ALL_BUILD is an aggregate target and not a real thing that can be run. At least for Xcode,

Re: [cmake-developers] iOS support

2014-09-29 Thread Ruslan Baratov via cmake-developers
On 23-Sep-14 19:42, Florent Castelli wrote: On 23 Sep 2014, at 16:56, Bill Hoffman bill.hoff...@kitware.com wrote: That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it

[cmake-developers] iOS support

2014-09-23 Thread Florent Castelli
Hi! My company is organizing soon a hack week where each employee is able to work on any project he wants. So, I've decided to work with Cmake and improve support for iOS to help the product team getting rid of manual project files, constant merge conflicts and bad project file documentation,

Re: [cmake-developers] iOS support

2014-09-23 Thread Robert Maynard
The lowest hanging fruit would be to transition over to setting the global variable CMAKE_MACOSX_BUNDLE which is used to initialize the MACOSX_BUNDLE property on all the targets. CMake also supports CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. Lastly have you looked at

Re: [cmake-developers] iOS support

2014-09-23 Thread Bill Hoffman
On 9/23/2014 8:09 AM, Robert Maynard wrote: The lowest hanging fruit would be to transition over to setting the global variable CMAKE_MACOSX_BUNDLE which is used to initialize the MACOSX_BUNDLE property on all the targets. CMake also supports CMAKE_XCODE_ATTRIBUTE global variables to allow easy

Re: [cmake-developers] iOS support

2014-09-23 Thread Bill Hoffman
That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It

Re: [cmake-developers] iOS support

2014-09-23 Thread Florent Castelli
On 23 Sep 2014, at 16:56, Bill Hoffman bill.hoff...@kitware.com wrote: That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look

Re: [cmake-developers] iOS support

2014-09-23 Thread Bill Hoffman
On 9/23/2014 11:42 AM, Florent Castelli wrote: I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. It's mostly changing cmCoreTryCompile::FindOutputFile() and