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. :) We have an established method in other repos of adding a VERSION file to the source tarball. Why not follow that method? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
