Next: Getting Started, Up: Retargeting Flex [Contents][Index]
The Flex code has been factored to isolate knowledge of the specifics of each target language from the logic for building the lexer state/transition tables. Code in the target language is generated via m4 expansion of macros in a skeleton. All knowledge of the target language is isolated in that skeleton; with only one exception, everything Flex contributes to the output stream is m4 macro definions that are expanded by m4 after they are introduced.
The only assumption that is absolutely baked into the macro definitions Flex ships is that the bodies of initializers for arrays of integers consist of decimal numeric literals separated by commas (and optional whitespace).
Otherwise, knowledge of each target language’s syntax lives in a language-specific skeleton file that is digested into a data structure inside Flex when Flex is compiled. The skeleton files are part of the Flex source distribution; they are not required by the Flex executable.
A few pieces of language-specific information that cannot conveniently be represented in a skeleton file are supplied by a per-language method table in the C code. All the Flex code that accesses language-specific information goes through a global pointer named "backend" to a method table. One method is a function to generate an appropriate suffix for output files.
For example: The methods for the C and C++ back end live in a source file named cpp_backend.c (so named because both languages use the C preprocessor), and in a skeleton file named cpp-flex.skl which is digested into a member of the method table when Flex is built.