Hi,
A common pattern in C/C++ is to define function signatures in a separate .h[pp] file, and then include the signatures into the implementation .c[pp] file. Would be helpful for deheader to account for this common practice.
There may not necessarily be any symbols reused from such a header. Some headers may consist chiefly of a header guard macro and a docstring comment. Yet even so, the implementation conventionally needs to include this header.
Most of the time, the header serves simply to export the implemented functions into a reusable API. The header contains no additional information, but rather acts like a checksum in terms of making sure the function signatures are correct. Although deheader currently treats these headers as removable, in fact, their removal could break the API for downstream users.
For example, drop the file extension from the header basename. Drop the file extension from the implementation basename. If the two match, then it is very likely safe for deheader to ignore this.
Hi,
A common pattern in C/C++ is to define function signatures in a separate .h[pp] file, and then include the signatures into the implementation .c[pp] file. Would be helpful for deheader to account for this common practice.
There may not necessarily be any symbols reused from such a header. Some headers may consist chiefly of a header guard macro and a docstring comment. Yet even so, the implementation conventionally needs to include this header.
Most of the time, the header serves simply to export the implemented functions into a reusable API. The header contains no additional information, but rather acts like a checksum in terms of making sure the function signatures are correct. Although deheader currently treats these headers as removable, in fact, their removal could break the API for downstream users.
For example, drop the file extension from the header basename. Drop the file extension from the implementation basename. If the two match, then it is very likely safe for deheader to ignore this.