On 28/7/2023 6:26 pm, Sebastian Huber wrote:
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.
I think we are broadly aligned however there are different labels for
some the pieces [1]. I have reviewed the existing code and then this
change and it seems the default is an empty string a user can altered
via a config.ini file. Is this correct?
Is this per BSP or global?
For me the sources are the controlled item the calls rtems_version() and
rtems_version_control_key() should report and not what a user can configure.
Why not just look for a file called VERSION and then a key=value pair
that is:
RTEMS_VERSION_VC_KEY=foo-bar
And document deployment users add this file and then configuration
control the released sources and this file?
[1] Informational only ..
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/version.py#n31
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.
The release currently updates spec/build/cpukit/optvermaj.yml. The issue
with this is the file is not the exact file in the git repo but as you
say this is another topic now I have reviewed the detail more.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
