why is RTEMS_VERSION not set?

Ralf Corsepius corsepiu at faw.uni-ulm.de
Wed Feb 26 17:44:07 UTC 2003


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.

> 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 - Compilation
could complain or fall back to something compatible if using
incompatible versions.

Cf. /usr/include/features.h from glibc on your linux box and __GLIBC__ +
__GLIBC_MINOR__.

Ralf






More information about the users mailing list