!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

891 Members
For people hacking on the Nix package manager itself191 Servers

Load older messages


SenderMessageTime
20 Feb 2025
@Ericson2314:matrix.orgJohn Ericson the symlink hack is only in the source tree 18:40:03
@Ericson2314:matrix.orgJohn Ericsonin the installed outputs, everything is normal18:40:13
@Ericson2314:matrix.orgJohn Ericson and also importantly, were not doing anything like sedding-in the #include "nix/... either, which would screw over meson subproject stuff 18:40:41
@emilazy:matrix.orgemilyalright. well since it doesn't affect any downstream user I guess it doesn't really matter. just seems silly to me18:40:47
@Ericson2314:matrix.orgJohn Ericson(and I do use that, to work on hydra and nix-eval-jobs and nix all at once, it's nice!)18:40:56
@emilazy:matrix.orgemilyI think you could construct the symlink hack inside the Meson build rather than polluting the source tree with it.18:41:04
@emilazy:matrix.orgemilyit supports generated include stuff etc.18:41:09
@Ericson2314:matrix.orgJohn Ericsonthat might cause some side effects like more confusing paths in compiler diagnostics18:42:15
@Ericson2314:matrix.orgJohn Ericson(which is fixable)18:42:18
@Ericson2314:matrix.orgJohn Ericson * (which is fixable, granted)18:42:21
@Ericson2314:matrix.orgJohn Ericsonif you are willing to try this out, then I would say try either the source symlink or meson-made symlink 18:42:42
@Ericson2314:matrix.orgJohn Ericson(just don't do something where meson configure needs to be re-run every time a header changes, but I don't think you would do anyways :))18:43:13
@Ericson2314:matrix.orgJohn Ericson Lix uses include_directories(".." / "..") but that is bad for isolating the headers between projects, and fine-grained per package builds 18:44:08
@Ericson2314:matrix.orgJohn Ericson * Also FWIW: Lix uses include_directories(".." / "..") but that is bad for isolating the headers between projects, and fine-grained per package builds 18:44:14
@emilazy:matrix.orgemily I'm just going to use the namespace-polluted headers for now; it's not avoidable anyway since the .pc forces them upon you 18:46:18
@Ericson2314:matrix.orgJohn Ericsonhuh?18:46:37
@Ericson2314:matrix.orgJohn Ericsonfor a specific downstream project?18:46:47
@emilazy:matrix.orgemilyyeah18:46:50
@archercatneo:matrix.orgarchercatneo There's something I was wondering on why it's not done but why couldn't we in step 1 of compilation copy all *.hh files to $dev/include/nix then in the actual compilation do -I $dev/include (and if $dev is not avalible just use the normal meson artifacts dir) 18:47:02
@Ericson2314:matrix.orgJohn EricsonI mean I would not be opposed to backporting the change to get rid of the header polution to 2.2618:47:03
@emilazy:matrix.orgemily as in, <shared.hh> is already taken over anyway, so no point to avoid that by doing <nix/shared.hh> 18:47:08
@emilazy:matrix.orgemilysure, I think it should be fixed18:47:23
@emilazy:matrix.orgemilyI don't think I'll be able to allocate time to fixing it myself as I haven't dived into the Nix Meson build and anyway it sounds like there are constraints I don't fully understand preventing what seems like the simple/correct solution to me :)18:47:48
@Ericson2314:matrix.orgJohn Ericson the simple correct solution being just make an include/nix dir in the source code? 18:48:18
@emilazy:matrix.orgemily how does this actually work within the Nix build? 18:48:21
@emilazy:matrix.orgemilyhow can the libraries see each other's headers?18:48:25
@emilazy:matrix.orgemily do they consume the generated .pc files internally? 18:48:31
@Ericson2314:matrix.orgJohn Ericsonregular meson deps18:48:34
@Ericson2314:matrix.orgJohn Ericsonno they don't consume the pc files internally sadly18:48:46
@emilazy:matrix.orgemilyand Meson just adds the entire source tree of every library to the include path of downstream ones?18:48:50

Show newer messages


Back to Room ListRoom Version: 6