We can't be sure that Mup can be easily ported to just any arbitrary system, but the program is generally quite "vanilla" C code, and we know it has been successfully compiled and run without changes or very minimal changes using at least 14 different compilers on at least 7 different kinds of hardware. We suggest you read the references on compiling Mup for UNIX and compiling Mup for DOS to get a general feel for what is involved in compiling Mup.
It is recommended that you use ANSI C compilation if possible. However Mup should compile under K&R too. With certain compilers, you may get some warnings. But we'd appreciate it if you'd let us know if you get any errors or warnings. We generally try to clean up all errors and most warnings we know about whenever we can do so in a portable way.
Mup is designed to be very frugal with memory and disk space, so on almost any reasonably modern system, Mup's use of memory and disk space will not be of concern. Depending on your compiler, and what optimization and debugging options you turn on, the object file will typically be anywhere from 500K to 3M. Mup uses a lot of malloc space, and often uses more than 1 MB of memory, so if you try to compile for a memory limited system, you will need to use memory management of some sort. There are some ifdefs in the code to attempt to deal with memory-limited systems (BIGMEM in structs.h and SMALLMEMORY in print.c). If your compiler/linker allocates a fixed amount of stack space, we recommended setting it to at least 32K. You should probably allow about 10 MB of disk space for source and objects. Mup has been run on systems as slow as a 386 processor, so almost any reasonably new processor will probably be plenty fast.
A Mup user has reported that the following script will work for compiling with the Watcom C compiler under OS/2:
rem script for building Mup on OS/2 using the Watcom C compiler set include=%WATCOM%\h; for %%f in (*.c) do wcc386 %%f -on -4r echo NAME mup > mup.lnk for %%f in (*.obj) do echo FIL %%f >> mup.lnk wlink sys os2v2 op st=32k @mup.lnk
Another user reported that when compiling Mup with lcc 4.2 on a system whose installed header files came from gcc 2.96, there was a problem in main.c because _UNISTD_H was defined but <getopt.h> was not included. The workaround is to add -D_POSIX_C_SOURCE=2 to the compiler options.
The mkmupfnt program is very straightfoward, so if you can compile Mup, you can will almost certainly be able to compile mkmupfnt. But that program is frankly not widely used.
The Mupdisp program will probably need work to port to any system that does not support X-windows. However, Mupdisp is only a convenience program anyway; you can always just use your favorite PostScript viewer program directly. If you do want to port Mupdisp, just the display and program execution parts generally need work.
The Mupmate program is likely to be the hardest to port. It depends on the FLTK toolkit, so porting to any system supported by FLTK shouldn't be too hard, but porting to a system not supported by FLTK is probably nearly hopeless. Get the latest version of FLTK in the 1.1.x series (we built with 1.1.8); don't get from the 2.x series. Mupmate is the only one of the utility program written in C++, but it does not use any of the more exotic features of C++, so almost any C++ compiler should be sufficient.
Please let us know if you need any other workarounds for compiling on other systems.
Once you get Mup to compile successfully, try running it on the sample input files (sample.mup and star.mup). Verify that the output you get matches the corresponding sample output files (sample.ps and star.ps). You will find differences in some of the numbers, comments, timestamp, filenames, etc, but otherwise, in general the PostScript output you get should be similar to the sample output files provided, and if you display them, the results should look pretty much identical.
If Mup fails to run properly on the sample files, first make sure you are not in a write-protected folder. If you are, try copying the file to a folder that isn't write protected, and run it from there. If it still fails to run properly on the sample files, perhaps either your system has uncovered a bug that we haven't seen yet or your machine has some incompatibility. You can turn on debugging, by running with the -dN option, where N is a bitmap of debugging flags, to help pinpoint where bugs may be. The Mup User's Guide explains the bits of the debugging flags. If you get stuck, you may contact us at
support@arkkra.com and we will try to help.If you need to make any changes in order to get Mup to compile and run successfully, please let us know. If you find anything confusing, we'd like to know that too. We want Mup to be as solid, portable, useful, and easy to use as possible.
Also, please let us know if there are ways we can improve the Mup documentation.
If you receive messages beginning with "internal error" this usually indicates a program bug, so we'd like to know about them. An exception is when you get a message about being unable to allocate memory when there really isn't any memory left. If you get other internal errors, please send us a copy of an input file and any other information that may help us reproduce the problem, so we can try to fix it in the next Mup release.
Provide feedback (bugs reports, comments, suggestions, questions) to:
support@arkkra.com