Hi all,

I've been working on Descent's builder and before I go too far into it, I wanted to know what everyone thought about the design philosophy I've chosen for it, and if people would prefer a more traditional builder, I am willing go that route, too. This will mostly be a long & philosophical post that may eventually become an article of some sort.

Basically, the assumption underpinning Descent's builder is that an IDE _isn't_ a build tool. For final/release builds, installation (end user builds), or even daily pushes, there are a number of very good tools out there (DSSS, Ant, etc.) that are more focused, capable, scriptable, and automatable than an IDE should ever be. Instead, an IDE is a _development_ environment, so builds performed within the scope of the IDE should work to support development and testing, not deployment. In particular, building within the scope of an IDE should have the following properties:

- It should be fast. Builds, generally with only small changes, are very frequent in a development or ad-hoc testing environment, and thus should run as quickly as possible. Rebuilding the project with all its dependencies for a one-line change is not an option.

- It should require as little configuration as possible. Simple builds should not require complex scripts or configuration of compiler options. Instead, the configurations should be chosen for building depending on the use case (more on this below).

- It should support test-driven development. D's built-in unit test construct allows developers to write unit tests very easily directly into their code, however D's typical method of running these stops program execution as soon as one fails and forces the user to run every test linked in. Test-driven development expects failures, so any builder should integrate an easy way to run unit tests one-by-one, support test automation for running subsets of the application's tests, and robust/complete stack tracing for failures. It should still be easy to run every test in the project, however.

Based on these principles, I came to question the build-then-run workflow of typical IDEs. Descent will work differently. There _is_ no build command. Instead, a user creates a run configuration for a specific use case and the compiler will be invoked when the user clicks run to support the run configuration (don't worry, if it's already been built for that run configuration, it won't be re-built. Only the first build will be slow, after that incremental compilation will kick in.)

The use cases will decide the options to use when compiling. For example, a simple run or debug session will generally build everything with debug symbols on. If you're running with unit tests, unit tests will be built, and a separate module will be linked in to support running specific tests and handling test failures (flute, which I will also release separately for command-line use). A profiling use case would allow the user to choose whether to optimize the code and inline functions  and would instrument for profiling. Another use-case would be code coverage analysis, which would build everything instrumented for this and optionally use the unit tests to determine coverage.

Besides zero-configuration & transparency to the user, the other advantage of this approach is IDE support that extends into run time. This means, for example, that you just need to click "run unit tests" and an interactive unit testing UI will pop up. Choose "profile," set a few options, and the IDE could interpret the results and show some cute colored bars over lines of code/process the results without the user needing to care about result files, etc.

There are two big disadvantages and one smaller one to this approach. First, it precludes using the IDE builder for "final builds." The future may hold integration with a different build system, but for now this isn't a priority, since a complete build/install is rarely needed during development. This means, for example, that you'll never actually see the executable generated unless you go digging through the bin folder, and there might be three different ones with weird names sitting there.

The other limitation of this approach is that it only works well for the use cases defined. Adding a new use case would take some significant effort, and probably include creating a new plugin that contributes to specific Descent & Eclipse extension points (read: a lot of complex Java code). However, the four use cases I mentioned (run/debug, unit test, profile, and code coverage) should cover most user needs for both application and library development (please tell me if I'm missing a broad category here). There will be an API for defining new use cases, but it'll still probably take 1500+ lines of code to define the build configuration, launch configuration, and UI for the new use case.

The last disadvantage is merely a cosmetic one: the entire build process is transparent to the user. While many users will like this, the lack of a more traditional and configurable build-then-launch process may alienate some users at first, who would prefer a greater level of control.

A word needs to be said on incremental compilation. Recently, there have been a number of posts related to incremental compilation being much slower, including some rather disturbing figures for DWT ;-P. Until this gets fixed, I will have an option to allow "all at once" compilation for projects. This may be faster at first for pathological cases such as DWT, but after a few hundred builds, the incremental process will likely be faster for most projects.

As I said, I'm not too far into Descent's builder to change it (although that may make unit test runs more complex) and traditional building may eventually be supported, likely by DSSS integration, but this would be an entirely separate feature. I was just wondering what people thought of this approach.

I am convinced this will provide a better workflow for most users, and make Descent an excellent IDE for both application and library developers alike.

On Thu, 21 Feb 2008 16:09:32 -0800, Robert Fraser wrote:

> I've been working on Descent's builder and before I go too far into it, I wanted to know what everyone thought about the design philosophy I've chosen for it, ...

Sounds like a good approach, one that would suit my style of development. I might even start using Descent on a regular basis ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/02/2008 1:11:05 PM

Robert Fraser wrote:
> Hi all,
> 
> Based on these principles, I came to question the build-then-run workflow of typical IDEs. Descent will work differently. There _is_ no build command. Instead, a user creates a run configuration for a specific use case and the compiler will be invoked when the user clicks run to support the run configuration (don't worry, if it's already been built for that run configuration, it won't be re-built. Only the first build will be slow, after that incremental compilation will kick in.)

The problem I'd have with that is that with and explicit "build now" button I know approximately what version of my code the current exe is built from.  Scenario that's happened to me many times:
- I have a working exe, I start hacking on something, and then start wondering 'how did the previous version handle case X before I started hacking?'  If the exe doesn't exist because the current code won't compile, or if it exists but is a newer version than the one I last ran, then I won't be happy.

You could perhaps handle this scenario by having a check-point button. Or doing automatic checkpointing of successfully built exes.

> This means, for example, that you'll never actually see the executable generated unless you go digging through the bin folder, and there might be three different ones with weird names sitting there.

That's problematic if the successful running of the exe depends on external dlls or resource files being in the same directory at run-time.  In Visual Studio you can use a custom post-build step to copy the exe to a particular location, or you can edit the output file path to say where the exe should go.

--bb

Bill Baxter wrote:
> Robert Fraser wrote:
>> Hi all,
>>
>> Based on these principles, I came to question the build-then-run workflow of typical IDEs. Descent will work differently. There _is_ no build command. Instead, a user creates a run configuration for a specific use case and the compiler will be invoked when the user clicks run to support the run configuration (don't worry, if it's already been built for that run configuration, it won't be re-built. Only the first build will be slow, after that incremental compilation will kick in.)
> 
> The problem I'd have with that is that with and explicit "build now" button I know approximately what version of my code the current exe is built from.  Scenario that's happened to me many times:
> - I have a working exe, I start hacking on something, and then start wondering 'how did the previous version handle case X before I started hacking?'  If the exe doesn't exist because the current code won't compile, or if it exists but is a newer version than the one I last ran, then I won't be happy.
> 
> You could perhaps handle this scenario by having a check-point button. Or doing automatic checkpointing of successfully built exes.
> 
>> This means, for example, that you'll never actually see the executable generated unless you go digging through the bin folder, and there might be three different ones with weird names sitting there.
> 
> That's problematic if the successful running of the exe depends on external dlls or resource files being in the same directory at run-time.  In Visual Studio you can use a custom post-build step to copy the exe to a particular location, or you can edit the output file path to say where the exe should go.
> 
> --bb

Thanks! Those are the sort of things I wouldn't think of, and both those sound like good solutions.

Robert Fraser wrote:
> Hi all,
> 
> I've been working on Descent's builder and before I go too far into it, I wanted to know what everyone thought about the design philosophy I've chosen for it, and if people would prefer a more traditional builder, I am willing go that route, too. This will mostly be a long & philosophical post that may eventually become an article of some sort.

From time to time I use Descent -- because autocomplete doesn't work (I already showed Ary). Personally, I have never used automatic build. A Makefile is very easy to write and usually takes me only a little bit of time. I notice there is support for make... My workflow looks like this:

[code a little]
[alt-tab]
make -j2 && ./program
[compiler spits out errors]
[alt-tab]
((repeat))

It'd be awesome if that output could be parsed into descent as source / line errors I can click on.

Next, I have a lot of possibilities to my makefile...

make -j2 (most common)
make -j2 DATATEST=true (next most common)
make -j2 PROFILE=true
make -j2 DATATEST=true PROFILE=true
make -j2 release
make -j2 release PROFILE=true

So, it'd be nice if I could customize which commands to various shortcuts or add buttons for other options


The next thing that happens after this is spit out, is I usually run a post execution command, such as:

gprof program gmon.out > profile_data && scite profile_data
gdb program
etc..

So, it'd be nice if I could automatically run something after a specific build. It'd also be super awesome if I could apply a wildcard here too, so I could over time automatically save the profile outputs, or the datatesting integrity or whatever files my program is spitting out.

Anyway, Descent really rocks, and I hope I helped a bit.

Kenny B Wrote:

> My workflow looks like this:
> 
>  [code a little]
>  [alt-tab]
>  make -j2 && ./program
>  [compiler spits out errors]
>  [alt-tab]
>  ((repeat))

Since you mentioned alt-tab I assume you are running Windows but I could be wrong ;)

> It'd be awesome if that output could be parsed into descent as source line errors I can click on.

FWIW there should be many Windows editors that already allowed you to do exact this, by letting you define an executable as a tool and have the editor capture it's output.

JussiJ

Jussi Jumppanen wrote:
> Kenny B Wrote:
> 
>> My workflow looks like this:
>>
>>  [code a little]
>>  [alt-tab]
>>  make -j2 && ./program
>>  [compiler spits out errors]
>>  [alt-tab]
>>  ((repeat))
> 
> Since you mentioned alt-tab I assume you are running Windows but I could be wrong ;)

Since when does alt-tab require Windows? :)

Alexander Panek wrote:
> Jussi Jumppanen wrote:
>> Kenny B Wrote:
>>
>>> My workflow looks like this:
>>>
>>>  [code a little]
>>>  [alt-tab]
>>>  make -j2 && ./program
>>>  [compiler spits out errors]
>>>  [alt-tab]
>>>  ((repeat))
>>
>> Since you mentioned alt-tab I assume you are running Windows but I could be wrong ;)
> 
> Since when does alt-tab require Windows? :)

I definitely use linux :) I also use Ctrl+alt+[left or right] arrow
for switching between desktops... windows definitely can't do that.

if you look later in my message... I have:

> gprof program gmon.out > profile_data && scite profile_data

I haven't used windows in a while, but when I used it, it didn't have output redirection :D

Also, my message header contains the header:

User-Agent: Thunderbird 2.0.0.9 (X11/20080216)

Sounds like a really good approach. I like the focus on development work, leaving deployment to more fully-featured build systems.

I particularly like built-in support for test-driven development.

One other thing I like in a build system is to enforce design rules. The particular rules I use aren't important (dependency management) - the point is that a build system can help add a bit more rigour to a project, especially one with multiple developers. These rules would probably have to be described via some sort of extension mechanism, because there will never be agreement on what the rules should be.

Kenny B wrote:
> if you look later in my message... I have:
> 
>  > gprof program gmon.out > profile_data && scite profile_data
> 
> I haven't used windows in a while, but when I used it, it didn't have output redirection :D

I don't think there's ever been a windows version without output/input redirection and pipes.  That goes back to very old versions of DOS.

But I seem to recall that win98 didn't allow you to redirect stderr. Things like 2>&1 works in winxp, when using cmd.exe.

&& and || doesn't work as far as i know.