Dec 192017
MAKEPREP is a utility that removes the drudgery in preparing large make files. MAKEPREP collects a set of basic information, scans the C and ASM files in the current directory, and then formulates the make file. | |||
---|---|---|---|
File Name | File Size | Zip Size | Zip Type |
MAKEPREP.DOC | 10345 | 4278 | deflated |
MAKEPREP.EXE | 122071 | 51915 | deflated |
MAKEPREP.UL | 388 | 257 | deflated |
Download File MKPREP.ZIP Here
Contents of the MAKEPREP.DOC file
Usage summary
=============
In essence, MAKEPREP is fairly easy to use and should present no
problems after you get accustomed to its operation. To get you
started, the following detailed instructions can be used.
First, move ALL of the relevant code into the TC home directory.
This includes everything you want to rebuild: header files, ASM
support modules, and C programs.
Then examine what you want to do in terms of the following:
- some entities should be compiled and placed in
libraries (LIB files). These are support modules.
Determine which libraries you want to make.
- some entities should be compiled and linked with
the default libraries only (EXE files).
- other entities should be compiled and linked with
one or more of the support libraries you made.
- some entities should simply be compiled as
standalone OBJ files.
Then run MAKEPREP and redirect your output.
MAKEPREP > MAKEFILE (or whatever the makefile should be named)
The first thing you should see is the MAKEPREP information panel.
This is simply collecting text strings for MAKE macros. As it
is set up in the default case, MAKEPREP assumes:
- that you are using TASM, TLINK, TC, and TCC.
- that you are using a RAM drive (D:) for all your
RTL prototypes and default libraries.
- that you want LARGE model compiles.
- that your various options are as shown.
These assumptions can be altered by simply typing in new values.
In fact, you can convert the entire MAKE file to Microsoft format
by simply doing block moves in your editor.
After filling out the information panel, the process resolves
itself into simply making menu choices.
When MAKEPREP is done, use an editor to make final touch ups,
make sure you have lots of room on your drive for the OBJ and
LIB files, start up the MAKE utility, and go read the Sunday Times.
Doing just this, with no changes whatever to the MAKE file (several
"touches" and several source modifications necessary, however), I
recompiled over 4 meg of source, which included:
- the entire C-SCAPE library
- BLAISE Tools for Turbo C
- my own QLIB version 5
- zillions of demo and how-to files
downloaded from go bor and go msoft
- all my utilities, games, and hacking tools
- various and sundry one-off applications
Detailed description of processing flow
=======================================
Normally, I don't do this, but assuming that the users of MAKEPREP
are sophisticated C programmers, and therefore kindred spirits,
here goes...
MAKEPREP first calls ioctl to assure that stdout is in cooked mode
and has been redirected.
It then zips through the current directory making a linked
list of any files with extensions of .C, .H, and .ASM.
After that, MAKEPREP mallocs ((unsigned) (unsigned-1)) of
memory for a reading buffer.
For each file in the list, MAKEPREP opens the file and looks
for any occurence of an #include statement using quotes
(#include "this.h"). Where these exist, the included file is
added to a MAKE rule for that file. The included file is also
deleted from the linked list.
Just to help things, MAKEPREP checks to assure that the included
file is present in the current directory. If not, a warning
message is popped.
The reading buffer is then freed to make room for the windows.
When this is complete, MAKEPREP then offers the menu to set
the disposition of each entity. This is when the list of libraries
is set up. When the disposition menu is offered, MAKEPREP backlights
the screen with the dependency rule as it currently exists.
For each entity to be updated to a library, MAKEPREP obtains the
library name. For C files, MAKEPREP uses the $(COMPILER) macro,
for ASM files, MAKEPREP uses the $(ASSEMBLER) macro.
After the disposition is known for each entity, MAKEPREP reiterates
the list for each entity to be compiled into an EXE file. Here,
MAKEPREP offers the list of libraries it has built. You can
select multiple libraries to be linked at link time.
After this, MAKEPREP prints the macro definitions to stdout.
MAKEPREP then formulates a pseudo MAKE rule called COMPLETE, this
rule assures that all libraries get created and all EXE files
get linked. It says that COMPLETE is dependent upon all your
EXE, LIB, and standalone compiles.
MAKEPREP then lists out the rules for each of your libraries. These
are not followed by commands, like the COMPLETE rule, because there's
no reason to.
MAKEPREP then lists out the rules to create any EXE files. This is
followed by the rules to compile each entity, and finally by the
rules to compile standalone OBJ files.
Limitations
===========
MAKEPREP needs lots of memory to work with. The heap structure,
for example is
typedef struct heap_struct {
int disposition;
int compile_to_lib_id;
int compile_to_exe_lib_ids [MAX_LIBRARIES + 20];
unsigned char dependentfiles [DEPENDENT_LENGTH];
int dependentcount;
unsigned char make_rule [DEPENDENT_LENGTH];
unsigned char first_fname[9];
struct ffblk heapblk;
struct heap_struct *heap_next;
};
The most taxing use I put MAKEPREP to was recompiling the CSCAPE
and BLAISE libraries. I did this in two separate passes, using
TASM, TCC, and TLIB. In both cases, I had false starts getting
the case sensitivity switches just right. After that MAKE happily
chugged away without a hitch.
MAKEPREP thinks that the only OBJ files that should be included
at link time are the C0X.OBJ and the target file itself. Support
functions should be incorporated into libraries. Of course, you
can simply edit the makefile to circumvent this constraint.
MAKEPREP thinks that a source file larger than ((unsigned) ((unsigned)-1))
is an abomination and will not deal with it. For that matter,
neither does TC.
MAKEPREP thinks that conditional #include statements (#ifdef...)
should be restricted to RTL prototypes and are therefore
irrelevant. So are nested includes.
Problem areas
=============
For modules destined to become EXE files, MAKEPREP wants to know
what libraries should be searched at link time. It offers a
bounce-bar menu of all the libraries it knows about. The first
selection is "FINISHED, GO TO NEXT FILE", the second allows you
to "ADD" a library to the list (select this option if you are
using Blaise, C-scape, etc). In this menu, you should select
any of the libraries needed to perform a clean link. Each library
you select is added to the dependency rule and to the link command.
When you select "FINISHED", the macro $(DEFAULT_LIBRARIES) is added
to the link command. In the beginning, this was confusing for me,
and I tried several different ways of handling it. Think of it
this way. If you have a straight C program, simply select
"FINISHED", this means compile with just the default libraries.
If you have a program that needs a Blaise/C-scape (etc)
library, "ADD" it to the list, select it, then select "FINISHED".
If you have a program that needs one of your custom libraries, select
it, then select "FINISHED". And so on... This is a usability issue
and not a problem area.
Without doubt, the first area to check is the make macros. Be sure
they are consistent with your own environment. By the way, to
invoke the Turbo editor on a file without an extension, try this:
TC MAKEFILE. (the dot is the trivia bit).
The next place to check is the file dates. You may have to do some
"touching" up to get things just right. To start, you can try
something like:
FOR %1 IN (*.H) DO TOUCH %1
You can also use my restamp utility to initialize the file
dates.
Converting from MASM to TASM in mixed mode programming can cause
some false starts where case sensitivity is concerned. You may
be faced with having to global change some all caps calls with
lower case and vice-versa.
Conflicting header files, conflicting structure definitions? Now
is as good a time as any to fix things.
Duplicate functions? Same advice...
Lots of junky C and H fragment files laying around? Erase them...
You might also try my HARDARC utility, which zips through the
entire hard drive and offers to ARC any directory with more
than two files in it.
A final suggestion, why not set up a header file called c_vrsn.h,
and include it in all your entities. This file contains a single
line:
#define COMPILER_VERSION "TURBOC 2.0"
This might make the transition to 2.X or 3.X or whatever a little
easier.
Opinions and miscellaneous drivel
=================================
After checking things out in my own way, I see no reason to use
MS LINK over TLINK. In fact, for all but the most arcane and
offbeat purposes (like CLIPPER and so forth), TLINK should be
the linker of choice. Why? definitely faster, no segment
limitations, packed segments, far call translation, etc. etc.
With the exception of protected mode and dynamic linking, TASM
seems to be faster and cleaner. I also find the output more
informative.
Although I find TC and TCC to be superior C compilers,
I cannot totally abandon CL because I just love the /Zg
option (which generates ANSI function prototypes).
I have essentially the same MAKEPREP utility for XENIX and UNIX
based environments. In fact, that's where MAKEPREP was born.
The user interface is less slick (i.e., non-existent, because
curses is such a bore compared to C-scape/Blaise), and the
vibrant options for compiling and linking are replaced with
ho-hum macros like COMPILER = cc. The only advantage is that
everything is done in the background, which gives me the
illusion of multitasking while it takes two minutes to do
a simple lc command. Maybe one day Borland will get wise and
dig into this market with an IDE letting us all kiss goodbye
to vi. On this same topic, I emphatically endorse Borland's
ANSI extensions for signal.
On a last note, if MAKEPREP has been useful to you, drop me
a line...
Garry J. Vass
=============
In essence, MAKEPREP is fairly easy to use and should present no
problems after you get accustomed to its operation. To get you
started, the following detailed instructions can be used.
First, move ALL of the relevant code into the TC home directory.
This includes everything you want to rebuild: header files, ASM
support modules, and C programs.
Then examine what you want to do in terms of the following:
- some entities should be compiled and placed in
libraries (LIB files). These are support modules.
Determine which libraries you want to make.
- some entities should be compiled and linked with
the default libraries only (EXE files).
- other entities should be compiled and linked with
one or more of the support libraries you made.
- some entities should simply be compiled as
standalone OBJ files.
Then run MAKEPREP and redirect your output.
MAKEPREP > MAKEFILE (or whatever the makefile should be named)
The first thing you should see is the MAKEPREP information panel.
This is simply collecting text strings for MAKE macros. As it
is set up in the default case, MAKEPREP assumes:
- that you are using TASM, TLINK, TC, and TCC.
- that you are using a RAM drive (D:) for all your
RTL prototypes and default libraries.
- that you want LARGE model compiles.
- that your various options are as shown.
These assumptions can be altered by simply typing in new values.
In fact, you can convert the entire MAKE file to Microsoft format
by simply doing block moves in your editor.
After filling out the information panel, the process resolves
itself into simply making menu choices.
When MAKEPREP is done, use an editor to make final touch ups,
make sure you have lots of room on your drive for the OBJ and
LIB files, start up the MAKE utility, and go read the Sunday Times.
Doing just this, with no changes whatever to the MAKE file (several
"touches" and several source modifications necessary, however), I
recompiled over 4 meg of source, which included:
- the entire C-SCAPE library
- BLAISE Tools for Turbo C
- my own QLIB version 5
- zillions of demo and how-to files
downloaded from go bor and go msoft
- all my utilities, games, and hacking tools
- various and sundry one-off applications
Detailed description of processing flow
=======================================
Normally, I don't do this, but assuming that the users of MAKEPREP
are sophisticated C programmers, and therefore kindred spirits,
here goes...
MAKEPREP first calls ioctl to assure that stdout is in cooked mode
and has been redirected.
It then zips through the current directory making a linked
list of any files with extensions of .C, .H, and .ASM.
After that, MAKEPREP mallocs ((unsigned) (unsigned-1)) of
memory for a reading buffer.
For each file in the list, MAKEPREP opens the file and looks
for any occurence of an #include statement using quotes
(#include "this.h"). Where these exist, the included file is
added to a MAKE rule for that file. The included file is also
deleted from the linked list.
Just to help things, MAKEPREP checks to assure that the included
file is present in the current directory. If not, a warning
message is popped.
The reading buffer is then freed to make room for the windows.
When this is complete, MAKEPREP then offers the menu to set
the disposition of each entity. This is when the list of libraries
is set up. When the disposition menu is offered, MAKEPREP backlights
the screen with the dependency rule as it currently exists.
For each entity to be updated to a library, MAKEPREP obtains the
library name. For C files, MAKEPREP uses the $(COMPILER) macro,
for ASM files, MAKEPREP uses the $(ASSEMBLER) macro.
After the disposition is known for each entity, MAKEPREP reiterates
the list for each entity to be compiled into an EXE file. Here,
MAKEPREP offers the list of libraries it has built. You can
select multiple libraries to be linked at link time.
After this, MAKEPREP prints the macro definitions to stdout.
MAKEPREP then formulates a pseudo MAKE rule called COMPLETE, this
rule assures that all libraries get created and all EXE files
get linked. It says that COMPLETE is dependent upon all your
EXE, LIB, and standalone compiles.
MAKEPREP then lists out the rules for each of your libraries. These
are not followed by commands, like the COMPLETE rule, because there's
no reason to.
MAKEPREP then lists out the rules to create any EXE files. This is
followed by the rules to compile each entity, and finally by the
rules to compile standalone OBJ files.
Limitations
===========
MAKEPREP needs lots of memory to work with. The heap structure,
for example is
typedef struct heap_struct {
int disposition;
int compile_to_lib_id;
int compile_to_exe_lib_ids [MAX_LIBRARIES + 20];
unsigned char dependentfiles [DEPENDENT_LENGTH];
int dependentcount;
unsigned char make_rule [DEPENDENT_LENGTH];
unsigned char first_fname[9];
struct ffblk heapblk;
struct heap_struct *heap_next;
};
The most taxing use I put MAKEPREP to was recompiling the CSCAPE
and BLAISE libraries. I did this in two separate passes, using
TASM, TCC, and TLIB. In both cases, I had false starts getting
the case sensitivity switches just right. After that MAKE happily
chugged away without a hitch.
MAKEPREP thinks that the only OBJ files that should be included
at link time are the C0X.OBJ and the target file itself. Support
functions should be incorporated into libraries. Of course, you
can simply edit the makefile to circumvent this constraint.
MAKEPREP thinks that a source file larger than ((unsigned) ((unsigned)-1))
is an abomination and will not deal with it. For that matter,
neither does TC.
MAKEPREP thinks that conditional #include statements (#ifdef...)
should be restricted to RTL prototypes and are therefore
irrelevant. So are nested includes.
Problem areas
=============
For modules destined to become EXE files, MAKEPREP wants to know
what libraries should be searched at link time. It offers a
bounce-bar menu of all the libraries it knows about. The first
selection is "FINISHED, GO TO NEXT FILE", the second allows you
to "ADD" a library to the list (select this option if you are
using Blaise, C-scape, etc). In this menu, you should select
any of the libraries needed to perform a clean link. Each library
you select is added to the dependency rule and to the link command.
When you select "FINISHED", the macro $(DEFAULT_LIBRARIES) is added
to the link command. In the beginning, this was confusing for me,
and I tried several different ways of handling it. Think of it
this way. If you have a straight C program, simply select
"FINISHED", this means compile with just the default libraries.
If you have a program that needs a Blaise/C-scape (etc)
library, "ADD" it to the list, select it, then select "FINISHED".
If you have a program that needs one of your custom libraries, select
it, then select "FINISHED". And so on... This is a usability issue
and not a problem area.
Without doubt, the first area to check is the make macros. Be sure
they are consistent with your own environment. By the way, to
invoke the Turbo editor on a file without an extension, try this:
TC MAKEFILE. (the dot is the trivia bit).
The next place to check is the file dates. You may have to do some
"touching" up to get things just right. To start, you can try
something like:
FOR %1 IN (*.H) DO TOUCH %1
You can also use my restamp utility to initialize the file
dates.
Converting from MASM to TASM in mixed mode programming can cause
some false starts where case sensitivity is concerned. You may
be faced with having to global change some all caps calls with
lower case and vice-versa.
Conflicting header files, conflicting structure definitions? Now
is as good a time as any to fix things.
Duplicate functions? Same advice...
Lots of junky C and H fragment files laying around? Erase them...
You might also try my HARDARC utility, which zips through the
entire hard drive and offers to ARC any directory with more
than two files in it.
A final suggestion, why not set up a header file called c_vrsn.h,
and include it in all your entities. This file contains a single
line:
#define COMPILER_VERSION "TURBOC 2.0"
This might make the transition to 2.X or 3.X or whatever a little
easier.
Opinions and miscellaneous drivel
=================================
After checking things out in my own way, I see no reason to use
MS LINK over TLINK. In fact, for all but the most arcane and
offbeat purposes (like CLIPPER and so forth), TLINK should be
the linker of choice. Why? definitely faster, no segment
limitations, packed segments, far call translation, etc. etc.
With the exception of protected mode and dynamic linking, TASM
seems to be faster and cleaner. I also find the output more
informative.
Although I find TC and TCC to be superior C compilers,
I cannot totally abandon CL because I just love the /Zg
option (which generates ANSI function prototypes).
I have essentially the same MAKEPREP utility for XENIX and UNIX
based environments. In fact, that's where MAKEPREP was born.
The user interface is less slick (i.e., non-existent, because
curses is such a bore compared to C-scape/Blaise), and the
vibrant options for compiling and linking are replaced with
ho-hum macros like COMPILER = cc. The only advantage is that
everything is done in the background, which gives me the
illusion of multitasking while it takes two minutes to do
a simple lc command. Maybe one day Borland will get wise and
dig into this market with an IDE letting us all kiss goodbye
to vi. On this same topic, I emphatically endorse Borland's
ANSI extensions for signal.
On a last note, if MAKEPREP has been useful to you, drop me
a line...
Garry J. Vass
December 19, 2017
Add comments