4 ms·

My point was referring to the JS toolchain here mostly. I get that for C, make is the tool for the job.

mturmon 13y ago
make is a general-purpose tool for describing dependencies for regenerating files. It would be worth your while to learn make, and try it on your example. Understand that it's a declarative language ("A depends on B"; when "B" changes, here's how to update "A"), and not a scripting tool. This is a good thing. In my experience, make is coupled to Unix. Make is not coupled to C.
- 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 ago
    What 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 ago
      Because now make can't build a clean source tree. I believe make parses the entire Makefile before running it.
      - nn3 13y ago
        GNU make restarts when a Makefile: dependency changes. So it works perfectly fine. Try it ...
        marshray 13y ago
        What happens if you list depend as a dependency of the first target?
  - Karellen 13y ago
    Well, #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
- Silhouette 13y ago
  In my experience, make is coupled to Unix. Make is not coupled to C. However, implementations typically include magic that is heavily biased toward building C and C++ code. As someone who works on a lot of projects, some using those languages and some not, I tend to think it's rather too magical at times. Personally, I'd prefer to have that kind of magic explicitly stated in some standard file that comes with the tool, so that file can be included with a one-liner for those projects that want it but there is nothing implicit going on by default.
  - mturmon 13y ago
    I think "magic" is much too loaded a way to characterize it. The rule applicable to C pertains to building foo.o from foo.c. It amounts to two lines in a Makefile: %.o: %.c $(COMPILE.c) $(OUTPUT_OPTION) $< where COMPILE.c and the other variable is predefined to trivial values. There are other rules useful for C++, and for yacc, etc., but they are just as simple. You can cancel all the implicit rules with "-r", or cancel selected implicit rules by naming them in the Makefile like this: %.o : %.c ; All this is in the make manual, which is quite good: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html https://www.gnu.org/software/make/manual/html_node/Catalogue...

make is a general-purpose tool for describing dependencies for regenerating files. It would be worth your while to learn make, and try it on your example. Understand that it's a declarative language ("A depends on B"; when "B" changes, here's how to update "A"), and not a scripting tool. This is a good thing. In my experience, make is coupled to Unix. Make is not coupled to C.

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 ago
  What 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 ago
    Because now make can't build a clean source tree. I believe make parses the entire Makefile before running it.
    - nn3 13y ago
      GNU make restarts when a Makefile: dependency changes. So it works perfectly fine. Try it ...
      - marshray 13y ago
        What happens if you list depend as a dependency of the first target?
- Karellen 13y ago
  Well, #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
Silhouette 13y ago
In my experience, make is coupled to Unix. Make is not coupled to C. However, implementations typically include magic that is heavily biased toward building C and C++ code. As someone who works on a lot of projects, some using those languages and some not, I tend to think it's rather too magical at times. Personally, I'd prefer to have that kind of magic explicitly stated in some standard file that comes with the tool, so that file can be included with a one-liner for those projects that want it but there is nothing implicit going on by default.
- mturmon 13y ago
  I think "magic" is much too loaded a way to characterize it. The rule applicable to C pertains to building foo.o from foo.c. It amounts to two lines in a Makefile: %.o: %.c $(COMPILE.c) $(OUTPUT_OPTION) $< where COMPILE.c and the other variable is predefined to trivial values. There are other rules useful for C++, and for yacc, etc., but they are just as simple. You can cancel all the implicit rules with "-r", or cancel selected implicit rules by naming them in the Makefile like this: %.o : %.c ; All this is in the make manual, which is quite good: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html https://www.gnu.org/software/make/manual/html_node/Catalogue...