PBMake 2.16 for Clipper, Xbase++, C and ASM

Script Initializer Tool:

What is PBInit?
Quick Start!
PBInit will create a .LNK file for me?
PBInit will create a .MAK file for me?
What do you mean, refresh the .MAK file?
How does PBMAKE.INI effect PBInit?


What is PBInit?

PBInit was created to make it easier for you to work with the PBMake make engine, by providing a facility to combine automatic link script creation, and the ability to use any existing link script to create a working .MAK file for PBMake. Unless you like making long complex .LNK and .MAK scripts for other cryptic make engines, PBInit will help you by automating this task, using preset defaults, whick can be customized to your specific needs. PBInit also creates MK.BAT and MAKE.BAT referred to elsewhere in this guide if they are missing.

Quick Start!

Just run PBInit followed by the file name of the .MAK file you want to create or refresh. Once PBInit starts, you will be presented with several menu choices. Check the options you need and let PBInit work for you.

PBInit will create a .LNK file for me?

Yes, PBInit now includes the ability to create link scripts for you. Go to the directory where your source code resides and run PBInit followed by the name of the make file you want to create. At the startup screen of PBInit, select Create Link Script. On the second screen, select the language and linker, and whether to use ALL source code or SOME source code. If you select to use SOME source code, you will be presented with a pick list of the source code. Go to each source module you wish to include in the .LNK file and press <space>. This will leave a mark next to any source code you have selected. When you are done selecting source modules, press <enter> to continue. PBInit will then ask you to pick the top module. Then, the .LNK script will be created, and this creation will be automatically followed by the creation of the matching .MAK file.

PBInit will create a .MAK file for me?

You bet! And it is a very smart mechanism, indeed. First, PBInit checks to see if the .MAK name you are about to create already exists. If it does, you can abort, refresh it, or delete it and start a new one. Next, PBInit scans for .LNK files in the current directory. If it finds more than one, you must choose one. If there is only one, PBInit continues without prompting. Once PBInit has determined which link file you are going to use, it opens it and reads it into memory. As it reads it in, it seperates it into categories, such as source references and library references and lines that have no bearing on .MAK script creation. After PBInit has determined all of the source files which were pointed to in the .LNK file you are using as a template, each source file is opened and completely scanned for #INCLUDE references. Now, PBInit has built three sets of files. The SOURCE set, the LIB set and the INCLUDE set. At this point, PBInit uses the CLIPPER compiler on each source module, trying different flag combinations from the most difficult to the most forgiving. Each file in the SOURCE set is subcategorized according to these flag combinations. Here is the list of FLAG= testing. /N is tested to see if you need it. Then, in the following order (with or without the /N flag as determined in the previous step) /M /W /ES2 /M /W /A /ES2 /M /W /V /ES2 /M /W /A /V /ES2 /M /ES2 /M Once this process finishes, the path to each file in the INCLUDE set and the LIB set is located. PBInit then reads your default data from the PBMAKE.INI file, such as the editor you have set up to jump to when an error is encountered. Finally, with all of this information that has been collected and determined, the .MAK file is written and you return to DOS.

What do you mean, refresh the .MAK file?

If you transfer code back and forth from one machine to another, you know how much work it is to keep all of the scripts working on both machines. The problem begins when the two machines that have files in different locations. For instance, if your compiler and .LIB directory is on C: on one machine and on D: on another machine, then any fully developed .MAK model would stop working as you transferred the code from one machine to the next. PBInit has relieved you of this problem by 'refreshing' the .MAK files from the environment of whichever machine you are on. Simply run PBInit <existingmakfile>, and you will be prompted three ways: 1. Abort, I didn't mean to do this. 2. Refresh, I just want to update the references in my .MAK file. 3. Delete this .MAK file and create a new one from scratch. Pick #2, Refresh, and PBInit will: 1. Locate all of the LIB= and INCLUDE= lines in the existing .MAK file 2. Strip the path off of them 3. Use the current environment to find the files that were referred to 4. Find the correct path to each reference 5. Replace them back into the .MAK file with the corrected path information for the current environment. If PBInit can't find a referred to file in the current environment, a comment will be placed in the .MAK file where the file was originally referred to stating that the reference couldn't be found, like: // LIB=SOMELIB not found in local directory or LIB= environment or // INCLUDE=SOME_CH not found in local directory or INCLUDE= environment After correcting the environment, you can run the PBInit refresh option again and PBInit will look up the full path and correct the .MAK file.

How does PBMAKE.INI effect PBInit?

The first section, [PBINIT], tells PBInit about your editor. When PBMake encounters an error in your code, it will automatically load the error list and the code in question into your editor. This sections tells PBMake what compiler you are using, so the error can be correctly parsed. It also tells PBMake what editor and the command to jump to a line number. This information is used in the automatic creation of .MAK files. [PBINIT] COMPILER=CLIPPER EDITOR=Q LINEFLAG=-N After the first section, there are 5 sections which are used to create link scripts (.LNK). They are [CLIPPER], [C], [TASM], [MASM] and [XPP]. Each of these sections are divided into two parts, signified by the {PRE} and {POST} position locators. When building a linker script, there is generally some linker commands that you need to put ahead of the object references, and in general, your library references go after your object reference. These two sections can be defaulted here and every time you build a link script, the {PRE} and {POST} sections will be included automatically as your default link script. If you need PBInit to always overlay your source code, include the {OVERLAY} command. Here is an example with the CLIPPER section filled in. Please note the extra library calls that are commented out. You can uncomment them or delete them, based on each link script's needs. This makes it easy for you to create a 'standard' link script here in the .INI file and use it as the basis for all your future link scripts without a bunch of copying and editing. [CLIPPER] {OVERLAY} {PRE} NOBELL BLINKER MESSAGE WINK BLINKER INCREMENTAL OFF BLINKER EXECUTABLE CLIPPER //F:99 //E:0 BLINKER EXECUTABLE EXTENDED 1500 # BLINKER EXECUTABLE COMPRESS 1 BLINKER HOST MESSAGE ON STACK 7168 SEARCH BLXRATEX,BLXCLP52 {POST} #BEGIN # file cmxdbt52.obj # file cmx52.obj # lib cm52 # lib cmx52 #END # lib nanfor # Search mrwindow # @mrdmax # fi mrdump.lib #@CL520MIN @CL520MID #@CL520MAX # MODULE EXITSTATE,GETAPPLYKE,_EXITSTATE,GETACTIVE,READVAR #fi cld #@cm #@cmx #begin # lib TPOVL52 #end #search TPBLX52 #@TPBLX.lnk #BEGIN # lib FLEX52 #END #BEGIN # lib FUNCK #END #lib LLIBCA #lib CTp #FI CTUSp [C] {PRE} {POST} [TASM] {PRE} {POST} [MASM] {PRE} {POST} [XPP] {PRE} {POST}