This is all well and good, but even with smart compilation turned on, things don't work quite as well as they should. I'm designing my own CPU core, so I'm not using NIOS, but I still need to be able to update BRAM's with new program code.
I've already worked around (sort of) the fact that for some reason, Quartus won't properly update a BRAM from a .hex file. (.hex files work fine for compilation, but not a mif/hex update. So, I bring my .hex file into Quartus, and save it as a .mif file. This is annoying, since I can no longer automate the whole build process. At some point, when I get irritated enough, I'll write a program that converts hex to mif correctly, but I haven't had the time for much extra programming lately.
However, the MORE irritating problem I've run into is that if I repeat the mif/hex update process a second time, changing only the .mif file, Quartus launches into a full recompile anyway. This is a bit frustrating, since the "hardware" is stable at this point. I just need to test software. Perhaps I've missed something, but I've yet to find a way to avoid the full recompile on the second update.
Maybe this works correctly in the NIOS flow, but I don't have that tool available. I did try the NIOS eval, though, and I didn't see any new tools in it that looked like they would solve my problem.