Refactor "target_config.c" logic to avoid #include of data fragments

[jphickey]

Is your feature request related to a problem? Please describe.
The content of the various CONFIGDATA global data structures is dynamically generated from a combination of build scripts, some which run at prep/generation time and some which run at build time.

The pattern currently used here is that the scripts generate "fragment" data files that only contain the dynamic content, without any C declarations or any other syntax. This is then paired/combined with the target_config.c file which is a regular version-controlled file that has the basic structure and declarations (i.e. all the non-dynamic bits) and uses #include to pull in the data fragments where needed (i.e. a "fill-in-the-blank" approach).

This works well but there are some rules against using the #include directive with anything other than an normal/conventional fully formed C header file (i.e. it has .h extension, fully self contained, syntactically correct, standalone, include-able by any C source file at will). So a "dynamic data fragment" file which is implemented here doesn't meet the criteria.

Describe the solution you'd like
Have the build system generate fully-formed source files before passing to C compiler in some way.

Currently evaluating/considering several approaches or combination thereof.

1. Put more of the non-dynamic "C" content (structure) into CMake configure_file templates, generating a separate but fully-resolved .c source for each object that has dynamic content.
2. Pass the file through another explicit macro-processing step (such as C preprocessor or m4) before compiling (basically introduce another layer of indirection) to generate a final file.

Either way the result should be a fully formed .c/.h file without any #include in its body - as all data items should be "filled in" already - which is then built and linked as the current file is.

Requester Info
Joseph Hickey, Vantage Systems, Inc.