Re: [Mingw-users] Re: Make configuration for Win32.

[Paul G.]

forgive the cross-post...

On 9 Sep 2002 at 22:41, Paul D. Smith wrote:

> %% "Luke Dunstan" <address@hidden> writes:
> 
>   ld> I don't quite understand what is wrong with _WIN32, but I also
>   ld> wouldn't object to __WINDOWS32__, etc. (but I agree with Danny
>   ld> that WINDOWS32 is no good for a compiler built-in).
> 
> Wait--please remember that WINDOWS32 is _NOT_ a compiler built-in, nor
> have I ever suggested it should be.
> 
> It's the macro that GNU make uses in its own code when it wants to build
> for a Windows platform.
> 
> It's you-all who are talking about defining new compiler builtin
> macros.  I personally see no real need for it.
> 
>   ld> Since only Mingw (and Cygwin I guess) will define __WINDOWS32__
>   ld> (AFAIK), checking for this macro will really just be checking for
>   ld> Mingw, but if that's what you want to do then __MINGW32__ would be
>   ld> a better option. Then again, you probably need special build
>   ld> processes for MSVC and other Windows compilers anyway, so
>   ld> explicitly defining __WINDOWS32__ for those wouldn't be a problem.
> 
> Maybe I'm misunderstanding what you're trying to accomplish in terms of
> changes to GNU make.
> 
> Right now GNU make has its own macro, WINDOWS32, as I said above.  When
> you compile with MSVC etc. you use a predefined config.h which contains
> hardcoded results for a Windows platform, and defines this macro.
> 
> If the MINGW folks want to allow GNU make to be autoconf-enabled on a
> MINGW system, that's fine with me.  But I don't understand the purpose
> of changing GNU make's personal macro.

        Mmm...don't think anyone is suggesting changing GNU "make", but could 
be way off 
on that.

        My understanding is that we are discussing changing certain internal 
Mingw 
definitions to more fully support an internal macro definition:  __WINDOWS32.

        Paul G.