On 28.07.23 07:37, Chris Johns wrote:
On 27/7/2023 3:59 pm, Sebastian Huber wrote:
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.
The policy we have been using is the RTEMS project owns the "clean" version
numbers. for example 6.1.0 on all packages, the kernel etc. The version details
have to be in the released source and so released tarball. The result of an
untar of the released tar file, with the released SHA512 hash, means the sources
contain the released version numbers. I would be concerned if someone with the
SHA512 sources we release could have a different version number or label.
I think allowing the version to be changed by a option when building goes
against the role version numbers have. You could end up with a number of
different versions of version labels for the same sources. I am fine with users
deploying their own labelled build of our tools by adding a VERSION file to the
top level directory of the RSB, rtems-tools etc. We are then able to determine
the sources in a bug report. Users of deployed tools, kernel etc should first
approach the provider of the tools before the project.
Adding a file for a release, such as VERSION, means the files in a release are
1:1 with the files in git, ie the version detail is additional and not a source
of merge conflicts.
I think this is not really related to the new
RTEMS_VERSION_VC_KEY/RTEMS_VERSION_CONTROL_KEY option. The purpose of
this option is to give users the ability to define their own version
control key.
How you get the release versions into the code base is another topic. If
you want to use a VERSION file, then you have to add this support to the
build system. An alternative is to modify the build items for the
release commit. There are lots of different ways to do the versioning.
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.
Hmm, sorry that should have read "good"!
Chris
--
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
