!OHimLTKAXNbFrEoogf:matrix.org

Nix Milan

128 Members
https://milano.nix.pizza/10 Servers

Load older messages

SenderMessageTime
11 Jun 2026
@telegram_32436951:t2bot.ioDavidsi esatto. e io non so cosa è statao toccato nel bootloader ma mi si è bruciato grub, l'unica cosa che non posso revertare in un minuto06:47:51
@telegram_32436951:t2bot.ioDavidimage.jpeg
Download image.jpeg		06:48:36
@telegram_176121111:t2bot.ioFrancescoieri ho fatto l'aggiornamento anch'io ma non ho ancora fatto il reboot, spero che non si spacchi nulla...06:56:00
@telegram_176121111:t2bot.ioFrancescoin altre news ho visto che Firefox finalmente supporta mettere la cartella di configurazione in $XDG_CONFIG_HOME06:56:35
13 Jun 2026
@telegram_7189191315:t2bot.iogecko Ciao amici, sto facendo un flake per buildare libone che dipende da libtwo.
libone e libtwo sono in due repo separati.
Di base nessun problema, buildo e son contento.
Ad una certa, voglio fare build incrementali per libtwo (per svilupparci sopra). Bellissimo, nix develop .#libtwo e son contento.
Ora, il problema sorge se voglio build incrementali *sia* su libtwo che su libone.

Ho pensato la cosa seguente:

1. Io mi buildo libone con nix develop e lo installo in una directory X (non in /nix/store).
2. Poi, nel buildare libtwo, uso nix develop, però nella configurePhase faccio in modo che se è stata esportata una variabile d'ambiente OVERRIDE_libone_PATH allora invece che dipendere da libone nello store, dipendo da X.
Tipo cmake -DLIBONE_PATH=$OVERRIDE_libone_PATH invece che -DLIBONE_PATH=${self.....libone}.

Ha senso 'sta roba?
Sto reinventando la ruota?
Vorrie adottare la cosa per un progetto complesso che ha molto più di due repo. 		15:54:03
@telegram_7189191315:t2bot.iogecko * Ciao amici, sto facendo un flake per buildare libone che dipende da libtwo.
libone e libtwo sono in due repo separati.
Di base nessun problema, buildo e son contento.
Ad una certa, voglio fare build incrementali per libtwo (per svilupparci sopra). Bellissimo, nix develop .#libtwo e son contento.
Ora, il problema sorge se voglio build incrementali *sia* su libtwo che su libone.

Ho pensato la cosa seguente:

1. Io mi buildo libone con nix develop e lo installo in una directory X (non in /nix/store).
2. Poi, nel buildare libtwo, uso nix develop, però nella configurePhase faccio in modo che se è stata esportata una variabile d'ambiente OVERRIDE_libone_PATH allora invece che dipendere da libone nello store, dipendo da X.
Tipo cmake -DLIBONE_PATH=$OVERRIDE_libone_PATH invece che -DLIBONE_PATH=${self.....libone}.

Ha senso 'sta roba?
Sto reinventando la ruota?
Vorrei adottare la cosa per un progetto complesso che ha molto più di due repo. 		15:54:42
@telegram_176121111:t2bot.ioFrancescohmm cioè tu vorresti fare in modo che mentre ci stai lavorando sopra, cmake possa direttamente compilare libtwo in modo che quando vai a fare qualche cambiamento su libtwo hai già gli artifact intermedi della build incrementale in cache16:19:26
@telegram_176121111:t2bot.ioFrancescoe se andassi a fetcharti il codice di libtwo come src della derivation di libone?16:20:04
@telegram_176121111:t2bot.ioFrancesco magari puoi usare srcs e in base ad un flag negli argomenti del package ci appendi libtwo https://nixos.org/manual/nixpkgs/stable/#variables-controlling-the-unpack-phase 16:22:22
@telegram_176121111:t2bot.ioFrancesco* hmm cioè tu vorresti fare in modo che mentre stai lavorando su libone, cmake possa direttamente compilare anche libtwo in modo che quando vai a fare qualche cambiamento su libtwo hai già gli artifact intermedi della build incrementale in cache16:33:55
@telegram_7189191315:t2bot.iogecko No, io vorrei che me le compilo separatamente ma libone invece che installarla nello store la installo in path nella mia home che poi uso come dipendenza quando buildo libtwo. 16:56:34
@telegram_176121111:t2bot.ioFrancescoAh ok capito16:57:24
@telegram_7189191315:t2bot.iogeckoPotrei fare una mega derivazione unica, ma è sbatti. Se tengo le derivazioni separate come suggerivo, gli use case "build normale di nix" e "build incrementali a manina" rimangono molto simili (eccetto gli override sostanzialmente).16:57:28
14 Jun 2026
@telegram_165995843:t2bot.ioNonno FeliceDi base è come se stessi ricreando uno /usr/lib in X giusto?08:04:09
15 Jun 2026
@telegram_7189191315:t2bot.iogecko Mmmmh, più /usr. È il prefix di installazione della build di libone. Ma non è un prefix globale (nel senso che X è solo per libone, non anche per libtwo). 02:00:02
@telegram_5487741145:t2bot.ioLuca Hai provato a guardare https://nixos.wiki/wiki/CCache. Puoi fare override di stdenv per quelle due derivation e gli artefatti andranno in un punto comune di cui puoi anche monitorare lo stato e le statistiche 06:18:14
@telegram_5487741145:t2bot.ioLuca Penso che configuri il servizio su nixos o darwin etc (ccache.enable più il resto tipo la directory della cache e i permessi) e poi
libone = pkgs.libone.override { stdenv = pkgs.ccacheStdenv; };
libtwo = pkgs.libtwo.override { stdenv = pkgs.ccacheStdenv; };
Se ha funzionato puoi fare ccache --show-stats
Come bonus lo puoi usare anche per la configurazione, tipo per packages unfree non presenti nei substituter che devi sempre compilare oppure quando applichi patch con gli overlay 		06:24:01
@telegram_5487741145:t2bot.ioLuca Gli hash sono gestiti separati. Nix ha il suo hash della derivazione intera (file sorgente + compilatore + ...), mentre ccache ha gli hash dei singoli file sorgente quindi li riusa se non cambi i file di libone 06:28:57
@telegram_5487741145:t2bot.ioLuca Se non ti funziona la cache per qualche file leggi https://ccache.dev/manual/4.7.4.html#:~:text=sloppiness

Tipo se hai usato __DATE__ nel codice allora l'hash di quell'artefatto cambierà ogni giorno, e ccache lo può evitare usando sempre lo stesso seed 		06:37:06
@telegram_5487741145:t2bot.ioLuca Ultima cosa: mozilla ha anche https://github.com/mozilla/sccache per avere cache distribuite su network 06:42:57
@telegram_7189191315:t2bot.iogeckoCCache approaccia il problema ad un altro livello e ti aiuta solo in parte, devi comunque ri-linkare tutto, ri-runnare la fase di configure. Non sono veramente "build incrementali".07:38:13
@telegram_7189191315:t2bot.iogeckoAlso, funziona solo con C/C07:38:40
@telegram_7189191315:t2bot.iogecko* Also, funziona solo con C/C++, non funziona con progetti Python/TypeScript ad esempio07:38:54
@telegram_7189191315:t2bot.iogecko* CCache approccia il problema ad un altro livello e ti aiuta solo in parte, devi comunque ri-linkare tutto, ri-runnare la fase di configure. Non sono veramente "build incrementali".08:06:06
@telegram_5487741145:t2bot.ioLucaGià già10:19:23
@telegram_5487741145:t2bot.ioLucaGrazie, su questo ci devo pensare. Mi fido, ma non so risponderti10:19:48
@telegram_5487741145:t2bot.ioLucaLa fase di configure è gestita da cmake giusto? quindi con il tuo metodo si salvano anche gli artifatti che genera lui e velocizzi il configure. Il linking è così lento? Forse se hai tante compilation unit inizia a pesare?10:25:28
@telegram_7189191315:t2bot.iogecko Se fai build incrementali rebuildi il minimo necessario a seguito di un cambiamento nel sorgente. Quindi se non cambi CMakeLists.txt, cmake non gira.
A volte lo è, soprattutto su progetti grossi (tipo LLVM).
Ma overall fare una builda pulita ogni volta è sbatti: CMake + script non ccachabili + linking. A meno che ci sia un blocker insormontabile vorrei le build incrementali Vere™. 		11:15:57
@telegram_5487741145:t2bot.ioLuca https://github.com/pdtpartners/nix-ninja (?) 11:36:40
@telegram_5487741145:t2bot.ioLucaDubito sia meglio di come hai fatto tu comunque11:37:35

Show newer messages

Back to Room ListRoom Version: 10