• Ary Borenszweig (40/40) Sep 01 2009 Hi all!
• Frank Benoit (8/12) Sep 01 2009 I think the build targets should also have a configuration of its own
• Jacob Carlborg (10/50) Sep 01 2009 This looks very nice. About the object files, every tool I've used (CDT,...
• Jacob Carlborg (6/46) Sep 01 2009 Another idea: if pragma(lib) could work like pragma(link) in dsss this
• Saaa (3/43) Sep 11 2009 Yes :)
• Bernard Helyer (2/3) Mar 24 2010 Couldn't you exclude some packages, like 'std' and 'tango'?

Ary Borenszweig <ary esperanto.org.ar> writes:

Hi all!

I started playing with an incremental builder for Descent. The idea is 
that you will never need to press a "compile" button anymore, just like 
the Java plugin for Eclipse works.

For this what I do is:
  - when a file is added or modified, compile it. Files that depend on 
this file are recompiled (recursively).
  - when a file is deleted, remove it's obj files and executables. 
Recompile files that depended on this one.

In both of these, new dependencies (and reverse dependencies) are 
recorded so I know what to recompile in case of a change/deletion.

If a file has a main method, an executable is generated automatically 
for it. This is all done in the "bin" folder (which will be 
configurable). This is done by executing, for example, dmd objfile1.obj 
objfile2.obj, etc. All this obj files exist there because they have been 
previously built.

Projects and include paths are automatically added to the compile command.

Here's a video that shows what it will look like (it works for me now 
but the compiler command and other things are hardcoded):

http://www.youtube.com/watch?v=RzvuKZG3jI0

Would something like this be useful? :)

I'm also thinking about creating build targets so you can quickly switch 
between them and compile them at once, without the need to change a lot 
of parameters, but that will come later.

My main difficulty now is how to treat include paths. When I include an 
include path it contains d files. It might not contain obj files. When I 
need to compile a file in a project that depends on some module on the 
include path, no problem, I add "-I..." and it works. But when I need to 
link everything to create the executable, I might not have the obj 
files. When and where should I compile these?

At first I thought: ok, if I don't have an obj file for some of these 
dependencies that are on include paths, I compile it to the bin folder 
just the first time (because later these include paths should not 
change, unless they are other projects but for these I have the obj 
files). But if the include path is phobos I don't want to compile these. 
How can I distinguish these cases? Also, when I include derelict it's 
something similar, I can't remember what command I used to compile a 
project when I included these. Maybe I miss the concept of library flags 
or something like that? I'm not very familiar with these things.

Well, any help about this is appreciated. Thanks!

Frank Benoit <keinfarbton googlemail.com> writes:

Ary Borenszweig schrieb:
 I'm also thinking about creating build targets so you can quickly switch
 between them and compile them at once, without the need to change a lot
 of parameters, but that will come later.
 

I think the build targets should also have a configuration of its own
set of version/debug identifiers, libs to link, own output directory for
 objects.

So if a file needs recompilation it may be recompiled for each build
target, and put into the target specific output folder.

The build targets shall be easy to deactivate to be either completely
passive, or just does compile but no link step.

Jacob Carlborg <doob me.com> writes:

On 9/1/09 20:24, Ary Borenszweig wrote:
 Hi all!

 I started playing with an incremental builder for Descent. The idea is
 that you will never need to press a "compile" button anymore, just like
 the Java plugin for Eclipse works.

 For this what I do is:
 - when a file is added or modified, compile it. Files that depend on
 this file are recompiled (recursively).
 - when a file is deleted, remove it's obj files and executables.
 Recompile files that depended on this one.

 In both of these, new dependencies (and reverse dependencies) are
 recorded so I know what to recompile in case of a change/deletion.

 If a file has a main method, an executable is generated automatically
 for it. This is all done in the "bin" folder (which will be
 configurable). This is done by executing, for example, dmd objfile1.obj
 objfile2.obj, etc. All this obj files exist there because they have been
 previously built.

 Projects and include paths are automatically added to the compile command.

 Here's a video that shows what it will look like (it works for me now
 but the compiler command and other things are hardcoded):

 http://www.youtube.com/watch?v=RzvuKZG3jI0

 Would something like this be useful? :)

 I'm also thinking about creating build targets so you can quickly switch
 between them and compile them at once, without the need to change a lot
 of parameters, but that will come later.

 My main difficulty now is how to treat include paths. When I include an
 include path it contains d files. It might not contain obj files. When I
 need to compile a file in a project that depends on some module on the
 include path, no problem, I add "-I..." and it works. But when I need to
 link everything to create the executable, I might not have the obj
 files. When and where should I compile these?

 At first I thought: ok, if I don't have an obj file for some of these
 dependencies that are on include paths, I compile it to the bin folder
 just the first time (because later these include paths should not
 change, unless they are other projects but for these I have the obj
 files). But if the include path is phobos I don't want to compile these.
 How can I distinguish these cases? Also, when I include derelict it's
 something similar, I can't remember what command I used to compile a
 project when I included these. Maybe I miss the concept of library flags
 or something like that? I'm not very familiar with these things.

 Well, any help about this is appreciated. Thanks!

This looks very nice. About the object files, every tool I've used (CDT, 
XCode, JDT) you have to explicitly say that this project needs these 
object files to link, if it isn't in the standard library. You can also 
look in standard paths for the object files.

I don't know if it is possible to do but a nice thing about XCode is 
that when you have to link to a special library you just drag the 
library file and drop it on the project and it knows what to do with the 
file, how to link it.

/Jacob Carlborg

Jacob Carlborg <doob me.com> writes:

On 9/1/09 20:24, Ary Borenszweig wrote:
 Hi all!

 I started playing with an incremental builder for Descent. The idea is
 that you will never need to press a "compile" button anymore, just like
 the Java plugin for Eclipse works.

 For this what I do is:
 - when a file is added or modified, compile it. Files that depend on
 this file are recompiled (recursively).
 - when a file is deleted, remove it's obj files and executables.
 Recompile files that depended on this one.

 In both of these, new dependencies (and reverse dependencies) are
 recorded so I know what to recompile in case of a change/deletion.

 If a file has a main method, an executable is generated automatically
 for it. This is all done in the "bin" folder (which will be
 configurable). This is done by executing, for example, dmd objfile1.obj
 objfile2.obj, etc. All this obj files exist there because they have been
 previously built.

 Projects and include paths are automatically added to the compile command.

 Here's a video that shows what it will look like (it works for me now
 but the compiler command and other things are hardcoded):

 http://www.youtube.com/watch?v=RzvuKZG3jI0

 Would something like this be useful? :)

 I'm also thinking about creating build targets so you can quickly switch
 between them and compile them at once, without the need to change a lot
 of parameters, but that will come later.

 My main difficulty now is how to treat include paths. When I include an
 include path it contains d files. It might not contain obj files. When I
 need to compile a file in a project that depends on some module on the
 include path, no problem, I add "-I..." and it works. But when I need to
 link everything to create the executable, I might not have the obj
 files. When and where should I compile these?

 At first I thought: ok, if I don't have an obj file for some of these
 dependencies that are on include paths, I compile it to the bin folder
 just the first time (because later these include paths should not
 change, unless they are other projects but for these I have the obj
 files). But if the include path is phobos I don't want to compile these.
 How can I distinguish these cases? Also, when I include derelict it's
 something similar, I can't remember what command I used to compile a
 project when I included these. Maybe I miss the concept of library flags
 or something like that? I'm not very familiar with these things.

 Well, any help about this is appreciated. Thanks!

Another idea: if pragma(lib) could work like pragma(link) in dsss this 
wouldn't be a problem, every file knows what it needs to link to. Vote 
for these two issues:
http://d.puremagic.com/issues/show_bug.cgi?id=2776 
http://d.puremagic.com/issues/show_bug.cgi?id=2968

"Saaa" <empty needmail.com> writes:

 Hi all!

 I started playing with an incremental builder for Descent. The idea is 
 that you will never need to press a "compile" button anymore, just like 
 the Java plugin for Eclipse works.

There is a compile button ?! :)

 For this what I do is:
  - when a file is added or modified, compile it. Files that depend on this 
 file are recompiled (recursively).
  - when a file is deleted, remove it's obj files and executables. 
 Recompile files that depended on this one.

 In both of these, new dependencies (and reverse dependencies) are recorded 
 so I know what to recompile in case of a change/deletion.

 If a file has a main method, an executable is generated automatically for 
 it. This is all done in the "bin" folder (which will be configurable). 
 This is done by executing, for example, dmd objfile1.obj objfile2.obj, 
 etc. All this obj files exist there because they have been previously 
 built.

 Projects and include paths are automatically added to the compile command.

 Here's a video that shows what it will look like (it works for me now but 
 the compiler command and other things are hardcoded):

 http://www.youtube.com/watch?v=RzvuKZG3jI0

 Would something like this be useful? :)

Yes :)
So, no need for a seperate building tool anymore?

 I'm also thinking about creating build targets so you can quickly switch 
 between them and compile them at once, without the need to change a lot of 
 parameters, but that will come later.

 My main difficulty now is how to treat include paths. When I include an 
 include path it contains d files. It might not contain obj files. When I 
 need to compile a file in a project that depends on some module on the 
 include path, no problem, I add "-I..." and it works. But when I need to 
 link everything to create the executable, I might not have the obj files. 
 When and where should I compile these?

 At first I thought: ok, if I don't have an obj file for some of these 
 dependencies that are on include paths, I compile it to the bin folder 
 just the first time (because later these include paths should not change, 
 unless they are other projects but for these I have the obj files). But if 
 the include path is phobos I don't want to compile these. How can I 
 distinguish these cases? Also, when I include derelict it's something 
 similar, I can't remember what command I used to compile a project when I 
 included these. Maybe I miss the concept of library flags or something 
 like that? I'm not very familiar with these things.

 Well, any help about this is appreciated. Thanks! 

Bernard Helyer <b.helyer gmail.com> writes:

Oh wow. This looks awesome! I want this in my hands, like yesterday. =P


But if the include path is phobos I don't want to compile these.

Couldn't you exclude some packages, like 'std' and 'tango'?