Wild Cards in Build Rules

OpenMake Meister for Intelligent Builds / Creating Your Build Service / Creating Your Custom Build Services / Overview Attributes

Wild Cards in Build Rules

In some cases, it may be necessary to use wild card substitutions, using an asterisk ( * ) to denote a wild card, in the Build Rule. Wild card substitution is often needed when defining rules to support pre-compile steps where actual source code is being generated, and used as an intermediate result.

In most cases when source code is generated, a standard naming convention is used to name the generated file. The naming convention is based on the name of the dependency file. In the Build Rule, you can represent the generated file by using a generic symbol allowing for the correct representation of the generated source code name. For example, if you are using IBM's Visual C's IDL command, an IDL file called hello.idl may need to be generated into a Final Target called helloC.cpp. The Build Rule would need to be defined with the Final Target defined as *C.cpp. When the build scripts are generated for this rule, it will replace the "*" with the name of the dependency file "hello", resulting in helloC.cpp.

Similarly, it may be necessary to use a wild card extension as part of your Build Rule dependencies when you do not need to explicitly define what file extension the Target is going to have. This is particularly useful for taking many files and adding them to a .jar file without having to specify every possible file extension as a Build Rule's dependency. The use of a ".*" Build Rule dependency will also allow developers to add a *.* dependency to their unique Target as a dependency.

When a wild card extension is used as a Build Rule, a build script will be generated that includes a build step for the .* dependency. At build time, the build process will resolve the wild card files as dependencies to the Target.

The use of wild card extensions will not work for a one to one Target to Build Rule dependency relationship. For example .* to .obj will not produce the desired results. Instead the rule must explicitly define the one to one relationship, i.e., ".cpp" to ".obj".