This question was triggered here: 829955 – sys-devel/gcc: fails when building on NixOS during bootstrap (cc1: error: no include path in which to search for stdc-predef.h) (tries to use system /usr/include?)
I am trying to bootstrap Gentoo Prefix, in essence a Gentoo Linux in user space. During it’s bootstrapping progress it looks for /usr/include
for system headers and libs which does not exist in NixOS.
So the two questions are
- How to check if a user is on NixOS? Maybe checking if
nixos-version
is available?
- How to find the paths for system headers and libs for the current nix generation?
A follow up question would be if Gentoo Prefix binaries (e.g. gcc) would continue to work if the user switches to a new nix generation where the ld paths might be different?
/etc/NIXOS
should exist on NixOS systems
I would say this is an anti-pattern with nix, you shouldn’t be concerned with build dependencies in a global context. I would probably package gentoo prefix with nix, and just expose the packaged versions.
However, you could set an environment variable with environment.variables
in your configuration.nix
1 Like
/etc/NIXOS
should exist on NixOS systems
Thanks, sounds good.
I would say this is an anti-pattern with nix, you shouldn’t be concerned with build dependencies in a global context. I would probably package gentoo prefix with nix, and just expose the packaged versions.
I had a similar feeling, but packaging gentoo prefix with nix somehow seemed weird to me as well - if only because I am not too familiar with either yet. A compromise could be to have a default.nix with the build deps and starting the booststrap-prefix.sh from nix-shell?
However, you could set an environment variable with environment.variables
in your configuration.nix
Ah, environment.variables
is good to know, thanks. But which env vars and which usage did you have in mind?
A compromise could be to have a default.nix with the build deps and starting the booststrap-prefix.sh from nix-shell?
This is the way, seriously! Not telling you what to do, but don’t throw the advantages Nix gives you away by installing dev dependencies globally. When I start a new project, I always start with a shell.nix
(or now its Flake equivalent, but that doesn’t matter) where I describe the whole development environment. I usually then use direnv
so that this environment is automatically activated once I enter the project folder.
If your project does not build on a fresh Nix/NixOS after git clone
followed by nix-shell
because you lack some global dependencies or environment variables, you are wasting potential. This is the power of Nix, you download the source repo that contains a Nix derivation that completely describes the build environment, activate it with nix-shell
and are immediately capable of building. With Flakes or otherwise pinned nixpkgs
(e.g. using niv
) you can also no longer be bitten by a different Nixpkgs version. If I wanted to meddle with my global configuration for every new project I build, I could have stayed with almost any other distro and save all the additional effort to use Nix.
Building an actual derivation for the code usually comes a lot later.
I can’t stress enough how much better it makes life for everyone if your build environments are self contained. If a friend (needs to use Nix obviously) wants to help on a project, he just clones the repo and is ready to build and contribute within minutes, no matter how complicated the environment might be. Heck, I’d almost say these reproducible build environments are THE reason for a dev to use Nix.
1 Like
This is the way, seriously!
Thanks for chiming in, your opinions, pointers and experiences. I will try going down that route then! Do you maybe have an example shell.nix
where the headers and libs path resolution is done?
1 Like