Re: [Autoconf-patches] Support for nested AT_DATA

[Akim Demaille]

| Hello, Akim!
| > I think your patch is wrong.  There is no reason to embed AT_DATA
| > within AT_DATA (or I missed something).  The real problem is your
| > willing to use AT_TEST_MACRO, or, if you prefer, the fact that
| > AT_TEST_MACRO is attractive, but does not suit your needs.  In this
| > case, you'd better use the primitive AT_CHECK macro.
| 
| I agree that creating constant files from configure was not a good idea. I
| was going to put $CPP there, but in this case AT_DATA would not help since
| it doesn't expand shell variables. But I may still want to use my code
| that does expand shell variables, e.g.
| 
| cat >mycpp <<EOF
| 
| #! /bin/sh
| $CPP 'address@hidden'
| exit 0
| EOF
| 
| You see, I would have problems with AT_DATA without actully nesting it. I
| would feel better if something more generic than EOF were used in the
| macro definitions. Maybe pathsubst is indeed an overkill, but why not
| simply use AT_EOF?
| 
| ChangeLog:
|         * tests/atgeneral.m4 (AT_DATA): use AT_EOF instead of EOF.
| ===================
| Index: tests/atgeneral.m4
| --- tests/atgeneral.m4        Mon Sep 18 22:05:04 2000
| +++ tests/atgeneral.m4        Tue Sep 19 10:05:47 2000
| @@ -332,8 +332,8 @@
|  
|  AT_DEFINE(AT_DATA,
|  [AT_DEFINE([AT_data_files], AT_data_files[ ]$1)
| -cat > $1 <<'EOF'
| -$2[]EOF
| +cat > $1 <<'AT_EOF'
| +$2[]AT_EOF
|  ])

I have not understood all the points of your message, but I agree with
your proposal :).  I'll use _ATEOF though, for consistency with
Autoconf, and in provision for an automated generation of testsuite à
la autoconf(1), which would not accept `AT_' in the output.

The thing was that I don't agree to see configure.in use Autotest
code.  I have nothing against configure.in using here docs, but not
thanks to AT_DATA.

I'm applying your patch (BTW, You always display your ChangeLog like
this, but cl2patch doesn't seem to be willing to understand it.  What
am I supposed to do?

Also, Pavel, I'd be really happy if you had a write access to CVS
Autoconf.  I don't remember what failed the last time we talked about
this.