Cmake Xcode

There are facilities in Cmake for hinting source code to be treated as resources for an iOS App, and that works modestly well. When you generate an Xcode project, the code behavior is close to being right. You get a project that moves icon data and storyboard data and so forth into the final bundle in the right locations. You can even set a property tells the app to use a specific icon group as it’s main icon (which would be good, but I haven’t been able to make it work). However, modern iOS apps need to compile the images and icons into an asset catalog and the .storyboard files need to be compiled into .storyboards files and stored in a Base.lproj directory for later localization (don’t even get me started on trying to engineer further localization via Cmake). So I have been able to move the UI Resources (images and storyboards) to the right folder layout with the RESOURCE target property and the MACOSX_PACKAGE_LOCATION source code property, but I am definitely not communicating to Cmake that they need to be “compiled” into the form that iOS is expecting to consume them at runtime.

  1. CMAKEBUILDTYPE isn't used by multi-configuration generators (Xcode, Visual Studio, etc), thus I provided an example to check this first. The default value for CMAKEBUILDTYPE is an empty string. And user can set CMAKEBUILDTYPE to any value at the cmake command line.
  2. Casablanca and Xcode I was using Xcode 5.1.1, Casablanca 2.0.1, cmake, openssl 1.0.1g, boost 1.55.0. At start we will do everything the same as Casablanca suggest in documentation Setup and Build on OSX.

So here are some possible directions to go:

Cmake xcode workspace

To be able to access your ssh keys from RDM please connect ssh-key interface: sudo snap connect redis-desktop-manager:ssh-keys.

Cmake Xcode

1.) stop using MACOS_PACKAGE_LOCATION and instead use add_custom_command to do what Xcode does at build time with all these things. That’s good, because, I’m probably going to have to do that anyway to make the ninja code work, assuming I meed both paths to work (which is right now, not a hard requirement of my project). What I don’t like about that is that Apple changes its build tool behaviors more often than I’d like, and they’re mot too interested in backward compatibility, so my custom command will be frozen in time.


2.) Leave things the way they are (more or less) and post process the generated Xcode project in python to bless all the files to be treated in the appropriate way. This is good because it’s surprisingly easy to do, but bad because it involves reverse engineering the XML of the project format, generating UUID’s, and all kinds of error-prone and unsupported behaviors.

3.) figure out how to properly hint the resource files, so that CMake generates an Xcode project that simply knows how to treat the files appropriately. This would be ideal, but it’s also very arcane and brittle. I founds some really weird behaviors, like failing to add the x86_64 architecture doesn’t produce a project that only works on devices, it produces a project that fails at build time (???). Nonetheless, I’d like to try this approach.

So I’m looking to the community to for wisdom in doing number 3 (numbers 1 or 2, I know how to do). Here’s some partial code for the sake of discussion:

The RESOURCE property is commented out, because if you properly apply the source code property MACOSX_PACKAGE_LOCATION on the files in RESOURCE_FILES, they will be moved to their proper destinations in the bundle, the information in the RESOURCE target property is implicit (for general purpose resources, this is exactly the thing to do). The problem is that this mechanism ONLY knows how to move files that are source code into destinations within the bundle. It obviously doesn’t understand how to properly process files of various specific kinds into type-specific formats. I used to use the RESOURCE target property alone, and had some success, but it was very hard to target the outputs to a standard location. I’m thinking the path forward is to mix and match. For example, I noticed that treating the folder with the storyboard files as a source file, and blessing it with its own MACOSX_PACKAGE_LOCATION had some desirable results, but when I switch to using the property on the individual storyboard files, it seemed to be redundant. Maybe it’s not. Maybe one says “compile these as resources” and the other says “put the compiled outputs here”. You don’t always need both, but in the case of storyboards you do. You would use the GENERATED key word and bless the speculative output of the compilation with MACOSX_PACKAGE_LOCATION and specify the folder they’re in as a RESOURCE, so it has the side effect of creating the compiled versions. I’ll experiment and see.

Anyone solve some of these problems yet? Is this just a missing feature, and I’m whistling in the wind to hope that this works? There are some future properties that are supposed to handle this mentioned in some feature requests and they are found in the source for version 3.16.4, but they are currently ignored.

The thing is this: you can’t be successful building an iOS application without these behaviors working and people have been successful in creating iOS apps with Cmake. However the examples I’ve seen on, say, GitHub generally use some combination of methods 1 and 2 above, and I would greatly like to avoid that. Still if the Cmake developers got even the most basic “hello world” to work on iOS, they would have to address this issue. Another thing I’m looking at is using another source code property (XCODE_EXPLICIT_FILE_TYPE for example) to make clear to Cmake certain special folders, like *.xcassets, should be handled a specific way (though Xcode should derive that from the extension.

All thoughts and ideas are much appreciated. You should know that I have scoured the Internet for wisdom before joining this forum and pleading for help, but I’m currently a bit stalled.

If enabled, the Xcode generator will generate schema files. Theseare useful to invoke analyze, archive, build-for-testing and testactions from the command line.

This property is initialized by the value of the variableCMAKE_XCODE_GENERATE_SCHEME if it is set when a targetis created.

Cmake Xcode Tutorial

The following target properties overwrite the default of thecorresponding settings on the 'Diagnostic' tab for each schema file.Each of those is initialized by the respective CMAKE_ variableat target creation time.
















Cmake Xcode12

Cmake Xcode

The following target properties will be applied on the'Info', 'Arguments', and 'Options' tab: