RTC SCM Multiple can we associate multiple Langauges to source files?
![]()
Hi, we have a large project that contains multiple levels (Developer, Test, Release/GA).
Some source files in each level may need to vary the version of the translator based on their level (i.e. the file may be promoted to a higher level of the project, and we will need the language translator version to change to the minimum version for that project level). Other source files must keep the same language translator version as they are promoted(i.e. tey are already at the highest version). So, we need to know: Are language and translator definitions isolated (definable within each repository workspace), or are they in shared in common for all workspaces within a project area? If they are not isolated, is there a way to vary translator attributes/behaviour depending on which workspace they are being built from? Frank |
3 answers
![]()
Making some guesses here .....
1. 'associate multiple languages' == 'associate multiple language definitions'
2. 'very the version of the translator' really means you perhaps have different compiler options or perhaps different compiler, DB, CICS etc levels at different promotion hierarchy levels.
Hopefully i have deciphered this. If I have not then you need to be a whole lot clearer as I have no idea what you mean by 'and we will need the language translator version to change to the minimum version for that project level'
Although I am doubtful I have got it right as if I have then I don't know what you mean by 'Other source files must keep the same language translator version as they are promoted(i.e. they are already at the highest version' since things like DB and CICS levels are not going to vary from file to file at one promotion level.
Can you clarify all of this please.
Answering your specific questions .....
System Definitions like Language Definitions and Translators are visible to all other project areas on a server. You can tell they are not defined within the context of a workspace as when you create a definition you don't specific a workspace.
Translators and Language Definitions can contain substitution variables. In v3 you could specify a value for a substitution parameter in a Build Definition. In v4 you can override at the file level. So, since a Builde definition is specific to a workspace then you could have a different build definition for each works space and so be able to have different substitution parameters in play for each workspace
|
![]()
Guy,
'associate multiple languages' == 'associate multiple language definitions' is correct. to illustrate: a compiler at version one may generate executable code that is not completely compatible with code generated by a different version of the compiler. Further, as compilers are enhanced, their enforced syntactic requirements may change (adopting new language standards). For a long lifespan project these two trends (compiler runtime code changes and compiler language syntactic requirements) require us to (1) keep all shipped code (at a given product release) compatible with all code within that release. So, if we have a source file that contains fixes and it is flowing into the workspace that represents the GA level of the product, if it may need to be built using the version of the language compiler that differs from the level currently used in development (to provide for run time compatibility of the executable code). Likewise, if we are checking out a source file that contains language constructs that are deprecated at later (more current) versions of the compiler, then we will need to (1)choose a version of the compiler that will allow the constructs (if the executable code is compatible between the two compiler releases), (2) re-factor the source code to remove/replace the deprecated constructs, or (3)suppress the deprecated code warnings and "hope for the best". So, the ability to vary the language translator (compiler version) or the compiler options used (based on the workspace) would be a big help. Frank |
![]()
ok, so this is a common scenario then. You have a stream for each promotion level, a build definition for each stream and a build workspace for each build definition. The translator that describes, in your example, the compile step would have a substitution parameter for either the compiler options. This would catcher for common options like debug and listings to be turned on or off at the various promotion levels. You could also have a substitution parameter for the DSD that describes the location of he compiler itself. The substitution parameter values would be set in the build definition. So at each promotion level, the build definition for that level would have the correct values for the substitution parameters.
BTW .... I would hope that it is highly unlikely that language constructs are depreciated in up level versions of a compiler. One would hope that something as fundamental as a compiler would always be backward compatible. This would remove your 'hope for the best' situation.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.