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

Reply via email to