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.

Apart from that, how does the Xcode build process work? Can't you just call a binary from inside Xcode?

Alexander Panek wrote:
> 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.

Why would you look at the semantic lines instead of the import & file lines? They don't give you all files a module depends on and they only give module names (not filenames).
On the other hand, the import & file lines give you all imported modules (transitively) and all import()ed files, with the full filename for each given between brackets at the end of the line.

When I needed to automatically generate dependencies (from a makefile), I grepped the output for lines beginning with 'import' or 'file' when I passed '-c -o- -v' to the compiler (as well as the normal include flags etc.).
(-c makes sure this doesn't generate an executable and -o- stops generation of object files)

Frits van Bommel wrote:
> Alexander Panek wrote:
>> 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.
> 
> Why would you look at the semantic lines instead of the import & file lines? They don't give you all files a module depends on and they only give module names (not filenames).
> On the other hand, the import & file lines give you all imported modules (transitively) and all import()ed files, with the full filename for each given between brackets at the end of the line.

As far as I can tell, all imports listed after a line "semantic Module" are the dependencies of that module. At least that's how it looks like.

> (-c makes sure this doesn't generate an executable and -o- stops generation of object files)

Ay..should have added those, too.

Alexander Panek wrote:
> Frits van Bommel wrote:
>> Alexander Panek wrote:
>>> 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.
>>
>> Why would you look at the semantic lines instead of the import & file lines? They don't give you all files a module depends on and they only give module names (not filenames).
>> On the other hand, the import & file lines give you all imported modules (transitively) and all import()ed files, with the full filename for each given between brackets at the end of the line.
> 
> As far as I can tell, all imports listed after a line "semantic Module" are the dependencies of that module. At least that's how it looks like.

Oh, I missed the part where you said '+ following "^import"'.
I just used one invocation of DMD per module, so all imports would automatically be for that file.
You did miss 'file' lines though.

>> (-c makes sure this doesn't generate an executable and -o- stops generation of object files)
> 
> Ay..should have added those, too.

Well, they're not required, just what I used. If you pass -v when compiling normally and filter out the right lines it works fine. The times you need to recompile are the same ones where dependency information needs to be updated anyway.

On 10/13/07, Frits van Bommel <fvbommel@remwovexcapss.nl> wrote:
> You did miss 'file' lines though.

What are 'file' lines?

Janice Caron wrote:
> On 10/13/07, Frits van Bommel <fvbommel@remwovexcapss.nl> wrote:
>> You did miss 'file' lines though.
> 
> What are 'file' lines?

I mentioned this in my first post in this thread, but perhaps a demonstration is clearer: make sure there's a "somefile.txt" in the current directory and compile this with 'dmd -v -J.':
---
import std.stdio;

void main() {
	writefln(import("somefile.txt"));
}
---

On 2007-10-13 05:18:18 -0400, Alexander Panek <a.panek@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@michelf.com
http://michelf.com/

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@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.
> 

On 2007-10-14 10:07:03 -0400, Paolo Invernizzi <arathorn@NO_SPAMfastwebnet.it> said:

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

Sure, it'll be available when ready.

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