<copumpkin>
will fix it up more tomorrow if someone doesn't get to it first
<copumpkin>
the LTO-enabled stdenv is also building right now, but I'm not sure I want to roll it out without releasing a new version of the bootstrap tools (that include libLTO.dylib)
<copumpkin>
or I suppose I could turn off LTO during bootstrap
<copumpkin>
okay, I should sleep
<LnL>
copumpkin: yeah, I think our current bootstrap-tools also won't work on 10.14
<johnw>
if I want a clang that knows where libc++ is, what should I pull in?
<LnL>
copumpkin: but I didn't update it yet because I was wondering if we could clean it up a bit
<johnw>
llvmPackages_6.libcxxStdenv.cc.cc doesn't have the libc++ includes in its -print-search-path
<johnw>
which strikes me as very odd
<LnL>
what context?
<johnw>
trying to use Nix to build Google's V8 engine
<{^_^}>
#41589 (by uri-canva, 13 weeks ago, open): stdenv.cc: use libc++ as default c++ standard library on darwin
<LnL>
libcxxStdenv.cc is a wrapped clang that will find nix dependencies
<LnL>
and the stdenv itself configures libcxx
<johnw>
but as you can see from my reproduction steps above, this is not the case
<johnw>
this should succeed: ls -l $($(nix-store -r $(nix-instantiate --expr 'let pkgs = (import <darwin> {}).pkgs; in (pkgs.wrapCC pkgs.llvmPackages_6.clang).cc.cc') | head -1)/bin/clang++ -print-search-dirs | tail -1 | sed 's/libraries: =//')/include/ctime
<johnw>
well, change that to libcxxStdenv.cc
<johnw>
it fails identically
<LnL>
well no, the stdenv determines what libc++ to use this is just a plain clang
<johnw>
not sure I understand your previous comment then
<johnw>
what attribute do I use to get what I want?
<johnw>
I also tried my command with: pkgs.llvmPackages_6.libcxxStdenv.cc.cc
<nikivi>
inherit (darwin.apple_sdk.frameworks) Foundation ApplicationServices AppKit;
<nikivi>
};
<nikivi>
I get this error now
<nikivi>
❯ nix-build -A watchexec
<nikivi>
error: anonymous function at /Users/nikivi/src/clones/nixpkgs/pkgs/tools/misc/watchexec/default.nix:1:1 called with unexpected argument 'Foundation', at /Users/nikivi/src/clones/nixpkgs/lib/customisation.nix:74:12
<LnL>
nikivi: like the second one, but only inherit the frameworks you need (eg. CoreServices)
<nikivi>
❯ nix-build -A watchexec
<nikivi>
error: anonymous function at /Users/nikivi/src/clones/nixpkgs/pkgs/tools/misc/watchexec/default.nix:1:1 called with unexpected argument 'CoreServices', at /Users/nikivi/src/clones/nixpkgs/lib/customisation.nix:74:12
<LnL>
it only builds stuff, you should have a ./result that points to the build output
<nikivi>
yep I got ./result
<nikivi>
but how can I build locally a package as if I got it from nixpkgs
<nikivi>
or its bad practice?
<nikivi>
so its in my .nix-profile/bin/tree
<nikivi>
or I should manually put it there
<LnL>
you can make nix-env use the local nixpkgs with nix-env -f . -iA watchexec or even install the resulting path you built before directly using nix-env -i ./result
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nix-darwin
<LnL>
btw you should contribute that and ask for a backport :)
<nikivi>
magic
<nikivi>
that worked
<nikivi>
will send PR in a bit
<nikivi>
can you expand on what you mean by a backport here?
<LnL>
for every stable nixos release there's also a corresponding channel for darwin now
<LnL>
these only get security updates and bugfixes and are pretty useful if you just want a working version of something
<LnL>
but 18.09 was only branched recently so this will also be broken there
<nikivi>
why does nixpkgs not have CONTRIBUTING.md
<LnL>
FYI. it's a big hidden if you don't know where to look, but you can change branches in the github ui
<LnL>
bit*
ryanartecona has joined #nix-darwin
philr has joined #nix-darwin
philr has quit [Ping timeout: 272 seconds]
ryanartecona has quit [Quit: ryanartecona]
goodwill has joined #nix-darwin
ryanartecona has joined #nix-darwin
<copumpkin>
LnL: sounds like llvm6 might be too big of a chunk to bite off just yet if there are still unresolved issues, so I might regenerate bootstrap tools on 5
<copumpkin>
which is already version bump since they're currently on 4 :)
<LnL>
yeah that's fine and might fix the stdenv build for 10.14 (and 10.13?)
<LnL>
I did have some questions about it while looking at it a while back