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

Introduction:

Introduction: What is a MAKE engine and script?
How to reap the Benefits.
What is a .CLP file
Making the Switch to PBMake from .CLP files.
A better way of 'Makeing' your executables!
Assumptions.
Incremental Linking.
Learning more about Link Scripts.


Introduction: What is a MAKE engine and script?

Welcome to PBMake. PBMake is a make engine, and was created to save time. If you are not using a make file, you are wasting time. The benefit of a make process is primarily one of saved time! A make engine and script is a program and text file that instructs the Clipper compiler to only compile modules that you have changed, instead of everything every time. A make engine is the program that reads that script and performs the appropriate actions. Make engines and scripts are sometimes called a make process.

How to reap the Benefits.

To effectively use a make engine, you will need to break your source modules in smaller units. Each function or group of functions should be compiled into it's own object. This allows Clipper to only compile in small chunks, and the linker will put it all together into the target file. In the case of Clipper the target file is an .EXE file. If you have your linker set to incremental mode, the entire compile and link process can be made extremely fast compared to compiling all objects and performing a total link.

What is a .CLP file

A .CLP file is an early implementation of instructions for the Clipper compiler. If you are not using .CLP files, you can skip any parts of this Norton Guide that refer to .CLP files. .CLP files were originally created to help programmers compile all of their individual source modules into a single object. Then, the supplied linker was used to link the objects with the Clipper libraries to create the final output. While .CLP files do work, other ways of using your linker eliminate the need for such a system, and in fact, the .CLP system and single object compiler output stands in the way of saving time and having more control.

Making the Switch to PBMake from .CLP files.

If you are using a .CLP file to create one large object, that is the first thing to change. Instead, compile each source module into it's own object by listing all of the source module names without their extensions into the .MAK script following the examples I provided. Then make a reference to each of the new files in your link script instead of a single entry that references the single object created by your .CLP file. For example, if you were using a file named MYPROG.CLP that reads like this: prog1 prog2 prog3 another andmore common used function It would create a single object named MYPROG.OBJ. If you change any of the source modules, you have to recompile all 8 of them. Usually, this is a big waste of time, because only one of them is different. If you allow PBMake to compile each source module into it's own object, there will be 8 objects, and PBMake will then be free to only compile the one that changed. This is how PBMake can save you time. By breaking the compile process into smaller parts. Here is an example script for PBMake that would create these smaller objects for you: ****************************************************************************** * PBMake 2.16 for Clipper, Xbase++, C and ASM * * Copyright (C) 1998 Phil Barnett, All Rights Reserved Worldwide * * See PBMAKE.NG for help. * ****************************************************************************** TARGET=MYPROG.EXE LINKFILE=MYPROG.LNK LINKER=BLINKER PROG1= PROG1 PROG2 PROG3 ANOTHER PROG1= ANDMORE COMMON USED FUNCTION The more complex your source code gets, the more time you save! Now you are faced with a new problem. You need a way to assemble all those parts. With a .CLP file, you probably have been using something like: CLIPPER @MYPROG.CLP plink86 file MYPROG Now that you have broken up the objects, one way to link them would be: rtlink file prog1,prog2,prog3,another,andmore,common,used,function (or whatever linker you are using) As you can see, that is going to get old in a hurry, and will break the byte limit of the dos command line if it gets much longer. Fortunately, the linker manufacturers give us a better way. As you have seen above, eliminating the .CLP file breaks the large object into many smaller ones, but you still need to put them together into an target/.EXE. So, instead of a list of files that Clipper will compile into a single large object, we will make a list of files the linker will link together into an target/.EXE. This called a linker script, and usually ends in the letters .LNK A linker script for the example above (named MYPROG.LNK) would look like: OUTPUT MYPROG.EXE FILE PROG1 FILE PROG2 FILE PROG3 FILE ANOTHER FILE ANDMORE FILE COMMON FILE USED FILE FUNCTION If you created a file with the above contents you would tell the linker to use it like: rtlink @MYPROG.LNK (or whatever linker you are using) PBMake actually writes and executes a batch file that performs all of these steps automatically. All you have to do is set up the make script correctly, which is a simple process. PBMake performs an incremental compile, and saves you time by doing as little as possible but all that is necessary to compile a fully up to date executable.

A better way of 'Makeing' your executables!

Most MAKE engines require you to learn complex or difficult procedures to create a make script, and then when you reach a certain point of complexity, the MAKE engine reaches it's limits, leaving you with no easy solutions. It's a shame that breaking your applications into smaller and smaller pieces is what makes make engines more efficient, and is the very thing that breaks them when your script gets too complex. You will not have this problem with PBMake. PBMake is not only easy to learn how to use, but using it will reward you with saved time, easy to understand make scripts and the knowledge that the job was done right and you understand why.

Assumptions.

A few assumptions are made in PBMake, primarily in the name of simplification and ease of use for Clipper programmers. These assumptions are: COMPILER=CLIPPER SRCEXT=.PRG OBJEXT=.OBJ LINKER_SEP=@ If you use another language, all of these can be changed. They are simply initial values that Clipper programmers need not supply for the make engine to work correctly. PBMake enforces the following dependencies automatically: 1. You will be creating an output file. (typically an .EXE) We will be referring to it as the target. 2. You are using a script for your linker which contains all of the linker directives. (this is important) 3. The output file will need to be relinked whenever any object file it depends on has a newer time/date stamp, or the link script has been modified. 4. Each object depends on only one source module, and will be named the same as the root name of the source module. ( AAXYZ.PRG will create AAXYZ.OBJ, XX.C will create XX.OBJ ) 5. Each object file will need to be rebuilt whenever the source module it depends on has a newer time/date stamp, or is older than anything in the INCLUDE= directive, or you used the /ALL flag.

Incremental Linking.

Even though this has nothing to do with PBMake, it does go hand in hand. You can save even more time with a modern linker like BLINKER, by using incremental linking during your development cycle. (For that matter, you can save a lot of time just by switching to BLINKER and not optimizing anything else, but that's another conversation...) Incremental linking works just like incremental compiling does. It only replaces the object that changed in the target/.EXE. It doesn't have to recreate the entire .EXE every time the linker runs. By using PBMake and a linker that can perform incremental links, you can accelerate your development process by huge amounts, by not waiting for processes that really don't need to be done. As a final note, please be aware of this; if you use incremental linking, you need to turn it off and relink one more time before placing the target/.EXE into production. Incremental linking, while providing an accellerated development cycle, adds size to the .EXE, which can be removed just before you create the final product.

Learning more about Link Scripts.

If need to know more about link scripts, please read your linker documentation. Learning to use link scripts will give you MUCH more control over how your linker puts your source code and libraries together to form the final product. It is worth the effort to learn how to use linker scripts.