GNU bug report logs - #8540
Java "make uninstall" doesn't work after "make clean"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8540 in the body.
You can then email your comments to 8540 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Java "make uninstall" doesn't work after "make clean"
Date: Sat, 23 Apr 2011 13:53:23 +0200

Hello automakers.

Currently, Java support in Automake provides uninstall rules that doesn't
work after "make clean":
  
  $ cat > configure.ac <<'END'
  AC_INIT(x,0)
  AM_INIT_AUTOMAKE(foreign)
  AC_CONFIG_FILES(Makefile)
  AC_OUTPUT
  $ cat > Makefile.am <<'END'
  javadir = $(prefix)/java
  java_JAVA = foo.java
  END
  $ echo 'class Foo {}' > foo.java
  $ autoreconf -vi
  configure.ac:2: installing `./install-sh'
  configure.ac:2: installing `./missing'
  $ ./configure --prefix=/tmp
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... gawk
  checking whether make sets $(MAKE)... yes
  configure: creating ./config.status
  config.status: creating Makefile
  $ make
  CLASSPATH=.:./.:$CLASSPATH javac -d .    foo.java
  echo timestamp > classjava.stamp
  $ ls *.class
  Foo.class
  $ make install
  /usr/bin/install -c -m 644 Foo.class '/tmp/java/'
  $ make clean
  rm -f *.class classjava.stamp
  $ make uninstall
  $ ls /tmp/java
  Foo.class

While IMHO it's acceptable to provide uninstall rules that stop working
after "make distclean", having them broken by a simple "make clean" is
unacceptable.

Probably, the better fix is to write at "make all" time a file (to
be removed by "make distclean" only, not by "make clean") that lists
all the generated class files; then, at "make uninstall" time, that
that file can be used to recover the names of the files to uninstall.

Regards,
  Stefano

Message #8 received at 8540 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Cc: 8540 <at> debbugs.gnu.org,
 Petteri Räty <betelgeuse <at> gentoo.org>,
 tsuna <tsunanet <at> gmail.com>, Stefano Lattarini <stefano.lattarini <at> gmail.com>,
 9088 <at> debbugs.gnu.org, 8662 <at> debbugs.gnu.org
Subject: [PATCH] Make clear the JAVA primary will no longer be developed,
 not even for bug fixes.
Date: Thu, 26 Dec 2013 15:47:49 +0100

[Message part 1 (text/plain, inline)]

tags 8540 + wontfix
tags 8662 + wontfix
close 8540
close 8662
stop

References:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8662>
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8540>

The existing java support in Automake is (with the JAVA primary) is
botched and hardly usable, so I'd rather declare it frozen and spend
no more time on it.  The right direction for a better Java support
in automake is likely to implement the proposed new JARS primary:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088>

The attached patch enhances the manual to make it clear that the
JAVA primary support is to be considered frozen, and will not even
receive bug fixes.

Unfortunately, I will have no time to attempt that implementation
myself in the foreseeable future, but I sill hope someone else will
find the time and motivation to give it a shot.

Anyway, I'm closing the bugs referring to the old JAVA primary as
"Will not fix", to try to reduce the clutter in the Automake bug
tracker.

Thanks,
  Stefano

[0001-docs-make-clear-the-JAVA-primary-is-frozen.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.