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

emacs: parameterize native compilation patch #353137

Open
wants to merge 1 commit into
base: staging
Choose a base branch
from

Conversation

AndersonTorres
Copy link
Member

@AndersonTorres AndersonTorres commented Nov 2, 2024

Split from #341656

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

pkgs/applications/editors/emacs/sources.nix Show resolved Hide resolved
mkArgs = { pname, version, variant, patches ? _: [ ], rev, hash }: {
inherit pname version variant patches;
mkArgs = { pname, version, variant, templateNativeCompDriverOptionsPatch, patches ? _: [ ], rev, hash }: {
inherit pname version variant templateNativeCompDriverOptionsPatch patches;
Copy link
Contributor

Choose a reason for hiding this comment

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

This specific patch changes almost every release so I agree with the idea of moving it to mkArgs from make-emacs.nix. However, not putting it in patches seems a bit over-engineering to me. Just my 2 cents.

Copy link
Contributor

@jian-lin jian-lin Nov 6, 2024

Choose a reason for hiding this comment

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

Well, given that we are passing the same patch to the same version of both emacs and emacs-macport, now I think it is better to not moving the patch into mkArgs from make-emacs.nix.

Copy link
Member Author

@AndersonTorres AndersonTorres Nov 8, 2024

Choose a reason for hiding this comment

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

Why not?

The patch depends on the Emacs source being built.
It looks reasonable to parameterize it.
This is similar to the patches we are using for Emacs 28.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why not?

To reduces code duplication.


Thinking it a bit more, I am fine with keeping it in make-emacs.nix or putting it into patches of mkArgs.

Comment on lines 150 to 165
patches = patches fetchpatch ++ lib.optionals withNativeCompilation [
(substituteAll {
src = if lib.versionOlder finalAttrs.version "29"
then ./native-comp-driver-options-28.patch
else if lib.versionOlder finalAttrs.version "30"
then ./native-comp-driver-options.patch
else ./native-comp-driver-options-30.patch;
backendPath = (lib.concatStringsSep " "
(builtins.map (x: ''"-B${x}"'') ([
# Paths necessary so the JIT compiler finds its libraries:
"${lib.getLib libgccjit}/lib"
] ++ libGccJitLibraryPaths ++ [
# Executable paths necessary for compilation (ld, as):
"${lib.getBin stdenv.cc.cc}/bin"
"${lib.getBin stdenv.cc.bintools}/bin"
"${lib.getBin stdenv.cc.bintools.bintools}/bin"
])));
})
];
patches = patches fetchpatch ++ lib.optionals withNativeCompilation [ nativeCompilationPatch ];
Copy link
Contributor

Choose a reason for hiding this comment

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

Factoring out substituteAll seems over-engineering to me. It also makes the diff larger than needed and harder to review.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, formatting makes the diff larger than needed and harder to review. Could you keep the old format? We can do formatting in a future PR or leave it to the tree-wide one.

pkgs/applications/editors/emacs/sources.nix Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants