4 ms·

> it relies on timestamps instead of content hashes Which means it can be faster. If you need to be able to write a file, but have the build system recognize

by LukeShu 10y ago

> it relies on timestamps instead of content hashes Which means it can be faster. If you need to be able to write a file, but have the build system recognize that the new one is the same as the old; this can be accomplished with a simple `sponge`-like script that only writes the file if the new version is different than the old. (I like to call the script write-ifchanged) > it doesn't rebuild things when e.g. compiler flags change, If you don't tell it to, no it doesn't. You can easily combine the above write-ifchanged with the technique described in the article to declare dependencies on variable values. > its approach to header dependencies in C/C++ is clumsy Sure, but not clumsier than other build systems. > it needs to parse the Makefile each time (which for large projects takes non-negligible time) Truth. > it doesn't have an integration with inotify (which means it needs to stat() every file to check its timestamp). Which means that it works with NFS, doesn't have race conditions involving renaming directories, ...

pg314 10y ago
>Which means it can be faster. If you need to be able to write a file, but have the build system recognize that the new one is the same as the old; this can be accomplished with a simple `sponge`-like script that only writes the file if the new version is different than the old. (I like to call the script write-ifchanged) > If you don't tell it to, no it doesn't. You can easily combine the above write-ifchanged with the technique described in the article to declare dependencies on variable values. You can make Make do a lot of things with enough hacking, but the defaults matter. The majority of projects that use make don't bother. Meaning you need a 'make clean; make' if you change compiler flags. > Which means that it works with NFS, doesn't have race conditions involving renaming directories, ... It has plenty of race conditions without that: if you change a header file in the middle of a make run, it will happily continue without warning. A lot of Make's design decisions make sense given its history. Given its ubiquity it's also the best choice for a lot of projects. That doesn't mean it's perfect.

by LukeShu 10y ago

pg314 10y ago

>Which means it can be faster. If you need to be able to write a file, but have the build system recognize that the new one is the same as the old; this can be accomplished with a simple `sponge`-like script that only writes the file if the new version is different than the old. (I like to call the script write-ifchanged) > If you don't tell it to, no it doesn't. You can easily combine the above write-ifchanged with the technique described in the article to declare dependencies on variable values. You can make Make do a lot of things with enough hacking, but the defaults matter. The majority of projects that use make don't bother. Meaning you need a 'make clean; make' if you change compiler flags. > Which means that it works with NFS, doesn't have race conditions involving renaming directories, ... It has plenty of race conditions without that: if you change a header file in the middle of a make run, it will happily continue without warning. A lot of Make's design decisions make sense given its history. Given its ubiquity it's also the best choice for a lot of projects. That doesn't mean it's perfect.