Re: [Mingw-users] definition of mingw version

[Keith M. <kei...@us...>]

On Monday 15 September 2008 22:40:14 Roumen Petrov wrote:
> > If that's what you see on GNU/Linux, then your glibc has a
> > seriously defective strtod() implementation.
>
> May be is broken, but it pass all python tests,

Really?  Then the python tests aren't much cop, if

  x=%.17g (strtod)

is the expected output, in every case, for that's what appears 
throughout the strtod-gcc.log file you attached.

> >> What about printf output ? Is it correct ?
> >
> > Yes, for the MSVCRT implementation.  Try compiling your test case
> > with -ansi, and see the difference, (with 3.15).
>
> According python tests cases {v}snprintf from mingwex is fine.

And, for mingwrt-3.15, if you compile with -ansi, or -posix, or any of 
the defines mentioned in the release notes, this should also extend 
to {,f,s,v,vf,vs}printf() too.

> > And by the same token, you can just as well test the MAJOR and
> > MINOR versions, perhaps combining them, as Greg suggests.
>
> Multiplication is so fast operation.

We are talking about a compile time operation, which might be done 
once or twice in a build cycle, so I would suggest that the overhead 
wouldn't be worth worrying about.

> What about a definition like this one:
> ((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION )

Well yes, that might have been my choice too; the point was that you 
can combine these two in a manner which facilitates a convenient 
check for a minimum version number, *if* you need such a check, (and 
you really should not be relying on this extensively).

> If the final decision as result of this discussion is don't change
> existing one and to add a new definition I will accept too.

You are free to add whatever extra definitions you wish, in your own 
code; I see no pressing need for any more than the system headers 
provide at present.  Ultimately, it is down to Chris' discretion, 
whether he wishes to pander to your whim, or not; IMO, it isn't 
necessary for him to do anything.

> >> ... the autoconf script is buggy:
> >> $ ./configure --help
> >> `configure' configures mingw-runtime __MINGW32_VERSION to adapt
> >> to many kinds of systems.
> >> The macro MINGW_AC_CONFIG_SRCDIR is not enough.
> >
> > Well, *I* wrote that macro, and I resent you glibly calling it
> > buggy, without offering any alternative; it does what it says on
> > the tin, and it is *your* expectations which are buggy.  (FWIW, I
> > wrote the macro to use the format the package maintainer had
> > already chosen for the definition of __MINGW32_VERSION; I could
> > have worked with either format, and chose not to demand that the
> > maintainer change it.  If there is a bug, it is possible that the
> > PACKAGE_VERSION should not be incorporated into PACKAGE_TARNAME).
>
> Ok. The bug is that you try to replace internal autoconf variables,

No, I don't; I replace only public variables...

> but the second argument of AC_INIT is cached

It isn't, in the strict sense of autoconf caching, but it is used at 
other places within the configure script, than simply to assign a 
value to $PACKAGE_VERSION.  The effect is benign, but I take your 
point -- it may not be particularly desirable.  I'll discuss this 
with Chris, and we'll agree how to improve the aesthetics, if at all, 
possibly for the next release.

> For now I would like to get only the name of the macros that we
> could use in #if statement.

They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for 
mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for 
w32api.  You can depend on nothing else, unless you wish to make your 
own software depend on some future, unknown versions of these two, 
which may or may not be released at some time beyond your control.

Regards,
Keith.