views:

103

answers:

2

I'm trying to add the item

<key>UIStatusBarHidden</key><true/>

to my plist that's auto-generated by CMake. For certain keys, it appears there are pre-defined ways to add an item; for example:

set(MACOSX_BUNDLE_ICON_FILE ${ICON})

But I can't find a way to add an arbitrary property.

I tried using the MACOSX_BUNDLE_INFO_PLIST target property as follows: I'd like the resulting plist to be identical to the old one, except with the new property I want, so I just copied the auto-generated plist and set that as my template. But the plist uses some Xcode variables, which also look like ${foo}, and CMake grumbles about this:

Syntax error in cmake code when parsing string

  <string>com.bedaire.${PRODUCT_NAME:identifier}</string>

syntax error, unexpected cal_SYMBOL, expecting } (47)

Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.

In any case, I'm not even sure that this is the right thing to do. I can't find a good example or any good documentation about this. Ideally, I'd just let CMake generate everything as before, and just add a single extra line. What can I do?

A: 

You can add your values using @ and pass @ONLY to configure_file.

Unfortunately there is no simple way to add custom line to generated file.

Michal Čihař
What do you mean "add your values using @"; also, I'm not calling `configure_file` anywhere. The plist currently is automatically generated.
Jesse Beder
Ah, I thought that this is why you get the error. So where do you get it?
Michal Čihař
+1  A: 

Have you looked into copying the relevant *.plist.in file in /opt/local/share/cmake-2.8/Modules (such as MacOSXBundleInfo.plist.in), editing it to put <key>UIStatusBarHidden</key><true/> (or @VAR_TO_REPLACE_BY_CMAKE@), and adding the directory of the edited version in the CMAKE_MODULE_PATH?

Simeon Fitch
Thanks! I didn't notice this answer for a while, but it's great! (I didn't know those `*.plist.in` files even existed. FWIW, I created my own one (based on `MacOSXBundleInfo.plist.in`) and set `MACOSX_BUNDLE_INFO_PLIST` property on my target to that new one.)
Jesse Beder