Re: updated win32 macro

2001-03-19 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] writes: Robert Well CFLAGS was the autoconf maintainers suggestion. Yes, my opinion was to have a macro which defines WIN32_FLAGS, and let the user do what they want with it: glue it to CFLAGS, AC_SUBST it etc.

Re: updated win32 macro

2001-03-19 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 19, 2001 10:37 PM Subject: Re: updated win32 macro "Robert" == Robert Collins [EMAIL PROTECTED

Re: updated win32 macro

2001-03-19 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] writes: Robert Wasn't that for the low level interface? Which I've done - it Robert defines WIN32FLAGS... This is fine! Most people will not want to bother, and having it into CFLAGS is fine, there is nothing else to do. And your low level one

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Alexandre Oliva" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 4:51 PM Subject: Re: updated win32 macro On Mar 14, 2001, "Robert Collins

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
| Sample code to use it in configure.in, when the program _needs_ the | win32 API: | | AC_CANONICAL_HOST | | case "${host}" in | *-*-cygwin*) | AC_PROG_CC_WIN32 | if $ac_cc_win32; then | dnl do nothing here - any header checks /library checks etc | later in configure.in

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 8:23 PM Subject: Re: updated win32 macro | Sample code to use it in configure.in, when

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Alexandre Oliva" [EMAIL PROTECTED] On Mar 14, 2001, "Robert Collins" [EMAIL PROTECTED] wrote: I suggest separating `test for features and display results' from `set variables', so that you can enclose the tests within AC_CACHE_CHECK and still

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
| 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. | There is no side effect if it is tested for on platforms other than | cygwin. Nor in my

Re: updated win32 macro

2001-03-15 Thread edward
- Original Message - From: "Robert Collins" [EMAIL PROTECTED] To: "Akim Demaille" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 4:18 AM Subject: Re: updated win32 macro - Original Message - From: "Akim D

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] writes: Robert It looks like the cc result is not used from cache - so I Robert don't think this test should allow caching. Also I have a Robert question on the caching: I need to cache _the change needed to Robert CC_... Is that temporary variable

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] | 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

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "edward" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED]; "Akim Demaille" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 8:33 PM Subject: Re: updated win32 macro - Origina

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
| 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. Then it seems to me that the interface is not

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] "Robert" == Robert Collins [EMAIL PROTECTED] writes: Robert It looks like the cc result is not used from cache - so I Robert don't think this test should allow caching. Also I have a Robert question on the caching: I

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] writes: Then it seems to me that the interface is not right. Maybe something like AC_HEADER_WINDOWS Robert Good suggestion. Then the developer can simply check for Robert HAVE_WINDOWS_H afterwards.. I like :] What about the language Robert

Re: updated win32 macro

2001-03-15 Thread edward
- Original Message - From: "Robert Collins" [EMAIL PROTECTED] To: "edward" [EMAIL PROTECTED]; "Akim Demaille" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 4:47 AM Subject: Re: updated win32 macro - Origina

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: "Alexandre Oliva" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 9:13 PM Subject: Re: updated win32 macro &qu

Re: updated win32 macro

2001-03-15 Thread Robert Collins
just a note: another reason that LDFLAGS etc aren't changed, is that it's not needed: (from the gcc specs file entry *cpp: %{mwin32:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -DWINNT -idirafter /usr/include/w32api} ) Of course it may need to change in the future.. Rob

Re: updated win32 macro

2001-03-15 Thread Robert Collins
I just went and looked at the AC_LANG stuff properly - to support that properly it seems like I need to choose _which_ variables get altered on the basis of the current stack value, or go with language specific functions. Whats better? Is it worth supporting the AC_LANG for this essentially

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
| Yes. Well the namespace pollution is already solved - that was my | ignorance. I think the best bet is the high/low level interface. | | the questions are then: | | one low level interface for each language? (I think yes) Yep, the current one. | one high level interface for each language

Re: updated win32 macro

2001-03-15 Thread Lars J. Aas
On Thu, Mar 15, 2001 at 02:51:08AM -0300, Alexandre Oliva wrote: : On Mar 14, 2001, "Robert Collins" [EMAIL PROTECTED] wrote: : : version 2.. returns true/false now. I've also updated te sample code : to reflect this : : Better use `:' instead of `true'. I'm not sure `:' is more

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] writes: Robert I just went and looked at the AC_LANG stuff properly - to Robert support that properly it seems like I need to choose _which_ Robert variables get altered on the basis of the current stack value, Robert or go with language specific

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: "Alexandre Oliva" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 11:28 PM Subject: Re: updated win32 macro Cor

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] writes: | What does the high level interface do ? (I suggest it sets the Robert variables | named above, setting them to " " as a minimum if WIN32 is found, and | nothing if it is not. What's the point? Just define a user var to the proper

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
"Robert" == Robert Collins [EMAIL PROTECTED] 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

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: "Alexandre Oliva" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 12:05 AM Subject: Re: updated win32 macro &qu

Re: updated win32 macro

2001-03-15 Thread Earnie Boyd
PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: "Alexandre Oliva" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 8:05 AM Subject: Re: updated win32 macro "Robert" == Robert Collins [EMAIL PROTECTED] writes: Then ther

Re: updated win32 macro

2001-03-15 Thread Lars J. Aas
On Thu, Mar 15, 2001 at 01:18:37PM +0100, Lars J. Aas wrote: : I agree, but I'd rather have the implementation/optimization details hidden : in some autoconf-provided variables like $as_true and $as_false - it would : be less obfuscating. Then you could set $as_true to ":" and perhaps $as_false

Re: updated win32 macro

2001-03-15 Thread edward
t;Alexandre Oliva" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 8:05 AM Subject: Re: updated win32 macro "Robert" == Robert Collins [EMAIL PROTECTED] writes: Then there is yet another thing to introduce IMHO, AC_SYS_WIN32 or so, which does

Re: updated win32 macro

2001-03-15 Thread Akim Demaille
"tailbert" == tailbert edward writes: tailbert it's a language feature. OK, but then I fail to understand why you'd need to have WIN32=' ' to know the test was run. Either you are looking for a switch for a language dependent feature, or you look for some support of something on your system,

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "edward" [EMAIL PROTECTED] Cc: "Robert Collins" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 12:41 AM Subject: Re: updated win32 macro "t

Re: updated win32 macro

2001-03-15 Thread Earnie Boyd
Robert Collins wrote: - Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "edward" [EMAIL PROTECTED] Cc: "Robert Collins" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 12:41 AM Subject: Re: upda

Re: updated win32 macro

2001-03-15 Thread Christopher Faylor
On Thu, Mar 15, 2001 at 11:29:34PM +1100, Robert Collins wrote: Neato.. But can we put CFLAGS="$WIN32FLAGS $CFLAGS" or will that break other things? AFAIK (Chris - any comment) the -mwin32 needs to go first.. It breaks builds from the gcc or gdb build trees which override CFLAGS from the top

Re: updated win32 macro

2001-03-15 Thread Christopher Faylor
On Thu, Mar 15, 2001 at 10:27:45PM +1100, Robert Collins wrote: just a note: another reason that LDFLAGS etc aren't changed, is that it's not needed: (from the gcc specs file entry *cpp: %{mwin32:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -DWINNT -idirafter /usr/include/w32api} ) Of course it may

Re: updated win32 macro

2001-03-15 Thread Christopher Faylor
On Fri, Mar 16, 2001 at 12:54:01AM +1100, Robert Collins wrote: I still don't think all of this fuss is really worth it but I'm going to add my 29 cents worth in this thread. AISI, what is needed is only whether or not the the compiler supports a -mwin32 switch. Then the configure.in can

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Christopher Faylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 2:29 AM Subject: Re: updated win32 macro On Thu, Mar 15, 2001 at 11:29:34PM +1100, Robert Collins wrote: Neato.. But can we put CFLAGS=&q

Re: updated win32 macro

2001-03-15 Thread Robert Collins
- Original Message - From: "Christopher Faylor" [EMAIL PROTECTED] On Fri, Mar 16, 2001 at 09:12:57AM +1100, Robert Collins wrote: - Original Message - From: "Christopher Faylor" [EMAIL PROTECTED] On Thu, Mar 15, 2001 at 11:29:34PM +1100, Robert Collins wrote: Neato..

Re: updated win32 macro

2001-03-15 Thread Robert Collins
o: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 11:08 AM Subject: Re: updated win32 macro On Fri, Mar 16, 2001 at 09:56:43AM +1100, Robert Collins wrote: So in a nutshell, because some packages change CFLAGS, and others ch

Re: updated win32 macro

2001-03-15 Thread Christopher Faylor
On Fri, Mar 16, 2001 at 09:56:43AM +1100, Robert Collins wrote: So in a nutshell, because some packages change CFLAGS, and others change CC, we require everyone to change their Makefiles ? I agree that overriding CC is bad - thats why it was changed to CFLAGS. But CFLAGS is the standard way of

Re: updated win32 macro

2001-03-14 Thread Alexandre Oliva
On Mar 14, 2001, "Robert Collins" [EMAIL PROTECTED] wrote: version 2.. returns true/false now. I've also updated te sample code to reflect this Better use `:' instead of `true'. I'm not sure `:' is more portable, but at least it's a built-in in more shells than `true'. I suggest