View Issue Details [ Jump to Notes ]

[ Print ]

Project

Category

View Status

Date Submitted

Last Update

0002253

CMake

public

2005-09-18 19:19

2005-09-21 18:23

Reporter

Eric Wing

Assigned To

Bill Hoffman

Priority

low

Severity

feature

Reproducibility

always

Status

closed

Resolution

won't fix

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0002253: Ability to generate native projects for other systems/versions

Description

I would like the ability to generate projects for other compilers or versions. This topic has come up before, but the usage patterns for this are becoming more clear to me as my CMake stuff is beginning to interact with other developers.
I know the Windows/Visual Studio side is a mess because there are no standard development paths and drive letters can be anything. So for simplicity, I would like to focus in on OS X/Xcode for now.

So it would be nice if I could pre-generate Xcode projects for different target systems. We have already discussed how Xcode 1.5 and 2.1 break compatibility in the file formats. It would be useful if I could generate both and then send out those projects for others to use rather than them needing to install and run CMake for their own systems.

The first problem is that other developers I have to interact with don't know about CMake. This poses two different problems for me. First, I spend a lot of time teaching these people what CMake is and how to run it. (Incidentally, I find that people have a very hard time understanding the out-of-source build.) The other problem is the installation of CMake itself. The people I deal with seem to fall into two categories, people who don't know Unix style tools and how to install stuff from them (this includes things like CVS too), and people who do understand this, but refuse to install anything until they totally trust the software and find it absolutely necessary because they are security paranoid. In the former case, I spend a lot of time telling people how to download source from CVS and how to use the command line. In the second case, I always seem to fail in convincing people to install this software. In either case, it is a headache for me, and just giving them a proper Xcode project would be much easier.

I should also step back and explain the actual usage patterns. There seem to be two I am falling into. I need to work with two different sets of developers. The first group are developers I work directly with and know personally. I usually can get these people to install CMake after much effort on my part. We have a similar, but not identical development environment.

The second group is external developers I deal with. I help maintain some packaging systems for some open source projects. I am considering implementing a CMake system for them to make easier on my end (though I first need OS X framework build support in CMake). But I will have a hard (if not impossible) time convincing developers to use CMake to generate their projects. I have already taken a lot of criticism for even mentioning CMake on the mailing lists because it is not a standard component with OS distributions. Furthermore, users used to just clicking on a project without touching the command line are going to get lost.

So in the first group of people, I can generally get people to install CMake. But it takes training which is time I have to spend. It would be much easier if I could just generate a project for them and go. For these systems, standard library and include file locations do not vary. The only wildcard is where they place the actual project files. But we do have one additional wild card. We have a few systems running Panther instead of Tiger so we have the Xcode 1.5/2.1 compatibility problem.

In the second group, things are potentially more random. But it turns out that at least for OS X and the projects I deal with, things always go to standard places and are actually very predictable. So this case actually looks exactly like the first group.

So maybe this will have to be an Xcode only feature (and can't be applied to Visual Studio) where I can generate projects for either 1.5/2.1, but it would still be handy.

So I believe CMake will need a modification though to pull this off. The big issue is how the paths are set. CMake seems to have things that are all absolute or all relative (though I haven't explored the relative details). I think we would need a hybrid. I think the easiest way to accomplish this is to use relative paths for everything except for those components that lie in "officially designated" absolute areas. These are pretty much already defined by Apple. Anything in /System, /Library, and the Unix ones /usr, etc. There is one minor complication, every user has their own /Library in their home directory. This is still useful as absolute, but you don't want to expand the user name for portability. Xcode allows the variable $(HOME), so you can set the path to $(HOME)/Library/... which gets around this problem.

Another Xcode trick is to always set the search paths, particularly for Frameworks, to $(HOME)/Library/Frameworks, /Library/Frameworks, and /System/Library/Frameworks.

Thank you

Notes
(0003040) Bill Hoffman (manager) 2005-09-21 14:26	This has come up serveral times, and CMake is by design always required to be installed on the build computer. Due to the system introspection features of CMake, it is not feasable to generate a project on one machine and move the project to a different machine. It just would not work in a reliable manner. Users should not have to use CVS cmake, Xcode support is now in the CMake 2.2.1, so that problem should go away for you. There is also some work being done to have more of GUI for the Mac.

(0003043) Eric Wing (reporter) 2005-09-21 18:23	A GUI would be very nice. Just a suggestion...It would be very helpful if you could make this a stand-alone, self-contained app-bundle, so it is drag-and-droppable and relocatable to anywhere on the system. This would avoid many of the permissions/security issues.

Issue History
Date Modified	Username	Field	Change

Relationships