APG version 5.0.1 is a successful port to the GNU/Linux operating system. I’ve used the Debian 4.0r1 distribution of GNU/Linux. Some “tweaking” of the files was necessary for a successful build. A new, minor version 5.0.1 has been created which 1) will build successfully under both Microsoft Visual C++ 6.0 and GNU gcc/g++ version 4.1 and 2) contains GNU Make files for the Linux build in addition to the VC++ project files.

 Functionally, there is no difference between versions 5.0.1 and 5.0. For the full operational details see the version 5.0 description.

 GNU/Linux file naming conventions:

.mk      – GNU make files

*.exe    – release version of executable files

*_d.exe  – debug version of executable files

lib*.a   – release version of library files

lib*_d.a – debug version of library files

<none>   – shell script files

*.tar.gz – compressed archived files

*.txt    – ASCII text

*.h      – C/C++ header file

*.c      – C source code file

*.cpp    – C++ source code file

*.bnf    – SABNF grammar file

*.bin    – binary (sequence of 8-bit bytes) file

*.bat    – Microsoft DOS batch (script) file

*.dsp       – Microsoft Visual C++ 6.0 project file

*.dsw    – Microsoft Visual C++ 6.0 project workspace file

 Make files:

GNU make files all have a “.mk” extension. Each folder contains the make files debug.mk, release.mk and Common.mk. debug.mk will build the object files for the debug version and contain debugging information. Release.mk will build optimized object files without debugging information.

 Script files:

The directory ./Apg5_01/MasterBuild contains two script files:

Each project directory contains a script file BuildParser. This file will generate the parser or parsers for the project from the *.bnf grammar file.

 Caveat – Projects IPv6 and SIP require modifications to the grammar file for generating the different parsers required for the examples. The instructions are contained in the grammar files themselves and the BuildParser file must  be modified to comment out the unwanted instructions on each separate generation. This is a little tricky and I, myself, get tripped up on it occasionally. The reason for leaving it this way is that the changes are minor and I don’t want to have separate grammar files that would need to be updated in synchronization for modifications and I don’t have the motivation for the considerable effort required to build a user-friendly procedure.

 GNU/Linux directory structure:

The make files will create several new directories.