MantisBT - CMake
View Issue Details
0014854CMakeCMakepublic2014-03-31 12:532014-11-03 08:38
Petr Lefner 
Brad King 
normalminoralways
closedfixed 
MacOS X10.9.2
CMake 2.8.12.2 
CMake 3.1CMake 3.1 
0014854: Xcode projects with binary files cannot load in Xcode
If an project lists some binary files, CMake generator creates .pbxproject where htese files are listed as 'source files', which causes Xocde unable* to load that project.

* depends on total file size or amount; say that 300MB makes it about 1 hour until Xcode can be used. Until that, hourglass and 200% CPU drain suggest heavy background thinking about he files.

If those file are not listed in project, Xcode opens it like a charm.
Create a CMakeLists.txt with usual structure to have some binary target in there.
Then add some binary files (assets or resources), let say we have them within the DATA_FILES list variable (full paths).
Intention is to get those files into app bundle (.app/). For this case, do not consider that to put into .app, a small hack must be achieved.

# Collect resource files

foreach(FILE ${DATA_FILES})
    set_source_files_properties(
    ${FILE}
    PROPERTIES
    MACOSX_PACKAGE_LOCATION ${MACOSX_BUNDLE_BUNDLE_NAME}.app/${TARGET}
    GENERATED TRUE
    )
    list(APPEND ASSETS ${FILE})
endforeach()

# Add binary target and register resoruce files in project listings
add_executable(osx_app_target MACOSX_BUNDLE ${SOURCES} ${ASSETS})
Given method worked prior 2.8.12 (not sure exactly about problem version).
There's same issue if one wants to copy files via a custom command:

# Copy from SRC to DST, being part of current target.
add_custom_command(OUTPUT ${DST}
    COMMAND ${CMAKE_COMMAND} -E copy ${SRC} ${DST}
    MAIN_DEPENDENCY ${SRC}
    COMMENT "Copying ${SRC} to ${DST}")

This used to do same troubles even already prior 2.8.12


In case of further assistance, do not hesitate to ask for more information. If htere's a new way adding resources to MACOSX_BUNDLE target (into .app), I did not found it - please point me out.
No tags attached.
Issue History
2014-03-31 12:53Petr LefnerNew Issue
2014-03-31 13:03Brad KingNote Added: 0035582
2014-03-31 13:37Petr LefnerNote Added: 0035585
2014-03-31 14:09Brad KingNote Added: 0035587
2014-03-31 16:25Petr LefnerNote Edited: 0035585bug_revision_view_page.php?bugnote_id=35585#r1424
2014-03-31 16:31Petr LefnerNote Added: 0035592
2014-04-01 09:42Brad KingNote Added: 0035599
2014-04-01 18:27Petr LefnerNote Added: 0035614
2014-04-01 18:28Petr LefnerNote Edited: 0035614bug_revision_view_page.php?bugnote_id=35614#r1432
2014-05-16 10:23Brad KingNote Added: 0035890
2014-05-16 10:23Brad KingAssigned To => Brad King
2014-05-16 10:23Brad KingStatusnew => assigned
2014-05-16 10:23Brad KingTarget Version => CMake 3.1
2014-05-19 09:42Brad KingStatusassigned => resolved
2014-05-19 09:42Brad KingResolutionopen => fixed
2014-05-19 09:42Brad KingFixed in Version => CMake 3.1
2014-11-03 08:38Robert MaynardNote Added: 0037138
2014-11-03 08:38Robert MaynardStatusresolved => closed

Notes
(0035582)
Brad King   
2014-03-31 13:03   
There is a mapping from file extension to Xcode file type (explicitFileType or lastKnownFileType):

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;hb=v3.0.0-rc3#l753 [^]

Is there a file type that could be used for these files such that Xcode knows what to do with them?
(0035585)
Petr Lefner   
2014-03-31 13:37   
(edited on: 2014-03-31 16:25)
The files are custom format with .snd or .skin extension. Therefore - no. I guess that both commands (add_binary_target, add_custom_command), based on their nature, assume the files in their arguments refer to source files, if the type mapping does not recognize something else.

(0035587)
Brad King   
2014-03-31 14:09   
Re 0014854:0035585: If one were creating this project by hand through the IDE and not using CMake, how would the resulting .pbxproj file treat these files?
(0035592)
Petr Lefner   
2014-03-31 16:31   
They call it just 'file':

BA477D6518EA070A006CEFE3 /* large.skin */ = {isa = PBXFileReference; lastKnownFileType = file; name = large.skin; path = ../../../../../../checkouts/trunk/designs/skins/large.skin; sourceTree = "<group>"; };

(Added manually, it automatically became bundle resource and has been included into 'Copy Bundle Resources' Build Phase)
(0035599)
Brad King   
2014-04-01 09:42   
Re 0014854:0035592: So the problem is the "sourcecode" default for unknown file types as explained in the comment here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;hb=v3.0.0-rc3#l822 [^]

Perhaps we could add a source file property called "XCODE_FILE_TYPE" or something to allow that to be overridden.
(0035614)
Petr Lefner   
2014-04-01 18:27   
(edited on: 2014-04-01 18:28)
Indeed, if I manually open the generated .pbxproj and replace 'sourcecode' in the line

C0D42DDA753B4EB9BA9F909F /* /checkouts/trunk/bin/skins/large.skin */ = {isa = PBXFileReference; explicitFileType = sourcecode; fileEncoding = 4; name = "large.skin"; path = "bin/skins/large.skin"; sourceTree = SOURCE_ROOT; };

with 'file' to 'explicitFileType' parameter, Xcode feels fine with that: changing this with all my binary files in the project makes Xcode open the project quickly (and it even does not complain about 'fileEncoding' parameter there, which is, obviously, nonsense to a binary resource).

Besides that, clicking the file item in the Project Navigator pane will not cause the Code Editor window to open it in text mode (showing unreadable binary stuff) like it used, if the file type was 'sourcecode' - instead, a blank window with large icon appears (I guess the icon is based on MIME stuff, e.g. in case of .png, image preview will be used.)

(0035890)
Brad King   
2014-05-16 10:23   
I've added new source file properties to set either explicitFileType or lastKnownFileType:

 Xcode: Refactor internal source file type selection
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae80cb9f [^]

 Xcode: Add source file property to control file type (0014854)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a339ea65 [^]

That should make this use case possible and also allow work arounds to other cases when the wrong type is chosen by default.
(0037138)
Robert Maynard   
2014-11-03 08:38   
Closing resolved issues that have not been updated in more than 4 months.