Skip to content

Fix missing <tuple> include for std::tie in network_interface_info.h #4009

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
1 commit merged into from
Mar 28, 2025

Conversation

rshrj
Copy link
Contributor

@rshrj rshrj commented Mar 27, 2025

This PR adds a missing #include <tuple> to network_interface_info.h, which is required for the use of std::tie.

Without this include, builds fail on compilers/environments that do not implicitly include <tuple> via transitive headers. For example, GCC on Debian 12 produces:

error: ‘tie’ is not a member of ‘std’
note: ‘std::tie’ is defined in header ‘’; did you forget to ‘#include ’?

Tested by successfully building the project in a clean Debian 12 dev container with GCC. No other changes.

@xmkg xmkg self-requested a review March 27, 2025 13:39
@xmkg
Copy link
Member

xmkg commented Mar 27, 2025

Hi @rshrj, thanks for the contribution!

I see that the linter is complaining about the include order. Could you make the suggested change?

Thanks!

Copy link
Member

@xmkg xmkg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rshrj rshrj force-pushed the fix-missing-tuple-include branch from 328b896 to a444b47 Compare March 27, 2025 14:06
@rshrj rshrj requested a review from xmkg March 27, 2025 14:08
@xmkg
Copy link
Member

xmkg commented Mar 27, 2025

Hi @rshrj, since this PR is coming from an external fork, some of the CI steps could not be run for security reasons. Would you mind if I open a pull request including both of your PRs? I'll just carry your commits as-is; the only difference would be the PR is coming from a main repository branch, not a fork.

@rshrj
Copy link
Contributor Author

rshrj commented Mar 27, 2025

Hi @rshrj, since this PR is coming from an external fork, some of the CI steps could not be run for security reasons. Would you mind if I open a pull request including both of your PRs? I'll just carry your commits as-is; the only difference would be the PR is coming from a main repository branch, not a fork.

Hi @xmkg. That explains it! Sure, I don't mind. Are you not supposed to fork this repository for contributions or are there different steps involved?

@xmkg
Copy link
Member

xmkg commented Mar 27, 2025

Hi @xmkg. That explains it! Sure, I don't mind. Are you not supposed to fork this repository for contributions or are there different steps involved?

Hi @rshrj, thanks for the confirmation :)

It's absolutely fine to fork the repo, and it's the way how it's supposed to work with external contributors, but there are some obstacles on the CI side regarding how the configuration is being handled. There are some changes we need to make to accommodate the PR's coming from forks. It's in our roadmap, so hopefully we won't have to use workarounds in the future and make it easier for the contributors.

@xmkg
Copy link
Member

xmkg commented Mar 27, 2025

Opened the non-fork MP: #4012, will be closing #4008 #4009 once it's merged.

@github-merge-queue github-merge-queue bot closed this pull request by merging all changes into canonical:main in ab399ad Mar 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants