• David Brown (8/8) Oct 10 2007 Just curious what people are using to build programs in D. There is
• Bill Baxter (4/14) Oct 10 2007 Try dsss / rebuild
• Clay Smith (2/20) Oct 11 2007 +1 for dsss
• BCS (4/15) Oct 10 2007 I use build inside a bash script. The bash is mostly because I do lots o...
• Jarrett Billingsley (3/12) Oct 11 2007 I use build, but most of my projects can also be compiled with DSSS.
• =?ISO-8859-1?Q?R=e9my_Mou=ebza._?= (2/12) Oct 11 2007 I had to rename the file macro.d into macro_.d and run "sed -i 's/macro/...
• Henning Hasemann (13/13) Oct 11 2007 I used rebuild but came across its limits when I had to work with
• Michel Fortin (9/9) Oct 12 2007 Using Xcode here, with Alanz's D plugin. Or rather I used to use
• Alexander Panek (5/8) Oct 12 2007 Why don't you just use DSSS/Rebuild for that?
• Michel Fortin (12/18) Oct 12 2007 The plugin only needs to tell Xcode which files depend on which files.
• Alexander Panek (7/10) Oct 13 2007 The easiest way to achieve the imports/dependencies is to parse the
• Frits van Bommel (13/17) Oct 13 2007 Why would you look at the semantic lines instead of the import & file
• Alexander Panek (4/18) Oct 13 2007 As far as I can tell, all imports listed after a line "semantic Module"
• Frits van Bommel (9/29) Oct 13 2007 Oh, I missed the part where you said '+ following "^import"'.
• Janice Caron (2/3) Oct 13 2007 What are 'file' lines?
• Frits van Bommel (10/14) Oct 13 2007 I mentioned this in my first post in this thread, but perhaps a
• Michel Fortin (41/52) Oct 13 2007 Given that it works reasonably well already using the front end, I'll
• Paolo Invernizzi (4/61) Oct 14 2007 Are you thinking about to release the Xcode plugin? I'm very interested
• Michel Fortin (7/8) Oct 14 2007 Sure, it'll be available when ready.

David Brown <dlang davidb.org> writes:

Just curious what people are using to build programs in D.  There is
<http://www.dsource.org/projects/build>, but it doesn't even compiler with
gdc-0.24, hitting 'macro' as a keyword.

I've managed to construct some python code that runs gdc verbosely, and
parses the output in order to generate dependency information, but it seems
kind of silly to write this when it looks like other tools do the job.

Thanks,
David Brown

Bill Baxter <dnewsgroup billbaxter.com> writes:

David Brown wrote:
 Just curious what people are using to build programs in D.  There is
 <http://www.dsource.org/projects/build>, but it doesn't even compiler with
 gdc-0.24, hitting 'macro' as a keyword.
 
 I've managed to construct some python code that runs gdc verbosely, and
 parses the output in order to generate dependency information, but it seems
 kind of silly to write this when it looks like other tools do the job.
 
 Thanks,
 David Brown

Try dsss / rebuild
http://www.dsource.org/projects/dsss

--bb

Clay Smith <clayasaurus gmail.com> writes:

Bill Baxter wrote:
 David Brown wrote:
 Just curious what people are using to build programs in D.  There is
 <http://www.dsource.org/projects/build>, but it doesn't even compiler 
 with
 gdc-0.24, hitting 'macro' as a keyword.

 I've managed to construct some python code that runs gdc verbosely, and
 parses the output in order to generate dependency information, but it 
 seems
 kind of silly to write this when it looks like other tools do the job.

 Thanks,
 David Brown

 
 Try dsss / rebuild
 http://www.dsource.org/projects/dsss
 
 --bb

+1 for dsss

BCS <ao pathlink.com> writes:

Reply to David,

 Just curious what people are using to build programs in D.  There is
 <http://www.dsource.org/projects/build>, but it doesn't even compiler
 with gdc-0.24, hitting 'macro' as a keyword.
 
 I've managed to construct some python code that runs gdc verbosely,
 and parses the output in order to generate dependency information, but
 it seems kind of silly to write this when it looks like other tools do
 the job.
 
 Thanks,
 David Brown

I use build inside a bash script. The bash is mostly because I do lots of 
other stuff at the same time.

I think I got Build as a binary from someplace.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"David Brown" <dlang davidb.org> wrote in message 
news:mailman.405.1192078598.16939.digitalmars-d puremagic.com...
 Just curious what people are using to build programs in D.  There is
 <http://www.dsource.org/projects/build>, but it doesn't even compiler with
 gdc-0.24, hitting 'macro' as a keyword.

 I've managed to construct some python code that runs gdc verbosely, and
 parses the output in order to generate dependency information, but it 
 seems
 kind of silly to write this when it looks like other tools do the job.

 Thanks,
 David Brown

I use build, but most of my projects can also be compiled with DSSS. 

=?ISO-8859-1?Q?R=e9my_Mou=ebza._?= <ray.jay.ay.moueza pleasedontspam.gmail.com> writes:

David Brown Wrote:

 Just curious what people are using to build programs in D.  There is
 <http://www.dsource.org/projects/build>, but it doesn't even compiler with
 gdc-0.24, hitting 'macro' as a keyword.
 
 I've managed to construct some python code that runs gdc verbosely, and
 parses the output in order to generate dependency information, but it seems
 kind of silly to write this when it looks like other tools do the job.
 
 Thanks,
 David Brown

I had to rename the file macro.d into macro_.d and run "sed -i
's/macro/macro_/g' *.d" to have Build compiled with gdc-0.24. Then I got
everything fine. 

Henning Hasemann <hhasemann web.de> writes:

I used rebuild but came across its limits when I had to work with
D-code that is generated by a D-program. So I use ole gnu make where I
can set up all rules myself.

That works quite well (and if written with a little care the same
makefile runs on windows as well as on linux), the only pain is that I
have to run "make clean" everytime I worked on a templated class or
similar since I'm too lazy to track those dependencies.

Maybe when the ongoing d parsers advance there will be an easy way to
generate those dependencies automagically (aka "make dep").

Henning

-- 
GPG Public Key:
http://gpg-keyserver.de/pks/lookup?op=get&search=0xDDD6D36D41911851

Michel Fortin <michel.fortin michelf.com> writes:

Using Xcode here, with Alanz's D plugin. Or rather I used to use 
Alanz's plugin.

I'm currently working on a new plugin for Xcode which can track 
dependency information and make D integration more seemless. It uses 
the DMD front end to parse the files.

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

Alexander Panek <alexander.panek brainsware.org> writes:

On Fri, 12 Oct 2007 08:58:52 -0400
Michel Fortin <michel.fortin michelf.com> wrote:
 I'm currently working on a new plugin for Xcode which can track 
 dependency information and make D integration more seemless. It uses 
 the DMD front end to parse the files.

Why don't you just use DSSS/Rebuild for that?

-- 
Alexander Panek <alexander.panek brainsware.org>

Michel Fortin <michel.fortin michelf.com> writes:

On 2007-10-12 11:19:04 -0400, Alexander Panek 
<alexander.panek brainsware.org> said:

 Michel Fortin <michel.fortin michelf.com> wrote:
 I'm currently working on a new plugin for Xcode which can track
 dependency information and make D integration more seemless. It uses
 the DMD front end to parse the files.

 
 Why don't you just use DSSS/Rebuild for that?

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.

Perhaps I should still take a look in DSSS/Rebuild to see how it reads 
the dependencies, but I don't think there's a way I can substitude 
Xcode build process with DSSS/Rebuild and get seemless integration.

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

Alexander Panek <a.panek brainsware.org> writes:

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?

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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)

Alexander Panek <a.panek brainsware.org> writes:

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.

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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.

"Janice Caron" <caron800 googlemail.com> writes:

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

What are 'file' lines?

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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"));
}
---

Michel Fortin <michel.fortin michelf.com> writes:

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/

Paolo Invernizzi <arathorn NO_SPAMfastwebnet.it> writes:

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.
 

Michel Fortin <michel.fortin michelf.com> writes:

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/