When is it time to move from an in-IDE build system to a script-based build?

Question

When should a developer move from using the default build capability of their IDE to writing and using custom build scripts?

I realize this is subjective and I am interested in hearing all opinions; hence the community wiki.

Answer 1

Well it also depends on what IDE you're using, what language and to a limited extent what operating system(s).

For example, in Java it is common to use Ant or Maven scripts that can be used in both the IDEs and as separate build processes. In PHP however there is typically no build process so something like Git can be used to push changes to a deployment server (manually or automatically).

As for when, the more of these that are true the more likely you'll need it:

• You have several developers working on the project;
• You have released the project to production at least once;
• You have extensive unit tests (or need them);
• You are releasing nightly builds.

Basically an automated build process is required when you want or need a continuous integration process. It's useful to see automatically if someone has broken the build ("but it works on my PC!") or not, if nothing else.

Answer 2

It's simple, when the IDE build system does not meet your requirements anymore. For example when you need a continuous integration.

Answer 3

There is some irony in such a common situation: you want to move to a script-based build to automate building, but in so doing you usually lose one great automation feature of your IDE, i.e. automatic dependency tracking. That is for me the main reason to no more check each new script-based build tool that appears on the scene.

Probably I am not up-to-date and some new tool has finally this feature (I will be glad to know such tools), but I only know of a single one that do this for C source programs, Clump. An interesting quote from its home page:

... I have long realized that the information in a makefile is largely redundant anyway -- almost all the necessary information to create a makefile already exists right in the .c and .h files themselves. Any extra information needed can easily be specified in a separate little configuration file. ...

P.S.: no, Automake does not seems to have a level of automation comparable to IDEs and Clump.

Answer 4

I've used a few main build systems in the last few years

• Ant, with or without an IDE, for Java on Windows, Linux, OS X

  • as the IDE uses a script, it's a non-question

• Visual Studio for C++ on Windows

  • for CI, you can call the IDE executable to build and run in batch mode

• GNU make for C or C++ on Linux, Windows and Solaris ( and IIRC Java early on )

  • already a scripted build, usually used with a lighter weight text editor (SciTE)
  • you have to do dependencies yourself, but that encourages you to not create spaghetti systems

Earlier in my career, I used JBuilder and Symantec VisualCafe, Turbo C++, Turbo Pascal, each of which had their own build system. Their IDE specific build processes are now extinct. I'v been on a few long running projects which had to change their builds as IDEs were replaced; using an independent build script means you don't have to ( the exception is Visual Studio, which has always been pretty good at backwards compatibility ).

In the languages I use, modern IDEs which either give a scripted build option or a use a script based tool. I move C and Java between platforms, so tend to use portable build tools for those.

Answer 5

You should support both, from the beginning, because they fullfill different roles:

1. the script-based build is the master: it's the only one used to create the final release, ideally used on a build machine. Use it for continuous, deployment and nightly builds
2. the IDE-base build is left to the developers to maintain. If you use Eclipse, you should leverage WTP for web applications, for example.

The idea is that as soon as you check in some code, it is validated using the master build system: you give your developers the freedom to choose their tool but still enforcing a common build system.