Steps for building MX: 1. Change the value of the MX_ARCH variable below to match the platform you are compiling the MX system for. The best tested platforms are: bsd - FreeBSD, NetBSD, OpenBSD, or PC-BSD cygwin - Cygwin 1.5.x or 1.7.x linux - Linux 2.2 or above macosx - MacOS X (using GCC) macosx-clang - MacOS X or macOS (using Clang) solaris - Solaris 2.5 or above solaris-gcc - Solaris 2.6 or above (using GCC) win32 - Microsoft Win32 (using Visual C++ 4 or above) There are other build targets available in the top level Makefile beyond the ones listed above. The MX makefiles assume that you are using Gnu Make on all supported platforms. Other versions of make such as BSD Make, Microsoft Nmake, Solaris Make, and so forth will not work and are not supported. On Microsoft Windows platforms, the MX "win32" build target uses Microsoft Visual C++. However, it also assumes the presence of the Cygwin environment which provides Posix style utilities like make, cp, rm, touch, and so forth. This may be installed from its web site at http://www.cygwin.com/. 2. Set MX_INSTALL_DIR to the directory that you want to install MX in, such as /opt/mx. 3. Look at the makefile variables configured near the top of the file "mx/libMx/Makehead.$(MX_ARCH)" to see if any need to be modified. For example, if MX_ARCH = linux, then the file to modify is "mx/libMx/Makehead.linux". The most common thing to modify here is to either comment out or uncomment the OPTIMIZE macro, since this is what turns on or off compiler optimization of the code. There may also be macros for selecting whether or not to compile 32-bit binaries or a 64-bit binaries. On most platforms, this is all you need to modify. However, on "win32", you will need to correctly set the MSDEV_ARCH and MSDEV_DIR macros for MX to be able to find the necessary runtime DLLs for your compiler. In addition, you should not modify anything in the makefile after the line that says "Generally, you should not have to modify anything after this point." 4. Do a "make distclean" command. 5. Do a "make depend" command. 6. Do a "make" command. 7. If MX builds correctly, do "make install" to install the binaries in the requested location. The directory $(MX_INSTALL_DIR) must exist before you do "make install". On Win32, $(MX_INSTALL_DIR) should use forward slashes like / rather than backslashes. 8. If you are using MX drivers that now are in dynamically loaded MX modules, then you select the modules to build by uncommenting the appropriate lines in the file mx/modules/Makefile. The build configuration of the various MX modules is done in module-specific make files found here: mx/modules/*/Makefile. For example, if you will be using XIA Handel drivers, then you configure them in the file mx/modules/xia_handel/Makefile. One special case is the core EPICS driver module (epics.mxo) which is configured in mx/modules/epics/Makefile.config. Another special case is the Python extension module (python.mxo) which can only be built _after_ the Mp Python package has been built and installed. If you will be building modules, then use the commands make modules-distclean make modules make modules-install 9. Now you must edit the configuration files in $(MX_INSTALL_DIR)/etc. This process is sufficiently long-winded that it deserves its own manual. I haven't written that manual yet, but for the moment you can use the program "mxdriverinfo" as a guide to figuring out the correct format for a given record type. Read the file "mx/doc/mxdriverinfo.man" for more information. Also, there are a variety of test databases in the "mx/test" and "mx/testserv" directories that can be used for inspiration. 10. Set up the environment variable MXDIR equal to the value defined for $(MX_INSTALL_DIR) above. Many tools will default to MXDIR = "/opt/mx", but it is better to just set up the define. 11. Add the directory "$(MX_INSTALL_DIR)/bin" to the PATH. 12. Add the shared library directory "$(MX_INSTALL_DIR)/lib" to the shared library path. On most unix systems, this is LD_LIBRARY_PATH, but on MacOS X it is DYLD_LIBRARY_PATH, while on HP/UX it is SHLIB_PATH. On Win32, the necessary DLLs automatically get copied to the directory $(MX_INSTALL_DIR)/bin, so Win32 users can skip this step. 13. If you are setting up an MX server on a Unix system with System V style startup scripts (Linux, Solaris, etc.), then you can use the file "$(MX_INSTALL_DIR)/sbin/mx" as a startup and shutdown script. All that should be necessary is to create the appropriate links in the /etc/rc?.d directories. On other Unix systems, you can use the script as a guide to what to do. If you are setting up an MX server on an LSB (Linux Standard Base) system, then you need to symlink $(MX_INSTALL_DIR)/sbin/mx to /etc/init.d/mx and then run the command "update-rc.d mx defaults" to get the correct startup script links working. If you are setting up an MX server on a Win32 system, then you can use the file "$(MX_INSTALL_DIR)/sbin/mx.bat" as a guide for what needs to be done to start up the MX server. An alternate, more flexible way of setting up MX Win32 startup files can be found in mx/scripts/windows. 14. The source code for MX extension packages should be unpacked in the same directory that you unpacked the MX tar file in. Thus, you should end up with a directory containing subdirectories like "mx", "mp", "mxtcl", and so forth. In general, the procedure for building and installing them is the same procedure of configuring the Makefile followed by "make clean", "make depend", "make", and "make install", but you should read any bundled instructions for more information. In particular, the MxTcl package has an extra file "mxtcl/libMxTcl/Makehead.$(MX_ARCH)" that must be modified. If it all fails, then contact me (Bill Lavender) at the email address of lavender@agni.phys.iit.edu and I will see what I can do for you.