[PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Chris Johns]

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:
>>> +  rtems_test_assert(__RTEMS_MAJOR__ == 4);
>>> +  rtems_test_assert(__RTEMS_MINOR__ == 11);
>>> +  rtems_test_assert(__RTEMS_REVISION__ == 99);
>> Please do not push this test like this, it breaks releases. The test
>> will never pass on a release.
> 
> In case someone adjusts the version number, this test must be adjusted
> accordingly.

As I said please do not push this test like this. Releasing does not
work this way. It breaks the releases and if pushed it will become a
release blocker.

> Where do I find the right document to mention this?

If you are asking where to document updating this test please do not
bother. This type of data should not exist in sources that need to be
committed and pushed. It can exist in the current build system files
(version.m4) and any generated files packaged in to a release. As a
result I do not accept this test as it stands for RTEMS.

I am happy to see something that clearly states there is to be no
numbering related to the "current" version numbering to be placed in
source files. The version can exist in the current list of version.m4
files and these can be used to create suitable compiler command line
defines. Maybe this needs to be added to the coding standard.

>>
>> 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 assume the test is checking the build system is correctly creating the
header file. Maybe it should check the values are only numbers.

Chris