Project

General

Profile

Bug #4041

Doxygen generates incomplete include paths

Added by Davide Pesavento almost 4 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Docs
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

As can be seen e.g. here, the #include line generated by doxygen contains only the header file name, without the path (it should be <ndn-cxx/util/ethernet.hpp>). The path information is critical for library users.

STRIP_FROM_INC_PATH option may be used to solve this problem.


Related issues

Blocked by ndn-cxx - Task #3084: Rename "src" folder to "ndn-cxx"ClosedDavide Pesavento

Actions
#1

Updated by Junxiao Shi almost 4 years ago

  • Description updated (diff)

STRIP_FROM_INC_PATH is insufficient. It can strip the initial part of an include path to make util/ethernet.hpp but cannot prepend ndn-cxx, until after #3084.

#2

Updated by Davide Pesavento almost 4 years ago

Junxiao Shi wrote:

STRIP_FROM_INC_PATH is insufficient. It can strip the initial part of an include path to make util/ethernet.hpp but cannot prepend ndn-cxx

That would still be much better than the status quo, and is trivial to implement.

#3

Updated by Davide Pesavento over 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Davide Pesavento
  • % Done changed from 0 to 50

https://gerrit.named-data.net/3942 is the first half of this task. FULL_PATH_NAMES and STRIP_FROM_INC_PATH are used to generate #include directives containing the relative path of the header from the "src" directory. The "ndn-cxx/" prefix will have to be added manually somehow.

#4

Updated by Junxiao Shi over 3 years ago

https://gerrit.named-data.net/3942 patchset5 includes:

security/conf/common.hpp is renamed to security/conf/conf-common.hpp to avoid conflicts with src/common.hpp

This doesn't seem to be a valid reason.
A quick search (find -name '*.hpp' -exec basename '{}' ';' | sort | uniq -c | sort -n) shows there are 29 list.hpp files in Boost 1.54.0 libraries. Boost.Fusion library has 4 of them.
ns-3 has 7 scan-header.h files in its repository, and ns-3 has a large Doxygen site.
If Boost and ns-3 are allowed to have non-unique header names, why ndn-cxx cannot?

#5

Updated by Davide Pesavento over 3 years ago

Junxiao Shi wrote:

This doesn't seem to be a valid reason.

Please go ahead and explain that to doxygen. I'm not going to waste any more time on this.

If Boost and ns-3 are allowed to have non-unique header names, why ndn-cxx cannot?

Boost doesn't use doxygen. Bad example.
The #include lines generated for ns-3 contain only the header name, not the path. Again, bad example.

#6

Updated by Junxiao Shi over 3 years ago

Please go ahead and explain that to doxygen. I'm not going to waste any more time on this.

Then this issue is blocked by the upstream issue in Doxygen.
There's a workaround without renaming files in this post.

The #include lines generated for ns-3 contain only the header name, not the path. Again, bad example.

If ns-3 can get away with header name only, ndn-cxx can as well.
It's a severe constraints if header names must be unique everywhere.

#7

Updated by Davide Pesavento over 3 years ago

  • Status changed from In Progress to Feedback
  • Assignee deleted (Davide Pesavento)

It's a severe constraints if header names must be unique everywhere.

The non-unique name generates a simple warning in doxygen, but doesn't cause any practical issues. It's only a problem because our Docs-Checkers in jenkins are extremely strict and fail hard when they encounter any warning.

#8

Updated by Davide Pesavento over 3 years ago

  • Target version deleted (v0.6)
  • % Done changed from 50 to 0
#9

Updated by Davide Pesavento over 3 years ago

Junxiao Shi wrote:

There's a workaround without renaming files in this post.

I tried that weeks ago. It has no effect.

If ns-3 can get away with header name only, ndn-cxx can as well.

Stop using ns-3 as an example. They have a very weird and unique way of including headers. User apps are supposed to include "ns3/foo-module.h" and that's it, all module headers are in the ns3/ directory, no subdirs. So the #include generated by doxygen is not so important for them.

#10

Updated by Junxiao Shi over 3 years ago

The non-unique name generates a simple warning in doxygen, but doesn't cause any practical issues. It's only a problem because our Docs-Checkers in jenkins are extremely strict and fail hard when they encounter any warning.

Can we grep -v out this warning from Doxygen output in Jenkins?

#11

Updated by Davide Pesavento over 2 years ago

  • Blocked by Task #3084: Rename "src" folder to "ndn-cxx" added
#12

Updated by Davide Pesavento over 2 years ago

  • Status changed from Feedback to Code review
  • Assignee set to Davide Pesavento
  • Target version set to v0.7
  • % Done changed from 0 to 100
#13

Updated by Davide Pesavento about 2 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF