7 ms·

I do like the straightforwardness of Make. But it doesn't do quite enough for it to be simple to use for C or C++ programs. The simplest generic Makefile I can

by Rusky 9y ago

I do like the straightforwardness of Make. But it doesn't do quite enough for it to be simple to use for C or C++ programs. The simplest generic Makefile I can come up with that handles header file dependencies correctly is 10-20 lines of relatively complex interaction with the compiler. But then again maybe that's just an argument against C and C++'s compilation model. :)

ajross 9y ago
To be fair, dependency tracking is properly a function of the compiler, you can't do it in make alone without the ability to parse the language. And it's not 10-20 lines. GCC and clang both support the -M family of arguments that do this for you. It's a matter of running it to generate some sort of dependency file and including it in the makefile. Yes, that's annoying and definitely a problem with the inclusion-based dependency model of C. But really it's not such a big deal.
- Rusky 9y ago
  Right, I was referring to adding the right -M arguments, including the generated .d files, and handling the edge cases with adding/removing files to the build. Overall the minimal Makefile I copy-paste into every new C project is about that size, so I suppose 10-20 lines includes a few other things as well.
- lifthrasiir 9y ago
  > It's a matter of running it to generate some sort of dependency file and including it in the makefile. This is not as simple as it sounds. Make has a fundamental limitation that dependencies cannot be generated on the fly, and current workarounds for dependency-generating dependencies are very messy [1]. [1] http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ http://make.mad-scientist.net/papers/advanced-auto-dependenc...
  - wruza 9y ago
    >Although it’s simple, there are serious problems with this method. First and foremost is that dependencies are only rebuilt when the user explicitly requests it; if the user doesn’t run make depend regularly they could become badly out-of-date and make will not properly rebuild targets. Thus, we cannot say this is seamless and accurate. Not so fundamental, if you quickly make depend after changing includes. Why is that messy? I never got that "buy magic automation, sell simplicity" trading. Deps changed, deps have to be updated. Once updated, they just work.
- JdeBP 9y ago
  Those arguments are not enough. For dependencies to be fully reliable, the compiler needs to emit information about where headers were not found, in addition to where they were found. Otherwise headers introduced earlier into search paths after a build do not properly trigger a rebuild. * http://jdebp.eu./FGA/introduction-to-redo.html#CompilerDeficiencies http://jdebp.eu./FGA/introduction-to-redo.html#CompilerDefic... * http://cr.yp.to/redo/honest-nonfile.html http://cr.yp.to/redo/honest-nonfile.html
  - ajross 9y ago
    Honestly, that's just intractable. That can't be solved for the same reason that changes to the makefile itself can't be tracked. Changes to the structure of the build system aren't "dependencies" as commonly understood. Almost all other systems have this flaw in some way as well. You can fool everything, because a system capable of not being fooled would literally have to reparse and rebuild everything from scratch.
    - erlehmann_ 9y ago
      Almost all other systems have this flaw because they require dependencies before a build. If recording dependencies after the build, the entire problem becomes very simple. See here: http://news.dieweltistgarnichtso.net/posts/redo-gcc-automatic-dependencies.html http://news.dieweltistgarnichtso.net/posts/redo-gcc-automati...
      - ajross 9y ago
        The example above was of a change to the build structure (include path, specifically) which changes the dependency tree in a way that doesn't involve changes to the files themselves and will be invisible to make or other tools that use file timestamps. I pointed out that this was just one of a whole class of intractable problems with dependency tracking that we all choose to ignore. It can't be fixed, even in principle. The only truly sure way to know you're building correctly is to build from scratch. Everything else is just a heuristic.

by Rusky 9y ago

ajross 9y ago

To be fair, dependency tracking is properly a function of the compiler, you can't do it in make alone without the ability to parse the language. And it's not 10-20 lines. GCC and clang both support the -M family of arguments that do this for you. It's a matter of running it to generate some sort of dependency file and including it in the makefile. Yes, that's annoying and definitely a problem with the inclusion-based dependency model of C. But really it's not such a big deal.

Rusky 9y ago
Right, I was referring to adding the right -M arguments, including the generated .d files, and handling the edge cases with adding/removing files to the build. Overall the minimal Makefile I copy-paste into every new C project is about that size, so I suppose 10-20 lines includes a few other things as well.
lifthrasiir 9y ago
> It's a matter of running it to generate some sort of dependency file and including it in the makefile. This is not as simple as it sounds. Make has a fundamental limitation that dependencies cannot be generated on the fly, and current workarounds for dependency-generating dependencies are very messy [1]. [1] http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ http://make.mad-scientist.net/papers/advanced-auto-dependenc...
- wruza 9y ago
  >Although it’s simple, there are serious problems with this method. First and foremost is that dependencies are only rebuilt when the user explicitly requests it; if the user doesn’t run make depend regularly they could become badly out-of-date and make will not properly rebuild targets. Thus, we cannot say this is seamless and accurate. Not so fundamental, if you quickly make depend after changing includes. Why is that messy? I never got that "buy magic automation, sell simplicity" trading. Deps changed, deps have to be updated. Once updated, they just work.
JdeBP 9y ago
Those arguments are not enough. For dependencies to be fully reliable, the compiler needs to emit information about where headers were not found, in addition to where they were found. Otherwise headers introduced earlier into search paths after a build do not properly trigger a rebuild. * http://jdebp.eu./FGA/introduction-to-redo.html#CompilerDeficiencies http://jdebp.eu./FGA/introduction-to-redo.html#CompilerDefic... * http://cr.yp.to/redo/honest-nonfile.html http://cr.yp.to/redo/honest-nonfile.html
- ajross 9y ago
  Honestly, that's just intractable. That can't be solved for the same reason that changes to the makefile itself can't be tracked. Changes to the structure of the build system aren't "dependencies" as commonly understood. Almost all other systems have this flaw in some way as well. You can fool everything, because a system capable of not being fooled would literally have to reparse and rebuild everything from scratch.
  - erlehmann_ 9y ago
    Almost all other systems have this flaw because they require dependencies before a build. If recording dependencies after the build, the entire problem becomes very simple. See here: http://news.dieweltistgarnichtso.net/posts/redo-gcc-automatic-dependencies.html http://news.dieweltistgarnichtso.net/posts/redo-gcc-automati...
    - ajross 9y ago
      The example above was of a change to the build structure (include path, specifically) which changes the dependency tree in a way that doesn't involve changes to the files themselves and will be invisible to make or other tools that use file timestamps. I pointed out that this was just one of a whole class of intractable problems with dependency tracking that we all choose to ignore. It can't be fixed, even in principle. The only truly sure way to know you're building correctly is to build from scratch. Everything else is just a heuristic.