www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - RFC: Article on IDE Builder Theory

reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
Feb 21 2008
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
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
Feb 21 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 21 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
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.
Feb 21 2008
prev sibling next sibling parent reply Kenny B <funisher gmail.com> writes:
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.
Feb 22 2008
next sibling parent reply Jussi Jumppanen <jussij zeusedit.com> writes:
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
Feb 24 2008
parent reply Alexander Panek <alexander.panek brainsware.org> writes:
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? :)
Feb 25 2008
parent reply Kenny B <funisher gmail.com> writes:
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)
Feb 25 2008
parent reply torhu <no spam.invalid> writes:
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.
Feb 25 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:

 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.


&& works in XP.  I use it all the time.  Don't know about ||, but it's 
probably there too.

--bb
Feb 25 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
The idea of this builder is to obviate the need for all that manual 
stuff. Instead, it would be a fully-integrated way to click a button and 
  profile your project without needing a configuration.
Feb 25 2008
prev sibling next sibling parent reply Graham St Jack <graham.stjack internode.on.net> writes:
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.
Feb 25 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Graham St Jack wrote:

 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.]


Can you give me an example of the sorts of rules you'd like to see?
Feb 25 2008
parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 25 Feb 2008 11:22:59 -0800, Robert Fraser wrote:


 Graham St Jack wrote:

 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.]


 
 Can you give me an example of the sorts of rules you'd like to see?


The rules I use in my own build system are:

Directory naming conventions determine what files are documentation, 
library source, executables and tests.

A test depends on its successful result file, and tests are run whenever 
their results file is out of date. If a test fails, the build fails.

A source module cannot depend on itself by any chain of imports.

A package depends on (from memory - I could have the details a bit wrong):
* all the packages it contains,
* all the sources it contains, and
* all the packages that its sources import, up to the common ancestor.

A package cannot depend on itself by any chain of dependencies.


I find the dependency rules make it a lot easier to keep the source well-
factored, and results in a much cleaner design. It is far too hard to 
resist the temptation to sneak in a "bad" dependency between packages in 
the head of the moment - I like the build system to nip it in the bud.

The dependency rules also make it FAR easier to write reusable packages. 
Without rules like these (or a lot of willpower and only one developer), 
there is a strong tendency to end up with a monolith of tangled-together 
code.

The directory naming rules are just a way of eliminating a build 
configuration file - everything except compiler options can be worked out 
from where the files are and what they import.


These particular rules aren't for everyone, but especially on projects 
with multiple developers, automatic enforcement of rules of some kind can 
make things run a lot smoother. One thing that has stopped me from using 
Eclipse so far has been the difficulty of figuring out how to make it use 
a custom build system. It would be great if Descent had a build system 
that allowed rules to be added.
Feb 26 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
In Descent, this sort of thing isn't the builder's job (well it is, but 
the other builder - the Eclipse builder). There already is a 
partially-ported version of eclipse metrics which calculates things like 
dependencies and can help in resolving circular dependencies (if the 
circle is relatively small and all within the same package, I don't 
consider them bad -- but that's not the issue at hand :-)).

The sorts of rules you're talking about could easily be added as a 
plugin to Descent (well, not easily, but...) and seem to be more 
"Warnings on the project level" rather than anything to do with 
executable building.

Graham St Jack wrote:

 On Mon, 25 Feb 2008 11:22:59 -0800, Robert Fraser wrote:
 

 Graham St Jack wrote:

 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.]


 Can you give me an example of the sorts of rules you'd like to see?


 
 The rules I use in my own build system are:
 
 Directory naming conventions determine what files are documentation, 
 library source, executables and tests.
 
 A test depends on its successful result file, and tests are run whenever 
 their results file is out of date. If a test fails, the build fails.
 
 A source module cannot depend on itself by any chain of imports.
 
 A package depends on (from memory - I could have the details a bit wrong):
 * all the packages it contains,
 * all the sources it contains, and
 * all the packages that its sources import, up to the common ancestor.
 
 A package cannot depend on itself by any chain of dependencies.
 
 
 I find the dependency rules make it a lot easier to keep the source well-
 factored, and results in a much cleaner design. It is far too hard to 
 resist the temptation to sneak in a "bad" dependency between packages in 
 the head of the moment - I like the build system to nip it in the bud.
 
 The dependency rules also make it FAR easier to write reusable packages. 
 Without rules like these (or a lot of willpower and only one developer), 
 there is a strong tendency to end up with a monolith of tangled-together 
 code.
 
 The directory naming rules are just a way of eliminating a build 
 configuration file - everything except compiler options can be worked out 
 from where the files are and what they import.
 
 
 These particular rules aren't for everyone, but especially on projects 
 with multiple developers, automatic enforcement of rules of some kind can 
 make things run a lot smoother. One thing that has stopped me from using 
 Eclipse so far has been the difficulty of figuring out how to make it use 
 a custom build system. It would be great if Descent had a build system 
 that allowed rules to be added.
Feb 26 2008
parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Tue, 26 Feb 2008 16:37:15 -0800, Robert Fraser wrote:


 In Descent, this sort of thing isn't the builder's job (well it is, but
 the other builder - the Eclipse builder). There already is a
 partially-ported version of eclipse metrics which calculates things like
 dependencies and can help in resolving circular dependencies (if the
 circle is relatively small and all within the same package, I don't
 consider them bad -- but that's not the issue at hand :-)).


I'm happy with circularities in the same module, but not so happy in the 
same package - but as you say, that isn't the issue.


 
 The sorts of rules you're talking about could easily be added as a
 plugin to Descent (well, not easily, but...) and seem to be more
 "Warnings on the project level" rather than anything to do with
 executable building.


If there is a plugin mechanism that isn't too tough then I am happy.

My experience is that as soon as you make something optional, then people 
will turn it off and code away, leaving an intractable mess for someone 
who cares to clean up later. I had that experience with unit tests - most 
people didn't run them, so they got out of date and it became too hard to 
fix them later. The only time to fix them is as soon as they get broken. 
Its the same (or even worse) for dependency violations.
Feb 26 2008
prev sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
Robert Fraser wrote:

 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.


i don't understand why there should be a distinction between building 
during development and for deployment. after all you trying to develop 
the software that you eventually are deploying, not something else.


 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.


re-building modules only when dependencies have changed is on of the 
most basic features of a build tool, regardless of whether it's embedded 
into an IDE or not.


 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.


what is slow, is compiling a single module at a time. incremental 
compilation does not have to do this. you can determine the set of 
modules that need re-compilation and compile all of those with one call.


For your feature requirements, i fail to see how this is specific to an 
IDE build tool. After all, an IDE is supposed to be a frontend to all 
the tools required during development, including build tools. Once i 
defined how to build my program, i don't want to specify it twice. If it 
is so simple that a build tool can figure it out on it's own, i never 
want to do it - not for development, nor for deployment.

So what you're actually proposing is to introduce a secondary build tool 
that is positioned at an earlier stage in the workflow, manifested by 
some, yet to be defined features that make it more suitable for that 
stage. That implies that current build tools don't do a good enough job 
at some type of build. I'd rather like to see those shortcomings and the 
reasons why they cannot be addressed in the existing build tools first.


Besides that, here is what i personally find useful, that not all build 
tools have:

- Rebuild also if only the build-parameters changed
I frequently jump back and forth between debug and release mode. I don't 
want to clean explicitly each time. scons does that - it saves all the 
build parameters for each module and considers them when determining 
whether a module is dirty.

- Have all build parameters compactly editable in one place. All GUI 
based build tool interfaces i know only provide dialogs with all 
available parameters. With tools like scons or dsss OTOH, i have a 
single, small text file, that only specifies exactly what is relevant to 
my project. I don't have to click my way through endless tabs and 
dialogs to get to the settings that i want to change.

- I can parameterize my build arbitrarily (debug, release, with 
test-code for module group A, B or C, etc.). With selection of 
version-groups being just a single parameter to the build-call that i 
bind to some shortcut in the editor. It's merely a matter of one or two 
key/value entries in my project specific config files.
Feb 27 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Hi Jascha. You make a number of valid points, but you may not understand 
exactly where I'm coming from. In particular, I think you're thinking of 
what I'm describing as a build tool, while it's actually the removal of 
a build tool from the user's perspective, and instead a way to set up 
run configurations from which the build follows. See inline:

Jascha Wetzel wrote:

 Robert Fraser wrote:

 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.


 
 i don't understand why there should be a distinction between building 
 during development and for deployment. after all you trying to develop 
 the software that you eventually are deploying, not something else.
 

 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.


 
 re-building modules only when dependencies have changed is on of the 
 most basic features of a build tool, regardless of whether it's embedded 
 into an IDE or not.
 

 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.


 
 what is slow, is compiling a single module at a time. incremental 
 compilation does not have to do this. you can determine the set of 
 modules that need re-compilation and compile all of those with one call.


Can't this introduce spurious dependencies between the modules? Oh well, 
I'm relying on rebuild to do the dependency analysis/collection/compiler 
activation at this point, so I hope it takes care of that part.


 For your feature requirements, i fail to see how this is specific to an 
 IDE build tool. After all, an IDE is supposed to be a frontend to all 
 the tools required during development, including build tools. Once i 
 defined how to build my program, i don't want to specify it twice. If it 
 is so simple that a build tool can figure it out on it's own, i never 
 want to do it - not for development, nor for deployment.


But what is a "development build"? If it's a run/debug configuration, 
you probably want --release off, optimization and inlining off (since it 
can screw up debugging), debug symbols on, etc. If it's a profile 
configuration, you may or may not want optimization/inlining, but you 
definitely want instrumentation for profiling so it provides profile output.

Further, deployment builds are often a lot more than simple builds. 
Where I work, the incremental build includes not only the build itself, 
but functional unit tests, a number of scripts running against the 
database, a push to test environments, e-mail notification to all the 
developers/testers, etc., etc. This is what a build tool like Ant is 
for. An IDE is for a different purpose, and I'm sure you'll agree an IDE 
should not support all of that.


 So what you're actually proposing is to introduce a secondary build tool 
 that is positioned at an earlier stage in the workflow, manifested by 
 some, yet to be defined features that make it more suitable for that 
 stage. That implies that current build tools don't do a good enough job 
 at some type of build. I'd rather like to see those shortcomings and the 
 reasons why they cannot be addressed in the existing build tools first.


In a way (as I mentioned, I'm switching to rebuild to perform the actual 
compile/link). The features are defined as whatever features the 
relevant use case adds: features such as automated unit testing, 
automatic collection of profiling results and integration of these 
results into the editor, or debugger integration.


 Besides that, here is what i personally find useful, that not all build 
 tools have:
 
 - Rebuild also if only the build-parameters changed
 I frequently jump back and forth between debug and release mode. I don't 
 want to clean explicitly each time. scons does that - it saves all the 
 build parameters for each module and considers them when determining 
 whether a module is dirty.


My original build system had that. Right now I'm using rebuild as-is, 
but I may tweak it a bit as well as give it a socket-based interface (if 
Gregor is cool with that) so it'll be better for builds without cleans.


 - Have all build parameters compactly editable in one place. All GUI 
 based build tool interfaces i know only provide dialogs with all 
 available parameters. With tools like scons or dsss OTOH, i have a 
 single, small text file, that only specifies exactly what is relevant to 
 my project. I don't have to click my way through endless tabs and 
 dialogs to get to the settings that i want to change.


That's what the whole "use case" thing is about. For development builds, 
most of these parameters are determined by how you want to use it, so 
will be configurable as-needed in the use case configuration, or not at 
all (since if you click the "debug" button, you'll always want debug 
symbols, or if you click the "unit test" button you'll always want unit 
tests compiled in). The user will never need to think about the exact 
command-line options that are being passed to the tool, but instead how 
she plans to use the output, and the particular options will stem from 
these choices. I know this may make some users uncomfortable (if you're 
used to build tools as you describe them), which is why I'm planning to 
eventually add DSSS support.


 - I can parameterize my build arbitrarily (debug, release, with 
 test-code for module group A, B or C, etc.). With selection of 
 version-groups being just a single parameter to the build-call that i 
 bind to some shortcut in the editor. It's merely a matter of one or two 
 key/value entries in my project specific config files.


I'm not sure exactly what you mean by this.
- If you mean different build/run configurations for the same project, 
this is definitely supported, and I think your idea of adding key 
bindings is a good one (this may already be in Eclipse, if not, I'll add 
it).
- If you mean debug/version identifiers on a per-file basis, I didn't 
think as much about this... How important is this to people?
Feb 27 2008