![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
More on Customizing Build PoliciesBuild Management customization is described in the C++ Compiler Reference.
Build Policy Implementation
The build policy for a view defines the actions that occur when a build operation is applied to the view as a whole. The build policy affects the standard build operations, including:
- prepare
- parse
- pretty_print
- dependencies
- analyze
- code
- link
- build
- verify
- test
- deliver
- disassemble
- clean
The build policy also effects two queries that are made of views:
- link_contribution.query
This query allows the view to specify what it will contribute to a link. If recompilation is requested as part of making the query then the internal operation query_code_precondition is also executed.
- object_files_content.query
This query allows the view to specify the object files in the view and is used when a library is being constructed that contains the contents of the view.
In the standard keys, whenever a build operation or query is applied to a view, make is invoked in such a way as to build the target "build-policy.operation-or-query". For example, when the code command is run on a view with build policy library, make will eventually be asked to build the target "library.code".
Each build policy must define targets for all of the standard operations and queries. For example, the build policy library, which causes the view to construct a library from all object files in the view and provide the library as the link contribution of the view, has the following targets which implement the policy.
- library.prepare
- library.parse
- library.pretty_print
- library.dependencies
Update the dependencies for all source files in the view.
- library.analyze
- library.code
Compile all source files in the view and then construct a library from the object files which were created.
- library.link
Link all registered main programs in the view.
- library.verify
Run the code rule checker on the files in the view.
- library.test
- library.build
- library.deliver
- library.disassemble
- library.clean
Remove all object files, libraries, and other compiler artifacts in the view.
- library.link_contribution.query
Return the name of the library and the values of the LINK_PRE_OPTIONS and LINK_OPTIONS switches as the link contribution of the view.
- library.query_code_precondition
Used in conjunction with library.link_contribution.query This target is used to rebuild the library prior to returning the result of the query.
- library.object_files_content.query
Return the names of object files for all the source files in the view.
Customizing Existing Build Policies
The existing build policies may be customized through the use of trigger macros whose values can be set in the customization makefile Policy/Customization.mk. For each of the standard operations (although not for the standard queries), there are two macros:
- CUSTOM_<operation>_PRECONDITION
This macro allows additional dependencies to be defined for the designated standard operation. If an error occurs during the processing of this dependency then processing of the standard operation will not occur. For example, to customize the standard code operation one could add the following to Customization.mk:
CUSTOM_CODE_PRECONDITION = code_precondition code_precondition: @<precondition-processing>
- CUSTOM_<operation>_ACTION
This macro allows additional actions to be defined for the designated standard operation. The actions specified are executed after standard processing has been done. For example, additional processing for the code operation would be defined by:
CUSTOM_CODE_ACTION = <action-processing> Where <action-processing> represents a call to a script or any arbitrary Bourne shell commands.
Creating New Build Policies
Users may also define their own build policies. Customization.mk contains the full set of targets necessary to define the build policy custom_build. Users may define the semantics of the custom_build policy by associating actions with targets. When the custom_build policy has been defined, it will be activated in the view by setting the BUILD_POLICY switch to custom_build.
The custom_build policy (and any other user policy) should make free use of the standard targets defined for other policies. For example, if the code operation for custom_build was to perform the same operation as that for the library policy then one could define the following target:
custom_build.code: library.code
Additional Topics
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2001, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |