Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Categories z/TPF
Created by Guest
Created on Dec 6, 2022

(TPFUG) Toolchain support for building code with multiple versions of the compiler

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.

Idea priority Medium
  • Guest
    Reply
    |
    Mar 8, 2023
    IBM does not intend to implement this idea.
    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.