DomTool/Building132018-08-11 16:36:04ClintonEbadi122018-08-11 16:34:52ClintonEbadinote where instructions on non-hcoop setups are112018-08-11 16:21:20ClintonEbadiredo prerequistes section102018-08-11 16:10:04ClintonEbadiquick list of packages needed92010-12-05 20:21:14ClintonEbadi82010-11-02 22:46:12ClintonEbadidebian's sml/nj is no longer too old to compile domtool72010-10-04 04:38:16ClintonEbadinote hcoop git repo is the canonical source location of domtool now62010-02-16 17:25:17DavorOcelic52009-09-27 16:59:52AdamChlipalaSML/NJ packages42009-09-27 16:34:46AdamChlipalaFixing markup32008-07-07 04:28:01localhostconverted to 1.6 markup22007-10-16 12:51:43MichaelOlsonAdd instructions for reinstalling server/slave12006-12-16 23:38:00AdamChlipalaPrerequisitesDomTool minimally requires an SML compiler, libpcre for regex handling, libssl for communications, and rsync to publish configuration. For Debian, the following packages are required for a standard build: You may optionally install SML/NJ packages for interactive development: A Note On CompilersTo compile the standalone DomTool tools, you will need the MLton Standard ML compiler. It's available as Debian package mlton
. To use DomTool from an interactive SML REPL session, you will need a recent version of Standard ML of New Jersey. Version 110.74 is sufficient, so packages in Debian 6 and above are adequate, for other distributions you may need to compile it manually. Why am I referencing two different compilers here? Well, developing with SML/NJ and building release binaries with MLton is standard practice in the SML world. SML/NJ supports separate compilation and interactive use, which are very helpful during development. MLton is a whole-program optimizing compiler that produces extremely efficient binaries, at the cost of much greater compile-time time and memory usage than SML/NJ. Getting the source codeYou can obtain the approximately-latest version of the DomTool source code from HCoop Anonymous Git. To clone simply execute: If you have been granted write permission to the repository and plan to commit code changes, then you'll want to check the repo out either via ssh or openafs using an account with credentials to write to the domtool git directory. Building the standalone toolsFirst, in the domtool2
directory that you have checked out, create a file config.sml
containing: CONFIG = struct
open ConfigDefault
end]]>Heck, you could even go ahead and set some non-standard configuration values! If you leave it as is, you inherit the defaults, which should be appropriate for HCoop servers. If you are not installation DomTool at HCoop, see DomTool/NonHCoopSetup for details on configuring DomTool to run outside of HCoop. Even if you set configuration parameters until you're blue in the face, this stuff probably won't work very well in environments that don't look much like Linux. Perhaps some day greater portability will become enough of a priority for us to fix that. Once you have that done, the rest is easy! Just runThis will populate domtool2/bin/
with the compiled DomTool programs. As root, runto copy these programs and some additional scripts to appropriate standard locations. Consult the Makefile if you'd like to see what those locations are ahead of time. Reinstalling the standalone toolsIf you want to reinstall domtool on machines that are running it already, then it is best to use a slightly modified set of instructions. First, create a config.sml
file as directed above, and run make
. If the current machine is a slave, then run If the current machine is a server, then run Building for SML/NJAfter following the same procedure as above for config.sml
, runfollowed byas root. Now you should be able to run sml
in the base domtool2
directory and run CM.make "src/domtool.cm";
. If you don't see any error messages, then the DomTool modules are loaded and you can start poking them. For instance, running open Main;
should print information on the primary entry-points.