1. Installing hosted Inferno from source
  2. Overview
  3. Like the native kernels emu relies on several auxil-
  4. iary libraries (the source of which it often shares with the
  5. native kernels). Emu itself is built by the mkfile in the
  6. emu subdirectory containing the platform-specific source for
  7. the host platform. Each library has its own mkfile; the
  8. various components are made in the right order by the
  9. mkfile at the root of the Inferno tree. The mkfile for
  10. each platform will also invoke mk recursively to make the
  11. appropriate libraries for a given configuration.
  12. The Unix emu variant generally is covered by `POSIX'
  13. (with common extensions) but each Unix port has one file
  14. that differs considerably for each port, namely
  15. emu/platform/os.c, the differences corresponding to the dif-
  16. ferent ways under Unix of implementing kernel-scheduled
  17. threads efficiently.
  18. There are working emu versions for FreeBSD/386,
  19. Irix/mips, Linux/386, NetBSD/386, MacOSX/386, MacOSX/power,
  20. Plan 9, Solaris/sparc, and Windows (NT, 2000 and Explorer
  21. plug-in). Each platform typically uses mechanisms specific
  22. to the host operating system to implement Inferno's internal
  23. thread/process structure. POSIX threads have often been
  24. found to be insufficient (poorly implemented) on some plat-
  25. forms, and if so are avoided. See kproc in emu/*/os.c.
  26. Source is included for ports to HP/UX (S800 architec-
  27. ture), Solaris/386, and Unixware, in case someone wishes to
  28. take them up now, but we have not determined their fitness.
  29. The Plan 9 hosted implementation is unusual in that it
  30. supports several processor types: 386, mips, power (Power
  31. PC) and sparc. Furthermore, all versions of emu can be
  32. built on any processor type, in the usual way for Plan 9.
  33. Otherwise, as distributed, emu for a platform can only
  34. be built when running on that platform.
  35. One unusual variant makes the whole of Inferno a plug-
  36. in for Microsoft's Internet Explorer, giving the same envi-
  37. ronment for Inferno applications running in an HTML page as
  38. is provided by hosted or native Inferno. That is, there is
  39. not a distinct `applet' environment with special programming
  40. interfaces. The source for the various plug-in components
  41. is found in /tools/plugin and /usr/internet within the
  42. Inferno tree; they use the version of emu defined by the
  43. configuration file /emu/Nt/ie.
  44. Build steps
  45. All the libraries and executables can be built in a
  46. tree containing only the source code. To do that for a sup-
  47. ported variant of hosted Inferno, on Unix or Plan 9, do the
  48. following in the root of the Inferno tree:
  49. 1 Edit mkconfig to reflect your host environment,
  50. specifically ROOT (which must be an absolute path
  51. name), SYSHOST and OBJTYPE. The comments in the file
  52. should help you choose.
  53. 2 Run to rebuild the mk command, which is
  54. used to build everything else.
  55. 3 Set PATH (or path on Plan 9) to include the bin
  56. directory for the platform, which will now contain the
  57. mk binary just built. On Unix, export PATH.
  58. 4 Then mk nuke to remove any extraneous object files.
  59. 5 Finally, mk install to create and install the
  60. libraries, limbo compiler, emu for hosted Inferno,
  61. and auxiliary commands. The rules do that in an order
  62. that ensures that the commands or libraries needed by a
  63. later stage are built and installed first. (Note that
  64. a plain mk will not suffice, because it does not put
  65. the results in the search path.)
  66. Doing something similar on Windows or Plan 9 currently
  67. requires the executable for mk to be available in the
  68. search path, since there is no equivalent of
  69. Otherwise the procedure is the same. On Plan 9, of course,
  70. the host system's normal version of mk should be adequate.