[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
why is RTEMS_VERSION not set?
- Date: Wed, 26 Feb 2003 10:07:46 -0800
- From: strauman at SLAC.Stanford.EDU (Till Straumann)
- Subject: why is RTEMS_VERSION not set?
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
>>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_
Guess what: I have the application print its version AND I
have it print the RTEMS_VERSION.
>>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.
use RTEMS_VERSION also.
> - 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?"
I'm not saying this is a terrible issue with top priority - 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.
> Cf. /usr/include/features.h from glibc on your linux box and __GLIBC__ +