Re: autoconf test ': >emtpy' problem under Ultrix
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >> Anyway, we really need to know how to create portably empty files, >> we use it at other places IIRC. Alexandre> Do we? A quick grep didn't show any such place. Alexandre> IIRC, there are filesystems that don't support zero-sized Alexandre> files. ISTR that for a time we believed AIX was one such FS, but it has never been demonstrated. What platform are you thinking about?
Re: Announcing Autoconf 2.49d
> "John" == John Poltorak <[EMAIL PROTECTED]> writes: John> This sounds more promising than the last time I tried... But I John> noticed it didn't find INSTALL, PERL or much else on the path. John> I am using OS/2 which uses DOS paths and seperators, and drive John> letters. Should I expect the path to be searched for sundry John> support files? Support for DOS and OS/2 is not yet complete. You'll have to help it. For a start, can you provide us with Autoconf's config.log.
Re: Announcing Autoconf 2.49d
> "Thomas" == Thomas Dickey <[EMAIL PROTECTED]> writes: Thomas> When I generate the Makefile.in's using automake 1.4, there Thomas> are a number of syntax errors (which also appeared in the Thomas> 2.49c and I recall being reported). I don't remember. Thomas> I don't see anything in the package which indicates this is Thomas> dependent on one of the alpha versions of automake. We are using a _fixed_ 1.4, as is distributed by Debian. automake (1.4-5) unstable; urgency=low * add postrm to remove entry in info page * fixed problem with EXTRA_DIST including a directory which is not installed (closes: #39436). * fixed problem with incorrect error message when running "automake --verbose --copy --add-missing --foreign" (closes: #46206). -- Kevin Dalley <[EMAIL PROTECTED]> Sun, 31 Oct 1999 07:32:56 -0800 automake (1.4-4) unstable; urgency=low * fixed problem with installation of info files (closes: #48757) -- Kevin Dalley <[EMAIL PROTECTED]> Sat, 30 Oct 1999 17:00:59 -0700 automake (1.4-3) unstable; urgency=low * Do not install INSTALL (closes: #36548). * updated config.{guess,sub} from automake cvs (closes: #48131). * update to Standards-Version 2.5.0.0 -- Kevin Dalley <[EMAIL PROTECTED]> Sat, 30 Oct 1999 10:57:06 -0700 automake (1.4-2) unstable; urgency=low * This patch allows the proper use and detection of alphapca56 machines. Debian Alpha needs this. (fixes bug #32390). -- Kevin Dalley <[EMAIL PROTECTED]> Sat, 30 Jan 1999 14:49:29 -0800 automake (1.4-1) unstable; urgency=low * first release of automake-1.4, which includes support for latest autoconf, fixes a number of bugs -- Kevin Dalley <[EMAIL PROTECTED]> Sat, 16 Jan 1999 14:26:53 -0800
Re: Announcing Autoconf 2.49d
On Tue, Mar 20, 2001 at 10:22:35AM +0100, Akim Demaille wrote: > > "John" == John Poltorak <[EMAIL PROTECTED]> writes: > > John> This sounds more promising than the last time I tried... But I > John> noticed it didn't find INSTALL, PERL or much else on the path. > > John> I am using OS/2 which uses DOS paths and seperators, and drive > John> letters. Should I expect the path to be searched for sundry > John> support files? > > Support for DOS and OS/2 is not yet complete. Couldn't any support for OS/2 fall in line with Win32 support? They are identical as far as paths are concerned, ie. use of drive letters, path seperators, and use of '\' instead of '/'. > You'll have to help it. > For a start, can you provide us with Autoconf's config.log. ## -- ## ## Platform. ## ## -- ## hostname = workpad uname -m = i386 uname -r = 2 uname -s = OS/2 uname -v = 2.45 configure.:826: creating cache /dev/null configure.:884: PATH=".;."; conftest.sh configure.:887: $? = 0 Most of the results from tests showed either 'missing' or 'no' -- John
Re: Announcing Autoconf 2.49d
| On Tue, Mar 20, 2001 at 10:22:35AM +0100, Akim Demaille wrote: | > > "John" == John Poltorak <[EMAIL PROTECTED]> writes: | > | > John> This sounds more promising than the last time I tried... But I | > John> noticed it didn't find INSTALL, PERL or much else on the path. | > | > John> I am using OS/2 which uses DOS paths and seperators, and drive | > John> letters. Should I expect the path to be searched for sundry | > John> support files? | > | > Support for DOS and OS/2 is not yet complete. | | Couldn't any support for OS/2 fall in line with Win32 support? | They are identical as far as paths are concerned, ie. use of drive | letters, path seperators, and use of '\' instead of '/'. We need people to work on it. Please, send patches. | > You'll have to help it. | > For a start, can you provide us with Autoconf's config.log. | | | ## -- ## | ## Platform. ## | ## -- ## | | hostname = workpad | uname -m = i386 | uname -r = 2 | uname -s = OS/2 | uname -v = 2.45 | | configure.:826: creating cache /dev/null | configure.:884: PATH=".;."; conftest.sh | configure.:887: $? = 0 | | Most of the results from tests showed either 'missing' or 'no' Thanks, that's very helping...
Re: autoconf test ': >emtpy' problem under Ultrix
On Mar 20, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote: >> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> IIRC, there are filesystems that don't support zero-sized Alexandre> files. > ISTR that for a time we believed AIX was one such FS, but it has never > been demonstrated. What platform are you thinking about? Hmm... Well, I recall things such as: C> copy con foo.txt ^Z failing on MS-DOS. But it may be that it's not a problem in the FS, but in copy. Anyway, automake uses `echo timestamp > file', instead of touch, and I've always thought the reason was to avoid having an empty file. OTOH, I've abused emoticons such as `: >' in the Samba Makefiles, and I don't recall anybody having reported problems with it. Maybe this is just portability myth... I wouldn't mind having the testsuite failing in case an empty file can't be created, but I'd be very concerned if autoconf or configure scripts generated by it depended on this ability, for now. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist*Please* write to mailing lists, not to me
Re: autoconf test ': >emtpy' problem under Ultrix
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> I wouldn't mind having the testsuite failing in case an Alexandre> empty file can't be created, but I'd be very concerned if Alexandre> autoconf or configure scripts generated by it depended on Alexandre> this ability, for now. The only place where it really matters is confdefs.h, and there, we can't use an empty file because some CPP would fail. So I think we are clear.
Re: Status of 2.50
On Mon, Mar 19, 2001 at 07:36:11PM +0100, Akim Demaille wrote: : There is something which is extremely important, and I think Lars can : help us on this issue: compatibility with Libtool. Lars Hecking, I presume? : I'm almost sure 1.3.5 and before did things that drive 2.50 crazy. I use 1.3.5, and don't have any problem with it except that I need to add AC_CANONICAL_ to configure.in for AC_PROG_LIBTOOL to work. At least that's how it was once - I haven't tried removing those macros since I found out they were needed. Lars J
Re: Status of 2.50
Lars J. Aas writes: > On Mon, Mar 19, 2001 at 07:36:11PM +0100, Akim Demaille wrote: > : There is something which is extremely important, and I think Lars can > : help us on this issue: compatibility with Libtool. > > Lars Hecking, I presume? I don't think so ;-)
Re: Status of 2.50
On Tue, Mar 20, 2001 at 12:53:49PM +, Lars Hecking wrote: : Lars J. Aas writes: : > On Mon, Mar 19, 2001 at 07:36:11PM +0100, Akim Demaille wrote: : > : There is something which is extremely important, and I think Lars can : > : help us on this issue: compatibility with Libtool. : > : > Lars Hecking, I presume? : : I don't think so ;-) Hmm, who else is there? Lars J
Re: Status of 2.50
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> On Mon, Mar 19, 2001 at 07:36:11PM +0100, Akim Demaille wrote: : > There is something which is extremely important, and I think > Lars can help us on this issue: compatibility with Libtool. Lars> Lars Hecking, I presume? I was thinking about you, sorry for the confusion... > I'm almost sure 1.3.5 and before did things that drive 2.50 crazy. Lars> I use 1.3.5, and don't have any problem with it except that I Lars> need to add AC_CANONICAL_ to configure.in for Lars> AC_PROG_LIBTOOL to work. This is an important piece of information! Thanks, I'll adjust the test suite then.
Re: autoconf test ': >emtpy' problem under Ultrix
Alexandre Oliva writes: > Anyway, automake uses `echo timestamp > file', instead of touch, and > I've always thought the reason was to avoid having an empty file. The reason (which is documented somewhere in the auto* manuals) is that on some (BSD?) systems a 'touch' of an empty file doesn't update the time stamp. So in a way, yes, you're avoiding empty files, but it is only necessary in 'make' context. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: autoconf test ': >emtpy' problem under Ultrix
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes: Peter> Alexandre Oliva writes: >> Anyway, automake uses `echo timestamp > file', instead of touch, >> and I've always thought the reason was to avoid having an empty >> file. Peter> The reason (which is documented somewhere in the auto* manuals) I don't know where. Peter> is that on some (BSD?) systems a 'touch' of an empty file Peter> doesn't update the time stamp. So in a way, yes, you're Peter> avoiding empty files, but it is only necessary in 'make' Peter> context. If someone could specify an actual system like this, I'd be happy to update autoconf.texi.
Re: autoconf test ': >emtpy' problem under Ultrix
Akim Demaille writes: > Peter> The reason (which is documented somewhere in the auto* manuals) > > I don't know where. autoconf.texi @node Automatic Remaking, , Build Directories, Makefile Substitutions @subsection Automatic Remaking [snip] The @file{stamp-} files are necessary because the timestamps of @file{config.h.in} and @file{config.h} will not be changed if remaking them does not change their contents. This feature avoids unnecessary recompilation. You should include the file @file{stamp-h.in} your package's distribution, so @code{make} will consider @file{config.h.in} up to date. On some old @sc{bsd} systems, @code{touch} or any command that results in an empty file does not update the timestamps, so use a command like @code{echo} as a workaround. > Peter> is that on some (BSD?) systems a 'touch' of an empty file > Peter> doesn't update the time stamp. So in a way, yes, you're > Peter> avoiding empty files, but it is only necessary in 'make' > Peter> context. > > If someone could specify an actual system like this, I'd be happy to > update autoconf.texi. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: autoconf test ': >emtpy' problem under Ultrix
| Akim Demaille writes: | > Peter> The reason (which is documented somewhere in the auto* manuals) | > | > I don't know where. | | autoconf.texi | | @node Automatic Remaking, , Build Directories, Makefile Substitutions | @subsection Automatic Remaking | | [snip] | | The @file{stamp-} files are necessary because the timestamps of | @file{config.h.in} and @file{config.h} will not be changed if remaking | them does not change their contents. This feature avoids unnecessary | recompilation. You should include the file @file{stamp-h.in} your | package's distribution, so @code{make} will consider @file{config.h.in} | up to date. On some old @sc{bsd} systems, @code{touch} or any command | that results in an empty file does not update the timestamps, so use a | command like @code{echo} as a workaround. Thanks! Do you people think we should continue explaining how to do things without Automake?
Re: autoconf test ': >emtpy' problem under Ultrix
Akim Demaille <[EMAIL PROTECTED]> wrote: | > "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes: | | Peter> Alexandre Oliva writes: | >> Anyway, automake uses `echo timestamp > file', instead of touch, | >> and I've always thought the reason was to avoid having an empty | >> file. | | Peter> The reason (which is documented somewhere in the auto* manuals) | | I don't know where. | | Peter> is that on some (BSD?) systems a 'touch' of an empty file | Peter> doesn't update the time stamp. So in a way, yes, you're | Peter> avoiding empty files, but it is only necessary in 'make' | Peter> context. | | If someone could specify an actual system like this, I'd be happy to | update autoconf.texi. Ok :-) >From fileutils/tests/touch/empty-file: # Make sure touch can set the mtime on an empty file. # Volker Borchert reported that touch 3.16r (and presumably all before that) # fails to work on SunOS 4.1.3 with `most of the recommended patches' when # the empty file is on an NFS-mounted 4.2 volume. Thanks again, Volker.
Re: autoconf test ': >emtpy' problem under Ultrix
Akim Demaille writes: > Do you people think we should continue explaining how to do things > without Automake? I think yes, because otherwise you decrease the overall usability of your product. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: Announcing Autoconf 2.49d
On Tue, Mar 20, 2001 at 11:05:44AM +0100, Akim Demaille wrote: > > | On Tue, Mar 20, 2001 at 10:22:35AM +0100, Akim Demaille wrote: > | > > "John" == John Poltorak <[EMAIL PROTECTED]> writes: > | > > | > John> This sounds more promising than the last time I tried... But I > | > John> noticed it didn't find INSTALL, PERL or much else on the path. > | > > | > John> I am using OS/2 which uses DOS paths and seperators, and drive > | > John> letters. Should I expect the path to be searched for sundry > | > John> support files? > | > > | > Support for DOS and OS/2 is not yet complete. > | > | Couldn't any support for OS/2 fall in line with Win32 support? > | They are identical as far as paths are concerned, ie. use of drive > | letters, path seperators, and use of '\' instead of '/'. > > We need people to work on it. Please, send patches. I was wondering whether configure managed to locate install, perl or any other required tools when running under Cygwin, and if so, how does it do this? -- John
RE: Announcing Autoconf 2.49d
> > > John> I am using OS/2 which uses DOS paths and seperators, and drive > > John> letters. Should I expect the path to be searched for sundry > > John> support files? > > > > Support for DOS and OS/2 is not yet complete. > > Couldn't any support for OS/2 fall in line with Win32 support? > They are identical as far as paths are concerned, ie. use of drive > letters, path seperators, and use of '\' instead of '/'. The problem is that both Cygwin's and DJGPP's bash are able to find foo.exe if given 'test -f foo'. OS/2's shell probably doesn't. If you don't mind autoconf finding directories and thinking they're the programs it wants, you could try adding as_executable_p='test -x' to your config.site; but this assumes OS/2 shell finds foo.exe if given 'test -x foo'. Alternatively, you could write some small batch file or C program that will return 0 if the path name passed to it is executable (albeit with a possible extension added), and set as_executable_p to point to it. A simple example would be: -- is-program.sh #!/bin/sh test -f $1 && exit 0 test -f $1.exe && exit 0 test -f $1.pl && exit 0 test -f $1.bat && exit 0 test -f $1.cmd && exit 0 test -f $1.com && exit 0 -- end of is-program.sh (modify the list to reflect the extension you want to consider) When as_executable_p is set to point to this script, configure will call it each time it tries to determine whether a program is available. I'm planning on adding support for system-defined executable extensions to 2.51, so all these problems will probably go away then (provided there is a clean way to determine what extensions should be checked).
toner supplies
PLEASE FORWARD TO THE PERSON RESPONSIBLE FOR PURCHASING YOUR LASER PRINTER SUPPLIES VORTEX SUPPLIES -SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES-- LASER PRINTER TONER CARTRIDGES COPIER AND FAX CARTRIDGES WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY LOW PRICES ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 CUSTOMER SERVICE: 1-888-248-2015 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NO SHIPPING CHARGES FOR ORDERS $49 OR OVER ADD $4.75 FOR ORDERS UNDER $49. C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES. FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE CONTINENTAL U.S. OR FOR CATALOG REQUESTS PLEASE CALL OUR CUSTOMER SERVICE LINE 1-888-248-2015 OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)$44 ITEM #2 LASERJET SERIES 1100 (92A)-$44 ITEM #3 LASERJET SERIES 2 (95A)---$39 ITEM #4 LASERJET SERIES 2P (75A)-$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)--$44 ITEM #6 LASERJET SERIES 5SI, 5000 (29A)--$95 ITEM #7 LASERJET SERIES 2100 (96A)-$74 ITEM #8 LASERJET SERIES 8100 (82X)---$145 ITEM #9 LASERJET SERIES 5L/6L (3906A0--$35 ITEM #10 LASERJET SERIES 4V-$95 ITEM #11 LASERJET SERIES 4000 (27X)-$72 ITEM #12 LASERJET SERIES 3SI/4SI (91A)$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M---$49 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)--$49 ITEM #15 LASERFAX 5000,7000 (FX2)--$54 ITEM #16 LASERFAX (FX3)$59 ITEM #17 LASERFAX (FX4)$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---$89 OPTRA R, 4039, 4049 HIGH YIELD-$105 OPTRA E$59 OPTRA N--$115 OPTRA S--$165 - EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000---$105 ACTION LASER 1000,1500-$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95--$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600$49 LASER WRITER SELECT 300,320,360-$74 LASER WRITER 300 AND 320--$54 LASER WRITER NT, 2NT--$54 LASER WRITER 12/640$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---$59 LASERCLASS 5000,6000,7000 (FX2)-$54 LASERFAX 5000,7000 (FX2)--$54 LASERFAX 8500,9000 (FX4)--$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)-$69 PC 300,320,700,720 and 760 (E-40)$89 IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.
Re: Announcing Autoconf 2.49d
On Tue, Mar 20, 2001 at 06:57:21PM +0100, Tim Van Holder wrote: > > > > > John> I am using OS/2 which uses DOS paths and seperators, and drive > > > John> letters. Should I expect the path to be searched for sundry > > > John> support files? > > > > > > Support for DOS and OS/2 is not yet complete. > > > > Couldn't any support for OS/2 fall in line with Win32 support? > > They are identical as far as paths are concerned, ie. use of drive > > letters, path seperators, and use of '\' instead of '/'. > > The problem is that both Cygwin's and DJGPP's bash are able to find foo.exe > if given 'test -f foo'. This is confusing... According to my test --help... -f FILE FILE exists and is a regular file I don't see why '-f' should search for an executable... > OS/2's shell probably doesn't. No, it doesn't look like it. > If you don't mind autoconf finding directories and thinking they're > the programs it wants, you could try adding > as_executable_p='test -x' > to your config.site; but this assumes OS/2 shell finds foo.exe if given > 'test -x foo'. This doesn't seem to work either, but it may be possible to change. > Alternatively, you could write some small batch file or C program that > will return 0 if the path name passed to it is executable (albeit with > a possible extension added), and set as_executable_p to point to it. > > A simple example would be: > > -- is-program.sh > #!/bin/sh > > test -f $1 && exit 0 > test -f $1.exe && exit 0 > test -f $1.pl && exit 0 > test -f $1.bat && exit 0 > test -f $1.cmd && exit 0 > test -f $1.com && exit 0 > -- end of is-program.sh > (modify the list to reflect the extension you want to consider) > > When as_executable_p is set to point to this script, configure will call > it each time it tries to determine whether a program is available. I guess I can give that a try, although if it's possible to set up the environment in advance, that may be easier... Is there a list of environment variables checked, and utilities required by autoconf? > I'm planning on adding support for system-defined executable extensions > to 2.51, so all these problems will probably go away then (provided there > is a clean way to determine what extensions should be checked). Sounds good! -- John
RE: Announcing Autoconf 2.49d
> This is confusing... > > According to my test --help... > > -f FILE FILE exists and is a regular file > > I don't see why '-f' should search for an executable... DJGPP's bash can have test -f find an executable simply because many Unixy scripts (including autoconf's configure) use -f to find programs along the path. Same goes for Cygwin, i think. My position is that it's the scripts that are broken, and we shouldn't bend over backwards to make them DTRT, but I also agree that until they are fixed, having this to fall back on is a Good Thing(tm). For DJGPP, it's not enabled by default for test -f (you need to set TEST_FINDS_EXE in the environment (I set it in config.site)), but test -x always finds executables. > I guess I can give that a try, although if it's possible to set up > the environment in advance, that may be easier... Of course, but I was just suggesting a kludge to get 2.50 to work for you. Technically, you're not even supposed to set as_executable_p yourself, as it is a variable internal to autoconf.
Autoconf 2.49d test: Command not found
After setting a number of environment variables and running sh ./configure followed by make I got the following error at the end:- make[1]: Leaving directory `/eval/autoconf-2.49d' Making all in m4 make[1]: Entering directory `/eval/autoconf-2.49d/m4' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/eval/autoconf-2.49d/m4' Making all in man make[1]: Entering directory `/eval/autoconf-2.49d/man' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/eval/autoconf-2.49d/man' Making all in doc make[1]: Entering directory `/eval/autoconf-2.49d/doc' make[1]: :: Command not found make[1]: Leaving directory `/eval/autoconf-2.49d/doc' make: *** [all-recursive] Error 1 How do I find out which Command was not found ? -- John