<Mic92>
more a hypothetical question because I assume cross-compilation for this particular package probably requires more work.
ckauhaus has joined #nixos-dev
makefu has joined #nixos-dev
ckauhaus has quit [Quit: Leaving.]
ckauhaus has joined #nixos-dev
ckauhaus has quit []
ckauhaus has joined #nixos-dev
ckauhaus has quit []
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<gchristensen>
it would be interesting to be able to define fixed-output drvs that execute as the user
LangeOortjes has quit [Ping timeout: 252 seconds]
<gchristensen>
like 1.12's fetchGit but without having to extend Nix itself
<gchristensen>
I suppose this is similar to the problems of IFD
orivej has joined #nixos-dev
LangeOortjes has joined #nixos-dev
<gchristensen>
also I suppose this is similar to builtins.exec, which is a bit scary
<gchristensen>
but maybe another mechanism could work better, where nix looks for helper programs in the PATH to do its bidding. this way the special fetchers have to already exist, but allows users to extend their fetchers as required
<gchristensen>
this is a similar model to how teraform works and how the grpc compiler plugins work
<gchristensen>
in this way, we can get perl back out of the nix closure by removing git ;)
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
bgamari has quit [Ping timeout: 256 seconds]
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
bgamari has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
ckauhaus has joined #nixos-dev
romildo has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
<LnL>
niksnut: does the nixos.org hydra evaluator run with any special options like GC_INITIAL_HEAP_SIZE?
<gchristensen>
niksnut: LnL and I are talking about a PR which adds 38*3 packages (QT or something) and pushes nixpkgs over a limit where it can't evaluate anymore on 4 archs without altering the initial heap size. this seems like an "early warning" of something we might want to spend some energy thinking about how to handle it. My inclination is to set the initial heap size for ofborg, but I think we should also do
<gchristensen>
something to help prevent major memory usage jumps in the future. an alternative is to assume that memory will continue to get cheaper, I guess? :) what do you think?
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
ckauhaus has quit [Remote host closed the connection]
ckauhaus has joined #nixos-dev
ckauhaus has quit [Remote host closed the connection]
orivej has joined #nixos-dev
<niksnut>
urgh, the new nix-mode annoys me
<niksnut>
it keeps screwing up my indentation
<__Sander__>
heh
* __Sander__
uses mcedit :D
romildo has quit [Quit: Leaving]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
contrapumpkin has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
ma27 has quit [Ping timeout: 276 seconds]
ma27 has joined #nixos-dev
<Sonarpulse>
Mic92: you want the C compiler this package would use at runtime?
<Sonarpulse>
not so then
<Mic92>
Sonarpulse: then teach me, so I can review code the correct way in future.
<Sonarpulse>
Mic92: sure
<Sonarpulse>
so there are tops **4** c compiler
<Sonarpulse>
Mic92: we classify them by there host and target platforms
<Sonarpulse>
the build platform is an "implementation detail" of the compiler
<Sonarpulse>
build -> build = $CC_FOR_BUILD
<Sonarpulse>
used to build build tools / code gen stuff on the fly
<Sonarpulse>
build -> host = $CC
<Sonarpulse>
build -> target $CC_FOR_TARGET
<Sonarpulse>
^ used to build standard library with compilers
<Sonarpulse>
those three are all used *during* the build
<Sonarpulse>
then there is host->target
<Sonarpulse>
this has no env var
<Sonarpulse>
this is the compiler used by the thing being built *after*
ma27 has quit [Ping timeout: 252 seconds]
<Mic92>
Sonarpulse: what compiler is behind stdenv.cc?
<Sonarpulse>
Mic92: $CC
<Sonarpulse>
buildPackages.stdenv.cc is $CC_FOR_BUILD
<Sonarpulse>
targetPackages.stdenv.cc is $CC_FOR_TARGET
<Sonarpulse>
sorry
<Sonarpulse>
targetPackages.stdenv.cc is the host->target one
<Sonarpulse>
CC_FOR_TARGET needs to be done conditionally
<Sonarpulse>
since build -> target "skips" host
<Mic92>
makefu: ^ we need this secret knowledge in the wiki :)
<Sonarpulse>
you need to rely on them not all being distinct in practice to do the condition
<Sonarpulse>
Mic92: some of it is in the manual :)
<Sonarpulse>
or the cc-wrapper comments :)
<Mic92>
both are not the most accessible forms of documentation.
<Sonarpulse>
:D
<Mic92>
Sonarpulse: if I would capture targetPackages.stdenv.cc in ponyc, this would work for the package after build, but not if I would plan to build a cross compiler with ponyc.
<Mic92>
is there a variable I could you for both?
<Sonarpulse>
Mic92: hmm? targetPackages.stdenv.cc for host->target should be always what you want theree
<Sonarpulse>
assuming ponyCC is just using cc at run time
<Mic92>
Sonarpulse: ok. let's say I would want to use ponyc to cross-compile projects with nix.
<Sonarpulse>
ok
<Sonarpulse>
ponyc has build != host == target
<Sonarpulse>
normal cross compiler
<Sonarpulse>
then the CC passed in also is build != host == target
<Sonarpulse>
and same platforms too
<Sonarpulse>
Mic92: it is correct to wrap with CC = something else, because that $CC is from the perspective of the derivation using ponyc
<Sonarpulse>
not from the perspective of the derivation building ponyc
<Mic92>
Sonarpulse: there is one more thing: the ponyc compiler that is build for the hostPlatform might take both $CC in its build system to build ponyc and take the content of $CC as a compiler used at runtime. So I assume that all compilers/buildsystem needs to be cross-compilation aware then?
<Sonarpulse>
Mic92: yeah, I've never seen a compiler that understood all 4 were distinct
<Sonarpulse>
but if they understand 3
<Sonarpulse>
the three build time ones
<Sonarpulse>
and let you force-override the host->target one
<Sonarpulse>
then its good enough
orivej has quit [Quit: No Ping reply in 180 seconds.]
__Sander__ has quit [Quit: Konversation terminated!]
goibhniu has quit [Ping timeout: 264 seconds]
<ekleog>
Sonarpulse: Hmm, was thinking a bit about having a cross-compiling hydra, and the least wrong solution I found was patching hydra to record the packages as not being cross-compiled but as being natively compiled. Have you already thought about this issue or are you busy enough making things work to not yet have had the time to think about it? :)
<Sonarpulse>
ekleog: hmm? I don't know of hydra needs changes
<Sonarpulse>
maybe I haven't thought about the issue :)
<ekleog>
hmm, I was thinking about the issue of the end-user needing to know the hash of the derivation to retrieve it, thus needing to know the buildPlatform?
<Sonarpulse>
ekleog: oh i see
<Sonarpulse>
right now we do foo.host-system
<Sonarpulse>
like foo.x86_64-linux
<Sonarpulse>
in the attr name
<Sonarpulse>
in release-lib.nix
<Sonarpulse>
I wanted to do foo.host-system.(build-system | native)
<Sonarpulse>
"native" being the magic string
<Sonarpulse>
Dezgeg: I'm thinking maybe import it, and move forAllSystems to release.nix too?
<ekleog>
oh, you mean searching for packages both cross-compiled and natively compiled? The issue with building indiscriminately foo.host-system.build-system is that preferLocalBuild derivations can't be built with buildPlatform != hostPlatform (can they?) (disclaimer: I hadn't looked at release-lib.nix yet and don't get yet exactly what it does)
Dezgeg has quit [Ping timeout: 264 seconds]
ma27 has joined #nixos-dev
<Sonarpulse>
ekleog: preferLocalBuild is fine for cross
<Sonarpulse>
ekleog: so right now Nix doesn't support substituting cross for native builds at all
<Sonarpulse>
prefer local build respects the build platform
<Sonarpulse>
because its a different derivation
<Sonarpulse>
*different build platform => different derivation
<Sonarpulse>
ekleog: release-lib.nix is in pkgs/top-level/release-lib.nix
<Sonarpulse>
it's not that complicated or anything
<Sonarpulse>
but looking at it will elucidate the division of labor between hydra and nix exprs
ckauhaus has joined #nixos-dev
ckauhaus has quit []
<ekleog>
hmm, looking more at release-lib.nix and trying to understand it better, I just grep'ed for recurseForRelease and can't find another mention of it, am I missing something or is it a legacy attribute?
<Sonarpulse>
ekleog: no idea
<Sonarpulse>
i'll check
orivej has quit [Ping timeout: 248 seconds]
<ekleog>
Sonarpulse: Ok, so I think I understand now a bit better how hydra builds stuff, including with cross-compilation, thanks! :) However, there's still one thing I'm not sure: let's say I have a hydra localSystem=amd64,crossSystem=armv7l. I have a reliant device that's configured to use hydra. In order to match the derivations built on hydra, it must be configured as localSystem=amd64,crossSystem=armv7l,
<ekleog>
right? Which means then that if it wants to build a patched package not available on the hydra, the build will fail due to localSystem being misconfigured… did I miss something? Or maybe it's supposed to use a second import of nixpkgs with the willingly-ill-configured localSystem? Or is avoiding the second import what you meant by adding .(build-system|native)? (in which case I don't get how it relates
<ekleog>
to the end-user, as afaiu the job.host-system only applies to hydra?)
orivej has joined #nixos-dev
<copumpkin>
niksnut: I'm trying to figure out a Nix 1.12 issue with a custom store and IFD... I currently have it working but I need to explicitly build the IFD derivation first, then copy it to the custom store, then I can evaluate the actual expression I care about. Is there a better way?
<copumpkin>
it feels cumbersome because I also need to name the intermediate derivation
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
<Sonarpulse>
ekleog: i think so
<Sonarpulse>
if there is an x86 build cluster
<Sonarpulse>
and you are on an arm machine
<Sonarpulse>
you cannot build locally what the hydra doesn't provide
<ekleog>
Sonarpulse: hmm ok, so I think that's a reason for suggesting that hydra could falsify the way it built packages to make it look like they were natively built (though this sounds like a great way to break the world, and at the time I thought about it for the wrong reasons ^^)
<Sonarpulse>
copumpkin: Subscribing cause I'm curious what the solution will be, but no i don't
Dezgeg has joined #nixos-dev
JosW has quit [Quit: Konversation terminated!]
FRidh2 has quit [Quit: Konversation terminated!]
<LnL>
ofborg will be down for the next >1h so evaluations, etc. won't run
orivej has quit [Ping timeout: 248 seconds]
<Sonarpulse>
LnL: ok!
jtojnar has quit [Ping timeout: 264 seconds]
kgz has quit [Ping timeout: 268 seconds]
jtojnar has joined #nixos-dev
kragniz has joined #nixos-dev
ma27 has quit [Ping timeout: 255 seconds]
<gchristensen>
niksnut: may I have a repo, nixos/ofborg? I'm going to rename the bot away from grahamcofborg and would like to also move it so it doesn't appear to be "graham's playground"