NFD » ndn-cxx

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.

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?

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.

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.

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.

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?