From 5fded916e00adfddd7bd332173175a82c4ef3221 Mon Sep 17 00:00:00 2001 From: "Charles.Forsyth" Date: Sun, 16 Mar 2008 17:16:17 +0000 Subject: 20080316-1724 --- INSTALL | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-) (limited to 'INSTALL') diff --git a/INSTALL b/INSTALL index 7f86204c..2c3a46a7 100644 --- a/INSTALL +++ b/INSTALL @@ -3,14 +3,14 @@ Installing hosted Inferno from source First change mkconfig to reflect your host environment, specifically ROOT (which must be an absolute path name), SYSHOST and OBJTYPE. - Like the native kernels _eeee_mmmm_uuuu relies on several auxil- + Like the native kernels emu relies on several auxil- iary libraries (the source of which it often shares with the -native kernels). Emu itself is built by the _mmmm_kkkk_ffff_iiii_llll_eeee in the -_eeee_mmmm_uuuu platform directory for the host, as described above. -Each library has its own _mmmm_kkkk_ffff_iiii_llll_eeee; the various components are -made in the right order by the _mmmm_kkkk_ffff_iiii_llll_eeee at the root of the -Inferno tree. The _mmmm_kkkk_ffff_iiii_llll_eeee for each platform will also -invoke _mmmm_kkkk recursively to make the appropriate libraries for +native kernels). Emu itself is built by the mkfile in the +emu platform directory for the host, as described above. +Each library has its own mkfile; the various components are +made in the right order by the mkfile at the root of the +Inferno tree. The mkfile for each platform will also +invoke mk recursively to make the appropriate libraries for a given configuration. The Unix emu variant generally is covered by `POSIX' @@ -27,18 +27,18 @@ typically uses mechanisms specific to the host operating system to implement Inferno's internal thread/process struc- ture. POSIX threads have often been found to be insuffi- cient (poorly implemented) on some platforms, and if so are -avoided. See _kkkk_pppp_rrrr_oooo_cccc in _eeee_mmmm_uuuu/*/_oooo_ssss._cccc. +avoided. See kproc in emu/*/os.c. Source is included for ports to HP/UX (S800 architec- ture), Solaris/386, and Unixware, in case someone wishes to take them up now, but we have not determined their fitness. The Plan 9 hosted implementation is unusual in that it -supports several processor types: _3333_8888_6666, _mmmm_iiii_pppp_ssss, _pppp_oooo_wwww_eeee_rrrr (Power -PC) and _ssss_pppp_aaaa_rrrr_cccc. Furthermore, all versions of _eeee_mmmm_uuuu can be +supports several processor types: 386, mips, power (Power +PC) and sparc. Furthermore, all versions of emu can be built on any processor type, in the usual way for Plan 9. - Otherwise, as distributed, _eeee_mmmm_uuuu for a platform can only + Otherwise, as distributed, emu for a platform can only be built when running on that platform. One unusual variant makes the whole of Inferno a plug- @@ -47,34 +47,34 @@ ronment for Inferno applications running in an HTML page as is provided by hosted or native Inferno. That is, there is not a distinct `applet' environment with special programming interfaces. The source for the various plug-in components -is found in /_tttt_oooo_oooo_llll_ssss/_pppp_llll_uuuu_gggg_iiii_nnnn and /_uuuu_ssss_rrrr/_iiii_nnnn_tttt_eeee_rrrr_nnnn_eeee_tttt within the -Inferno tree; they use the version of _eeee_mmmm_uuuu defined by the -configuration file /_eeee_mmmm_uuuu/_NNNN_tttt/_iiii_eeee. +is found in /tools/plugin and /usr/internet within the +Inferno tree; they use the version of emu defined by the +configuration file /emu/Nt/ie. All the libraries an executables can be built in a tree containing only the source code. To do that for a supported variant of hosted Inferno, on Unix or Plan 9, do the follow- ing in the root of the Inferno tree: -1. Run _mmmm_aaaa_kkkk_eeee_mmmm_kkkk._ssss_hhhh to rebuild the _mmmm_kkkk command, which is +1. Run makemk.sh to rebuild the mk command, which is used to build everything else. -2. Set _PPPP_AAAA_TTTT_HHHH (or _pppp_aaaa_tttt_hhhh on Plan 9) to include the _bbbb_iiii_nnnn +2. Set PATH (or path on Plan 9) to include the bin directory for the platform, which will now contain the - _mmmm_kkkk binary just built. On Unix, export _PPPP_AAAA_TTTT_HHHH. + mk binary just built. On Unix, export PATH. -3. Then _mmmm_kkkk _nnnn_uuuu_kkkk_eeee to remove any extraneous object files. +3. Then mk nuke to remove any extraneous object files. -4. Finally, _mmmm_kkkk _iiii_nnnn_ssss_tttt_aaaa_llll_llll to create and install the - libraries, _llll_iiii_mmmm_bbbb_oooo compiler, _eeee_mmmm_uuuu for hosted Inferno, +4. Finally, mk install to create and install the + libraries, limbo compiler, emu for hosted Inferno, and auxiliary commands. The rules do that in an order that ensures that the commands or libraries needed by a later stage are built and installed first. (Note that - a plain _mmmm_kkkk will not suffice, because it does not put + a plain mk will not suffice, because it does not put the results in the search path.) Doing something similar on Windows or Plan 9 currently -requires the executable for _mmmm_kkkk to be available in the -search path, since there is no equivalent of _mmmm_aaaa_kkkk_eeee_mmmm_kkkk._ssss_hhhh. +requires the executable for mk to be available in the +search path, since there is no equivalent of makemk.sh. Otherwise the procedure is the same. On Plan 9, of course, -the host system's normal version of _mmmm_kkkk should be adequate. +the host system's normal version of mk should be adequate. -- cgit v1.2.3