-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Collect "file system object" parts of libnixutil
together
#9278
Comments
2023-11-17 Nix team meeting notes:
|
libnixutil
into a new libnixfile
libnixutil
together
@edolstra if the main files go in a directory, and the main files are next to he headers, should we do more |
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 |
(Now that I did the requested reword of the issue, I think it is safe to say this issue is team-approved) |
Hi, I want to work on this.
So, the main thing here is that we have to move filesystem-related functionality from
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.
Inside At any rate, we need to choose which approach to follow before refactoring. Also, please let me know if I got the idea correctly. |
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 (seebuild/
inlibstore
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 #8918src/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.The text was updated successfully, but these errors were encountered: