Re: Trying to build on FreeBSD

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Tue, Dec 06, 2011 at 07:27:25PM -0500, lists+mirage@xxxxxxxxxxxx wrote:
> Hi Anil, thanks for the quick reply. I had to do what you suggested to
> create a lib/os/runtime_unix/ev_freebsd.c file, as well. I just copied
> the Mac file for that; I'm not sure whether FreeBSD should choose SELECT
> or EPOLL. But at least I got everything to build. I'll attach my patches
> from git HEAD to this email; I'm not sure though if this list will
> accept attachments.

FreeBSD should actually use kqueue, but I'm less convinced by the utility
of libev these days; the bindings are quite complex and there's at least
one SEGV bug lurking in there.

> I had to change the shebang lines for the bash scripts, because on BSD
> systems bash is underneath /usr/local. I changed them to `/usr/bin/env
> bash ...`
> instead. That _should_ work, however for reasons I don't understand then
> `gmake install` fails. I had to change the shebang line on ./assemble.sh
> to /usr/local/bin/bash.

I'll fix these up to work on BSD make directly; the Makefiles are just
wrappers now and don't do much except call ocamlbuild. 

> 
> I haven't yet been able to run a test though. This page
> <http://www.openmirage.org/wiki/hello-world> says to do this:
> 
> $ cd mirage.git/tests/basic/sleep
> $ mir-unix-direct sleep.bin
> $ ./_build/sleep.bin

Ah yes, that is out-of-date indeed: we did a big tutorial and neglected
the wiki examples, but I've fixed them up now.  The old build scheme was
to have a separate command per-backend, but now the ocamlbuild integration
has advanced enough that we just need to specify the backend as a virtual
pathname prefix.

So you do:

$ mir-build unix-direct/sleep.bin
or
$ mir-build xen/sleep.xen # note the different extension

I'm just refreshing my FreeBSD-current machine to see if I can get a
Mirage Xen domU compiling on there. Shouldn't be any reason why not.

We've been doing quite a few benchmarks on performance recently, and also
some other work on I/O that have led to some ideas about improving the
structure of the Mirage network stack considerably. Expect a new branch
that strips things down and simplifies things considerably over the next
month or so. 

In particular, it's probably time to split out some of the higher-level
libraries into separate repos (regexp, http, etc) as other people want to
use them outside Mirage too. I'd like Mirage-core to have everything up to
TCP for networking for now, and focus on keeping it simple and adding
robust profiling and visualisation support (sorely needed at the moment).

-- 
Anil Madhavapeddy                                 http://anil.recoil.org