Commit Graph

24752 Commits

Author SHA1 Message Date
github-actions[bot]
81f60ef90d Merge master into staging-next 2024-11-11 00:14:46 +00:00
Peter Waller
51ba14b167 llvmPackages: Make targetLlvmLibraries overridable
Pull #320261 introduced the possibility to consistently override
dependencies within an llvm package set. This is useful for development
and testing exotic configurations.

Go one step further and enable overriding targetLlvmLibraries.

This makes it possible to write an overlay such as:

```nix
overlays = [
  (self: super: {
    llvmPackages = super.llvmPackages.override (prev: {
      targetLlvmLibraries = super.targetPackages.llvmPackages.libraries // {
        compiler-rt = super.targetPackages.llvmPackages.libraries.compiler-rt.override {
          ...
        }
      };
    });
  })
];
```

... where the overridden compiler-rt will be used in a pkgsLLVM build.

As a straw man, I've done the minimally invasive thing to the code
structure: `targetLlvmLibraries` is not an explicitly named parameter
for llvmPackages; but it is available in `packageSetArgs` if passed.
This makes it slightly less discoverable, but this seems like a
reasonable tradeoff considered that modifying this would be a fairly
advanced/esoteric thing to need to do.

In some ways it would be better to have as an explicit parameter with a
default, but the obvious thing won't work because the default needs to
be a non-trivial expression. Potentially we could instead have it as a
defaulted parameter with the value of 'null', and if it's null, then
compute the current thing.

Signed-off-by: Peter Waller <p@pwaller.net>
2024-11-10 14:31:35 +00:00
Victor Engmark
106ba63900 tree-wide: Indent .bash files like .sh 2024-11-10 14:52:08 +13:00
aucub
a2143e6870 dart.flutter_volume_controller: init 2024-11-10 05:40:39 +08:00
aucub
da4bf61402 dart.fvp: init 2024-11-10 05:35:55 +08:00
Artturin
74dd18743f openjdk: Fix cross for most versions (#353952) 2024-11-09 21:21:20 +02:00
Tomo
c04d7170e0 team-list: establish java team
As discussed in #jdk:nixos.org on Matrix, the maintainers of the
Java ecosystem in Nixpkgs feel that a team for Java would be helpful.
2024-11-09 18:26:59 +00:00
github-actions[bot]
9d10d593cf Merge staging-next into staging 2024-11-09 15:14:38 +00:00
github-actions[bot]
a90280100f Merge master into staging-next 2024-11-09 15:14:08 +00:00
Peter Waller
cdefc40e99 llvmPackages.*: Expose git rev through pkg.src.rev
Also exposes owner, repo, and other attributes available on the original
monorepoSrc. These attributes were previously hidden behind a
runCommand that consumes monorepoSrc and hides this information away.

```
$ nix eval --raw .#llvmPackages_18.llvm.src.rev
llvmorg-18.1.8

$ nix eval --raw .#llvmPackages_git.llvm.src.rev
0e8555d4dbfdfeddc01dc2ecf9a9b6e804f7b645
```

Signed-off-by: Peter Waller <p@pwaller.net>
2024-11-09 15:12:56 +00:00
alexfmpe
04f72b6930 ispc: 1.25.0 -> 1.25.3 (#354585) 2024-11-09 14:50:30 +00:00
Emily
6da79a4528 Merge staging-next into staging 2024-11-09 12:55:34 +00:00
Emily
ce788776a5 Merge master into staging-next 2024-11-09 12:51:01 +00:00
aleksana
571c71e6f7 treewide: migrate packages to pkgs/by-name, take 1
We are migrating packages that meet below requirements:

1. using `callPackage`
2. called path is a directory
3. overriding set is empty (`{ }`)
4. not containing path expressions other than relative path (to
makenixpkgs-vet happy)
5. not referenced by nix files outside of the directory, other
than`pkgs/top-level/all-packages.nix`
6. not referencing nix files outside of the directory
7. not referencing `default.nix` (since it's changed to `package.nix`)
8. `outPath` doesn't change after migration

The tool is here: https://github.com/Aleksanaa/by-name-migrate.
2024-11-09 20:04:51 +08:00
Emily
40a6c76e11 llvmPackages_12: build from monorepo source (#348568) 2024-11-09 06:11:58 +00:00
github-actions[bot]
4a61ce1626 Merge staging-next into staging 2024-11-09 00:14:21 +00:00
github-actions[bot]
f3327c0d2a Merge master into staging-next 2024-11-09 00:13:55 +00:00
sternenseemann
37437849de llvmPackages_12.clang: use nostdlibinc patch instead of sed command
Seems like the patch we've written for LLVM 13 and above also works for
LLVM 12 which seems a little more robust.
2024-11-08 23:31:05 +01:00
sternenseemann
8408b91e8d llvmPackages_12.compiler-rt: move codesign patch into versioned dir
All LLVM versions < 12 have been removed, so this patch can live in the
versioned directory, simplifying the patch list in the process.
2024-11-08 23:30:29 +01:00
sternenseemann
ee9eacf23e llvmPackages_12: build from monorepo source
As mentioned in #305146, keeping LLVM 12 is a source of pain because it
is the only version to be built from individual release tarball instead
of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo
as well, simplifying all common LLVM expressions in the process.

With #347887, some quirks in the expressions for LLVM <14 were ironed
out, so building LLVM through from the monorepo is quite simple now.

- Most expressions only required minor changes, mostly removing the
  special casing for `sourceRoot`.

- The patch lists from llvm/12/default.nix were ported to
  common/default.nix. This only required a few extra conditionals which
  could be reduced via a rebuild also involving other LLVM versions.
  Outstanding tasks of little urgency have been noted in TODO comments.
  I have verified that the patch lists stay the same for all packages
  except LLVM where merely the order changes. An extra set of eyes
  is appreciated, of course.

- clang: The expression was reworked to use the same symlink location
  for clang-tools-extra for all versions including LLVM 12. This
  required adjusting the ad hoc patching of the clangd cmake files
  slightly.

- libunwind: We no longer need to make the libcxx sources available
  manually. We can rely on the monorepo source instead.

- lld: We no longer need to make the libunwind sources available manually.

- llvm: We no longer need to make the polly sources available manually

- On Darwin, we need to bypass CMake's C++ compiler for libcxx and
  libunwind now. It isn't a 100% clear why, probably because we've
  started to use Darwin's bootstrapStdenv for libcxx in the common
  expression compared to LLVM 12 on master [1].
  The reordering of flags for wasm causes a rebuild for some packages
  like firefox, but this should be tolerable on staging.

[1]: 665ebfb253/pkgs/development/compilers/llvm/12/default.nix (L392-L430)
2024-11-08 23:30:20 +01:00
sternenseemann
ce6c31c312 llvmPackages_{12,13}.lldb: don't try to find nonexistent patch
We just need to make sure the attribute evaluates so we can cleanly
access `meta.broken` for those versions.
2024-11-08 23:19:52 +01:00
Alexandre Esteves
1754ed842e ispc: 1.25.0 -> 1.25.3 2024-11-08 20:26:05 +00:00
alexfmpe
8e8f317319 ispc: 1.24.0 -> 1.25.0 (#350090) 2024-11-08 20:20:05 +00:00
Artturin
fc46586422 openjdk: Fix cross for most versions
`jdk8` cross still broken

Using `__spliced.depsBuildBuild` to reduce rebuilds/space usage because it does not seem to matter if
it's that or `buildHost`

`depsBuildBuild` `configure: error: Could not find required tool for BUILD_CC`

`zlib` in `nativeBuildInputs`

```
/build/source/src/java.base/share/native/libzip/Adler32.c:33:10: fatal error: zlib.h: No such file or directory
   33 | #include <zlib.h>
      |          ^~~~~~~~
compilation terminated.
make[4]: *** [lib/CoreLibraries.gmk:88: /build/source/build/linux-aarch64-server-release/buildjdk/support/native/java.base/libzip/Adler32.o] Error 1
make[4]: *** Waiting for unfinished jobs....
/build/source/src/java.base/share/native/libzip/CRC32.c:32:10: fatal error: zlib.h: No such file or directory
   32 | #include <zlib.h>
      |          ^~~~~~~~
compilation terminated.
/build/source/src/java.base/share/native/libzip/Deflater.c:35:10: fatal error: zlib.h: No such file or directory
   35 | #include <zlib.h>
      |          ^~~~~~~~
compilation terminated.
make[4]: *** [lib/CoreLibraries.gmk:88: /build/source/build/linux-aarch64-server-release/buildjdk/support/native/java.base/libzip/CRC32.o] Error 1
make[4]: *** [lib/CoreLibraries.gmk:88: /build/source/build/linux-aarch64-server-release/buildjdk/support/native/java.base/libzip/Deflater.o] Error 1
make[3]: *** [Main.gmk:191: java.base-libs] Error 2
make[2]: *** [make/Main.gmk:589: create-buildjdk-interim-image] Error 2
make[2]: *** Waiting for unfinished jobs....
ERROR: Build failed for target 'images' in configuration 'linux-aarch64-server-release' (exit code 2)
Stopping javac server
```
2024-11-08 21:59:38 +02:00
Martin Weinelt
46b1474255 Reapply "haskellPackages: update stackage and hackage" (#354547)
This reverts commit 7701a9e6c6, reversing
changes made to 8991dc8e9d.

Restore haskell-updates on staging-next to save resources on hydra.
2024-11-08 18:42:24 +01:00
Martin Weinelt
2900723943 Merge remote-tracking branch 'origin/master' into staging-next 2024-11-08 18:40:48 +01:00
Vladimír Čunát
fe6d94b8f9 Revert "haskellPackages: update stackage and hackage" 2024-11-08 18:36:29 +01:00
Peter Waller
2c14728202 llvmPackages.compiler_rt: Fix compiler_rt version tests for git
Without these fixes, the git build currently fails because the tests are
out of date.

One is updated since it was fixed upstream, the other is still needed
for the git build, but testing `version` resulted in a test against the
`unstable-*` string and not the one with the version number in it.

Signed-off-by: Peter Waller <p@pwaller.net>
2024-11-08 12:36:25 +00:00
Peter Waller
801a9a90db llvmPackages.libcxx: Include libc sources in input
Without this, after llvm 6c4267fb1779bc5550bb413f33250f9365acfbc6  you
get a build failure because libcxx can't find headers which now live in
the libc tree.

Ref: https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701/18
Ref: 6c4267fb17
Signed-off-by: Peter Waller <p@pwaller.net>
2024-11-08 12:34:51 +00:00
github-actions[bot]
bd6de6fc37 Merge staging-next into staging 2024-11-08 06:05:13 +00:00
github-actions[bot]
4ab3ca7c50 Merge master into staging-next 2024-11-08 06:04:48 +00:00
Zhong Jianxin
8dfed1b9a4 swift: Workaround Hydra darwin build problem
Fail to build with ninja 1.12 when NIX_BUILD_CORES is low (Hydra or Github Actions):

```
ld: warning: directory not found for option '-L/nix/store/g9rbp9m6vs1xj4jl6b6vjb6bm8kgr107-SDKs/MacOSX10.15.sdk/usr/lib/swift'
...
ld: warning: Could not find or use auto-linked library 'swiftCompatibility56'
Undefined symbols for architecture arm64:
  "__swift_FORCE_LOAD_$_swiftCompatibility56", referenced from:
      __swift_FORCE_LOAD_$_swiftCompatibility56_$_Optimizer in libswiftCompilerModules-bootstrapping1.a(Optimizer.o)
  ...
```

Can reproduce using `nix --option cores 2 build -f . swiftPackages.swift-unwrapped`.

Until we find out the exact cause, follow [swift upstream][1], pin ninja to version
1.11.1.

[1]: https://github.com/swiftlang/swift/pull/72989
2024-11-08 12:31:09 +08:00
github-actions[bot]
cb98ce3863 Merge staging-next into staging 2024-11-07 20:49:50 +00:00
github-actions[bot]
3533282a88 Merge master into staging-next 2024-11-07 20:49:24 +00:00
David McFarland
0b1994850e chicken: remove hardening disable (#353966) 2024-11-07 16:01:08 -04:00
Emily
3a6d4d006a treewide: use getLib when accessing clang / libclang / stdenv.cc.cc (#354197) 2024-11-07 18:16:05 +00:00
K900
a3600c0788 Merge remote-tracking branch 'origin/master' into staging-next 2024-11-07 21:06:37 +03:00
sternenseemann
a469250971 haskellPackages: update stackage and hackage (#351154) 2024-11-07 16:40:33 +01:00
John Ericson
e05973a53b lib.systems.doubles: add aarch64-windows double (#335067) 2024-11-07 10:07:40 -05:00
sternenseemann
df930b804c Merge branch master into haskell-updates 2024-11-07 15:03:08 +01:00
github-actions[bot]
b3a0f2d3f1 Merge master into staging-next 2024-11-07 12:05:37 +00:00
Luflosi
d56656e487 yosys: 0.46 -> 0.47
https://github.com/YosysHQ/yosys/releases/tag/0.47

Also mark Synlig as broken as it is currently not compatible with the latest Yosys version.
2024-11-07 12:08:33 +01:00
Sandro
bb9824109f dtc: 1.7.1 -> 1.7.2 (#354154) 2024-11-07 11:47:18 +01:00
Reno Dakota
52bf1163fa treewide: use getLib when accessing clang / libclang / stdenv.cc.cc
In preparation to eliminate the lib output for the unwrapped clang, use
`lib.getLib` to access the `lib` output.
2024-11-07 10:27:41 +00:00
Jörg Thalheim
34abc6ed69 go_1_23: 1.23.2 -> 1.23.3 (#354124) 2024-11-07 11:05:48 +01:00
Joshua Leivenzon
3688e311b4 flutter: Pass flutter_tools package_config.json to Dart runtime 2024-11-07 19:50:37 +11:00
Sergei Trofimovich
793e324096 dtc: 1.7.1 -> 1.7.2
Changes: https://github.com/dgibson/dtc/releases/tag/v1.7.2
2024-11-07 06:58:27 +00:00
github-actions[bot]
8d77160080 Merge staging-next into staging 2024-11-07 06:05:15 +00:00
zowoq
514bd9d740 go_1_23: 1.23.2 -> 1.23.3
Changelog: https://go.dev/doc/devel/release#go1.23
2024-11-07 12:32:29 +10:00
zowoq
5731759a98 go_1_22: 1.22.8 -> 1.22.9
Changelog: https://go.dev/doc/devel/release#go1.22
2024-11-07 12:29:28 +10:00