[Cmake] Re: CMake Apple XCode support?

[Zachary Pincus]

Hello Eric,

First off, I certainly agree that it would be great if CMake could 
create XCode projects automatically.

In response to your questions about XCode and Makefiles: in general, 
the really cool features do not seem available. Specifically, fix and 
continue, distributed builds, predictive/incremental compilation, good 
code completion, and the like, do not seem to be really available. 
Basically, anything that requires XCode to talk directly to GCC, and a 
smattering of other things, does not work properly.

The indexing does work, and it's easy enough to add all the files in 
the source tree to XCode, and simple code completion works. The 
debugger works, and the build errors from GCC get parsed fine. The 
"errors and warnings" smart group doesn't get populated right, but 
there is access to the errors (in a plenty fine GUI) otherwise. (Apple 
knows about this issue.)

As to the question of whether to generate project files directly or 
with XCode via Applescript, I can clarify some questions:
First, Applescript is basically an API to program functionality, and as 
such, doesn't depend on the GUI at all. As such, the designers need to 
specifically code hooks for Applescript calls into their program code. 
(Apple does offer "GUI Scripting" for non-Applescript-enabled programs, 
which does break when the interface changes, but XCode has pretty 
complete Applescript functionality built in.) As such, this is actually 
a nice option, since the Applescript "API" is already public, 
documented, and supported, and Apple therefore will be more reticent to 
change that than the file formats. Though you raise a good point that 
legacy project files will likely be supported for a long time anyway.

There are hooks to call scriptable applications through interprocess 
communication ("Apple events"), or one could simply write a text script 
to disk, and then execute that script. This latter approach is sort of 
clever: CMake writes a script that then XCode executes to on-the-fly 
build the appropriate project. (It might also be too clever by half.)

Anyhow, the downsides of the applescript approach are:
(1) Requires learning applescript. (This may or may not be less painful 
than reverse-engineering a file format.)
(2) CMake would then *reqire* XCode to be present to build project 
files, and would actually cause XCode to start up in order to make the 
project. This is intrusive, at variance with how CMake behaves 
otherwise, and prevents creating XCode projects on non MacOS computers. 
Of course, if CMake just writes out an applescript that, when executed, 
causes XCode to create an appropriate project, this complaint is 
largely mitigated.

Just out of curiosity, is there a "CMake Project Writer" interface 
somewhere that I could maybe look at to see if XCode's applescript 
interface is even up to all the requirements for CMake?

Anyhow, I'm happy to help where I can.

Zach Pincus

Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine


On Apr 22, 2004, at 12:24 PM, Eric Wing wrote:

> Very interesting approachs you two have...However,
> having CMake generate native Xcode projects would
> still be the best solution for me. I have to maintain
> Windows (multiple compilers), Linux, and FreeBSD
> builds in addition to OS X, and I just don't want to
> have to muck around with more stuff. Since CMake
> already generates native projects for so many other
> systems, it seems appropriate to handle Xcode too.
>
> Out of curiosity, does the Xcode using Makefiles
> automatically give you access to all the files and do
> indexing through the IDE? And is it able to distribute
> builds to other computers on the network since Xcode
> is not directly managing the dependency information?
>
>
> As for Applescript, it sounds like an interesting
> idea, but I don't know anything about Applescript. And
> being bogged down with supporting so many platforms
> already, I wouldn't have time to fiddle with it. I
> really need a one step solution.
>
> Also, I don't know Applescript well enough to know
> this, but will Applescript break if the Xcode UI
> designers reorganize or rename some of the menu or
> setup interfaces? I think the front-end is more likely
> to go through cosmetic changes than the actual file
> format. Apple will still have to support legacy file
> formats (as they currently do with Project Builder)
> for at least awhile, to give developers a chance to
> switch. However, the modifications to UI's seem to be
> fair game from Apple's recent behavior.
>
> I think building native Xcode support for today's
> format would not risk becoming unusable anytime soon.
> I think they would have to give developers at least a
> year after they hypothetically change it to switch,
> but most likely longer.
>
> Thanks,
> Eric
>
> --- Zachary Pincus <zpincus at stanford.edu> wrote:
>> Hello,
>>
>> I also just filled out a bug form with Apple.
>>
>> More to the point here, I have been using XCode with
>> the CMake
>> generated makefiles for some time. This approach
>> works quite well, and
>> would be easy (though almost unnecessary) to
>> automate with Applescript.
>> Unnecessary because it is already so easy to add a
>> Make-based project
>> to XCode.
>>
>> However, a different approach might be to attempt to
>> use Applescript to
>> generate full-fledged XCode build files *instead* of
>> the makefiles.
>> Instead of trying to generate an Xcode project file
>> based on an
>> unstable spec, it might be easier to use Applescript
>> to tell XCode to
>> build the project file itself.
>>
>> XCode has a fairly complete Applescript dictionary,
>> which looks like
>> enough to procedurally generate a project. (Open
>> Script Editor, and
>> choose "Open Dictionary..." from the file menu, and
>> then choose XCode
>> form the list, to see the XCode Applescript
>> dictionary.)
>>
>> I don't know if this is an overall more or less
>> preferable way to
>> generate project files than trying to write the
>> files directly. I
>> suspect that for the time being, the Applescript
>> method will be both
>> more accessible, better documented, and better
>> supported, than the
>> other. However, I'm not sure if this is best for an
>> ultimate solution.
>>
>> I'm happy to look more into this and help where I
>> can; however, I know
>> relatively little about CMake's internals.
>>
>> Zach Pincus
>>
>> Department of Biochemistry and Program in Biomedical
>> Informatics
>> Stanford University School of Medicine
>>
>> On Apr 22, 2004, at 11:23 AM, Chris Scharver wrote:
>>
>>> On Apr 22, 2004, at 12:58 PM, Eric Wing wrote:
>>>
>>>> In conclusion, I suggest that everybody
>> interested in
>>>> seeing CMake build native Xcode projects file a
>>>> Bug/Enhancement request with Apple to release the
>>>> Xcode file format documentation with the
>> understanding
>>>> we use at our own risk.
>>>
>>> Thank you very much for the additional
>> information, Eric! Could you
>>> provide the bug tracking numbers for those entries
>> that have already
>>> been filed? It could make one less step for the
>> engineers to track
>>> down when reading new requests.
>>>
>>> In the meantime, it looks like the way to
>> integrated CMake projects
>>> with XCode is to create a new XCode project that
>> uses the makefiles. I
>>> have done it a few times, but maybe something like
>> AppleScript could
>>> automate that process.
>>>
>>> Chris
>>> --
>>> Chris Scharver
>>> Electronic Visualization Laboratory
>>> The University of Illinois at Chicago
>>> Ph: 312-996-3002   FAX: 312-413-7585
>>> <http://www.evl.uic.edu/scharver/>
>>>
>>> _______________________________________________
>>> Cmake mailing list
>>> Cmake at www.cmake.org
>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>
> _______________________________________________
> Cmake mailing list
> Cmake at www.cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>