How kwinject handles a command line from your build
kwinject uses the following rules to handle a command line from your build:
- The name of the executable file is matched against the list of known commands in kwfilter.conf. If no match is found, the command is ignored.
- The matching record in kwfilter.conf contains the name of the filter, which is used to derive the name of the compiler filter file, <compiler_name>_filter.py.
- kwinject reads a set of rules from the compiler filter file.
- The command line is broken down into a list of arguments.
- kwinject iterates through the list of arguments and options and tries to apply filtering rules to every argument.
- Rules are applied in the order they were defined in a compiler filter file, so the rules at the beginning of the configuration file take precedence.
- A rule may instruct kwinject to ignore the option/argument, or to copy it to the build specification.
- A rule may have a side effect that affects the state of the command-line parser. For example, some compilers support passing options through a file (such as Microsoft Visual Studio and ARMCC), so the rule for this kind of option instructs kwinject to ignore the option, but to insert the contents of the option file into the command line.
Multiple compile or link records from one command line
A single command line can be transformed into multiple compile or link records in the build specification.
For example, if the original command line was used to compile several source files, kwinject would generate the same number of compile records in the build specification.
As another example, most compilers have an option to perform compilation and linking in one step. A number of tags in the compiler filter file control whether kwinject translates a specific command into one or more compile records, or into a sequence of compile and link records.