Hi Danny,
Danny Milosavljevic <dannym@scratchpost.org> writes:
Toggle quote (5 lines)
> But when I use our separate package definitions it fails when building libcore> (which is the first library for the target compiler).> Invoke seems to swallow the output, so I have no idea where or why it failed> (grr).
Hmm. What makes you think that 'invoke' swallowed the output? Youmight be right, but 'invoke' is used quite widely by now in Guix,including to invoke 'make' in gnu-build-system, and I haven't seenreports of it swallowing output.
I looked at the code. 'invoke' calls 'system*' which calls'scm_open_process' (in libguile/posix.c) with an empty mode string.
In this case, the child STDOUT becomes (current-output-port) from theparent if (current-output-port) is a "file port", i.e. a Guile portbacked by a POSIX file descriptor, e.g. a file, socket or pipe. If it'sa Guile port that's not backed by a file descriptor, e.g. a custom port,soft port, string port, bytevector port, etc, then indeed the childoutput will go to /dev/null instead.
(Note that the port returned by 'open-pipe*' when used in OPEN_BOTH modeis also a soft port and not considered a file port, even though it isinternally backed by two file ports.)
Ditto for STDERR, except that it uses (current-error-port).
So, if 'invoke' seems to be swallowing output, it's probably because itwas called within the dynamic extent of 'with-output-to-port','with-error-to-port', 'with-output-to-string', or similar.
Regards, Mark