<dhess>
LnL: nix-darwin is working great on this Hydra remote builder now!
<dhess>
I skipped the part of the activation script that creates the build user as that doesn't work on 10.13.2, so I created that by hand. But the rest is working perfectly, including the new overlays support.
<dhess>
I think I feel comfortable enough with this now to put it on my other Macs
contrapumpkin has joined #nix-darwin
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
<johnw>
I have it on my main machine and my laptop now
<johnw>
hmm.. ld: unknown option: -mmacosx-version-min=10.10 is biting a perl package build
nkpart has joined #nix-darwin
pjan_ has joined #nix-darwin
<dhess>
johnw: when you installed nix-darwin on your main machine(s), were those already running a multi-user nix setup, or was it single-user?
<johnw>
it was single-user, and then I had to switch them all to multi-user
<dhess>
ok I'm in the same boat. How did you do that? Is there a guide or a gist somewhere?
<johnw>
i ran nix-darwin's bootstrap.sh script
<dhess>
oh that converted it for you?
<dhess>
or did you have to wipe Nix and start from scratch?
<dhess>
well it appears bootstrap.sh doesn't do any single->multi conversion so I guess that didn't do it in any case
<dhess>
I think the new installer supported it at one point (or there was a PR) but it was rejected due to concerns about impurities in the converted store etc.
<pjan_>
It's in the bootstrap script of nix-darwin, @dhess
<acowley>
I glanced at their issue tracker, and it seems like it might be a transient failure
<LnL>
oh!
<LnL>
yeah it is, thought I disabled it with the last update
<acowley>
LnL: Btw, I've semi-automated setup of cquery for C++ development. You may recall how I had talked about needing to dig around NIX_CFLAGS_COMPILE for rtags in the past. It'll work more smoothly once cquery starts tagging releases and I PR this to nixpkgs.
<LnL>
do you know about a tool that can generate a compile_commands.json for non cmake projects?
<acowley>
LnL: bear is a commonly cited one, but I could not get it to work on macOS
<acowley>
LnL: It broke with SIP
<acowley>
so the authors recommend another tool which I also could not get to work
<LnL>
yeah
<LnL>
oh what's the other one?
<acowley>
My cquery packaging now supports two ways of running things: with a compile_commands.json (from eg cmake) or using a .cquery file
<acowley>
The latter just dumps all the needed include flags in a way that cquery can pass to libclang
<acowley>
That approach is arguably worse than a compiler_commands.json since it doesn't give per-source-file flags, but it gets things working in a nix environment.
<acowley>
And I've been working with upstream to make sure the build continues to work under nix. As is usual they accidently break it with some regularity.
<acowley>
All in attempts to make it as smooth as possible for typical users.
<acowley>
I think the issue of people needing to juggle multiple simultaneous installations of LLVM is going to become more and more of a thing over the next year
<acowley>
Oh drats, I've created another situation where I get linker failures
<acowley>
Good old glfw
<acowley>
I should upstream the fix for bindings-GLFW (Haskell) on macOS, but it's kind of a rigamaroll.
<LnL>
dhess: added a warning for distributed builds :)
<dhess>
LnL: good move for dummies like me :)
<johnw>
does anyone here use mod_perl with NixOS?
<dhess>
LnL: this is awesome because I have never been able to get remote builds to work from my Mac before this.
<dhess>
I will try NixOps later today :O
<johnw>
when they work, remote builds are amazing
<johnw>
really cuts down my world-rebuild times
<johnw>
or spreads the load to my other machine if I'm busy on this one
<dhess>
johnw: you said it. Hey did you put localhost in your nix.buildMachines ?
<johnw>
no
<johnw>
I never got that to work
<johnw>
it *does* use my local machine, it just still doesn't prefer it
<dhess>
johnw: does nix-build run anything on your local machine when you have remotes defined in buildMachines?
<dhess>
oh
<LnL>
it's only hydra that won't use the local machine
<johnw>
yes
<dhess>
hmm I did not see that but I wasn't doing a massive build or anything
<dhess>
maybe there just wasn't enough parallelism
<johnw>
I have it set to do 4 jobs on the laptop, 8 jobs on the desktop
<johnw>
right, dependencies may block parallelism
<johnw>
the new "nix build" shows it the best, when rebuilding the world
<johnw>
there is a bold number in green that shows the current number of active jobs
<dhess>
johnw: what do you have buildCores set to?
<johnw>
cores is 1
<dhess>
yeah that is where I ended up as well
<johnw>
I have too many builds that unpredictably fail when run parallel
<johnw>
there should be a better relationship between jobs and cores
<dhess>
yeah it should be more dynamic
<johnw>
right now you have to balance between them, which is always bad
<dhess>
yes
<LnL>
orivej made a pr that improves that recently I think
<johnw>
because if jobs is 2 and cores 2, and you have a bunch of single-threaded builds all of a sudden, now you're not using half your machine
<dhess>
johnw: are you running nix 1.12 then?
<johnw>
yes, 1.12
<johnw>
right now mod_perl is kicking my ass :(
<dhess>
on macOS or NixOS or both?
<johnw>
just on macOS right now
<LnL>
it makes builds look at loadavg to avoid using more than available
<johnw>
on NixOS (which I use for servers) I tend to be much more stable
<johnw>
LnL: nice!
<dhess>
any issues you have seen so far? (I am inferring that this mod_perl issue is related?)
<johnw>
what I'd like is a capability pool
<johnw>
i.e., my machine has 8 virtual cores
<johnw>
so, jobs + cores should always try to reach 8
<johnw>
but should shift the allocation dynamically
<johnw>
is anyone else seeing "ld: framework not found Cocoa"?
<johnw>
this problem has come and gone for me, but now I'm completely stuck on it
szicari has quit [Quit: szicari]
<dhess>
johnw: no, which package?
<LnL>
yeah where? I did change propagatedness for the frameworks of mercurial/rust recently
<mitchty>
johnw: in that case i'd want a max of 4, those hyperthreaded processors tend to perform worse most of the time
<mitchty>
in my experience, it can vary, but then you can get down clocking etc... depending on the core usage
<mitchty>
of course i might be too embedded in junk like knc etc.. that is super weird
<johnw>
dhess: right now, building something local for which i use cabal configure and cabal build; it doesn't happen when I'm just building within Nix