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!

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.

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

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

> 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!

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'?