Boost & libpcap's VERSION

[gvanem]

I stumbled on an issue while building libtins with support for Boost. When compiling libtin's src/tcp_ip/ack_tracker.cpp:

In file included from ./include\tins/tcp_ip/ack_tracker.h:38:
In file included from f:/MinGW32/src/CPP/Boost_1_74_0\boost/icl/interval_set.hpp:13:
In file included from f:/MinGW32/src/CPP/Boost_1_74_0\boost/icl/type_traits/is_interval_joiner.hpp:11:
In file included from f:/MinGW32/src/CPP/Boost_1_74_0\boost/config.hpp:44:
In file included from f:/MinGW32/src/CPP/Boost_1_74_0\boost/config/detail/select_stdlib_config.hpp:24:
f:/MinGW32/src/inet/libpcap\version(1,1): error: expected unqualified-id
1.11.0-PRE-GIT
^

The lines prior to line 24 in Boost's select_stdlib_config.hpp:

#if defined(__cplusplus) && defined(__has_include)
#  if __has_include(<version>)
// It should be safe to include `<version>` when it is present without checking
// the actual C++ language version as it consists solely of macro definitions.
// [version.syn] p1: The header <version> supplies implementation-dependent
// information about the C++ standard library (e.g., version number and release date).
#    include <version>  // << !! libpcap's VERSION. 
#  else
#    include <cstddef>
#  endif

This should be no issue on e.g. Linux. But on Windows, the filesystem is case-insensitive. So could libpcap's VERSION please be renamed to VERSION.dat or similar (as OpenSSL does it)?

PS. I was building libtins with the dev-tree of libpcap (not the installed stuff). Using clang-cl on Win-10.

[infrastation]

Renaming VERSION would not be the right thing to do, as later some other code could have #include <changes> with some 3rd-party changes.h in mind, and libpcap would have to move CHANGES out of the way, and so on.

The complication seems to be caused by providing the full libpcap source tree to a 3rd-party build process. If you run make install (or the equivalent), you should have one directory with pcap.h and its entourage only (for inclusion) and another with the shared library only (for linking). Then if the 3rd-party build process uses these directories instead of the full source tree, there will be no unexpected clashes like the one you are observing. Does it make sense?

[gvanem]

Does it make sense?

I guess so. But's too much hassle to install libpcap headers etc. just to use it. So I'll just delete (and recreate) VERSION as needed.

[infrastation]

Fine.

[guyharris]

We could rename VERSION and CHANGES to *.txt...

...or we could move the public header files. Libssh 0.9.4, for example, has "include" and "src" directories under the top-level directory. We could put the public header files in an "include" directory; if somebody points a build at that directory, that will not only prevent them from seeing "VERSION" as a header file, it'd also prevent them from seeing pcap-int.h as a public header file, which would be a Good Thing.

[infrastation]

This was not apparent to me. Obviously, downstream-visible churn should be avoided if there is no good reason for it. Some projects have src and include (the former comes from Automake defaults, AFAIR), and some do not, I do not have a strong opinion about it. If moving the headers makes enough sense to you and you feel confident addressing all bugs that surface in the process, it would be wrong to get in your way. Perhaps this would be one more reason to address the last warning in libpcap and to make the CI feedback loop more complete.

That said, if someone is determined to include pcap-int.h, they will make sure to use both include paths.

[rigtorp]

...or we could move the public header files. Libssh 0.9.4, for example, has "include" and "src" directories under the top-level directory. We could put the public header files in an "include" directory;

This is the way to go. I always structure my projects like this. It also makes it easy to include libpcap in a external/ directory and statically build and link into my own software.