[TxMt] Re: Build Xcode projects in Textmate 2?

[Allan Odgaard]

On 11 Apr 2014, at 20:01, John Sturgeon wrote:

> 1) build a project (obj-c)

I assume you’re building a Cocoa application.

For TextMate 1.x I used an Xcode project myself and built it via the 
`xcodebuild` command line tool, though called from the Xcode bundle, 
which gave me build output inside TextMate (with clickable 
warnings/errors).

This is shown at 
http://blog.macromates.com/2005/html-output-for-commands/

However, `xcodebuild` has probably changed its output a dozen times 
since then, so I would be surprised if it still works.

Also, I found the workflow cumbersome because I had to go to Xcode when 
adding and removing files, so for 2.0 I initially used CMake but later 
did my own build system based on ninja.

I have not kept up with CMake, but this might be a viable alternative to 
using `xcodebuild`. CMake generates either Makefiles or ninja build 
files, for which there are TextMate bundles so that the build can be run 
from within TextMate (I’d recommend setting it up to generate ninja 
build files over Makefiles).

> 2) show compile errors while editing

Not possible.

> 3) autocomplete

You can use option-escape to complete Cocoa and standard library stuff.

The Cocoa completion also works when implementing (delegate) methods, in 
this case leave out the return type, e.g.:

     - windowWill‸

Pressing option-escape here will show you all the windowWill… methods.

Another useful feature is ⌃H which will give you documentation for the 
current thing the caret is on. This works on method signatures like 
above (when the signature is a standard method), constants, types, 
method calls, C and C++ functions, etc.

> 4) debug?

Nothing here either.

> Are these things possible to do within text mate, or perhaps a hybrid 
> of both editors?

I tend to suggest people just use Xcode for Cocoa development because 
building Cocoa apps have so many steps to it, and I am not familiar with 
an alternative build system that does not make it the user’s 
responsibility to manage this complexity.

That said, I am not using Xcode myself and find my own build system much 
more pleasurable to work with, than how I remember Xcode, for example I 
never need to manually add or remove files, the build system detects 
that automatically and when a file is removed, so are the things 
generated from it in the build directory (so no old resources or public 
headers will stick around, making you not realize that something 
depended on the thing you removed, until after next clean build), no 
fiddling around with UI palettes to harmonize build settings accross 
your main project and sub-projects representing custom frameworks being 
used, no custom shell phases that always run because the dependencies 
can’t be expressed, depending on a framework automatically depending 
on the succesful run of that framework’s tests, etc.

If it sounds interesting, you can look at the TextMate project at 
https://github.com/textmate/ — the `target` files are build system 
declarations, and `bin/gen_build` is responsible for reading them and 
generating a ninja build file, which will re-run `bin/gen_build` if any 
of the `target` files changes, or any of the folders from which files 
are loaded via globs.

Relevant to mention about this is that the “build target” is folder 
specific (via `.tm_properties`). So if I use ⌘B in a test file, it 
just builds and tests the target to which the tests belong.