Jacek M. Holeczek wrote:
> 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?
These are changed when I do a merge from upstream.
> Every time you make a change to the mingw32ce include files?
>
Of course not.
> 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.)
>
I understood that already. You want a way to get at the
version number. Fine. What I'm saying is that what you
think is the version number, isn't very helpful. I gather
from you examples that you're mostly interested in the macro
to get around header changes. I would be really interested in
a real practical example of what you're saying, because without
one, I'll say that if you want to support older releases of
mingw32ce, and you happen to be using one of the
structs/defines/functions that is broken, you'll have to
somehow define a correct version in your sources anyway.
Example:
#ifdef __MINGW32CE__ < MINGW32CE_VERSION(0,5,0)
(...)
#define REPLACEMENT_XXX
#define XXX REPLACEMENT_XXX
struct replacement_xxx { (...) };
#define xxx replacement_xxx
(...)
#endif
If that was the case, you'd better off just
unconditionally defining the replacements and be
done with it:
(...)
#define REPLACEMENT_XXX
#define XXX REPLACEMENT_XXX
struct replacement_xxx { (...) };
#define xxx replacement_xxx
(...)
But, now imagine that the XXX define comes from
src/w32api/include/*, and imagine yourself some point
in the future when were releasing w32api seperatelly
from the full bundle, because it changes much more
frequently (a much smaller download is another
advantage) (That's how MinGW/Cygwin releases works
too, BTW) than gcc or mingw or binutils.
So you have a base mingw32ce 1.0.2 package, and you decide
to update w32api to CE release 6.7.4 which is based
on upstream version 4.3.9. Would the
MINGW32CE_VERSION(1,0,2) mean anything then?
(... snip example of how to increment a number ...)
>
>> 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?
>
Those are useful to know the version of gcc you're building
against. That's it. Sure, we could have some macro for the
our own mingw32ce-gcc version. It could even be __MINGW32CE__
itself, but would that really really be useful? Again, let
me reiterate that its the version of the header set that you
want most of the times. The versioning concept already
exists, in the form of __MINGW32_VERSION, __W32API_VERSION,
but it was never extended to differenciate our own fork ---
mainly because we always kept the idea that we would
someday migrate our changes upstream, which would obsolete
any versioning we'd invent on top of the existing.
> Binutils are not related to the compilation of the source code.
> If they are not working, get another version that does.
>
Huh? I could say the same to any other component of
the toolchain. I only mentioned binutils, because you mentioned
something about windres, which comes from binutils...
I agree with Danny when he says:
"I understand your point, but the gcc build system is rather complicated
already. Introducing this into it is not something I'd like to do for
two reasons : the complexity, and the same argument as with the include
files (you can't keep this in sync with the original tool sources).
Besides, even though I understand the need for supporting a cegcc
version number, it is hardly something I want to encourage. So I don't
mind if using it is a little hard :-) "
>> 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.
We're talking about compile time versioning. Runtime
versioning is another (bigger) problem in Windows.
> 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).
>
The easiest is to not do a thing about it :-)
I don't have platform builder experience, but my understanding
is that except for core funcionality, every CE based device
could have a different set of supported functions. That is no
generic SDK.
There's a notion of something like "profiles" - Windows Mobile,
Pocket PC, SmartPhone. Does MSFT have any macro to differentiate
those in the headers? We could support that too. Supporting
every other device that doesn't fall in some standard profile
would be impossible. It is the developers responsability to
garanty that he's linking with the lowest common set of
functions he should support, and dynamically loading the
rest.
--
Pedro Alves
-------------------------------------------------------------------------
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
