4

I have been reading up on make and looking at the Makefiles for popular C projects on GitHub to cement my understanding.

One thing I am struggling to understand is why none of the examples I've looked at (e.g. lz4, linux and FFmpeg) seem to account for header file dependencies.

For my own project, I have header files that contain:

  1. Numeric and string constants
  2. Macros
  3. Short, inline functions

It would seem essential, therefore, to take any changes to these into account when determining whether to recompile.

I have discovered that gcc can automatically generate Makefile fragments from dependencies as in this SO answer but I haven't seen this used in any of the projects I've looked at.

Can you help me understand why these projects apparently ignore header file dependencies?

M. Berk
  • 189
  • 1
  • 6
  • Because they aren't mature? – Andrew Henle Nov 15 '17 at 13:34
  • one possibility may be: the makefiles are just used to batch compile everything. But if you change something, you have to clean the project to be sure it recompiles. Developpers use another dev. system and don't want to impose it to people who just want to build it once: configure => make => done. Plus it is faster because no need to compute dependencies using `gcc -MM` to append to the existing makefiles. – Jean-François Fabre Nov 15 '17 at 13:34
  • @AndrewHenle: Torvalds will not be pleased with your remarks. – vgru Nov 15 '17 at 13:35
  • Linux does calculate header dependencies and incorporate them into the build with `include` directives in the Makefile. If you doubt this, run an actual build, change a header file, and run it again. It can be difficult to find all the rules through the maze of `include`d files, but it works. You won't find a big *static* list of header file dependencies because it's all dynamically generated. –  Nov 15 '17 at 13:49
  • 2
    lz4 looks like it doesn't build object files as separate targets at all. From a quick peek it invokes a single instance of the compiler and passes all the _source_ files to it, then creates a library from them all in the same rule. So, header prerequisites are useless. I don't know why you list `linux` and `FFmpeg` in your examples, they both clearly DO have automatically generated header file prerequisites. – MadScientist Nov 15 '17 at 16:30
  • @MadScientist I follow your description of the rules for lz4 but I don't understand why it follows that header prerequisites are useless. I don't see how, based on this description, the library will be rebuilt if a header file is changed. As for including `linux` and `FFmpeg`, it's not clear to me that they do have automatically generated header file prerequisites. Of course, a good answer to this question is one that shows why I'm mistaken. – M. Berk Nov 16 '17 at 15:44
  • True if the changes are solely to headers and no change to any source file then things won't be rebuilt. Probably this single rule should also depend on all header files as well as all source files. The current makefile is sufficient for downstream people who just want to build the code without doing development on it. Don't know what the developers do. – MadScientist Nov 16 '17 at 17:56

1 Answers1

3

I'll attempt to answer.

The source distros of some projects include a configure script which creates a makefile from a template/whatever.

So the end user which needs to recompile the package for his/her target just has to do:

$ configure --try-options-until-it-works
$ make

Things can go wrong during the configure phase, but this has nothing to do with the makefile itself. User has to download stuff, adjust paths or configure switches and run again until makefile is successfully generated.

But once the makefile is generated, things should go pretty smooth from there for the user which only needs to build the product once to be able to use it.

A few portion of users will need to change some source code. In that case, they'll have to clean everything, because the makefile provided isn't the way the actual developpers manage their builds. They may use other systems (code::blocks, Ant, gprbuild...) , and just provide the makefile to automate production from scratch and avoid to depend on a complex production system. make is fairly standard even on Windows/MinGW.

Note that there are some filesystems which provide build audit (Clearcase) where the dependencies are automatically managed (clearmake).

If you see the makefile as a batch script to build all the sources, you don't need to bother adding a dependency system using

  • a template makefile
  • a gcc -MM command to append dependencies to it (which takes time)

Note that you can build it yourself with some extra work (adding a depend target to your makefile)

Jean-François Fabre
  • 137,073
  • 23
  • 153
  • 219
  • Any system that uses automake (most software with a `configure` script will be using both autoconf and automake) has header file dependency generation built in automatically: it's a feature that comes standard with automake. – MadScientist Nov 15 '17 at 16:27
  • @MadScientist makes sense. However, on my MSYS system, I don't have `autoconf` or `automake` handy. I'm not saying that _all_ project don't generate dependencies, just saying that it's not needed by 95% of people who just need to recompile (and which would have probably liked to avoid even recompilation), so some projects probably skip that. – Jean-François Fabre Nov 15 '17 at 16:31
  • 1
    Sure. I just meant, if you have a project that contains a `configure` script it most likely already has support for header file dependencies built in. Not all, of course. Some use autoconf without automake, and some create a `configure` script by hand rather than using either autoconf or automake. – MadScientist Nov 15 '17 at 16:49
  • Agreed. OP must be talking about those special "lazy" cases else it makes no sense – Jean-François Fabre Nov 15 '17 at 16:53
  • Could this be summarised as there is (depending on the project) a distinction between Makefiles used for installation purposes and those used during development? – M. Berk Nov 17 '17 at 09:59
  • @M.Berk yes, that seems reasonable – Jean-François Fabre Nov 17 '17 at 10:29