> From: Andy Wingo <wi...@pobox.com> > Cc: guile-devel@gnu.org, l...@gnu.org, m...@netris.org > Date: Tue, 12 Jul 2016 16:05:35 +0200 > > > It's hard for me to build Guile from Git, due to the additional > > prerequisites that needs. > > Understood, in that case please note that there is also an automatic > build service that runs "make" and "make dist" to make tarballs: > > https://hydra.nixos.org/job/gnu/guile-2-0/tarball > > Just click through and you can download a tarball. For example: > > > https://hydra.nixos.org/build/37557639/download/3/guile-2.0.11.238-e1cb7.tar.gz > > There is .xz too. This service exists for Guile master too: > > https://hydra.nixos.org/job/gnu/guile-master/tarball
Thanks, I will try that when I have time, if Guile is not released before that. > getuid is used in boot-9.scm, so if it's unavailable, we cannot build > Guile without making changes in the Scheme code. I don't know if that > convinces you, and I have no practical way of counting their uses in > Guile programs outside Guile itself. > > But in reality the getuid is of this form: > > (define (load-user-init) > (let* ((home (or (getenv "HOME") > (false-if-exception (passwd:dir (getpwuid (getuid)))) > file-name-separator-string)) ;; fallback for cygwin etc. > (init-file (in-vicinity home ".guile"))) > (if (file-exists? init-file) > (primitive-load init-file)))) > > So, no problem. Won't this fail to compile during boot, or at least produce a warning? > > The only other issue I see is the type of the value returned by > > start_child, and as result by scm_open_process. On Windows, the value > > returned has the type HANDLE, which is actually a pointer in disguise. > > I used intptr_t for that, but you changed it to just int. This will > > not work in 64-bit MinGW builds, where a pointer is a 64-bit type. I > > think we should go back to intptr_t, and also change the conversion to > > the value returned by scm_open_process, since scm_from_int will AFAIK > > not support 64-bit integer types. Note that the MinGW waitpid > > implementation also expects to get a valu that is interpreted as a > > handle. > > Hummmm, I don't know, there are a number of other things in that file > which treat PIDs as ints (scm_waitpid, scm_getppid, etc etc etc). I > think that would need to be another patch that adds scm_from_pid_t and > scm_to_pid_t and so on. And then what is this? > > http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/12235 The process ID is indeed an int, but my code hides a process handle inside it. > I will apply your patch though and I look forward to hearing if it works > for you :) The above is not a problem for me, since I use the 32-bit MinGW, where a handle is a 32-bit type. This is only a potential problem in 64-bit builds. Thanks.