Skip to content
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

Split up util.{hh,cc} #8920

Merged
merged 2 commits into from
Nov 5, 2023
Merged

Conversation

Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented Sep 4, 2023

Motivation

Fixes #8913

All OS and IO operations should be moved out, leaving only some misc portable pure functions.

This is useful to avoid copious CPP when doing things like Windows and Emscripten ports.

Context

This sort of thing is annoying to write and annoying to read, but I realized I have to do it before trying to finish #8901.

Checklist for maintainers

Maintainers: tick if completed or explain if not relevant

  • agreed on idea
  • agreed on implementation strategy
  • tests, as appropriate
    • functional tests - tests/**.sh
    • unit tests - src/*/tests
    • integration tests - tests/nixos/*
  • documentation in the manual
  • documentation in the internal API docs
  • code and comments are self-explanatory
  • commit message explains why the change was made
  • new feature or incompatible change: updated release notes

Priorities

Add 👍 to pull requests you find important.

@github-actions github-actions bot added new-cli Relating to the "nix" command with-tests Issues related to testing. PRs with tests have some priority store Issues and pull requests concerning the Nix store repl The Read Eval Print Loop, "nix repl" command and debugger fetching Networking with the outside (non-Nix) world, input locking labels Sep 4, 2023
@fricklerhandwerk
Copy link
Contributor

Triaged in Nix maintainers meeting:

  • @Ericson2314: goal is to get closer to make Nix work on Windows
  • @edolstra: would be better to make the changes when there is direct need
    • you will only know exactly what the ideal factoring is once you start the porting
  • @tomberek: recently played around with providing an Emscripten build output, this would help with that kind of thing
  • @edolstra: two more problems:
    • adds friction to using git blame
    • more compilation units increases compilation time
      • @Ericson2314: would rather focus on readability, can always add compilation performance hacks on top (e.g. pre-concatenating files)
        • can do follow up and also merge into lazy trees
  • idea approved

@Ericson2314 Ericson2314 added the idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome. label Sep 22, 2023
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-09-22-nix-team-meeting-minutes-88/33343/1

Copy link
Contributor

@fricklerhandwerk fricklerhandwerk left a comment

Choose a reason for hiding this comment

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

Okay, I gave it an almost complete but still somewhat cursory look. I think the desired end result is very desirable.

I fully trust you on doing the right thing here, so that's approved.

Yet I'm quite concerned about this being a huge diff that could allow mistakes to slip through into foundational components, and I wouldn't want to share responsibility for that. I'd feel a lot more comfortable with doing that in multiple steps, even if that ends up being 30% more work. It will also ease dissection a lot.

Multiple commits may be fine, but reviews leading to rewriting history will just produce friction as those tend to confuse me, so I'd err towards multiple PRs. If anything, it will make a lot more likely for me to really go through each component and make sure I understand it and its role in the system, so I see it as a good opportunity for knowledge sharing. Being involved in way too many things, spending hours in a row staring at code is something I simply can't afford these days.

If anyone else on the @nixos/nix-team says "nah it'll be fine" we can of course just merge it as is.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's a weird name. What is it really about? Why is it not e.g. system-specific.hh?

Copy link
Member Author

Choose a reason for hiding this comment

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

I went with current-process.hh, with the new first commit nativeSystem is no longer there, and everything else is squarely about the current process.


std::string drainFD(int fd, bool block, const size_t reserveSize)
{
// the parser needs two extra bytes to append terminating characters, other users will
Copy link
Contributor

Choose a reason for hiding this comment

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

Which parser?

Copy link
Member Author

Choose a reason for hiding this comment

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

I just moved that code :)

I don't think we need a CPP defininition and a header entry, and this
way allows constant expression elimination.
All OS and IO operations should be moved out, leaving only some misc
portable pure functions.

This is useful to avoid copious CPP when doing things like Windows and
Emscripten ports.

Newly exposed functions to break cycles:

 - `restoreSignals`
 - `updateWindowSize`
@Ericson2314
Copy link
Member Author

Thanks @fricklerhandwerk. So one that makes me feel a lot better about this is git show --color-moved. That "proves" that this is just moving code around, and thus while it's a lot of code motion and the drudgery of cutting and pasting was mind-melting, there isn't anything interesting going on.

I do agree knowledge sharing is good, but I an easier way to do that is going through these files post split, e.g. during the Windows porting process. It's much easier to digest things when they are already cut into bite sized pieces :).

As you saying trying to redo this into separate PRs for each header would take longer. While I don't really mind it for the headers themselves, it would worse code churn on the #includes in all the other files and headers came and went. Because of that, because we have so many more interesting things to spend reviewer time on (this is a boring step towards an interesting destination, Windows), and because you are on board with breaking up the giant file, I think it is just best to merge this as-is.

@roberth
Copy link
Member

roberth commented Nov 5, 2023

These moves were long overdue. Merging while the merge base is up to date.

Not expecting much merge conflicts from this, as this is support code - not a place where features happen. Certainly we have better places than a "utils" file by now!

git show --color-moved.

This is a life saver for review.

@roberth roberth merged commit 1a14ce8 into NixOS:master Nov 5, 2023
8 checks passed
@Ericson2314 Ericson2314 deleted the split-util-cchh branch November 5, 2023 22:07
@roberth roberth mentioned this pull request Nov 6, 2023
Ericson2314 added a commit to obsidiansystems/nix that referenced this pull request Aug 5, 2024
The test split matches PR NixOS#8920, so the utility files and tests files
are once again to 1-1. The string changes continues what was started in
PR NixOS#11093.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fetching Networking with the outside (non-Nix) world, input locking idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome. new-cli Relating to the "nix" command repl The Read Eval Print Loop, "nix repl" command and debugger store Issues and pull requests concerning the Nix store windows with-tests Issues related to testing. PRs with tests have some priority
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Split utils.hh
4 participants