Autoconf testsuite and cross setups

Let's give developers with uncommon cross setups help for Autoconf
regression testing: The Autoconf testsuite should work as well as
possible with a cross-compilation environment, just like the CVS
Libtool one does.  Likewise TODO for Automake.

The patch below is a first step.  It allows

$ configure_options="--host=i586-mingw32msvc --build=i686-pc-linux-gnu" \
    make check "TESTSUITEFLAGS=FC=no F77=no"

to pass or skip most tests, on my Debian testing system.  I haven't
yet done the mktests-generated tests that fail with this:

201: AC_TRY_RUN (acgeneral.at:32)
288: AC_FUNC_SETPGRP (acfunctions.at:31)

these need to be rewritten manually, and then exempted from mktests.
And then we need documentation for $configure_options -- does anyone
see a nice way to pass variables with spaces through TESTSUITEFLAGS?

(Also, --build, and the $FC and $F77 settings should not be needed
IMHO, but let's defer the more difficult but also more cosmetic
issues for now.)

FYI, these tests are skipped:
115: AC_RUN_IFELSE (compile.at:141)
145: GNU Fortran 77 (fortran.at:33)
146: GNU Fortran (fortran.at:61)
147: AC_F77_MAIN (acfortran.at:12)
148: AC_F77_WRAPPERS (acfortran.at:13)

Re: Autoconf testsuite and cross setups

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> Where should I write documentation beside NEWS?  HACKING
> only would seem a bit thin, no?

Ideally it'd be in the documentation, yes.  Sorry, I don't have a
precise suggestion.

> +AT_CHECK([echo Hello | top_srcdir=$abs_top_srcdir ./configure $configure_options | grep -v
'configure: loading site script '],, [Hello

This always does globbing on $configure_options, which means we can't
reliably support arbitrary characters.  How about doing this instead?

  AT_CHECK([echo Hello | eval "top_srcdir=\$abs_top_srcdir ./configure $configure_options" | grep -v
'configure: loading site script '],, [Hello

and similarly for the other uses of $configure_options.

AC_CONFIG_LINKS should look in build tree; more AC_CONFIG_FOOs issues

As reported by Pallav Gupta in this thread:
<http://lists.gnu.org/archive/html/help-gnu-utils/2007-04/msg00005.html>
AC_CONFIG_LINKS doesn't search for its input file in the build tree,
rather it simply links to the source tree.

Here's a patch to expose the issue in the test suite, and a few more
while we're at it:

- AC_CONFIG_LINKS is not documented consistently to take FILE:IN
  argument.
- with INIT-CMDS, the initialization is not consistent wrt.
    ./config.status
    ./config.status TAG
  usage.  One way to fix this is to encourage
    init_var=...
    AC_CONFIG_FOO(TAG-USING-$init_var, CMDS, [init_var='$init_var'])
- several examples from the manual don't actually work with that format.

I'm not sure whether the patch below is sufficient in terms of
documentation, or even the best way to go.  If we could automatize bits
here, or avoid the need for double-initialization without shell quoting
issues, that would likely be better.  I think it will require some
surgery in status.m4 though.  (I'm posting what I have in case somebody
is eager to pick it up.  

So for the moment: ok to apply the status.m4 change of the patch below?

Cheers,
Ralf

Ajax call really slow...

Hey Guys,

I'm fairly new to Rails, so my guess is that I'm just doing this
wrong.  I have a site that I'm building that uses ajax to update a
list of items depending on what tab a user clicks.  Unfortunately, it
isn't live yet so I can't send a link directly to the site, but I have
it all working using straight HTML/JS/XML.  Where the problems start
is when I try to use Rails to generate the update.

At first I tried to use RJS to push a partial template that loops
through each item to generate the html block that I need to push to
the list.  I figured this would be easy and straight forward, but even
though I only have 2 items in the DB currently (will eventually be
hundreds) the list was taking 2+ seconds to update even locally.  I
even tried changing my technique to use :update on a link_to_remote
instead of the RJS template with no increase performance.

Next I tried leaving the javascript that I was using before in place,
but used a partial template to build the xml file that was requested.
This seemed to help the performance, but I still wasn't able to
decrease the load time to an acceptable amount.

Lastly, I'm trying to use an rxml template to build the xml instead of
looping within a partial template:

xml.items do
  for p in  <at> products
    xml.item(:tags => p.tags, :id => p.id) do
      xml.title(p.title)

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

Hello,

let me return to the problem reported on Thu, Mar 29, 2007 by Chris Johns:

> The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and that has 
> broken MinGW based cross-compilers using autoconf packages in MSYS.
> 
> The change is:
> 
> http://cvs.savannah.gnu.org/viewcvs/autoconf/lib/autoconf/general.m4?root=autoconf&r1=1.931&r2=1.932

the changelog entry is:

2006-10-04  Paul Eggert  <eggert <at> cs.ucla.edu>

	(_AC_LINK_IFELSE): Test that resulting file is executable.
	Problem reported by mwoehlke in
	<http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00048.html>.

I think we shall make a note in the comment above _AC_LINK_IFELSE,
e.g.:

# Test that resulting file is executable; see the problem reported by mwoehlke
# in <http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00048.html>.

> RTEMS uses AC_LINK_IFELSE and MinGW cross-compilers fail this test.
> 
> A MinGW compiler cannot set an execute bit on an executable as Windows 
> provides no support for it. MSYS emulates the execute bit by pattern 
> matching the file extension (.exe, .bat, .com) so a native Windows compiler 

Re: Ambiguity in autoconf info documentation

Hi Ralf,

On Wed, Apr 11, 2007 at 05:49:12AM +0200, Ralf Wildenhues wrote:
> Thanks.  I'm applying this patch.

> 	* doc/autoconf.texi (External Software, Package Options):
> 	Fix ambiguous wording.  Report by Reuben Thomas <rrt <at> sc3d.org>.

... and I'm applying the following fix to your typo.  

Stepan

2007-04-11  Stepan Kasal  <kasal <at> ucw.cz>

	* doc/autoconf.texi (External Software): Fix a typo in the
	previous change.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1143
diff -u -r1.1143 autoconf.texi
--- doc/autoconf.texi	11 Apr 2007 03:50:11 -0000	1.1143
+++ doc/autoconf.texi	11 Apr 2007 16:19:31 -0000
 <at>  <at>  -15924,7 +15924,7  <at>  <at> 
  <at> var{action-if-given} in the shell variable  <at> code{withval}, which is
 actually just the value of the shell variable named
  <at> code{with_ <at> var{package}}, with any non-alphanumeric characters in
- <at> var{feature} changed into  <at> samp{_}.  You may use that variable instead,

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

Stepan Kasal <kasal <at> ucw.cz> writes:

> 	* lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip AS_TEST_X
> 	when cross-compiling.

Thanks, I installed that.

Re: AC_CHECK_SIZEOF

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> I don't see a simple way for Autoconf to deal with function types
> short of writing a parser for C function declarations, for the
> AC_CHECK_{TYPE,TYPES,SIZEOF,ALIGNOF} macros.

I can, for C (except for AC_CHECK_ALIGNOF).  I can't see how to do it
for C++, but perhaps a C++ wizard can figure that out later.  I
installed this:

2007-04-11  Paul Eggert  <eggert <at> cs.ucla.edu>

	* doc/autoconf.texi (Generic Types): Document the restrictions
	on types imposed by AC_CHECK_TYPE, AC_CHECK_TYPES.
	(Generic Compiler Characteristics): AC_CHECK_SIZEOF now works
	with objects too.  Document the restrictions on its use.
	Document the restrictions on AC_CHECK_ALIGNOF's type argument.
	* lib/autoconf/types.m4 (_AC_CHECK_TYPE_NEW):
	For C, just try sizeof (TYPE) and sizeof ((TYPE)); if the former
	works but the latter doesn't, then it's a valid type.
	This lets people use function types and so forth.
	For C++ there doesn't seem to be a simple solution, so leave it alone.
	(AC_CHECK_SIZEOF): Allow argument to be a variable.
	(AC_CHECK_SIZEOF, AC_CHECK_ALIGNOF): Don't bother to invoke
	AC_CHECK_TYPE; that wasn't documented or necessary.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1144

Re: AC_CONFIG_LINKS should look in build tree; more AC_CONFIG_FOOs issues

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> 	* lib/autoconf/status.m4 (_AC_OUTPUT_LINK): Fix AC_CONFIG_LINKS
> 	to prefer a link source from the build tree, if it exists.
> 	Report by Pallav Gupta <pallavgupta <at> gmail.com>.

That part looks OK to me, thanks.  I haven't had time to think through
the rest (but I guess you haven't either .

Re: AC_CONFIG_LINKS should look in build tree; more AC_CONFIG_FOOs issues

Hi Paul,

* Paul Eggert wrote on Thu, Apr 12, 2007 at 02:58:02AM CEST:
> Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:
> 
> > 	* lib/autoconf/status.m4 (_AC_OUTPUT_LINK): Fix AC_CONFIG_LINKS
> > 	to prefer a link source from the build tree, if it exists.
> > 	Report by Pallav Gupta <pallavgupta <at> gmail.com>.
> 
> That part looks OK to me, thanks.

Thanks.  I applied that.

> I haven't had time to think through the rest (but I guess you haven't
> either .

Yep, that summarizes it well.  I'll redo, also the cross-test patch,
eventually.

Cheers,
Ralf