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
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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
