Re: [PATCH] {master} coverage: more on java support: EXTRA_ and noinst_ prefixes

[Stefano Lattarini]

On Saturday 09 April 2011, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Fri, Apr 08, 2011 at 10:59:55AM CEST:
> > * tests/java-extra.test: New test, checking support for the
> > prefix `EXTRA_' with the JAVA primary.
> > * tests/java-noinst.test: New test, checking support for the
> > prefix `noinst_' with the JAVA primary.
> > * tests/Makefile.am (TESTS): Update.
> 
> > --- /dev/null
> > +++ b/tests/java-extra.test
> 
> > +# Check use of EXTRA with the JAVA primary.  Also test interaction
> > +# of JAVA with conditionals (it's natural to test it here, since
> > +# JAVA_EXTRA exists mostly for ensuring interoperation with Automake
> 
> s/for ensuring/to ensure/
> s/\(JAVA\)_\(EXTRA\)/\2_\1/
> 
> > +# conditionals).
>
Fixed.

> High-level question: I don't see where EXTRA_JAVA is documented in the
> manual.  Can we reasonably infer its semantics from somewhere there?

From section 3.3. "The uniform naming scheme":

  For each primary, there is one additional variable named by prepending
  'EXTRA_' to the primary name. This variable is used to list objects
  that may or may not be built, depending on what configure decides. This
  variable is required because Automake must statically know the entire
  list of objects that may be built in order to generate a Makefile.in
  that will work in all cases.

Is this enough?

> If not, I think it would be prudent to document intended semantics.
> Thanks.
>
I won't have time to look at this right now.  In case the documentation I
reported above is not enough, could you open a "wishlist" bug report so
that we won't forget about this?

> > +cat >> configure.in << 'END'
> > +AC_CHECK_PROG([HAS_JAVAC], [javac], [:], [exit])
> > +($HAS_JAVAC 77); $HAS_JAVAC 77
> > +AC_OUTPUT
> > +END
> > +
> > +cat > Makefile.am << 'END'
> > +javadir = $(pkgdatadir)/java
> > +
> > +EXTRA_JAVA = Class1.java Class2.java Class3.java
> > +
> > +java_JAVA = Class1.java
> > +
> > +if COND
> > +java_JAVA += Class2.java
> > +else !COND
> > +java_JAVA += Class3.java
> > +endif !COND
> > +
> > +Class3.java: Makefile
> > +   echo 'class Class3 {}' > $@
> > +CLEANFILES = Class3.java
> > +END
> > +
> > +echo "class Class1 {}" > Class1.java
> > +echo "class Class2 {}" > Class2.java
> > +
> > +$ACLOCAL
> > +$AUTOCONF
> > +$AUTOMAKE
> > +
> > +./configure cond=yes
> 
> This doesn't make sense to me, $cond is not referenced in configure.
>
Hmmm... $cond was definitely referenced in an AM_CONDITIONAL call in
configure.in when I tested the patch (this test script fails without
a proper AM_CONDITIONAL call in configure.in which defined the 'COND'
conditional).  I must have messed up with some last-time squash-in.
This is what I'll add to configure.in to fix the problem:

  diff --git a/tests/java-extra.test b/tests/java-extra.test
  index f1f7764..9c514d1 100755
  --- a/tests/java-extra.test
  +++ b/tests/java-extra.test
  @@ -26,6 +26,7 @@ set -e
   cat >> configure.in << 'END'
   AC_CHECK_PROG([HAS_JAVAC], [javac], [:], [exit])
   ($HAS_JAVAC 77); $HAS_JAVAC 77
  +AM_CONDITIONAL([COND], [test x"$cond" = x"yes"])
   AC_OUTPUT
   END

The test passes with this edit.

> > +$MAKE
> > +ls -l
> > +test -f Class1.class
> > +test -f Class2.class
> > +test ! -f Class3.class
> > +test ! -f Class3.java
> > +
> > +$MAKE distclean
> > +
> > +./configure cond=no
> > +$MAKE
> > +ls -l
> > +test -f Class1.class
> > +test ! -f Class2.class
> > +test -f Class3.class
> > +test -f Class3.java
> 

I will push shortly, barring new objections.

Thanks,
  Stefano