why is RTEMS_VERSION not set?

[Ralf Corsepius]

Am Mit, 2003-02-26 um 19.07 schrieb Till Straumann:
> Ralf Corsepius wrote:
> > Am Mit, 2003-02-26 um 18.24 schrieb Till Straumann:
> > 
> >>Ralf Corsepius wrote:
> >>
> >>>Am Mit, 2003-02-26 um 16.01 schrieb Valette Eric:
> >>>
> >>>
> >>>>Joel Sherrill wrote:
> >>>>
> >>>>
> >>>>
> >>>>>As a side note, I think it would be nice to have some
> >>>>>cpp constants like RTEMS_VERSION_MAJOR, RTEMS_VERSION_MINOR or
> >>>>>something that could be tested in conditional code. It has
> >>>>>been disccused a few times over the years but never got to a 
> >>>>>concrete proposal that would be useful to applciations.
> >>>>
> >>>>While I do not really care about RTEMS_VERSION, it is sometimes useful 
> >>>>for system to provide such information so that specific work around can 
> >>>>be developed for a particular version or incompatible API's... 
> >>>
> >>>The problem with the current implementation of RTEMS_VERSION is it being
> >>>a string. 
> >>>
> >>
> >>I was actually quite happy with the string version. I am ofter playing
> >>with different versions and I like an application printing the
> >>RTEMS version string. In case I discover a problem with an application,
> > 
> > 
> > Note: application! 
> > 
> > Nothing prevents you from composing a string inside of _your_ 
> > application.
> > 
> 
> Guess what: I have the application print its version AND I
> have it print the RTEMS_VERSION.
Use uname(2) instead.

> >>I have a clear indication what version I (or one of my colleagues)
> >>had it built with (I usually also include a 'build-date' string).
> > 
> > You won't need it if we had numerical version defines 
> 
> Sure - it was just a surprise to me that RTEMS_VERSION just disappeared.
> 
> FYI:
> 
>    powerpc/shared/startup/bspstart.c
This needs to be investigated.

> and
> 
>    cpukit/libcsupport/src/utsname.c
> 
> use RTEMS_VERSION also.
Yes, but this IMO is an rtems internal implementation detail.

> > - Compilation
> > could complain or fall back to something compatible if using
> > incompatible versions.
> 
> I'm not (only) concerned with compiling. I have someone out there 
> running an application. They come to me and say: hey, there's a crash.
> I'd like to be able to ask them: "What does the version string say?"
Well, how would you to tell the person to retrieve the version string?

Several ways:
1) Run the application and check what it says. -> uname
2) If the application doesn't start up at all, "Get yourself a
disassembler" and try to find the contents of some version string.
-> You won't see RTEMS_VERSION because it is a #define.
With some luck, however, you can figure out the contents of
_RTEMS_version.
3) Adding a versioned symbol to librtemscpu, one can retrieve by using
"nm -s". This currently is not implemented, but would not be too
difficult to do.

> I'm not saying this is a terrible issue with top priority
Well, not top priority, but high priority to me, because the way 
RTEMS_VERSION and _RTEMS_version currently is set up is origin of pretty
large chain of structural issues in RTEMS.

>  - I was just
> asking why it doesn't work anymore (and part of the automagic seems
> to still mention or use and define it). I thought it was broken because 
> RTEMS_VERSION is still defined but has no value.
FYI: I fixed it in CVS. (cpukit/configure.ac)

Ralf