www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Build tools.

reply 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
Oct 10 2007
next sibling parent reply 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
Oct 10 2007
parent 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
Oct 11 2007
prev sibling next sibling parent 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.
Oct 10 2007
prev sibling next sibling parent "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.
Oct 11 2007
prev sibling next sibling parent =?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.
Oct 11 2007
prev sibling next sibling parent 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
Oct 11 2007
prev sibling next sibling parent reply 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/
Oct 12 2007
parent reply 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/
Oct 12 2007
parent reply 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?
Oct 13 2007
next sibling parent reply 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)
Oct 13 2007
parent reply 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.
Oct 13 2007
parent reply 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.
Oct 13 2007
parent 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")); } ---
Oct 13 2007
prev sibling parent reply 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/
Oct 13 2007
parent reply 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.

Oct 14 2007
parent 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/
Oct 14 2007
prev sibling next sibling parent 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>
Oct 12 2007
prev sibling parent "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?
Oct 13 2007