[flohofwoe]

How would a tool know from a header dependency, in which source file the implementation for the header lives? C or C++ don't require any relationship between a declaration file and implementation file. The implementation could be in an entirely differently named source file, or spread over various files, mixed with implementation code from other headers, or included right in the header.

[stkdump]

In the common 2 step generation model of C and C++, this information is not needed. When generating object files it is not relevant which .c/.cpp file corresponds to which header files, because they are no inputs to that. Linkong has to happen when any object file changed.

[adrian_b]

Generating automatically the dependencies is trivial with gcc and GNU make, if you just take care to group adequately in directories and subdirectories.

I.e. you just have to put all the source files from which you generate object files that will go in the same libray in a set of directories which does not contain files that will not go there.

Similarly, all the source files for the object files required for an executable, except those that are in libraries, should be in a set of directories.

The sets of directories need not be disjoint, just a given set must not contain files that must be excluded for linking a certain target, as that will make the building process more complex.

Given this constraints, it is possible to write a universal GNU makefile usable for any project, which will generate automatically all dependencies.

For any executable or library you want to build, it is enough to write an extremely small makefile, containing 4 lists (of defined symbols, of source files, of directories with header files and of libraries) and the name of the generated file and its type (excutable, shared library, static library).

At the end you need to include a makefile that is good for any project targetting a certain CPU + operating system combination.

The makefiles per CPU/OS must define a few things, e.g. the compiler used and other utilities, option flags for all, locations of the tools and so on, then you include a unique makefile for all architectures and operating systems.

I have started using this method more than twenty years ago and I have never ever needed to write manually any dependency information.

Whenever I see the huge and intricate and impossible to maintain makefiles that are too frequently encountered in many software projects, I wonder how one is willing to waste so much time with a non-essential part of the project.

From my point of view, building easily any large software project is a problem solved a long time ago by gcc & GNU make, but for reasons that I cannot understand most people choose to not do it in the right way.

Of course having to use in 2019 a programming language which does not implement modules by any better method than including header files is something even more difficult to understand, but I still must use C/C++ in my work, as there is no alternative for most embedded computers.

[adrian_b]

Sorry, there are several typos in my message above. For most of them it is obvious which was the correct intended word.

However, one typo can lead to a confusion because an entire word is missing. In the 4 lists that must be written in the makefile, the most important list, as the other lists can be omitted, is the list of directories with source files (not a list of source files).

For simple projects the list will be reduced to a single source directory. Whenever you add, delete or rename source files, there is no need to edit the makefile of the project.

All changes can be taken automatically into account by GNU make, which can be instructed to scan the source directories for source files for all the programming languages that you use.