-
-
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
Reorganise include files #7847
Reorganise include files #7847
Conversation
I just noticed this is not enough because nix headers also don't have the |
Yeah, this is the main reason we're not doing this already. I think it would require moving all the headers to a |
Thanks for doing this @andreabedini. It is also necessary to work on Hydra and Nix at the same time incrementally, which is critical for being able to address NixOS/hydra#1164 productively.
Git handles file moves very well. We should move the headers to |
I started working on this, although I opted for -#include "serialise.hh"
+#include "nix/util/serialise.hh" Let me know if you have strong opinions about this. |
I personally like that (I am all about good layering!), and it shouldn't matter since this stuff is unstable anyways, but I will note that this is a breaking change as to where the files are installed whereas the other thing isn't. |
You are right, this was a step past the original intention which was only changing the pc files are readjusting the include paths. That would have only required a small change in the consumer build setup (e.g. a change in a Makefile) while this brings in (possibly annoying) a change in the source code. Thanks for pointing this out @Ericson2314! I could add a bunch of symlinks to ease up the transition pain? (edit: or shims with a deprecation warning?) |
Added compatibility shims as well.
|
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.
I really like the overall change (modulo a couple of small things). Given the amount of code churn, I'd like to leave @NixOS/nix-team a chance to voice their opinion, but it's a 👍 from me.
src/libcmd/include/nix/command.hh
Outdated
@@ -0,0 +1,2 @@ | |||
#warning "Including nix/command.hh is deprecated. Include nix/cmd/command.hh instead." |
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.
Would it make sense to generate these files on-the-fly rather than checking them out?
(they aren't big nor anything, but I imagine them being a bit confusing and very annoying when browsing the codebase with a fuzzy-finder)
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.
I personally don't think these stub files are worth the trouble. It's not too hard to do the bulk rename with a small script to see which library it was moved to. This stuff is explicitly unstable/internal, so breakage is not so much of an issue.
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.
As a maintainer of a package that uses the headers headers, I will have to add a version check conditional around my imports anyway.
Automating this guidance is probably not worth the effort for our limited ecosystem of library consumers.
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.
If that's the consensus, I am happy to remove the shims. @roberth do you see any way we can make the transition easier for downstream consumers?
I think the worst part is figuring out where each include file went, and the shims addressed this by mentioning the location of the new file. I could make a awk script to migrate to the new locations but it won't help if you need to support both.
This reverts commit a205add.
I'm not really in favor of this, not just because of the massive amount of code churn, but also because I rather like having the header files next to their corresponding implementation files (e.g. Also, the resulting paths seem superfluous/repetitive (e.g. |
I suggest that this PR #7847, PR #7870, and my old #5589 both touch on very similar issues, and projects like #7735 (more bindings) somewhat force the issue. These PRs are hard to rebase (thought actually easy to rebase other PRs over! The disruption is not bad!) so I guest we figure out what we want in an issue first. I'll get started on writing that issue. |
#7876 This is the issue. Please comment there! |
Triaged in the Nix team meeting:
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-02-24-nix-team-meeting-minutes-35/25757/1 |
I am aware this change is quite invasive. pkg-config by itself is not the goal, the goal is to make it easier to link to nix C++ API from other projects (e.g. outside nix). Language bindings come to mind but the sky is the limit. |
@andreabedini I will say the notes reflect but a very brief triaging conversation moving this to the "to discuss column". |
Discussed in Nix team meeting: @andreabedini we decided to postpone this for now, as the change is fairly costly in terms of moving around lots of files. We will reconsider it in light of the more general issue when we make more progress there: #7876 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-03-27-nix-team-meeting-minutes-44/26759/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-04-14-nix-team-meeting-minutes-48/27358/1 |
Revisited in the Nix maintainers meeting:
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-07-21-nix-team-meeting-minutes-73/30768/1 |
Oh one downside to I think @thufschmitt had started to think of symlinking so we could use the layout from the issue while still keeping the headers next to sources as @edolstra wanted? That would also be a good option. |
Another way to check that is to have a derivation per library. That would save some rebuilds as well. |
At this point I would say the PR is useful only for the discussion it generated. Given this PR is also mentioned in the discussion in #7876, I can be confident it will not get lost and close it |
Motivation
Currently the pkg-config files says to use the following include path
I believe it would be more appropriate if this said
In this way consumers could do
#include <nix/config.h>
, while at the moment this does not work.From what I can understand, in a stdenv pkg-config files are redundant because adding
nix
to your build dependencies automatically causes the compiler wrapper to pass-I${nix-dev}/include
to the compiler, which is the same thing I believe we should do with pkg-config.One example consumer of the nix libraries is hercules-ci-cnix-store, which cannot be compiled outside of a nix evironment (I should say without a nix wrapped compiler) because it includes the
nix/config.h
path.Context
I am making (so far very experimental) tools that link to nix code from outside of a nix stdenv. I have installed nix-dev in my profile and manually adjusted PKG_CONFIG_PATH.
Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests
tests/nixos/*