This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: updated win32 macro


it's a language feature.

it attempts to answer the following question:

how do i get a windows C-based [.c, .cc, .m] file to an object file?

it's just syntactic sugar for -mwin32, which itself is syntactic sugar for
setting some defines, some include paths.

iirc, it doesn't set the *link* parameters though. that's a separate issue
on cygwin systems, which may want to target cygwin or mingw backends.

this is a fine mess we're in =)

cheers,
edward

----- Original Message -----
From: "Akim Demaille" <akim@epita.fr>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: "Alexandre Oliva" <oliva@lsd.ic.unicamp.br>;
<cygwin-apps@sources.redhat.com>; <autoconf@gnu.org>
Sent: Thursday, March 15, 2001 8:05 AM
Subject: Re: updated win32 macro


> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
>
> >> Then there is yet another thing to introduce IMHO, AC_SYS_WIN32 or
> >> so, which does define this symbol to yes/no.  You high level macro
> >> ac_requires it.
>
> Robert> Doesn't that just check the _current_ support ?
>
> Sorry, I don't understand.
>
> Is the feature your trying to test related to the compiler, or to the
> system?  If the language is relevant, then indeed AC_SYS is wrong.  If
> the language is not, then I don't understand your sentence: all that
> matters is whether we are running this system or not, to decide, for
> instance, of the programs to compile.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]