View mode: basic / threaded / horizontal-split · Log in · Help
February 22, 2008
RFC: Article on IDE Builder Theory
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.
February 22, 2008
Re: RFC: Article on IDE Builder Theory
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
February 22, 2008
Re: RFC: Article on IDE Builder Theory
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
February 22, 2008
Re: RFC: Article on IDE Builder Theory
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.
February 23, 2008
Re: RFC: Article on IDE Builder Theory
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.
February 25, 2008
Re: RFC: Article on IDE Builder Theory
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
February 25, 2008
Re: RFC: Article on IDE Builder Theory
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? :)
February 25, 2008
Re: RFC: Article on IDE Builder Theory
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)
February 25, 2008
Re: RFC: Article on IDE Builder Theory
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.
February 25, 2008
[OT] windows command line (was: Re: RFC: Article on IDE Builder Theory)
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home