[PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Chris Johns]

On 3/5/17 4:28 pm, Sebastian Huber wrote:
> On 03/05/17 08:17, Chris Johns wrote:
>> On 3/5/17 3:40 pm, Sebastian Huber wrote:
>>> On 03/05/17 07:28, Chris Johns wrote:
>>>> On 3/5/17 3:09 pm, Sebastian Huber wrote:
>>>>> On 02/05/17 23:30, Chris Johns wrote:
>>>>>> On 2/5/17 6:20 pm, Sebastian Huber wrote:
>>>>>> [...]
>>>>>> If you want to add this test please extract the version details from
>>>>>> the
>>>>>> build system
>>>>> Can we trust the build system?
>>>>>
>>>> Given the header file with the values it created by the build system
>>>> yes
>>>> we can.
>>> I don't think we can trust the build system. The requirement for a
>>> release is that the version macros should have specific values. We
>>> should test that this is the case.
>> We have to trust the build system for a clean or fresh build and if we
>> cannot not it is a bug. To state otherwise expands the scope of
>> uncertainty and I do not believe we need too.
>>
>> I will state again, doing this breaks the release process. I am sorry
>> but this is just now the release model and supporting configuration
>> control structures exist.
> 
> I still don't see how this breaks the release process. One task of it is
> surly to change the version from N to N + 1. This requires to modify
> some files (with a script). This test would be just one of these files.
> Some are *.m4 files, some *.c files, it doesn't matter.

It is not that simple. The details are in the rtems-release.git repo.
There are a number of ways this can be done, I have settled on this
release model and I do not wish to revisit it. It has been like this for
while now and given I am the only one doing any of this it is reasonable
to have the major say. All efforts have been unfunded.

A release is defined as the compressed tar file and the release
signature is the SHA512 hash. A release defined this way is unique and
this is important. You cannot clone it, you can only clone an equivalent
and that equivalent will have the branch's version numbering not the
release's version numbers, again this is important. The cloned version
and the real release are not able to be mixed without direct
intervention by someone and that invalidates the configuration. The
release's tar file contains file system's meta data which effects the
SHA512 hash and that makes replication difficult.

The version.m4 file are modified during the release process to the
release specific details and the build system files are generated. This
is understood and accepted and that part of the release can be
separately audited and checked. The RSB, docs and rtems-tools have a
different method where a VERSION file is added to the archived cloned
repo files.

The release branch version tested is the version released and tagged. It
does not contain extra commits to fiddle embedded version numbers such
as this test. There is also no need to perform any post release commits
on a release branch to put back the release branch version numbers which
is needed to make the repo meet the release branch requirements for the
next dot release. I wanted to avoid this type of repo noise and the
complexity created if any of the commits needed fail requiring recovery
processes. Any time manual actions are needed auditing demands increase.
It is not enough to have requirements, you need to prove it happened.

I do not want the release process touching .c, .h etc type files. I am
touching the version.m4 files because I have too. I would prefer to add
a file.

The release process runs without intervention from the start to the end
across a number of repos and packages. Once created a separate process
runs to tag the repos and the release hash.

I hope this helps explain what is happening.

> 
>>
>>> Maybe we have some time in the future something like this:
>>>
>>> Requirement 2341: There shall be a C pre-processor define
>>> __RTEMS_MAJOR__ available via #include <rtems.h> defined to 123.
>> I doubt this would be in the RTEMS Project's requirements. It might be
>> in a qualification package for the specific qualification effort.
> 
> It is a RTEMS Project's requirement. Its just not explicitly stated. If
> you release RTEMS 3.4.531 a user expects to have
> 
> #define __RTEMS_MAJOR__ 3
> #define __RTEMS_MINOR__ 4
> #define __RTEMS_REVISION__ 531
> 

Yes but the requirement does not state exact version numbers, rather it
would define the release number fields, what they mean, how and why they
change, and how they can be used in software via the defines.

>> How
>> that define it created is for the RTEMS Project to determine.
> 
> Yes, but somehow the define must exist with the right value and this is
> what needs to be tested.
> 

Is this a cat in a box type issue?

I am happy for a test to check the macros are suitably formed and meet
the needs of the compiler, language etc.

I feel any specific version check is something a user needs to wrap
around RTEMS once installed. They could grep, sed and check the values
because the test confirms they are correctly formed.

Chris