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

gnumake: do not use MAKE_CXX #314716

Merged
merged 2 commits into from
Aug 19, 2024
Merged

gnumake: do not use MAKE_CXX #314716

merged 2 commits into from
Aug 19, 2024

Conversation

tie
Copy link
Member

@tie tie commented May 25, 2024

Description of changes

Removes unnecessary C++ compiler reference when CXX environment variable is set to an absolute path.

See also https://savannah.gnu.org/bugs/?63668

Parent PR:

Motivation

I’m trying to fix cross-compilation for platforms where C/C++ compiler’s targetPrefix is identical. It’s common to set

depsBuildBuild = [ buildPackages.stdenv.cc ];

when cross-compiling, however, cc/bintools wrapper setup hook currently sets {CC,CXX}{,_FOR_BUILD} et cetera to program name instead of absolute path. That obviously doesn’t work because only the first program from PATH is used (for example, this is part of the reason why static glibc doesn’t work in Nixpkgs and we have pkgsStatic use musl that has different target prefix). There are a lot of other things that start falling apart in stdenv when we set these variables to absolute paths, this is just one of them: gnumake is part of the stdenv and shouldn’t refer to the bootstrap tools.

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.

@tie
Copy link
Member Author

tie commented Jul 16, 2024

Yikes, gnumake doesn’t have a maintainer now (#324539) 🫠

@AndersonTorres, would you mind reviewing this PR?

@tie tie requested a review from AndersonTorres July 16, 2024 23:39
@AndersonTorres
Copy link
Member

Let's start with this!

#327779

Copy link
Member

@AndersonTorres AndersonTorres left a comment

Choose a reason for hiding this comment

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

I have some extra doubts about this specific project.

From a puristic perspective, it should be bootstrapped.
However, how can it be bootstrapped, given that a truckload of things that compose stdenv depend on it?

But let's postpone this. For now we need to test.

pkgs/development/tools/build-managers/gnumake/default.nix Outdated Show resolved Hide resolved
@AndersonTorres
Copy link
Member

P.S.: technically this PR should wait for next staging merge so that the meta info can be updated. But let's hope it does not conflict.

@tie tie force-pushed the make-cxx branch 2 times, most recently from 239a8ed to adc412c Compare July 17, 2024 02:10
@Sigmanificient
Copy link
Member

Let's start with this!

#327779

Do we have a place that list all tracking issues? I always find myself to search them which can something be tedious as i don't remember their name well

@AndersonTorres
Copy link
Member

Do we have a place that list all tracking issues? I always find myself to search them which can something be tedious as i don't remember their name well

Search for the label "scope tracking":
https://github.com/NixOS/nixpkgs/labels/5.%20scope%3A%20tracking

@tie
Copy link
Member Author

tie commented Aug 17, 2024

I’ve rebased the PR and updated the change to use autoreconfHook with a patch to configure.ac and src/default.c. The only downside is that now we always need pkgconf/pkg-config to regenerate configure script (hence the updated nativeBuildInputs).

@tie tie requested a review from philiptaron August 17, 2024 05:25
@rhelmot
Copy link
Contributor

rhelmot commented Aug 17, 2024

Isn't updateAutotoolsGnuConfigScriptsHook a subset of autoreconfHook, so you only need the latter?

Copy link
Contributor

@philiptaron philiptaron left a comment

Choose a reason for hiding this comment

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

I built and tested the stdenv, Nix, and a few other things (gcc, clang, zig.)

LGTM.

@philiptaron
Copy link
Contributor

I intend to merge this tomorrow; I'm holding it open for more commentary.

@tie
Copy link
Member Author

tie commented Aug 17, 2024

Isn't updateAutotoolsGnuConfigScriptsHook a subset of autoreconfHook, so you only need the latter?

Uh, I’m not that familiar with Autotools and related build infrastructure in Nixpkgs. I guess this is true if autoreconfHook regenerates the files that updateAutotoolsGnuConfigScriptsHook updates 😅

I’ll remove it today when I get home if I don’t fall asleep, otherwise in the morning.

Removes unnecessary C++ compiler reference when CXX environment variable
is set to an absolute path.
@tie
Copy link
Member Author

tie commented Aug 18, 2024

As suggested in #314716 (comment), recreated MAKE_CXX patch with git format-patch and updated the patch set. Also removed updateAutotoolsGnuConfigScriptsHook, #314716 (comment).

Comment on lines +33 to +35
# TODO: stdenv’s setup.sh should be aware of patch directories. It’s very
# convenient to keep them in a separate directory but we can defer listing the
# directory until derivation realization to avoid unnecessary Nix evaluations.
Copy link
Member Author

Choose a reason for hiding this comment

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

Created #335579

Copy link
Contributor

@philiptaron philiptaron left a comment

Choose a reason for hiding this comment

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

I'm planning on merging once a test of the stdenv completes, even though I'm not sold on the patches approach.

# TODO: stdenv’s setup.sh should be aware of patch directories. It’s very
# convenient to keep them in a separate directory but we can defer listing the
# directory until derivation realization to avoid unnecessary Nix evaluations.
patches = lib.filesystem.listFilesRecursive ./patches;
Copy link
Contributor

Choose a reason for hiding this comment

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

As I wrote on #335579, I sort of love the old approach where the patches are just listed out. I'm willing to hear the case, but my "do the most simple thing" grugbrain triggers when there's magical patch application.

I'm willing to experiment, though.

Comment on lines +6 to +9
Purity: don't look for library dependencies (of the form `-lfoo') in
/lib and /usr/lib. It's a stupid feature anyway. Likewise, when
searching for included Makefiles, don't look in /usr/include and
friends.
Copy link
Contributor

Choose a reason for hiding this comment

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

This was taken from the comment in the Nix file (and I appreciate it here!)

@philiptaron philiptaron merged commit b50a4a2 into NixOS:staging Aug 19, 2024
24 of 26 checks passed
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.

5 participants