-
Notifications
You must be signed in to change notification settings - Fork 701
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
Dedupe include dirs inherited from dependencies #3974
Dedupe include dirs inherited from dependencies #3974
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Just a minor suggestion about code layout.
++ [ "-I" ++ dir | ||
| dep <- deps | ||
, dir <- Installed.includeDirs dep ] | ||
++ installedIncludeDirs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I'd keep it inline here rather than pulling it out. e.g.
++ [ "-I" ++ dir
, dir <- ordNub [ dir | dep <- deps
, dir <- Installed.includeDirs dep ]
-- dedupe include dirs of dependencies
-- to prevent quadratic blow-up
]
cd4fb25
to
ca09443
Compare
If you build a big number of packages, all with the same extra -I flags, the flags get inherited by the dependent packages and duplicated. For big dependency trees it can exceed the maximum command line length on some systems, this happened to me with Linux and hoogle 5. This patch decreases the redundancy by dropping all but the first occurrence of an include dir, preserving the semantics, as they are processed left to right.
ca09443
to
6e31b30
Compare
I've updated to accommodate the suggestion with a minor formatting change to respect 80-col limit. |
LGTM. Feel free to merge once Travis is green. |
Travis timed out, I've tried restarting the job but it didn't seem to have done anything. |
I restarted it myself, seems to have worked. |
Merged, thanks! |
@niteria I have a question about this. In the commit you say:
But if they are processed left to right (and thus I assume later ones override earlier ones) shouldn't you keep the last one instead the first? E.g. if you have dirs |
@nh2: Here's the documentation: https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html The relevant part:
My understanding is that it searches left to right and takes the first one that matches. |
OK, if that's how it works, then that's OK. |
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
…LibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
… and `PD.extraLibDirs`. Should help with big invocations as found in NixOS/nixpkgs#41340.
If you build a big number of packages, all with
the same extra -I flags, the flags get inherited
by the dependent packages and duplicated.
For big dependency trees it can exceed the
maximum command line length on some systems,
this happened to me with Linux and hoogle 5.
This patch decreases the redundancy by
dropping all but the first occurrence of
an include dir, preserving the semantics,
as they are processed left to right.