[CMake] Having design issues implementing Xbox360 Generator support

David Genest david.genest at ubisoft.com
Tue Jan 19 12:05:09 EST 2010


Hi Again,

Hopefully I will catch the attention of cmake maintainers. I think Cmake support of Xbox 360 would help the gaming industry more easily adopt cmake to build their projects. I don't know it this work is too specific to warrant inclusion in cmake. This is a long post, so please bear with me. Please tell me if there is a better place to post this question.

I want to contribute the work I have done, but I need some guidance. 

Here is where I'm at: (Right now, I have what I call an alpha version of VisualStudio9 support for Xbox360)

A little background: Xbox360 projects do not differ all that much from the native counterpart. They have differing tool names for compiler and linker (i.e VCCLX360CompilerTool and VCX360LinkerTool). They also have two additional tools for converting the exe to an xbox image (VCX360ImageTool) and a tool to control how the deployment is enacted on the console (VCX360DeploymentTool). All this is supported in a platform named "Xbox 360". 

Starting with Visual Studio 9, to support these variations, I needed to implement a new platform in the Visual Studio sense. Seeing that this is precisely what was done for the win64 platform, I used this route of deriving a GlobalVisualStudio9XboxGenerator from cmGlobalVisualStudio9Generator.

In this xbox360Generator, I set the PlatformName field to "Xbox 360" (name based on the x360 project wizard). With this simple change, the projects are almost there. We still need to manage the differing tool names. Seeing that all the work of writing the projects is done in the LocalVisualStudio7Generator, I only needed 3 extension points to modify the base behaviour. To that end, I derived a LocalVisualStudio7Xbox360Generator from LocalVisualStudio7Generator and added three virtual functions: GetVCCompilerToolName(),GetVCLinkerToolName() which in the base return the default tool names and provide an empty AddPlatformSpecificTools(). These are reimplemented in the VisualStudio7Xbox360Generator to name correctly the tools on that platform. The AddPlatformSpecificTools() method adds the Xbox360DeploymentTool and VCX360ImageTool sections. These sections rely on user target properties being set which I also added to cmTarget.cxx. (XBOX360_DEPLOY_FLAGS, XBOX360_DEPLOY_ROOT, XBOX360_DEPLOY_TYPE, XBOX360_EMULATION_TYPE, XBOX360_IMAGE_FLAGS).

With these changes, the system almost works. Here is where I need some guidance. I am not sure that I did the correct changes in the system cmake files.

When I ran the initial configure, cmake complained that it could not build a simple program. This was tied to the wrong default libraries being set in the LocalGenerator. The default libraries are set in Windows-cl.cmake. I wanted a way to specify an alternative set of default libraries, and did not want the user to have to specify an override file. So I created a Windows-cl-xbox360.cmake file which basically sets the correct default libraries and linking conventions that xbox needs. But this was not enough, because the -xbox360.cmake file was never included. This inclusion is triggered by the CMAKE_SYSTEM_PROCESSOR variable  being set, so I hard-code it in the GlobalVisualStudio9XboxGenerator::AddPlatformDefinitions() override.

The Windows-cl-Xbox360.cmake file was still not included, so I had to add a "if (NOT CMAKE_SYSTEM_PROCESSOR)" around the unconditional set in CMakeDetermineSystem.cmake. This done, my file was correctly included. But the battle is not over. The CMakeCInformation.cmake file drives the inclusion of Windows-cl.cmake and Windows-cl-Xbox360.cmake, but the last one to be included (Windows-cl.cmake) overrides any changes that I make in the platform one. I had to add if (NOT <VariableSet>) around each unconditional set (i.e. if (NOT CMAKE_CXX_FLAGS_INIT) set CMAKE_CXX_FLAGS_INIT (...) endif()).

With these changes, the Xbox360Generator works. With one canveat: on the Xbox360 platform, the CMAKE_C[XX]_STANDARD_LIBRARIES_INIT variable are not the same for each configuration. In debug, each library is appended with a "d", and in release they are not suffixed. How should I manage this variation ? This variation in configuration is not present in the standard win32 projects. To support correctly the default values, I would need to modify the LocalVisualStudio7Generator to fetch a CMAKE_C[XX]_STANDARD_LIBRARIES_<CONFIG>_INIT and if it is present, use that. Is this a viable implementation?

Thank you very much to have read up to this. I really hope someone can help me. Please comment on the design strategy and let me know if there is interest in this work.

David.



More information about the CMake mailing list