configure.ac has two operating systems hard-coded, posix-clocks-foo.scm related?

[gdt]

Trying to build/test #53 on NetBSD, I got an error:

gmake: *** No rule to make target 'fibers/posix-clocks-.scm', needed by 'fibers/posix-clocks.scm'.  Stop.

because of Makefile's

fibers/posix-clocks.scm: Makefile fibers/posix-clocks-$(PLATFORM).scm
        ln -sf $(abs_top_srcdir)/fibers/posix-clocks-$(PLATFORM).scm $(abs_top_builddir)/fibers/posix-clocks.scm

I then found in configure.ac:

# Detect the target system                                                                                                                                                    
case "$host_os" in
    linux*)
        build_linux=yes
        PLATFORM=linux
        ;;
    darwin*)
        build_darwin=yes
        PLATFORM=darwin
        ;;
esac

I don't understand why this exists; I'm guessing that despite posix-clocks-foo starting with posix, it might use beyond-posix features? I would hope that we can end up with a build that works on pretty much any modern posixy system without per-platform code, but it looks like this is ffi glue code and needs to know types (which are left unspecified by posix).

[gdt]

In posix-clocks-common, (define clockid-t int32) but clockid_t on NetBSD is int, as far as I can tell from headers. My impression is that POSIX tends to require these types to be "an integral type". On most CPU architectures, that works out to be the same, but e.g. alpha is ILP64. This is just an aside; I don't think it's causing the affinity trouble.

/usr/include/sys/types.h:typedef        _BSD_CLOCKID_T_         clockid_t;
/usr/include/sys/common_ansi.h:#define  _BSD_CLOCKID_T_         int             /* clockid_t */

[gdt]

posix-clocks-common.scm analysis:

                NetBSD          fibers
clockid_t       int             int32
time_t          int64_t         long
pid_t           int32_t         int
pthread_t       void*           unsigned long
s_timespec      time_t/long     time_t/long

NetBSD pthread_t is really a pointer to struct.

[aconchillo]

@gdt I believe we should be OK closing this issue now, right?

[gdt]

I think it's ok, and things have certainly changed. So I will hit close and start over if I find anything else. Thanks for all the fixes