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