Nix flake for isolated GCC-Rust development environment

[nsvke]

This PR introduces a pure, reproducible Nix development environment for gccrs. I placed the files under gcc/rust/nix/ strictly for ease of review and to avoid polluting the global GCC root directory.

The main goal of this flake is to significantly reduce the onboarding friction for new contributors by handling all toolchain, glibc, and dependency configurations automatically.

• Provides completely separate environments for both 64-bit and 32-bit targets, automatically preventing linker conflicts.

• Injects useful global scripts (gccrs-setup, gccrs-build, gccrs-mklog, gccrs-check-commit) to automate the build process and ensure GNU commit standards are met effortlessly.

While this PR is a proof-of-concept placed inside the GCC tree, I believe the best approach would be to host this flake in a dedicated side-repository, such as Rust-GCC/gccrs-nix, and document it in the main gccrs README.

With that setup, new developers wouldn't even need to manually clone gccrs. They could simply run a single command to get a ready-to-use environment:
nix develop github:Rust-GCC/gccrs-nix -c gccrs-setup

You can review the full implementation in my reference repository here:

I would love to hear your feedback on this workflow.

cc: @P-E-P

gcc/rust/ChangeLog:

* nix/flake.lock: New file.
* nix/flake.nix: New file.

[P-E-P]

Could we pin this dependency to a specific commit ?

[nsvke]

I was initially relying on the flake.lock file to handle the version pinning, but we can definitely pin the exact commit hash directly in flake.nix if preferred. I can update this in the next commit.

[P-E-P]

Completely forgot about lock file, forget what I said.

[P-E-P]

I think the location of this file is incorrect. We should probably put this in $GCC_TOP/contrib/. I can't remember how we usually tag files that should not be sent upstream though.

@dkm probably has a lot of advice and opinions on that matter (and I'd like to hear them)

EDIT: Didn't read that part about the side repository for the flake at first. This would probably help a lot and reduce potential friction when upstreaming.

[dkm]

Correct, that's really not something we should send upstream, at least not in this form.

It would be nice to have it in contrib/ if it was meant to be shared, but as it's really a gccrs specific thing.

We could have it in gcc/rust/<something> to avoid any mistake. We already have a non-code doc/ subdir.

Or, we could still have it in contrib/, BUT:

• we also need to adjust the hardcoded list in https://github.com/Rust-GCC/gerris/blob/dkm/upstream-command/src/upstream.rs#L314 .
• as we don't directly push anything outside the rust directories, anything touching this file would NOT be sent upstream. Meaning that you'll need to avoid having commits mixing code changes and flake change, as these commits won't be sent upstream.

TLDR: the easier would be to keep it in rust/ (sent upstream), but the cleaner would be to keep it in contrib/ and be careful.

[P-E-P]

Correct me if I'm wrong but this shouldn't happen if we retrieve the script from the store, you could use builtin.FilterSource to make it lighter.

[nsvke]

You are absolutely right. However, if we proceed with the side-repository approach, the flake won't be able to access this script during the evaluation phase. The source code is only available after the environment is initialized (either via the gccrs-setup command or a manual clone).

Depending on which repository structure we ultimately choose to move forward with, I can definitely rethink and refactor this for the most optimal solution.

[powerboat9]

/contrib/gcc-git-customization.sh shows a method for using rev-parse to handle execution outside the root folder.

[dkm]

I would try to add more info in the commit log. You have the info as the PR description is very well detailed.
Keep in mind that the git repository will probably be live for a long time. It's also really nice to have the basic info in the git log without having to browse github (e.g. think offline work, or if github is down, or if github dies).

[nsvke]

I have completed a major refactoring of the Nix environment in my reference repository. To preserve the existing inline comment history, I am not pushing these commits to this draft PR.