| 20 Feb 2025 |
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 |
emily | what I mean is
stdenv.mkDerivation {
name = "nix-kitchen-sink";
outputs = [ "bin" "out" "dev" ];
dontUnpack = true;
dontBuild = true;
installPhase = ''
runHook preInstall
ln -s ${nix-cli} $bin
mkdir -p $out/lib
ln -s ${lib.getLib nix-lib-1}/lib/* $out/lib/
ln -s ${lib.getLib nix-lib-2}/lib/* $out/lib/
mkdir -p $dev/{lib/pkgconfig,include/nix}
ln -s ${lib.getLib nix-lib-1}/include/nix/* $out/include/nix/
ln -s ${lib.getLib nix-lib-2}/include/nix/* $out/include/nix/
# etc. (and also this is probably wrong for splicing/cross but you get the idea)
runHook postInstall
'';
}
| 00:20:06 |
emily | which does not seem like it would require any strange low-level workarounds for the output selection machinery, because they would just be real outputs (that happen to be full of symlinks) | 00:20:26 |
Robert Hensing (roberth) | I do have a goal for that machinery to not be strange, because it helps remove certain dependency chains, especially those in foo.doc outputs, but that is secondary | 00:21:56 |
Robert Hensing (roberth) | can be used to simplify bootstrapping a bit | 00:22:34 |
emily | ok, a bigger issue is that e.g. /nix/store/8fc4pxbkadmhnw2zspsbiayz0qdkkm94-nix-main-2.26.1-dev/include/nix/shared.hh does #include "path.hh", but <nix/path.hh> is in nix-store, and AFAICT even if you have them both on the include path a relative include won't look at "the same prefix in another directory" like that | 00:22:44 |
emily | (I haven't tested with your PR yet since it requires a full Nix rebuild, I'm just manually adding libs.foos, but it seems like the separate library packages just don't work so I don't think propagation would fix that) | 00:23:04 |
emily | (a symlink farm would hide the issue I think, by making path.hh be in the same directory as shared.hh, but it seems like a general issue for having split-up components) | 00:23:24 |
emily | hm, it might be user error actually. let me test some more | 00:24:30 |
Robert Hensing (roberth) | between these packages, meson seems to figure things out, fwiw | 00:25:26 |
Robert Hensing (roberth) | we could make dev a symlink farm if we need to | 00:25:58 |
John Ericson | emily: you might want to see what nix-eval-jobs and hydra are now doing for 2.26 | 00:29:11 |
John Ericson | yes the config stuff is not yet good by any means | 00:29:24 |
emily | looks like explicit -includes rather than anything in the .pc? https://github.com/NixOS/hydra/blob/18c0d762109549351ecf622cde34514351a72492/meson.build#L22-L26 | 00:30:17 |
John Ericson | yes :* | 00:30:27 |
John Ericson | * yes :( | 00:30:30 |
John Ericson | now that we are more explicit about the configuration variables than with autoconf, I want to only export the ones the headers actualy depend on | 00:31:15 |
John Ericson | (which should be a lot less) | 00:31:21 |
John Ericson | and use regular #include | 00:31:37 |
John Ericson | emily: another thing is I don't know whether #include "foo" or #include <nix/foo> is better within nix itself | 00:34:26 |
John Ericson | the latter violates "don't know your own name" but keeps us dogfooding our headers as others would use them | 00:34:50 |