View mode: basic / threaded / horizontal-split · Log in · Help
September 01, 2009
Writing an incremental builder for Descent
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!
September 01, 2009
Re: Writing an incremental builder for Descent
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.
September 01, 2009
Re: Writing an incremental builder for Descent
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
September 01, 2009
Re: Writing an incremental builder for Descent
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
September 11, 2009
Re: Writing an incremental builder for Descent
> 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!
March 24, 2010
Re: Writing an incremental builder for Descent
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'?
Top | Discussion index | About this forum | D home