Add compile-time version macros by seladb · Pull Request #2118 · seladb/PcapPlusPlus

seladb · 2026-04-30T07:53:23Z

Addresses #2101.

This PR adds version macros and introduces a patch version in case we need it:

#define PCAPPLUSPLUS_VERSION_YEAR 25
#define PCAPPLUSPLUS_VERSION_MONTH 5
#define PCAPPLUSPLUS_VERSION_PATCH 0
#define PCAPPLUSPLUS_VERSION_DEV 1

It also includes macros to compare versions, for example:

#if PCAPPLUSPLUS_VERSION_HIGHER_OR_EQUAL_THAN(25, 5, 0)
    /// Use new APIs introduces in v25.05
#endif

codecov · 2026-04-30T08:13:53Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.72%. Comparing base (6ba29cf) to head (586fdc4).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev    #2118   +/-   ##
=======================================
  Coverage   82.72%   82.72%           
=======================================
  Files         332      332           
  Lines       59807    59807           
  Branches    12591    12586    -5     
=======================================
  Hits        49475    49475           
+ Misses       8947     8929   -18     
- Partials     1385     1403   +18

Flag	Coverage Δ
23.11.6	`7.32% <ø> (+0.04%)`	⬆️
24.11.5	`7.32% <ø> (+0.01%)`	⬆️
25.11.1	`7.29% <ø> (-0.04%)`	⬇️
alpine320	`76.85% <ø> (ø)`
fedora42	`76.43% <ø> (ø)`
macos-14	`82.26% <ø> (ø)`
macos-15	`82.25% <ø> (ø)`
mingw32	`71.13% <ø> (+0.01%)`	⬆️
mingw64	`71.00% <ø> (-0.02%)`	⬇️
npcap	`85.69% <ø> (ø)`
rhel94	`76.28% <ø> (+0.03%)`	⬆️
ubuntu2204	`76.26% <ø> (ø)`
ubuntu2204-icpx	`59.40% <ø> (ø)`
ubuntu2404	`76.57% <ø> (ø)`
ubuntu2404-arm64	`76.53% <ø> (-0.03%)`	⬇️
ubuntu2604	`76.47% <ø> (-0.04%)`	⬇️
unittest	`82.72% <ø> (ø)`
windows-2022	`85.68% <ø> (-0.01%)`	⬇️
windows-2025	`85.71% <ø> (+<0.01%)`	⬆️
winpcap	`85.92% <ø> (+0.01%)`	⬆️
xdp	`53.15% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

seladb · 2026-05-04T08:50:03Z

@Dimi1010 this PR is still in draft, but I wanted to get your opinion on this approach

seladb · 2026-05-04T08:50:51Z

+
+/// @def PCAPPLUSPLUS_VERSION
+/// @brief Short version string (e.g., "25.05" for official release or "25.05+" for development)
 #define PCAPPLUSPLUS_VERSION "25.05+"


It's possible to create this string using macros, but it'll be very complex, so maybe it's easier to keep it as is...

I suppose we can manually set it.

A potential alternative is to have the cmake build system generate the version file, like it does with the package config files. I think that is generally more flexible and we would only need to change the version in the CMakeLists.

Also, do you think we should include the patch number in all versions? (eg. 25.05.0), so people always expect it if they decide to do magic with the version string?

A potential alternative is to have the cmake build system generate the version file, like it does with the package config files. I think that is generally more flexible and we would only need to change the version in the CMakeLists.

@seladb Additional discussion may be needed separately, but I managed to get CMake to compile a version from the git tags. The versioning is based on the signature major.minor.patch.tweak.

It fetches the MAJOR, MINOR, PATCH from the most recent tag. (eg. last release)
It then calculates the Tweak version as the number of commits past the most recent tag the build is.

If we are precisely on the release commit, the tweak version will be 0 and the full version maj.min.patch.0, if we are 1 commit past it it will be maj.min.patch.1. This can then be used to determine official releases (tweak 0) vs nightly / dev builds (tweak != 0).

The solution will allow us to have rolling versions unique for each development build commit, so we don't have just a nebulous "DEV" version flag. For example the current master would be 25.05.0.201.

A extended version string can also be added with a commit hash, if we need to differentiate between commits on different branches, but I think most will be used from the master / dev line.

I'm not sure we need a build version because we never publish those versions. We don't even publish patch versions... I think year.month.patch is enough for the version.

I managed to get CMake to compile a version from the git tags

I'm curious how does it work?

When does it run and fetch the tag from git? In every commit?

Does it fetch the latest tag?

I think year.month.patch is enough for the version.

Sure. I guess that works.

I'm curious how does it work?

When does it run and fetch the tag from git? In every commit?

Does it fetch the latest tag?

It is based on git describe --tags --long --always, which is called during the CMake configure step. The command results in a string like v25.05-211-g1a2ad56b which can then be reformatted. From what I have seen, it fetches the latest tag that the current commit is derived from. The command can be configured to select only annotated tags (default), or any tags (--tags).

Also, on second thoughts it does have some inconvenient drawbacks. Main one is that it establishes a dependency on the git repo being available at configure time to compute the correct version. This leads to some problems when remote compilation is used, like building on WSL since the default behaviour of rsync does not copy the .git folder since it is not needed. The requirement should only be relevant when the lib is build from source tho, since installs don't really run the configure the same way.

Yes I agree. Version should probably be static and not rely on CMake configuration or on git.

Should we stick with what we have in this PR?

Version should probably be static and not rely on CMake configuration or on git.

Hmm, it might be fine to rely on CMake configuration to generate the Version.h header as long as the version in the configuration is static? We could have the cmake project version to be the "source of truth" for version.

project(MyLib VERSION 2.4.1) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/version.h.in ${CMAKE_CURRENT_BINARY_DIR}/generated/version.h @ONLY)

As a sidenote, setting project version would also allow consuming packages to designate required versions for the package directly in the build system like this find_package(PcapPlusPlus 25.04 ...).

Anyway, that can be handled in a separate PR, if we decide to do it as it does not strictly relate to the current PR.

I'm not sure I understand this comment. Do you suggest adding another file version.h in addition to PcapPlusPlusVersion.h that is based on CMake?

As you said, we can probably merge this PR as is and address this separately later.

Dimi1010

Looks ok. I am a bit iffy on PCAPPLUSPLUS_VERSION_DEV, but I don't have any better ideas for it, so... 🤷

Dimi1010 · 2026-05-04T10:15:31Z

+
+/// @def PCAPPLUSPLUS_VERSION
+/// @brief Short version string (e.g., "25.05" for official release or "25.05+" for development)
 #define PCAPPLUSPLUS_VERSION "25.05+"


I suppose we can manually set it.

A potential alternative is to have the cmake build system generate the version file, like it does with the package config files. I think that is generally more flexible and we would only need to change the version in the CMakeLists.

Also, do you think we should include the patch number in all versions? (eg. 25.05.0), so people always expect it if they decide to do magic with the version string?

KangLin · 2026-05-07T06:20:18Z

it is recommended to use Semantic format. the major for the API，the minor for year, the path for date.
eg:
v1.26.05-dev
1: major
26: minor, the year
05: patch, the date
dev: develop, it is can dev count. eg: 1, 2, 3 etc

seladb · 2026-05-08T04:54:27Z

it is recommended to use Semantic format. the major for the API，the minor for year, the path for date. eg: v1.26.05-dev 1: major 26: minor, the year 05: patch, the date dev: develop, it is can dev count. eg: 1, 2, 3 etc

@KangLin I don't think we want to switch from CalVer to SemVer, at least not now

Dimi1010

LGTM. One comment on possible integration with cmake package versioning, but that can be addressed separately.

Dimi1010 · 2026-05-17T07:27:56Z

+
+/// @def PCAPPLUSPLUS_VERSION
+/// @brief Short version string (e.g., "25.05" for official release or "25.05+" for development)
 #define PCAPPLUSPLUS_VERSION "25.05+"


Version should probably be static and not rely on CMake configuration or on git.

Hmm, it might be fine to rely on CMake configuration to generate the Version.h header as long as the version in the configuration is static? We could have the cmake project version to be the "source of truth" for version.

project(MyLib VERSION 2.4.1) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/version.h.in ${CMAKE_CURRENT_BINARY_DIR}/generated/version.h @ONLY)

As a sidenote, setting project version would also allow consuming packages to designate required versions for the package directly in the build system like this find_package(PcapPlusPlus 25.04 ...).

Anyway, that can be handled in a separate PR, if we decide to do it as it does not strictly relate to the current PR.

Add version macros

22694c7

seladb mentioned this pull request Apr 30, 2026

Provide version checking functionality #2101

Open

Merge branch 'dev' into compile-time-version

3313dc7

seladb requested a review from Dimi1010 May 4, 2026 08:49

seladb commented May 4, 2026

View reviewed changes

Dimi1010 reviewed May 4, 2026

View reviewed changes

Dimi1010 approved these changes May 17, 2026

View reviewed changes

Merge branch 'dev' into compile-time-version

586fdc4

seladb marked this pull request as ready for review May 28, 2026 08:12

Conversation

seladb commented Apr 30, 2026

Uh oh!

codecov Bot commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

seladb commented May 4, 2026

Uh oh!

seladb May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Dimi1010 May 4, 2026

Choose a reason for hiding this comment

Uh oh!

Dimi1010 May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seladb May 16, 2026

Choose a reason for hiding this comment

Uh oh!

Dimi1010 May 16, 2026

Choose a reason for hiding this comment

Uh oh!

seladb May 17, 2026

Choose a reason for hiding this comment

Uh oh!

Dimi1010 May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seladb May 28, 2026

Choose a reason for hiding this comment

Uh oh!

Dimi1010 left a comment

Choose a reason for hiding this comment

Uh oh!

Dimi1010 May 4, 2026

Choose a reason for hiding this comment

Uh oh!

KangLin commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seladb commented May 8, 2026

Uh oh!

Dimi1010 left a comment

Choose a reason for hiding this comment

Uh oh!

Dimi1010 May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov Bot commented Apr 30, 2026 •

edited

Loading

seladb May 4, 2026 •

edited

Loading

Dimi1010 May 5, 2026 •

edited

Loading

Dimi1010 May 17, 2026 •

edited

Loading

KangLin commented May 7, 2026 •

edited

Loading

Dimi1010 May 17, 2026 •

edited

Loading