feat: C template #27
13
c/default.nix
Normal file
|
|
@ -0,0 +1,13 @@
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
{ stdenv, gnumake }:
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
stdenv.mkDerivation {
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
name = "hello";
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
src = ./.;
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
nativeBuildInputs = [ gnumake ];
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
enableParallelBuilding = true;
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
installPhase = ''
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
install -D hello $out/bin/hello --mode 0755
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
'';
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
|
}
|
||||||
```suggestion
```
`make` is in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these instead
```nix
nativeBuildInputs = [ cmake ];
```
```nix
nativeBuildInputs = [ meson ninja ];
```
this is also another reason to use cmake or meson: this phase wouldn't be required ```suggestion
installPhase = ''
runHook preInstall
install -Dm755 hello $out/bin/hello
runHook postInstall
'';
```
this is also another reason to use cmake or meson: this phase wouldn't be required
|
|||||||
17
c/flake.nix
|
|
@ -1,5 +1,5 @@
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
{
|
{
|
||||||
description = "Templates for getting started with Aux";
|
description = "Aux template for C project";
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
inputs.nixpkgs.url = "github:auxolotl/nixpkgs/nixos-unstable";
|
inputs.nixpkgs.url = "github:auxolotl/nixpkgs/nixos-unstable";
|
||||||
we aren't actually updating branches besides master currently ```suggestion
inputs.nixpkgs.url = "github:auxolotl/nixpkgs";
```
we aren't actually updating branches besides master currently
master template use it too. master template use it too.
this should changed as well this should changed as well
This might need it's own dedicated issue This might need it's own dedicated issue
|
|||||||
|
|
||||||
|
|
@ -28,20 +28,11 @@
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
packages = forAllSystems (pkgs: rec {
|
packages = forAllSystems (pkgs: rec {
|
||||||
default = hello;
|
default = hello;
|
||||||
hello = pkgs.stdenv.mkDerivation rec {
|
hello = pkgs.callPackage ./default.nix { };
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
name = "hello";
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
src = ./.;
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
nativeBuildInputs = [ pkgs.gnumake ];
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
enableParallelBuilding = true;
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
V = 1;
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
installPhase = ''
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
install -D ${name} $out/bin/${name} --mode 0755
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
'';
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
};
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
});
|
});
|
||||||
|
|
||||||
|
overlays.default = final: prev: { hello = final.callPackage ./default.nix { }; };
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
apps = forAllSystems (pkgs: rec {
|
apps = forAllSystems (pkgs: rec {
|
||||||
default = hello;
|
default = hello;
|
||||||
hello = {
|
hello = {
|
||||||
|
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
makeis in stdenv, so i'm not sure we need this? also if you were to switch to meson/cmake, this would need to be replaced with one of these insteadthis is also another reason to use cmake or meson: this phase wouldn't be required