Hello!
GNU make is able to resolve dependencies between files and to compile only the necessary ones; my question is: can i interrupt make with ctrl-c and restart it later?

I'll explain better with an example:
I download app-x.y.z.tar.gz, unzip and untar, run ./configure, run make. While make is still compiling, let's suppose i have to reboot my computer; so i press ctrl-c while it is compiling appunit.c, and make stops. Later, a run make again. It doesn't compile the files it has already compiled, and restarts from the point where id had been stopped. Could appunit.o (result of compilation of appunit.c) be damaged?

Hope i was clear..
Thanks to everyone!

It should be fine. "Should be" means I'd ^C with confidence, but keep an eye out for gremlins on the next make. Wouldn't expect to see any, though.

It really is not different from compiling, modifying a source file and compiling again. That being said, why not just ./configure; make; make install; again to be 100% safe?

The original poster's question had to do with interrupting the make. If you're interrupting the make, you don't have to do the ./configure again later, because that's already run to completion. So just the make should be sufficient. His question was whether it would be safe, and my answer was Yes.

The frosting on the cake is that he won't recompile the modules that have already been completely compiled, thus saving time.

I don't know if it would be safe to simply continue. What if an object file was only partially written. You might want to run "make clean" and start over.

Whether you want to make clean and start over depends on how much time you would save by just continuing.

Suppose you don't make clean, but just continue, and a .o file (compiled, unlinked object) was only partially written. In that case, you will have an invalid .o file, and the linking phase will catch it during the next make. Suppose, instead of some .o file, the linked executable was only partially written. In that case, you will catch it the first time you try to run the program. If you'd save a lot of time by not starting over, it would be just as good to rely on these other ways of catching the error.

Thanks guys for your advice. My fear is that the object/executable may be corrupt. I've got no idea whether what i'm going to say is correct: if i ctrl-c just while the compiler is writing the object file to disk, shouldn't the kernel wait for the completion of the i/o operation before closing the process?

However, i think i can risk getting a bad file if it's worth it, i.e. if it would be too long to restart from the beginning... I can always recompile..!

Ctrl-c is an interrupt signal, not a kill -9. I would guess that when make receives the interrupt signal, make would finish something like writing the object/executable to disk before halting.

make has no special knowledge of what pass a compiler is in, or whether it's in the middle of writing an object file and should be allowed to complete. But I still think the ^C thing isn't terribly dangerous, for the reasons I said before.

Of course it is, I interrupt make all the time. The compiler doesn't leave half written files lying around (unless perhaps you kill -9 it), any partial files will either be completed or deleted. Naturally, though, if you're using make for some other purpose (it isn't just for compiling programs), with a program that doesn't clean up after itself, YMMV, but as far as gcc is concerned, there is no problem.