delorie.com/archives/browse.cgi | search |
----- Original Message ----- From: "Akim Demaille" <akim AT epita DOT fr> To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au> Cc: "Alexandre Oliva" <oliva AT lsd DOT ic DOT unicamp DOT br>; <cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT org> Sent: Friday, March 16, 2001 12:05 AM Subject: Re: updated win32 macro > >>>>> "Robert" == Robert Collins <robert DOT collins AT itdomain DOT com DOT 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. > I assume AC_SYS_WIN32 is a system feature test? I can't see it on the autoconf manual page... We are trying to enable a feature of the system/compiler that may not be enabled by default. The language will likely be relevant (thus the low level tests), and the feature once enabled is language specific. Having a C compiler that has the necessary files for WIN32 compilation and linking does not imply having a C++ compiler that can do the same. All that matters here is whether we can find some way compile WIN32 code (as part of a program) AND tell the user that we have found that way. In one sense it's two separate problems: a) force the compiler to compile & link win32 source if possible. b) allow the user to #define their code to avoid compilation errors on pure unix systems. Rob
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |