Hello, Zhu Zihao <all_but_l...@163.com> writes:
> If your foreign function use case is very trivial? Why not give Guile > dynamic FFI a try? That could be another option, but I'd like to have autoconf be able to detect whether the target supports things like posix_spawn and getrlimit, which I use in the code. > It's possible to use guix channel to test a local guix repo. A short > example here. Right, but for the example of adding extensions it won't work since there's a part of `guix pull` that uses the guix package, as well as in the installer or system-wide Guix, as I outlined before. The issue [1] I outlined in the opening mail was an issue that is specific to the guix package method, so there really isn't a way to uniformly test changes without knowing the intricacies of the different builds and where they end up (I do know these, having run into these issues myself before). > This is somewhat "the bootstrap problem". It's very ideal if we can > describe the build graph in Guix with derivations. But we still need a > daemon first to process derivations. So we need to build daemon without > Guix. I don't think that's the case, (guix self) relies on a working daemon connection before anything else, the built daemon will just be a part of the resulting `guix pull` profile, but won't be used to build the new Guix (as a matter of fact, the build daemon is built... using the build daemon!). > This issue may be solved by rewriting daemon in Guile. If daemon is > written in Guile. We can run it without compilation. I don't think this is directly related, although some changes that we could bring to it would definitely ease what I'm proposing here: having a way to build things directly without relying on a root-owned daemon running would make the bootstrapping problem easier to solve. Best, -- Josselin Poiret
