feat: C template #27
2
c/.gitattributes
vendored
|
|
@ -1,2 +0,0 @@
|
||||||
* text=lf
|
|
||||||
* eol=lf
|
|
||||||
63
c/.gitignore
vendored
|
|
@ -1,15 +1,64 @@
|
||||||
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
# binaries
|
# binaries
|
||||||
hello
|
hello
|
||||||
|
|
||||||
# build
|
# language support
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
*.[aod]
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
# config
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
compile_commands.json
|
compile_commands.json
|
||||||
.pre-commit-config.yaml
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
.cache
|
.cache
|
||||||
|
|
||||||
# nix
|
# nix
|
||||||
.direnv
|
.direnv
|
||||||
.envrc
|
result*
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
result
|
repl-result-*
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Prerequisites
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.d
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Object files
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.o
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.ko
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.obj
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.elf
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Linker output
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.ilk
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.map
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.exp
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Precompiled Headers
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.gch
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.pch
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Libraries
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.lib
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.a
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.la
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.lo
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Shared objects (inc. Windows DLLs)
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.dll
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.so
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.so.*
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.dylib
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Executables
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.exe
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.out
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.app
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.i*86
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.x86_64
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.hex
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Debug files
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.dSYM/
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.su
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.idb
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.pdb
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
# Kernel Module Compile Results
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.mod*
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
*.cmd
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
.tmp_versions/
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
modules.order
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
Module.symvers
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
Mkfile.old
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
dkms.conf
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
|
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
this can be commited, as long as it doesn't assume nix is installed. this can work for example ```suggestion
```
this can be commited, as long as it doesn't assume nix is installed. this can work for example
```
if has nix_direnv_version; then
use flake
fi
```
```suggestion
result*
repl-result-*
```
these are all unused ```suggestion
```
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched ```suggestion
```
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched
Only the I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like Only the `.pre-commit-config.yaml` is unused so I'll remove it.
I'm not sure why do you want to include entries unrelated to this template in the gitignore but also removing important ignore like `.cache` or `compile_commands.json` that are useful, it seems like a contradiction?
Committing a Committing a `.envrc` doesn't seems like a good practice to me.
I can remove that entry tho, so it's up to the user to decide was to do i they use direnv
I cant find any public gitignore using I cant find any public gitignore using `repl-result-*`, so it sound like something we may not need
yeah this would be better removed yeah this would be better removed
if you use > I cant find any public gitignore using repl-result-*, so it sound like something we may not need
if you use `:bl` in a repl, you do. this is a known nix artifact, same as `result*`
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either > important ignore like .cache or compile_commands.json
the only reason they are important is because of the specific way you have this set up. other projects are very unlikely to use these, and i would say they shouldn't be used here either
This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other This is the same scenario with the other GitHub ignore you wanted me to include, I think either both should be put or none, because it doesn't seem logic to add one and not the other
|
|||||||
29
c/Dockerfile
|
|
@ -1,29 +0,0 @@
|
||||||
# Credit to Mitchell Hashimoto
|
|
||||||
# post: https://mitchellh.com/writing/nix-with-dockerfiles
|
|
||||||
|
|
||||||
# Nix builder
|
|
||||||
FROM nixos/nix:latest AS builder
|
|
||||||
|
|
||||||
# Copy our source and setup our working dir.
|
|
||||||
COPY . /tmp/build
|
|
||||||
WORKDIR /tmp/build
|
|
||||||
|
|
||||||
# Build our Nix environment
|
|
||||||
RUN nix \
|
|
||||||
--extra-experimental-features "nix-command flakes" \
|
|
||||||
--option filter-syscalls false \
|
|
||||||
build
|
|
||||||
|
|
||||||
# Copy the Nix store closure into a directory. The Nix store closure is the
|
|
||||||
# entire set of Nix store values that we need for our build.
|
|
||||||
RUN mkdir /tmp/nix-store-closure
|
|
||||||
RUN cp -R $(nix-store -qR result/) /tmp/nix-store-closure
|
|
||||||
|
|
||||||
# Final image is based on scratch. We copy a bunch of Nix dependencies
|
|
||||||
# but they're fully self-contained so we don't need Nix anymore.
|
|
||||||
FROM scratch
|
|
||||||
|
|
||||||
# Copy /nix/store
|
|
||||||
COPY --from=builder /tmp/nix-store-closure /nix/store
|
|
||||||
COPY --from=builder /tmp/build/result /app
|
|
||||||
CMD ["/app/bin/hello"]
|
|
||||||
19
c/Makefile
|
|
@ -1,21 +1,12 @@
|
||||||
.POSIX:
|
|
||||||
.SUFFIXES: .o
|
|
||||||
|
|
||||||
CC ?= gcc
|
CC ?= gcc
|
||||||
|
CFLAGS += -pedantic -Wall -Wextra -O2
|
||||||
|
|
||||||
OUT := hello
|
OUT := hello
|
||||||
|
BINDIR ?= /usr/bin
|
||||||
|
|
||||||
SRC += main.c
|
SRC += main.c
|
||||||
OBJ := $(SRC:.c=.o)
|
OBJ := $(SRC:.c=.o)
|
||||||
|
|
||||||
CFLAGS += @compile_flags.txt
|
|
||||||
CFLAGS += -ffunction-sections -fdata-sections
|
|
||||||
|
|
||||||
LDFLAGS := -fwhole-program -flto
|
|
||||||
LDFLAGS += -Wl,--gc-sections -s
|
|
||||||
|
|
||||||
RM ?= rm -f
|
|
||||||
|
|
||||||
.DEFAULT_GOAL: all
|
|
||||||
.PHONY: all
|
.PHONY: all
|
||||||
all: $(OUT)
|
all: $(OUT)
|
||||||
|
|
||||||
|
|
@ -33,3 +24,7 @@ fclean: clean
|
||||||
.PHONY: re
|
.PHONY: re
|
||||||
.NOTPARALLEL: re
|
.NOTPARALLEL: re
|
||||||
re: fclean all
|
re: fclean all
|
||||||
|
|
||||||
|
.PHONY: install
|
||||||
|
install:
|
||||||
|
install -D hello ${BINDIR}/hello --mode 0755
|
||||||
|
|
|
||||||
|
|
@ -1,18 +0,0 @@
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-std=c99
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-pedantic
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-pipe
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wall
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wcast-qual
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wconversion
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Werror=return-type
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Werror=vla-larger-than=0
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wextra
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wmissing-prototypes
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wshadow
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wstrict-prototypes
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-Wwrite-strings
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-O2
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-march=native
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
-mtune=native
|
|
||||||
why assume this? ```suggestion
```
why assume this?
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary ```suggestion
```
there's no reason to use these by default. it will only be confusing if anyone shares a locally built binary
I think that C99 is a very good standard to based a template on I think that C99 is a very good standard to based a template on
most people also aren't using c99 anymore. i feel this is just your personal taste here > i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
most people also aren't using c99 anymore. i feel this is just your personal taste here
|
|||||||
|
|
@ -1,13 +0,0 @@
|
||||||
```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
|
|||||||
{ 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
|
|||||||
29
c/flake.nix
|
|
@ -8,37 +8,20 @@
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
let
|
let
|
||||||
forAllSystems =
|
forAllSystems =
|
||||||
function:
|
function:
|
||||||
nixpkgs.lib.genAttrs [
|
nixpkgs.lib.genAttrs nixpkgs.lib.systems.flakeExposed (
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"x86_64-linux"
|
system: function nixpkgs.legacyPackages.${system}
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"aarch64-linux"
|
);
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"x86_64-darwin"
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"aarch64-darwin"
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"i686-linux"
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"mipsel-linux"
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
"powerpc64le-linux"
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
] (system: function nixpkgs.legacyPackages.${system});
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
in
|
in
|
||||||
rec {
|
rec {
|
||||||
devShells = forAllSystems (pkgs: {
|
devShells = forAllSystems (pkgs: {
|
||||||
default = pkgs.mkShell {
|
default = pkgs.mkShell { inputsFrom = [ packages.${pkgs.system}.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 = { ... }; } { ... } ]`
|
|||||||
hardeningDisable = [ "fortify" ];
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
inputsFrom = pkgs.lib.attrsets.attrValues packages;
|
|
||||||
|
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 {
|
||||||
|
Can we move the package defection to a file called default.nix Can we move the package defection to a file called default.nix
Is there a need to split the flake? it is quite small > Can we move the package defection to a file called default.nix
Is there a need to split the flake? it is quite small
It allows it to have old nix compatibility. that’s the main thing for me. Also prevents redeclaring the package a few times. It allows it to have old nix compatibility. that’s the main thing for me. Also prevents redeclaring the package a few times.
|
|||||||
default = hello;
|
default = hello;
|
||||||
hello = pkgs.callPackage ./default.nix { };
|
hello = pkgs.callPackage ./hello.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 = { ... }; } { ... } ]`
|
|||||||
});
|
});
|
||||||
|
|
||||||
```suggestion
overlays.default = final: prev: {
hello = final.callPackage ./default.nix {};
};
```
What does this do? What does this do?
this allows the user to consume the overlay and it will be added the nixpkgs list. so i could use this allows the user to consume the overlay and it will be added the nixpkgs list. so i could use `enviroment.systemPackages = [ pkgs.hello ];` instead.
doesn't this cause conflict with the nixpkgs's hello pkgs? doesn't this cause conflict with the nixpkgs's [hello](https://github.com/NixOS/nixpkgs/blob/nixos-23.11/pkgs/by-name/he/hello/package.nix#L34) pkgs?
|
|||||||
overlays.default = final: prev: { hello = final.callPackage ./default.nix { }; };
|
overlays.default = final: prev: { hello = prev.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 = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
|
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 {
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
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 = { ... }; } { ... } ]`
|
|||||||
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 = { ... }; } { ... } ]`
|
|||||||
program = "${packages.${pkgs.system}.hello}/bin/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 = { ... }; } { ... } ]`
|
|||||||
type = "app";
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
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 = { ... }; } { ... } ]`
|
|||||||
7
c/hello.nix
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
{ stdenv }:
|
||||||
|
stdenv.mkDerivation {
|
||||||
|
name = "hello";
|
||||||
|
src = ./.;
|
||||||
|
|
||||||
|
env.BINDIR = "${placeholder "out"}/bin";
|
||||||
|
}
|
||||||
17
c/main.c
|
|
@ -1,16 +1,11 @@
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
|
#include <stdio.h>
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
#include <stdlib.h>
|
#include <stdlib.h>
|
||||||
#include <unistd.h>
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
#define lengthof(sstr) (sizeof (sstr) / sizeof *(sstr))
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
#define sstr_len(sstr) (lengthof(sstr) - 1)
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
#define sstr_unpack(sstr) (sstr), (sstr_len(sstr))
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
static const char GREETING[] = "hello, world!\n";
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
|
|
||||||
int main(void)
|
int main(void)
|
||||||
{
|
{
|
||||||
return (
|
char greet[] = "hello, world!\n";
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
write(STDOUT_FILENO, sstr_unpack(GREETING))
|
int written = printf("%s", greet);
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
== sstr_len(GREETING)
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
) ? EXIT_SUCCESS : EXIT_FAILURE;
|
return written == (sizeof(greet) - 1)
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
|
? EXIT_SUCCESS : EXIT_FAILURE;
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
}
|
}
|
||||||
|
|
|
||||||
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
we really don't need to overcomplicate this ```suggestion
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello from Aux!\n");
return 0;
}
```
we really don't need to overcomplicate this
`write` is lighter than `printf`. I think it is better to use it, and i am not sure by what means it is overcomplicated?
I agree with getchoo. I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled. I agree with getchoo.
I think defining macros when it's arguably not needed is overcomplicating it. Also, I think we really don't care about the performance of printf vs write here. Getchoo's suggestion is the canonical hello world C program, it doesn't bring in any header other than stdlib, it doesn't define any item besides main (which you probably need), and it's recognizable so people know they should scrap it anyway.
I feel like the template should focus on nix code, and completely disregard C code (unless it demonstrates something on the nix side). I'd even be fine with an empty source file if that compiled.
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this > write is lighter than printf
>> i feel this is once again putting a lot of focus on what is really just throwaway example code. i would really take a look at https://github.com/NixOS/templates/tree/master/c-hello as a reference
> and i am not sure by what means it is overcomplicated?
i don't think we're really going to get anywhere with this question being asked, so i would rather not continue with this
i genuinely don't get it, but i changed the implementation to use a regular i genuinely don't get it, but i changed the implementation to use a regular `printf`
|
|||||||
|
|
@ -1,4 +0,0 @@
|
||||||
columns = 80
|
|
||||||
sort = "lines"
|
|
||||||
types = ["C", "C Header", "Makefile", "Markdown"]
|
|
||||||
treat_doc_strings_as_comments = true
|
|
||||||
this can be commited, as long as it doesn't assume nix is installed. this can work for example
these are all unused
when using cmake or meson with github's template, these are not necessary as we have a standard build directory and file extensions are already matched