dynamic autotest testsuite options

I'm trying to convert the CVS test suite to use autotest rather than its current homeroll and I was hoping to carry over some of the options that the homeroll accepts into the new testsuite. Is there some way other than converting them into VAR=XXX type options to have testsuite accept them? S

autotest scripts (Autom4te)

Hey, I'm noticing that when Autom4te generates autotest scripts, only the macros in testsuite.at are output. In other words, unlike configure.ac conversion, arbitrary shell snippets are not in the final generated file. Is there a good reason for this? Could I change a single switch in autom4

Re: autotest scripts (Autom4te)

Grzegorz Jakacki wrote: On Sat, 22 Mar 2003, Derek Robert Price wrote: Hey, I'm noticing that when Autom4te generates autotest scripts, only the macros in testsuite.at are output. In other words, unlike configure.ac conversion, arbitrary shell snippets are not in the final generated

Re: dynamic autotest testsuite options

Grzegorz Jakacki wrote: On Fri, 21 Mar 2003, Derek Robert Price wrote: I'm trying to convert the CVS test suite to use autotest rather than its current homeroll and I was hoping to carry over some of the options that the homeroll accepts into the new testsuite. Is there some way other

Autotest scripts

Okay, this is still eluding me after spending several hours reading through the source and I thought I'd double check that I have it right. For some reason, shell snippets I include in the testsuite.at file do no appear in the final output and I still can't figure out why, much less how to chan

Autoshell documentation

Whoops. Sent this to the automake list the first time: Is there a good reason, other than nobody getting around to it yet, that the only Autoshell macros that've been documented are AS_DIRNAME & AS_MKDIR_P? Derek -- *8^) Email: [EMAIL PROTECTED] Get CVS support at

Next release?

Any talk of when the next release of Autoconf will be? I'm reluctant to have CVS depend on an unreleased Autoconf but I really want to use the Autotest changes I've been making. Is the Autoconf release process documented anywhere? Derek -- *8^) Email: [EMAIL PROTECTED] Get CV

AC_HELP_STRING as AS_HELP_STRING?

As I've mentioned, I'm looking into some potential changes for the Autotest stuff. As I'd like to have generated test suites accept arguments which could be set by a macro call in testsuite.at, I was thinking it might be appropriate to move AC_HELP_STRING into AS_HELP_STRING to make it availab

Re: [Bug-gnulib] lstat/stat

Jim Meyering wrote: Regarding this: http://mail.gnu.org/archive/html/bug-gnulib/2003-05/msg00014.html [. . . snip . . .] Do you know if it'd solve the problem to make the prerequisite tests unconditional? Yes, it would. I really hope so, because using cache variable names from other tests m

Running the Darwin preprocessor

Has anyone encountered this on MacOSX? I'm running the pre-Jaguar OSX 10.1 (Darwin kernel 5.5). Autoconf/configure discovers that running the C preprocessor requires `cc -E', but `cc -E' doesn't appear to pass other options through to the C preprocessor (in this case `cpp'). Basically, I was

Re: Running the Darwin preprocessor

Andreas Schwab wrote: Derek Robert Price <[EMAIL PROTECTED]> writes: |> Basically, I was attempting to discover a definition using `cpp -dM' to |> output defined macros, but `cc -E -dM' doesn't work even though `cpp -dM' |> does. Is there some way around this

Re: po directory?

Jose Roman Bilbao wrote: Hi all, Does anybody know what does the po directory store?. I have tried to make make dist and then configure on other machine and It says it can not find po/Makefile.in.in. Is something wrong with my autotools?, Why is it not included when doing make dist?. Thanks I

AC_PROG_CC_O

Could someone tell me why this macro checks both $CC & cc for acceptance of -o and -c? The docs don't really specify and all I can see the macro itself doing is #defining NO_MINUS_C_MINUS_O. I ask because a user configuring CVS on Solaris is complaining that he is set up with CC=gcc and the c

AM_PROG_CC_C_O (was Re: AC_PROG_CC_O and Re: wierd test inconfigureon bug-cvs)

Hey Jim, sorry, I just looked this up and it appears that I reported on the wrong macro (kinda), to the wrong list (kinda), and that there was a reason for it after all. Jim Meyering wrote: I think it was designed to be used mainly in GNU Make's configure.ac file. From the description, you get

Re: Idiom for setting defines

Bill Moseley wrote: I also saw Harlan Stenn's suggestion about using a case statement. If that's a better way to go can someone provide an example? case "$enableval" in no) ;; yes) ;; *) ;; esac Derek -- *8^) Email: [EMAIL PROTECTED] Get CVS support at

Re: [Bug-gnulib] lstat/stat

Derek Robert Price wrote: Index: m4/lstat.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/lstat.m4,v retrieving revision 1.14 diff -u -r1.14 lstat.m4 --- m4/lstat.m431 Dec 2002 13:43:06 -1.14 +++ m4/lstat.m420 Jul 2003 12

Re: [Bug-gnulib] lstat/stat

Jim Meyering wrote: Regarding this: http://mail.gnu.org/archive/html/bug-gnulib/2003-05/msg00014.html Do you know if it'd solve the problem to make the prerequisite tests unconditional? I really hope so, because using cache variable names from other tests makes the code very fragile -- I've

Re: [Bug-gnulib] lstat/stat

Jim Meyering wrote: Derek Robert Price <[EMAIL PROTECTED]> wrote: Did you have an opinion about my tweaks to stat.c? Yes. I liked it and have just made that change. Thanks. I also confirmed that Solaris5.9 still requires the work-around code and added this comment: Also work ar

Re: AC_CONFIG_LIBOBJ_DIR usage

Ralf Wildenhues wrote: $ autoreconf -vis # ... from automake: Makefile.am:3: required file `./strtod.c' not found Maybe because you have referenced LIBOBJS in your top leve Makefile.am, automake assumes it should look for them there? I played with AC_CONFIG_LIBOBJ_DIR and it doesn't seem to h

Re: problem compiling Autoconf-2.57 on RedHat 7.2

Paul Eggert wrote: "* sAn *" <[EMAIL PROTECTED]> writes: "rpm -q autoconf" This sounds like a Red Hat issue, not an Autoconf issue. Autoconf is distributed as source code; Red Hat takes that source code and turns it into RPMs. So you'll need to ask Red Hat. Source RPMs for autoconf 2

Re: AC_CHECK_DECL+autoheader ==> nothing in config.h.in?

Sam Steingold wrote: I put AC_CHECK_DECL(signgam) in configure.in to check for the lgamma() sign indicator. I expected autoheader to place "#undef HAVE_DECL_SIGNGAM" in config.h.in, but it does not do that. Do I _have_ to use the full version, like AC_CHECK_DECL(signgam, AC_DEFINE([HAVE_DECL_SIGNG

Re: AC_CHECK_DECL+autoheader ==> nothing in config.h.in?

Sam Steingold wrote: AC_CHECK_DECLS defines the config.h.in variable automatically. If you want to use AC_CHECK_DECL, yes, you have to use a construct like you mentioned. Thank you very much. what about ? how do I have included during the check for signgam without having to define [ACTION-I

Re: signal handler definition

Richard Bos wrote: Hello, My first question to you: the application's makefiles use a definition called SIGFUNC which must be set manually to void or int depending on the system. Is there a similar autoconf defition (macro) that can be used to do this automatically? Fourth occurance of the

Out of the Office

I will be away from my mail for several days. Your mail regarding: "[SPAM] Lower your payments" is important to me, however, and will be read when I return on Thursday, August 28.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "Gener.ic Cial.is - Your wife will love you for it!" is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "Last all weekend with this new blue pill." is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "Not p.leasing your wife anymore? Try Via.gra!" is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "Last all weekend with this new blue pill." is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "Gener.ic Cia.lis - Lasts 2 times longer then Via.gra!" is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "Gener.ic Cia.lis - Lasts 2 times longer then Via.gra!" is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "How can it be.. BETTER THEN V_IAGRA! open to see." is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "How can it be.. BETTER THEN V_IAGRA! open to see." is important to me, however, and will be read when I return on Monday, January 5th.

Out of the Office

I will be away from my mail for several days. Your mail regarding: "How can it be.. BETTER THEN V_IAGRA! open to see." is important to me, however, and will be read when I return on Monday, January 5th.

Tracking dependencies based on AC_SUBST_FILE

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does it sound like a tough problem to automatically track dependencies created via AC_SUBST_FILE()? Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at ! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.