Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-08-01 Thread Sebastian Huber 

On 01.08.23 00:43, Chris Johns wrote:

I think naming this option RTEMS_VERSION_CONTROL_KEY makes more sense, since the
corresponding RTEMS API directive is rtems_version_control_key(). Is VC a well
known abbreviation?

The name in the API is what it is and I am not suggesting it be changed. Maybe
it could have been more general to serve a wider purpose than just the VC but it
is there now so that time has passed.


This define is only internally used. The API element is 
rtems_version_control_key().


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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-31 Thread Chris Johns 
On 31/7/2023 5:14 pm, Sebastian Huber wrote:
> On 29.07.23 08:30, Chris Johns wrote:
>>> 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?
> 
> In v2 of the patch, the default is "git" indicating that the version control 
> key
> should be obtained using Git.

What version control keys are supported?

>>
>> Is this per BSP or global?
> 
> This is per BSP. All the configuration options are per BSP. In your config.ini
> you can set options for all BSPs via the [DEFAULT] section.

Per BSP does not make sense. Having a means for a user to inject anything at
build time is confusing to me because it can be different for the same set of
sources.

>> 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.
> 
> We don't control the version control system of the user, so it should be user
> configurable.

The configuration file controls a build and this setting changes the meaning of
the configuration data being built. It does not align.

>> Why not just look for a file called VERSION and then a key=value pair that 
>> is:
>>
>> RTEMS_VERSION_VC_KEY=foo-bar
> 
> Why not just use what is normally used by the build system? Supporting the
> VERSION file needs extra code for only one purpose.

Yes releasing RTEMS. At the moment a get clone of a release tag will show a file
does not match. In a formal sense that would require a special consideration
that would need to be documented and applied.

> I think naming this option RTEMS_VERSION_CONTROL_KEY makes more sense, since 
> the
> corresponding RTEMS API directive is rtems_version_control_key(). Is VC a well
> known abbreviation?

The name in the API is what it is and I am not suggesting it be changed. Maybe
it could have been more general to serve a wider purpose than just the VC but it
is there now so that time has passed.

>>
>> And document deployment users add this file and then configuration control 
>> the
>> released sources and this file?
> 
> The config.ini are not included in the sources shipped with RTEMS and they can
> be version controlled by the user.

That is the central point I am attempting to make. Version data should be the
version of the sources shipped and not the build.

A build label is different and would clearly state the purpose and if I see a
bug report I can ignore it and concentrate on the version data.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-31 Thread Sebastian Huber 



On 29.07.23 08:30, Chris Johns wrote:
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?


In v2 of the patch, the default is "git" indicating that the version 
control key should be obtained using Git.




Is this per BSP or global?


This is per BSP. All the configuration options are per BSP. In your 
config.ini you can set options for all BSPs via the [DEFAULT] section.




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.


We don't control the version control system of the user, so it should be 
user configurable.




Why not just look for a file called VERSION and then a key=value pair 
that is:


RTEMS_VERSION_VC_KEY=foo-bar


Why not just use what is normally used by the build system? Supporting 
the VERSION file needs extra code for only one purpose.


I think naming this option RTEMS_VERSION_CONTROL_KEY makes more sense, 
since the corresponding RTEMS API directive is 
rtems_version_control_key(). Is VC a well known abbreviation?




And document deployment users add this file and then configuration 
control the released sources and this file?


The config.ini are not included in the sources shipped with RTEMS and 
they can be version controlled by the user.




[1] Informational only .. 
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/version.py#n31


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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-28 Thread Chris Johns 

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
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
    > 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 00..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_k

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-28 Thread Sebastian Huber 

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
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
    > 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 00..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 Gi

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-27 Thread Chris Johns 
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
 >>> >
 wrote:

    On 25.07.23 19:09, Joel Sherrill wrote:
    >
    > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
    > >>> 
    > >> 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 00..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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-26 Thread Sebastian Huber 

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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-26 Thread Chris Johns 


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
>> > >
>> wrote:
>>
>>   On 25.07.23 19:09, Joel Sherrill wrote:
>>   >
>>   > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
>>   > > 
>>   > > >> 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 00..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?

Can the option be overridden in a config file?

>>
>> We have an established method in other repos of adding a VERSION file to the
>> source tarball. Why not follow that m

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Sebastian Huber 

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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Chris Johns 
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
 >>> >
 wrote:

  On 25.07.23 19:09, Joel Sherrill wrote:
  >
  > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
  > >>> 
  > >> 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 00..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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Sebastian Huber 



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
>

wrote:

 On 25.07.23 19:09, Joel Sherrill wrote:
 >
 > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
 > 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 00..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

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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Sebastian Huber 

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
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
 > 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 00..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 "".


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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Chris Johns 
On 26/7/2023 4:27 am, Joel Sherrill wrote:
> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>  >
> wrote:
> 
> On 25.07.23 19:09, Joel Sherrill wrote:
> >
> > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
> >  
> >  >> 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 00..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.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Joel Sherrill 
On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber <
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
> >  > > 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 00..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.

--joel

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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Sebastian Huber 

On 25.07.23 19:09, Joel Sherrill wrote:


On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber 
> 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 00..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?


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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-25 Thread Joel Sherrill 
On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber <
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 00..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?

I'm reading this as a project specific version string in addition to major
and minor.

And that if used, it would be the responsibility of the user to track that
back to revision control hash.

If so, this likely needs a bit more written.

Right?

--joel


> +enabled-by: true
> +format: '{}'
> +links: []
> +name: RTEMS_VERSION_VC_KEY
> +type: build
> diff --git a/wscript b/wscript
> index 862000513d..2026d55070 100755
> --- a/wscript
> +++ b/wscript
> @@ -58,38 +58,44 @@ def no_unicode(value):
>
>
>  class VersionControlKeyHeader:
> -_content = None
> +_git_commit = None
>
>  @staticmethod
>  def write(bld, filename):
> -if VersionControlKeyHeader._content is None:
> -from waflib.Build import Context
> -from waflib.Errors import WafError
> -
> -content = """/*
> +content = """/*
>   * Automatically generated. Do not edit.
>   */
>  #if !defined(_RTEMS_VERSION_VC_KEY_H_)
>  #define _RTEMS_VERSION_VC_KEY_H_
>  """
> -try:
> -rev = bld.cmd_and_log("git rev-parse HEAD",
> -  quiet=Context.STDOUT).strip()
> -content += """#define RTEMS_VERSION_VC_KEY "{}"
> +rev = bld.env.RTEMS_VERSION_VC_KEY
> +if not rev:
> +rev = VersionControlKeyHeader._git_commit
> +if rev is None:
> +from waflib.Build import Context
> +from waflib.Errors import WafError
> +
> +try:
> +rev = bld.cmd_and_log("git rev-parse HEAD",
> +  quiet=Context.STDOUT).strip()
> +except WafError:
> +rev = ""
> +VersionControlKeyHeader._git_commit = rev
> +if rev:
> +content += """#define RTEMS_VERSION_VC_KEY "{}"
>  """.format(rev)
> -except WafError:
> -content += """/* No version control key found; release? */
> +else:
> +content += """/* No version control key found; release? */
>  """
> -content += """#endif
> +content += """#endif
>  """
> -VersionControlKeyHeader._content = content
>  f = bld.bldnode.make_node(filename)
>  f.parent.mkdir()
>  try:
>  if content != f.read():
> -f.write(VersionControlKeyHeader._content)
> +f.write(content)
>  except:
> -f.write(VersionControlKeyHeader._content)
> +f.write(content)
>
>
>  class EnvWrapper(object):
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel