[PATCH] build: Add optional RTEMS_VERSION_VC_KEY
Chris Johns
chrisj at rtems.org
Sat Jul 29 06:30:01 UTC 2023
On 28/7/2023 6:26 pm, Sebastian Huber wrote:
> On 28.07.23 07:37, Chris Johns wrote:
>> On 27/7/2023 3:59 pm, Sebastian Huber wrote:
>>> On 27.07.23 06:36, Chris Johns wrote:
>>>>
>>>> On 26/7/2023 4:54 pm, Sebastian Huber wrote:
>>>>> On 26.07.23 08:20, Chris Johns wrote:
>>>>>> On 26/7/2023 3:44 pm, Sebastian Huber wrote:
>>>>>>> On 26.07.23 06:58, Sebastian Huber wrote:
>>>>>>>> On 26.07.23 00:08, Chris Johns wrote:
>>>>>>>>> On 26/7/2023 4:27 am, Joel Sherrill wrote:
>>>>>>>>>> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>>>>>>>>>> <sebastian.huber at embedded-brains.de
>>>>>>>>>> <mailto:sebastian.huber at embedded-brains.de>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 25.07.23 19:09, Joel Sherrill wrote:
>>>>>>>>>> >
>>>>>>>>>> > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
>>>>>>>>>> > <sebastian.huber at embedded-brains.de
>>>>>>>>>> <mailto:sebastian.huber at embedded-brains.de>
>>>>>>>>>> > <mailto:sebastian.huber at embedded-brains.de
>>>>>>>>>> <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Allow the user to set the version control key.
>>>>>>>>>> > ---
>>>>>>>>>> > spec/build/cpukit/grp.yml | 2 ++
>>>>>>>>>> > spec/build/cpukit/optversionvckey.yml | 20
>>>>>>>>>> ++++++++++++++
>>>>>>>>>> > wscript | 38
>>>>>>>>>> ++++++++++++++++-----------
>>>>>>>>>> > 3 files changed, 44 insertions(+), 16
>>>>>>>>>> deletions(-)
>>>>>>>>>> > create mode 100644
>>>>>>>>>> spec/build/cpukit/optversionvckey.yml
>>>>>>>>>> >
>>>>>>>>>> > diff --git a/spec/build/cpukit/grp.yml
>>>>>>>>>> b/spec/build/cpukit/grp.yml
>>>>>>>>>> > index e07e975d7d..fbeab45b5c 100644
>>>>>>>>>> > --- a/spec/build/cpukit/grp.yml
>>>>>>>>>> > +++ b/spec/build/cpukit/grp.yml
>>>>>>>>>> > @@ -18,6 +18,8 @@ links:
>>>>>>>>>> > uid: cpuopts
>>>>>>>>>> > - role: build-dependency
>>>>>>>>>> > uid: cfghdr
>>>>>>>>>> > +- role: build-dependency
>>>>>>>>>> > + uid: optversionvckey
>>>>>>>>>> > - role: build-dependency
>>>>>>>>>> > uid: libdebugger
>>>>>>>>>> > - role: build-dependency
>>>>>>>>>> > diff --git a/spec/build/cpukit/optversionvckey.yml
>>>>>>>>>> > b/spec/build/cpukit/optversionvckey.yml
>>>>>>>>>> > new file mode 100644
>>>>>>>>>> > index 0000000000..7197381342
>>>>>>>>>> > --- /dev/null
>>>>>>>>>> > +++ b/spec/build/cpukit/optversionvckey.yml
>>>>>>>>>> > @@ -0,0 +1,20 @@
>>>>>>>>>> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR
>>>>>>>>>> BSD-2-Clause
>>>>>>>>>> > +actions:
>>>>>>>>>> > +- get-string: null
>>>>>>>>>> > +- env-assign: null
>>>>>>>>>> > +build-type: option
>>>>>>>>>> > +copyrights:
>>>>>>>>>> > +- Copyright (C) 2022, 2023 embedded brains GmbH
>>>>>>>>>> & Co. KG
>>>>>>>>>> > +default:
>>>>>>>>>> > +- enabled-by: true
>>>>>>>>>> > + value: ''
>>>>>>>>>> > +description: |
>>>>>>>>>> > + If defined to a non-empty value, then the
>>>>>>>>>> value will be
>>>>>>>>>> used for
>>>>>>>>>> > the version
>>>>>>>>>> > + control key returned by rtems_version() and
>>>>>>>>>> > rtems_version_control_key(),
>>>>>>>>>> > + otherwise the value will be determined by the
>>>>>>>>>> Git
>>>>>>>>>> repository
>>>>>>>>>> > containing the
>>>>>>>>>> > + waf top directory.
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > And would this change for a release tarball?
>>>>>>>>>>
>>>>>>>>>> Which RTEMS_VERSION_VC_KEY has a release tarball? What
>>>>>>>>>> happens if
>>>>>>>>>> you
>>>>>>>>>> unpack an release archive in an external Git repository?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't know but think we should discuss it.
>>>>>>>>>>
>>>>>>>>>> Chris should speak up since the release scripts are his and this
>>>>>>>>>> might be used by the distribution packaging he has made
>>>>>>>>>> available.
>>>>>>>>> I am not sure what the purpose of this change is. It would be
>>>>>>>>> good to
>>>>>>>>> understand
>>>>>>>>> what it is for. The RTEMS_VERSION_VC_KEY could mean a number of
>>>>>>>>> things such
>>>>>>>>> as a
>>>>>>>>> means to set the git hash in sources not in a git repo but that
>>>>>>>>> is guess.
>>>>>>>> Yes, this is helpful if you have the RTEMS sources not in a Git
>>>>>>>> repository or
>>>>>>>> the Git repository has the wrong commit (git subtree for example).
>>>>>>>>
>>>>>>>> It could be also useful for the release archive. We could use
>>>>>>>> this scheme:
>>>>>>>>
>>>>>>>> * If the value is "git", then get the value from git.
>>>>>>>>
>>>>>>>> * If the value is "", then we use no version key.
>>>>>>>>
>>>>>>>> * Otherwise we set the key to the value.
>>>>>>>>
>>>>>>>> For the release archive we would set the default value of the
>>>>>>>> option from
>>>>>>>> "git" to "".
>>>>>>> I sent a patch with this approach:
>>>>>>>
>>>>>>> https://lists.rtems.org/pipermail/devel/2023-July/075989.html
>>>>>> Can you please just explain the mechanics of how this gets used?
>>>>>> While I could
>>>>>> try and guess but I would rather not. 😄
>>>>> In the v2 patch you just have to do this for a release archive:
>>>>>
>>>>> sed -i "s/ value: git/ value: ''/"
>>>>> spec/build/cpukit/optversioncontrolkey.yml
>>>>>
>>>> Does this mean the default is changed in the sources in the tarball?
>>>
>>> Yes, this is one option.
>>>
>>>>
>>>> Can the option be overridden in a config file?
>>>
>>> This depends on what we want. If you just change the default value,
>>> then you can
>>> change it in your config.ini. It will also show up in
>>>
>>> ./waf bspdefaults --rtems-bsps sparc/erc32| grep -B 10 VERSION
>>> COVERAGE_COMPILER_FLAGS =
>>> # Linker flags recommended for executables which contain modules which
>>> # generate coverage information.
>>> COVERAGE_LINKER_FLAGS =
>>> # This option defines what is returned by the directives
>>> # rtems_version() and rtems_version_control_key(). If the value is
>>> # "git", then the version key is determined by the Git repository
>>> # containing the waf top directory for each build process. If the
>>> # value is the empty string "", then no version key is used.
>>> # Otherwise, the value is used as the version key.
>>> RTEMS_VERSION_CONTROL_KEY = git
>>>
>>> If you want to hide this option, then we have to set the description
>>> to null.
>>>
>>> You can still set this option in this case. If you want to also
>>> disable this,
>>> then we have to use:
>>>
>>> actions:
>>> - set-value: ''
>>> - env-assign: null
>>>
>>> instead of
>>>
>>> actions:
>>> - get-string: null
>>> - env-assign: null
>>>
>>> A user can still edit the option item and change it to whatever, so I
>>> am not
>>> sure if it is worth hindering a user to do certain things.
>>
>> The policy we have been using is the RTEMS project owns the "clean"
>> version
>> numbers. for example 6.1.0 on all packages, the kernel etc. The
>> version details
>> have to be in the released source and so released tarball. The result
>> of an
>> untar of the released tar file, with the released SHA512 hash, means
>> the sources
>> contain the released version numbers. I would be concerned if someone
>> with the
>> SHA512 sources we release could have a different version number or label.
>>
>> I think allowing the version to be changed by a option when building goes
>> against the role version numbers have. You could end up with a number of
>> different versions of version labels for the same sources. I am fine
>> with users
>> deploying their own labelled build of our tools by adding a VERSION
>> file to the
>> top level directory of the RSB, rtems-tools etc. We are then able to
>> determine
>> the sources in a bug report. Users of deployed tools, kernel etc
>> should first
>> approach the provider of the tools before the project.
>>
>> Adding a file for a release, such as VERSION, means the files in a
>> release are
>> 1:1 with the files in git, ie the version detail is additional and not
>> a source
>> of merge conflicts.
>
> I think this is not really related to the new
> RTEMS_VERSION_VC_KEY/RTEMS_VERSION_CONTROL_KEY option. The purpose of
> this option is to give users the ability to define their own version
> control key.
I think we are broadly aligned however there are different labels for
some the pieces [1]. I have reviewed the existing code and then this
change and it seems the default is an empty string a user can altered
via a config.ini file. Is this correct?
Is this per BSP or global?
For me the sources are the controlled item the calls rtems_version() and
rtems_version_control_key() should report and not what a user can configure.
Why not just look for a file called VERSION and then a key=value pair
that is:
RTEMS_VERSION_VC_KEY=foo-bar
And document deployment users add this file and then configuration
control the released sources and this file?
[1] Informational only ..
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/version.py#n31
> How you get the release versions into the code base is another topic. If
> you want to use a VERSION file, then you have to add this support to the
> build system. An alternative is to modify the build items for the
> release commit. There are lots of different ways to do the versioning.
The release currently updates spec/build/cpukit/optvermaj.yml. The issue
with this is the file is not the exact file in the git repo but as you
say this is another topic now I have reviewed the detail more.
Chris
More information about the devel
mailing list