[PATCH] build: Add optional RTEMS_VERSION_VC_KEY

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Jul 27 05:59:59 UTC 2023 

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.

> 
>>> 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.

-- 
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