[PATCH] build: Add optional RTEMS_VERSION_VC_KEY
Sebastian Huber
sebastian.huber at embedded-brains.de
Fri Jul 28 08:26:19 UTC 2023
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.
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.
>
>>>>> We have an established method in other repos of adding a VERSION file to the
>>>>> source tarball. Why not follow that method?
>>>> This is certainly possible, however, this would add another configuration source
>>>> to the build system.
>>> Being consistent is a god thing. I am not sure what is required in the build
>>> system.
>
> Hmm, sorry that should have read "good"!
>
> Chris
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list