In order to migrate to a new compiler, all new warnings or errors in user code must be corrected and/or user defined compiler overrides must be applied to suppress warnings enabled by default for the new compiler. Some shops may require all code remediation is done before migrating to the new compiler to avoid issues with emergency loads etc. Remediation can take considerable effort, resources, and coordination. Coordination steps may include a period of time where dual compiles (build with both the current and new compiler versions) are required as part of the process to build code for production to ensure that new problems are not injected into remediated code. These dual builds would be required prior to migration of production builds to the new compiler and may or may not mandate that the build with the new compiler must complete RC=0 in order to allow the build for production with the current compiler to be allowed to move forward.
We need IBM toolchain support to make it easier to implement dual or triple (if the compiler compatibility mode Idea TPF_I_977 is accepted) build processes. This support needs to be able to be invoked via line command that can be integrated into the "build for production" process run by the appropriate production support group, and also made available to developers by being able to be invoked from a Toolkit menu option (requiring developers to constantly update maketpf.cfg options in their Toolkit project is error prone and confusing for them).
The support also needs to allow a user admin to define a set of rules to use to determine:
which compiler versions (TPFGCC_VERSION settings) should be run (up to 3 TPGCC_VERSION settings would be ideal)
in which order the builds should be done
whether a non-zero RC in one build should prevent further builds from being done
how to manage build output – e.g. identify one build as the “production load” build and identify alternate locations for other build output (e.g. compiler version named subdirectories, or entirely different “TPF_ROOT” type locations and subdirectory names), or support the ability to throw away the non-production load build output.
manage warnings/errors output – e.g. compiler version named .err* and .out* files that could be attached to an email to the developer to inform them of any issues found in any builds.
Example of how this support would be used: Customer is currently on GCC 4.6 and migrating to GCC 7. They have remediated all known GCC 7 issues in their code base and determine all TPF code loads installing to production on or after a specific date (MIGRATION_DATE) must be built with GCC 7. Prior to MIGRATION_DATE, the “move to production” process should 1) build all code with GCC 4.6 and GCC 7 to ensure changes to the current code do not result in new GCC 7 errors 2) move the GCC 4.6 build forward as the one to install to production and 3) notify the owner of the code if there are GCC 7 issues but still allow the GCC 4.6 build to move forward in the “move to production” cycle. Any issues in the GCC 4.6 build fails the process (as it would do normally). A little later, the customer might want to change the rules so that the GCC 4.6 build won’t be allowed to move forward if there are any issues in the GCC 7 build of the code.
Build/make rules are predicated on a one-to-one relationship between target and source and it is not feasible to create multiple targets from one build pass. What is being proposed is better handled as a wrapper around the provided maketpf build tools, not an enhancement to maketpf itself.