Collect "file system object" parts of libnixutil together

[Ericson2314]

We now have bunch of involved code for working with file system objects.

Someday it might be good to codify this into a new libnixfile. (Don't worry, that doesn't mean I am planning a "file-only" Nix!) But going down that road would mean lots of little libraries, which could have implications for dynamic linking. For now we can instead group files into subdirectories (see build/ in libstore for this same concept), but keep all such directories linked together in the parent library.

For initial contents I am thinking:

• src/libutil/archive
• src/libutil/canon-path
• src/libutil/fs-sink
• src/libutil/git.cc will contain more stuff after Git object hashing in libstore #8918
• src/libutil/posix-source-accessor
• src/libutil/source-accessor
• src/libutil/file-content-address New, doesn't distinguish between "flat" and "text" because w.r.t file system objects (as opposed to store objects) they are the same.

I think this will continue growing too based on our current plans. libnixfetchers only barely depends on the store layer anyways, so I think some or even all of it could end up here too.

[Ericson2314]

@edolstra Are you OK with this? Part of my motivation is in #8918 many duplicative call sites need to be updated. I would to provide some new functions that abstract over those patterns (and work with arbitrary accessors) instead.

[Ericson2314]

2023-11-17 Nix team meeting notes:

• @edolstra: nope
• @edolstra: I don't care about libnixfile, but we could start organising libutil a bit more (moving stuff to subfolders)
  • @Ericson2314: I like that. I'll do that first
  • I'll rewrite issue

[Ericson2314]

@edolstra if the main files go in a directory, and the main files are next to he headers, should we do more -I flags or should we do e.g. #include "file/canon-path.hh?

[nixos-discourse]

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

https://discourse.nixos.org/t/2023-11-17-nix-team-meeting-minutes-104/35753/1

[Ericson2314]

(Now that I did the requested reword of the issue, I think it is safe to say this issue is team-approved)

[oxcabe]

Hi, I want to work on this.

Someday it might be good to codify this into a new libnixfile.

So, the main thing here is that we have to move filesystem-related functionality from libnixutil to a new libnixfile lib, right?

But going down that road would mean lots of little libraries, which could have implications for dynamic linking.

Being a Nix-specific library, does it need to be dynamic, or could we just statically link it to the rest of the modules that depend on it? I infer it's way more convoluted than my current understanding of things.

For now we can instead group files into subdirectories (see build/ in libstore for this same concept), but keep all such directories linked together in the parent library.

Inside libnixutil you mean, right? So we end up with something like src/libutil/fs/...

At any rate, we need to choose which approach to follow before refactoring. Also, please let me know if I got the idea correctly.