Notes on porting Jam - revised 11/11/97 1) Working out system dependencies in the Jam code. Jam's OS footprint is fairly small. For OS independent work Jam liberally uses standard libc functions like stdio, malloc, and string. The OS dependent interfaces are: From filesys.h: file_parse() - split a file name into dir/base/suffix/member file_build() - build a filename given dir/base/suffix/member file_dirscan() - scan a directory for files file_archscan() - scan an archive for files file_time() - get the timestamp of a file, if not already done by file_dirscan(). From execcmd.h: execcmd() - execute a shell script execwait() - wait for any outstanding execcmd()'s. The current implementations are: filemac.c - mac MPW filent.c - NT fileos2.c - OS/2 fileunix.c - all UNIX filevms.c - VMS execmac.c - mac MPW execunix.c - UNIX, OS/2, NT execvms.c - VMS 2) Defining OTHERSYMS in jam.h So that the Jambase and Jamfile know their host, Jam defines $(OS) to be something useful for each platform. Make sure that there is code in jam.h to generate a useful value for $(OS), and key it off the platform specific C-preprocessor symbol. If the C-preprocessor doesn't itself defines such a symbol, add a define to the Makefile. In addition to $(OS), you can also set $(OSPLAT) if the OS runs on multiple platforms (like Linux or NT), or $(OSVER) if the OS has multiple, incompatible releases, like HPUX 9 and 10 and AIX 3 and 4. 3) Working out system dependencies in the Jambase With the value of $(OS) available, the Jambase can be extended to support special variables or rules for new platforms. See the current support for VMS, NT, and Mac. 4) Yacc troubles The generated files jamgram.h and jamgram.c are distributed for the poor souls without yacc. 5) Known problematic systems: - Pyramid has no malloc.h, memory.h - Encore has no stdlib.h - Bull DPX has sys/file.h problems 6) Send the results back. If you do porting work, the result can be integrated into future releases if you send it back to the author's adress in the README.