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



----- Original Message -----
From: "Akim Demaille" <akim@epita.fr>


>
> | > My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE
of
> | > AC_CANONICAL_HOST, and should ensure the case $host itself.
> |
> | Why?
>
> To make it easier to read and write where it is used.

Ok. Lets see what can be done.

> | And by being a little bit more generic less changes will be
> | needed to work with (say) WINE. Or on a cross-compile chain.
>
> We are probably misunderstanding each other.  I don't understand what
> you mean here.

Quite possibly ... I mean that the current test doesn't care what the
platform is. The case and platform check where there for the developer
to use.

> | And the developer writing the configure test will still need to
decide
> | what to do if it fails && they are compiling on cygwin, so they
still
> | need a case statement.
>
> It was not clear to me that ac_cc_win32 was the main point, I
> understood that setting CC was the main point.

There are two things. One is to set CC automatically. The second is to
allow the developer to turn off code that is win32 dependent if win32 is
not present. Or equally fail the configure script if the entire program
is dependent on win32.

The developer could use
AC_PROG_CC_WIN32
AC_CHECK_HEADER([windows.h])

and then (test in the configure script) / (surround the win32 code with
#IF_HAVE_WINDOWS_H), but I thought  giving the developer a clear
mechanism would be nice.

> So if that's the case, then I have further comments to make.  Don't
> use the ac_cc name space at all when interacting with the user.  Use
> some upper case thing such as CC_MWIN32.  I have no idea about it, but
> I guess the C++ compiler will also want something similar?

Ok, point taken. AFAIK the windows.h test is valid for C++ and CC, so a
second macro AC_PROG_CXX_WIN32 that just wraps AC_PROG_CC_WIN32 would be
ok? Then the developer uses AC_CHECK_HEADER([windows.h]) and that solves
it.

Thinking about my desire for a clear cut mechanism, each language will
need a separate test (although CPP and C are the same - others may not
be), so it's probably better to document that AC_PROG_CC_WIN32 sets the
CC variable, if you want to test for the success or fail of the test,
use the AC_CHECK_HEADER([windows.h]).

Does that make sense?

Rob


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