I am working on a project that has around a hundred different files (.cpp & .h), and it requires around an hour to build the entire project on MSVC 2008, suppose that I now make a change to any one file, do I need to build the entire project once again, right from the beginning, or is there a way out ?

I know it is very very noob like, but I am wasting a lot of time, hence I was wondering

  • 1
    An hour for a clean build? Or just building the changed files? I would have thought the compiler would be intelligent to know which files are affected by the change and only compile those... – FrustratedWithFormsDesigner Jun 18 '12 at 17:49
  • An hour for a clean build (don't I have to make a clean build if I change a file ?) – potato man Jun 18 '12 at 17:50
  • 1
    Did you try changing a file and building? MSVC will build what's needed, no more. – Erik Jun 18 '12 at 17:50
  • 3
    @Aaditya: an hour for 100 cpp files seems to be way too much on actual hardware, even for a clean build (at least if you don't include some very large libs, and your source files don't contain >20k LOC each). Does your Makefile or build script use precompiled headers? If not, try to utilize them. – Doc Brown Jun 18 '12 at 18:02
  • 1
    @Aaditya: You can post an answer to your own question (and mark it as the answer), if you think it will be useful to others in the future. – FrustratedWithFormsDesigner Jun 18 '12 at 18:02

The short answer: It depends.

The long answer: It depends on your source code dependencies.

For example, if every class knows about every other class in the project, then every time you make a change to one, you probably have to recompile the other.

It also depends on linkage. If you link everything into one binary file, it's also likely to compile everything again. A better way would be to separate to different shared libraries (DLLs), or at the very least into separate object (.o) files.

But then (in the latter case) you might need to tinker with it to see that it doesn't recompile all object files when you just need to recompile one and link them all together again.

But then again, maybe the linking process takes a while too. You basically need to experiment with that.

On a final note... An hour for building ~100 files? That's way, way too much, unless you're running on a really old machine. Or unless each file contains tens of thousands of lines.


There are two kinds of builds: clean builds and incremental.

A clean build always starts from scratch: it takes nothing but the bare project as input, figures out dependencies, and builds all the parts in order, then assembles them into the final output. A clean build, by definition, has to recompile all the source files in your project; while doing this, it produces intermediate files, such as .obj files, which are neither source nor shippable binaries - once the build is complete, you could throw them away (which is what Build>Clean Solution is supposed to do), or you can leave them in place for later, which brings us to...

Incremental builds. An incremental build compares every source file's last-modified date to the timestamp on the intermediate files it produces, as well as anything else that depends on it ('targets'); if any dependency has been modified after the target was last built, the target is rebuilt, otherwise the file from the previous build is reused. For example, if you have users.c, which gets compiled into users.obj (a build target) and includes users.h and basics.h (dependencies), then the incremental build would check the timestamps on all these files, and if any of them is newer than the one on users.obj, then users.obj gets rebuilt; otherwise, the existing users.obj is considered valid, and this particular build step can be skipped.

Because incremental builds only rebuild what needs to be, they are typically much faster than clean builds - for large but well-structured projects, the difference can be one of mere seconds vs. lunch break.

However, correctly determining dependencies borders on black magic, and some overall settings invalidate all intermediates (e.g. if you switch target architecture), so if you want "the real thing", most people will recommend doing a complete clean build. In fact, pretty much all Continuous Integration setups (where a build server executes a complete build each time new code gets pushed to the master repository, fully automated) use clean builds, simply because they are the only reliable way of making sure everything is really really up-to-date.


This is really the point of make. Only rebuild what you need to rebuild, nothing more. As such, your makefile should be set up so that the built components do not get in your way while you work, such as dumping them into a build directory. It should also have proper dependencies set up, so that any relevent sections of the project will recompile if you change their dependencies.

I suggest going through the makefile you have for your project, and learning what all the different pieces do. It's another important and useful tool. The manual isn't very long, and goes over everything. Or, you can read Managing Projects with Gnu Make, which goes over how make is more than just a software compiler.

  • I don't think this answer deserves a downvote, so I'm upvoting it. – K.Steff Jun 18 '12 at 23:20
  • 1
    Visual Studio doesn't use make. – MSalters Nov 15 '13 at 12:33

A 'make clean' should only be neccessary once if you just started working on an already existing project, e.g. it was just downloaded and unpacked, or if you want to be sure that everything is up to date, e.g. for a release. If just a few files were modified, a simple 'make' should suffice. It is then up to the 'make' utility to find and compile just the modified files, and link the results together with the already compiled files to create the finished binary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.