3 ms·

Ask HN: Is it rational to compile from scratch sometimes when you don't need to?

1 points by amichail 5y ago

While developing, do you trust your IDE's incremental compiles enough to never compile from scratch unnecessarily?

PaulHoule 5y ago
I think sudo apt-get install X is faster, stronger, easier than ./configure make sudo make install but that is not true for any other software installation mechanism either CLI or GUI. (e.g. I could go drive to a town an hour away, watch a feature film and come back in the time anything Docker spends downloading irrelevant cruft if I really believed that it was going to make progress the whole time and not get stuck.) Intel is very slow to roll out new features such as SIMD instructions so most Linux distributions are targeted to machines that are a decade old. If you compile from scratch you can often get a big gain on the latest hardware.
AnimalMuppet 5y ago
I do not trust my IDE's incremental compiles very much. But I have a small-ish code base, so the cost of my distrust is small.
h2odragon 5y ago
Yes, a clean compile can kick loose bugs that might've been hiding; cure bitrot, and workout parts of the build system that you might not otherwise notice have broken. Watching all your error messages scroll by is a useful prod for discipline and code cleanliness. (No error messages? what kind of whips and chains hacker are you?) "Irrational" is the third (and subsequent) times you do `make clean && make all` in vain hope that the bug will just go away, without making other changes.
simonblack 5y ago
Nine times out of ten my Makefile has the sequence app: clean all install ..... ..... ..... That covers most (all?) eventualities. If the compile can go from a clean set of source files to a fully installed application, I know that it is complete. During the depths of development I might not include the 'make install' while I'm still getting source-file errors. The reason for my 'belt and braces' use of 'make clean' is that on odd occasions my Makefiles haven't been as bullet-proof as they should have been and previously compiled object-files being linked in have caused compile errors which didn't actually exist.

1 points by amichail 5y ago

While developing, do you trust your IDE's incremental compiles enough to never compile from scratch unnecessarily?

I think sudo apt-get install X is faster, stronger, easier than ./configure make sudo make install but that is not true for any other software installation mechanism either CLI or GUI. (e.g. I could go drive to a town an hour away, watch a feature film and come back in the time anything Docker spends downloading irrelevant cruft if I really believed that it was going to make progress the whole time and not get stuck.) Intel is very slow to roll out new features such as SIMD instructions so most Linux distributions are targeted to machines that are a decade old. If you compile from scratch you can often get a big gain on the latest hardware.

AnimalMuppet 5y ago

I do not trust my IDE's incremental compiles very much. But I have a small-ish code base, so the cost of my distrust is small.

h2odragon 5y ago

Yes, a clean compile can kick loose bugs that might've been hiding; cure bitrot, and workout parts of the build system that you might not otherwise notice have broken. Watching all your error messages scroll by is a useful prod for discipline and code cleanliness. (No error messages? what kind of whips and chains hacker are you?) "Irrational" is the third (and subsequent) times you do `make clean && make all` in vain hope that the bug will just go away, without making other changes.

simonblack 5y ago

Nine times out of ten my Makefile has the sequence app: clean all install ..... ..... ..... That covers most (all?) eventualities. If the compile can go from a clean set of source files to a fully installed application, I know that it is complete. During the depths of development I might not include the 'make install' while I'm still getting source-file errors. The reason for my 'belt and braces' use of 'make clean' is that on odd occasions my Makefiles haven't been as bullet-proof as they should have been and previously compiled object-files being linked in have caused compile errors which didn't actually exist.