build variables into source files
Hi all,
We have variables within our code that are were expanded into meaningful values on our last code repository when extracted (for example %Z% might be expanded to 1.76, which is the version of that file).
Is there anyway to do this in Jazz? If not what do people recommend for keeping track of code levels in the field. The version numbers for example were usually put into trace, which would help the service team pinpoint the level of code that they were using, enabling a quicker turnaround for customer problems (potentially).
Cheers
Rich
We have variables within our code that are were expanded into meaningful values on our last code repository when extracted (for example %Z% might be expanded to 1.76, which is the version of that file).
Is there anyway to do this in Jazz? If not what do people recommend for keeping track of code levels in the field. The version numbers for example were usually put into trace, which would help the service team pinpoint the level of code that they were using, enabling a quicker turnaround for customer problems (potentially).
Cheers
Rich
3 answers
Hello Rich,
You can specify build variables, so called properties, in the build engine
as well as the build definition. At least for the command line build i know
that these can be passed to the builder e.g. make. I know ANT builds get
properties passed but am unsure how the situation is with custom properties.
However, my assumption is, if you can use these properties and expand them
into the code today, the mechanism you are using today could be used with
the Jazz build too.
Ralph
You can specify build variables, so called properties, in the build engine
as well as the build definition. At least for the command line build i know
that these can be passed to the builder e.g. make. I know ANT builds get
properties passed but am unsure how the situation is with custom properties.
However, my assumption is, if you can use these properties and expand them
into the code today, the mechanism you are using today could be used with
the Jazz build too.
Ralph
Hi all,
We have variables within our code that are were expanded into
meaningful values on our last code repository when extracted (for
example %Z% might be expanded to 1.76, which is the version of that
file).
Is there anyway to do this in Jazz? If not what do people recommend
for keeping track of code levels in the field. The version numbers for
example were usually put into trace, which would help the service team
pinpoint the level of code that they were using, enabling a quicker
turnaround for customer problems (potentially).
Cheers
Rich
Hello Rich,
I have worked with systems that could expand version numbers in files etc.
But I am not aware we have that in RTC.
You would either wait for other comments or ask for a feature to be implemented.
Ideally this would have to be built into the versioning system, otherwise
each change of the version would create a new version of the file, which
would need to be checked in, I guess.
However, I am not sure this feature is really important, I haven't used features
to incorporate the file version into e.g. a header file for many years, but
of yourse this is my personal view. You have the history of the file which
can tell you the version number, you have baselines, snapsots, releases.
e.g. the build number incorporated into a released set of files allows you
to identify the files and pull exactly those file versions from the repository.
Since a file on its own is pretty useless in most cases I know I think it
would be beneficial to create a baseline/snapshot that consistently tags
all files belonging together.
What would be the benefit of having this in the source? Do you ship the source
file rather than some kind of executable? If you think it would be beneficial,
you could create a work item.
Ralph
I have worked with systems that could expand version numbers in files etc.
But I am not aware we have that in RTC.
You would either wait for other comments or ask for a feature to be implemented.
Ideally this would have to be built into the versioning system, otherwise
each change of the version would create a new version of the file, which
would need to be checked in, I guess.
However, I am not sure this feature is really important, I haven't used features
to incorporate the file version into e.g. a header file for many years, but
of yourse this is my personal view. You have the history of the file which
can tell you the version number, you have baselines, snapsots, releases.
e.g. the build number incorporated into a released set of files allows you
to identify the files and pull exactly those file versions from the repository.
Since a file on its own is pretty useless in most cases I know I think it
would be beneficial to create a baseline/snapshot that consistently tags
all files belonging together.
What would be the benefit of having this in the source? Do you ship the source
file rather than some kind of executable? If you think it would be beneficial,
you could create a work item.
Ralph
Hi Ralph,
We previously used CMVC as our code repository and you had two ways to
check out a file, with keywords expanded and with them not expanded.
If you wanted them expanded when you viewed/checked the code out,
then the %Z% would be replaced in each file automatically for you by
CMVC.
As far as I am aware, ant and custom build.properties would not allow
us to do this, or anything similar.
There must be other users of Jazz out there with a similar issue,
multiple versions of code out in the wild, and a service team that
must support multiple versions of the same file. How do they handle
this?
rschoonwrote:
Hello Rich,
You can specify build variables, so called properties, in the build
engine
as well as the build definition. At least for the command line build
i know
that these can be passed to the builder e.g. make. I know ANT builds
get
properties passed but am unsure how the situation is with custom
properties.
However, my assumption is, if you can use these properties and
expand them
into the code today, the mechanism you are using today could be used
with
the Jazz build too.
Ralph
Hi Ralph,
We previously used CMVC as our code repository and you had two ways to check out a file, with keywords expanded and with them not expanded. If you wanted them expanded when you viewed/checked the code out, then the %Z% would be replaced in each file automatically for you by CMVC.
As far as I am aware, ant and custom build.properties would not allow us to do this, or anything similar.
There must be other users of Jazz out there with a similar issue, multiple versions of code out in the wild, and a service team that must support multiple versions of the same file. How do they handle this?
We previously used CMVC as our code repository and you had two ways to check out a file, with keywords expanded and with them not expanded. If you wanted them expanded when you viewed/checked the code out, then the %Z% would be replaced in each file automatically for you by CMVC.
As far as I am aware, ant and custom build.properties would not allow us to do this, or anything similar.
There must be other users of Jazz out there with a similar issue, multiple versions of code out in the wild, and a service team that must support multiple versions of the same file. How do they handle this?
Hello Rich,
You can specify build variables, so called properties, in the build engine
as well as the build definition. At least for the command line build i know
that these can be passed to the builder e.g. make. I know ANT builds get
properties passed but am unsure how the situation is with custom properties.
However, my assumption is, if you can use these properties and expand them
into the code today, the mechanism you are using today could be used with
the Jazz build too.
Ralph