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.hu...@embedded-brains.de >>>>>> <mailto:sebastian.hu...@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.hu...@embedded-brains.de >>>>>> <mailto:sebastian.hu...@embedded-brains.de> >>>>>> > <mailto:sebastian.hu...@embedded-brains.de >>>>>> <mailto:sebastian.hu...@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? Can the option be overridden in a config file? >> >> 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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
