| 19 Feb 2025 |
Robert Hensing (roberth) | I have some code that seems to implement the multi output attribute interface correctly now | 23:33:31 |
Robert Hensing (roberth) | I think so | 23:34:40 |
emily | fwiw I think the "import the nix/ directory of the Nix repo" approach makes it much harder for regular Nixpkgs contributors to fix issues in the Nix packaging, since there is an entire layer of non-standard abstractions that mostly do not directly benefit Nixpkgs and diverge from its conventions; there's a reason we usually don't import other projects' Nix infrastructure wholesale when packaging them | 23:39:58 |
emily | but my primary concern is just that currently it seems to break every downstream that uses Nix as a library | 23:40:17 |
ElvishJerricco | I'm also still just not really seeing the actual use case... | 23:40:39 |
emily | uh, also the components use lib.fileset somehow? | 23:42:58 |
emily | which isn't meant to be allowed in Nixpkgs and I don't really understand how it's not breaking eval | 23:42:59 |
emily | oh, I guess because it's dead code in the Nixpkgs context | 23:43:29 |
ElvishJerricco | which itself is a problem | 23:44:44 |
emily | libs.nix-store doesn't seem to work properly. nix/path.hh wants types.hh which is not in its include dir. | 23:44:58 |
ElvishJerricco | the dead code made it much harder for me to understand what was going on | 23:45:00 |
emily | (if it's part of another package it should be propagating that) | 23:45:11 |
Robert Hensing (roberth) | I've opened https://github.com/NixOS/nixpkgs/pull/383508 | 23:52:12 |
Robert Hensing (roberth) | I believe it fixes the .dev output | 23:52:45 |
Robert Hensing (roberth) | IME the dev output propagates what you need, but I'd be happy to improve the individual libs.* packages | 23:55:29 |
emily | hm, why is it propagating the CLI package? | 23:58:34 |
| 20 Feb 2025 |
Robert Hensing (roberth) | otherwise it didn't get picked up by nativeBuildInputs | 00:03:37 |
Robert Hensing (roberth) | I'm not sure this is the best solution | 00:03:51 |
emily | i feel the split-lib packaging could probably use more time to bake before being unleashed into Nixpkgs… :) | 00:05:20 |
emily | the level of packaging complexity seems very high and I'm not really sure why, we package a lot of multi-lib projects with much more mundane tooling than this | 00:05:38 |
emily | is there a reason it couldn't just be: nix-whatever library packages in pkgs/by-name, the nix package symlinks everything and has bin, out, dev outputs? | 00:06:27 |
emily | I don't see why the outputs need emulating at all – installing nix on a system would use nix.bin and only pull in the binary, nix.dev would be an actual output with all the relevant files symlinked, etc. | 00:06:53 |
emily | <nix/globals.hh> wants SYSTEM which is defined in Meson-generated config-store.hh which doesn't appear to be included anywhere. again not sure I'm holding it right. (maybe it needs to be explicitly included by Nix C++ API users?) | 00:13:48 |
Robert Hensing (roberth) | we did it this way because the out (bin) is a trivial builder, not a proper mkDerivation call | 00:13:58 |
Robert Hensing (roberth) | if the root package remains too buggy we could do a more custom derivation in a non-custom package attrset | 00:15:34 |
Robert Hensing (roberth) | those should be part of the pkg-config compiler flags | 00:17:06 |
Robert Hensing (roberth) | which is admittedly a weird approach | 00:17:36 |
emily | Libs: -L${libdir} -lnixstore
Libs.private: -lsandbox /nix/store/nqwpwimfcy6wakn4p47v4prijq0cbqik-boost-1.87.0/lib/libboost_container.dylib -L/nix/store/x99grmq3agqymigz4kbns60vqc1w9d2k-aws-sdk-cpp-1.11.448/lib -laws-cpp-sdk-transfer -laws-cpp-sdk-s3 -laws-cpp-sdk-core -laws-crt-cpp
Cflags: -I${includedir}/nix -std=c++2a
| 00:17:37 |
emily | it doesn't seem to be | 00:17:39 |
emily | I grepped the whole ^dev outputs for config-store and there's nothing | 00:17:49 |