Re: process result code in if
On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote: Also when I just have: echo $var | grep -Eq '^[0-9]+$' echo $? --8-- I am on a win7 x64 machine with MinGW 3.20 and W32API 3.17 sh --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) How is the var variable set? If you're using the output of a compiled program, I'm guessing the issue is CRLF versus just LF. MSYS will not remove the CR from the variable. Add the /mingw/lib/binmode.o to the compiled program or use _setmode on stdout to make it _O_BINARY. http://msdn.microsoft.com/en-us/library/tw4k6df8(v=vs.110).aspx -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 2:34 AM, Ben Elliston wrote: On Mon, May 20, 2013 at 02:54:20PM +0800, Paul Wise wrote: There are thousands of copies of config.guess/sub (or configure scripts) out there (in tarballs) with no support for this at all. Once it is added to config.guess/sub in git (or autoconf) then it will take many years before the majority of copies of config.guess/sub (or configure scripts) have support for this. This is what I mean by bootstrap phase. Right. Just thinking out loud: isn't the Autoconf concept of aux dir of use here? That's where configure looks for config.guess. The latest version of install-sh, config.guess, etc. could live in such a system-wide directory. Unfortunately, it's not possible to set auxdir from the configure command line as you can with --srcdir, etc. Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and teach autoconf to look there if it doesn't find config.guess/config.sub in the project directory and copy them when copy is specified? I dislike the environment variable idea. Too fragile, someone forgets it is set and then has trouble because the config.guess/config.sub he's trying to use isn't being used. I know you mean for the variable to be set at autoreconf/configure usage but there are always idiots who install it into their .profile files and forget they did that. -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:09 AM, Ben Elliston wrote:
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess
{} \;
People forgetting about the symlink during distribution of their
package. Not all systems support it. Using cp -f would be better.
This puts the latest version into the tree, no patching required.
I tend to use a sub module repository and have config.guess and
config.sub in a directory (build-aux/) and I tell autoconf via
configure.ac where to find it.
--
Earnie
-- https://sites.google.com/site/earnieboyd
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:36 AM, Ben Elliston wrote: Yes, but that requires re-running autoconf. I think we're trying to avoid that because if configure.in is old, you may have a lot of work to do to get autoreconf to work. So in that case, a change to the start of config.guess and config.sub something similar to the following might be best? ~ if [[ -f /usr/local/share/config/config.guess ]] then . /usr/local/share/config/config.guess exit fi if [[ -f /usr/share/config/config.guess ]] then . /usr/share/config/config.guess exit fi -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:59 AM, Ben Elliston wrote: First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. So that's your objection to the symlink/copy idea as well? Second, I don't like the idea of doing things that surprise users. That will confuse people. It also causes recursiveness so the idea is lame unless we also trap the recursive nature to one instance. I don't think it is that confusing but perhaps --with-config-dir=/path/to/config files might be nice and configure would execute the config.guess and config.sub in that directory or error if the files do not exist or are unreadable. -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:21 PM, Ben Elliston wrote: I suggested a simple, low impact way of updating the files, particularly for people wanting to build a large number of packages (eg, for a distro). Can anyone tell me why this approach is not satisfactory? It's what I've done for years. Does it get rid of the problem? I don't think so but for legacy code that is no longer being maintained, either you maintain it, or the problem exists into infinity with a hard stop when someone does maintain it. I think the battle is trying to overcome continuing the legacy method of needing to replace config.guess/config.sub within a package and allow a common (or configurable) location be used as new development takes place. Your symlink/copy method doesn't overcome that legacy method so it would not be a satisfactory solution since that solution continues the legacy method. However, your solution does help those with packages that currently use that legacy method. -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: PACKAGE_STRING
Perhaps you could specify the shell via ``./configure SHELL=/usr/bin/ksh'' or which ever one isn't buggy? Earnie. [EMAIL PROTECTED] wrote: Hello, I use autoconf 2.59... AC_INIT generates a PACKAGE_STRING preprocessor variable which includes a blank between the package name and its version. When not using a config.h, but letting the Makefile use -D switches for the preprocessor variables, the POSIX shell under HP UX 11.00 complains: -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438
Re: GNU Libtool 1.5.2 released
Bob Friesenhahn wrote: Autoconf now performs two levels of header tests. One level is to check that the header file exists, while the other is to ensure that it can be entirely preprocessed correctly. Probably /lib/cpp is used because it is more work to figure out how to use the compiler as a preprocessor. I thought autoconf already had a macro to test for preprocessor invocation through the compiler frontend. Am I wrong? Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438
Re: [committed] Disable shared cache file more.
Nathanael,
I don't understand why you force a static cache file. Please give your
reasons.
Earnie.
Nathanael Nerode wrote:
Ick. But it appears necessary for now.
Works for me on i686-pc-linux-gnu.
* configure.in: Don't share a cache file for host dirs.
* configure: Regenerate.
Index: configure.in
===
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.264
diff -u -r1.264 configure.in
--- configure.in 3 Jan 2004 18:23:22 - 1.264
+++ configure.in 5 Jan 2004 00:47:12 -
@@ -1826,7 +1826,9 @@
cache_file_option=--cache-file=../${cache_file} ;;
esac
-host_configargs=${cache_file_option} --build=${build_alias} --host=${host_alias} --target=${target_alias} ${extra_host_args} ${baseargs}
+# Host dirs don't like to share a cache file either, horribly enough.
+# This seems to be due to autoconf 2.5x stupidity.
+host_configargs=--cache-file=config.cache --build=${build_alias} --host=${host_alias} --target=${target_alias} ${extra_host_args} ${baseargs}
target_configargs=${baseargs}
--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438
Re: [committed] Disable shared cache file more.
Nathanael Nerode wrote: Nathanael, I don't understand why you force a static cache file. Please give your reasons. Earnie. I'm disabling the shared cache file for the obvious reason; different subdirectories want to cache different, inconsistent values for the same variables. This should eventually be dealt with at its source (the configure scripts), of course. You need to remove the named cache file all together. You don't want individual subdirectory cache files either. Earnie. -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438
Re: New target
Kristian Van Der Vliet wrote: Hi, I have a small patch to config.guess config.sub which adds a new target for the Syllable operating system (A fork of the now-defunct AtheOS). I assume I just need to send the CVS diffs to autoconf-patches? IIRC, that should be config-patches. Earnie -- http://www.mingw.org Powered by SourceForge http://sourceforge.net/projects/mingw
Re: autoconf 1.7
Roopa Prabhu wrote: Can anybody direct me to autoconf 1.7 download. Cause i tried searching for it, but in vain. Perhaps you're really looking for automake-1.7? Or perhaps autoconf-2.57? Earnie -- http://www.mingw.org
Re: How many packages use autotools?
Joseph D. Wagner wrote: Pretty wild statement, especially considering the existance of the Cygwin Net Release. As far as I am aware, all packages contained in it are built using an autoconf-based ./configure script. Check out http://cygwin.com/. They use their own customized install agent (http://cygwin.com/setup.exe) for binary releases, which are downloaded as Slackware-style tarballs, and standard source tarballs that are patched when need be for source installs. If we are all honest with ourselves, autoconf on Windows and the whole cygwin project is really just a moderately successful attempt to port applications designed for, and written for, UNIX to Windows without having to completely rewrite the applications for Windows. When I see Norton SystemWorks or McAfee SpamKiller using cygwin, then I'll consider cygwin a viable development platform for Windows. Until then, it's just a port. Why would providers of predominatly Windows tools need to use Cygwin? Cygwin provided the runtime layer needed to make it easier to port predominatly UNIX tools to Windows without refactoring the code. A nice thing to have. MinGW provides tools that make it nice to actually refactor the code without refactoring the build process. Perhaps you should check those out. Earnie. -- http://www.mingw.org
Re: How many packages use autotools?
Joseph D. Wagner wrote: I use Autotools only on *NIX, I would expect that the view is different when you look through the Windows. Nobody uses autoconf on Windows. On Windows, people use Microsoft Installer or InstallShield. Autoconf is exclusively for UNIX variants (Linux, *BSD, Solaris, SCO UNIX, AIX, etc.) You couldn't be farer from the truth with that statement. I use autoconf on Windows for most products. I have been since 1998. Earnie. -- http://www.mingw.org
Re: Help -- Cygwin configuration problem
I'm redirecting you to [EMAIL PROTECTED] Please research their archives. Please remove [EMAIL PROTECTED] from your responses. Earnie. Wei Qin wrote: I have some trouble running the generated configure script on Cygwin, it complains that /bin/sh: not found at various occasions. I created a link from /bin/sh.exe to /bin.sh, but useless. Please help out if you know how to fix this. Thanks in advance. Wei
Re: Default for libexecdir
John Burger wrote:
I believe you want to do this:
libexecdir='${prefix}/lib'
which will carry over unexpanded to your Makefiles, where prefix is
given a proper value.
That would break the configure --libexecdir option, though.
I finally get it. I think you're right, you cannot change the default
values of the standard variables. In some ways, Autoconf assumes that
one is building a standard Gnu package, with all that entails about
directory stricture and names. There is some flexibility in this area,
but not as much as one might like.
I think the only thing you could do is edit the value after AC_INIT
happens, taking some care to check that the user didn't explicitly set
it on the command line - I'm not sure how to do this without using
internal details of the generated configure script ...
Create a new switch, something like --with-libexecdir=/path/to/pkg/lib,
or perhaps you like --with-pkglibdir=/path/to/pkg/lib better. The
default value for your new switch is the value for --libexecdir.
Earnie.
Re: autoconf and cl.exe
Braden McDaniel wrote: If sh is not available, presumably there would be substantial difficulty in using autoconf/configure at all. In practice, I think there are very few projects using cl with autoconf. But I want to use autotools, and building with cl is a requirement for the project I'm working on. So hopefully I can come up with a general solution to the problem. Have you looked at MSYS from www.mingw.org? I know of no reason why you shouldn't be able to use cl with it. Let's discuss on [EMAIL PROTECTED] what your difficulties are. Earnie.
Re: autoconf and cl.exe
Braden McDaniel wrote: I know of no reason why you shouldn't be able to use cl with it. Let's discuss on [EMAIL PROTECTED] what your difficulties are. Maybe I'm missing something, but I don't see that MSYS provides a bridge for the disconnect between autoconf's macros and cl. Is there a specific piece of MSYS I should be looking for? It provides a Minimal SYStem to execute configure and make. To use cl as your compiler then just ``CC=cl CXX=cl configure ... make''. If what you're after is for autoconf to look for cl as a possible compiler that's another matter; but one that could be worked through on the mingw-users list. Earnie. P.S.: Due to SPAM issues mingw-users and mingw-msys have become member only lists. If you wish to post, you will need to join the list. If you don't want to receive the list mail then choose the nomail option when joining. Please visit http://www.mingw.org/lists.shtml for links to the list form. There may be a time lag between subscribing and you are actually listed as a member. If you see this rejection message again after subscribing, please try your post again later.
Re: OT - Packages maintaining source for systems no longersupported[WAS: Re: Portability of preprocessor directives]
Andreas Buening wrote: Earnie Boyd wrote: [snip] I would like to emphasize though, if the hobbyist isn't willing to test for new releases using his hobby environment then support for that environment should be removed. A package maintainer doesn't have enough cycles to maintain code that no one uses and doesn't have enough cycles to do the testing himself. So, if no one is testing then the maintainer can assume that no one is using that environment and drop support for it altogether. What do you consider a hobbyist system? One that the vendor no longer supports and supplies fixes for and I as a maintainer of the software no longer have no access to test it myself. If it's not even tested how can it be used? It has a high probability of not working anyway! I guess, 99.99% of all people (maybe even more) don't test software packages as long as they don't need to do. If I'm rolling out new systems and new software, then yes regressions must be tested for. I only care about the ones I use, not the ones I don't. If I have a HP UX 9.x system and a maintainer of a software package makes improvements and I don't test them I my system then whose fault is it. The maintainer doesn't make any warranties, nor does anyone else. I must myself make the warranty, provide the appropriate patches and move on. I remember Debian hit the 8000 package limit some time ago. How many of the software packages you use for your daily work do you really test? 1000? 100? I guess, it's less. Much less. If it's just 1 then you do much more than 99.x% of all people do. Having no tester for a specific system doesn't mean there are no users. Well, if the package works for the maintainer and he rolls that out as a production release but it works for no one else because no one has an enviroment like the maintainers then the package will only have one user. It is impossible for a package maintainer to test all combinations of environment. He can do his best to try not to break the workings of the program for a particular system, but if no one is using that system anyway why continue to support it? At that moment of realization it's time to prune support for that system from the code. Not all packages have as many contributors as autoconf. If you immediately drop support for all systems when you don't have a tester then you will hurt all systems that are not a standard Red Hat Linux out of the box installation. So, you've tried both RedHat and Debian versions of Linux. ;) I'm not talking about viable well supported systems that are currently being used. I'm talking about systems that are no longer supported by their respective vendors at all and used little. You won't get a feedback one day after you've released the new version of foo, maybe not even this year, maybe in two years when Joe User wants to compile the cool new xyz program on SysBlurb which needs the great and unique abc library. And to compile abc he needs the latest version of foo and this doesn't work because there was no tester so nobody needs foo on SysBlurb. At that point it's called porting. He ports the package to his system and submits patches to the maintainer for enjoyment in the future. The maintainer of an open source package is more a facilitator of patches more than he is the originator of the patch himself. I take it from your tone that you are a user and not a participant in open source? I take it from your tone that you don't want your programs to stop working but that you aren't willing to put effort into making sure that doesh't happen beyond spouting words? I take it from your tone that you think the maintainer of code should keep code in his source files that someone someday maybe might use again on the pretense that someone used it once and it maybe someday just might be done that way again? Ridiculous! If the code isn't being used then remove it. If I remove the code from packages I maintain and it was used then perhaps someone might complain and it can be readded. Perhaps someone will do something even more clever and supply a better patch. Perhaps it just might cause testing by those interested in the package before the next release. Earnie.
Re: OT - Packages maintaining source for systems no longersupported[WAS: Re: Portability of preprocessor directives]
Thomas Dickey wrote: On Wed, Mar 12, 2003 at 08:27:21AM -0500, Earnie Boyd wrote: What do you consider a hobbyist system? One that the vendor no longer supports and supplies fixes for and I as a maintainer of the software no longer have no access to test it myself. If it's not even tested how can it be used? It has a high probability of not working anyway! bear in mind that Ernie's frame of reference is that anything older than a year is probably too far into the past to consider (look at his webpage for an example of his notion of support). Which webpage would that be? Earnie.
Re: OT - Packages maintaining source for systems no longersupported[WAS: Re: Portability of preprocessor directives]
Thomas E. Dickey wrote: cygwin mingw32 You mean the freeyellow site? I've taken care of that. Earnie.
Re: OT - Packages maintaining source for systems no longersupported[WAS: Re: Portability of preprocessor directives]
Thomas Dickey wrote: On Wed, Mar 12, 2003 at 12:32:41PM -0500, Earnie Boyd wrote: Thomas E. Dickey wrote: cygwin mingw32 You mean the freeyellow site? I've taken care of that. well, that's (one of) your hobbiest webpages. where's the professional one? I have nothing to do with the ``professional'' Cygwin webpage that you can find at www.cygwin.com. As for MinGW try http://www.mingw.org. Earnie.
Re: Portability of preprocessor directives
Thomas Dickey wrote: On Mon, Mar 10, 2003 at 06:58:59PM -0500, Earnie Boyd wrote: If the OS isn't supported by the vendor is it really necessary for new releases of the tool to support such a beast. If a hobbyist is in need of an older release, so be it, let the hobbyinsts help each other. Otherwise, there is this term known as ``porting'' that comes to mind. If you make it known that you need testing for a new release and testing doesn't happen for the hobbyist, then whose problem is it, yours, I think not. Let the hobbyist test when testing is needed or else remove support for the untested in the next release from the current. I assume you're talking about Redhat, for instance. Have to be fair, you know. No, my reference wasn't to any particular vendor. The comments came from references to HP UX version 9.x but I generalized even more. I would like to emphasize though, if the hobbyist isn't willing to test for new releases using his hobby environment then support for that environment should be removed. A package maintainer doesn't have enough cycles to maintain code that no one uses and doesn't have enough cycles to do the testing himself. So, if no one is testing then the maintainer can assume that no one is using that environment and drop support for it altogether. Earnie.
Re: Portability of preprocessor directives
Paul Eggert wrote: Thomas Dickey [EMAIL PROTECTED] writes: HPUX 9.x's C compiler trashed files starting with an #elif (that's in the early 90's - within the scope of his request). Thanks for mentioning that; I hadn't heard that one. I found a 7-year-old bug report for CVS that mentions the same issue, for HP-UX 9.01, in http://www.geocrawler.com/archives/3/383/1996/5/0/2114760/. If the OS isn't supported by the vendor is it really necessary for new releases of the tool to support such a beast. If a hobbyist is in need of an older release, so be it, let the hobbyinsts help each other. Otherwise, there is this term known as ``porting'' that comes to mind. If you make it known that you need testing for a new release and testing doesn't happen for the hobbyist, then whose problem is it, yours, I think not. Let the hobbyist test when testing is needed or else remove support for the untested in the next release from the current. Earnie.
Re: please reply immediately
Giuseppe Greco wrote: On Sat, 2003-03-08 at 20:17, Bob Lockie wrote: On 03/08/03 11:51 Abdulahi Mohammed spoke thusly Ya, right. This is an illegal scam. How did it get on this list anyways? I FULLY AGREE!!! I get messages like this every day... Pflui! And you two are contributing to the distribution of SPAM. **It happens, ignore **it and go on. Earnie.
Re: keeping $exec-prefix et al unexpanded
IIRC, ``make install prefix=/tmp/foo'' is a GNU standard mandate where prefix for the install does not modify the prefix for the build. Earnie. Harlan Stenn wrote: Why don't you use DESTDIR instead? IE: ./configure --prefix=/usr make make DESTDIR=/tmp install cd /tmp tar cfz binary-tarball.tgz usr H
Re: Is AC_FUNC_MALLOC more trouble than it's worth?
Ronald Landheer-Cieslak wrote: On Thu, 6 Feb 2003, Jim Meyering wrote: Paul Eggert [EMAIL PROTECTED] wrote: Ronald Landheer-Cieslak [EMAIL PROTECTED] writes: I have never (so far) tried to allocate a block of 0 bytes willingly In that case you don't need those macros. They're mainly useful for programs that want malloc(0) to return a nonnull pointer. Another reason to use at least AC_FUNC_REALLOC (and one that motivated me to write the macros and replacement functions) is that on some systems, realloc (p, n) fails when P is NULL. Right - guess I'm back off experimenting, then. Would you happen to know of any (common) systems for which this is a problem? (just so I can get an idea of what kind of priority I should give this - I've been having a bit of trouble using the replacement realloc in a C++ program) Win32 systems, both realloc and free. Earnie.
Re: How to Setup Autoconf?
[EMAIL PROTECTED] wrote: HELP!!! well that's a good way to start the mail :D. I'm trying to compile apache 2.0. i need autoconf to make the configuration file. (I've never done this b4 so don't be surprised by the incomptence of the questions hehe). I have Borlands C++ text line compiler and autoconf 2.57. How do i use autoconf??? howdo i setup autoconf, does it need compiling first??? what is a cpp file??? why haven't i got any cpp files in the autoconf download??? what other inane questions can i come up with??? Any comments greatly appreciated You shouldn't need autoconf, you should just execute the configure script. Is this a MS windows environment? Yes, see http://www.mingw.org. Earnie.
Re: How to Setup Autoconf?
[EMAIL PROTECTED] wrote: Ok, i've downloaded MinGW (i've tried this b4 unsucessfully, but then none of its worked yet, roflmao). How do i use this with the configure script (damn it i'm being dumb) Install http://prdownloads.sf.net/mingw/MSYS-1.0.8.exe. See http://www.mingw.org/msys.shtml for info. BTW, you may need to see http://www.cygwin.com if this is a cygwin1.dll dependent version fo apache. Earnie.
Re: Makefile variables depending on configure args - how?
Markus Werle wrote:
Paul Brook wrote:
I think you need to add
AC_SUBST([DIET], [${DIETDIR}])
Thanks! I knew it was something very simple.
Another question: I thought configure.in was just a shell
script substitute, so I ommitted the {}.
Also missing brackets around DIET do not disturb autoconf.
Is the follwing OK, or are there any issues (like portability)?
AC_SUBST(DIET, $DIETDIR)
The rule of thumb is to quote. The expansions may cause problems that
quoting will avoid. I.E.: It may work this time, but not the next.
Earnie.
Re: auto{conf,make} DJGPP: DESTDIR
Richard Dawe wrote: Hello. I've ported autoconf 2.57 and automake 1.7.2 to DJGPP, based on Tim van Holder's work. Unfortunately DESTDIR support is currently broken for DJGPP. The reason is that the generated Makefiles do things like $(DESTDIR)$(binprefix). $(binprefix) could be something like c:/djgpp/bin and $(DESTDIR) could be, say, d:/put/packages/here/. So $(DESTDIR)$(binprefix) becomes d:/put/packages/here/c:/djgpp/bin, which doesn't make sense. DJGPP supports referring to c: as /dev/c. So one possible solution to this problem is to ensure that $(prefix) and its derivatives are always mapped to /dev/letter/ paths from letter: paths. But where would this mapping take place? In autoconf alone? Or would both autoconf and automake require modification? That sounds as if it's a modification to the way you define prefix during the configure process. ./configure --prefix=/dev/c/djgpp. But that still sounds bothersome when combining DESTDIR. Check out: http;//www.mingw.org/msys.shtml for a Minimal SYStem alternative that can cope with this problem. Curious, what does DJGPP return for ``uname -s''? Earnie.
Re: test (and gmane)
Guido Draheim wrote: has gnu.org eaten our mails? I know atleast of four mails that have been sent but not coming back through the mail loop to me, nor do they pop up at gmane within the last dozen hours. Pretty irritating that is... well, atleast here's the link to gmane in case you have not come across this greatest new thing on the internet in the last months...;-) Perhaps the forwarding account for gmane has been purged from the autoconf list. For gmane to work, it must maintain an active account with the autoconf list. http://news.gmane.org/thread.php?group=gmane.comp.sysutils.autoconf.general actually, who has started this one? the libtool mailinglist has made it to comp.gnu which I think is much more logical... http://news.gmane.org/thread.php?group=gmane.comp.gnu.libtool.general So complain to the gmane maintainers they might do something, they might not. Some interested fourth party (a single individual) creates the mail - news via a request to gmane. Gmane administrators then create the link by joining the mail list. Earnie.
Re: make fails for 2.57 with mingw/msys
Johan Lindh wrote: Hi, I downloaded the source tarball for autoconf-2.57, but I ran into problems when making. autoconf-2.52 does not have this problem. I am running mingw-2.0.0-3 and MSYS-1.0.8 on Win2K, with ActivePerl 5.6.1.633. This is an authoritative answer from the maintainer f mingw-2.0.0-3 and MSYS-1.0.8. The combination you've set forth does not work. I provide for that reason a prebuilt autotools in a msysDTK package. If you wish to discuss this further, please take it to the [EMAIL PROTECTED] list. Earnie.
Re: Defining prefix
John Poltorak wrote: If I have prefix defined in config.site and use a diferent value on the command line, which should take precedence? The command line. Earnie.
Re: AC_MINGW32 and AC_CANONICAL_HOST
Kevin Ryde wrote: I notice that AC_MINGW32 and friends don't cooperate with AC_CANONICAL_HOST. A configure.in AC_INIT AC_CANONICAL_HOST AC_MINGW32 AC_CYGWIN AC_EMXOS2 processed with autoconf gives configure.in:3: warning: AC_CANONICAL_HOST invoked multiple times configure.in:4: warning: AC_CANONICAL_HOST invoked multiple times configure.in:5: warning: AC_CANONICAL_HOST invoked multiple times I see it was a deliberate change not to use AC_REQUIRE in those, perhaps something else is wanted. (I know these macros are obsolete, I only struck this running a recent autoconf over a guile configure.in.) Did you autoupdate? Earnie.
Re: autopoint?
Olaf Weber wrote: Patrick Welche writes: What is autopoint? Apparently a utility in the gettext package. That apparently needs executed through the missing script? Earnie.
Re: check for microsoft compiler cl
Warren Young wrote: Paul Eggert wrote: I assume so, but you may have to consult a Cygwin mailing list. No, _don't_ bother the Cygwin mailing lists about Visual C++ problems. _Way_ inappropriate forum; they'll tell you to use gcc, which auto* will use without any problems. Johannes, if you're just changing the CC variable and expecting it to work, that's why you're having problems. The configure script probably assumes that foo.c gets compiled to foo.o and linked to foo. What cl will do is make foo.obj and link that to foo.exe. Due to the Cygwin work, there's probably a way to tell auto* what the platform filename extensions are, but this is not a Cygwin problem per se, so don't bother them about it. Just find out what extensions they added to the traditional POSIXy core of auto*, and use them. IIRC, autoconf handles .obj correctly. I don't know if there's a make builtin rule for .obj though. Earnie.
Re: ccache and autotools
Jean-Eric Cuendet wrote: Hi, I have a C++ project with a lot of source files (~4000). I'd like to use ccache to speed recompilation of the project. I can't since ccache doesn't support -MT flag to gcc What does EXACTLY this flags? Is it possible to tell autoconf/automake to not use -MT when generating the Makefiles? Would it not be best to fix ccache? Or is it such that ccache should avoid -MT? Earnie.
Re: configuring sub directories optional
Jeff Squyres wrote: On Mon, 28 Oct 2002, Stefan Seefeld wrote: I'd like to use AC_CONFIG_SUBDIRS to configure a set of sub-packages, but I'm missing some functionality: I'd like to control what to do if configuration fails. Some sub-packages are mandatory, so if AC_CONFIG_SUBDIRS fails, the parent configure should report an error and bail out. Some, however, are optional, so I'd just like to skip them, i.e. not creating the build tree for these sub-packages at all. I'd like to second this request -- I recently had to write a huge workaround for AC_CONFIG_SUBDIRS because it wouldn't let my [optional] subdirectory configure's fail gracefully. It would be highly preferable if there was some kind of way of knowing whether the sub-configure failed, and then allowing the top-level configure.ac to decide whether to continue or not. And I would like it to butter my toast on both sides then top it with jelly on one side and peanut butter on the other. I just love sticky messes! ;) I suppose checking for the existance of a created file in the subdirectory from the top-level configure isn't a choice that one would consider? Earnie.
Re: configuring sub directories optional
Jeff Squyres wrote: On Mon, 28 Oct 2002, Earnie Boyd wrote: I suppose checking for the existance of a created file in the subdirectory from the top-level configure isn't a choice that one would consider? No -- that's not the problem. The problem is that AC_CONFIG_SUBDIRS (and therefore the top-level configure.ac) will immediately abort if any of the sub-configures return anything other than a status of 0. So there's no possibility of the top-level configure.ac checking to see if the sub-configure succeeded or not -- if the sub-configure fails, everything aborts. Ok, I'll shut-up now. But, at least we have a full understanding of the problem. Thanks, Earnie.
Re: Libtool 1.4.3
Paolo Bonzini wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. But it also contains more features. Releasing 1.5 should be done by the maintainers, not by a community process; instead I think that such a process is perfectly valid to review patches and ChangeLogs and put them together. The community are the maintainers, therefore a maintainer has spoken for a minor version increment, rather than a patch release increment. Enough has changed to increment the minor version number. Yes, libtool would-be-1.5 has been used by gcc at least since 3.0, so it should be pretty good, but I think that it is easier (in terms of brainwork, not of needed resources) to do a definitive 1.4.x release. Since I'm one of the community, I suggest the release to be 1.5 and that Akim's suggestion for AC_PREREQ a strong point. Perhaps, both a 1.4.3 and a 1.5 where 1.4.3 does a AC_PREREQ 2.13. Earnie.
Re: functions in different libraries on different OSes.
Russ Allbery wrote: Dan Kegel [EMAIL PROTECTED] writes: Standard practice is probably to always write #if HAVE_SYS_TYPES_H #include sys/types.h #endif There's no need to check for the existance of sys/types.h unless you're attempting portability far beyond that any normal software package will need. It exists on pretty much any modern platform and nearly all obsolete ones. True for Windows. #if HAVE_SYS_SOCKET_H #include sys/socket.h #endif Likewise here; if it has the socket functions, it will have sys/socket.h. Not true for windows, it uses either winsock.h or winsock2.h depending on the windows socket version level you want to support. Typically this will be winsock2.h which is for the ws2_32 library while winsock.h is for the wsock32 library. The current compilers support ws2_32 by default, i.e.: when including windows.h you get winsock2.h by default. One of the reasons for this is that it uses the socket() function. Under FreeBSD this is in libc, and requires the following header files to be included: #include sys/types.h #include sys/socket.h The same is also true of GNU/Linux. However, under Solaris (SunOS 5.6) you must compile againt -lxnet and include only #include sys/socket.h It's harmless to include sys/types.h as well. You probably don't want -lxnet. You probably want -lsocket. Don't pay too much attention to the Solaris man pages unless you're sure you have the right section. There may be other methods of getting socket() on other OSes, for all I know. What is the correct way to diagnose how to get socket(), or any other function, on a given OS, and to build the software appropriately, using autoconf? Always include sys/types.h and sys/socket.h. Then use something like this, which should work pretty well: dnl The rat's nest of networking libraries. The common cases are not to dnl need any extra libraries, or to need -lsocket -lnsl. We need to avoid dnl linking with libnsl unless we need it, though, since on some OSes where dnl it isn't necessary it will totally break networking. Unisys also dnl includes gethostbyname in libsocket but needs libnsl for socket(). AC_SEARCH_LIBS(gethostbyname, nsl) AC_SEARCH_LIBS(socket, socket, , [AC_CHECK_LIB(nsl, socket, LIBS=$LIBS -lsocket -lnsl, , -lsocket)]) You'll need to modify this for windows support. Earnie.
Re: Fw: MKS toolkit the 2nd
Just point people to www.mingw.org and it's Minimal SYStem package, MSYS, and it's MinGW package. :) Advantage: : The configure script already executes properly. : It's open source. : It uses gcc+binutils+gmake. Earnie.
Re: Autom4te, autoconf problem
/usr/bin/m4 --version? Earnie. f l wrote: Hi all, when I execute this command: autom4te -F autoconf.m4f autoconf.m4 I obtain this output: autoconf.m4:108: /usr/bin/m4: Warning: Too few arguments to built-in 'patsubst' Anyone know what is the problem ? Thanks __ Boîte aux lettres - Lycos - http://www.lycos.fr
Re: [PATCH] fix bug in autoconf-2.13 that keeps cross gcc from buildingon cygwin
I suggest that this issue be dealt with within the Cygwin distribution of
autoconf-2.13.
Earnie.
Dan Kegel wrote:
[repost -- mail system problems]
Building cross gcc's on cygwin fails because autoconf 2.13's AC_TRY_COMPILER
test assumes that it's ok to try to run possibly cross-compiled binaries,
and that if they run, the compiler must not be a cross-compiler.
This assumption fails on Cygwin; see
http://www.oarcorp.com/rtems/maillistArchives/rtems-users/1999/may/msg00075.html
http://gcc.gnu.org/ml/gcc-help/2002-05/msg00165.html
http://sources.redhat.com/ml/crossgcc/2002-08/msg00099.html
The symptom is the build hangs about twenty times waiting for you to click a dialog
box,
and the target directory's ac_cv_prog_cc_cross is improperly set to 'no'.
The problem will likely go away when gcc moves to using autoconf 2.5x, but
that may take a while, and won't help people who need to build oldish
gcc's like 3.0.x. So it's worth fixing autoconf-2.13 if it's a small, safe fix.
Fortunately, the fix does look small and safe:
--- /usr/share/autoconf2.13/acgeneral.m4.orig Thu Aug 22 18:26:58 2002
+++ acgeneral.m4Thu Aug 22 19:03:12 2002
-1510,11 +1510,13
EOF
if AC_TRY_EVAL(ac_link) test -s conftest${ac_exeext}; then
[$2]=yes
- # If we can't run a trivial program, we are probably using a cross compiler.
- if (./conftest; exit) 2/dev/null; then
-[$3]=no
- else
-[$3]=yes
+ if test $[$3] != yes; then
+# If we can't run a trivial program, we are probably using a cross compiler.
+if (./conftest; exit) 2/dev/null; then
+ [$3]=no
+else
+ [$3]=yes
+fi
fi
else
echo configure: failed program was: AC_FD_CC
i.e. after the patch, AC_TRY_COMPILER checks its 3rd parameter,
and if it's already 'yes', it knows not to run the binaries.
After applying this patch to autoconf-2.13 and installing,
you then need to regenerate libiberty/configure,
gcc/configure and fastjar/configure. It might be good if future releases
of gcc that still used autoconf-2.13 were done on machines with an
autoconf-2.13 with this patch applied.
This is only a partial fix; it requires the user to override
ac_cv_prog_cc_cross. A similar bug in ltconfig can be worked around
without a patch by overriding cross_compiling=yes in the same way.
Both overrides should only be done during the build of runtime libraries.
Fortunately, gcc's makefile has pseudotargets that let you do this.
For instance:
make all-gcc
ac_cv_prog_cc_cross=yes cross_compiling=yes make all-target
make install
Users on non-cygwin platforms can ignore this issue, and just do
'make install' as usual. This patch will neither help nor hurt them.
(Note that overriding ac_cv_prog_cc_cross at make time appears to be sufficient.
Although it would be more logical to override them when doing initial
configuration of gcc, that wouldn't let you work around the ltconfig bug.)
Even if future autoconf and gcc releases don't apply this patch, maybe
this post will help people who need to build gcc on cygwin.
- Dan
http://www.kegel.com
Re: Compilation of GIMP under window32
We can handle this in MinGW. We'll create the sys/param.h file. For now you can use: FILE NAME=/mingw/include/sys/param.h #ifndef _SYS_PARAM_H #define _SYS_PARAM_H #include sys/types.h #include limits.h #endif /FILE Please report other problems with this to [EMAIL PROTECTED] Earnie. James Michael DuPont wrote: Here is an update on the mingw32 build. I have found some more files that contain the problem of the bad assumptions. this same text occurs in the following spots on my cygwin install autoheader.m4f:3885:# define HAVE_SYS_PARAM_H 1 autoconf.m4f:3939:# define HAVE_SYS_PARAM_H 1 Now these are Frozen Files? I dont seem to be able to change them without breaking something. So, I have installed the source code for autoconf-2.53a under cygwin, and have modified the lib/autoconf/functions.m4, line 924-927, to remove the assumption. The make builds the frozen files ../../tests/autom4te\ --language=autoconf \ --freeze\ --include=./.. \ --include=..\ --output=autoconf.m4f Right now, I am just commenting out the assumption, that is sure to break all the other builds. I dont think this is the final solution, some checks to see if we are running mingw are needed... Any ideas? Mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Autoconf for DJGPP
I suggest you as an appropriate DJGPP list for help. The autoconf and configure are Bourne shell scripts and therefore you need an appropriate Bourne shell interpreter. Earnie. [EMAIL PROTECTED] wrote: Dear All, I am trying to compile GNU Chess with the help of DJGPP. I am doing everything exactly as in the instruction: -- First, cd to the src directory. Run autoconf to build configure from configure.in Then run configure to build Makefile from Makefile.in. Now run make to build gnuchess.exe -- Can anyone tell me where to get autoconf.exe and configure.exe ? I don't have them after installation of DJGPP :-( Can anyone give a link where I can download all necessary packages? Thank you very much in advance. Best regards, Ihor.
Re: Autoconf for DJGPP
Earnie Boyd wrote: I suggest you as an appropriate DJGPP list for help. The autoconf and s/as/use configure are Bourne shell scripts and therefore you need an appropriate Bourne shell interpreter. Earnie. [EMAIL PROTECTED] wrote: Dear All, I am trying to compile GNU Chess with the help of DJGPP. I am doing everything exactly as in the instruction: -- First, cd to the src directory. Run autoconf to build configure from configure.in Then run configure to build Makefile from Makefile.in. Now run make to build gnuchess.exe -- Can anyone tell me where to get autoconf.exe and configure.exe ? I don't have them after installation of DJGPP :-( Can anyone give a link where I can download all necessary packages? Thank you very much in advance. Best regards, Ihor.
Re: Autoconf for DJGPP
Please stay on list. [EMAIL PROTECTED] wrote: eyc I suggest you as an appropriate DJGPP list for help. Which list? http://www.google.com/search?hl=enie=ISO-8859-1q=DJGPP+mail+list eyc The autoconf and eyc configure are Bourne shell scripts and therefore you need an appropriate eyc Bourne shell interpreter. Can you hint me, does there exist a Win32 version of these script interpreters? http://www.mingw.org/msys.shtml As far as I understood, you're working under Unix. Could you create a makefile for me if I send you makefile.in and makefile.am? No, I'm working on Win32, executing bash. And, no I won't create a Makefile from your Makefile.in as that is pointless. The purpose of autoconfiguration is so that the build process knows about your environment and your environment doesn't match mine. Earnie.
Re: preprocessor definitions with am, ac and ah without template files
Christian Kreibich wrote: I used to use acconfig.h. So I thouht I'd try to clean this up, have removed acconfig.h, and updated my configure.ac accordingly. After adding AC_CONFIG_HEADERS to configure.ac, autoheader is happy, but automake fails with automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'. If I use AM_CONFIG_HEADER instead, autoheader complains autoheader2.50: error: AC_CONFIG_HEADERS not found in configure.ac. So, how do I solve this? automake still appears to be doing its job, but returns an error code of 1 which causes make to abort. I've tried a number of version combinations and am now on ac 2.53 and am 1.6.2, but I just cannot work around this. Make sure that your acinclude.m4 file doesn't include older versions of these macros. Earnie.
Re: auto-regenerating Makefile.in and Makefile files
Tom Tromey wrote: Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf This works perfectly well unless the structure of the configured Ralf source-tree changes (adding/removing Makefile.ams) or if the Ralf source-tree contains conditionally configured sub-directories Ralf (eg. CONFIG_SUBDIRS which get condistionally excluded/included Ralf from building). I've always wanted to make adding a new Makefile.am work. There's never seemed to be a particularly good implementation though. Wouldn't this work anyway because you had to change the top-level Makefile.am or configure.in to include the new SUBDIR? I.E.: Makefile.in : Makefile.am configure.in Earnie.
Re: auto-regenerating Makefile.in and Makefile files
Schleicher Ralph (LLI) wrote: Ralf Corsepius [EMAIL PROTECTED] writes: Am Mit, 2002-07-03 um 09.44 schrieb Ionutz Borcoman: Or is there a simple command to do this (but keeping all the options I've give to configure) ? make Wrong answer. Read the question more carefully. To the Automake maintainers: please device a way for adding user-defined configure options to configure when re-running configure (e.g., grep the configure command line from config.log). Doesn't `./config.status -recheck ./config.status' do what you need? That is what automake causes the Makefile to do and what Ralf meant with his make answer. What do you mean by user-defined configure options? Earnie.
Re: [Autogen-devel] building a libguile client
Bruce Korb wrote: Earnie Boyd wrote: I execute noag-boot.sh and find that configure can't locate -lregex for some reason. I do have it in /usr/lib. But not in /usr/lib/libc*. But, couldn't we just look for them in the other common libraries in the configury before complaining and have the configury set the LIBS value appropriately? So I export LIBS=-lregex and execute noag-boot.sh again. Exactly the thing I was hoping to point you at with the config message: Yep, that's what clued me in. cat 2 '_EOF_' I cannot detect POSIX compliant regcomp/regexec routines. These are required for AutoGen to work correctly. If you have such a library present on your system, you must specify it by setting the LIBS environment variable, e.g., LIBS='-lregex'. If you do not have such a library on your system, then you should download and install, for example, the one from: ftp://ftp.gnu.org/gnu/rx/ ... I make distclean, configure --prefix=/usr --disable-shared and make. Now I find config.h and /usr/include/libguile/scmconfig.h redefine a boat load of constants, like PACKAGE_*, is this due to a misconfigure of libguile? Yes. Unfortunately, there is no trivial way out of the problem. I think the proper solution is for guile (and any other package that installs its own config.h file) to prefix the defines: http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html and use those #define-d values from their installed config header. It would be good to prominently document the importance of this in the autoconf docs. Meanwhile, we have a problem So it sounds as if we need to submit patches to libguile, if not done so already, and argue the case. However, we might need to update autoconf documentation first. I finally get to the compile of agen5/cgi-fsm.c and find cgi-fsm.h missing. Is this supposed to be generated? The agen5/cgi-fsm.c file is stored in CVS, should the corresponding header also be available from CVS? No. cgi-fsm.c is under CVS because it contains some edited source, though it is mostly generated. Looks like I left cgi-fsm.h off the list of generated source. Sorry. It will be updated in a few minutes. I'll also send it as an attachment under separate cover. Thanks, Earnie.
Re: cache directory is not removed
Sam Steingold wrote: * In message [EMAIL PROTECTED] * On the subject of Re: cache directory is not removed * Sent on 07 Jun 2002 17:06:04 +0200 * Honorable Akim Demaille [EMAIL PROTECTED] writes: Sam == Sam Steingold [EMAIL PROTECTED] writes: Sam nope. when I distribute CLISP, I cannot assume that my users Sam have autoconf, so I distribute the generated configure scripts Sam too. i.e., the configure scripts are in the source tree and are Sam regenerated just before a release. thus, if I use autoconf 2.53, Sam I have to remove the cache directories by hand before a release, Sam so that they do not end up in the distribution file. But how do you write you dist target? How come it ends in the tarball!?! pretty much `tar cz dist.tgz src/` (with some bells and whistles). now I will need to exclude the cache directory name, which includes the autoconf version number, i.e., I will have to change my `make dist` after every autoconf release. So your real problem is where the cache directory is created. If it weren't created in the source directory then your problem would be solved. Earnie.
Re: cache directory is not removed
Sam Steingold wrote:
So your real problem is where the cache directory is created. If it
weren't created in the source directory then your problem would be
solved.
pretty much yes.
/tmp/autocong.cache would be perfectly fine with me.
I was thinking more of /var/tmp/autom4te.cache/application-version if
/var/tmp exists or /tmp/autom4te.cache/application-version if /var/tmp
doesn't exists or if neither exists the value of
`pwd`/autom4te.cache/application-version with the default overridden
by ${AUTOM4TE_CACHE_PATH}/application-version.
For the purposes of the above paragraph the term exists also implies
user readable and user writable.
Earnie.
Re: cache directory is not removed
Bill Wendling wrote:
Also sprach Earnie Boyd:
} Sam Steingold wrote:
}
}
}
} So your real problem is where the cache directory is created. If it
} weren't created in the source directory then your problem would be
} solved.
}
} pretty much yes.
} /tmp/autocong.cache would be perfectly fine with me.
}
}
} I was thinking more of /var/tmp/autom4te.cache/application-version if
} /var/tmp exists or /tmp/autom4te.cache/application-version if /var/tmp
} doesn't exists or if neither exists the value of
} `pwd`/autom4te.cache/application-version with the default overridden
} by ${AUTOM4TE_CACHE_PATH}/application-version.
}
} For the purposes of the above paragraph the term exists also implies
} user readable and user writable.
}
Of course, you run into the problem of having multiple packages you're
developing on the same machine and they're using the same
${TMP}/autom4te.cache/ directory
I suppose I should have mentioned that application-version is a
directory named after the application being autoconfed. I also should
have called it package-version. So if I have package foo-1.0 then the
cache directory would be one of
/var/tmp/autom4te.cache/foo-1.0
/tmp/autom4te.cache/foo-1.0
./autom4te.cache/foo-1.0
${AUTOM4TE_CACHE_PATH}/foo-1.0
Earnie.
Re: cache directory is not removed
Steven G. Johnson wrote: Bill Wendling wrote: I concur. It is an annoyance. Having a flag (--remove-cache) as mentioned above would be very nice. Having the cache directory is fine, but keeping them there is a pain... I would go further and suggest that perhaps this should be the default behavior...probably the vast majority of autoconf users are more annoyed by the generated files lying around than they are by an extra three seconds on the rare occasions they run autoconf. And the time penalty will drop over time as computers get faster (unless Akim bloats autom4te to compensate :-). (Instead of creating and removing the cache, it would be better to not create it at all, or just send it all to /dev/null like we did with config.cache.) So now I run `configure -C' always. I use the cache files to determine problem areas of my runtime libraries. It could use/create the cache only if the autom4te.cache directory exists, or if the user passes --autom4te-cache or something like that. This way, you would only need to explicitly indicate once that you want the cache (per project), and it will be used thereafter (unless the users deletes the cache directory). There is an easy way to get rid of the cache directory. It involves a simple command. This commands repeated use will not even come close to the amount of bits spread for this thread and others like it. Just `rm -rf autom4te-2.53.cache' if you don't want it laying around. Earnie.
Re: cache directory is not removed
Steven G. Johnson wrote: Earnie Boyd wrote: So now I run `configure -C' always. I use the cache files to determine problem areas of my runtime libraries. Bill Wendling wrote: BTW, the removal of automatically generating a config.cache file by default was a bad idea, in my opinion. We actually use that file quite a bit. Generating config.cache by default caused recurrent problems with users who would inadvertantly use stale config.cache files. Notice that I said that I use `configure -C' as a suggestion for the users who want config.cache. There was a point in time when I didn't know what a config.cache was. There was a point in my life when config.cache was bad. Then I came to realize how it was useful to me. Yes, if I change the runtime, I must recreate the config.cache. The configure script is intended for *users*, who by far outnumber developers and are far less capable of realizing what config.cache is doing. It doesn't make sense to optimize the uncommon case (the developers, who are perfectly capable of using -C or of modifying config.site to make it the default) at the expense of the common case (the users). I agree. Akim wrote: They don't have understood the point. And then, why keep the .o too? And the .deps? Again, it's a matter of tradeoffs and optimizing for the common case. On the one hand, programs spewing files as a side-effect that the user didn't explicitly request is generally undesirable. On the other hand, developers change source code files and recompile *very* often, so the extra speed (which can be orders of magnitude for .o!) is worth the filesystem litter. I don't think you realize the impact of using the cache here. On the file utils, on my machine, it means that running automake, autoconf and autoheader is about 1min long. Remove the cache, it's three minutes. Running autoconf + automake + autoheader is not a common operation for most developers (autoconf developers don't count!), and in such a context I would argue that one minute vs. three is not that significant. There are a number of packages that if you have these installed will run them for you. I don't think it good but ... Earnie.
Re: Cross-compiler setup with autoconf and M$ CL
Have you ever review MinGW and MSYS? See: http://www.mingw.org/ for more information. Earnie. Keve Müller wrote: Hi! Thanks for the _fast_ help. With your pointers I've tracked down the problem to the following. CC=cl ./configure --host=windows32 fails, because config.guess tries to canonicalize the _build_ environment by compiling a small code that includes features.h which is unavailable with the M$ compiler. CC=cl ./configure --build=windows32 --host=windows32 works fine, as nothing needs to be guessed by compilation. Autoconf brilliantly sets up all the other stuff, like obj/exe suffixes, etc. As in my setup the configure script is called from another build environment (Ant), I've decided to set CFLAGS, etc from within the configure script. The rather preliminary work can be inspected at SourceForge. The project's name is jxUtil. The C stuff is under jxUtil/src/c Thanks again for your support! Keve
Re: Latest autoconf breaks ccAudio, ccRTP
You need an AC_PREREQ(2.53) in your configure.in file. Cygwin has specialized scripts that search for AC_PREREQ to determine whether or not to use 2.13 or the newer versions of autoconf. If it doesn't find an AC_PREREQ then it defaults to 2.13. Earnie. Jason Spence wrote: Hi, I'm not on the list, please CC me on any replies. I've been trying to debug a problem with the latest auto* tools which has caused at least two packages I work with to not configure under cygwin any more. Autoheader outputs this: aclocal.m4:770: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/general.m4:2000: AC_TRY_EVAL is expanded from... aclocal.m4:770: the top level autoheader: autom4te failed with exit status: 1 at /usr/autotool/devel/bin/autoheader line 163 configure.in:22: required file `src/config.h.in' not found aclocal.m4:770: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/general.m4:2000: AC_TRY_EVAL is expanded from... aclocal.m4:770: the top level I read the note about this in section 15.6.2 of the autoconf manual, but the recommendation (run autoupdate) doesn't fix the problem. What do we have to do to our configure.in to fix the problem? -- - Jason Anthony's Law of Force: Don't force it; get a larger hammer.
Re: Site Macro Directory
Mark D. Roth wrote: Does this work for everyone? Works for me. Also, I would say that for now there should not be a site macro directory unless the autoconf installer or autoconf user says so. If the feature proves to be popular, we can always change this default. As I mentioned above, I think it would be better for it to check the site macro directory by default, but I can live with it being an option if that's what everyone else prefers. An option to do as you desire should be setup by the autoconf configuration with a switch. The default for that switch would be to not check for the site macro directory. Earnie.
Re: OpenWatcom support
--- John Poltorak [EMAIL PROTECTED] wrote: Is the GNU build system designed specifically for gcc or will it support other compilers such as the newly released Open Watcom ? Isn't Open Watcom Win32 based? If so, the first thing you need for autoconf to work is a minimal POSIX/Bourne system to allow the configure script to work. You can find such a minimal system at http://www.mingw.org/msys.shtml. MinGW is hosted by SourceForge and you can find the files you need to download for MSYS at http://sf.net/projects/mingw. With MSYS you should be able to configure and use your Open Watcom binaries. Earnie. = Earnie Boyd mailto:[EMAIL PROTECTED] --- http://earniesystems.safeshopper.com --- --- Cygwin: POSIX on Windows http://gw32.freeyellow.com/ --- --- Minimalist GNU for Windows http://www.mingw.org/ --- __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: Why does c++ use CFLAGS and not
Try CXXFLAGS instead of CPPFLAGS. Earnie. Dr. David Kirkby wrote: I've got a test is a configure.in which sets CPPFLAGS to what I want, by calling an external programme wx-config. CPPFLAGS=$CPPFLAGS `wx-config --cflags` That works, and if I echo $CPPFLAGS, its value is as expected. However, when a C++ programme (extension .cpp) is compiled using g++, it uses the CFLAGS, not the CPPFLAGS. So no matter what I put in CPPFLAGS, it never propagates to the makefile. Am I supposed to do anything special in the Makefile.am? I just have this: bin_PROGRAMS = checksum checksum_SOURCES = checksum.cpp EXTRA_DIST = README -- Dr. David Kirkby PhD, email: [EMAIL PROTECTED] web page: http://www.david-kirkby.co.uk Amateur radio callsign: G8WRB _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: How do I conditinally make a makefile?
Check the use of SUBDIR in the automake info manual. Earnie. Dr. David Kirkby wrote: Hi, I've an application that has both a command-line and a version with a graphical user interface (GUI). These are located in directories src/non_gui and src/gui. The GUI version should only be built if the option --with-gui is added when running configure. If the user does not add that option, then the GUI version -8- _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: RFC: ./configure or ./config.status --clean
Paul Eggert wrote: Date: Tue, 02 Apr 2002 22:41:50 -0800 From: Dan Kegel [EMAIL PROTECTED] Clearly, one would also want cp --clean. rm --clean would be far more useful. I've often wanted that, usually right after I've removed the wrong thing. (Sorry, Akim, couldn't resist) But, seriously, one could accomplish this with the currently fictions tools `dirsnap' and `dirrestore'. Dirsnap would snapshot a project directory and dirrestore would return the directory to it's original state. Dirsnap could simply be `tar -cf /tmp/foo.tar' and dirrestore could simply be `rm -rf *; tar -xf /tmp/foo.tar'. If you didn't want that, then dirsnap could simply be a saved `ls -R' listing and dirrestore could be an awk script that parses the listing and removes anything that doesn't exist in the list. My point is, there are a number of ways to accomplish the desired result. However, --clean for all tools isn't the correct way to go about it. The only tools needing to know how to clean a project directory are config.status, configure and make. Anyone building projects in the source directory should be convinced to do otherwise. It should be a requirement of configure to refuse to execute in it's parent directory or any directory that isn't empty, without at least a warning should be issued and a confirmation. Exceptions to that could be if files created by configure already exists in the directory. Sorry, I seem to be rambling. But I hope I've made some valid observations/points/suggestions. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: cross-compiling question: static libraries and binaries to different places?
I've always done this with a two stage build Stage 1 is for the build system, Stage 2 is for the targeted host system If my host name is foo and the targeted host is bar then I would do: configure --prefix=/usr --host=foo --build=foo --target=bar make make install make clean rm configcache configure --prefix=/usr --host=bar --build=foo --target=bar make make install DESTDIR=/depot The standards for configure and make are such that this is the only way to accomplish what you want, AFAICS Earnie Dan Kegel wrote: I'm cross-developing I want to build a package that has both static libraries and binaries The binaries should go to the target system; the libraries should stay on the build system What do I pass to configure and to make? If I do configure --build=pentium-unknown-linux --host=@IXIA_K_ARCH-unknown-linux --disable-shared --with-gnu-ld --prefix=/usr make -C IXIA_PORTARCH/src/lib DESTDIR=$(DEST) install the library ends up in the right place (DEST/usr/lib) but the binary ends up in the wrong place (DEST/usr/bin) If instead I do make -C IXIA_PORTARCH/src/lib DESTDIR=$(DEST)/fsimg install the library ends up in the wrong place (DEST/fsimg/usr/lib) but the binary ends up in the right place (DEST/fsimg/usr/bin) What to do? In cross-development environments, is it not supported to have static libraries go to the build system, but binaries go to the target? - Dan _ Do You Yahoo!? Get your free yahoocom address at http://mailyahoocom
Re: Two problems for autoconf(1.NEC SX 2.Cray)
Paul Eggert wrote: Autoconf's goal is to port the application; 'configure' is merely a means to that goal. One of Autoconf's assumptions is that you are trying to write a 'configure' script that is as portable as possible. Autoconf does not (and cannot) check that the shell code that you insert into 'configure' is portable; that has to be your responsibility. But autoconf could supply it's own shell that one could use to execute the configure script. Then the configure script itself would always be portable assuming that the shell itself could build. ;) Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Chances of build success on non-Unix platforms
John Poltorak wrote: Is there any place I can search to find if an app has been succesfully built with autoconf+friends on a non-Unix platform? Yes, www.mingw.org www.cygwin.com I'm thinking of trying to build Tar 1.13 and see refences to DOS but have no way of telling whether they are purely historical, (going back to the last millenium :-) ) or whether there is any likelihood of success nowadays. Is there a tar mailing list around, BTW? Don't know. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: AC_INIT translates PACKAGE to lower case
Ralf Corsepius wrote: BTW, I would appreciate the other autoconf and automake maintainers to speak up, because apparently a reasonable discussion between Akim and me doesn't seem to be possible anymore. First let me say that IANAAM (I Am Not An Autoconf Maintainer) but I'm going to give my opinion anyway. I agree with your intent Ralf. But let's stand back and look at what we have. 1) Autoconf is a tool for configuration purposes to help decide what features an environment has or doesn't have and supply values for substitution from the Makefile.in files and create Makefile files. 2) Automake is a tool for configuration purposes to help create the Makefile.in(s) that autoconf uses to create the Makefile(s). 3) Automake is wholly dependent on autoconf and must live within the bounds with which autoconf places on it. 4) Given rule 3, autoconf is in it's rights to implement new features that might break backward compatibility with automake. 5) Give rule 4, it is therefore automake not autoconf that needs to provide for the distribution package name since it is automake that creates the Makefile.in. Conclusion, Akim is very patronizing in offering the fourth optional parameter in AC_INIT. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: cmp in test scripts
Tim Van Holder wrote: On Fri, 2002-01-25 at 02:09, Earnie Boyd wrote: John Poltorak wrote: On Thu, Jan 24, 2002 at 06:00:36PM -0500, Earnie Boyd wrote: John Poltorak wrote: Is there any way that autoconf can be used to handle cmp in test scripts? Occasionally a test will fail because of the use of cmp to test differences between generated data and expected results due to line termination on DOS filesystems. If diff is used instead the test may succeed. What I'd like to see is some check to see if the use of cmp is valid and if not then maybe set CMP=diff ... What shell are you using on the DOS filesystem? A properly ported cmp would be a better solution. What relevance does the shell have? Worlds of difference. A properly ported shell might eliminate the concern for a properly ported cmp. Are you talking strictly MSDOS or are you talking COMMAND.COM/CMD.EXE or are you talking UWIN or are you talking CYGWIN or are you talking ... A shell has absolutely NOTHING to do with how a program reads a file. Ok, I'll give you that one, I should have referenced the runtime. I'm guessing from other posts that the runtime is OS/2 but I'm assuming. hello, world\n is longer on a DOS filesystem than on Unix so cmp will distinguish between whereas diff won't. No it isn't. hello, world\n is the same size in both worlds. hello, world\r\n is the same size in both worlds. A properly ported cmp would be a better method. It IS properly ported. cmp is supposed to compare file DATA (on a per-byte basis). As such it HAS to distinguish between DOS text, Mac text and Unix text (and whatever other forms are there), because the FILES differ. 'diff' on the other hand, is supposed to show differences in a file's CONTENTS, which is a higher-level concept. For it, text is text, and line endings don't necessarily have to count as different. As such, diff (or diff -a, if that's a portable option) is better at determining difference between text files than cmp. I agree with everything you've said except for suggesting diff as a better solution than cmp and that the problem resides with autoconf. The problem as you pointed out isn't cmp. The problem is the files of reference. It is often customary to need to convert from unix line endings to dos line endings and vice versa before operating on files from the differing platforms so the burden is still yours. You may want to consider modifying the program that's creating the files you're comparing to open files in what is known as `binary mode' so that the \r isn't prepended to the \n when writing the file. I speak from experience. I know that the problem can be rectified from the user side. I use autoconf and friends on a DOSISH platform daily. You need to find where the real problem resides. You need to stop the \r\n garbage from being generated. It can be done. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: cmp in test scripts
John Poltorak wrote: Is there any way that autoconf can be used to handle cmp in test scripts? Occasionally a test will fail because of the use of cmp to test differences between generated data and expected results due to line termination on DOS filesystems. If diff is used instead the test may succeed. What I'd like to see is some check to see if the use of cmp is valid and if not then maybe set CMP=diff ... What shell are you using on the DOS filesystem? A properly ported cmp would be a better solution. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: cmp in test scripts
John Poltorak wrote: On Thu, Jan 24, 2002 at 06:00:36PM -0500, Earnie Boyd wrote: John Poltorak wrote: Is there any way that autoconf can be used to handle cmp in test scripts? Occasionally a test will fail because of the use of cmp to test differences between generated data and expected results due to line termination on DOS filesystems. If diff is used instead the test may succeed. What I'd like to see is some check to see if the use of cmp is valid and if not then maybe set CMP=diff ... What shell are you using on the DOS filesystem? A properly ported cmp would be a better solution. What relevance does the shell have? Worlds of difference. A properly ported shell might eliminate the concern for a properly ported cmp. Are you talking strictly MSDOS or are you talking COMMAND.COM/CMD.EXE or are you talking UWIN or are you talking CYGWIN or are you talking ... hello, world\n is longer on a DOS filesystem than on Unix so cmp will distinguish between whereas diff won't. No it isn't. hello, world\n is the same size in both worlds. hello, world\r\n is the same size in both worlds. A properly ported cmp would be a better method. You're problem isn't an autoconf problem, it's a tool problem. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Is config.guess generated from some auto tool
Lars J. Aas wrote: On Tue, Dec 18, 2001 at 11:25:09PM +, Sergio wrote: : Hi there. : : Sorry for the basic question but i cant find in faq(s)or manuals the : origin of config.guess. config.guess and config.sub are developed separately. You can find them in ftp://ftp.gnu.org/gnu/config/ Or use automake --add-missing Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf: _m4_divert_diversion
Joe Foxton wrote: I'm trying to build the PHP source on Cygwin with an extension. Heres the end of the output I get when I run buildconf. rebuilding configure ./aclocal.m4:814: error: m4_defn: undefined: _m4_divert_diversion ./aclocal.m4:360: PHP_SUBST is expanded from... ./aclocal.m4:814: the top level rebuilding main/php_config.h.in autoheader: error: shell error while sourcing /tmp/ah976/traces.sh I've seen these when converting from autoconf 2.13 to 2.52. Is there a reason why you're needing to run autoconf on an existing package? Or does the Makefile that's created do that for you? I'm an absolute amateur in all things automake/autoconf. I've been told to try downgrading to autoconf 2.50 (which didn't make a lick of difference), and I am running automake 1.5. If you were told to downgrade, whom ever told you to do that must have meant to downgrade to autoconf-2.13 and automake-1.4. Downgrading to 2.50 isn't recommended by people in the know. Any help would be very much appreciated. Use version autoconf-2.52 and automake-1.5. Look for a directory containing .m4 files other than aclocal.m4 (I don't know your package so I don't know if there is one). aclocal -I directory with .m4 files autoheader automake autoconf If you still get the error, then ask the package maintainers where the m4 functions are defined because they're not in the package. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
bash-2.05a - possible autoconf considerations
quote cc. `printf', `echo -e', and the $'...' code now process only two hex digits after a `\x' escape sequence for compatibility with other shells, and the documentation was changed to note that the octal and hex escape sequences result in an eight-bit value rather than strict ASCII. /quote The above quote was posted on the Cygwin mailing list by Chet Ramey the bash maintainer. IIRC, there was discussion prior to 2.50 release concerning these. -- Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Autotools conformance parser
Anyone know of a tool or methods in use to parse for package configuration standards as expected by the tools? There seem to be many variations and it would be a nice to have a parser to give deviation from standard reports. -- Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Functions / satellite scripts (Was: bison-1.29c 'configure' problems on Solaris 8.)
Paul Eggert wrote: I think this idea is a blind alley. If we want to use modern shell features, then we should go ahead and require the configure user to have a modern shell. That's much simpler. We've already started down that path with the LINENO changes. Wouldn't this be solvable by autoconf supplying it's own Shell executable? Let's see...uhm...autosh sounds like a good name. It wouldn't need to be interactive friendly so perhaps a starting point would be the old Linux ash shell. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Repost: AC_CONFIG_SUBDIRS problem
David Snopek wrote: I really need some assistance with this problem, so here is a re-explanation. Here is my directory tree: project/ | |- configure |- configure.in |- src/ | | | ... | |- main.cpp ... | |- libltdl/ | ... |- configure.in |- configure |- ltdl.c This is an over simplification, but you get the idea. The main configure script has a line like AC_CONFIG_SUBDIRS(libltdl). This works in most situations, when I am just passing --enable/--disable arguments to configure. But when I pass a build type for example: ./configure --build=i386-mingw32msvc Are you using Cygwin or are you cross compiling using Linux? It appears to me as if you've used the wrong switch, you want --target not --build. I may be wrong, I've never cross compiled. If you're using Cygwin you need to: CC='gcc -mno-cygwin' configure --host=mingw32 --build=mingw32 --target=mingw32 Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Functions / satellite scripts (Was: bison-1.29c 'configure' problems on Solaris 8.)
Lars J. Aas wrote: On Mon, Oct 22, 2001 at 08:18:13AM -0400, Earnie Boyd wrote: : Paul Eggert wrote: : I think this idea is a blind alley. If we want to use modern shell : features, then we should go ahead and require the configure user to : have a modern shell. That's much simpler. We've already started down : that path with the LINENO changes. : : Wouldn't this be solvable by autoconf supplying it's own Shell : executable? Let's see...uhm...autosh sounds like a good name. It : wouldn't need to be interactive friendly so perhaps a starting point : would be the old Linux ash shell. Then you can only use Autoconf on systems with C compilers. If that wasn't the case, I would be all for this :) How many systems with Bourne compliant shells don't have a C compiler? How many systems without GNU m4 that need to build it? IMNSHO a C compiler should be a requirement of autoconf even if C isn't the language being autoconfigured. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Autoconf, DOS and NT (was Ebcdic rule)
Paul Eggert wrote: From: Mike Castle [EMAIL PROTECTED] Date: Thu, 4 Oct 2001 12:40:50 -0700 Does that mean that autoconf should limit itself to the POSIX portable file name character set? Of course. If Autoconf uses non-POSIX file names (other than as part of a test for file name portability, or after such a test succeeds), then that is a portability bug that should get fixed. And when I was getting to like Autoconf. Now I'll have to fork it to get my needs for portability met. Way to go, Paul. ;^D Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: configure busybox
Glenn McGrath wrote: Hi, im trying to make a project im involved with (http://busybox.lineo.com/) more portable, specifically i want to make it compile under GNU/Hurd as well as linux. My initial thoughts were that autotools would be ideal, but busybox is an unusal project and im unsure how to go about it. Busybox is a single binary that can provide the funcionality of one of about 130 (i think) general unix commands. Current build process goes roughly as follows, there is a manually edited config file (Config.h, not to be confused with the autotools config.h) that Since you're worried about portability then let me warn against using file names that differ only in case. This won't work well with file systems that are case insensitive. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Portability of find(1)
Akim Demaille wrote:
Hi People!
I'm looking for information on the portability of find(1). Please,
send me everything you know. In particular, I think I'm understanding
that `{}' is portably replaced by the argument only when alone, i.e.,
exactly
find ... {} ...
and not
find ... foo: \{\} ...
At least on DU.
find . -name \*foo -exec echo \{\} {} \;
gives
\{\} somefile-foo
on Cygwin and
\{\} {}
on HP-UX 10.20 and HP-UX 11.
Earnie.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: times ?!
Tim Van Holder wrote: For some reason, the generated tests/testsuite contains times at-times all over the place. What is times? I can't find it, and it isn't a /bin/sh builtin.. I think it's a bash builtin which reports the elapsed time of all processes in the current shell. I'm not sure if other shells have similar commands. Maybe autotest should test for this: at_times=: times /dev/null 21 times=at_times ... $at_times at-times Shouldn't that be time and not times for portability? Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Default values for infodir and mandir [WAS: Re: [autoconf] doc dirs?]
Rüdiger Kuhlmann wrote:
Hi!
-8-
AC_SUBST([infodir],['${prefix}/info'])dnl
+AC_SUBST([docdir], ['${datadir}/doc'])dnl
AC_SUBST([mandir], ['${prefix}/man'])dnl
In my simplistic mind having three places for documentation isn't
logical. I can understand leaving switches for infodir and mandir in
place for backward compatibility but shouldn't there values default to
['$(docdir)/info'] and ['$(docdir)/man'] instead. IIRC this is what the
FHS recommends.
--
Earnie.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: gcc -mno-cygwin and autoconf 2.50
Teun Burgers wrote: Tim Van Holder wrote: Of course, if you need to specify CC anyway, you might as well specify your host system too: ./configure CC='gcc -mno-cygwin' --host=i386-pc-mingw32 After all, you're basically cross-compiling, aren't you. Earnie Boyd wrote: This is the correct way to do it. You can shorten to --host=mingw32 if you wish. I agree that this is basically a cross-compile. It is however just a little bit annoying to specify the target OS twice, with --host and -mno-cygwin. You may be annoyed but you're only specifying the target OS once. So I decided to add the following bit to the configure script: So you've readded what was removed from autoconf in the first place. The better option if you don't want to specify -mno-cygwin and --host=mingw32 is to create a true Cygwin hosted mingw cross compiler. I.E. Configure GCC --host=i686-pc-cygwin --build=i686-pc-cygwin --target=mingw32. -- Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: cygwin libtool breakage
Robert Collins wrote: I _did_ have autoconf CVS HEAD at one point, I reverted to 2.13 to be in line with other users, and I haven't upgraded again yet. I don't recall this problem from back then.. if that helps at all :] Rob Hi Robert, Don't know if you follow the autoconf list but you might give the google.com a try with this http://www.google.com/search?hl=enlr=safe=offq=AC_EXEEXT+2001+site%3Agnu.org -- Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf auxdir
Alexandre Oliva wrote: On Apr 12, 2001, Akim Demaille [EMAIL PROTECTED] wrote: aux means nothing and is not portable. auxdir is puke puke puke Agreed. I still like AC_CONFIG_SUPDIR better than AC_CONFIG_CONFIGDIR or AC_CONFIG_CFGDIR. I do too. Akim has already given examples of where the auxiliary directory is used for more than just autoconfiguration so IMHO promoting config/ isn't a fair use of the function. If you want to promote $ac_config_supdir/config/ as the directory of choice for autoconfiguration files then that is fair use and I would promote that use. I chose the SUPDIR name based on the denotation of auxiliary so that it would fit the original intention of use. IMNSHO, I believe that CONFIGDIR or CFGDIR is changing the intended use. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf auxdir
Akim Demaille wrote: "Earnie" == Earnie Boyd [EMAIL PROTECTED] writes: Earnie Alexandre Oliva wrote: On Apr 12, 2001, Akim Demaille [EMAIL PROTECTED] wrote: aux means nothing and is not portable. auxdir is puke puke puke Agreed. I still like AC_CONFIG_SUPDIR better than AC_CONFIG_CONFIGDIR or AC_CONFIG_CFGDIR. Earnie I do too. Akim has already given examples of where the Earnie auxiliary directory is used for more than just Earnie autoconfiguration so IMHO promoting config/ isn't a fair use Earnie of the function. If you want to promote Earnie $ac_config_supdir/config/ as the directory of choice for Earnie autoconfiguration files then that is fair use and I would Earnie promote that use. Hm, I think I'm lost, or we don't talk about the same thing. I'd like to promote config/ as the common AC_CONFIG_AUX_DIR, i.e., using your vocabulary, $ac_config_supdir (which will remain as $ac_config_auxdir for backward compatibility) _is_ config. Yes, we're talking about the same thing. I think promoting the use of config/ for autoconfiguration files is a good thing but not as the default of AC_CONFIG_AUX_DIR but rather in relation to the value of it. Earnie I chose the SUPDIR name based on the denotation of auxiliary Earnie so that it would fit the original intention of use. IMNSHO, I Earnie believe that CONFIGDIR or CFGDIR is changing the intended use. Are we talking about the same thing? I'm referring to where mkinstalldirs, config.guess, etc. will be instead of the top level... Yes I understand that. However I can use AC_CONFIG_AUX_DIR for support and supplemental files that have no relation to autoconfiguration. The config/ rightly suggest that the directory contains only autoconfiguration files. So I'm suggesting that $ac_config_auxdir/config/ is appropriate. I.E.: AC_CONFIG_AUX_DIR(support) means that ./support/config/ contains the configuration files if the directory exists otherwise ./support contains them. AC_CONFIG_AUX_DIR() or not specified means that ./config/ contains the configuration files if the directory exists otherwise ./ contains them. NOTE: . is equivalent to SRCDIR. Hmm..., we've switched subjects here; in light of this I think that AC_CONFIG_SUPDIR is a better name for the directory than AC_CONFIG_CFGDIR. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf auxdir
Alexandre Oliva wrote: On Apr 10, 2001, Akim Demaille [EMAIL PROTECTED] wrote: PS/ I would like to know why sometimes we end up with ``Earnie Boyd [EMAIL PROTECTED]'' in the CC. That's from Earnie's Reply-To: Right. I set the Reply-To that way to help the blind not add my email address back into the distribution. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Release next week?
Akim Demaille wrote: "Ralf" == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf Akim Demaille wrote: Let's flush all the documentation related patches, Lars' cleanups, and target an actual release next week. Ralf I am in favor for letting autoconf-2.50 be preceeded by a at Ralf least 4 weeks long "code-freeze", "inevitable bug-fixes only" Ralf and "no new features/cleanups" phase. Releasing it next week Ralf would mean to push it, IMHO. The thing is, we have already done this. No real patch gets in. Nobody complains about the betas. And no one use them. Let's face it, the only means to have feedback on Autoconf is to release it and be ready to release another one within a month. Release early, release often. I agree. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf auxdir
Alexandre Oliva wrote: On Apr 10, 2001, "Tim Van Holder" [EMAIL PROTECTED] wrote: On Tue, Apr 10, 2001 at 11:39:19AM +0200, Akim Demaille wrote: : How about AC_CONFIG_CONFIG_DIR? AC_CONFIG_SCRIPT_DIR, AC_CONFIG_EXTRA_DIR, AC_CONFIG_STUFF_DIR, AC_CONFIG_LIB_DIR, AC_CONFIG_CONF_DIR... "CONFIG_CONFIG" seems a bit strange. And the original point was also o be consistent with *_SRCDIR (no _ before DIR). So AC_CONFIG_CFGDIR? I like better AC_CONFIG_SUPDIR, as suggested by Earnie. The ambiguity is perfect :-) Ditto. ;) Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf auxdir
"Lars J. Aas" wrote: 1) I've become quite a fan of using the AC_CONFIG_AUX_DIR macro, and I wouldn't mind if one was set up in Autoconf too. Are there good reasons for not setting one up? Don't know. 2) We ought to unify the way these macros are named: AC_CONFIG_AUX_DIR AC_CONFIG_SRCDIR One ought to change and be AU_DEFUN'ed, and sooner rather than later IMO (before 2.50). Any opinions on this? Any other such convention- breaking names in the package? I agree that they should be the same format. However, I want to complain about the name of AC_CONFIG_AUX_DIR (the AUX part). This leads developers and maintainers to choose aux as a directory name and that isn't portable to all platforms (Primarily Win32). I would like to lobby a name change from AC_CONFIG_AUX_DIR to AC_CONFIG_SUPDIR. The SUP would be for either SUPplementary or SUPport which I obtained from the definition of auxiliary. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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
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
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
Re: Detecting the need for -mwin32 in newer cygwin gcc's
Alexandre Oliva wrote: On Mar 8, 2001, "Charles S. Wilson" [EMAIL PROTECTED] wrote: So, by absorbing AC_PROG_GCC_USES_MWIN32, are you helping the GPL half, or the proprietary half? By refusing to absorb it, are you hurting the proprietary half, or the GPL half? Both, of course. Which is more important? Autoconf is about portability across multiple platforms. If you depend on MS-Windows proprietary libraries, there's not much hope for portability. So, why use autoconf, in the first place? If you don't depend on MS-Windows proprietary libraries, then there's no reason for -mwin32. Or am I missing something about the effects of this new -mwin32 flag? I don't think you're missing a thing and I agree with you. It doesn't belong in autocoonf. This is a platform dependent issue that should be handled in the platform dependent coding of Makefile.in and/or configure.in. The application maintainer/porter knows that the -mwin32 switch is needed and can make certain it gets added to CC or CFLAGS and CXXFLAGS under the appropriate conditions. I can't even understand how such a macro fits Autoconf. I may need it and I may not need it but Autoconf can't determine my needs it can only determine what I have. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Rename atomicity
Mike Castle wrote: On Tue, Mar 06, 2001 at 05:51:45PM +0100, Assar Westerlund wrote: Mike Castle [EMAIL PROTECTED] writes: NT. (NT will happily rename() across disks, hardly an atomic operation). What rename() is that? It's not the one in their posix library I assume? Is there a rename function in any of the ordinary set of libraries. Well, I was mostly considering the rename() function supplied with vendor libraries. Ie, Borland and MS products. I would suppose that autoconf would attempt to support those products as well. As far as the Cygwin stuff goes, I would have to defer to others. Otherwise I'd have to search the source. The underlying code uses the Win32 API MoveFile or MoveFileEx depending on NT or 9x/ME. According to msdn.microsoft.com: The MoveFile function will move (rename) either a file or a directory (including its children) either in the same directory or across directories. The one caveat is that the MoveFile function will fail on directory moves when the destination is on a different volume. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: autoconf 2.49c fails if '.' is in PATH
Akim Demaille wrote: Alexandre Oliva [EMAIL PROTECTED] writes: On Feb 3, 2001, Akim Demaille [EMAIL PROTECTED] wrote: The question is `is $FILE an executable in the common sense'. I think the best thing to do is to just ignore the issue of whether the found executable is a directory while testing -x or -f, and test for -d later on, notifying the user and possibly aborting. This second test might have false positives on Cygwin if x/ and x.exe exist, but I really don't care. I'd rather warn the user that something bad is about to happen. As a data point to support this choice, directories aren't generally skipped when searching the PATH. So why should we? What do you mean? /tmp % mkdir executable nostromo 17:43 /tmp % PATH=/tmp which executablenostromo 17:43 executable not found /tmp % which -a whichnostromo Err 1 which: shell built-in command /usr/bin/which /tmp % PATH=/tmp /usr/bin/which executable nostromo 17:44 /tmp/executable Arg... Is this really good? Are there any other PATH walking programs behaving like this? Is this behavior due to the hash cache? What if you rehash or hash -r? Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: hardcoded prefix in aclocal
Brian Cameron wrote:
Autoconf team:
I notice that the bin/aclocal script has the following two lines:
$prefix = "/hardcoded/install/directory";
$acdir = "${prefix}/share/aclocal";
The "$acdir" is used to find config files that may be installed by
other packages.
This creates a problem in our environment...
We have each package (autoconf, gettext, and libtool) are installed
in each directory. Then we are using a program that makes a single
directory tree with symbolic links to the various installed programs.
So our system looks like this
automake is installed in /install/automake
gettext is installed in /install/gettext
libtool is installed in /install/libtool
You want to
configure --prefix=/usr/local
make
make install prefix=/install/automake
Earnie.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: GNATS needs some work (autoconf/59)
Akim Demaille wrote: "Tim" == Tim Van Holder [EMAIL PROTECTED] writes: Tim I suppose so. My main point was that there were 2 different Tim issues related to path separators (build _HOST_), which the PR Tim didn't seem to take into account. Personally, at least for the time being, we don't care about HOST: as said by Pavel, only specific packages will need it, and they certainly need it so badly that they already perform their tests. And if they don't, the simple fact that Autoconf supports some HOST-path-sep test will not make these package HOST-path-sep aware. So let's drop this. But BUILD-path-sep *does* matter, and will be a significant win. [suggested test snipped] Tim I suppose this would be a better way to do it (or rather, the Tim Demaillator Edition of this test :-) ). :) :) :) Tim I'll try this out on DJGPP and Cygwin bashes and whip up a patch Tim if it works. Could you describe precisely how it works? In fact, may I ask you to complete the documentation of PATH in autoconf.texi to explain how it works on Cygwin and DJGPP? Maybe Earnie would have good hints to give. Because I seem to have understood we kinda can have ; or : as a PATH sep on Cygwin. But then, the test suggested above might not be right, since we will have to adjust ourselves to the choice made by the user. Autoconf by itself does not care extending PATH, it wants to be able *split* it. PATH for Cygwin isn't a problem. Cygwin adjusts the PATH to be POSIX compliant even if executed from the DOS command.com/cmd.exe shells. PATH will be a problem for MinGW if Amol's ZSH port is used for the Bourne compatible shell. The multipath separator will then need to be a ';'. If we introduce some other shell, for which I haven't even tried, there may be problems with even finding the PATH variable as Win32 usually names it Path and environment variables are case sensitive. Amol, in his ZSH port, ensures that the variable is named PATH; however, other shell ports may not be so wise. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
