3 ms·

> IME, `clean` is for when I want things rebuilt despite "nothing" having changed. Of course, you can use clean in this case. You can do that also with redo,

by jnxx 6y ago

> IME, `clean` is for when I want things rebuilt despite "nothing" having changed. Of course, you can use clean in this case. You can do that also with redo, just delete all the intermediate files and start a normal build. However the point is that you do a "make clean" most often to be sure that all dependencies are refreshed, because you are actually not sure that your Makefile captures them all. A good example are builds in yocto. This is a system to build complete embedded Linux images based on make, with many subprojects. But if you change, for example, the kernel to support large files, or a 32 bit time_t, you can't be sure that a simple "make" delivers a correct system, because the dependencies on the system headers are not include in all the makefiles.

danaris 6y ago
Please forgive the confusion, as I've only dabbled in Make, but... > You can do that also with redo, just delete all the intermediate files and start a normal build. ...isn't that pretty much what "make clean" generally does? I mean, in a project of any significant size, "all the intermediate files" aren't going to be trivial to delete without a pre-built "delete all the intermediate files" script...which is what "make clean" is (at least partly) for. Or are you just saying that "redo" (which I'd never heard of before, so, again, please forgive my ignorance) can also process a pre-built list of "intermediate files" to delete with some particular command or option...?
- dllthomas 6y ago
  If I understand, the real point was that clean is less often needed. Having said that, you could certainly list system headers in a Makefile (... hopefully a generated one) if that's the behavior you want, so I am not sure what difference is actually being pointed to.
  - jnxx 6y ago
    > Having said that, you could certainly list system headers in a Makefile You can. But that's a lot of headers. You can instruct gcc to tell the dependencies to you, but this information is hard to pipe into make because you'd need to generate a new Makefile from it (which is more or less what some larger projects do). Using redo it is easy to use this compiler-generated dependency information, and the paramount reason for this is that it is not a DAG dependency graph DSL with added shell snippets but just a shell script with added shell commands which define dependencies. This is what I mean with "it is Make turned inside out".
    - dllthomas 6y ago
      I should note that in general, decomposing things into multiple shell utilities is something I'm a huge proponent of, and assuming redo does it well that's really cool! That said, I don't think "depending on system headers" is somewhere make is lacking. The -M argument to gcc or clang gives you a well formatted Makefile which includes system headers. You have to explicitly ask they be excluded (-MM) if that's what you want (which it was often enough for the option to be added, it seems).
- jnxx 6y ago
  > ...isn't that pretty much what "make clean" generally does? Yes, exactly. The point is that "make clean" is used because the Makefile does not capture the dependencies perfectly. So, "make clean" ensures a clean rebuilt. But that can cost a lot of time, especially in large projects or when using C++ header libraries such as boost::python or Eigen. Now, if you were sure that your depedency description is correct, you could skip "make clean". And this is what redo provides, because, at the one hand, it allows to use dependency information provided by the compiler, and moreover, it covers a lot of corner cases precisely. The corner cases not always working is why "make clean" is typically used for.

by jnxx 6y ago

danaris 6y ago

Please forgive the confusion, as I've only dabbled in Make, but... > You can do that also with redo, just delete all the intermediate files and start a normal build. ...isn't that pretty much what "make clean" generally does? I mean, in a project of any significant size, "all the intermediate files" aren't going to be trivial to delete without a pre-built "delete all the intermediate files" script...which is what "make clean" is (at least partly) for. Or are you just saying that "redo" (which I'd never heard of before, so, again, please forgive my ignorance) can also process a pre-built list of "intermediate files" to delete with some particular command or option...?

dllthomas 6y ago
If I understand, the real point was that clean is less often needed. Having said that, you could certainly list system headers in a Makefile (... hopefully a generated one) if that's the behavior you want, so I am not sure what difference is actually being pointed to.
- jnxx 6y ago
  > Having said that, you could certainly list system headers in a Makefile You can. But that's a lot of headers. You can instruct gcc to tell the dependencies to you, but this information is hard to pipe into make because you'd need to generate a new Makefile from it (which is more or less what some larger projects do). Using redo it is easy to use this compiler-generated dependency information, and the paramount reason for this is that it is not a DAG dependency graph DSL with added shell snippets but just a shell script with added shell commands which define dependencies. This is what I mean with "it is Make turned inside out".
  - dllthomas 6y ago
    I should note that in general, decomposing things into multiple shell utilities is something I'm a huge proponent of, and assuming redo does it well that's really cool! That said, I don't think "depending on system headers" is somewhere make is lacking. The -M argument to gcc or clang gives you a well formatted Makefile which includes system headers. You have to explicitly ask they be excluded (-MM) if that's what you want (which it was often enough for the option to be added, it seems).
jnxx 6y ago
> ...isn't that pretty much what "make clean" generally does? Yes, exactly. The point is that "make clean" is used because the Makefile does not capture the dependencies perfectly. So, "make clean" ensures a clean rebuilt. But that can cost a lot of time, especially in large projects or when using C++ header libraries such as boost::python or Eigen. Now, if you were sure that your depedency description is correct, you could skip "make clean". And this is what redo provides, because, at the one hand, it allows to use dependency information provided by the compiler, and moreover, it covers a lot of corner cases precisely. The corner cases not always working is why "make clean" is typically used for.