Build tools.

[Paolo Invernizzi]

Are you thinking about to release the Xcode plugin? I'm very interested 
in it!

Cheers, Paolo

Michel Fortin wrote:
> On 2007-10-13 05:18:18 -0400, Alexander Panek <a.panek at brainsware.org> 
> said:
> 
>> Michel Fortin wrote:
>>> The plugin only needs to tell Xcode which files depend on which 
>>> files. The rest of the build process is handled by Xcode, with the 
>>> help of a few other settings the plugin provide.
>>
>> The easiest way to achieve the imports/dependencies is to parse the 
>> output of `dmd -v file1.d file2.d', and grep for "^semantic <fileX>" + 
>> following "^import".. just take a look yourself, I'm sure it's easier 
>> than using the frontend itself.
> 
> Given that it works reasonably well already using the front end, I'll 
> probably stick to what I have, at least for now. Beside, I'm using the 
> front end for a few other things too, so I'll have the front end built 
> in the plugin anyway.
> 
> For instance: the Xcode language specification format can't handle 
> things like nested /+/+comments+/+/, r"raw strings\", binary numbers 
> (0b1101) and a few other nice things about D, so for syntax highlighting 
> in D files I'm substituting Xcode's lexer for the one in the front end.
> 
>> Apart from that, how does the Xcode build process work? Can't you just 
>> call a binary from inside Xcode?
> 
> Yes. I could create a target with a shell script build phase in which I 
> would call DSSS/Rebuild. But my goal is to have better integration than 
> that.
> 
> Within an Xcode project, you choose the files you wish to compile for a 
> specific target. When building, Xcode finds the most appropriate build 
> rule for each file. A build rule determines the dependencies for a given 
> file, the command to run to compile that file, and the products of 
> running that command (these are object files in our case). Xcode creates 
> the dependency graph and run the appropriate build rules for files which 
> have been modified or have some dependency modified; then it sends the 
> products (objects files) to the linker.
> 
> The user interface gives various clues about what's happening during 
> that process. You can see which file need to be recompiled, the size of 
> the produced object files, the build history (in a nice outline view), 
> have the error count for each file in a list and see each compilation 
> error in the margin when editing. You can also compile files 
> individually and get the same (for only one file). All this is provided 
> by the compiler specification class in Xcode, which can only deal with 
> one file at a time.
> 
> So it turns out that it's much easier to just create a compiler 
> specification class to figure out the dependencies and give GDC the 
> proper command line arguments than try to overthrown the Xcode building 
> process with something foreign. The result is probably better than what 
> could be done with DSSS/Rebuild too: beside the better feedback in the 
> UI (which is partially lost when Xcode is not in charge of compiling 
> individual files), Xcode will also handle a mix of files in different 
> languages (with their depdenencies) in the same target.
>