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

Stdenv setup: Process dependencies before dependents #31414

Draft
wants to merge 6 commits into
base: staging
Choose a base branch
from

Conversation

Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented Nov 9, 2017

Motivation for this change

This is intended to be reviewed commit-by-commit.

This does 2 things

  1. Change the dependency order. Before, we did the current node before children, now we do the children before current node. Were dependencies forming a tree, this would simply be the inverse traversal, but since they in fact form a DAG, it's a bit more subtle. The opposite of the new invariant "dependencies before dependents" wasn't true: dependents weren't always processed first because it was possible that a dependency was already visited via another dependent.

    This is an observable change because the processing we are doing does not commute: arbitrary bash setup hooks certainly don't, and PATH concatenation doesn't either. I do think having this invariant is valuable, though, and rely on it to simplify cc-wrapper's setup hook.

  2. Cyclic dependencies are now an error. Yes, they are only possible in absurd cases, but possible nonetheless:

    └── /nix/store/asdfasdfasdf-foobar/
        ├── foo
        │   └── nix-support
        │       └── propagated-build-inputs = /nix/store/asdfasdfasdf-foobar/bar
        └── bar
            └── nix-support
                └── propagated-build-inputs = /nix/store/asdfasdfasdf-foobar/foo
    

    (foo and bar are cyclic). The old algo would silently work with this; the new one would naively diverge, so I made it error out instead as such a thing should never be intended. But if we agree this shouldn't happen in practice so infinite recursion is a good enough error, I can simplify things

Things done

Hoping to merge this Monday 2017-11-13 at the latest :). Thanks!

  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built stdenv on platform(s)
    • NixOS -- latest in progress, see nixborg build
    • macOS -- latest in progress
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

CC @bgamari

@copumpkin
Copy link
Member

This seems sensible in principle, but can we get a Hydra job showing what the implications might be? Subtly changing behavior (that arguably nobody should rely on the order of, but people probably do) makes me very uncomfortable even if it does make sense.

@globin
Copy link
Member

globin commented Nov 9, 2017

@nixborg build

@nixborg
Copy link

nixborg commented Nov 9, 2017

Jobset created at https://hydra.mayflower.de/jobset/nixos/pr-31414

}

# Add package to the future PATH and run setup hooks
activatePackage() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Who calls this function?

@@ -359,15 +389,22 @@ if [ -z "${crossConfig:-}" ]; then
${propagatedNativeBuildInputs:-} ${propagatedBuildInputs:-}; do
findInputs "$i" nativePkgs propagated-native-build-inputs
done
for i in "${nativePkgs[@]}"; do
activatePackage "$i"
Copy link
Member Author

Choose a reason for hiding this comment

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

@orivej here

for i in ${nativeBuildInputs:-} ${defaultNativeBuildInputs:-} ${propagatedNativeBuildInputs:-}; do
findInputs "$i" nativePkgs propagated-native-build-inputs
done
for i in "${nativePkgs[@]}"; do
activatePackage "$i"
Copy link
Member Author

Choose a reason for hiding this comment

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

@orivej And here

@Ericson2314
Copy link
Member Author

@globin is there any good known-good jobsest to compare the nixborg one to?

@Ericson2314 Ericson2314 added this to Needed for binutils-wrapper in Cross compilation Nov 9, 2017
@Ericson2314
Copy link
Member Author

Oh hmm, this breaks down when different dependencies are in fact the same derivation. I'm going to have to think about that.

@orivej
Copy link
Contributor

orivej commented Nov 10, 2017

Could you give an example in nixpkgs?

@Ericson2314
Copy link
Member Author

@orivej Nevermind. The already-visited logic is based on actual paths, I just mistakenly changed the iteration order. [I did have to make _PATH be prepended instead of appended, but that is expected.]

There's still a theoretical issue where "unrelated" deps could clobber each other on the PATH in different ways based on different topological sorts, and our depth-first one might not have the most intuitive behavior in that regard, but I won't worry about this unless it shows up in practice.

I added a cc-wrapper commit from my #29396 branch that actually leverages this, to make sure everything works alright.

@orivej orivej changed the base branch from master to staging November 10, 2017 19:49
@orivej orivej changed the base branch from staging to master November 10, 2017 19:51
Copy link
Contributor

@orivej orivej left a comment

Choose a reason for hiding this comment

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

Looks good. https://hydra.mayflower.de/jobset/nixos/pr-31414 did not pick your changes yet… And since AFAIK it does not contribute to the nixos cache, shouldn't this PR go to staging first?

@Ericson2314 Ericson2314 changed the base branch from master to staging November 10, 2017 20:58
@globin
Copy link
Member

globin commented Nov 11, 2017

@nixborg build

@nixborg
Copy link

nixborg commented Nov 11, 2017

Jobset created at https://hydra.mayflower.de/jobset/nixos/pr-31414

@Ericson2314 Ericson2314 changed the base branch from staging to master December 20, 2017 20:38
@Ericson2314 Ericson2314 changed the base branch from master to staging December 20, 2017 20:38
@Ericson2314 Ericson2314 moved this from After big PR to Perhaps not priority for 18.03 in Cross compilation Jan 2, 2018
@Ericson2314 Ericson2314 mentioned this pull request May 7, 2018
8 tasks
Ericson2314 referenced this pull request Jul 27, 2018
This will be very useful for bootstrapping, eventually.
Ericson2314 referenced this pull request Sep 17, 2018
…d of strings

This is generally cleaner: less eval, less worrying about separators,
and probably also faster. I got the idea from that python wrapper
script.
@FRidh
Copy link
Member

FRidh commented Jul 20, 2019

I like the motivation behind this change but because nothing is happening I am closing this.

@FRidh FRidh closed this Jul 20, 2019
@JohnAZoidberg
Copy link
Member

This issue is mentioned in nixpkgs stdenv: https://github.com/nixos/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L1167

@Ericson2314
Copy link
Member Author

Yes maybe a GitHub issue rather than open PR canbe made for that.

@Ericson2314
Copy link
Member Author

Reopning and marking as draft because I ought to finish it at some point.

@Ericson2314
Copy link
Member Author

Should be possible to finish after #132340 is the default and cc-wrapper is simplified.

@stale
Copy link

stale bot commented Apr 19, 2022

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Cross compilation
Perhaps not priority for 18.03
Development

Successfully merging this pull request may close these issues.

None yet

9 participants