# Semi-dependency on GNU utils

Some of the features depend on GNU-specific implementation of standard software. These are all semi-dependencies, which means if an user doesn't have GNU software on a system, it is still possible for him/her to compile libmawk. Unfortunately editing some parts of the source on such a system would not result in the desired updates. Obviously a main goal is to minimize this sort of dependency, but sometimes it is very hard or impossible to avoid. This document describes these dependencies explaining the tradeoff and the ways around.

## 1. Bison

### 1.1. Rationale

There are four GNU-specific features in use:

- %pure-parser for getting a reentrant parser
- %parse-param to pass mawk state around to avoid global variables
- %lex-param for the same reason as %parse-param
- --name-prefix to avoid namespace pollution

The first three features are critical for having a reentrant/thread safe libmawk. Without those three, there could be only one mawk context in an application, or at least parsing more than one script in the same time would cause both context mangled.

The fourth feature, --name-prefix helps avoiding namespace pollution - the application may have its own parsers with or without name prefixing, and libmawk shouldn't collide with those.

### 1.2. effects, restrictions

Scconfig detects presence of bison; in case bison is not installed, Makefile.conf is generated in a way that bison is never run. Output of bison is included in the source tree (parse.c/parse.h).

Not having bison on a systam means editing parse.y will not update the actual parser code in parse.c.

### 1.3. how to bypass

It is possible to use traditional yacc for compiling parse.y. Besides editing Makefile.conf and parse.y for removing those 4 features, scan.c/scan.h should be edited too, because arguments for the scanner depends on these settings. A global variable for the mawk context for the script currently being parsed should be introduced. Actions should be made to ensure no concurrent loading of scripts is possible.

## 2. Makefile.dep needs gcc

### 2.1. Rationale

Source file dependencies are generated using gcc -MM and are stored in Makefile.dep shipped with the source package.

### 2.2. effects, restrictions

After changing #include lines in the source, running make depend will not update Makefile.dep but will zap it.

### 2.3. how to bypass

It is easily possible to keep Makefile.dep in sync by hand. Another option is to ignore Makefile.dep and run make clean before compilation.