5 ms·
On one hand, make typically comes with built-in rules for .c targets. On the other hand, make can't cleanly handle #include dependency detection. I doubt that
by marshray 13y ago
On one hand, make typically comes with built-in rules for .c targets.
On the other hand, make can't cleanly handle #include dependency detection. I doubt that there is any major C project where "make extraclean" (or its equivalent) isn't occasionally necessary.
So yeah it's really not very well suited for C.
- nn3 13y agoWhat is wrong wrong with just using the following. Given it would be nice if make had a builtin macro to do this, but it is not too bad to type out. depend: .depend .depend: ${SRC} ${CC} -MM -I. ${SRC} > .depend.X && mv .depend.X .depend include .depend Makefile: .depend
- marshray 13y agoBecause now make can't build a clean source tree. I believe make parses the entire Makefile before running it.
- Karellen 13y agoWell, #include resolution would require that make be able to parse C, which would add a heck of a lot of complexity, and be unscalable. For instance, you'd need to modify make to parse CSS to teach it about @import, or to parse javascript to teach it about require() (but only if you're using RequireJS) Or, you could use the C preprocessor option "-M" and its variants[0] to get it to generate make rules with C #include resolution for you. See also Recursive Make Considered Harmful[1] for a good description on how to set up this in combination with GNU make's "include" facility to autogenerate your per-source #include resolution fragments. [0] http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html [1] http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf