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>
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>
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>
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
Work in progress cross compiler for x86_64. I've managed to get a full x86_64 gcc using the binaries built from foundation, and am working on implementing their builds into tidepool.
### Bootstrapping steps
0) Start with i686 tools (gcc, binutils, musl, etc)
1) Build binutils targeting x86_64-linux
2) Build a minimal gcc cross compiler using the cross binutils. This minimal cross compiler does not have support for libc, so is pretty much only useful for building musl or glibc.
3) Use the minimal cross compiler to build x86_64-linux glibc or musl
4) Now that we have a cross compiler and x86_64-linux libc, we can build gcc for the target architecture!
5) Profit! We can now build anything x86_64 using our gcc compiler!
Co-authored-by: Jake Hamilton <jake.hamilton@hey.com>
Reviewed-on: #8
Reviewed-by: Jake Hamilton <jake.hamilton@hey.com>
Co-authored-by: Victor Fuentes <vmfuentes64@gmail.com>
Co-committed-by: Victor Fuentes <vmfuentes64@gmail.com>
