Make Link Depend

A hypothetical tool[*] that automatically figures out which .o object files and .a library files a given main program needs to be linked with.

E.g. file foo_main.cc may contain

    #include "foo.hh"
    #include "bar.hh"

    int main() { 
       bar_c bar_object;
       foo::do_this(bar_object);
       bar_object.do_that();
    }

Unless foo or bar are HeaderOnlyCeePlusPlusPackages the object files will probably need to be linked something like

    gcc -o foo foo_main.o foo.o bar.o

A MakeLinkDepend tool would automatically figure this out. Barring such a tool, you typically need to add this to the Makefile by hand.

---

Some Makefiles create libraries containing all the object files in a directory subtree. This just puts the problem off: you may then want to create make dependencies so that not all users of a library need to be recompiled if only a single .o object file in a library .a archive changes.

---

[*] I say that MakeLinkDepend is a hypothetical tool, because I am not aware of any satisfactory implementation.

One of my junior programmers wrote one of these almost 10 years ago for DEC C++ on VMS. It not only figured out the dependencies, it fetched the necessary code from version control. It wasn't difficult. -- EricHodges

---

Include Centric Approach

Do a conventional include file oriented header MakeDepend.

For every header file (.h, .hh, .hpp, .hxx, .H), if there is a corresponding source file (.c, .cc, .cpp, .cxx, .C), indicate that the corresponding object file needs to be linked in. Transitively close.

Link Symbol Centric Approach

Try to link the executable. Process the linker error messages, grepping for undefined symbols. Grep source (.c,.cc) and header files for the missing symbols. Link the corresponding object files in, and repeat.

Or, process the symbol table for an object module. E.g. using UNIX nm (an external command), or by opening a shared library.

---

The need for this is largely C and C++. Java, Haskell, Oberon, Modula-2, Qomp (undoubtedly), Pascal, and so on, and so on, all can figure this out for itself.

---

Some linkers in embedded toolchains are so-called "smart" linkers. They start from the startup file (which initializes variables via tables built by the linker and then calls main) and only adds symbols that are not yet linked. Typically, all file-scope variables are in one linkable section, and each function is in its own linkable section.

If you include a .o file that has no needed functions, your executable won't get bigger.

---

CategoryCpp