Re: updated win32 macro
- 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" [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'. Ok, will do. 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 get the variables properly set even when the result was taken from the cache. I'll readup on AC_CACHE_CHECK and give this a go. Thanks Rob
Re: updated win32 macro
| 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 will now pass
| else
| echo "configure: error: Win32 API needed and no acceptable
| cc could be found" 12;
| exit 1;
| fi;;
| esac
My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE of
AC_CANONICAL_HOST, and should ensure the case $host itself.
Re: updated win32 macro
- 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 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 will now pass
| else
| echo "configure: error: Win32 API needed and no
acceptable
| cc could be found" 12;
| exit 1;
| fi;;
| esac
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? There is no side effect if it is tested for on platforms other than
cygwin. And by being a little bit more generic less changes will be
needed to work with (say) WINE. Or on a cross-compile chain.
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.
Rob
Re: updated win32 macro
- 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 get the variables properly set even when the result was taken from the cache. I'll readup on AC_CACHE_CHECK and give this a go. It looks like the cc result is not used from cache - so I don't think this test should allow caching. Also I have a question on the caching: I need to cache _the change needed to CC_... Is that temporary variable automatically cached? Rob
Re: updated win32 macro
| 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 proposal. I'm just saying the AC_CANONICAL_HOST and case should get into it, nothing more. | 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. | 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. 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?
Re: updated win32 macro
- 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 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 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 will now pass
| else
| echo "configure: error: Win32 API needed and no
acceptable
| cc could be found" 12;
| exit 1;
| fi;;
| esac
My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE of
AC_CANONICAL_HOST, and should ensure the case $host itself.
that's my suggestion as well.
Why? There is no side effect if it is tested for on platforms other than
cygwin. And by being a little bit more generic less changes will be
needed to work with (say) WINE. Or on a cross-compile chain.
you don't lose any generality. what you gain is assurance that you are
testing on a relevant platform.
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.
ps. you might consider extending it to handle optional arguments, a-la
AC_PROG_CC_WIN32(HAVE_WIN32, [echo imma winnie], [echo imma no win])
implementation is left as an exercise to you =)
Rob
Re: updated win32 macro
"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 automatically cached? If you ac_cv_ it, yes. But never display a cache variable to the user. You macro, indeed, is fragile to the changes of LANG. I'm not sure AC_PROG_CC_WIN32 AC_LANG(C++) AC_LANG(C) echo $ac_compile will display what you hope it would. And actually, now that coffee suddenly breaks my mind free, I just understood you meant to do here: ac_cc_win32=yes ac_compile="$ac_compile -mwin32" ac_link="$ac_link -mwin32" CC="$CC -mwin32" this is `wrong'. ac_compile and friends are not evaluated at their definition, but at their uses. So you need not (and must not) change them at all. Changing CC is a bad idea. And BTW, my suggestion behind the C++ stuff was that, IMHO, you should not set CC, or maybe at least provide the user with a means to get the switch, say the variable $WIN32CFLAGS. AC_LANG_COMPILER_MWIN32([YES-WIN32], [NOT-WIN32]) I would be able to write AC_LANG_COMPILER_MWIN32([CC="$CC $WIN32CFLAGS]) CXX="$CXX $WIN32CFLAGS"
Re: updated win32 macro
- 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 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
Re: updated win32 macro
- 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 - 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 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 My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE of AC_CANONICAL_HOST, and should ensure the case $host itself. that's my suggestion as well. Why? There is no side effect if it is tested for on platforms other than cygwin. And by being a little bit more generic less changes will be needed to work with (say) WINE. Or on a cross-compile chain. you don't lose any generality. what you gain is assurance that you are testing on a relevant platform. No we don't - that was my point - by wrapping it in a case statement, if someone ports Win32 to linux, and addes -mwin32 to gcc on linux, it won't work. See my just mailed reply to Akim for a much better test method (once my brain was fed Coca Cola :] ). 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. ps. you might consider extending it to handle optional arguments, a-la AC_PROG_CC_WIN32(HAVE_WIN32, [echo imma winnie], [echo imma no win]) implementation is left as an exercise to you =) I thought about that, and I figure that the answer is: If you don't want Win32, don't call the macro. Dead easy. Rob
Re: updated win32 macro
| 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 right. Maybe something like AC_HEADER_WINDOWS which would do the whole thing might be what you need. Also, why do you set CC and not CFLAGS (and maybe LDFLAGS)? This is a tricky question, I often wondered, not only in the present case.
Re: updated win32 macro
- 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 need to cache _the change needed to Robert CC_... Is that temporary variable automatically cached? If you ac_cv_ it, yes. But never display a cache variable to the user. Understood (now). You macro, indeed, is fragile to the changes of LANG. I'm not sure AC_PROG_CC_WIN32 AC_LANG(C++) AC_LANG(C) echo $ac_compile will display what you hope it would. And actually, now that coffee suddenly breaks my mind free, I just understood you meant to do here: ac_cc_win32=yes ac_compile="$ac_compile -mwin32" ac_link="$ac_link -mwin32" CC="$CC -mwin32" this is `wrong'. ac_compile and friends are not evaluated at their definition, but at their uses. So you need not (and must not) change them at all. Changing CC is a bad idea. And BTW, my suggestion behind the C++ stuff was that, IMHO, you should not set CC, or maybe at least provide the user with a means to get the switch, say the variable $WIN32CFLAGS. Ah, Well I answered a different question then :] AC_LANG_COMPILER_MWIN32([YES-WIN32], [NOT-WIN32]) I would be able to write AC_LANG_COMPILER_MWIN32([CC="$CC $WIN32CFLAGS]) CXX="$CXX $WIN32CFLAGS" Ok problem here: that might not be valid for CXX. AFAIK it happens to be on cygwin, but I can't vouch for other scenarios (WINE comes to mind again). For that reason I suggest a separate test for each language. I've copied from your next email to prevent us having 20 concurrent threads.. Then it seems to me that the interface is not right. Maybe something like AC_HEADER_WINDOWS Good suggestion. Then the developer can simply check for HAVE_WINDOWS_H afterwards.. I like :] What about the language specific issues? Or should AC_HEADER_WINDOWS look for _every_ compiler that it knows how to set WIN32 on? which would do the whole thing might be what you need. Also, why do you set CC and not CFLAGS (and maybe LDFLAGS)? This is a tricky question, I often wondered, not only in the present case. Because I misunderstood the ac_* variable vs the CAPITALISED ONES. Does this mean I get to set CC again? Rob
Re: updated win32 macro
"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 specific issues? Or should AC_HEADER_WINDOWS look for _every_ Robert compiler that it knows how to set WIN32 on? Nope, I'd say the current compiler, adn you should provide a variable that contains the needed switch. Then it is up to the user to give it to her CXX if it is G++ etc. Or maybe give two interfaces, one being low level computing this switch for the current compiler (and *no caching*), so that the low level user can test all her compilers, and a high level one: that above. which would do the whole thing might be what you need. Also, why do you set CC and not CFLAGS (and maybe LDFLAGS)? This is a tricky question, I often wondered, not only in the present case. Robert Because I misunderstood the ac_* variable vs the CAPITALISED Robert ONES. Does this mean I get to set CC again? There are two things. One is that the interface with the user is typically in capitals, but that is not really required. It makes sense in the present case to capitalize it (the difference is more or less, lower case variables are shell variables only, and upper case denotes values which might escape configure, eg, be AC_SUBST'd in a Makefile etc.). The second thing is that in any case ac_/AC_ etc. variables are private to Autoconf, no user should ever have to use them.
Re: updated win32 macro
- 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 - 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 - 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 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 My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE of AC_CANONICAL_HOST, and should ensure the case $host itself. that's my suggestion as well. Why? There is no side effect if it is tested for on platforms other than cygwin. And by being a little bit more generic less changes will be needed to work with (say) WINE. Or on a cross-compile chain. not sure how useful that is... let's say i already have a header called windows.h. all of a sudden, now i'm supposed to be targeting a mswin-type platform? better to test against a feature (like winbool) rather than the existence of a header. (because you set ac_cc_win32 to true if cpp w/o -mwin32 against windows.h works first). you don't lose any generality. what you gain is assurance that you are testing on a relevant platform. No we don't - that was my point - by wrapping it in a case statement, if someone ports Win32 to linux, and addes -mwin32 to gcc on linux, it won't work. See my just mailed reply to Akim for a much better test method (once my brain was fed Coca Cola :] ). my view of autoconf macros is to make life easier for me (the user of the macro). let's say gcc is extended to emit the proper modifications needed to compile with windows on a non-windows platform. now i have to re-write every configure.in to add that feature. i would rather rewrite the macro, then re-aclocal-etc. akim's suggestion of a low-level and a high-level macro would probably handle that. 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. ps. you might consider extending it to handle optional arguments, a-la AC_PROG_CC_WIN32(HAVE_WIN32, [echo imma winnie], [echo imma no win]) implementation is left as an exercise to you =) I thought about that, and I figure that the answer is: If you don't want Win32, don't call the macro. Dead easy. i don't really mean whther or not to call the macro. rather what to do once you've called it. as in your sample usage post, you are almost always going to test the return and do something with it. doing the above will let you move from case $host_os in *cygwin*) # start AC_PROG_CC_WIN32 if $ac_cc_win32; then : true stuff here else : false stuff here fi # end ;; esac case $host_os in *cygwin*) AC_PROG_CC_WIN32([ : true stuff here ], [ : false stuff here ]) ;; esac at the very least, you remove the pollution of the namespace required via the ac_cc_win32. the user can always AC_PROG_CC_WIN32(my_ccflags="$withval") etc. Rob cheers, edward
Re: updated win32 macro
- 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 "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 specific issues? Or should AC_HEADER_WINDOWS look for _every_ Robert compiler that it knows how to set WIN32 on? Nope, I'd say the current compiler, adn you should provide a variable that contains the needed switch. Then it is up to the user to give it to her CXX if it is G++ etc. Sorry I used incorrect terminology - I meant "check for every language". What if the switch is different between C and C++? so AC_WIN32_CFLAGS sets WIN32_CFLAGS and AC_WIN32_CXXFLAGS sets WIN32_CXXFLAGS and AC_WIN32_F70FLAGS sets WIN32_F70FLAGS ? The other goal I had was to minimise the need for changes to makefiles and the like. Of course the user can do CXX="$CXX $WIN32_CXXFLAGS" in the configure script as you pointed out before. So that's no longer an issue. Or maybe give two interfaces, one being low level computing this switch for the current compiler (and *no caching*), so that the low level user can test all her compilers, and a high level one: that above. ie, AC_HEADER_WINDOWS - calculate the switchs for all known languages (just calls AC_WIN32_CFLAGS CXX etc) and the individual AC_WIN32_CFLAGS are the low level tests? This would also work quite compactly. actually, why not AC_ which would do the whole thing might be what you need. Also, why do you set CC and not CFLAGS (and maybe LDFLAGS)? This is a tricky question, I often wondered, not only in the present case. Robert Because I misunderstood the ac_* variable vs the CAPITALISED Robert ONES. Does this mean I get to set CC again? There are two things. One is that the interface with the user is typically in capitals, but that is not really required. It makes sense in the present case to capitalize it (the difference is more or less, lower case variables are shell variables only, and upper case denotes values which might escape configure, eg, be AC_SUBST'd in a Makefile etc.). The second thing is that in any case ac_/AC_ etc. variables are private to Autoconf, no user should ever have to use them. === replying to edward now Why? There is no side effect if it is tested for on platforms other than cygwin. And by being a little bit more generic less changes will be needed to work with (say) WINE. Or on a cross-compile chain. not sure how useful that is... let's say i already have a header called windows.h. all of a sudden, now i'm supposed to be targeting a mswin-type platform? better to test against a feature (like winbool) rather than the existence of a header. (because you set ac_cc_win32 to true if cpp w/o -mwin32 against windows.h works first). No. What's wrong here is my assumption that windows.h was a valid test. I'll do a feature based test. I think we've covered the use/non usefulness elsewhere - we've eliminated the case statement. The point that the test is bad is very usefull though. my view of autoconf macros is to make life easier for me (the user of the macro). let's say gcc is extended to emit the proper modifications needed to compile with windows on a non-windows platform. now i have to re-write every configure.in to add that feature. i would rather rewrite the macro, then re-aclocal-etc. akim's suggestion of a low-level and a high-level macro would probably handle that. that's also been covered by implication: removing the case statement completely. I agree with you - rewriting the Macro was exactly the goal I had in mind rather than rewriting the tests in configure.in. So the case statement was Roberts short sightedness. i don't really mean whther or not to call the macro. rather what to do once you've called it. as in your sample usage post, you are almost always going to test the return and do something with it. doing the above will let you move from snip 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) one high level interface for each language (I think no) What does the high level interface do ? (I suggest it sets the variables named above, setting them to " " as a minimum if WIN32 is found, and nothing if it is not. Or should we have a second variable for each language indicating the win32 status? ) I also think the high level interface should take no parameters, to be as easy to use as possible. What does the low level interface do? For each language it
Re: updated win32 macro
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
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 non-unix feature? I'm happy to put the time in if it is.. Rob
Re: updated win32 macro
| 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 (I think no) Correct. Anyway Autoconf is dead broken when it comes to try to isolate features of these or those libraries/headers used by this or that compiler: there is a single namespace for HAVE_FOO_H etc. | What does the high level interface do ? (I suggest it sets the 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 flags if needed, and set the current compiler to use it. | What does the low level interface do? For each language it finds a win32 | set of switchs and puts them in the appropriate variable. It could have | a [if true, if false] layout if needed, but I don't really see the need. If there is no need, just don't. Low level macro just compute some $WIN32FLAGS for the current language.
Re: updated win32 macro
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 portable, : but at least it's a built-in in more shells than `true'. 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 to "(exit 1)" if "false" for some reason does not work on a system. Lars J
Re: updated win32 macro
"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 functions. Robert Whats better? Is it worth supporting the AC_LANG for this Robert essentially non-unix feature? I'm happy to put the time in if Robert it is.. You are not concerned by the current language at all in the low level macro, and the high level macro should set the compiler or flags var associated to the current language. There is no direct support for this, you have to AC_LANG_CASE([C], [CFLAGS="$CFLAGS $WIN32FLAGS], [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)])
Re: updated win32 macro
- 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 Correct. Anyway Autoconf is dead broken when it comes to try to isolate features of these or those libraries/headers used by this or that compiler: there is a single namespace for HAVE_FOO_H etc. Ah. | What does the high level interface do ? (I suggest it sets the 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 flags if needed, and set the current compiler to use it. To enable the user to test for the win32 API in configure.in. (A few emails back now - the second half of the issue). I know a lot of users will just be compiling a win32 only program and don't care, but I work openBSD to windows _all the time_... On second thought, lets just set WIN32="yes" if we found it. That's fairly intuitive. You are not concerned by the current language at all in the low level macro, and the high level macro should set the compiler or flags var associated to the current language. There is no direct support for this, you have to AC_LANG_CASE([C], [CFLAGS="$CFLAGS $WIN32FLAGS], [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) Neato.. But can we put CFLAGS="$WIN32FLAGS $CFLAGS" or will that break other things? AFAIK (Chris - any comment) the -mwin32 needs to go first.. I'm going to pull all of this together now, with a better test case. Rob
Re: updated win32 macro
"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 flags if needed, and set the current compiler to use it. Robert To enable the user to test for the win32 API in Robert configure.in. Robert (A few emails back now - the second half of the issue). I know Robert a lot of users will just be compiling a win32 only program and Robert don't care, but I work openBSD to windows _all the time_... On Robert second thought, lets just set WIN32="yes" if we found Robert it. That's fairly intuitive. 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.
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 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.
Re: updated win32 macro
- 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 "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 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
win32 macro version 3
This has a better test that windows.h; a high level interface and two low level interfaces. I had _no_ idea what the high level interface should be called, so I called it AC_API_WIN32 - please suggest a better name. The low level interface sets WIN32FLAGS to the needed flags for that language (but doesn't check the current language is infact C or C++). It defines WIN32 so that the user _can test if they want to_ in configure.in in order to skip other tests or turn on compilation of win32 specific programs. basic use: AC_API_WIN32 can't get easier really. advanced use AC_API_WIN32 if test -z "$WIN32" ; then dnl we are able to build win32 code. Compile the win32 only bonus programs dnl within all source files any win32 code is #ifdef WIN32 EXTRA_PROGRAMS="$EXTRA_PROGRAMS servicemon serviceinstall" fi Rob acinclude.m4
Re: updated win32 macro
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 use it. Code for what's needed in a portable fashion and don't worry about the what ifs. Earnie. edward wrote: 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" [EMAIL 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 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. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: updated win32 macro
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 : to "(exit 1)" if "false" for some reason does not work on a system. Just "(exit 1)" didn't work, but this does: as_true=":" as_false="eval (exit 1)" Don't know what's more optimal of that and fork + exec /bin/false. Could probably go the way of fork + eval... Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy'
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" [EMAIL 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 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.
Re: updated win32 macro
"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, in which case AC_HEADER_WINDOWS was fine, IMHO. But Robert says he needs more: be able to make decisions based on whether windows.h is there or not, and he was suggesting to provide $WIN32 as a configure interface to HAVE_WINDOWS_H. Then, it is a host feature you are looking for, and AC_SYS is the logical answer.
Re: updated win32 macro
- 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 "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, in which case AC_HEADER_WINDOWS was fine, IMHO. But Robert says he needs more: be able to make decisions based on whether windows.h is there or not, and he was suggesting to provide $WIN32 as a configure interface to HAVE_WINDOWS_H. Then, it is a host feature you are looking for, and AC_SYS is the logical answer. Not quite. I chose windows.h INCORRECTLY. I was trying to test whether the win32 api was _really working_ without running the code (so that cross compiling would still work). The #define WIN32 is a much better test (Edward and I took that part off-line). It is a language feature as Edward described. The test is not for language features, but to allow (for example) certain targets to be only built if that language feature exists. An example (as I've used in the email that crossed this one) is if a given package has some targets that build on unix and on windows, and some targets that only build on windows _with that language_. If AC_SYS_WIN32 is a new macro you are suggesting, that will test whether the target system will run WIN32 code, that's probably a useful macro to have. But it's what the language is able to build that interests me. Here's the real-world example I am wrestling with. I've just written an async file system module for squid that uses WIN32 threads, not pthreads. So if the compiler can't build code that uses WIN32 threads I need to turn off compilation of that module if the end user requested it. Conversely I want to make that module built by default if the compiler can build code that uses WIN32 threads (to offer the end user best performance). The test therefore is very useful, and tied to the language. Rob
Re: updated win32 macro
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: updated win32 macro "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, in which case AC_HEADER_WINDOWS was fine, IMHO. But Robert says he needs more: be able to make decisions based on whether windows.h is there or not, and he was suggesting to provide $WIN32 as a configure interface to HAVE_WINDOWS_H. Then, it is a host feature you are looking for, and AC_SYS is the logical answer. Not quite. I chose windows.h INCORRECTLY. I was trying to test whether the win32 api was _really working_ without running the code (so that cross compiling would still work). The #define WIN32 is a much better test (Edward and I took that part off-line). It is a language feature as Edward described. The test is not for language features, but to allow (for example) certain targets to be only built if that language feature exists. An example (as I've used in the email that crossed this one) is if a given package has some targets that build on unix and on windows, and some targets that only build on windows _with that language_. If AC_SYS_WIN32 is a new macro you are suggesting, that will test whether the target system will run WIN32 code, that's probably a useful macro to have. But it's what the language is able to build that interests me. Here's the real-world example I am wrestling with. I've just written an async file system module for squid that uses WIN32 threads, not pthreads. So if the compiler can't build code that uses WIN32 threads I need to turn off compilation of that module if the end user requested it. Conversely I want to make that module built by default if the compiler can build code that uses WIN32 threads (to offer the end user best performance). The test therefore is very useful, and tied to the language. This is a different issue than simply the compiler supporting a -mwin32 switch. This issue is code based and should be based on a HAVE_WIN32_THREADS switch. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: win32 compiler test V3a
| Hopefully this is it (barring a rename on the high level interface.
| I missed the CPPFLAGS in the last version..
| If you're code is portable this is effective with a simple
| AC_API_WIN32
You should really read the CVS Autoconf documentation. Your quotation
is dangerous at some points, and there are a few suggestions in there
on how to unobfuscate M4 code.
| dnl COMPILER WIN32 support
| AC_DEFUN(AC_PROG_CC_WIN32, [
| dnl figure out how to run CC with access to the win32 api if present
| dnl configure that as the CC program,
| dnl WIN32 may be present with WINE, under cygwin, or under mingw,
| dnl or cross compilers targeting those same three targets.
| dnl as it happens, I can only test cygwin, so extra input here will be appreciated
| dnl send bug reports to Robert Collins [EMAIL PROTECTED]
|
| dnl logic: is CC already configured? if not, call AC_PROG_CC.
| dnl if so - try it. If that doesn't work ,try -mwin32. If that doesn't work, fail
| dnl
| dnl 2001-03-15 - Changed from yes/no to true/false -suggested by Lars J
|Aas[EMAIL PROTECTED]
| dnl * Change true to : - suggest by Alexandre Oliva [EMAIL PROTECTED]
| dnl * changed layout on the basis of autoconf mailing list:
| dnl there are now two interfaces, a language specific one which sets
| dnl or clears WIN32 WIN32FLAGS as appropriate
| dnl
Move the comments out of the macro, use `#', not dnl, quote the name
being defined.
| AC_REQUIRE([AC_PROG_CC])
dnl at the end
| echo $ECHO_N "checking how to access the Win32 API..." 6
This is wrong, use the AC_FD_* if you need to, otherwise you certainly
mean AC_MSG_*
| WIN32FLAGS=
| AC_TRY_COMPILE(,[#ifndef WIN32
| #ifndef _WIN32
| #error WIN32 or _WIN32 not defined
| #endif
| #endif],
#error is suspected to cause problems, although I don't recall having
seen it happen. Please indent cpp directives.
| [
| dnl found windows.h with the current config.
| echo "${ECHO_T}Win32 API found by default" 6
| ], [
You must not use ECHO_N, you are breaking the abstraction layers :)
| dnl try -mwin32
| save_cc="$ac_compile"
You break out of the Autoconf name space: use ac_compile_save for
readability.
| dnl we change CC so config.log looks correct
| save_CC="$CC"
| ac_compile="$ac_compile -mwin32"
| CC="$CC -mwin32"
| AC_TRY_COMPILE(,[#ifndef WIN32
| #ifndef _WIN32
| #error WIN32 or _WIN32 not defined
| #endif
| #endif], [
| dnl found windows.h using -mwin32
| echo "${ECHO_T}Win32 API found via -mwin32" 6
| ac_compile="$save_cc"
| CC="$save_CC"
| WIN32FLAGS="-mwin32"
| ], [
| ac_compile="$save_cc"
| CC="$save_CC"
| echo "${ECHO_T}Win32 API Not found" 6
| ])
| ])
|
| AC_PROVIDE([$0])
Huh? Don't, AC_DEFUN did for you.
| AC_DEFUN(AC_PROG_CXX_WIN32, [
Same comments.
| AC_DEFUN(AC_API_WIN32, [
| dnl high level interface for finding out compiler support for win32.
|
| AC_LANG_CASE([C], AC_PROG_CC_WIN32 [CFLAGS="$WIN32FLAGS $CFLAGS"
| CPPFLAGS="$WIN32FLAGS $CPPFLAGS"],
| [C++], AC_PROG_CXX_WIN32 [CXXFLAGS="$WIN32FLAGS $CXXFLAGS"
| CPPFLAGS="$WIN32FLAGS $CPPFLAGS"],
| [echo "No macro support for WIN32 with $_AC_LANG"
| exit 1])
| ])
Use AC_FATAL. Quote the exec parts. And in fact, just factor
AC_PROG_CXX_WIN32 as an AC_REQUIRE of this macros.
installation instructions on OpenBSD and FreeBSD
Marc Espie, maintainer of gcc for OpenBSD, wrote: The gcc that is the system compiler on OpenBSD is never going to look under /usr/local. The same problem affects also FreeBSD and NetBSD. Therefore I propose the following changes to the INSTALL file. Apart from *BSD, it also treats the HP-UX and BeOS platforms. They are each special in their own sense. I'm going to use this patch in the next gettext release. Bruno *** INSTALL.origSun May 25 18:17:24 1997 --- INSTALL Sun Mar 11 16:49:42 2001 *** *** 119,124 --- 119,147 you can use the `configure' options `--x-includes=DIR' and `--x-libraries=DIR' to specify their locations. + Particular Systems + == + +On FreeBSD, NetBSD, and OpenBSD, the compiler doesn't search include + files in /usr/local/include, and the linker doesn't search libraries in + /usr/local/lib. Therefore some packages won't find other packages + installed earlier. To overcome this problem, it is recommended to use + the following options: + + env CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure + +On HP-UX, the default C compiler is not ANSI C compatible. If GNU CC + is not installed, it is recommended to use the following options in order + to use an ANSI C compiler: + + env CC="cc -Ae" ./configure + +On BeOS, user installed software goes in /boot/home/config, not + /usr/local. It is recommended to use the following options: + + CPPFLAGS=-I/boot/home/config/include LDFLAGS=-L/boot/home/config/lib \ + ./configure --prefix=/boot/home/config + Specifying the System Type ==
Re: updated win32 macro
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 level. In my current tree, I've had to add additional stuff to the Makefile to get things to work. I think that setting CC=stuff will suffer from the same problem. So, I think we will have to make changes to both configure.in and Makefile.in, unfortunately. cgf
Re: updated win32 macro
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 need to change in the future..
That's right. At some point, I would like to make -mwin32 work
similarly for the linker.
cgf
Re: win32 compiler test V3a
| | AC_REQUIRE([AC_PROG_CC]) | | dnl at the end | | what do you mean by this? AC_REQUIRE([AC_PROG_CC])dnl | The curse of reading other peoples code : I got this from a | /usr/share/aclocal/ routine Send fixes to the authors :) | I'm not quite sure whether you meant indent all of them a certain | amount, or use heirarchical indenting on them.. See the documentation. #if # if ... # else ... # fi #else #fi | I had a problem with _AC_LANG not being found by autoconf with your | suggested code. In fact I'm not sure that $_AC_LANG will be found | either. What code, how did you write it? /tmp % cat configure.ac nostromo Err 1 AC_DEFUN([Rob], [AC_LANG([$1]) AC_LANG_CASE([C], [# Nada], [C++], [# Niente], [AC_FATAL([no support for: ]_AC_LANG)])]) AC_INIT Rob([C]) Rob([C++]) Rob([Fortran 77]) /tmp % ace nostromo 16:15 autoconf: warning: both `configure.ac' and `configure.in' are present. autoconf: warning: proceeding with `configure.ac'. configure.ac:10: error: no support for: Fortran 77 configure.ac:5: Rob is expanded from... configure.ac:5: Rob is expanded from... configure.ac:5: Rob is expanded from... configure.ac:10: the top level
Re: win32 compiler test V3a
On Fri, 16 Mar 2001, Robert Collins wrote: The curse of reading other peoples code : I got this from a /usr/share/aclocal/ routine | WIN32FLAGS= | AC_TRY_COMPILE(,[#ifndef WIN32 | #ifndef _WIN32 | #error WIN32 or _WIN32 not defined | #endif | #endif], #error is suspected to cause problems, although I don't recall having seen it happen. Please indent cpp directives. I'm not quite sure whether you meant indent all of them a certain amount, or use heirarchical indenting on them.. preferably neither (autoconf claims to be portable). -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: win32 compiler test V3a
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 2:16 AM Subject: Re: win32 compiler test V3a | | AC_REQUIRE([AC_PROG_CC]) | | dnl at the end | | what do you mean by this? AC_REQUIRE([AC_PROG_CC])dnl | The curse of reading other peoples code : I got this from a | /usr/share/aclocal/ routine Send fixes to the authors :) | I'm not quite sure whether you meant indent all of them a certain | amount, or use heirarchical indenting on them.. See the documentation. #if # if ... # else ... # fi #else #fi | I had a problem with _AC_LANG not being found by autoconf with your | suggested code. In fact I'm not sure that $_AC_LANG will be found | either. What code, how did you write it? /tmp % cat configure.ac nostromo Err 1 AC_DEFUN([Rob], [AC_LANG([$1]) AC_LANG_CASE([C], [# Nada], [C++], [# Niente], [AC_FATAL([no support for: ]_AC_LANG)])]) AC_INIT Rob([C]) Rob([C++]) Rob([Fortran 77]) /tmp % ace nostromo 16:15 autoconf: warning: both `configure.ac' and `configure.in' are present. autoconf: warning: proceeding with `configure.ac'. configure.ac:10: error: no support for: Fortran 77 configure.ac:5: Rob is expanded from... configure.ac:5: Rob is expanded from... configure.ac:5: Rob is expanded from... configure.ac:10: the top level AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) -- I'll try this tomorrow.. thanks for the great help - I'm off to get some sleep. Rob
Re: win32 compiler test V3a
AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) What problem do you have? It works fine for me. /tmp % cat configure.ac nostromo Err 1 AC_INIT AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) /tmp % ace nostromo 16:35 autoconf: warning: both `configure.ac' and `configure.in' are present. autoconf: warning: proceeding with `configure.ac'. configure.ac:6: error: NIah? Never heard of C configure.ac:6: the top level
Re: updated win32 macro
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 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. I'm not sure what you're referring to but anything I posted would accomodate older or newer compilers. I am very happy to see an autoconf option for this, though. That's what I was hoping for. cgf
Re: installation instructions on OpenBSD and FreeBSD
Marc Espie writes: which would tend to indicate to me that even knowledgeable people don't find this obvious... Yup. Also, on HP-UX my first attempt was "cc", my second was "cc -Aa", my third was "cc -Aa -D_HPUX_SOURCE", and only with some help by Jim or Paul I knew that "cc -Ae" is the right thing. It's not obvious. Bruno
Re: installation instructions on OpenBSD and FreeBSD
"Bruno" == Bruno Haible [EMAIL PROTECTED] writes: Bruno Marc Espie writes: which would tend to indicate to me that even knowledgeable people don't find this obvious... Bruno Yup. Also, on HP-UX my first attempt was "cc", my second was Bruno "cc -Aa", my third was "cc -Aa -D_HPUX_SOURCE", and only with Bruno some help by Jim or Paul I knew that "cc -Ae" is the right Bruno thing. It's not obvious. That's why it is configure which must find it.
Re: installation instructions on OpenBSD and FreeBSD
Akim Demaille writes: a system specific section seems not too good an idea to me. I thought the same, until the bug reports I got from users of these systems showed me that 1. the default settings are not right on these systems, 2. the right settings are not obvious even to the users of these systems. Bruno
Re: installation instructions on OpenBSD and FreeBSD
On Thu, Mar 15, 2001 at 07:13:24PM +0100, Akim Demaille wrote: "Bruno" == Bruno Haible [EMAIL PROTECTED] writes: Bruno Marc Espie writes: which would tend to indicate to me that even knowledgeable people don't find this obvious... Bruno Yup. Also, on HP-UX my first attempt was "cc", my second was Bruno "cc -Aa", my third was "cc -Aa -D_HPUX_SOURCE", and only with Bruno some help by Jim or Paul I knew that "cc -Ae" is the right Bruno thing. It's not obvious. That's why it is configure which must find it. I don't have any objection to guessing at -I/usr/local/include and -L/usr/local/lib on BSDs...
Re: installation instructions on OpenBSD and FreeBSD
Bruno Haible writes: Marc Espie writes: which would tend to indicate to me that even knowledgeable people don't find this obvious... Yup. Also, on HP-UX my first attempt was "cc", my second was "cc -Aa", my third was "cc -Aa -D_HPUX_SOURCE", and only with some help by Jim or Paul I knew that "cc -Ae" is the right thing. It's not obvious. There's a macro for that. System specifics have no place in the generic INSTALL file IMHO.
Re: installation instructions on OpenBSD and FreeBSD
"Marc" == Marc Espie [EMAIL PROTECTED] writes: Bruno Also, on HP-UX my first attempt was "cc", my second was "cc Bruno -Aa", my third was "cc -Aa -D_HPUX_SOURCE", and only with some Bruno help by Jim or Paul I knew that "cc -Ae" is the right Bruno thing. It's not obvious. That's why it is configure which must find it. Marc I don't have any objection to guessing at -I/usr/local/include Marc and -L/usr/local/lib on BSDs... :P Just for my information, why is it so?
Re: installation instructions on OpenBSD and FreeBSD
| Akim Demaille writes: | a system specific section seems not too good an idea to me. | | I thought the same, until the bug reports I got from users of these | systems showed me that | 1. the default settings are not right on these systems, | 2. the right settings are not obvious even to the users of these systems. That you use an ad-hoc INSTALL seems OK and good to me: you help your users. But *our* job is to have Autoconf have it right, not to hide our failures in documents the installer will have to read.
Re: installation instructions on OpenBSD and FreeBSD
I wrote: Marc I don't have any objection to guessing at -I/usr/local/include Marc and -L/usr/local/lib on BSDs... Actually, I have one reservation. This MUST be overridable by the person running configure. In the first place, we do want to be able to build the system without getting influenced by what is in /usr/local... if configure gets smarter and starts outguessing us, then we're back where we started, and we can't build clean systems in a reproducable way (because configure will find out a tk that's in /usr/local, say, and start building gdb with tk support, which is mostly fine, except that the base system doesn't ship with tk, or some such thing). So, we definitely must have a switch to turn so that configure won't second-guess the system installation. A simple --system-paths-only or something similar would be enough. Nothing cuter. Cute gadgets work 99% of the time, and take hours to debug the remaining percent. This is very important. Having automatic guessing and not having such a switch would mean all BSDs would have to patch configure before importing stuff into their respective trees, and all three systems developpers would get angry at me for making such a half-baked suggestion in the first place... :)
Re: installation instructions on OpenBSD and FreeBSD
On Thu, Mar 15, 2001 at 03:38:34PM +0100, Bruno Haible wrote: Marc Espie, maintainer of gcc for OpenBSD, wrote: The gcc that is the system compiler on OpenBSD is never going to look under /usr/local. The same problem affects also FreeBSD and NetBSD. This isn't specific to BSDs at all. It'll be an issue on any system where the package is being built with the system compiler. (That this will only be the case when the system compiler is GCC is an unwarranted assumption.) If the warning is included, it should be more generic, perhaps something like: On some systems, the compiler doesn't search for include files in /usr/local/include, and the linker doesn't search for libraries in /usr/local/lib. Therefore this package won't find any packages that have been installed in /usr/local. To overcome this problem, the following options are recommended: CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure (I've also tweaked the wording a bit.) Therefore I propose the following changes to the INSTALL file. I don't really have an opinion on whether system-specific hints belong in INSTALL; I can see the arguments both ways. But they do belong *someplace*! The obvious place would be a FAQ, or a "Hints" page on the autoconf site; if the latter existed, INSTALL would only need to provide the URL. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source)
Re: Depending on system install scripts (was Re: [BUGS] COBOL) (fwd)
Akim Demaille writes: Peter Hi, this came up in our project. Why, if a package is required Peter to ship install-sh anyway, do we look for a system install Peter program when this might just cause weird problems? The point being we are *falling* back to our version of the tools, but we always try to use what's available on the system. This is why we don't impose GNU fnmatch.c, regex.c, strftime.c etc. It's almost ideological, we are here to cure diseases, and sane bodies must not pay our portability tricks. The problem with AC_PROG_INSTALL is that it doesn't actually test whether the found program works. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: win32 compiler test V3a
- Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 2:35 AM Subject: Re: win32 compiler test V3a AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) What problem do you have? It works fine for me. /tmp % cat configure.ac nostromo Err 1 AC_INIT AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) /tmp % ace nostromo 16:35 autoconf: warning: both `configure.ac' and `configure.in' are present. autoconf: warning: proceeding with `configure.ac'. configure.ac:6: error: NIah? Never heard of C configure.ac:6: the top level It must have been a side effect of one of the other syntax errors. I just retired and it works now. Rob
Re: updated win32 macro
- 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="$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 level. In my current tree, I've had to add additional stuff to the Makefile to get things to work. I think that setting CC=stuff will suffer from the same problem. So, I think we will have to make changes to both configure.in and Makefile.in, unfortunately. cgf I think that Earnie was having success building unaltered packages with CC=gcc -mwin32 ./configure ... I would really like to minimse the alterations needed outside of configure.in - can you think of any package in particular likely to have trouble with CC=gcc -mwin32 ? (So that we could test it) Rob
Re: updated win32 macro
- 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.. 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 level. In my current tree, I've had to add additional stuff to the Makefile to get things to work. I think that setting CC=stuff will suffer from the same problem. So, I think we will have to make changes to both configure.in and Makefile.in, unfortunately. I think that Earnie was having success building unaltered packages with CC=gcc -mwin32 ./configure ... I would really like to minimse the alterations needed outside of configure.in - can you think of any package in particular likely to have trouble with CC=gcc -mwin32 ? (So that we could test it) Yes. If you configure this way in the tcl directory and then cd .., the tcl directory won't build because CC is overridden by the toplevel make. If you use CC='gcc -mwin32' configure in the top-level, then we might as well just get rid of -mwin32 completely. This will cause every single package to be built with -mwin32 whether it needs it or not. IMO, I don't think it is a good idea to override CC anyway. It may be a quick fix but it will lead to confusion if/when people say 'make CC=something'. cgf 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 changing the compiler behaviour - why do the makefiles over ride that? And how common a practice is that? In fact, on second thought, packages that override CFLAGS just use the low level interface AC_PROG_CC_WIN32 EXTRA_CFLAGS="$WIN32FLAGS" Rob
Re: win32 compiler test V3a
Robert Collins wrote: - Original Message - From: "Akim Demaille" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 2:35 AM Subject: Re: win32 compiler test V3a AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) What problem do you have? It works fine for me. /tmp % cat configure.ac nostromo Err 1 AC_INIT AC_LANG_CASE( dnl[C], AC_PROG_CC_WIN32 [CFLAGS="$CFLAGS $WIN32FLAGS], dnl [C++],[CXXFLAGS="$CXXFLAGS $WIN32FLAGS], dnl [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS], [AC_FATAL([NIah? Never heard of] _AC_LANG)]) /tmp % ace nostromo 16:35 autoconf: warning: both `configure.ac' and `configure.in' are present. autoconf: warning: proceeding with `configure.ac'. configure.ac:6: error: NIah? Never heard of C configure.ac:6: the top level It must have been a side effect of one of the other syntax errors. I just retired and it works now. Well hopefully retiring isn't what made it work. I want to be lazy when I retire. ;^) LOL, Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
win32 v4
This should be ok now. With 2 exceptions: the AC_REQUIRE lines were causing a problem - so I've dnl'd them barring some feedback from a more m4 knowedgable person. I'm a little unsure whether overriding both CPPFLAGS and CFLAGS is a good idea, but the reason is that non automake makefile.in's may not use CPPFLAGS, so CFLAGS does need to be set. Not setting CPPFLAGS results in AC_CHECK_HEADER tests for win32 headers failing. The upshot is that in automake environments -mwin32 is added twice... If there's an easy way to test for the presence of automake in the macro, I could make this conditional... I'll visit the automake doco in more detail later today... Rob acinclude.m4
Re: updated win32 macro
Well CFLAGS was the autoconf maintainers suggestion. I think I'll stick with that, and let any individual maintainer (such as cgf :] ) use the low level interface if they have a non-ordinary environment. Rob - Original Message - From: "Christopher Faylor" [EMAIL PROTECTED] To: "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 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 changing the compiler behaviour - why do the makefiles over ride that? And how common a practice is that? In fact, on second thought, packages that override CFLAGS just use the low level interface AC_PROG_CC_WIN32 EXTRA_CFLAGS="$WIN32FLAGS" I'm sure that the autoconf maintainers have more experience with this than I, but IMO relying on overriding of CC and CFLAGS isn't the way to go. When I first started changing things, I thought I could use this technique but I think it is too fragile. cgf
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 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 changing the compiler behaviour - why do the makefiles over ride that? And how common a practice is that? In fact, on second thought, packages that override CFLAGS just use the low level interface AC_PROG_CC_WIN32 EXTRA_CFLAGS="$WIN32FLAGS" I'm sure that the autoconf maintainers have more experience with this than I, but IMO relying on overriding of CC and CFLAGS isn't the way to go. When I first started changing things, I thought I could use this technique but I think it is too fragile. cgf
How do I configure to link to libtcl8.0 or libtcl7.6 depending on what is available?
Dear Autoconfiscaters: I would like to have my package link to whatever version of a package installed, but the names of the library files have the version in the name, i.e. libtcl8.2.so or libtcl75.sl etc. I could read the tcl.h header to get the version numbers, then append that to the library name string, but I want to query more expierenced users in hopes of a better way. Any suggestions? Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: How do I configure to link to libtcl8.0 or libtcl7.6 depending on what is available?
On Mar 15, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
I could read the tcl.h header to get the version numbers, then
append that to the library name string, but I want to query more
expierenced users in hopes of a better way.
Any suggestions?
tclConfig.sh
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Web Site Traffic Building
We have ranked the top ten traffic building sites on the web, these sites have been ranked by our experts, our clients and by you our visitors. Come to www.greatfreesite.net/bestten One of the top ten sites, can even guarantee top placement on the top ten search engines. Our site has been developed to help you find the most cost-effective traffic on the web. Please feel free to contact us with any questions.
