Hi,
> #define __MINGW32_VERSION 3.11
> #define __MINGW32_MAJOR_VERSION 3
> #define __MINGW32_MINOR_VERSION 11
> (...)
> #define __W32API_VERSION 3.8
> #define __W32API_MAJOR_VERSION 3
> #define __W32API_MINOR_VERSION 8
Well, how often do you change them?
Every time you make a change to the mingw32ce include files?
For simplicity reasons, I will only talk about mingw32ce (I don't have
much experience in cegcc, and you strongly discourage from using it).
My original idea was to introduce a special macro in form:
#define CEGCC_VERSION(VERSION,SUBVERSION,PATCHLEVEL) (((VERSION) <<
16) + ((SUBVERSION) << 8) + (PATCHLEVEL))
(You might need two macros, of course, one for mingw32ce, one for cegcc.)
Actually, this is not really my original idea. I just "copied" it from a
project which I am following (from time to time).
In the meantime, however, I've got yet another idea. That's also not my
original idea. I copied it from another project that I'm following (from
time to time).
What one needs is not just an abstract "version" of something, but a real
"patchlevel" of the WinCE include files and the WinCE DLL libraries.
The CeGCC project is not a "stable branch". Changes (fixed and addons)
happen very often, one really needs a way to deal with it smoothly.
That means, each time a header is modified/fixed and/or a mingw32ce
library function is fixed/added in the WinCE DLLs, there should be a new
"patchlevel" assigned (an always "increasing" value).
(You don't really need "separate" patchlevels for mingw32ce and cegcc.)
Then there should be a small file in which one should gather all these
"patchlevel" informations - what was changed/added (of course, there can
be separate files for mingw32ce and cegcc - each of them will keep just
the changes related to itself).
This may sound awkward, but I think that it might really help people.
How could such a "patchlevel" be assigned?
Well, you can assign arbitrary numbers (always increasing), starting from
1, for example, and adding 1 for each "patch", but ... a better idea is to
take the "date" of the patch commitment ("patchlevel = YearMonthDay"):
#define patchlevel 20071117
This way one can guarantee that this will always "increase".
You don't need "separate" patchlevels for mingw32ce and cegcc.
You don't really need the "time" - the day is fine (people will not really
download/install the CeGCC compiler every day several times).
Then, having the "patchlevel-description-file", I could simply:
#if (patchlevel > 20071116)
... the function and header are fixed
#else if (patchlevel > 20071012
... the function is not fixed, the header is o.k.
#else
... sorry, you have to upgrade to patchlevel > 20071012
#endif
> You're missing the fact that the same compiler can be used with
> different versions of the headers, or that an older version of
> the headers can be used with a newer version of binutils,
> or [ insert favorite permutation here ], which breaks the
> global version number scheme.
Well, the "normal" gcc compiler provides ("gcc/g++ -dumpspecs"):
-D__GNUC__=%v1
-D__GNUC_MINOR__=%v2
-D__GNUC_PATCHLEVEL__=%v3
-D__GXX_ABI_VERSION=some_magic_number (no idea what it is)
Do I need more?
Binutils are not related to the compilation of the source code.
If they are not working, get another version that does.
> Looks like we're missing a cegcc.h header for the
> cegcc.dll runtime versioning indeed. But that should
> represent the runtime version alone.
That's a very good point, too.
But it might be hard to realize.
The standard "glibc" needed also some time to deal with it.
The DLL versioning is definitely something one should think about.
However, we need it more for user DLLs, not for the WiCE system provided
DLLs - they are pretty "stable" (a much more serious problem is that
different WinCE systems provide different sets of implemented functions,
despite the kernel version "equality" - I don't really have any idea how
to deal with it).
Best regards,
Jacek.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
