Add macOS support

[thatcomputerguy0101]

This updates the build scripts and fixes a few minor incompatibilities to add macOS support. The macOS build uses a universal binary to reduce the number of distribution artifacts. This replaces malloc.h with stdlib.h, adds matching for macOS libraries, and links to Accelerate for BLAS support. The double *. in the dependency library glob prevents matching the libopencv_java bundle dylib which cannot be loaded via fetchcontent.

[thatcomputerguy0101]

MacOS still needs added to the build workflow.

[mcm001]

Can/should we be building universal binaries?

[thatcomputerguy0101]

I added additional targets for macOS to the build action. I was going to try to get both targets to build on the Arm runner, but I was encountering a problem where the OpenCV arch got dropped if I tried to change the complier target.

[thatcomputerguy0101]

Can/should we be building universal binaries?

Maybe? I didn't try that yet.

[thatcomputerguy0101]

Building a universal binary seemed to work, which yields fewer artifacts to distribute.

[thatcomputerguy0101]

It seems like OpenBLAS may not be easy to compile a universal binary for. (I haven't eliminated the possibility yet though.)

[spacey-sooty]

Can we not link to Accelerate?

[thatcomputerguy0101]

Prior to macOS 26, Accelerate is 32-bit only. I only confirmed it passes the PV tests on macOS 26.

[Gold856]

To be honest, I think we use a 32 bit BLAS everywhere. I believe OpenBLAS is built with the LP64 API, so I think it's fine? And if it works with the ILP64 API, then I guess that's also fine?

[Gold856]

I'm gonna block only because I want a vanilla mrcal.

[thatcomputerguy0101]

I tested this again with mrcal 2.5 from #17, and had it working. A few corrections from my previous messages, Apple Accelerate was actually updated with ILP64 support in macOS 13.3, not macOS 26. There were other version updates since then, and Apple's documentation only mentions the most recent one. PhotonVision tests still passed with both compile definitions removed, but I think it may still be good to leave the ACCERATE_NEW_LAPACK definition enabled. (I don't really know what either definition is doing though.)

[thatcomputerguy0101]

When I updated the Gradle scripts, I only replaced the arm64 build with the universal build. Any other architectures will remain unchanged.

[mcm001]

Looks like a green pipeline to me!

[thatcomputerguy0101]

I wasn't building mrcal_jni_test before. That is still broken.

[thatcomputerguy0101]

vnlog seems to be incompatible with macOS due to its use of tdestroy, which doesn't exist there. Is it better to just skip trying to build the tests on macOS for now?

[Gold856]

Seems like <search.h> is part of the POSIX standard, not the C standard. See if invoking Apple Clang manually with -D_POSIX_C_SOURCE=200809L and compiling this test file will work:

#include <search.h>

If it does, use add_compile_definitions to add that define into the CMake build.

[thatcomputerguy0101]

This is the search.h VSCode finds on macOS 26:

/*-
 * Written by J.T. Conklin <jtc@netbsd.org>
 * Public domain.
 *
 *	$NetBSD: search.h,v 1.12 1999/02/22 10:34:28 christos Exp $
 * $FreeBSD: src/include/search.h,v 1.10 2002/10/16 14:29:23 robert Exp $
 */

#ifndef _SEARCH_H_
#define _SEARCH_H_

#include <sys/cdefs.h>
#include <_bounds.h>
#include <_types.h>
#include <sys/_types/_size_t.h>

_LIBC_SINGLE_BY_DEFAULT()

typedef	struct entry {
	char *_LIBC_CSTR	key;
	void	*data;
} ENTRY;

typedef	enum {
	FIND, ENTER
} ACTION;

typedef	enum {
	preorder,
	postorder,
	endorder,
	leaf
} VISIT;

#ifdef _SEARCH_PRIVATE
typedef	struct node {
	char *_LIBC_CSTR	key;
	struct node  *llink, *rlink;
} node_t;

struct que_elem {
	struct que_elem *next;
	struct que_elem *prev;
};
#endif

__BEGIN_DECLS
int	 hcreate(size_t);
void	 hdestroy(void);
ENTRY	*hsearch(ENTRY, ACTION);
void	 insque(void *, void *);
void	*lfind(const void *, const void *_LIBC_UNSAFE_INDEXABLE, size_t *, size_t,
	    int (*)(const void *, const void *));
void	*lsearch(const void *, void *, size_t *_LIBC_UNSAFE_INDEXABLE, size_t,
	    int (*)(const void *, const void *));
void	 remque(void *);
void	*tdelete(const void * __restrict, void ** __restrict,
	    int (*)(const void *, const void *));
void	*tfind(const void *, void * const *,
	    int (*)(const void *, const void *));
void	*tsearch(const void *, void **, int (*)(const void *, const void *));
void	 twalk(const void *, void (*)(const void *, VISIT, int));
__END_DECLS

#endif /* !_SEARCH_H_ */

Maybe twalk could be used to replace tdestroy?

[thatcomputerguy0101]

I found this (POSIX?) documentation with an example of how to delete all nodes of a tree without tdestroy. I guess I'll PR that to vnlog.

[Gold856]

Yeah, that's probably the move. I just reread some documentation and somehow missed that tdestroy is actually a GNU extension of search.h.