This is the mail archive of the
mailing list for the Cygwin project.
Re: updated win32 macro
----- Original Message -----
From: "Earnie Boyd" <firstname.lastname@example.org>
To: "edward" <email@example.com>
Cc: "Robert Collins" <firstname.lastname@example.org>;
Sent: Friday, March 16, 2001 12:41 AM
Subject: Re: updated win32 macro
> I still don't think all of this fuss is really worth it but I'm going
> add my 29 cents worth in this thread.
> AISI, what is needed is only whether or not the the compiler supports
> -mwin32 switch. Then the configure.in can use it.
Not true if you want to support users with cygwin gcc 2.95.2-6. That's
what I didn't like about the code Chris was putting in his configure.in
and prompted me to put into practice what I'd been thinking about. As
has already been pointed out -mwin32 may not be here to stay. The
concept of a compiler being able to build win32 source files into
objects is though.
> Code for what's needed in a portable fashion and don't worry about the
> what ifs.
You're right Earnie - as long as all your source files /modules/targets
are appropriate on every platform. I've covered this just now in another
mail so I won't repeat myself. configure is the best place to turn such
high level things on or off.
The core test is done and dusted - the volume was really just sorting
the best way of letting the configure script writer use that test.
The stuff about whether to define WIN32 .. hangon - breakthrough.
We're really doing two _completely_ separate things (as Akim has been
pointing at with the AC_SYS_WIN32 thing).
1st thing, active win32 compiler support if possible.
2nd thing, test for the feature (as you just pointed out - a
But I don't agree that it is _only_ code based. It is feature based.
So I retract my request for a WIN32 define. I'll just craft up a
AC_SYS_WIN32 as Akim suggested, but that won't be called by the compiler
support macro. It'll be completely separate.