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