> Ideally a toolchain file should have only settings specific to
> the local machine where it will be used, such as the paths to
> staging prefixes where dependencies built for the target arch
> may be installed. All information that is general to the iOS
> platform should be in a module that come
On 09/23/2014 11:42 AM, Florent Castelli wrote:
> On 23 Sep 2014, at 16:56, Bill Hoffman wrote:
>> Much of the stuff found in these toolchains:
>> https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake
>> https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.c
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 s
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
On 9/23/14, Florent Castelli 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 files, constant merge co
On 23-Sep-14 19:42, Florent Castelli wrote:
On 23 Sep 2014, at 16:56, Bill Hoffman 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.
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
On 23 Sep 2014, at 16:56, Bill Hoffman 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 into this try_c
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 wo
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 c
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 se
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,
whil
12 matches
Mail list logo
