section m of routines in global.i

all functions - m

mac_primitives


    mac_primitives, file  


sets FILE primitive data types to be native to MacIntosh, 8 byte double.  
Interpreted function, defined at i0/std.i   line 2913

macl_primitives


    macl_primitives, file  


sets FILE primitive data types to be native to MacIntosh, long double.  
Interpreted function, defined at i0/std.i   line 2921

make


    make  
 or make, path  
 or make, path, template=1  
 or make, path, template="Makefile_name"  


 creates or updates the Makefile for a compiled package (plugin).  
 If PATH is given, it is the directory containing the source code  
 for the package; by default, PATH is ".", the current working  
 directory.  
  
 With the template= keyword, a template Makefile is written, which  
 you can use as a starting point, filling in all the necessary  
 information by hand.  In this case, make makes no further checks  
 on the contents of the directory.  In the first form, the name of  
 the Makefile template is "Makefile", but if the template= keyword  
 is a string, that name is used instead.  The template Makefile  
 will not function at all until you edit it.  
  
 Alternatively, without the template= keyword, make looks at the  
 contents of the directory, and fills in as much of the Makefile  
 as it can using what it sees.  There are two cases:  
 1. A Makefile (or makefile) already exists.  Provided the file  
    contains a Y_MAKEDIR= line, make merely updates Y_MAKEDIR,  
    Y_EXE, and Y_EXE_PKGS to reflect this running yorick, and  
    attempts no other modifiactions of the existing Makefile.  
 2. No such Makefile exists.  Then make writes a template Makefile,  
    and reads all the .i interpreted source files, .c and .h C source  
    files, and .f or .F or .m Fortran source files in the directory,  
    filling in as much of the Makefile as possible.  In simple cases,  
    the resulting Makefile will be perfectly adequate.  (If there  
    is any Fortran source, however, it will never be adequate.)  
  
 In case 2, the following steps are taken:  
 A. Any .i files containing lines of the form  
     plug_in, "pkname"  
   or  
     if (!is_void(plug_in)) plug_in, "pkgname"  
   are identified as the "package include file(s)" which define  
   the interpreted API for the package.  The make function takes  
   the name of the package from the "pkgname" in these lines.  
   At least one .i file must contain at least one plug_in line;  
   at most one "pkgname" must occur in all the plug_in lines in  
   all the .i files in the directory.  This information is used  
   to fill in the PKG_NAME macro and the PKG_I macro in the  
   Makefile (the latter becomes a list of every .i file containing  
   a plug_in statement).  
 B. All .c, .f, .F, or .m files are assumed to be required compiled  
   source, and the OBJS macro in the Makefile is set to a list of  
   all corresponding .o object files.  
 C. If there are any .h C header files in the directory, every .c  
   C source file is scanned for an include directive which reads  
   the header.  An approriate dependency line for each .o file which  
   is discovered to depend on local .h files in this manner.  
 These steps will be sufficient to produce a finished Makefile in  
 many simple cases; an example is given in the extend/ directory of  
 the yorick distribution (a compiled complementary error function).  
  
 However, it is impossible for yorick to automatically discover  
 complicated Makefile rules your package may require.  The most  
 common example is dependency on a third party library, which  
 requires a -l loader option, and very possibly a -L option as  
 well.  You need to add these flags to PKG_DEPLIBS in the Makefile  
 by hand.  If you want such a package to be buildable by non-experts,  
 you will need to provide a configure script in order to fill in  
 the required information across a wide variety of platforms.  This  
 can be exceptionally challenging, which is why yorick itself has  
 no dependencies beyond what is guaranteed to be present on every  
 system where it can run (libc, libm, and, on Unix systems, libX11).  
  
 Once the Makefile has been built it becomes part of the source code  
 of your package, and should not be removed.  (You may want it to  
 have an include directive to get the results of any configure script  
 which must be run, however.)  Thereafter, use  
   yorick -batch make.i  
   (or simply make in a running yorick)  
 to set Y_MAKEDIR, Y_EXE, and Y_EXE_PKGS appropriately for the  
 particular platform where you are building (case 1 above).  
  
 Read Y_HOME/Makepkg for a description of the various make targets  
 available.  In a nutshell:  
   make debug          builds a debugging version (never a plugin)  
   make                builds a release version (a plugin if possible)  
   make install        installs the release version (may require root)  
   make clean          removes all results, leaving only original source  
  
   Interpreted function, defined at i/make.i   line 6