rakhimov / cppdep Goto Github PK

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.

For example, Qt and STL provide header files without extensions.

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.

Proper documentation for the code.

• Remove global variables
• Decouple, group procedures into cohesive classes

...we consider classes that refer to more than 20 other classes and which are referred to by more than 20 other classes as critical. On the level of subsystems the critical limit is 10 referring and referred to subsystems.

Klaus Wolfmaier and Rudolf Ramler:
Common Findings and Lessons Learned from Software Architecture and Design Analysis

An example issue is the UIC auto-generated headers in user projects.

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).

This is relevant when pairing files into components.

Currently, report and warnings are mixed into stdout.

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.

#29

An ability to run the tool with command-line arguments only.
Deduce package name and include paths from the command-line arguments,
the current directory, and the system.

Analyze files/packages concurrently. Add '-j' flag.

• existence
• duplicate
• redundancy
• inconsistency
• conflict
• schema

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.

The main seems to be called twice per run.

An option to report the analysis results into separate report files per package/group/graph-type
in the same manner as graph dot files are produced.

The original code lacks tests and relies on manual testing via the main test driver.

• Unit tests
• Analysis validation
• Performance tests

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

yaml as a potential alternative.

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 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.

http://stackoverflow.com/questions/12843099/python-logging-typeerror-not-all-arguments-converted-during-string-formatting#12843139

The components are described with levels in the CCD approach.
The current implementation reports graph layers instead.

As a CMake user, I don't want to have to create another project configuration file to specify my product structure. cppdep should be able to use CMake to gather this information. This might be done with a build generator or it might be done via APIs that I understand CMake is making available for IDEs.

setup.py locally behaves differently than pip install;
as a result, the schema file is ending in different places
unexpected by the modules.

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.

If both implementation and header include the same header,
the included header may be redundant in either of them (e.g., refactoring artifact).

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

Cycles must add extra levels as described in the book.
The current implementation doesn't seem to calculate levels this way.

Heavy C code with some extern declarations.

Incorporation of include-wrangler analysis

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

In collaboration with include-wrangler author @lukedodd

Cycles are stripped for some reason from the dependency graph.

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.

Related to #18.