14

I am writing a multiple-filed program right now, and apparently running only 'make' (as one would intuitively think needs to be done in most situations) for some reason causes my program to fail. I guess I can provide more detail of the problem, but the important thing is that it does run when using 'make clean'. So I was wondering if anyone knew the general rule of thumb for running 'make clean' instead of just 'make'

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Dark Templar
  • 6,223
  • 16
  • 46
  • 46

4 Answers4

17

You run make clean in two situations - when you want to package up the source code (and therefore don't need/want the built objects) OR when you have some reason to believe that the built objects are bad.

In your case, you're using 'make clean' to fix a problem that is likely the result of a buggy Makefile. Something in there is not re-compiling when it should, and that's causing the output binary to be bad.

There are many reasons that could happen, depending on the complexity of your project, and how you've used make, but the gist of it is: you need to spend some time debugging your Makefile.

Michael Kohne
  • 10,038
  • 1
  • 36
  • 45
  • 6
    You forget "some change in the build environment" like upgraded compiler, new versions of libraries etc. always a good idea to "make clean" in these cases just to make sure all the modules are singing from the same song sheet! – James Anderson Sep 23 '11 at 01:42
  • 2
    @JamesAnderson One could argue these are simply instances of buggy Makefiles. – Kristof Provost Sep 23 '11 at 10:41
  • 4
    @KristofProvost: I am not sure I'd class "New ABI" (possibly by introduction of a new compiler version) as 'buggy Makefile'. It's sufficiently outside the scope of what I'd expect 'make' to look at. – Vatine Sep 23 '11 at 10:48
  • 1
    True, but it is possible (and not even all that difficult) to add the compiler to the makefiles as a prerequisite. That's sufficient to catch the problem. All in all it's not a huge issue and it's very rare anyway. I made the point because I've used (and written) makefiles which take compiler flags and such into account. That's also fairly uncommon in makefiles, but very useful (more so than checking the compiler ;)). My expectations of good, well-written makefiles are fairly high. My expectations of the *average* makefile are rather lower... – Kristof Provost Sep 23 '11 at 12:30
8

I agree with Michael Kohne's answer in general. I would add you need to read the installation docs to know what "make clean" actually does. There can be different levels of clean that you might need to use, such as "make realclean" and "make distclean." There are informal conventions for these, but nothing carved in stone.

Bill Ruppert
  • 181
  • 1
  • 5
  • 2
    +1: "you need to read the installation docs to know what "make clean" actually does". There's no "general rule". You have to actually read the docs. – S.Lott Sep 23 '11 at 03:34
6

I understand that this is your project, so it's your makefile. My goal is to have make always produce a correct build, if it is possible to produce one. If make clean is necessary to recover from some condition, then in my opinion the makefile is wrong, and should be corrected. If your dependencies have been calculated correctly, then a simple make should recompile everything that needs to be recompiled.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 2
    I agree. It's no longer an issue in these days of nearly infinite disk space, but I'm old enough to remember when make clean and make realclean were used mainly to save disk space after the linked executable was created. Making GCC, apache, perl, etc left a lot of stuff laying around. – Bill Ruppert Sep 25 '11 at 15:34
1

I would run "make clean" before a nightly build. In that case the additional time it takes to do a full build probably won't matter much, but the additional safety you will get from making sure everything is in the right version is probably worth it.

Zachary K
  • 10,433
  • 2
  • 37
  • 55
  • That will depend on the size of your project. Where I use to work an incremental build would take 2-4 hours with the changes from other sites pulled in overnight. A clean build could take 7 to 9 hours. On top of that we sometimes had 2 or 3 branches we would want to build. Even on fast machines, very large code bases need treated quite differently to smaller ones. – TafT Jun 11 '15 at 10:04