* [ECOS] serial_devio renamaed to cyg_serial_devio
@ 2000-06-14 1:21 Andrew Lunn
2000-06-14 1:26 ` John Dallaway
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2000-06-14 1:21 UTC (permalink / raw)
To: ecos-discuss
Hi Folks
I just started to play with 1.3.X release and found that there has
been a few minor changes in the serial drivers. The first one i've
found is that the global serial_devio has been renamed to
cyg_io_serial_devio. Is it possible to get at the version number of an
ecos package as a pre-processor symbol? That way i can have #ifdefs to
select between 1.2.X and 1.3.X ways of doing things.
Thanks
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [ECOS] serial_devio renamaed to cyg_serial_devio
2000-06-14 1:21 [ECOS] serial_devio renamaed to cyg_serial_devio Andrew Lunn
@ 2000-06-14 1:26 ` John Dallaway
2000-06-14 2:25 ` Andrew Lunn
0 siblings, 1 reply; 6+ messages in thread
From: John Dallaway @ 2000-06-14 1:26 UTC (permalink / raw)
To: ecos-discuss
Hi Andrew,
To access eCos package versions:
#include <pkgconf/system.h>
John Dallaway
> -----Original Message-----
> From: ecos-discuss-owner@sourceware.cygnus.com
> [ mailto:ecos-discuss-owner@sourceware.cygnus.com]On Behalf Of Andrew
> Lunn
> Sent: 14 June 2000 09:21
> To: ecos-discuss@sourceware.cygnus.com
> Subject: [ECOS] serial_devio renamaed to cyg_serial_devio
>
> Is it possible to get at the version number of an
> ecos package as a pre-processor symbol? That way i can have #ifdefs to
> select between 1.2.X and 1.3.X ways of doing things.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] serial_devio renamaed to cyg_serial_devio
2000-06-14 1:26 ` John Dallaway
@ 2000-06-14 2:25 ` Andrew Lunn
2000-06-14 4:58 ` Bart Veer
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2000-06-14 2:25 UTC (permalink / raw)
To: John Dallaway; +Cc: ecos-discuss
Unfortunally this only works for 1.3.x. 1.2.x does not have the
version info, just a #define if the package is included.
My problem is 1.2.x defines
#define CYGPKG_IO_SERIAL
and 1.3.x defines
#define CYGPKG_IO_SERIAL v1_3_5
#define CYGPKG_IO_SERIAL_v1_3_5
and i want something which says
#if CYGPKG_IO_SERIAL > v1.2
new serial code fragment
#else
old serial code fragment
#endif
Any ideas anyone?
Thanks
Andrew
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi Andrew,
>
> To access eCos package versions:
>
> #include <pkgconf/system.h>
>
> John Dallaway
>
> > -----Original Message-----
> > From: ecos-discuss-owner@sourceware.cygnus.com
> > [ mailto:ecos-discuss-owner@sourceware.cygnus.com]On Behalf Of Andrew
> > Lunn
> > Sent: 14 June 2000 09:21
> > To: ecos-discuss@sourceware.cygnus.com
> > Subject: [ECOS] serial_devio renamaed to cyg_serial_devio
> >
> > Is it possible to get at the version number of an
> > ecos package as a pre-processor symbol? That way i can have #ifdefs to
> > select between 1.2.X and 1.3.X ways of doing things.
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] serial_devio renamaed to cyg_serial_devio
2000-06-14 2:25 ` Andrew Lunn
@ 2000-06-14 4:58 ` Bart Veer
2000-06-14 5:18 ` Andrew Lunn
0 siblings, 1 reply; 6+ messages in thread
From: Bart Veer @ 2000-06-14 4:58 UTC (permalink / raw)
To: andrew.lunn; +Cc: jld, ecos-discuss
>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:
Andrew> Unfortunally this only works for 1.3.x. 1.2.x does not have the
Andrew> version info, just a #define if the package is included.
Andrew> My problem is 1.2.x defines
Andrew> #define CYGPKG_IO_SERIAL
Andrew> and 1.3.x defines
Andrew> #define CYGPKG_IO_SERIAL v1_3_5
Andrew> #define CYGPKG_IO_SERIAL_v1_3_5
Andrew> and i want something which says
Andrew> #if CYGPKG_IO_SERIAL > v1.2
Andrew> new serial code fragment
Andrew> #else
Andrew> old serial code fragment
Andrew> #endif
Andrew> Any ideas anyone?
I do not think there is any easy way of achieving this at present. The
C preprocessor can only do numerical comparisons. Version numbers can
be much more complicated than just a simple number, so trying to use
the > or < operators is not going to work.
What might be possible is for the configuration tools to generate
additional #define's along the lines of:
#define CYGPKG_IO_SERIAL v1_3_5
#define CYGPKG_IO_SERIAL_VERSION_MAJOR 1
#define CYGPKG_IO_SERIAL_VERSION_MINOR 3
...
Some other systems like Tcl already do this, updating the exported
header file by hand for every release and every snapshot. In the CDL
world this could be automated.
I am not quite sure what to call the versioning levels after major or
minor, there could be any number of these. Also versions may include
letters or text, e.g. 1.3.5beta, and attempting to use C preprocessor
operators on 5beta will probably give a strange compiler error
message. There could also be problems if packages try to define
options with those names.
Arguably the correct solution is a more powerful C preprocessor, but
that is not likely to happen any time soon.
Bart
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] serial_devio renamaed to cyg_serial_devio
2000-06-14 4:58 ` Bart Veer
@ 2000-06-14 5:18 ` Andrew Lunn
2000-06-14 7:26 ` Bart Veer
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2000-06-14 5:18 UTC (permalink / raw)
To: bartv; +Cc: andrew.lunn, jld, ecos-discuss
> I do not think there is any easy way of achieving this at present.
OK. Lets think about the future. The aim of using packages is so that
3rd parties can develop there own packages which can be plugged into
the standard distribution. Things change, move on, and are no longer
compatible. As this has shown you sometimes need the version
information to work out what to do to make things work with different
versions.
It seems to me there are two ways to do this, which are not mutually
exclusive. If there are big changes you distribute multiple packages
and let CDL work out the dependances and pick the correct package to
use. If the changes are minor, as in this cause just one variable
name, #ifdef seems a good way to go.
> What might be possible is for the configuration tools to generate
> additional #define's along the lines of:
>
> #define CYGPKG_IO_SERIAL v1_3_5
> #define CYGPKG_IO_SERIAL_VERSION_MAJOR 1
> #define CYGPKG_IO_SERIAL_VERSION_MINOR 3
> ...
Sounds good.
> I am not quite sure what to call the versioning levels after major or
> minor, there could be any number of these.
CYGPKG_IO_SERIAL_VERSION_VERY_MINOR? You have to draw the line
somewhere. 3 levels seems enough to me.
> Also versions may include letters or text, e.g. 1.3.5beta
Specify that any trailling text are removed to leave an integer?
So, do we need this sort of versioning features? Is this a good approch?
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] serial_devio renamaed to cyg_serial_devio
2000-06-14 5:18 ` Andrew Lunn
@ 2000-06-14 7:26 ` Bart Veer
0 siblings, 0 replies; 6+ messages in thread
From: Bart Veer @ 2000-06-14 7:26 UTC (permalink / raw)
To: andrew.lunn; +Cc: ecos-discuss
>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:
>> I do not think there is any easy way of achieving this at
>> present.
Andrew> OK. Lets think about the future. The aim of using packages
Andrew> is so that 3rd parties can develop there own packages
Andrew> which can be plugged into the standard distribution.
Andrew> Things change, move on, and are no longer compatible. As
Andrew> this has shown you sometimes need the version information
Andrew> to work out what to do to make things work with different
Andrew> versions.
Incompatible interface changes between versions, especially minor
releases, should be avoided. The original name serial_devio was wrong,
there should have been a prefix such as cyg_ in there from the
beginning to reduce the possibility of name clashes. In practice
getting all these things right takes time.
Strictly speaking the serial renaming should have involved a major
version upgrade, to V2.0, but we are not set up just yet to release
core packages with different version numbers. Such functionality will
be more and more important in future: it is quite likely that some
packages, e.g. platform HAL's, will not change at all between core
releases; there is no point in having separate installed versions x
and y of a package when the two are identical. This will require
enhancements to the release system and to the administration tools.
However some way of coping with interface changes is desirable.
Andrew> It seems to me there are two ways to do this, which are
Andrew> not mutually exclusive. If there are big changes you
Andrew> distribute multiple packages and let CDL work out the
Andrew> dependances and pick the correct package to use. If the
Andrew> changes are minor, as in this cause just one variable
Andrew> name, #ifdef seems a good way to go.
Agreed.
>> What might be possible is for the configuration tools to generate
>> additional #define's along the lines of:
>>
>> #define CYGPKG_IO_SERIAL v1_3_5
>> #define CYGPKG_IO_SERIAL_VERSION_MAJOR 1
>> #define CYGPKG_IO_SERIAL_VERSION_MINOR 3
>> ...
Andrew> Sounds good.
>> I am not quite sure what to call the versioning levels after major or
>> minor, there could be any number of these.
Andrew> CYGPKG_IO_SERIAL_VERSION_VERY_MINOR? You have to draw the
Andrew> line somewhere. 3 levels seems enough to me.
>> Also versions may include letters or text, e.g. 1.3.5beta
Andrew> Specify that any trailling text are removed to leave an
Andrew> integer?
Andrew> So, do we need this sort of versioning features? Is this a
Andrew> good approch?
Unless somebody comes up with a better suggestion, or discovers a
major flaw in this approach, I think something along these lines is
worthwhile. I'll add it to the libcdl TODO list, which unfortunately
is rather longer than I would like. If this is proving a major problem
for you, and since Ascom is a paying customer, you may want to file a
formal problem report to get its priority raised.
Bart
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-06-14 7:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-14 1:21 [ECOS] serial_devio renamaed to cyg_serial_devio Andrew Lunn
2000-06-14 1:26 ` John Dallaway
2000-06-14 2:25 ` Andrew Lunn
2000-06-14 4:58 ` Bart Veer
2000-06-14 5:18 ` Andrew Lunn
2000-06-14 7:26 ` Bart Veer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).