Build tools.

Michel Fortin michel.fortin at michelf.com
Sat Oct 13 06:00:42 PDT 2007


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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/




More information about the Digitalmars-d mailing list