Anomalous (rare, error) case of having "component.c" and "component.cc" or "component.h" and "component.hpp" at the same time trying to define the same component. In other words, files with the same basenames but different extensions in header and/or source groups.

Traceback (most recent call last):
  File "/.../python3env/bin/cppdep", line 11, in <module>
    sys.exit(main())
  File "/.../python3env/lib/python3.5/site-packages/cppdep/__main__.py", line 59, in main
    analysis.analyze(printer, args)
  File "/.../python3env/lib/python3.5/site-packages/cppdep/cppdep.py", line 797, in analyze
    lambda x: isinstance(x, PackageGroup)))
  File "/.../python3env/lib/python3.5/site-packages/cppdep/cppdep.py", line 779, in _analyze
    digraph.write_dot(graph_name)
  File "/.../python3env/lib/python3.5/site-packages/cppdep/graph.py", line 273, in write_dot
    write_dot(self.digraph, file_basename + '.dot')
  File "<decorator-gen-416>", line 2, in write_dot
  File "/.../python3env/lib/python3.5/site-packages/networkx/utils/decorators.py", line 224, in _open_file
    result = func(*new_args, **kwargs)
  File "/.../python3env/lib/python3.5/site-packages/networkx/drawing/nx_pydot.py", line 54, in write_dot
    P = to_pydot(G)
  File "/.../python3env/lib/python3.5/site-packages/networkx/drawing/nx_pydot.py", line 199, in to_pydot
    pydot = _import_pydot()
  File "/.../python3env/lib/python3.5/site-packages/networkx/drawing/nx_pydot.py", line 348, in _import_pydot
    import pydot

If component/project names contain paths as identifiers, the path separator on Windows \ followed by 'U' or 'u' is interpreted as a Unicode literal by pydotplus plotting on Windows with python 2.7.

This problem does not show up on python 3.

For the sake of consistency in the report (stable report) and testing, use Unix path separator in Ids.

Even though templates are only in headers, ipp files could be considered as implementation pair of the interface header. This occurs, for example, in Boost. #29.

Unlike the original ldep, the cppdep is printing the whole cumulative dependencies; that is, the all link time dependencies are printed. This information is visually provided in the graph, and implicitly provided in the original ldep '-l | -L' flags.

It seems like the current implementation of the cumulative dependency printing is geared towards debugging rather than analysis report.

Fix this printing by implementing the original behavior of ldep.

Header and implementation files can be located in different directories, e.g., headers in include and implementation in src. The current implementation assumes the same location.

The package can be deduced from the include directives following the pattern: "<package/header>", e.g., "<boost/any.hpp>". This approach will avoid the relatively expensive lookup of the header from the system. Whether such external header actually exists on the system or not is irrelevant to the dependency analysis.

This heuristic would make the configuration simpler and more robust for cross-platform work.

In addition, the standard library headers can be "hard-coded" into the script since these are the most likely to be used/searched by the source files.

There's a small chance of false positives if the project under analysis happens not to conform to this convention and invents its own packages with the same names as external ones, e.g., boost, qt, libxml.

The current implementation overcounts link time dependencies with common components deep in the dependency graph. Consider: A->B->C, A->D->C. CCD(A) must be 4 (4 object files in total.) The current approach overcounts the common object C, so CCD(A) ends up being 5.

Even though John Lakos defined a component as a pair of h and c files, C++ can have template only components residing only in header files (e.g., STL/Boost/etc.). Moreover, some header-only components may contain only inline functions or macros without any need for an implmentation file (e.g., inline math, Boost PPL). For these reason, unpaired header files can be counted as components by default.

In addition, the implementation file containing the main function of an application could be considered as a component as well (an entry point).

The current implementation uses the basename of the included files as the key in dependency search. This approach ignores the current location of the dependent files and the language include rules, i.e. <header.h> vs. "header.h". Moreover, it results in name conflicts for files that may belong to completely separate projects or packages.

This PR contains some fixes that I needed to get the cppdep tool running in my recent python 3.8 environment. Also handling of errors in the yaml file was adapted a little bit to get more helpful error messages

I've just installed this project, tried to run it but I get this error message.

Traceback (most recent call last):
  File "cppdep.py", line 36, in <module>
    from .graph import Graph
ModuleNotFoundError: No module named '__main__.graph'; '__main__' is not a package

  File "/.../cppdep/cppdep.py", line 92, in path_common
    path = os.path.commonprefix(paths)
  File "/home/olzhas/temp/pyenv/lib/python3.6/genericpath.py", line 76, in commonprefix
    if not isinstance(m[0], (list, tuple)):
TypeError: 'set' object does not support indexing

Incorporation of include-wrangler analysis

• header file cost
• include cost
• translation unit cost
• other features

In collaboration with include-wrangler author @lukedodd

• [ ] Duplicate include
• [ ] Redundant (transitive from the component header) include
• [ ] Missing a component header (incomplete component)
• [ ] Failure to locate a header from an include directive