This option was causing some compilation faliures. I want to address the root cause being foundation libstdc++ being broken, but for now let's avoid broken builds.
Reviewed-on: #41
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Co-committed-by: Victor Fuentes <vlinkz@snowflakeos.org>
Using `.extend` function causes nix to not cache the evaluation of a package (`a.extend {} != a.extend {}` ). In effect this meant that every time we used
```
gcc-cross = packages.foundation.gcc.versions."13.2.0-stage2".extend {
settings.target = config.platform.host;
};
binutils-cross = packages.foundation.binutils.versions."2.41-stage1".extend {
settings.target = config.platform.host;
};
```
we were performing full re-evaluations of binutils and gcc. To make this worse, since binutils and gcc depend on other binutils and gcc (sometimes with this `.extend`), the amount of evaluations would start to blow up.
Before this patch evaluating `packages.foundation.gcc.latest.packages.x86_64-linux.x86_64-linux.package` would evaluate `binutils` stage1 139 times, after this patch (and before target patch) it's 4.
Reviewed-on: #40
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Co-committed-by: Victor Fuentes <vlinkz@snowflakeos.org>
A friend was looking at tidepool, and was confused when these were deadlinks.
Reviewed-on: #37
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: dawnofmidnight <dawnofmidnight@duck.com>
Co-committed-by: dawnofmidnight <dawnofmidnight@duck.com>
This way, the binaries glibc builds will actually get linked to our libc.so at runtime, instead of the system one.
Reviewed-on: #36
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: Piper McCorkle <contact@piperswe.me>
Co-committed-by: Piper McCorkle <contact@piperswe.me>
WIP. Posting just to make sure people know this is something I'd like to do.
Context: https://matrix.to/#/!PvnunzXUk4Vm1CmKS4:auxolotl.org/$bOm6iaBpWbo-KRJgo7FUZdeFIv9StzRHxklbx7OQ23g?via=auxolotl.org&via=matrix.org&via=catgirl.cloud
Reasons:
1. Why should GCC inflict complication upon all of tidepool just because of its own architectural deficiencies?
2. Most other compilers are multi-target so it doesn't matter
2. Target is useless for 99.9% of packages and only leads to user confusion, especially since many compilers also call what would be host here "target".
3. Canadian-cross is not very well supported. GCC barely supports it, and is broken in many cases. Nixpkgs does not support it (regardless of what its API may imply) and no one has ever complained.
Plan:
1. Remove most target related things. No reason to have it.
2. Add configuration parameter on GCC that selects its target
What does this mean:
This basically moves target to be a GCC-specific artifact rather than an official parameter every package must endure the cognitive load of. This is because it is. Nixpkgs plans on dumping target in the future as well because of this. Or at least making it an alias.
If you want to create a compiler with a different target, then override GCC to do so. No need to pervade all of tidepool just for GCC.
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Reviewed-on: #31
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: Ross Smyth <snix@treefroog.com>
Co-committed-by: Ross Smyth <snix@treefroog.com>
Use builtins and aux `lib.fp.id` instead of nixpkgs functions for `lib.systems.validate.compatible`.
Reviewed-on: #35
Reviewed-by: Ruby Iris Juric <ruby+auxolotl@srxl.me>
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Co-committed-by: Victor Fuentes <vlinkz@snowflakeos.org>
https://ftp.gnu.org is very, *very* slow. From the [GNU downloads page](https://www.gnu.org/prep/ftp.en.html):
> [...]please try to use one of the many mirrors of our site listed below: the mirrors will give you faster response. [...] You can use the generic URLs https://ftpmirror.gnu.org and http://ftpmirror.gnu.org to automatically choose a nearby and up-to-date mirror.
Indeed, in my experience the mirrors are much faster. I don't see a reason we shouldn't default to them personally, so I've changed the default here.
Also see: auxolotl/foundation#8
Reviewed-on: #26
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: Ruby Iris Juric <ruby@srxl.me>
Co-committed-by: Ruby Iris Juric <ruby@srxl.me>
This is very far from perfect, but it lays some groundwork to Tidepool
documentation. This follows my (very limited) understanding, and so is
very much incomplete and WIP. I would like some help with the concepts I
haven't quite understood <3
Reviewed-on: #18
Reviewed-by: Jake Hamilton <jake.hamilton@hey.com>
Co-authored-by: KFears <kfearsoff@gmail.com>
Co-committed-by: KFears <kfearsoff@gmail.com>
Before this, a value that does not correspond to an attribute under a
package alias' `versions` would make it default to the latest as defined
by `lib.packages.getLatest`, which isn't a silver bullt: it choose
"bash5.2.15-bootstrap" for instance instead of stage1-passthrough (and I
don;t think we have an easy fix for that).
Given values like `"1.2.3"` makes little sense in
`config.preferences.packages.version` (because it's a package-set-wide
preference), this means it was hardly ever useful.
before:
```console
❯ nix eval -f tidepool --apply 't:
t.extend {modules = [{config.preferences.packages.version = "latest";}];}
|> (t: t.config.lib.packages.resolve t.config.packages.foundation.bash)
|> (p: p.version)'
"5.2.15-bootstrap"
❯ nix eval -f tidepool --apply 't:
t.extend {modules = [{config.preferences.packages.version = "stable";}];}
|> (t: t.config.lib.packages.resolve t.config.packages.foundation.bash)
|> (p: p.version)'
"5.2.15-bootstrap"
```
after:
```console
❯ nix eval -f tidepool --apply 't:
t.extend {modules = [{config.preferences.packages.version = "latest";}];}
|> (t: t.config.lib.packages.resolve t.config.packages.foundation.bash)
|> (p: p.version)'
"5.2.15-stage1-passthrough"
❯ nix eval -f tidepool --apply 't:
t.extend {modules = [{config.preferences.packages.version = "stable";}];}
|> (t: t.config.lib.packages.resolve t.config.packages.foundation.bash)
|> (p: p.version)'
"5.2.15-bootstrap"
```
Co-authored-by: austreelis <git@swhaele.net>
Reviewed-on: #33
Reviewed-by: Ruby Iris Juric <ruby+auxolotl@srxl.me>
Co-authored-by: Austreelis <austreelis@noreply.git.auxolotl.org>
Co-committed-by: Austreelis <austreelis@noreply.git.auxolotl.org>
Untested, but should fix#28?
Reviewed-on: #29
Reviewed-by: Ruby Iris Juric <ruby+auxolotl@srxl.me>
Co-authored-by: Steve Dee <steved424@gmail.com>
Co-committed-by: Steve Dee <steved424@gmail.com>
Difference in license attrset schema between lib and tidepool caused eval fails, as in [here](https://hydra.aux-cache.dev/jobset/aux/tidepool#tabs-errors).
This PR changes tidepool's scheme to align it with lib:
```console
❯ nix eval -f tidepool packages.foundation.bash.latest.meta.license --json | jq
{
"free": true,
"fullName": "GNU General Public License v3.0 or later",
"name": "gpl3Plus",
"redistributable": true,
"spdxId": "GPL-3.0-or-later",
"url": "https://spdx.org/licenses/GPL-3.0-or-later.html"
}
```
I kinda liked the previous schema of tidepool, but it's a lower impact fix than bumping lib's major, and I think we want to think more about licenses in lib (e.g. it would probably make sense to move tidepool's license type there to avoid dupplicating the code for the default behavior).
Co-authored-by: austreelis <git@swhaele.net>
Reviewed-on: #30
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: Austreelis <austreelis@noreply.git.auxolotl.org>
Co-committed-by: Austreelis <austreelis@noreply.git.auxolotl.org>
A lot of misc fixes to foundation packages to better support cross compiling
- Reduce number of gcc stages
- Fix cross compile hooks for gcc, no overrides necessary in stage3 anymore
- Add hooks to zlib
- Fix compiliation for `i686-linux.i686-linux.i686-linux`
Depends on #20
Reviewed-on: #23
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Co-committed-by: Victor Fuentes <vlinkz@snowflakeos.org>
See comment in `tidepool/src/lib/fetchurl.nix` for details on rationale.
I've made this a function in `lib` instead of defining this as a builder, since we don't have a great mechanism at the moment for specifying the source of a package as another package. We'll need to tackle this eventually, but given that this is a bit of a special case in that it's only intended to be used to fetch sources during bootstrap, I think it's fine to just have this be a function that returns a derivation, instead of being a full builder. Open to other opinions, though.
Reviewed-on: #27
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: Ruby Iris Juric <ruby@srxl.me>
Co-committed-by: Ruby Iris Juric <ruby@srxl.me>
This PR adds a new way of declaring supported platforms for packages. Previously individual build, host, and target values needed to be set for a given platform combination. Now, a platform spec can be written to generate many platform combinations.
This allows for easy mapping of all possible systems with `@all`, linux systems with `@linux` or any other available alias of `lib.systems.doubles.<alias>` by using `@<alias>`. In addition, you can use `@build` and `@host` to lock either the host or target respectively to match the prior platform.
Reviewed-on: #15
This pr adds initial support for creating a cross-compile tool chain for arbitrary architectures. For now only `aarch64` and `riscv64` are implemented, but simlpy adding another architecture to the list of supported platforms in each package should mostly work with minimal patches.
In order to build native gcc for aarch64, you can run
```
nix-build --expr '((import ./tidepool).packages.foundation.gcc.versions."13.2.0-stage4".package.extend { platform = { build = "aarch64-linux"; host = "aarch64-linux"; target = "aarch64-linux"; }; }).package'
```
or
```
nix-build tidepool -A packages.foundation.gcc.latest.packages.aarch64-linux.aarch64-linux.aarch64-linux
```
Running this command:
- Uses [foundation](https://git.auxolotl.org/auxolotl/foundation) to bootstrap i686 gcc
- Incrementally bootstraps x86_64 gcc from i686
- Runs through the same incremental process, but this time using x86_64 gcc we previously built to bootstrap aarch64
- Build the final native aarch64 gcc
Co-authored-by: Jake Hamilton <jake.hamilton@hey.com>
Reviewed-on: #14
Reviewed-by: Jake Hamilton <jake.hamilton@hey.com>
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Co-committed-by: Victor Fuentes <vlinkz@snowflakeos.org>
people were denied permission to clone aux repos to their store when building
from source if they didn't have an account with a correct local ssh setup.
Co-authored-by: austreelis <git@swhaele.net>
Reviewed-on: #17
Co-authored-by: Austreelis <austreelis@noreply.git.auxolotl.org>
Co-committed-by: Austreelis <austreelis@noreply.git.auxolotl.org>
