(Last modified by Gil madar on 11 April 1997)

		mgen (MakeGENerator) users' guide

1. General

	mgen is a utility for programmers. It intends to help programmers
creating makefiles for applications / libraries. It was written for my own
usage and fun, and after using it under different programming envionments,
such as MS-windows, MS-DOS and Linux, I added the MakeGENerator many features
as requested by my friends and their needs. The MakeGENerator has grown into
a flexible tool, yet, very easy to use and learn.

2. Using the MakeGENerator

	The MakeGENerator is easy to run. It receives an arguments' file, and
performs a recursive search for the header files included in the C-language
source files, and saves this list of header files into a makefile. It contains
more features, but thats all for now. You can read about these features in
sections 2.4.* .

2.1 Fast start using the MakeGENerator

	In this quick introduction, we will create a makefile named "example"
for the source files of this product. For this, I will need you to do some
initial work before.

2.1.1 Initial assumptions

	First of all, I assume your current working directory is "src", and
you wish to create the makefile named "example" in the current working
directory. For this, please create a file named "example.mak" in the current
directory, which consists of the following two lines:
line #1: "-Mexample"
line #2: "-sexample.mak"

2.1.2 do it!

	Now all you have to do is run the "../bats/mgen example.mak" command
from the command line. You will see a banner, and a list of header files that
mgen could not find. If you will list the files in your directory, you will
have a new file named "example". This is the first makefile that you generated
using MakeGENerator. Congratulations! Perhaps it does not match your personal
configuration, but, very soon it will be match better. You must have noticed
a few lines were added to your "example.mak", which we will refer to as "your
profile".

2.2 Initial assumptions

	The following is a list of assumptions. Some of the assumptions are
not realy a must, but, its easier to think of it as one, for a start.

2.2.1 Package layout

	I assume you wish to create binary executable for this MakeGENerator.
As you can see, the files are already put in a certain order, which I find,
easy to manage:
---mgen--
	|---bats	script files for compilation, and mgen binary
	|---control	control files such as *.lnk, *.cfg
	|---doc		mgen documentation
	|---ext		mgen binary
	|---obj		object files
	|---src		source files and makefiles

2.2.2 Terms

	Here, I'll try to explain some of the terms I use in this document.
Some of them are quite simple

2.2.2.1 target

	target in a makefile is a string of characters, which is positioned
at the beginning of a line, perhaps followed by whitespaces, and a ":". Any
such string is a valid node in the makefile, which we might want to "make".

2.2.2.2 main target

	The main target, is a target that depends on all the targets which
could be created for all the source files. In this MakeGENerator, the main
target is, usually, an executable or library (archive file), which depends on
all the possible object files, for the given source files.

2.2.2.3 secondary target

	The secondary targets are the target that the MakeGENerator creates
for each of the source files, whether the search for header files is performed
for the source file, or not. Other types of secondary targets, are the ones
a user would like to define automaically, or, by himself, using iclusion of
an external file.

2.2.2.4 main secondary targets

	The main secondary targets are the secondary targets introduced in the
previous section.

2.2.2.5 dependency list

	A target's dependency list, is a list of files. The change of any of
these files requires the generation of that target. For a main target, this
could be the list of object files which compose the executable, or library,
plus, user's specific files, if requested.

2.2.2.6 link commands

	By "link command", we mean, the list of commands that would have to
be performed, in order to create the main target from the secondary targets,
assuming all the files in the dependency list of the main target, are up to
date.

2.2.2.7 compile commands

	By "compile command", we mean, the list of commands that would have
to be performed, in order to create the secondary target from it's source
files, assuming all the files in it's dependency list are up to date.

2.2.2.8 extra extentions

	Extra extentions are the extentions of source files, which recursive
search of header files, is not performed for. Yet, we do create secondary
targets for these source files. You can see those extentions as extentions
for languages, which, are not yet, supported.

2.2.2.9 maximum searched lines per file

	The maximum searched lines per file, is the number of lines, which we
will search, in every source file, for the "#include" directive. A value of 0
(zero), which is the default, means - search all the lines in the files.

2.2.2.10 source pattern

	The source pattern is a list of filenames and simple patterns, such
as *.c or /home/users/linda/proj/src/*.cxx. The MakeGENerator will try to
perform the recursive search for these files, first. The default search
pattern is *.c .

2.2.2.11 mgen profiles

	The mgen profiles, are the files from which it takes parameters that
modify the default behaviour of it. The MakeGENerator supports usage of
multiple profiles. The last profile in the command line (see bellow) overrides
switches set by it's predesessors.

2.2.2.12 logical path

	Logical path is a representation of a certain path, using a name which
is more easy to remember. that name, is implemented using the macro mechanism
in makefiles. This mechanism is supported by most make utilities. Using the
macro definition, we can describe the file, in a human readable manner. These
macros can be defined in the profile, or, as environment variables.

2.3 Command line switches

	The command line for the MakeGENerator could be shown, simply, running
from the command line the command "mgen". The command line synopsis is as
follows:
	mgen {filename[s] | -[H|h|?]}

2.3.1 No switches at all

	Without any switch, you will see a small explanation about the command
line.

2.3.2 -[?Hh] switches - Getting help

	Running mgen -?, or, mgen -h, or, mgen -H, you will receive some help
screens about the different flags and macros that could appear in the
profiles.

2.3.3 mgen profile1 [profile2[...]] - Makefile generation

	Running mgen with a non empty list of profiles, the MakeGENerator
would read the switches from the files, and generate the requested makefile.
Switches from the last profiles, may override previous switches, taken from
the first profiles. On the other hand, they might be appended to the switches
from the first profiles.

2.4 Configuration file parameters

	The different profile's switches, enable the user with alternation of
the output file, the makefile generated by the MakeGENerator. If a switch can
occur with a '-' prefix and a '+' prefix, The instance of the switch with the '-' 
prefix, overrides any previos definition of the switch, with any of the
prefixes.

2.4.1 -P{PATH} - Starting new search path

	The "-P" switch enables the definition of a new search path for header
files. If a search path was already defined, this switch overrides it.

2.4.2 +P{PATH} - Continuing search path

	The "+P" switch enables the user to append a directory to the current
search path for header files.

2.4.3 -R{subdir name} - Seting linker's run directory

	The linker run directory, is the name of the directory from where we
should run the link (or archive) command. This location is relative to the
upper working directory. Sound complex? It's not. According to the package
layout, we run the MakeGENerator from the "src" directory. If the link command
is supposed to be run from the directory where all the object file are, that
is, directory "obj" relative to the upper working directory. Thus, we will
have to set the linker run directory to "obj" by "-Robj".

2.4.4 -O{subdir name} - Seting linker's output directory

	The linker output directory is the name of the directory where we will
keep the product of the link (or archive) command. This location is relative
to the upper working directory. According to the package layout, we keep the
product of the the link command in the "ext" directory, relative to the upper
working directory. Thus, we will have to set the linker's output directory to
"ext" by "-Oext".

2.4.5 -o{subdir name} - Seting compiler's output directory

	The compiler output directory is the name of the directory where we
will keep the product of the compile command. This location is relative to the
upper working directory. According to the package layout, we keep these object
files in the "obj" directory, relative to the upper working directory. Thus,
we will have to set the compiler's output directory to "obj" by "-oobj".

2.4.6 -L{link command} - Setting new link commands

	The purpose of link command is to create the main target, once all the
secondary targets are up to date. The link command can be a sequence of acts.
The setting of a link command is done using the "-L" switch. Assuming we are
creating a library, from all the object files in the current directory using
the "ar a libtemp.a *.o" command, we can set the link command using this line
in the profile: "-Lar a libtemp.a *.o".

2.4.7 +L{link command} - Continuing link commands

	If we wish to add an activity to the list of actions done for creation
of the main target, we can use the "+L" switch. Assuming we want to move the
created archive file into ../ext/libapp.a, and print a message to the screen
saying "Library is updated", we can use the "+Lmv libtemp.a ../ext/libapp.a"
switch in the profile, followed by "+LLibrary is updated".

2.4.8 -l{num} - Setting maximum searched lines per file

	By default, the MakeGENerator searches the C language source files for
lines containing the "[whsp]#[whsp]include[whsp]{<|"}[filename][whsp]{<|"}",
where "whsp" stands for "whitespace", for all the lines. The user can instruct
the MakeGENerator to perform the search only on the first nn lines, by using
the "-lnn" switch. For example, if the user wants the search to be performed
only on the first 20 lines, [s]he can add the "-l20" in the profile.

2.4.9 -C{compile command} - Setting new compilation commands

	The "-C" switch is used to start the definition of set of activities
that must be done for creation of each of the secondary targets derived from
C language source files. The compile command can be very simple, and contain
"-Lgcc -c" only, and it can be very powerful, taking the advantage of using
the MakeGENerator's macros in the compile commands. For more about these
macros and thir usage, see section "Compile and Link command-line macros".
	for the "-Lgcc -c" definition, the MakeGENerator will generate the
following compilation command for file demo.c: "gcc -c demo.c".

2.4.10 +C{compile command} - Continuing compilation commands

	As with the link command, the compile command can be extended through
usage of the "+C" switch. We can use "+Cecho A file has been compiled" to give
the user a message while running make, that "A file has been compiled". But
this is not importent. using the MakeGENerator's macros in compile commands,
the user can do much more than that. Until section "Compile and Link command-
-line macros" its eanough to remember that the main use of this switch is with
these macros.

2.4.11 -M{file name} - Specifing the  makefile's name

	The default output filename is "makefile". If the user wants to
override this name by "anything.mak", [s]he can use the "-Manything.mak"
switch.

2.4.12 -D{file name} - Specifing new dependency list for main target

	We can add more files to the dependency list of the main target. The
switch starts the definition of additional dependency list for a main target.
This is useful if there are configuration files, that contain information
whose change forces the need to build the main target again. Assuming file
"resource.rc" contains such an information, we can add the following line in
the profile, to add the file to the dependency list: "-Dresource.rc".

2.4.13 +D{file name} - Continuing main target dependency list

	Adding more files to the additional dependency list for a main target,
is done using the "+D" switch. If we want to add file "/local/home/project.rc"
to the additional dependency list for a main target, than we can add the
following line to the profile: "+D/local/home/project.rc"

2.4.14 -d{file name} - Specifing new dependency list for secondary targets

	As for the main target, we can add more files to the dependency list
of the secondary targets. This is useful if there are configuration files,
that contain information whose change forces the need to build each of the
secondary targets. Assuming file "switches.cfg" contains such an information,
we can add the following line in the profile, to add "switches.cfg" to the
dependency list: "-dswitches.cfg". This way we start the this list of files.

2.4.15 +d{file name} - Continuing secondary targets' dependency list

	Appending more files to the dependency list of the secondary targets,
is done using the "+d" switch. If a user wants ../control/switches.cfg to be
added to to this list, [s]he simply add "+d../control/switches.cfg" to the
profile.

2.4.16 -T{extention} - Specifing the target's extention

	The user defines the main target using some values: the {extention},
the {file name}, and the linker's output directory. These three values define
the fullname of the target that will be generated. This is usefull if the user
wants a main target to have some extention. For library (archive) files, the
user can use "-Ta".

2.4.17 -t{file name} - Specifing the target's name

	The default target name, before addition of path and extention, is as
the name of the upper working directory. For the package at "Package layout"
section, it will be "mgen".

2.4.18 -e{extention} - Specifing the secondary targets' extention

	The object file extention, for files generated through compilation of
source files, is usually "o". Using other tools it can be "obj", or anything
else. If the user wants all secondary targets created through compilation of
C language source files, then [s]he should add the "-eobj" to the profile.

2.4.19 -E{source pattern} - Specifing input files

	The "-E" switch is used to start a new files' pattern, for which, we
will perform the recursive search algorithm. Usually, the MakeGENerator looks
for source files in the current directory, matching the pattern "*.c". The
user can choose other file patterns, like "*.cpp" by adding the "-E*.cpp" line
to the profile.

2.4.20 +E{source pattern} - Specifing additional input files

	Adding more file patterns, for which, we will perform the recursive
search algorithm, is done using the "+E" switch. If a user wants to add to the
list of files, "*.c" files from directory "/home/users/project/package1/src",
then, [s]he would have to add the "+E/home/users/project/package1/src/*.c"
line to the profile.

2.4.21 -F{linker flags} - Specifing LINKER_FLAGS macro

	The user may use this flag to create a macro in the makefile , named
LINKER_FLAGS. If the user adds the "-Fsome taxt" line to the profile, than,
the "LINKER_FLAGS=some taxt" line is added to the makefile.

2.4.22 -f{compiler flags} - Specifing COMPILER_FLAGS macro

	The user may use this flag to create a macro in the makefile , named
COMPILER_FLAGS. If the user adds the "-fsome taxt" line to the profile, than,
the "COMPILER_FLAGS=some taxt" line is added to the makefile.

2.4.23 -B{full | uwd} - Specifing BASE_WD macro

	This flag is used to set the value of a macro in the makefile, called
"BASE_WD". This macro may be assigned one of two values: "full" is the full
path of the current working directory, and "uwd" is "..".

2.4.24 -I{file name} - Specifing a file to be included in the makefile

	The user can force the inclusion of a file into the makefile, before
the definition of the main target. This can be usefull if [s]he wants to
include a global macro definitions file. Assuming the project has a such a
file, named "/home/users/project/control/macros.mak", than, the user can
include it using the "-I/home/users/project/control/macros.mak" switch.

2.4.25 -i{file name} - Specifing a file to be included in the makefile

	The user can force the inclusion of a file into the makefile, after
the definition of the last secondary target. This can be usefull if [s]he
wants to include additional targets file. Assuming the project has a such a
file, named "/home/users/project/control/targets.mak", than, the user can
include it using the "-I/home/users/project/control/targets.mak" switch.

2.4.26 -N{bwd[+- ]} - Enabling / Disabling usage of BASE_WD macro

	If the user adds the "-Nbwd+" or "-Nbwd" line to the profile, all the
secondary targets will be named using the "BASE_WD" macro, which has been
introduced earlier. For example, if one of the source files is "demo.c", and
it is located in "/home/users/project/package1/src". If the user enables the
above switch, the secondary target that will be created for it will be ...
"$(BASE_WD)/obj/demo.o", instead of "/home/users/project/package1/obj/demo.o".
The switch'es default is disabled.

2.4.27 -N{exe[+- ]} - Enabling / Disabling definition of EXE_FILE macro

	If the user adds the "-Nexe+" or "-Nexe" line to the profile, a macro
named "EXE_FILE" is added to the makefile, and this macro becomes, also, the
main target. That is, the name of the main target is "EXE_FILE". The switch'es
default is disabled.

2.4.28 -N{obj[+- ]} - Enabling / Disabling definition of OBJECTS macro

	If the user adds the "-Nobj+" or "-Nobj" line to the profile, a macro
named "OBJECTS" is defined, and it holds all the secondary targets. This is
usefull if the user wants to use the list of object files in the link command.
For example, for a command such as "gcc -o $(EXE_FILE) $(OBJECTS)". The
switch'es default is disabled.

2.4.29 -N{inc[+- ]} - Enabling / Disabling definition of INCLUDE_PATH macro

	If the user adds the "-Ninc+" or "-Ninc" line to the profile, a macro
named "INCLUDE_PATH" is defined, and it holds all the pathes used for the
search for include files. This macro has a formatting ability which we will
explain later. The switch'es default is disabled.

2.4.30 -N{com[+- ]} - Enabling / Disabling usage of COMPILER macro

	If the user adds the "-Ncom+" or "-Ncom" line to the profile, a macro
named "COMPILER" is defined, and it holds the command used for the compilation
of a C language source file. For compilation using "gcc -c -I$(INCLUDE_PATH)",
The user enables the definition "COMPILER=gcc -c -I$(INCLUDE_PATH)" in the
makefile, and also, for each compilation line, for each of the secondary
targets, we will have the macro being used in the command. than, instead of
"gcc -c -I$(INCLUDE_PATH) demo.c", we will have "$(COMPILER) demo.c". The
switch'es default is disabled.

2.4.31 -N{lin[+- ]} - Enabling / Disabling usage of LINKER macro

	If the user adds the "-Nlin+" or "-Nlin" line to the profile, a macro
named "LINKER" is defined, and it holds the command used for the linking of
the secondary targets, into the main target. If linking the main target using
"gcc -o $(EXE_FILE) $(OBJECTS)", The user enables the definition of the macro
"LINKER=gcc -o $(EXE_FILE) $(OBJECTS)" in the makefile, and also, the usage of
the macro in the link command which becomes $(LINKER). The switch'es default
is disabled.

2.4.32 -N{rel[+- ]} - Enabling / Disabling usage of relative pathes

	If the user adds the "-Nrel+" or "-Nrel" line to the profile, [s]he
enables the usage of relative file names in the makefile. The file "demo.c"
which appears in the dependency list of "../obj/demo.o" using the full path to
the file. Enabling this switch, it will be appearing as "demo.c" only. The
switch'es default is disabled.

2.4.33 -N{mis[+- ]} - Enabling / Disabling missing files list

	If the user adds the "-Nmis+" or "-Nmis" line to the profile, [s]he
will get the list of missing header files added to the makefile, as a comment.
Without it, this list will be presented on the screen only. The switch'es
default is disabled.

2.4.34 -N{flat_P[+- ]} - Enabling / Disabling flat search path in profile

	The profile holds the list of header files' search pathes. This list
can appear in the profile, if asked to save one, using a list of directories
seperated using a semicolon, or, using one "-P" line, followed by some "+P"
lines. The first form is enabled if the user adds the "-flat_P" line, or the
"-flat_P+" line to the profile. The switch'es default is disabled.

2.4.35 -N{flat_L[+- ]} - Enabling / Disabling flat link command in profile

	The profile holds the list of commands to be performed in the linking
phase. This set of commands can appear in the profile, if asked to save one,
using a list of commands, seperated by a "\\n", or, using one "-L" line,
followed by some "+L" lines. The first form is enabled if the user adds the
"-flat_L" line , or the "-flat_L+" line to the profile. The switch'es default
is disabled.

2.4.36 -N{flat_C[+- ]} - Enabling / Disabling flat compile command in profile

	The profile holds the list of commands to be performed in the compile
phase. This set of commands can appear in the profile, if asked to save one,
using a list of commands, seperated by a "\\n", or, using one "-C" line,
followed by some "+C" lines. The first form is enabled if the user adds the
"-flat_C" line , or the "-flat_C+" line to the profile. The switch'es default
is disabled.

2.4.37 -N{flat_D[+- ]} - Enabling / Disabling flat Dependency list in profile

	The profile holds the dependency list of main target. This list of
files can appear in the profile, if asked to save one, as a list of files,
seperated by a semicolon, or, using one "-D" line, followed by "+D" lines. The
first form is enabled if the user adds the "-flat_D" line, or the "-flat_D+"
line to the profile. The switch'es default is disabled.

2.4.38 -N{flat_d[+- ]} - Enabling / Disabling flat dependency list in profile

	The profile holds the dependency list of secondary target. This list
of files can appear in the profile, if asked to save one, as a list of files,
seperated by a semicolon, or, using one "-d" line, followed by "+d" lines. The
first form is enabled if the user adds the "-flat_d" line, or the "-flat_d+"
line to the profile. The switch'es default is disabled.

2.4.39 -N{source_files[+- ]} - Enabling / Disabling definition of SOURCE_FILES macro

	If the user enables this switch, by adding the "-Nsource_files" line,
or the "-Nsource_files+" line, to the profile, a macro named "SOURCE_FILES"
will be created in the makefile, and it will ontain the list of C language
source files, not including header files. The switch'es default is disabled.

2.4.40 -N{make_depend[+- ]} - Enabling / Disabling "depend:" label

	If the user enables this switch, by adding the "-Nmake_depend" line,
or the "-Nmake_depend+" line, to the profile, a target named "depend" is added
to the makefile, and it will ontain the command used to create the makefile,
to enable updating it, simply by running "make depend" at the command line.
The switch'es default is disabled.

2.4.41 -N{flat_inc[+- ]} - Enabling / Disabling flat INCLUDE_PATH

	If the user enables this switch, by adding the "-Nflat_inc" line, or
the "-Nflat_inc+" line, to the profile, the "INCLUDE_PATH" macro will be added
to the makefile, as a multi line macro. Otherwise, the macro will apear as a
single line macro. The switch'es default is disabled.

2.4.42 -N{flat_E[+- ]} - Enabling / Disabling flat source files in profile

	The profile holds the dependency list of C language source files. This
list of files can appear in the profile, if asked to save one, as a list of
files, seperated by a semicolon, or, using one "-E" line, followed by "+E"
lines. The first form is enabled if the user adds the "-flat_E" line, or the
"-flat_E+" line to the profile. The switch'es default is disabled.

2.4.43 -N{"inc_prefix "} - Formatting INCLUDE_PATH

	The user can have a very limitted formatting ability over the printed
"INCLUDE_PATH" macro. Assuming the "/usr/include;/home/user/project/include"
is the user's header file search path, if the user adds the "-Ninc_prefix  -I"
line into the profile, the next line would appear in the generated makefile:
"INCLUDE_PATH= -I/usr/include -I/home/user/project/include".

2.4.44 -N{use_logical_pathes[+- ]} - Enabling / Disabling logical pathes

	The user can define logical names, for almost every location of header
files. These logical names will be defined using the macro support mechanism
presented in the next section. If the user adds the "-Nuse_logical_pathes+"
line, or, "-Nuse_logical_pathes" line in the profile, than, header files found
in such a location, will apear using the logical name. Assuming the name "inc"
is a user defined macro, defined as in the "Specifing user defined macro"
section, to be "/usr/include", and added to the header files search path by
adding "+P$(inc)" to the profile. If the "-Nuse_logical_pathes+" line, or the
"-Nuse_logical_pathes" line is also added to the profile, than the "stdio.h"
found at "/usr/include", will appear in the secondary target dependency list
as "$(inc)/stdio.h".

2.4.45 -m{name = text} - Specifing user defined macro

	If a user wants to start defining macros in the profile, [s]he will
have to add a "-m" line to the profile. A "-m" line dismisses any previous
macro definition. To dismiss any previous macro definition and to define the
name "inc" to be a macro which is equal to "/usr/include", the user will have
to add the "-minc = /usr/include" to the profile.

2.4.46 +m{name = text} - Adding user defined macro

	To add another macro definition, or, to override the macro's previous
definition, the user will have to add a "+m" line to the profile. If the user
wans name "inc" to be a macro which is equal to "/usr/include", the user will
have to add the "+minc = /usr/include" to the profile. The user can also use
a previously defined macro, to define another one. First, the user can define
"+mu = /usr", than, "+minc = $(u)/include". As Said before, now "$(inc)" can
be added to the header files search path by adding "+P$(inc)" to the profile.

2.4.47 -X{[0-9]{target}.{source}{compile cmd}} - Specifing extra extentions

	A user can specify file extentions for which secondary targets will be
created, but no search algorithm will be performed to search for header files.
This mechanism intends to help the user, to combine other languages' source
files into the makefile. For examle, if a user wants to combine assembly files
with extention ".asm", to the makefile. Assuming the files are compiled using
the command "assem", and the generated file ends with a ".obj" extention. Than
the the line "-X0obj.asm.assem" will have to be added to the profile, in order
to enable the generation of the coresponding secondary target. If the assembly
file is "startup.asm" then the secondary target which will be generated for it
is "../obj/startup.obj:".

2.4.48 -S{spc | nl} - Specifing dependet seperator

	A user can instruct the MakeGENerator to write the dependency list of
a target in one line, using the "-Sspc" line in the profile. Otherwise, the
default will be taken, which is "-Snl".

2.4.49 -s{profile} - Saving configuration into profile

	Using this switch, a user can save the current configuration, perhaps
based on more than one profile, into a new profile. You have already seen, its
use in the "Fast start using the MakeGENerator" section.

2.5 Compile and Link command-line macros

	The MakeGENerator supports its own macro support, intended to enable
the user to have greater flexibility, in the definition of the compilation
command, in the profile. These "macros" behave actually like prcedures which
work on the current target's source filename, and return a string.

2.5.1 \fn | \filename - file's name with extention

	For each filename, this macro returns the string itself. That is, the
expansion of "\fn" (same as "\filename") for the file "../../pkg2/src/demo.c"
will be "../../pkg2/src/demo.c" itself. For file "example.c" it will be
"example.c".

2.5.2 \bn | \basename - file's name without extention

	For each filename, this macro returns the base name of the string.
That is, the expansion of "\bn" (same as "\basename") macro for the file
"../../pkg2/src/demo.c", will be "../../pkg2/src/demo". For file "example.c"
it will be "example.c".

2.5.3 \xt | \extention - file's extention

	For each filename, this macro returns the extention of the string.
That is, the expansion of "\xt" (same as "\extention") macro for the file
"../../pkg2/src/demo.c", will be "c". For file "example.asm" it will be "asm".

2.5.4 \n | \newline - NEWLINE (\n) followed by TAB (\t)

	For any source filename, the expansion of the "\n" (same as
"\newline") will be the C-language string "\n\t".

2.5.5 \bs | \backslash - BACKSLASH (\\)

	For any source filename, the expansion of the "\bs" (same as
"\backslash") will be the C-language string "\\".


3. Restrictions over using MakeGENerator

	As in the GNU General Public License. For more information,
see file copying.

3.1 Copyright, Banners, and Version notes

	I have spent a long time on this program, and I wish all the banners,
the copyright and version notes, will not be removed from the code.

3.2 Responsibility over using the MakeGENerator

	I found no problems using the MakeGENerator. It is stable, and does
not trash the file system. Yet, I still have to add the following: "Gil-ad
Madar will not be responsible for usage of the MakeGENerator, in
any matter, at any time, for any reason".

4. Credits

4.1 For my wife

	I wish to thank my wife, Vered, for not getting mad, after all
the mess I created, while I was trying to install Linux on our PC that
runs MS-DOS, for porting the MakeGENerator to UNIX.

4.2 For my friends

	I wish to thank my friends, for giving me feedbacks on the
MakeGENerator, while using it for their programming needs.

5. Miscelenous

	Here are some matters, that I found no better place to add them.

5.1 Comments and Bug reports

	I would be very happy to accept comments on the MakeGENerator, and fix
any bug, that any of you, might have found. There is no such one, that I know
of, but, it is possible that the MakeGENerator still contains a one. If you
find one, please, report it to me.
	I wish this program will serve the programmers' comunity, as best as
it can. Some of it, depends on finding the bugs, that were not found by me and
my friends, who use the MakeGENerator. Some of it, depends on adding features,
that many of you, would like to have in it.
	The code is given to the users. If someone thinks there is a way to
make the MakeGENerator, serve it's users better, or, serve more users, I
encourage this user to write me of her/his ideas. I will try to merge these
ideas, for the benefit of all users. I will continue to support the
MakeGENerator.

5.2 TODO

	I think, this is all I need for my own use. In a week, or, in a month,
I will, probably change my mind. Perhaps I'd like to have support for other
languages, different makefile formats, generalization of the search routines,
wildcards in the file patterns, and many more. This is how I made it, till
version 3.64 . It's an evolution of a program, not a product of a precise
engeenering process. I encourage each of the users to send me her/his list of
features to add. Perhaps it will be added to future releases, since I intend
to keep on supporting it.

5.3 Contacting the MakeGENerator's programmer

	The Reccomended way to reach me is throu e-mail.

5.3.1 Thru e-mail

	gil-ad@inter.net.il

5.3.2 Thru voice

	+972 8 9283 116		- at reasonable hours, please.

5.3.3 Thru mail

	Gil-ad Madar
	Box 1334
	Be'er Ya'akov
	Israel

5.4 Versions
5.4.1 mgen current version is 3.65
5.4.2 This document's version is 1.00

6. Additional documentation

6.1 How to make an executable

	See file how2make.inf, for information on the creation of executables
for your system.

6.2 List of files

	See file files.lst, for the list of files included in this version.

6.3 Help screens' contents

	See file screen.inf, which contains the content of the help screens,
which are accessible by running "mgen -[Hh?]".

6.4 Linux Software Map (LSM) File

	The mgen.lsm file was sent to lsm@osf-alpha.cs.helsinki.fi and to
sunsite.unc.edu .
