<clever>
Myrl-saki: have you seen the example i recently did?
<clever>
andrewrk: that util is less for packing properly, and more for testing things you dont want to package immediately, but yea, it is nix-speciic
<clever>
(since nix wont know the ELF is using them)
<clever>
as an added benefit, the result pointing to the bash script roots those libraries, so nix cant GC them on you
<clever>
andrewrk: if you then run that bash script on an ELF, it will fix the dynamic linker, and rpath
<clever>
andrewrk: if you nix-build this file, it generates a bash script
<clever>
suzu: so at build-time, you have to either embed $(which pandoc) into your code somewhere (template-haskell, ew!), or generate a bash script that puts the path into a shell script wrapper
<clever>
suzu: runtime deps are detected automatically, based on the subset of build-time paths, that wind up as strings in your output
<clever>
noonien: yep
<clever>
suzu: correct, it will only be in PATH at build-time
<clever>
it was still a boot package though (baked into nix's ghc package)
<clever>
it was a different type, but i cant remember which one
<clever>
dep used 1, shell used a 2nd
<clever>
2 different versions of the same library where in scope
<clever>
suzu: i once ran into a type error, expected Data.String, got Data.String
<clever>
and if things get out of sync, all qt apps break hard
<clever>
QT propagated the libs into ~/.nix-profile if you nix-env things
<clever>
that is also what breaks QT
<clever>
suzu: thats also why i use cabal-install from the same nixpkgs, rather then just nix-env -i it, like others do
<clever>
suzu: yep
<clever>
suzu: but if you use a new cabal field in the cabal file, it will keep working in nix-shell, but then later fail in nix-build with the old cabal
<clever>
suzu: using a newer cabal can sometimes cause weird problems, where it may work in nix-shell and fail in nix-build
<clever>
illegalprime: thats cc-wrapper, a bash script that enforces various things
<clever>
tokudan[m]: i had so many tabs open, that that UI was laggy
<clever>
suzu: vimium, shift+t to search all open tabs by title
<clever>
suzu: regular tabs
<clever>
chromium
<clever>
currently have 840 tabs open
<clever>
i really need to get better at closing my tabs
<clever>
suzu: heh, generic-builder, script-runner, and make-package-set where all open in tabs beside eachother, from the last time i demo'd how this works, lol
<clever>
kai_w: you could just change TMPDIR to /tmp/
<clever>
joko: would need some changes to stage-1.sh, one sec
<clever>
kai_w: why do you need to use a diff dir?
<clever>
yep
<clever>
you could also PR things to move them around
<clever>
CMCDragonkai: its mostly a choice left to whoever wrote the code first and how its planned to be used
<clever>
CMCDragonkai: some of those are used like a replacement to configuration.nix, nix-build '<nixpkgs/nixos>' -I nixos-config=/foo/nixpkgs/nixos/modules/virtualisation/something.nix -A config.system.build.fooImage
<clever>
due to xen breaking 9plan, i had to generate a full disk image (including a valid bootloader and MBR)
<clever>
Ashy: to get that in a shell, nix-shell -p 'ffmpeg-full.overrideAttrs (drv: { configureFlags = drv.configureFlags ++ [ "--enable-libcaca" ]; })'
<clever>
WilliamHamilton[: not sure, definitely sounds like a bug, having a pkgconfig file in z3 might also help, not sure
<clever>
WilliamHamilton[: it still needs the right LDFLAGS to find the static libs
<clever>
yep
<clever>
ghcid is enough to know when i break things
<clever>
thats part of why i havent bothered setting up any more IDE like stuff
<clever>
and you would have to run emacs inside the nix-shell
<clever>
suzu: then `runhaskell Setup.hs && runhaskell Setup.hs build` and maybe `ghcid -c "runhaskell Setup.hs repl"`
<clever>
suzu: nix-shell default.nix -A normal.env
<clever>
yeah
<clever>
i often test with nix-build -A foo && ./result/bin/foo
<clever>
suzu: yep
<clever>
suzu: rm result-1 result-2
<clever>
suzu: when you run nix-build on a set, it creates 2
<clever>
suzu: yeah
<clever>
but ghci wont obey that!, i think i see the issue
<clever>
WilliamHamilton[: cc-wrapper will then forcibly add that, when calling gcc to link things
<clever>
WilliamHamilton[: it should be in things like NIX_LDFLAGS
<clever>
suzu: add result to the .gitignore
<clever>
suzu: if you do src = ./.; then the result symlink will change the source, so every nix-build invalidates the cache by mutating the source
<clever>
WilliamHamilton[: what about `env | grep --color z3`
<clever>
suzu: nix-shell impurely fetches bash from <nixpkgs>
<clever>
nearly all nix commands accept -I
<clever>
then it will reuse the nixpkgs nix-shell is already loading
<clever>
but you could make it slightly faster, with import ./default.nix { inherit pkgs; }
<clever>
to call it with an empty set of args
<clever>
suzu: the default.nix returns a function, so you need import ./default.nix {}
<clever>
suzu: oh, lol, i was reading the error {^_^} gave, not the one you gave!
<clever>
WilliamHamilton[: not sure what else to try there
<clever>
WilliamHamilton[: dont think that will help much, its refering to changes in stack.yaml
<clever>
then nativeBuildInputs may be best
<clever>
suzu: though if your baking its path into something, you can embed the result of $(which foo) at build time
<clever>
suzu: buildInputs would mostly be if you want to run it or link against it, at build time
<clever>
so when you nix-shell -p hello, its just dropping you into a shell with buildInputs = [ (hello) ];
<clever>
suzu: behind the scenes, nix-shell -p is just doing -E, with buildInputs = [ ((import ./default.nix).static) ];
<clever>
suzu: yep
<clever>
suzu: nix-shell -p '(import ./default.nix).static)' for example
<clever>
suzu: yeah
<clever>
suzu: you want either -A normal, -A static, or just replace the set with one of those values directly
<clever>
suzu: if you give nix-build a set, it will build every attribute on it
<clever>
suzu: yay
<clever>
WilliamHamilton[: weird, what about `cabal repl` ?
<clever>
suzu: can you pastebin both the error and the nix file?
<clever>
WilliamHamilton[: what about with just `cabal build`, ignore the new- commands?
<clever>
WilliamHamilton[: i'm not sure the .env attribute supports native libraries, you may need to adjust line 34 to do: (drv.env.overrideAttrs (drv: { buildInputs = drv.buildInputs ++ [ pkgs.z3 ]; }))
<clever>
i'm not entirely sure why the order matters for that, i would have expected it to work either way
<clever>
and a PR should probably be filed, after the changes are confirmed
<clever>
yeah
<clever>
though, if the build is failing, its not in the binary cache anyways
<clever>
but, beam-core then wont have any help from the binary cache
<clever>
and then it will force it to have zero patches
<clever>
similar to how i overrode datadog in extra-statsd, you can do beam-core = pkgs.haskell.lib.overrideCabal super.beam-core (drv: { patches = []; });
<clever>
and that patch in nixpkgs is no longer required
<clever>
suzu: it looks like beam-core upstream have applied the same patch to their source
<clever>
suzu: i did a search on github for beam-core-fix-ghc-8.6.x-build, within the nixpkgs repo