<matthewbauer>
Hey if anyone is able to look at https://github.com/NixOS/nixpkgs/issues/41906 that would be great! We cannot figure out why macOS -> iOS cross compilation is broken for C++ programs.
bbarker has quit [Ping timeout: 264 seconds]
matthewbauer has quit [Ping timeout: 256 seconds]
disasm has joined #nixos-dev
matthewbauer has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
__Sander__ has quit [Quit: Konversation terminated!]
<gchristensen>
Sonarpulse: ^
<copumpkin>
I think shlevy knows about it too
<copumpkin>
or did at some point
<niksnut>
samueldr: thanks, merged
<samueldr>
thanks!
<niksnut>
copumpkin: so the issue here is that when doing "nix copy .drv', it's ambiguous whether you want to copy the .drv file or the paths built by it
<copumpkin>
nix copy --include-drvs perhaps ? :)
<gchristensen>
hmm doesn't seem ambiguous to me, since the .drv and the outputs have different closures and different meanings
<niksnut>
sure, but then we reintroduce all the warts of the old interface
<copumpkin>
but I haven't looked at dtz's PR yet
<gchristensen>
oh
<niksnut>
for instance, nix-copy-closure has a --include-outputs option
<copumpkin>
I don't think including flags for optional behavior is necessarily a wart
<gchristensen>
is it ambiguous though?
<copumpkin>
I think nicely categorized bundles of behavior are the main benefit of the new UI/UX
<copumpkin>
not fewer options
<copumpkin>
I also think, sad as it may be, that "feeling modern" is another major improvement in the new UI :)
<copumpkin>
even if it's just reskinning the old functionality
<copumpkin>
or to put it differently, not feeling like `rpm`
<gchristensen>
can we examine a moment if it really actually is ambiguous?
<joepie91>
general rule of thumb: the amount of flags needed for a command should be inversely proportional to how commonly it is needed
<joepie91>
adhering to that rule gets you 90% of the way to a good command-line interface :P
<copumpkin>
gchristensen: I don't think it has to be, although our treatment of .drv paths isn't super consistent I think
<niksnut>
gchristensen: it's ambiguous in the sense that there are multiple reasonable expectations of what it should do
<gchristensen>
I guess I don't agree, but I believe you
<niksnut>
gchristensen: what would you expect 'nix copy .drv' to do?
<gchristensen>
copy the .drv and its closure to the target machine so I can nix-build it over there
<niksnut>
right
<niksnut>
however, then 'nix copy' might be inconsistent with (say) 'nix build' which does dereference .drv files (I think)
<niksnut>
but maybe that's okay
<gchristensen>
nix build is taking drv and turning it in to built result, I think that is probably okay
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<matthewbauer>
anyone have objections to merging staging into master? they've already diverged enough for both to be mass rebuilds & i'd like to speed it up
<gchristensen>
LnL: ^
<gchristensen>
we shouldn't be using master as a last resort way to stabilize staging
<niksnut>
'nix build' also substitutes store paths, so it's ambiguous whether 'nix build .drv' should substitute the .drv file or build it
<gchristensen>
niksnut: :D you might be right. I suspect samueldr has good ideas here
<LnL>
I really don't want to end up in the state of 2 merges back again
<matthewbauer>
well if they diverge too much we end up overloading the build farm with two trunks. staging is such a low priority that it will take a long time otherwise to "stabilise"
<samueldr>
gchristensen: would I?
<samueldr>
I'm assuming someone else as I'm not entirely sure what .drv are under the hood!
<gchristensen>
I think you have a good handle on usability, is all
<samueldr>
oh, thanks
<LnL>
matthewbauer: but we can prepare another merge, there's nothing particularly scary in the diff last I checked
<samueldr>
reading a bit about .drv, and looking at what was said, I'd tend to agree with you gchristensen, I would assume a `nix copy some.drv` to not dereference (do the build/download from cache and copy the output); a end-user of the CLI probably intended to pass the .drv and not the output
<samueldr>
though, it all depends of the use case of copying derivations
<copumpkin>
or we could make a distinction between `nix build` and `nix realise` :P
<copumpkin>
and have nix build refuse .drvs :)
<samueldr>
yeah, it all depends of the current behaviour and expected behaviour of building .drv
<samueldr>
id `nix build some.drv` equivalent to `nix build would-output-that-drv.nix`?
<samueldr>
oh, I see the ambiguousness, I think, where `nix build /nix/store/0d60i73mcv8z1m8d2m74yfn84980gfsa-nix-2.0.4` realizes it
<gchristensen>
now _that_ seems really weird
<samueldr>
I would think too
<samueldr>
since for a given /nix/store/some.drv, should it realize it or should it build what it represent?
<gchristensen>
IMO nix build is a transmute, taking a buildable and build-or-substituting it
<gchristensen>
but /nix/store/0d60i73mcv8z1m8d2m74yfn84980gfsa-nix-2.0.4 isn't buildable, so it shouldn't go find it
<copumpkin>
if you want that sort of magic, reach for nix-store -r then?
<copumpkin>
or a separate command?
<gchristensen>
exactly
<copumpkin>
nix substitute <path>
<copumpkin>
will tell you if <path> is in the binary cache and get it for you?
<samueldr>
would it make sense that anything on the FS be kind of a "tangible" input, while things like unknown store paths not be tangible things, so that nix build only acts on tangible inputs? where nix build cannot act if there is intangible inputs?
<samueldr>
or whatever the already established nomenclature if there is
<gchristensen>
that seems hard to understand
<gchristensen>
as written :)
* samueldr
needs a better brain to computer interface
<samueldr>
what would you call files that are in the FS, or already present in the store?
<samueldr>
and what would you call a path that could be in the store, but isn't necesarily?
<gchristensen>
magic waiting to be applied
<samueldr>
:)
<samueldr>
the issue may be that the `nix build` shouldn't rely on magic, and realize handle the magic?
<samueldr>
if it is known that `build` doesn't rely on magic, then a `/nix/store/some.drv` can only mean one thing
<gchristensen>
I like substitute best, since "realize" is a bit weird
<gchristensen>
but with substituting a path you don't have, you're creating something from nothing, hardly substituting
<samueldr>
`nix magix /nix/store/some-path` :) you can magic a path out of nothing
<samueldr>
which is apt, since niks → nix
{^_^} has quit [Remote host closed the connection]
<Drakonis>
mesa's libgl got proxied, which is nice.
<Drakonis>
anyways i gotta go.
Drakonis has quit [Remote host closed the connection]
<dtz>
haha from the libcapsule README: "In an ideal world, you would never want this."
<dtz>
xD
<Dezgeg>
maybe it means that in an ideal world Unix DSOs would work like Windows DSOs x)
<copumpkin>
I can't tell, is libcapsule purely re-exporting other symbols from other libraries
<copumpkin>
it sounds like some native functionality inside mach-o files if so
<Dezgeg>
no, it's not a pure re-export; it also means that your libGL.so gets to link against the specific libstdc++.so that the libGL needs, and the application can still have its own different libstdc++.so
<copumpkin>
ah
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
{^_^} has joined #nixos-dev
<rycee>
Hmm, am I confused somehow or is `nix build` not printing the output path?
matthewbauer has quit [Read error: No route to host]
<rycee>
For example, `nix-build '<nixpkgs>' -A sl --no-out-link` prints the path on stdout while `nix build -f '<nixpkgs>' sl --no-link` doesn't.
<rycee>
Ah, I need `nix eval`?
<dtz>
you're not confused, `nix build` doesn't print output paths
phreedom has quit [Write error: Connection reset by peer]
phreedom has joined #nixos-dev
<gchristensen>
one thing I do and very much like to do is nix-instantiate an expression locally, copy the drvs over to a build host, build there, then copy from that host to a third host
<LnL>
I used nix-copy-closure with a drv a lot before --store ssh-ng://foo
<clever>
does --store ssh-ng://foo allow using a local nix expression but an entirely remote store?
<LnL>
yes
<clever>
nice
<LnL>
there's one edgecase that doesn't work IIRC
orivej has joined #nixos-dev
<LnL>
ah right, tar: Error opening archive: Failed to open '/nix/store/af6qlx0vqwx76hh5hvzdi6gh66phnj7l-source'
<clever>
thats an odd one
<LnL>
either with ifd it tries to read that locally instead of remote
<LnL>
or there's something with special about my PATH in this context because I use command=
<LnL>
careful with --out-link and multiple outputs
<LnL>
but you're probably fine in this case
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 240 seconds]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
<Sonarpulse>
LnL: any idea why llvm depends on libcxxabi on Darwin?
matthewbauer has quit [Ping timeout: 276 seconds]
<LnL>
not sure
matthewbauer has joined #nixos-dev
jtojnar has quit [Ping timeout: 248 seconds]
jtojnar has joined #nixos-dev
<Sonarpulse>
LnL: I'll just try
<LnL>
I think you asked before, did you ping dtz?
<dtz>
I'm not sure how that even works since libcxxabi depends on llvm :D. But you definitely need (IIRC) some libcxx to build LLVM on darwin.... but why the stdenv's copy isn't good enough? no idea
<Sonarpulse>
LnL: hehe I asekd about why compile-rt depends on llvm!
<Sonarpulse>
and indeed for some reason both libcxxabi and libcxx need the llvm source
<Sonarpulse>
who the hell knows why
<Sonarpulse>
and then llvm on darwin is given build libcxxabi
<LnL>
don't know much about clang internals like that
<LnL>
but we do some juggling with libcxx/libcxxabi in the stdenv bootstrap IIRC
<Sonarpulse>
LnL: yeah that's what I am looking it
<Sonarpulse>
how to make sure cross stuff doesn't get rid of it
<Sonarpulse>
I don't know how llvm uses libcxx abi
<Sonarpulse>
so not really sure how it ought to be done
<LnL>
dtz: oh but, the clang/llvm 6 update fails with allowedReferences
<LnL>
I should really move the cmake/libxml overrides to the stdenv phases...
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
<Sonarpulse>
LnL: I'm currently building llvm 6 *without* libcxxabi
<Sonarpulse>
to check my hypothesis that it is just some bootstrapping thing
<Sonarpulse>
not needed for non-bootstrap llvmPackages
<Sonarpulse>
LnL: and btw i just did a PR making llvmPackages llvmPackages_6 in bootstrapping
<Sonarpulse>
it's important that we don't override (including persist) the originals, not aliases
<Sonarpulse>
unless we actually wish for them to be distinct
<LnL>
you mean 5 -> 6 or bootstrap 6 without 5
matthewbauer has quit [Ping timeout: 256 seconds]
<orivej>
Could someone restart the aborted jobs in https://hydra.nixos.org/eval/1463373 ? (They were cancelled as part of the mass rebuild evaluation.)
<LnL>
done
<orivej>
thanks!
<orivej>
Sonarpulse: If that helps, I know that libcxx requires one of this so called runtimes to implement C++ stdlib: libcxxabi (an LLVM project), libcxxrt (a Pathscale project) or glibcxx (a part of glibc?): https://github.com/llvm-mirror/libcxx/blob/204d5ec7/src/exception.cpp
<orivej>
…one of these…
<orivej>
glibcxx is probably not used on Darwin, this is why it may depend on libcxxabi
<Sonarpulse>
orivej: true, but we build libcxx separately
<Sonarpulse>
from llvm
<Sonarpulse>
(both libcxx and libcxxabi are built separately, but each sees each other's sources)